I upvoted it, but I have mixed feelings about it. I agree with the overall sentiment that it's ludicrous how much slower everything feels on computers these days: we're able to do more complex things than ever, which is great, but it's hard to rationalize why even the simple things that we've been doing forever have become so sluggish.

My first job out of college was to migrate an internal inventory management system from a in-terminal keyboard-based application (which nobody could be hired to maintain, as they stopped teaching IBM-RPG to college grads twenty years before) to a webapp. As part of gathering requirements I learned how to use it, and god damn was it fast. I watched salespeople and warehouse stockers alike fly through the menus so fast that they didn't even need to wait for screens to draw before advancing (and the screens were snap-quick to draw!), they just conjured the paths they needed from muscle memory and batched up a dozen keypresses and boom, done. I felt awful imposing this new laggy webapp on them, though I did make sure to at least leave the familiar keyboard shortcuts.

But at the same time I think the author is somewhat overselling the idea that keyboard interfaces are just as intuitive as mouse interfaces. To use the application above as an example, when we showed the new webapp to people who only had cause to use this system occasionally, they were able to navigate it more easily and professed to prefer it over the old one. Contrast this with people who used the system all day, who grumbled at the loss of productivity and need to re-learn things.

Keyboard shortcuts are great for power users who have cause to master an application thoroughly. For occasional users who don't need to master it and don't want to learn anything, a mouse will get them up and running faster. And, of course, there's still no excuse for how much lag and slowness we willingly endure in our modern UIs.

I feel like a large part of the unintuitiveness of keyboard interfaces is not actually an intrinsic quality of keyboard interfaces since they're so often conflated with command-line or TUI interfaces. There might be an alternative but yet undiscovered paradigm which combines the best of both worlds: keyboard control and intuitive, beautiful, graphical widgets.

To motivate this with a somewhat blunt example, what if we had a typical GUI but named each control (button, field, etc) with a short code (1-2 letters), in the style of Vimperator/Tridactyl/Vimium? You lose none of the intuitiveness and discoverability, but suddenly you can select the control much more quickly and precisely than clumsily trying to point a mouse pointer onto it.

And that's just a silly example I came off the top of my head now. There may be much better keyboard-centric yet intuitive paradigms.

>To motivate this with a somewhat blunt example, what if we had a typical GUI but named each control (button, field, etc) with a short code (1-2 letters), in the style of Vimperator/Tridactyl/Vimium?

Excel basically does this. If you hold down alt it hovers the companion hotkey above each function on the ribbon. It is very handy for learning your way around.

I think this is actually the big challenge with keyboard interfaces is that there is a learning curve. The advantage of mouse (or even mores touchscreens) is that a literal monkey can figure it out. But they're also limited in what they can do and how quickly they can do it. Meanwhile, keyboard based inputs take some time to learn but become extremely powerful once you're adept at them. But for non-power users who aren't that comfortable navigating a computer, it can feel like trying to learn a musical instrument for them. We nerds can flit from one interface to another because a lot of the general mechanics and muscle memory can carry over. But for people who haven't trained that skill it's much harder to learn these things, similar to playing video games. People who have never done it have no clue what they're doing when you put a controller in their hands.

I mostly agree with your point: keyboard interfaces are often harder to learn than the standard graphical mouse interface.

But I'd like to argue that a mouse also takes a bit of time to grok when you first encounter it. A simple interface like "each thing on the screen has a two-letter code; type the code to select it" doesn't sound intrinsically harder to explain to me than teaching someone how to use a mouse the first time. Especially when you consider that there's often a lot of subtlety in when to use the right or the left button. I find this is something that often trips up people that are encountering a mouse for the first time.

> no clue what they're doing when you put a controller in their hands.

May I agree to that?

I am a power user by any measure (CS major and program for a living) but still fail to grasp the controls of the simplest video game, to the point that, after hours of play, I still confuse (say) jump and attack

Older versions of Excel, that had traditional menus, did this by underlining the access key so you could see it immediately at a glance without first holding down alt and waiting. And so did every other Windows program (and OS/2, and GTK, and Qt).

