Kevin Cheng  


November 14th, 2003 by Kevin Cheng :: see related comic

>_”The nice thing about standards is that there are so many to choose from.” -_ __Andrew S. Tanenbaum, Computer Networks (2003)__

Andrew’s quote may be one of the most overused statements in modern IT. Why do cliche and stereotypes exist? Because they are mostly true. Similarly, Tanenbaum’s statement holds true in many areas. When it comes to user interfaces, we certainly like our standards.

Microsoft, of course, has an extensive set of guidelines for developing on the Windows platform. Not to be outdone, every other major operating system has their own including Mac?s Aqua, Unix?s KDE, Java, and the open source GNOME. Unlike last week, I won?t go into too much depth about each one and leave that instead as an exercise for you. The two more interesting guidelines of the group are GNOME and Java. GNOME is unique because it is an open source project and HCI’s role in open source projects is a topic that’s worthy of a week?s discussion in itself. Java is unique because unlike Windows or Aqua, it is designed to function across platforms, thus potentially directly conflicting with the platform guidelines.

Whilst searching for interface guidelines and standards, I came across an interesting new standard currently being developed for Automotive Multimedia Interfaces (AMI) by numerous automotive firms. Standards, of course, do not only apply to user interfaces on desktop screens. While I will discuss the usefulness of standards in the context of graphical user interfaces, the core concepts could certainly be transferred.

Are standards really that useful? Let?s study the commonly perceived advantages of standards. For the scope of this article, we will talk about platform standards. Later on, we might talk about building internal standards for custom applications or entire companies.

##Perceived Advantages of Standards

_Users can take advantage of learning effect:_ presumably, users will be able to take what they know from another application in Windows and apply them to other applications in Windows. Certainly, this is true to an extent. I know where to close a window, where to resize it, and generally speaking, I know what a save icon might look like. However, beyond these common functions, it there really any gain? For the most part, I would maintain that there is not. Applications are so varied in their core functionality that standardized paradigms may often be an exercise of fitting a square peg in a round hole.

_Developers will be able to maintain code more easily:_ probably true. Let me demonstrate the easiest standardized interface to maintain:


As user focussed professionals, we should not be optimizing for developer?s needs. Just because a piece of code is reusable for the developer does not mean it is usable for the new context. Users may change, the use scenario may change, and as a result, the control which the developer happily reused may be completely inappropriate.

_Developers know what things should look like:_ Here lies the biggest advantage of a standard. Ideally, we want to be involved whenever changes are made to the interface but this presence isn?t always possible. In particular, Microsoft or Apple cannot guarantee application developers will even utilize HCI. If a set of guidelines are made available, developers as well as third party vendors, can develop on these and at least minimize the risk.

_All the applications look the same:_ visual and branding consistency is definitely a desired effect for the platform developer. However, application developers should feel no obligation (unless contractually bound) to create applications that comply. Consider WinAmp, the popular MP3 player. Nullsoft recognized that the default controls for Windows were too large and would not be accepted by users. To remedy the problem, they created their own ?skin? and controls to match the skin.

##So Are Standards Useless?

Standards are definitely not useless. However, they stem from developers? need for maintainable and reusable code which is not necessarily in line with a usability professional’s priorities. Platforms provide a great foundation for building an application. Equally, platform guidelines designed by the platform vendor act as great interface foundations for an application.

As Tanenbaum’s quote implies, a variety of standards often creates an even larger problem than no standards at all. The automotive industry is taking the right approach by collaboratively developing their specifications in AMI-C. While a pipe dream like a single standard for all platforms would be nice, perhaps a more realistic approach is for platform vendors to provide looser guidelines in line with their role as a platform. As the ground from which applications build on top of, it is not necessary to spell the exact pixel measurements of controls or types of controls that must be used. Providing more flexibility not only invites the third party developers to do their own leg work and determine the right interface for their problem, but could also foster new designs and interfaces.

What are your experiences with UI standards and how do you think they should be applied?

11 Responses to “OKGo!”
Bob Salmon wrote:

I (slightly) disagree with the comment that the gain through the learning effect isn’t worth it.

