“Modernizing” legacy applications and legacy users

Question

I'm tasked with modernizing many older UNIX based applications to new, web-based applications. The UNIX applications are completely keyboard-based (ie. "04" to select the fourth application, "Enter" to move to the next field, "M" to return to menu, etc.) The users of these legacy applications are used to this, and are quite fast at working with these applications, as they know their shortcuts.

When they see the new, web-based versions, they are often put off. They see a lot of clicking, and immediately feel like they can't be as productive. Some of the issue is stubbornness, some is training, some is possibly that the new interfaces are not as intuitive as they could be.

From a usability perspective, what are some things that can be done to guide these users? What sorts of shortcuts, features, and options can/should be built into web applications to allow for speedy data entry?

(Maybe it's a matter of introducing users to the "Tab" key and "File > Print".)

Answer 1

Philosophical background

For the user, the system is the user interface. This is actually the programmers' definition of an interface. You can change every other part as you wish, as long as the interface stays the same the users won't notice. As soon, as you change the user interface however, you affect users' life.

DA01 is right on that for data-heavy applications, albeit they have a really large learning curve, the keyboard is the best interface.

However, they're not intuitive. They don't really tell the user how they should be used. They usually require a handbook, internal help, and lots of training.

So the question is: how could you make clickable applications which could be still used using the same old keyboard shortcuts all your users are used to, while presenting fresh / untrained users with an intuitive interface?

Research Background

Learn everything you can about the following things:

• Jeff Raskin's biography, as he was a big fan of the keyboard
• The Canon Cat (Raskin has made it), and Archy
• The Humane Interface from Raskin (Pro Tip: Amazon doesn't offer a kindle version, but Safari Books Online has a digital version which you can read with their reader on iOS / Android
• Mozilla Ubiquity, the user interface designed by Raskin's son, Aza Raskin (a notable UX designer on his own right)

Perhaps it's a bit one-sided, all of it is Raskin stuff, but they still show you how to make an effective, keyboard-based user interface, something you can't find in the latest "how to design for Touchscreens like iPhone, iPad or Android" kind of books.

User research

Next thing: get a screen + keylog, and learn how people use the system. An effective tool for this would be the UNIX script command, which creates 'typescripts', which you can replay. Hopefully, there are no hidden character shortcuts, otherwise you may need keymon as well.

Making storyboards of original functionality

Next, draw a flow diagram, with each keyscreen connected with an arrow, and for each arrow, write down the keys which actually get you there. An example would be:

Enhance functionality

Here comes the trick: re-design each of the keyscreens with their graphical equivalent, ensuring, that the keyboard shortcuts stay the same between them

It can be that you don't need confirmation, but would rather like to have an Undo instead. Make sure that in this case the "y" to the confirmation gets eaten up without causing any errors (like, if an y comes within 1 second - cognitive barrier time for feedback - ignore it)

It can be, that the menu is not taking up a full screen by now, that's also fine, just make it highlighted when M comes, so they know they are at the right place. Give them feedback (based on the Norman book), just like what you'd do normally. Still, keep keyboard-level consistency.

Also, ensure that everyone has all the information at all the keyscreens to have the right decisions. For example, when saving a form, the form itself should be visible. This might not have been possible with the old interface, but this time, you have pixels to work with.

Make the user interface clickable

While keeping yourself to the previous rule, that is, keeping the system consistent, make it more-or less handable by GUI as well. It can be, that the GUI flows are a bit alternative,but the system should still respond to the same keyboard sequence the same way.

Give keyboard hints

In order to help new users learn the functionality, design a visual clue to handle keyboard shortcuts. An example could be:

(Not exactly aesthetically pleasing, but it's still nicer than a text-only interface I hope)

The perfect solution would be to handle these contextually, that is, enable them only when context actually allows their usage, this might, or might not be possible. Eg, a "Save" button could be enabled for click, but could be disabled for shortcut if there's another field in focus. Wether you show it to them with a disabled button (which is disabled both keyboard-wise and click-wise in its current state), that's up to you.

Also, you could allow users to hide these based on preference,it just frustrates the old guys, also those who prefer not to learn it at all, but helps transition perhaps.

Design a keyboard-based controller (devs task)

Tell the programmers the original Krassner & Pope MVC did think of MVC in a way that keyboards could be also used. This is actually the MVC what is quoted in the Design Patterns book. It might be a different model than what they're used to nowadays, but that's life. And again, this is actually a challenge: you have tons of users to support, with a literally easy to use interface! :)

Test prototypes with users

You'll have two group of users: those who know the keyboard shortcuts as muscle reflex / muscle memory, and those who don't. Test on both. You know, usual thing, story goal, try to go through the system and achieve the story goal, how did you feel, did it went well, think aloud, did it feel ok, where you lost at any point... UX research stuff.

Implement application

That's it. Tedious process, but a unique challenge to build an interface which is usable in a way we don't think anymore today of usability. I think it's worth it, this would be a pretty good adventure, I'm sure I'd love it. Then again, I have my own muscle memories myself, having started to use command line UNIXes in the 90s, I still use command line on OS X even to watch my movies sometimes, as it was the only way back then...

Or

Just wait for the old users to die out / leave company. That's also a solution.

Hope this helped.Enjoy the ride, seriously, this will be unique and fun, UX is about making the best experience for users, not about shininess!

Answer 2

The Superior Efficiency of UNIX Apps

UNIX UIs have a tradition of favoring user efficiency over learnability. For example, UNIX’s designers ask, “Why type “rename” when you can more quickly type “mv” instead? Who cares if that’s harder to memorize?” I expect the UNIX versions of the apps do in fact allow users to do whip off the tasks with remarkably little time and effort. That’s an important part of being usable.

For example, using GOMS KLM operator times, it takes on average only 1.6 seconds to select a menu item by typing two keys like “04.” In contrast, it takes on average 2.5 s to select a link with a mouse –or 2.9 s if the user has to move his/her hands from the keyboard to the mouse (if most other input is text). If there’s a lot of selection like that, the web apps are going to feel noticeably slower.

If each link selection includes a full browser page-load that takes a second or more, the web apps are going to feel downright clunky. In contrast, your average UNIX app can display a new line or even a whole new screen in less than 0.1 seconds. If you watch your users, you’ll probably see your expert users firing off chains of memorized inputs like they’re typing a single word: “04021206, okay I’m on the right screen, what do you want me to do?” So your users have a point: you may be giving them a user interface that is less usable (in terms of efficiency) than the one they have now. Why should they be happy about it?

The Superior Learnability of Web Apps… or Maybe Not

In theory, web apps have excellant learnability, a different dimension of usability than efficiency. With simple point and click input and on-screen descriptions and hints for the user, a user can get through the app on their first time without once typing “man.”

However, as you imply, maybe the new web apps are not more learnable. If the UNIX apps feature menus listing options along with the keys to select them (e.g., “01 Network Edit, “02 Troubleshoot, 03 Deploy, M Main Menu”), then it’s plenty intuitive. How is Tab easier to learn than Enter? It’s only a matter of what you’re used to. If the apps have your basic form-and-menu UIs, then going from UNIX to web by itself is not going to make it more learnable. All it gets you is proportional font and pretty colors. Big whup. Being modern just for the sake of being modern is not going to cut it.

And if your web app includes just a couple badly chosen field orders, icons or link labels, or IA choices, it could easily be less learnable than the UNIX app for your population of users.

Solutions

So maybe the situation is you want your users to make the effort of learning something (in boring training or frustratingly on their own) that is slower to use than what they’re used to. It can’t be surprising they don’t like it.

Learnability

First of all, you need to make the web app as learnable as possible for your particular users. So put in keyboard shortcuts like “03” to select the third menu item and “M” to go to the home page/main menu. Make Enter advance to the next field. Who cares if it isn’t standard? Standards are only good if users know them. If you have both legacy and new web-savvy users (now or in the future), then consider making both Tab and Enter advance to the next field. Or, if UNIX users use Tab for something else, or your other users expect Enter to execute a dialog (the GUI standard), then consider a Legacy Mode for your legacy users which uses the legacy shortcuts.

If you have to, include text hints and reminders on how to use the web apps. But remember: reading even brief documentation takes time and distracts the user from the task. It’s better than using man, but not as good as not needing anything. Consider using imagery and metaphors to more quickly document the UI (e.g,, lines and arrows directing the user through the task flow).

More than Learnability

Maximize learnability is not enough because your legacy users already know the UNIX apps. Sticking with UNIX means zero learning, while going to web app is going to mean at least some learning, however small it is. You can’t possibly win on learnability alone. To get the legacy users’ approval you need to beat the legacy apps at their own game and make the web apps more efficient than the legacy apps. Get better efficiency (with techniques I describe below), and then publicly race the UNIX apps against the web apps to convince yourself and your users the new app is faster once they learn it.

If you can’t make the web apps more efficient, then you need to provide some other benefit: reduced errors, faster error recovery, more convenience (e.g., can be used remotely or when mobile) –something. You have to make the web apps sufficiently better that it’s worth the learning effort.

As part of doing this, study the legacy system and watch the experts use it and find:

• Advantages to include in the new system, such as keyboard shortcuts, and quick popups.

• Weaknesses to avoid in the new system, such as absence of defaults or lack of preserved input, or text input when a menu can be used.

• What users care about -what you can give them more of in the new apps.

Minimize Navigation and Raw Time

Capitalize on the fact that you probably have more screen real estate than UNIX apps were designed for all those years ago, and use it to minimize navigation overhead and present a clearer information hierarchy. Use AJAX or other tools to further minimize the “excise” of navigating and make response times 0.2 seconds or less. Avoid confirmation pages and errors message –use on-page feedback instead. Validate input one field at a time using this kind of feedback. Use edit-in-place forms and tables –avoid dialogs.

Suite Consistency

Make sure you web apps are internally consistent. If users have to stop and think which rule applies in a given context, you’ll kill efficiency. Make sure the same action has same effect throughout your suite of apps. The same command should have the same label, same icons, same shortcuts, and same relative position throughout the suite. The same field should use the same name, graphic codes, units, and format throughout the suite.

Other

General design elements to improve efficiency/speed include:

• Keyboard shortcuts, already mentioned.

• Context menus, which shorten the slew time to menu items.

• Drag and drop especially as an alternative to a dialog.

• Terse but clear labels (faster to scan and read than the verbose labels typical of web apps).

• Progressive disclosure, used carefully for rarely used features that can distract users.

• Order menus from most common to least common choices (while still keeping order semantically sensible when necessary).

• Good defaults.

I’ve more on handling legacy users and experts in general at What Have You Done for Your Power Users Lately?

Answer 3

It sounds like these are primarily data-entry heavy applications. As such, keyboards are likely the quickest and easiest way for the users to enter the data. I'd suggest keeping it that way. Make sure the app is fully keyboard navigable and include appropriate keyboard shortcuts (perhaps as an end-user option)