Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

>a well-intentioned UX Designer at a large high-tech company who was given a new project: Redesign an internal control panel that was ugly [...] It lasted one month before the company was forced to retire it. Users absolutely hated the new system. Sure, the old system was ugly, but it had everything they needed, right at their fingertips! Their jobs were incredibly fast paced—they worked in a tech support call center and were rated on productivity metrics. They didn’t have time to click or scroll to find information while the clock was literally ticking.

This same exact story of a UI disaster happened at a Fortune 100 company I was at in 2005. They had a legacy app (think DOS character mode talking to a mainframe) for entering accounting documents.

To replace it, a high-priced consulting firm installed a "web portal" technology. (Unifying a company's various enterprise applications behind a single web portal was a hot endeavor back then.)

When it was rolled out, the accounting department fell behind on their work. Nobody noticed that the constant UI banner at the top of the of the web portal browser window was forcing users to always use the mouse to scroll up and down to look at information. In the old DOS system, they could just enter info from invoices quickly without even looking at the screen. But the new system broke the users' fluid familiarity.

The UI disaster was so bad that the consulting company had to have their consultants come in on Saturday to help the client's workers catch up on all their data entry. Imagine an army of $150k consultants doing the work of $10/hour clerks because the web portal's UI was never really field-tested with a real-world workload! If just one UI web developer actually shadowed one of their users for a day, they would have noticed the usability problem.

I can't believe how many times I've heard your story but in different companies.

I feel like there is an opportunity to make a graphical user interface framework that mimics old terminals. Full screen apps that leverage use of the keyboard shortcuts or hell even a custom keyboard specifically made for industrial use. Basically a IBM 400 system but running on modern software stack. Airlines have stuck with their UI and for good reasons.

No. Just mimic the speed, information density, and task-centricity.

Even a web app could do that in a pretty straightforward way with proper handling of keyboard events and tab order and a compact layout. "Press 1/2/3/4 to select a tab" is entirely doable in a web view.

There are custom keyboards, they're just hard to find. The Devlin KMX-144 or the Logic Controls LK1800 come to mind. I'm sure there are others. You can use (n?)curses to make a terminal user interface.

I still prefer the web - just with the keyboard as a first class citizen.

I don’t think webapps can ever make the keyboard a first class citizen. The browser already has a bunch of keybindings.

Personally, I’ve never used a web app that I actually liked or trusted. Maybe it’s just me, but I’m always worried the page will time out or refresh or something.

Like imagine emacs or vim in a browser window, it would be horrible!

Try vimium, I've been using it for years - as long as the HTML is semantically correct a surprisingly amount of the web is navigable.

I wasn't going to mention qutebrowser[0] since I didn't think it was relevant, but it works well. Most of the keys in the browser can actually be rebound. With keyboards like I mentioned, the additional keys can be mapped to special key combos like `Alt+Shift+D` to avoid collisions.

It's also possible to map most or all of Chrome's (not sure about other browsers - but we're talking within the enterprise) keys can be rebound. Check out keycode.info - every key even ones like `Alt+D` and F1 and even `Ctrl+R` can be rebound and prevented from doing their normal function in place of something else!

[0]:https://www.qutebrowser.org/

Not sure the lesson here in going back to CLI. What designers need to do is to conduct research - interviews, observational studies, etc - to understand how and why people use their software and then create design alternatives.

Ignoring a learning curve for the sake of argument, the most effective UI's tend to be command-oriented. If you memorize the abbreviated commands, you don't have to traverse menu trees. Command-line interfaces can still have menus for newbies.

For example, pressing Enter or giving the command "m" or the fuller "menu" at the command prompt may give a menu similar to:

   1 - Search for employees (SE)
   2 - New hire (NH)
   3 - Department transfer (DT)
   4 - Etc.
   0 - Back to prior menu [app-wide convention]
   Command: __

Here newbies just enter menu numbers; but next to each menu is a shortcut command, such as "DT". After they get experienced, they start using the shortcut commands to jump across the menu tree as needed, they are usually global. It's like a Go-to (gasp!). The prior stuff is still on the screen for reference because they wouldn't get a menu when using the shortcut commands; it only shows up if you ask for one.

And the shortcuts may take optional parameters, such as "SE gar" to search for all employees with a last name starting with "Gar". (Without the parameter, they get a typical search form.)

Before GUI's, I worked with users directly to gradually fine-tune such gizmos, and after a while their productivity screamed. They loved me and even forgave my lack-luster people skills.

Many emacs modes use something akin to this (see magit as a stellar example). This makes learning it relatively easy (it's discoverable), but becoming a power user is still possible.

Yup. Magit is a stellar example of UI that's both discoverable and ergonomic. It shows you a popup with a list of options available to you at a given stage, with plainly visible keyboard shortcut. But it doesn't block or slow you down with this.

Say you're trying to show git log. The first time around, you'll press "?" to show the top-level popup, notice "l" is for logging, press "l", see the popup for logging commands, notice you need to press "l" again, press it. The next time around, you'll just press "l l" without thinking, and Magit will react as fast as you can type.

Being easy to use and easy to learn are not necessarily the same thing. GUI's are generally easier to learn, but not necessarily the most productive once a typical user reaches the plateau of the learning curve. A UI designed to minimize hand and eye movements may have a longer learning curve than a GUI. The ideal solution may thus depend on staff turnover rate.

I think you'd be surprised how quickly people can pick up on an interface that is as simple as the kinds of TUIs we're talking about. These kinds of things were very common for all sorts of tasks throughout the late 80s and early 90s and I don't think I've ever heard of the learning curve being a problem.

Shift+F5 F10 F10 code Return.

How to look up unsold inventory on the system at the first job I worked in 1999.

There people there who could navigate 5 screens without looking until the system returned the result they wanted.

People are smarter than many give them credit, the computing revolution in business really started taking off in an era when computers booted to something like.

    C:\>

I’m not suggesting we throw out guis but we could do much better in some areas.

Those old green screen apps (CICs etc) supported enormous key stroke rates all right, with nary a mouse in sight.

But productivity was not as high as a rosy colored view of the past might suggest.

Operators had to be highly skilled. Entering a record for the East coast sales team would require remembering the code ESALES03. There were no helpful UI affordances of the modern age, e.g. fuzzy or free form searching.

So combine the two, there isn’t intrinsically a reason you couldn’t do either with a TUI.

I work on enterprise systems and try hard to keep things consistent, it’s amazing how much enterprise web stuff I’ve run into that doesn’t even handle tab order correctly on a form that is pure data entry.

It’s hard to go all in on keyboard because browsers are somewhat inconsistent on which key combos do what though.

Reply on news.ycombinator.com