Hacker News Reader

I think that's absolutely fair. The pace at which the industry is starting to solve really big, hairy problems in standard ways is ever accelerating; the devops space right now is undergoing massive solidification under the Cloud and Kubernetes. UI is one of those problems I hope we're humble enough to admit that we got horribly wrong with HTML/CSS, and maybe we need to go back to square one.

But at the same time, lets pick on Slack. There's no good reason that it needs to take more than 5 seconds per team to load. Maybe its Electron, HTML, and CSS. Maybe they're loading too much data at the start. Maybe their Ruby servers are a little slow.

All of that could be true, but one thing is definitely true: There's a Product Manager or an Engineering Lead somewhere in San Francisco who looked at what their engineers had built and said "Yup, this lives up to the quality our users expect, ship it."

Jira is the same way. Its dog slow. Its full of UI bugs and inconsistencies. But people still buy it, and someone at Atlassian has to have said "we'll worry about this UI bug later, we have more reports for middle management we want to add to the product."

Our best minds will solve the tremendously difficult UI problem one day. But today, the best thing most of us can focus on is the People problem. Expect and Pay for better. Reach out to leaders at these companies on Twitter. A core problem in the software purchasing process is that, often, the people who buy the software aren't the people who have to use it day-in day-out, and often there's obvious lost productivity between the feature bullets on the marketing page and an engineer on an old PC her company won't upgrade for another year.

Will we ever solve UI? UI is the meeting place of tech and user, and in a sense it is THE problem for humanity right now. UI informs how we tend to use the internet, and for example we are currently involved with UIs that tend towards consumption (e.g. discovery mechanisms, feeds, etc). To solve UI would imply a certain optimal way to live our lives, if that exists. I agree with you that UI is unsolved and extremely complex, but I don't think it something to be solved as much as it is the political heart of technology.

There’s an inherent dichotomy in UI in that the most “efficient” interfaces generally have the steepest learning curve. You can be really efficient in a terminal or VIM. But figuring those out take a lot of work.

When we design interfaces we try to make them have a short learning curve but expose greater ability as you use them but it’s still hard.

That makes sense, for example Reddit has a very simple concept with the upvote/downvote, but also more advanced features if you need them. But I would also argue that UIs also implicitly convey a preference for how data on the web should be organized, and that affects usage.

For example the feed, besides being a UI pattern, also claims that content on the web is for consumption and not exploration, and so we remain stationary on these aggregation platforms instead of 'browsing' the web as we used to. This is efficient but politically bad for society, and we would need to introspect on how we use the internet in tandem with the development of new tech like decentralized platforms.

Duckduckgo David Galernter and Lifestreams. He predicted the feed over 20 years ago but his vision accounted for the exploration aspect as well.

Completely agree, but we can also figure out how to make it easier. Take a look at http://kakoune.org/why-kakoune/why-kakoune.html#_improving_o... (this is the section that introduces the flip on vim's command structure, but is otherwise a great article to read top to bottom).

There are a lot of ways vim is right or not right, but this lowers the barrier to entry in a profound way. We can keep advancing like this, and stacking those advancements on each other until vim isn't hard. Maybe? What do you think?

I think one of the big ways vim is hard is what Kakoune attempts to fix - visualizing selection. Adding a "layer" to working in vim, we had `u` and `^r` to figure things out - doing something and knowing we could go back. Now with Kakoune we have movement before action. This adds another way the program can converse with the user.

Disclaimer: I don't use Kakoune, but I dig what it's doing and I want to try it out. I think it is a fantastic critique of vim.

I'm not trying to say Kakoune's exploration is without value, but Vim very much does have "movement before action" mode. It's the visual mode, entered by the "v" key. It's the main feature vim has over vi.

https://en.wikipedia.org/wiki/Learning_curve

> The familiar expression "a steep learning curve" is intended to mean that the activity is difficult to learn, although a learning curve with a steep start actually represents rapid progress.

