In the EHR space, all the CMO (chief medical officer) cares about is it helps keeps them in compliance. Why should they care if it’s hard for their office staff to use?
So there were two sides, the engine optimizations to assure things like tab orders on a form, and the was the actually writing the form descriptions. In the first couple organizations that adopted it I wrote the forms and the engine in parallel adding feature flags/controls as needed to support the desired UI outcomes. Later after I quit, the lady who wrote much of the RFP responses started writing the actual form descriptions because it was just as easy as drawing them out in the (visio?) plugin she was using with MS word and doing screen captures for the RFP. Then I guess because she knew how to do it, was doing the "tuning" as well.
The latter is definitely not the problem. Even the Twitter re-design from a couple years back still supports all the old hotkeys.
All it takes to at least support a tab-based workflow is using the "tabindex" property if your form isn't logically laid out already, and the rest can be done by capturing hotkeys.
Even multimedia content can be operated using hotkeys. Youtube is a good example. There's no excuse but laziness and incompetence IMO.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
If you watch people use the sabre command line interface (the one from the 1970s?), you can see some of what i'm talking about when people are just filling out the forms with the submission line, its less using the GUI and more just knowing some sequence of keystrokes that results in an action being taken.
AKA its possible to do both, without having the user wear out the tab key, or grabbing the mouse all the time.
A sign up form that a given user will only use once in their lifetime is another matter. It needs to be simple lest the user abandons the process. Most users in that case are not willing to learn keyboard shortcuts, tabbing over optional fields probably makes more sense here.
I'm constantly writing UI for sports teams who do not at all like to waste time with these kind of fiddly UI elements and flows. Most of them would likely stick to Excel if our solutions are more cumbersome (which is a high bar to meet/beat, but rightfully so). They need to be able to easily get to data and relevant, connected pieces of data, quickly enter data into relatively complex forms, and have it all be clear, reliable, and fault-tolerant. This means making some tradeoffs, particularly around what is considered modern UI aesthetics, and doing things most UI developers don't need to do such as automating little things, adding hotkeys, etc.
Kind of a hard core position in my opinion considering it's ignoring the sometimes advantages / use cases for client side code (like complicated SPAs where the user is explicitly buying into the idea of running lots of code in their browser, figma comes to mind) but I still like to think about it here and there.
99% of web applications are not Figma and probably do not need any client side JavaScript. The amount of JavaScript that's actually just wrong is incredible.
1. I don't care what your client side validation thinks. That is my email address.
2. Why are you serving people all of the news story if you are going to then hide it? We can block the JavaScript and read the news.
So I don't disagree on merit alone, but it seems if we wanna do a good capitalism, we need to make sure people are actually giving us real emails apparently
In fact, it makes the experience generally worse.
Tying this back to the top-level comment: at some point I've realized that so many SaaS would be better off as an Excel sheet, because they're fundamentally just a slower, buggier, much less productive and uglier version of one. But the point isn't efficiency and empowerment. The point is control: the SaaS forces the user to a specific workflow. One that makes it easier for developers to develop (by constraining the problem space), or for company to monetize, or for corporate to retain legibility - but rarely to actually help the end-user.
As an end user from a generation that was taught Excel and MS Access at school, I'd go as far as saying that 50+% of web applications I use would be an order of magnitude more useful if the UX was that of Excel or Access.
I preach this all the time. Anyone who has to enter data really wants excel and not the fancy wizardized stepped workflow that seems to be the norm nowadays
I suspect an overwhelming majority of use cases is for this reason alone.
As you say the web is a culprit but so is attempting to shoehorn mobile designs into desktop.
With some OS's you can't even have fine grained control over those defaults anymore. Dark modes have brought some of it back, so its better now than 5 years ago, but still worse than 20 years ago. But people pretend that having a dark/light switch is the same thing as being able to customize the color of just about every layer of the UI and have the vast majority of the applications honor it.
Where we partially lost that is when UX started to get async. It's not fundamentally incompatible with well-ordered input messages, but in practice, people who write async code all too often forget that it's async all the way (and not just for their favorite scenario). And so you get travesties such as textboxes that let you type text into them, and then erase all that when the app or the page is "fully loaded".
I was at the post office here in Australia a few years ago and saw the screen. It was one of those DOS-era full screen red and blue text interfaces. She was flying through hotkeys and getting things done. People can learn, so much software treats them as infants.
And you know there's definitely someone looking at replacing that software with a modern GUI.
You should see the customized JBHIFI terminal + keyboard.
Bloomberg terminals also have a custom keyboard and are essentially a terminal program.
It was supposed to be read:
A [ncurses or gum] workflow.
Gum being an alternative method of making a Bash UI.
At the time I had no idea why. In hindsight, it's hilarious. I'm guessing it was the result of a clash between someone that wanted to use modern tech for the sake of it and someone representing the users that told them to get fucked, probably went through 15 meetings before eventually getting palmed off on the intern so it didn't pick up too much steam (probably the only good decision that was made in the whole process).
So learning an interface is frowned upon. Every interface must be designed as if the user has never seen it before.
Which is ok, as long as there’s also an alternative path which may take time and effort to learn but leads to increased efficiency and productivity.
Unfortunately, that alternate path takes a lot of effort. And worse, it leads to very few extra sales. The company which puts in the effort to build a complex but efficient workflow in addition to the initial easy workflow will get beat in the market by competitors who only focus on the easy workflow that looks great in demos leading to the C-suiters to buy it.
The best example is the pioneer of both these trends. Apple. It used to be that Apple insisted on a single button mouse so the primary interface was extremely easy to use. Yet, it spent a lot of effort including keyboard shortcuts, which were prominently displayed, everywhere. Unlike Windows, which basically only had Ctrl/Alt modifier keys, Apple has had the Ctrl/CMD/Opt modifier keys as integral parts for a very long time, encouraging those shortcuts. Apple also put s lot of effort to make their, and 3rd party applications easily scriptable (the choice of AppleScript however always held this back). The most MS did was VBA for Office.
But once Apple entered the iEra, it realized it didn’t need any of this to sell products anymore. The massive lag in supporting basic keyboard shortcuts on the iPad when using a keyboard is one of the strongest evidence for this.
Completely agree with all of this.
Adding that it's not even web technologies that can't be used. My work Mac had an issue with a Bluetooth mouse, removing and adding a Bluetooth device with the keyboard is basically impossible using tab as nothing gets highlighted to show you switched to it and some of the crucial parts don't get toggled through.
Modern GUIs are absolutely not fit for purpose.
No one knows what they really want till the software starts getting written and someone finds out they can't do their job, then come change requests (made a lot of money off of them). You kind of just get numb to it all.
Early GUI's didn't have the problem you describe because they were designed as discovery mechanisms to the underlying function. AKA, the idea was that after clicking File->Save a dozen times you would remember the keyboard accelerators displayed on the right hand side of the menu. Or if nothing else, Remember that the F in File was underlined along with the "S" in Save (or whatever). Which would lead people to just press ctrl-s, or Alt-F, S. Then part of testing was making sure that that the tab key moved appropriately from field to field,etc.
I remember in the 1990's spending a fair amount of time doing keyboard optimization in a "reporting" application I wrote (which also had an early touchscreen) for use by people who's main job wasn't using a computer. Then we would have "training" classes and watch how they learned to use it.
So, much of this has been lost with modern "GUI's", even the OS vendors which should have been keeping their human interface guidelines updated, did stupid things like _HIDE_ the accelerator keys in windows if the user wasn't pressing the Alt key. Which destroys discoverability, because now users don't have the shortcut in their face. Nevermind the recent crazy nonsense where links and buttons are basically the same thing, sometimes triggering crazy behaviors like context menus and the like. Or just designing UI's where its impossible to know if something is actually a button because the link text is the same color as the rest of the text on the screen..