I'm not sure if you're aware that standard GUIs (common 90s-style GUIs based on IBM's CUA[1] design) already do this. Every control can be assigned an access key[2] that allows you to access it with alt + some letter, with the letter indicated using an underscore.

The trend lately seems to be to hide the underscore until you hold down alt for a while, which makes the feature much more difficult to use when you don't know every shortcut by heart.

[1] https://en.wikipedia.org/wiki/IBM_Common_User_Access

[2] https://docs.microsoft.com/en-us/windows/win32/uxguide/inter...

I was aware of this as a thing that programs often did but wasn't aware that this was a standard. Thanks!

That said, I find that even when programs support this for accessing menus, they often do not support clicking buttons and focusing text boxes using it, so it could be taken further.

They can, and they often do (or used to). It works with both buttons and text boxes – the latter by connecting the text box to an adjacent label.

Have a look at some older piece of UI in Windows and hold down alt for a while. All we need for this to be taken further is for the programmer to pay a bit of attention to the existing feature and make use of it.

For a non-Windows example, I just looked at the XFCE appearance settings dialog. Hold down alt for a few seconds and you'll see that every single control has an access key: all the tabs, all the buttons, all the checkboxes, all the dropdowns.

I'm on Linux and I quickly tried some of my most commonly used software, such as Firefox and Deluge, but they did not seem to be supporting this, unfortunately. Only the menus get their access keys highlighted.

I appreciated his complaints, but not his solution. Only a programmer would think that going back to keyboards is a good idea.

Most people are happy waiting for a few seconds for their webpage to load, if it means they can do it without learning anything new.

Programming is a profession, and we design software for people who have other interests than software. Many of us would be better off if we got better at empathizing with people who are not like us.

> Only a programmer would think that going back to keyboards is a good idea.

He goes too far and his suggestions are nebulous.

But it sure would be nice to go back somewhat to the keyboard.

There are so many apps with broken tab-orders; so many common operations without common shortcuts; so many badly tuned completion engines; bad interactions with autofill, etc. There's a whole lot of stuff that I could do faster on the keyboard, but I am being constantly trained to not dare assuming I can fly through and the right things will happen. In any application that I am not positive will do the "right things", I am slow and tentative.

It's bad for accessibility, too. A vision deficit or dexterity deficit impacts mouse use harshly.

We need to go back to making the keyboard experience good. Not just in individual applications, but across the board. While we're at it, we should realize that being too free in design choices has negative impacts to user. There was a time that Apple really cared about this stuff, for instance, and usability on Apples excelled because you knew that there was a lot of effort in the developer community to do the right things and conform to common standards.

And you have to have 3 browsers because 2 of them are broken on some field. I wonder how often updates cratered green consoles back in the day. Curses could be tricky at times.

The path for many commercial UIs seems to be to map out complex processes into the most linear common path so that anyone off the street could do it. All that mouse action kneecaps productivity, and as soon as you come to an exception you enter a hell of popups or bazaar of UI elements.

Then of course they chop out all the keyboard ahortcuts.

Great UX is sort of like fusion, it’s always 30 years away.

Great UX is worse than fusion - at least once we get fusion done it'll be worked out, but UX will always be on the brink of regression.

>I appreciated his complaints, but not his solution. Only a programmer would think that going back to keyboards is a good idea.

Or anybody that has to deal with frequent input work -- anybody at a POS, a factory control center, an air traffic control tower, a ship, a library, and thousands of other such cases.

Those people would very much want to go back to keyboards if they used such an interface, and would very much would resist taking one from them for a mouse based interface.

And most of us are not that alike those people for many of our program uses, we just change between different programs, many of which could be modelled like the programs mentioned above (like TFA describes) and be far easier/faster to use.

That's true and actually that's a good point because I sometimes design software for people who key in stuff at a warehouse. I should ask them if they'd like those features.

It's funny I read the article without thinking I could apply the results at my job!

But going that extra mile is hard. In most shops like mine, what people need is more features and fixes, and elegant UI isn't a high priority. It's not all laziness, there is wisdom in satisficing.

>Most people are happy waiting for a few seconds for their webpage to load, if it means they can do it without learning anything new.

Ignorance is bliss. Show them a fast way and they don't want to go back. Unless your software has a "fast" and a "slow" mode you can't make assumptions that those users are "happy" with that delay.

I found the list great and it fit the twitter format well. I usually don’t like twitter but it is what it is and this seems like what it is good for.

I disagree about mice but everything else hit the nail on the head for how frustrating it is to be using basically supercomputers and still be sitting around waiting on code bloat.

I upvoted it because I wrote and spoke this last 20 years.

Keyboard buffer. You know what is keyboard buffer?

It's the thing that used to let me connect to a network in Windows 7 by rapidly typing win, s, n, f to open the start menu -> settings -> network -> Foobar Example VPN – without having to wait for Windows to catch up between the steps. The commands are buffered as you type and executed when the system is ready.

Of course, this doesn't work anymore in Windows 10. Now you have to wait for each bit of mysterious UI to load before you can click on to the next step.