By ultan o'broin on Dec 22, 2010
I'm always on the lookout for how different apps handle errors and what kind of error messages they show (I probably need to get out more). I use this 'research' to reflect on our own application error message patterns and guidelines and how we might make things better for users in future. Users are influenced by all sorts of things, but their everyday experiences of technology, and especially what they encounter on the internet in their own, increasingly sets their expectations for enterprise applications.
I recently came across a couple of examples from Google's Chrome web browser that got me thinking. In the first case, we have a Chrome error message about not being able to find a web page. I like how simple, straightforward messaging language is used along with the optional ability to explore things a bit further--for those users who want to.
The 'more information' option shows the error encountered by the browser (or 'original' error) itself in technical terms, along with an error number. Contrasting the two messages about essentially the same problem reveals what's useful to users and what's not. Everyone can use the first message, but the technical version of the message can be explicitly disclosed by the more advanced user to pursue the problem further. More technical users might search for a resolution, using that "Error 324" number, but I imagine most users who see the message will simply try again later or recheck their URL. Seems reasonable that such an approach be adopted in the enterprise space too, right?
Maybe. Generally, end users don't go searching for solutions based on those error numbers, and help desk folks generally prefer they don't do so. That's because of the more critical nature of enterprise data or the fact that end users may not have the necessary privileges to make any fixes anyway. What might be more useful here instead is a link to a trusted source of additional help provided by the help desk or reputable community. This takes me on to the second case, this time more closely related to the language used in messaging situations.
Here, I first noticed by the using of the (s) approach to convey the possibility of there being one or more pages at the heart of the problem. This approach is a no-no in Oracle style terms (the plural would be used) and it can create translation issues (although it is not a show-stopper). I think Google could have gone with the plural too. However, of more interest is the use of the verb "kill", used both in the message text and the action button label.
For many writers, words like "kill" and "abort" are to be avoided as they can give offense, or so I'm told. I am not so sure about that judgment, as really the use of these words cannot be separated from the context. Certainly, for more technical users, such words are fine and have been in use for years, so I see no reason to avoid using them if the audience has already accepted them. Most end users too, I think would find the idea of "kill" usable and may even use the term in every day speech.
Others might disagree--Apple uses a concept of Force Quit, for example. Ultimately, the only way to really know how to proceed is to research these matter by asking users of differing roles and expertise to perform some tasks, encounter messaging experiences like the two here, record the findings, analyze them and then make recommendations for our designs. Something to do in 2011!