The Perils of a Decent Human Interface
By Jim Kent
Start Contributing editor
Reprinted without permission
from STart Magazine Volume 4 No 1 (August 1989)
My first commercial program, MicroIllustrator, was a paint system written in 6809 assembly language for the Tandy color computer. I was very pleased with myself when I managed to squeeze the flood fills, rectangles, circles, lines, text, brushes, patterns and other graphic elements into 3k of code in a months work. All done, I said to myself – except for the user interface.
The MicroIllustrator was not that much by today’s standards: no drop down menus or overlapping windows. But we did have a cursor following the mouse icons that would be highlighted when you clicked on them and a couple of different menu screens.
I was more than a little shocked when it took another 2 months of work and 6k of code to implement it.
Now I have a text editor that does block copies, a C compiler to figure out what to put in what register and hundreds of libraries of functions I’ve built up over the years. It’s not unusual to generate 3k of code a day. However one thing has remained constant: it always seems to take at least twice as long to build the interface as the rest of the program.
Pleasing All the People
Different people like to control their computers in different ways. Some people like the keyboard, some like to see their choices spelled out in drop down menus. Some people find drop downs too slow and would rather make a quick click somewhere on the screen and have something happen. So to keep everyone happy you need to have three ways to do everything.
Keyboard commands work best if they are easy to remember. Spelling out the keyboard equivalents next to their corresponding option on drop down menus certainly helps. It’s also good to make the key the same as the starting letter of the drop down command.
Sadly, nearly half the words in the English language start with S T R N or C. A Jack Powell, former Antic Software Product manager says “Thank god for Word Perfect’s Thesaurus !”. Unless a program is a word processor, it should not use the CONTROL, ALTERNATE or SHIFT keys as part of the keyboard commands; it’s hard to press ALT+P with one hand, and many people like to keep one hand on the mouse.
Drop down menus force you to spell out exactly what a command does in two words or less, and sometimes it’s very hard to come up with a meaningful name. My suggestion – at all costs avoid using words – get, put, push, pop and buffer. These words tend to mean more to a programmer than to someone who’s not, and also have different interpretations in computerese.
Selecting from a drop-down menu involves three steps :
Moving the mouse to the top of the screen.
Finding the drop down that contains the drop down you want.
Clicking the mouse over a rather narrow strip to select it.
If you can organize the drop-downs into logical groups and place the most commonly used items near the top or the bottom, the process goes faster.
The third component of a user interface is the panel menu – the area on the screen where a single mouse click tells the computer to do something.. I usually put these at the bottom of the screen out of respect for the Quantel Paintbox, a hardware/software combination used by production companies which has one of the nicest interfaces I’ve ever seen.
From the programming standpoint, panel menus are the most labor-intensive part of the user interface. I have a program that will generate drop-downs from a list of the text, but panel menus must be laid out by hand. Adding an extra feature at the last moment can force you to visually redesign the whole menu.
Panels offer the quickest selection, so you’d like to put as much as possible in them. But the bigger the panel is, the less room there is for text or picture the user would like to see. Remember the user has work to do. (Maybe MIDI programmers don’t have this problem). To save space lately I’ve been using both left and right mouse clicks over panel menus (e.g. left-click to select a color, right click to go to another menu)
Got to Admit it’s getting better
Object Orientated Programming Systems (OOPS) are much the rage these days, and there is a reason. The work with Smalltalk at Xerox PARC inspired GEM, the Macintosh display, Sun Windows and a host of other windowing systems. Lately I’ve had a chance to play with Smalltalk a bit, and I like its windowing system better than any of these offspring’s.
One idea Smalltalk uses that hasn’t made it into the mainstream yet is to start a program in the same place you left it. In other words, instead if having to remember what you called a file, hunt for the place you were working on, reset your tabs, choose the correct font etc., you simply run your text editor and you’re in the same place you were when you last quit the program.
Remember the Basics.
The two most important aspects of a friendly user interface are so obvious that they are overlooked in theoretical discussions. A program must not crash, and must be fast enough to keep up wit the user. There’s just no substitute for machine coding speed critical program sections and then letting a hundred beta testers put a program through it’s paces.
If your design is too complex or your program is too ambitious, you’ll find it’s nearly impossible to make your code fast and reliable. Keep it simple. Don’t try to include every feature your product manager and early users suggest, or even the ones you dream up yourself. It’s better to do a few things very well. After all, you can always write another program once this one is bulletproof and in shrink-wrap.
Jim Kent is a professional graphics programmer living in San Francisco. He wrote his first commercial programs, the MicroIllustrator for the Coco and Aegis Animator for the Amiga while employed at Island Graphics. Since then, Jim has started his own company and written Aegis Animator and Cyber Paint for the Atari ST and Zoetrope for the Amiga. He’s also had numerous programs published in Start, including Flicker (Summer 1987), the Audio Visual Sequencer (November 1988) and the computer animation programming language Pogo in this issue.