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.

Firstly sorry if I have been messing up your RSS feed, I had a few issues with wordpress, I promise to make better use of the draft option!

Previous Parts
Part 1

Here are the issues I generally have with message boxes.

All message boxes look the same.
But there suppose too! Yeah? Cosmic! That means every time any application tells me something I see the same thing I see the same thing. I know the text might be different, but I see the same thing.
Now if I’m rushed or stressed (maybe windows has crashed?) and suddenly my applications start popping up message boxes, I can’t easily judge which ones are important and which ones are just “helpful”, which leads me to”¦

Takes to much time to assess the problem.
Here’s an example, I work with an application that has a section where you can change some modelling parameters. After you change them it asks you if you want to confirm the changes via a message box (well yes of course I do, but”¦) you click yes, and you exit this section, returning to the part of the application you came from. At this point you are presented with another (ubiquitous) message box which now tells you that some settings have been change which may affect the results of the model (no way!!). Although both of these message boxes are really not necessary, that’s not the main problem. Because, you see, on occasion there is actually an important message, either the parameters are invalided (or cause an invalided result) or they were not accepted for some reason.

The problem is I don’t differentiate these message boxes from one another, so I just click it to get it out of the way, at best I continue with an invalid parameter at worst an invalid model!

I have become accustomed to the message boxes and I don’t notice the genuinely important one.

I need to know in an instant weather it’s important or not.

Does not tell me what I have done wrong or how to correct problem
Improvements have been made recently, but it’s important to provide the used with as much meaningful help as possible. This means suggestions of what was done wrong, where the error is exactly and how to correct it referring to a help file if a cop out, even more so when the help file in question has nothing to do with the actual problem!

Icons are not pertinent and do not provide context
Remember, I’m not a developer. I don’t know (or care) what the difference between an exclamation mark in a yellow triangle and a red circle with a cross in it is. Not to mention that there assignment is completely arbitrary between programs. Ask 5 devs to draw up a set of rules for the correct and appropriate use of the icons in message boxes and I’d wager you’d get a few differences and that’s before you even start to use them in warm blood.
Further, I want to know where the message is coming from. Often the application name is in the title bar, not always, but I might be working in application one, and get a message from application two. I don’t properly read the title and before I know where I am I’m excepting changes to something I don’t know anything about!

Too small.
It’s a fact of life. Small may be beautiful but big things stands out. If your small it’s easy to get ironed, lost even in a stack of windows, being big gives the message box a better chance of being noticed.

Text is unhelpful or meaningless.
This is a much bemoaned problem and is totally inexcusable. Any text should be clear and in very plain langue, no technobabble!

In the 3rd and final part I will make some suggestions that we can work towards to address these issues.

Comments welcome!

This will be the first of three posts I’ll make on “interacting with users”, or more specifically message and error boxes! Here’s the outline:

1. The current state of play
2. There’s a problem?… If it aint broke?
3. Suggestions for Improvements

So let’s get started then!

Windows 3.x

Windows 95

Windows NT

Windows XP

Windows Vista

For a while now I’ve had the feeling that message boxes, input boxes and error messages are just “broken”. Modern software such as Visual Studio has made some improvements in this type of messaging with extended descriptions of errors and suggestions for fixes but there are still short comings.

One of the problems a platform like Windows faces is that it has to support the design of all message box code from it’s APIs. Code that calls this API is limited to the original design of the API. Excel is an example of a programme that does this.

And so to the specific case of Excel. Right out of the box there are issues with the message box function, mainly its modal nature. This can be over come by using the Windows API directly yourself, as described here.

But this isn’t at the core of the broken-ness and we will take a look at these in my next post!