I'm always on the lookout for how different apps handle errors and what kind of messages are shown (I probably need to get out more), I use this 'research' to reflect on our own application error messages patterns and guidelines and how we might make things better for our 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, increasingly sets their expectations for the enterprise user experience too.

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 about not being able to find a web page. I like how simple, straightforward messaging language is used along with an 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) 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 has to be explicitly disclosed for any more advanced user to pursue further.

More technical users might search for a resolution, using that Error 324 number, but I imagine most users who see the message will try again later or check their URL again. 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 is a link to a trusted source of additional help provided by the help desk or reputable community instead.

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 possibilities 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 (though 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", shown in the message text and as an action button label.

For many writers, words like "kill" and "abort" are to be avoided as they can give offense. I am not so sure about that judgment, as really their use cannot be separated from the context. Certainly, for more technical users, they're fine and have been in use for years, so I see no reason to avoid these terms if the audience has 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 these messages and then make recommendations based on those findings for our designs.

Something to do in 2011!