In this the final of my posts around messaging I’ll suggest some ideas that work towards a better experience for users and thus better functioning software. Of course this will not be exhaustive and I encourage others to shear their thoughts, ideas and experiences.

Previous Parts
Part 1
Part 2

Why bother!?!
It’s a fact that handling things well when they go wrong is critical in customer satisfaction and retention. We all know the frustration of crappy error messages and how angry it makes us feel. So we should ensure our users don’t have to go though the same pain.

If you’re working on a serious piece of work why not take the extra time to properly handle messaging? OK, if I’m knocking out a quick and dirty maybe I don’t want the hassle of getting my hands dirty. If however you’re working on a serious project it could make a big difference in how your application is used and viewed.

Use a custom form?
Rather than sticking with bog standard “msgbox”, why not use a userform? You can tailor this to suit your applications messaging needs and over come some of the short falls of standard approaches. You can:

> Make the form bigger
> Customise it to fit in with your applications/tool look and feel
> Make text bigger and clearer
> Use colour
> Use varied and meaning full images
> Make use of controls

It was my intention to publish a (production quality) userform that could be used as a replacement for the standard message and error boxes; unfortunately this has proven to be far more complex than I first thought! I will endeavour to complete this task as I feel it would be a genuinely useful tool.

Use directional messages.
With built in messaging you have to use OK, Cancel, Abort, Retry, Ignore, Yes or No. You have to contort your messages to fit around these generic options. For example,

Might be better presented like this:

And what if there are more than 3 options? With “msgbox” you’re into the business of popping up multiple dialogs! However be sure to avoid this type of thing from Lotus Notes:

So that will be 2 clicks every time I want to do something SO frustrating!

Undo rather than nag!
If I click the close button lets go right ahead and assume I want to close the window!
Rather than asking me for endless confirmations provide a way to undo the action. In their new OSX, “Leopard”, Apple have tried to do this in just about everything. From a VBA perspective it’s quite hard. Jan Karl and J-Walk have published methods for undoing VBA actions. The other popular idea is to save the file state just before the VBA code runs. You will have to pick the right one for the situation, need less to say there will be an overhead!

Provide context
One of the most important aspects missing from a lot of messaging is context. Context is about communicating “relativity” thus what the importance/effect of a choice maybe. For example

“Save Changes?”

vs

“2000 records have changed – Save Changes?”
And
“1 record has changed – Save Changes?”

You could add even more context to this, by say making the label back ground light up red for the 2000 case, this would elevate its relative importance level over the 1 record case, this type of idea might be useful in some cases, but actually counter productive in others, so you need to think hard. Ultimately it’s a judgment about adding value, does it make the thing easier/nicer to use?

Avoid pop up messages.
There may be a very good reason why you want to pass on some information to a user, some value is invalid, some settings will lead to a long run time and so on. But if you code for a popup to appear all the time it soon becomes annoying. Consider instead using “inline” information. Think about filling out forms on web pages. Generally warnings which appear are much less intrusive, and more helpful. There is also less of a disconnect for the user, the error message can appear right next to the place where the error has occurred.

What to say?
When you do have to message the user what should you say and how should you say it?
Well the first thing I would suggest is a big fat line which say what’s gone wrong. This needs to be short and sweet and to the point it needs to be clear and something that I can quickly understand and judge.

Then I think I would like to know what it is I have done wrong. So rather than:

“Could not find file”

say

“File [File Name] could not be found in folder [dir].

After that you need to tell me how I can fix this problem. So:
“Check the file is in the location targeted, check the extension is correct and that the file can be accessed, that it’s not copy protected and that the drive is accessible”

Ok so I’m sure you could come up with better suggestions, but you see the point.

Some good guides as to what to include in you error text can be found here and here.
The MS guide is here, but it’s not the best!

A note about the Task Dialog
Many of the issues I have highlighted and some of the suggestions I’ve made above have been implemented in the new Vista Task Dialog (good piece here). This goes some way to better messaging (“Task Dialog”, ?!), sadly it’s only available via an API in Vista (well, according to a VSJ article I read, so not in .Net 3?!)

So there you have it, not complete, in fact probably just the tip of the iceberg, but hopefully something to get you thinking.

Related posts:

1. HumanComputer interfaces. Problems with messaging- Part 1.
2. HumanComputer Interfaces. Problems with messaging – Part 2
3. Custom File Extensions