Well, progress along the Y axis is only achieved if progress is made on the X axis too. If the curve is too steep, the user is expected to learn too much too quickly, and many will simply give up.

The X axis of an actual-jargon “learning curve” is effort, not time. Steeper slope means higher “learning ROI”—more learning out per unit of effort invested in.

I think this is nowhere more evident than in the world of games. In my opinion RTS games stagnated and died because they failed to innovate in interface department, outside of a few like Total Annihilation / Supreme Commander. The classic Dune2/Warcraft interface only works for selecting single units and squares. So when any bigger engagement happens, it's just people throwing blobs at one another and juggling group hotkeys.

I think RTS games should be controlled primarily by keyboard, not mouse. Select units of X type by pressing a key, target them at units of Z type, make the command 'attack' by pressing A. Vim-inspired.

It's not surprising that games are chiefly aimed at the least patient people - the goal of publishers is to sell to as many people as possible.

Hmm. To me, large-army games and small-army games are just very different games, and I have little interest in large-army games. I don't see Total Annihilation ever replacing StarCraft for me, for instance. If I could only control the game via keys, I'd be very uninterested as that'd be a very different kind of game. Most of these games went turn based for a reason.

I specifically like AoE II for the feeling of grabbing a pack of Mangudai and watching them quickly run somewhere and fire arrows. It's not realistic, but it's understandable and pleasing, in a way that a super serious military simulator isn't.

I think RTS, like many other genres, mostly "died" due to stagnation around clones, which I think has more to do with the industry at large that is not innovating all that much anymore, and RTS is often not the genre of choice for a small indie developer, either.

> we are currently involved with UIs that tend towards consumption

Astute observation. Clearly this relates heavily to our culture of consumption and the asymmetry of creation/consumption.

But I wonder if another important part of this is related to the divide between how humans learn to do things and how computers can't teach humans very well. If we could automate showing people how to accomplish their goals, we'd be empowering creatives. So far, this task is relegated to youtube videos (e.g. "How do I make two shapes into one shape in Adobe Illustrator?").

>UI is hard

How many people are actually putting effort into their UIs? How many people do usability tests? I know Microsoft has done them before, but what about Slack? There are a lot of complaints here about their UI. I'm sure not many free software projects do usability tests.

You can't just slap things together and hope for the best, you need to have tests, and you need to run the tests again when you make changes. We've already learned this with the software itself.

I've been reading "Designing User Interfaces for Software" by Joseph Dumas from 1988. It enumerates common usability issues at the time, but many of them are still common. Inscrutable error messages, inconsistent terminology, unexpected interactions, the list goes on. These are solvable problems by they require a departure from "worse is better".

I'm not sure that UI is hard, it seems like it just requires effort to be put forth.

> I know Microsoft has done them before

