I recently completed an enterprise architecture assessment for a client, and one issue in particular was a major pain point for them. I've seen this problem before, and struggled with it in my own design work, but I've don't recall reading much about it. What I'm talking about is hard to sum up in a few words. I tried to do this in the original, somewhat ridiculous, working title I had for this post:
Web UI Design for Keyboard-Based, Data Entry-Oriented Users of DOS and Mainframe Apps
I used to be one of these users. I got started in software in 1994 when Clipper was still in style (though not for much longer). I worked for a company that sold a shrinkwrap DOS app that had a character-based display (that is, screen display was "graphical," but only using ASCII characters), used a hierarchical menu system, and had 100% keyboard-based navigation. I also was a DOS command-line junky. Not to mention, we had several other DOS-based apps that were all keyboard-based. It was all about the Enter key, the arrows, the Tab key, the Esc key, the Num pad.
Our application was somewhat complex, and I knew my way around that thing with my fingers like you wouldn't believe. I could drill down four screens, enter some data (tabbing from field to field), escape back up two levels, hit F12, wait a beat, hit Enter three times, and finish the sequence off with another Escape--all in a flash. In case I sound like I think you should be impressed, this was true of many people I knew. It took you a little while to figure it out, but once you did you could fly through a user interface.
Say what you will about all that crusty old technology, but you could really reach a level of operator efficiency that's tough to match in today's mouse-based navigation systems.
Now imagine that you work in a bureaucratic office deep in the bowels of a large corporate campus, and that you have been using the same keyboard-based COBOL application for the last nine years. You know your job like you know your kids' faces, and nobody does it better than you. (Imagine also that you have not seen an error message from this application in *months*--but that's a whole other story.) Imagine you have reached a level of keyboard Zen by this point that's just scary.
Also imagine that your boss is telling you that your favorite old application will be going away soon because the hardware it runs on has become old, fragile, and expensive to maintain. The data center just tripled the hosting fee as an incentive to get your department off of the thing. (In fact, your company has in it's possession all of the known replacement parts for this server that they could find anywhere, and the data center staff has literally placed a statue of a vulture on top of the machine.)
You are going to miss your old friend, but your boss tells you they got some of these web guys comin' in to make you a new application. You are promised it will look better, run in any web browser (even from home!), and you won't be limited to just 34 database fields any longer--you'll be able to have hundreds of fields! You are definitely excited now, even though you're still a little trepidatious about losing your familiar tool.
So these web guys show up and ask a bunch of questions about how you do things, and you do your best to tell them. They go off, and a couple months later your boss tells you it's time to switch to the new web app. It has all the same functions and menu choices you're familiar with, and they even thought up a clever acronym for a name.
With the "web guys" you're company hired, it wouldn't even have mattered if they'd given you a chance to test drive the new application first because they don't realize two things:
- To do your job you have to process 30+ paperwork packets a day. If you don't process them that fast, you're going to hear about it.
- What has enabled you for nine years to be the best, fastest, most accurate paperwork packet processor your company has ever seen is the fact that your keyboard-based COBOL application enables you to fly through the application as you process the paperwork packets.
They got the functionality right. It's all in there. Everything sounded correct in the requirements specification document. But now, with your new web application, it goes like this:
- Click the New Packet button.
- Wait.
- Switch from mouse to keyboard; enter the data on the first screen.
- Switch back to the mouse. Click the Next button.
- Wait.
- Read error message from the server; switch back to the keyboard; correct the data entry mistake you made; switch back to the mouse; click Next again.
- Wait.
And on it goes. Bang. Head. On. Desk. ... Again, please.
You may be able to deal with this situation when buying a book online, but it's just unacceptable when you have 30+ paperwork packets per day to process. So even though you have your new web app, you're not using it, and the machine with the vulture on top is still humming away. Not only that, but your boss is breathing down your neck about it because he just paid another one of those astronomical hosting bills.
So here's what got me in front of the keyboard tonight: what exactly *are* the techniques that we should use when designing web applications that are intended to replace these old keyboard-based applications? How do we make sure you can still process 30+ paperwork packets? (Even better, how can we get that number up to 40+?)
To further generalize the question, what user interface and system design techniques can we bring to bear to enable high volume throughput on paper- and data-entry-intensive applications? I've started a short list below, but I really would like to hear other ideas and experiences from other people. Please post them as comments to this post.
Some techniques I can think of (in no particular order):
- Maximizing the amount of data that can be entered between trips to the server.
- Lean, fast web-side code that serves up light, text-based pages.
- Minimization of layers on the server side (see above). Maximization of marshaling efficiency between layers.
- Asynchronous processing on the server whenever a request from the client would take a long time to process.
- Use of client-side code (e.g. JavaScript) to push as much business logic out to the client and limit round trips to the server as much as possible.
- Web server caching where it makes sense to ensure that pages are generated fast.
- Get the tab order right for keyboard-based navigation from field to field.
- Take advantage of keyboard shortcut ("accelerator key") functionality made available by browsers.
- Make efficient use of screen real estate.
Somehow that list seems inadequate. Help me out here.
It also occurs to me that we should test our own web applications of this sort without the use of a mouse.
Another question that comes to mind: should we really be designing these kinds of applications in a web browser at all?
I welcome your thoughts. Thanks for reading.
Dan
RSS Feed [1] • Dan's Feed Subscriptions [2]
[3]