User Interface Design: Defacto Standards and Unicorns
Q: How many software engineers does it take to change a light-bulb?
A: None. They just change the standard to darkness.
It's easy to change the standards. That's because few companies actually have any kind of documented standards in any area, least of all around the user interface. Paradoxically, this area where you will find the least definition in standards is the highest profile. It's where the user meets the machine, what the software looks like, how it behaves at the most quintessential level. Yet we tend to let it grow wild, like a patch of weeds. A lot of companies are searching for that perfect face lift — some sleek new graphical interface that is going to bring a smoothly polished, consistent, and professional feel to their software. But we expect it to happen organically. Plant the new interface, add water, and we will find ourselves in a neatly ordered world filled with de facto standards and, just as likely, populated with lovely white unicorns!
De facto standards — isn't that an oxymoron? What do we mean when we talk about standards? Sometimes we use the word standard to talk about a bare minimum. An item is "standard" as opposed to "premium" or "upgraded". Sometimes it is an inclusion word — this car comes "standard" with cruise control and tinted windows. Standards are often associated with regulations imposed by some governing body. That will usually happen when there are safety issues or potential for fraud. There isn't much of a safety issue in the user interface of a typical business application. You can't even get a paper cut from a bad user interface! What we are probably looking for in user interface standards is uniformity — "User Interface uniformity." And yet, understandably we are motivated to avoid the sameness with other applications. We want our software to have our creative signature. Plus, the reality is that most companies have a conglomeration of different purchased and home-grown applications along with those that have been acquired via company mergers and acquisitions along the way. If you could document hard and fast rules about how the software should look — even if the target weren't constantly moving — how would you go about getting all of the different programs to comply with it?
We've been getting away with following the leaders and flowing with the current. In reality, that natural flow of currents doesn't wind through green hillsides of frolicking unicorns. Rather, we find ourselves in eddies and brackish backwaters. As lovely as our vision of organically grown graphics may be, it is probably better to have a plan. But like any of the other things that we know we could improve, taking time out to develop and document standards takes precious time away from actually developing the applications and using them in business. This is compounded by the frustration of documenting standards just in time for them to be made obsolete by some flashy new front end.
This is where the latest generation of graphical user interfaces is going to take us to the next level. What the software does and how it does it can increasingly be separated from how it looks (fig. 1). A different look and feel can be dropped over an existing application without affecting the nature of the application itself. A decade or so ago when the term "business rules" sprang into use it was meant to convey the separation between what the software did and how the software looked. Now we are moving to the next layer with this new term "lookless controls." We can define not only the business rules, but the interface rules. The "controls." Maybe they are "logic controls." The actual interface can be slid over those like a slipcover. This idea of lookless controls is going to be the game-changer for user interfaces. We can create a corporate skin that we put over purchased and homegrown applications alike. We can even give users choices for their own skins, and — here's the important part — building a design standard at that middle layer will enable us to adapt to upcoming interfaces, like mobile phones and, well, golf bags, vending machines, and coffee makers. We form a layer of standardization that comes between what our application does and how it communicates with the human.
Fig. 1
If we harken back we can remember when the global acceptance of open standards for communications between computers revolutionized the way we work and play. Take e-mail for example. In the early days, e-mail was only available between similar servers and applications. So one could only e-mail to and from the same application over a specific communication protocol. As soon as communication standards were published and adopted, suddenly anyone could connect to anyone — regardless of what was sending the message and what was receiving it. E-mail, EDI, XML, SOA (service oriented architecture). The list goes on and on, all dealing with computer-to-computer interfaces. Computer-user interface standards have lagged behind. So it is this latest abstraction layer — this ability to separate the most superficial components of look/style from the user interface — that will enable us to develop meaningful standards for that interaction. Standards that will allow us to move more quickly rather than holding us back.
It is still a lot of work. Even trying to work out what you need to work out is a workout. But you may be convinced that the time has come. If you go out looking for guidance on UI standards, be prepared to read a lot of opinions and find very little consensus. Still, there is excellent food for thought out there. Blogs where people have taken the time to document their own experiences — successes and failures — can save you some time. There are books that offer guidance from every angle — psychological, artistic, functional, and statistical. The wiki on Eclipse user interface standards offers some excellent high level guidelines. How can you go wrong following the advice offered in figure 2?
Guideline 1.1 Follow and apply good user interface design principles: user in control, directness, consistency, forgiveness, feedback, aesthetics, and simplicity.
Fig. 2 Guidelines from Eclipsepedia
The best exercise may be to start with your current application — green screen or whatever it is — and think about developing standards with two interfaces in mind. In addition to the general guidelines mentioned on Eclipsepedia, here are a few things to keep in mind as you get started.
- Make the standards simple, practical and implementable.
- Make it easy for a developer to find the particular standard or guidance that he or she needs.
- Make each standard/definition an entity that can be mapped across multiple UI's.
- Make sure it is intuitive. If you aren't sure, borrow someone's seven year old and see if they can figure it out.
As in all insurmountable tasks, it will help to break it down. Four main components to start with are: Navigation, Forms, Reports, and Documentation. They cross-apply to one another, too, but you have to start somewhere. Error messages and help messages fall under documentation in this broad categorization. Some people might argue that they deserve their own category and should be addressed first!
Navigation — How do you get into the application and then move around within it? Switchboards, drop down menus, command buttons on forms? Do you make one choice at a time or are many options presented at once? How does that translate to the application running on the green screen? How about on your phone or mobile device?
Forms — How are the forms laid out? How is navigation handled within the form? Borders, fonts, and colors might be something that you later allow to be changed as a skin. In fact, it may be a good idea to decide in advance which aspects you do plan to be skin-changeable. Think about the "hardware." How are forms shaped? Aligned? Do you use interior boxes? White space? On small devices you may want to get away from people entering an answer and rather to let them choose one of several choices. How will those choices be presented?
Reports — First decide what qualifies as a report. Are reports even necessary anymore? Is a dashboard or graphical representation going to be the output of choice instead? To keep from junking everything up with a lot of different things, some early decisions should be made about when each form of "informational output" would be best used. Guidelines about context or the type of information and in what format it should be presented. Then get into the standards about how each will look, including traditional reports.
Documentation — Let's face it, in the new age of user interface, people are not going to spend much time with their face in a book. We want the answer to the question we are facing right now . We want it quickly, and we don't want to have to move very far. So documentation almost disappears. In its place well designed help and error messages will be the wave of the future. To be successful, these must convey a lot of information in a small amount of space with few words. Establishing some standards for how that will be accomplished is arguably the most important aspect of designing a modern user interface.
Oh — and don't forget to add the unicorns.