Having had a switch from Outlook to Notes (v5.0 *shudder*) imposed on me at work, I have been exposed to a whole new world of pain. Even if the standards cover only a small set of things e.g. opening, closing, confirming, cancelling, moving, deleting and editting text that’s still a large slice of what you spend your time doing.

Also, even if you only have things shared between a small set of programs e.g. an Office-level standard, then if you use Office most of the time then it’s worth it. I wouldn’t mind if e.g. spectogram-generating software didn’t share application specific things with e.g. inventory management software, but inventory management and accounts ought to do common things in the same way.

I suppose this is suggesting a patchwork of overlaps, which is in theory less elegant etc. than a grand universal standard, but if I’m being pragmatic (cynical?) it’s more likely to work.

Shameless self-publicity:
(which includes an external link to a detailed and lengthy list of gripes about Notes, so you can share my pain).

Bob Salmon wrote:

Sorry to comment on my own comment, but I’ve thought of something else. I know it’s a continuum, and that every action should be easy to accomplish, but I think that there is still merit in having standards that cover just the low-level operations such as open, close, delete etc. These are like muscle movements in that they should require no conscious thought. The higher-level operations such as setting up the details of a new budget payment plan for your billing system will already require thought, the task is more complex and often structured in one of several arbitrary ways and so a lack of standards up at this level is less of a problem.

Just because a standard can’t encompass the high level things doesn’t stop it being useful.

Paul Reinheimer wrote:

Personally, I HATE it when programs dont decide to follow standard Windows design standards (this of course only applies to apps running under windows).

Lotus Notes R5 is currently the source of much irritation. Right clicking on a mail folder should bring up options like rename, delete, properties, etc. I get document properties (with a bunch of densly packed information I dont understand), two opens, a copy and a print. No rename, no delete.
To delete a folder i must Actions -> Folder Options (Not folder, that is something else) -> Delete Folder.
The folder option under Actions in fact only edits items within the folder.

This change has cost me several minuts when I have to do it, and having been on helpdesk, probably an hour in total explaining it to others. Add that up with the amount of time those users wasted before calling me, and you have a significant waste of time.

All that time could have been saved if the standard options were available under the right click menu.

