There’s a little tempest brewing in the teapot containing the cream of various developer communities. Joel Spolsky of Joel on Development is an immensely respected developer with whom I agree practically all of the time and think that the bulk of his blog should be required reading for anyone who is/plans to/works with/manages developers.
But his latest article concerning when and under what conditions you should disable menu items has been taken up by the UI Nazis of the Mac development community (and I mean that as a compliment). These are the people that are pushing forward the expectations of what a good UI should be and have produced some of the reference works in consumer Mac software.
Some responses from Daniel Jalkut, Lukas Mathias, John Gruber…
And I agree with them. But I also agree with Joel (at least a little bit).
I think that the biggest issue here is the difference in market target and the type of applications each spends most of their time working on. Some of this has to do with the culture of both the developers and the user audience.
Red Sweater Software, et al all produce consumer level applications where people buy an application with a clearly targeted use and a relatively constrained set of use cases. Joel is coming more from the Windows enterprise application development end of things where your application probably tried to do everything imaginable and you’re (shudder) developing from a spec written by an analyst who interviewed users and managers and wrote down every single wished for feature imaginable.
The key here is complexity and the number of potential contexts that you have to deal with. A well designed single-purpose consumer application has a limited number of contexts. A enterprise application can have many many more (although, I would argue that in many cases, it doesn’t need them).
Generally speaking the approach of the average developer is to look at a use case and go one of two routes :
-
Funnel the user into a brutally limited wizard style interface with no margin for stepping outside the boundaries
-
Present as much as information as you can display on the screen and hope that the user can decipher the context
Joel is not your average developer and is trying to put forward some best practices, but has fallen into the “more is always better” trap. He posits that the error message is your best way of communicating with the user and there I disagree.
The wizard approach is great for very well defined use cases where the process and inputs are written in stone. But it’s often used in inappropriate instances. How many call centers can’t log tickets because the caller is missing one piece of data defined as mandatory by the wizard. It’s not a user education issue since the user (call taker) is stuck on a screen that’s asking for home phone number and the caller is in the process of moving and doesn’t have one, or no longer uses a land line. There, the context is clear, the inability to move ahead is unambiguous, even if potentially badly designed.
On the other end of the spectrum, with a rich client interface, this is where I think that Joel is closer to being on the right track, but with the wrong solution. He posits that the user is unable to determine the context that is toggling the enabled/disabled state of the menu item. I think what we’re looking at here is a failure of imagination on the UI front.
If the user is using the application to produce the TPS Reports and the monthly report requires some piece of data, then the place where this data is supposed to go should be visually highlighted in some way. Ideally there should be a visual highlight over the field that gives the user the hint that once they fill in this field, they’ll be able to run the report or launch the desired operation.
I tend to push for the use of visual cues in the workflow to assist people. Some examples have been to show each screen where data entry is possible with each mandatory field background filled in red, and the color goes away as soon as acceptable data has been entered. My menu items for the next available steps are not available as long as there’s red field on the screen. (well actually I tend to use a very pale red, more of a pink). The best designed applications don’t assault your eyes in order to communicate with you. You shouldn’t need to - we have a well developed visual function that is able to pick up subtle cues. It doesn’t take much and if you promote a coherent graphic language in the application, what was learned using module 1 should apply equally well in module X.
For more complex applications, I tend towards the use of some kind of dashboard floating window that visually represents the available tasks and their current state. A red green yellow indicator next to a task button that is disabled until the necessary prerequisites have been met. You get a tooltip of the missing pieces by hovering over the color indicator and hopefully clicking there will take you directly to the missing or offending data item. If your applications live in a procedural world, why not display a floating image of the workflow chart, with the current state of the object in the flow ? Filled in blocks have been completed, yellow indicates waiting on data and red for error state. You’ve probably spent a whole lot of time modeling this stuff, why not expose it to the user so that they might have a chance of understanding the relationship of the work they do with the rest of the company?
I think that this is a fundamental aspect of good application design. Done correctly the user should be able to intuit the current state and context of the application based on what they see. One of the things they see is the state of menu items, which should be used to educate the user on the current state of the application.
If your use cases are so complex that the user can’t visually ascertain where they are in a given process, it’s time to go back and revisit the use case since you’re developing an application that is destined to disappoint and frustrate the users.
Personally, I find it exceedingly frustrating to select a menu item only to be told that I can’t use it. That’s punishment, the equivalent of “bad user, you don’t know what you’re doing”.