And they added toggle switches to UWP (https://docs.microsoft.com/en-us/windows/uwp/design/controls...) that are usability disasters IMO.

When such switch used alone you cannot tell in what state it is - you need to remember that "on the right - is on" (yet what about RTL environment?).

While there is no such problem with old plain checkboxes.

I designed a very convenient interface for my otherwise extremely simple Chess program.

In most chess games, keyboard interface works like this: one axis has labels 1, 2, 3, 4, 5, 6, 7, 8; the other has a, b, c, d, e, f, g, h. Then you movie pieces by inputing stuff like b4 d5. This is AWFUL. You have to look at the border of of the chessboard to see which row and column your chess piece is in. It wasn't designed for humans to play, it was for keeping records of matches and tournaments.

My interface works differently: each of your pieces having valid moves is assigned a key on keyboard. For example rooks could be labeled 1-8, others a-h. You select a piece to move simply by inputing its symbol. When that happens, spaces reachable with legal moves become labeled with symbols... You see where that goes. You look at a piece you want to move, read its symbol, then read the symbol of the place you want to move to. In each case you look at pieces or spaces that interest you, not at X and Y axis.

I've mentioned his name elsewhere in this thread but Aza Raskin had some very interesting thoughts on this subject.

One of his main assertions was a big problem is the whole app paradigm. The whole notion of silod apps bound to native widget tool kits is very limiting and that the host platform should really just provide a facility for running commands.

I think a simple data-display UI shouldn't be that hard to code. Every program you run has access to a terminal, which it can use to display and read text. It shouldn't be hard to extend that to displaying and reading structured data. One dream I have is to have a Desktop where each program can send an ioctl to stdout that turns it into a stripped-down browser, so it can then just dump XHTML data and have it be visualised on screen, while stdin feeds you json-serialized user input, e.g. user entered text X in input field Y, or selected file Z. It won't be useful for multimedia or anything like that, but will make building simple one-off UIs much easier.

The difficulty is not just in coding the UI, but crafting one that's easily and intuitively understood by users. We haven't yet established a universal design pattern for GUI's yet, to the parents point, just a bunch of conventions that are often tossed in favor of something new.

A 'solved' UI example would be of a car (not the radio, but the operation of the vehicle). Learn to drive one car, and you can pretty much drive any car - same pedals, steering wheel, gear shift, turn signals, etc. I don't know if we'll ever get to something like that for software though.

IMO, intuitiveness is overrated.

As one snarky joke goes: only the nipple is intuitive, everything else is learned.

And as anyone with children can tell you, the nipple is far from intuitive.

Explain.

That's a hilarious joke, made me LOL. If you want your product to be used though you have to think about what users already know how to do and try to build off of that. This is why baby bottles and skeumorphic design are popular and effective.

Since when does intuition exclude learned information? It's very much relevant to, say, what interfaces people have used before.

You might be thinking of instinct.

I wouldn't compared all GUIs with the car; the car is more like a particular type of GUI, say, of word processors. Plus, the basics may be standard, but everything else (mainly the dashboard) is still quite a mess. I wouldn't say it's solved at all.

If you know how to drive cars, you will still not be able to drive trucks, motorcycles or tractors. Software in general us more diverse than the types of vehicles that are in existence.

If you want to make a car analogy, then you should compare cars to browsers. And these have very similar UIs, the underlying stupefying complexity nonwithstanding. So we seem to create standardized interfaces for certain common classes of user interfaces over time.

I think that people tend to think in terms of discrete and dedicated appliances because this is how the real world is structured. Being faced with a small box with the overbearing set of capabilities of a swiss army jackhammer (atomic bombs included) ends with confusion unless lot of time is devoted to trying to discover and learn all the magic spells to which that infernally picky and annoying thing will respond meaningfully.

One more thing RE car analogy. People are spending 30+ hours learning how to operate a car before being allowed to do it on their own on public roads. Software vendors no longer expect users to spend even 5 minutes learning. This is a cultural problem.

As someone who has only been driving for a couple of years, please don’t make my UI as complicated as my car's 'interface'! I take your point about 'portability' (although different cars are notoriously different to drive - even the gear pattern on the stick varies between different manufacturers) but the initial learning curve is incredibly steep. If I really wanted to, I could learn emacs from a manual. I can’t imagine learning to drive without another human involved.

Building UI/UX demands designing an API for people to use not people's code to implement. The developer must take into account the "existing libraries" available to their end users (people or code) and the human equivalent of "libraries" is generally unspecified, varies greatly, and is slow to teach and learn.

The process to get there takes time. A clever simple solution always look easy to come up with.

Creating Intuitive interfaces has been solved, you need a design centered culture, a good design system, and implementing user centered methodologies (look into human factors, cognitive engineering...)

It takes more investment upfront, but it’s worth it in the long run.

I think that one of our biggest problems with UI is that it is immutable.

Users can't really change most UI. Developers have to make one ultimate one-size-fits-all UI for all of their users.