Because of all of that, I found picking up Lotus Notes to be troublesome (and secretly, not worth my time), while Bloomba (email only package) ( was a breeze to lean and a joy to use. Because I already knew how to do most everything.

Kevin Cheng wrote:


I don’t think either of your points are in contradiction to what I was saying. My examples encompassed saving, window resizing, etc. I absolutely agree that at such basic operations should be consistent throughout.

You do bring up a good point about Outlook vs. Notes though. The question though is whether the problems come from a lack of standards or simply Notes’s absurdly poor UI. If you switched from Eudora to Outlook or vice versa, you’d certainly have some transition pains but nowhere near the scale of Notes. In my experiences with Notes (which are quite extensive so I share your pain), my preconceptions of e-mail clients consisted of elm or pine on Unix systems. That didn’t stop Notes from completely confounding me. So I’d argue that Notes just illustrates what bad UI is like rather than what good UI not following a standard is like.

Looking at Eudora and Outlook, there are still some differences. My hotkeys for checking new mail or forwarding an e-mail are different, for example. So ideally, I’d love Eudora to just use the same hotkeys and hey, why not the same icons as well? Well, that’s useful because I won’t have to learn anything new but then, when does the vendor innovate on the interface?

To be clear, I advocate standards for global operations but those who adhere strictly to the minute details of standards may have their priorities wrong. Winamp and other applications are presenting examples of using the standards to enhance, but not limit, their interfaces.

Gautam Ghosh wrote:

Having delivered UI standards and styleguides to umpteen clients, I’ve come to recognise the time saving aspect that many projects hope to achieve -and in some cases do acheive. By having made a set of design decisions for the developers, they can get on with developing instead of spending hours on discussions or research about how to organise user interfaces. Unfortunately, this time-reduction only works when the UI standards are good enough to support the developers (without all the convincing, but redundant, explanations) and when there is a consensus to actually adhere to the standards.
AS HCI professionals, it is up to us to provide guidelines that wil improve usability. But if the standards themselves aren’t usable, the alternatives are always just one click away….

KC wrote:


Excellent point - I absolutely agree. I want to talk about UI standards within a specific app in a little bit more detail later this week. Stay tuned. The article I initially wrote talks more about standards at a more global, or at least platform, level.

Paul Reinheimer wrote:

I think then we can agree to following the word of the law, rather than the letter of the law.

Read UI guidelines as just what they are, researched recomendations for how to make things easy and understandable for the end user.

The goal of UI guidelines (as I read them) is not to tell you that the border around a button must be 2px and 35%-47% darker than the surrounding colour. Or that scroll bars must be 7px wide with a slider whose height is determined by (page height / 100 * (visible screen - status bar height - frame overhead)). The goal is to tell me that buttons need to visually stand out from their surrounding, and that scroll bars should have sliders.

Those are definetly important points, and pretty much essential to UI design, so don’t ignore them. But be more concerned with the overall point than the nitty gritty details.

Jon wrote:

An anecdote about Lotus Notes: when I was interning at a company many years ago, we had weekly meetings which were announced via email; about a month and a half into the internship, two new people arrived at the weekly meeting. When asked where they had been for the previous month and a half, they explained that they had pressed the giant square mail button down in lotus notes for their email; they figured it would pop up when they had new mail. Since it never popped up, they assumed they had no mail.


Btw, Kevin & Tom, I’m talking about Klaus’s fiance-to-be ( ) :D

Bob Salmon wrote:

So far the discussion has been about standards for _graphical_ user interfaces. What about speech user interfaces? IVR (interactive voice response) systems can be just as bad as Notes R5. I don’t know of any standards, but there are useful conventions / guidelines, e.g.:
1. if giving a list of numbered options, do the words first and then the number. This way if the words don’t match your goal you don’t bother listening to the number. The other way round means you need to remember the number until the end of the words that follow it, just in case.
2. don’t nest your menus too deep. There is next to nothing to help you remember your point in grand scheme of things.
3. don’t make your menus too wide. Usually you only have 12 buttons on a phone, but who wants to listen to a list that long?

Plus the usual considerations of consistency, adapting to users e.g. beginner vs. expert, adequately fast response to help map action to consequence etc.

This assumes DTMF (dual tone multi frequency i.e. buttons) input; it becomes even more interesting if you do speech recognition + DTMF. Ideally you don’t force users to wait for the beep but allow them to talk over (interrupt) the prompt. (This requires clever echo cancellation so that the prompt doesn’t constantly interrupt itself due to reflections in the phone network.) If you don’t need the beep to signal “I’m listening now” do you still need it? I think yes, as it’s also a marker of “It’s your turn now”.

A tricky question I faced when designing a voice mail system was how to do the speech equivalent of greying out options on a screen. E.g. if you’re at the start of a list of messages the ‘previous message’ command is inappropriate. Do you miss out that bit of the prompt altogether, say it quietly, say it normally etc? Each has pros and cons.

KC wrote:


Your interpretations are quite reasonable and exactly what I’ve been trying to get across but I’m not convinced they are widely held.

1) “Read UI guidelines as just what they are, researched recomendations for how to make things easy and understandable for the end user.” We would need to assume they are researched WELL.

2) “The goal of UI guidelines (as I read them) is not to tell you that the border around a button must be 2px and 35%-47% darker than the surrounding colour.” I completely agree that should be the goal but it’s not the case. I refer you to MS Guidelines:

Paul Reinheimer wrote:

I think in many cases I am willing to surrender the point that major corporations have researched their usability guidelines (, I know from my history lessons that groups like Xerox Parc put a lot of time and effort into researching how to build usable UI. I think I remember stories in which people talked about how much money was spend deciding wether to light buttons from the top left or top right.

Looking at that MS document, it really looks like the type of thing that was developed for internal use, then published for the world at large. If that is the case, I completely agree with its existance, and its level of detail. Since their product line is based on inter-operability, and is often sold in packages, consistancy is mandatory (imagine buying the Office Suite and having the Font menus look different in Word than in Excell).

If I ever get back to C++ from webapps will I design my UI to follow those exact standards? No. I will certainly read up on it a bit, and follow the essence of the overall document, but I wont lose sleep if my buttons are 5px rather than 2DLUs apart.

Leave a Reply

OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?