HumanComputer Interfaces. Problems with messaging - Part 2

Posted on Tuesday 13 February 2007

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!


6 Comments for 'HumanComputer Interfaces. Problems with messaging - Part 2'

  1.  
    14 February 2007 | 11:14 pm
     

    All good. I’ve been trying lately to minimize the number of words in my message boxes. I read that people won’t read more than eight words. It’s harder than I thought it would be. How about the default (the click-without-reading option)? Should that be the most likely choice or the least destructive choice?

    Re RSS: It appears you’re only displaying partial posts in your RSS. I prefer full posts.

  2.  
    18 February 2007 | 12:01 pm
     

    Hi Dick,
    Yes, I agree. I would also say that on a number of occasions I find myself having to read the text about 4-5 times because by the time i get to the bottom i have forgotten what the first 2 points where.
    Joel Has some thoughts on this here:
    http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

    I think the important thing is to provide the key info clearly and quickly - that is be able to make an accurate judgment quickly, and to do this you need to provide context. Ideally you should then provide further information which can help the user.

    Default option - I would make it the most likely choice, it will for sure catch you out, but I think it would be the better way to go. Basically it’s a difficult choice.

    Cheers
    Ross

  3.  
    18 February 2007 | 12:02 pm
     

    Re RSS:
    Yeah I might change that - don’t what people rippping my content though (poor as it maybe)

  4.  
    18 February 2007 | 5:58 pm
     

    The content is good enough that I’ll keep reading whatever you decide to do. :)

  5.  
    19 February 2007 | 5:27 am
     

    Ross
    You know when you a delete file - do you ever change your mind because of the warning?
    I don’t, the very odd time I get it wrong I just restore from the recycle bin. I keep thinking to turn off the warning but I’m so conditioned to software asking me to confirm everything I do it seems wrong to turn it off. Imagine driving your car and it asking you to confirm everything.
    I’ve read software dev standards that say all dialogs should default to making no change ‘to protect the user from themselves’. how annoying would that be?
    I’d say the no damage one is the easiest to code, the most likely probably needs smarter code to work out what to choose.
    cheers
    Simon

  6.  
    ross
    19 February 2007 | 10:17 am
     

    Thanks Dick.

    Simon, your comments on deleting a file is an excellent example of one of the ideas I’m going to suggest in the last part - keep messages low(not so good in your example), and provid a way to undo the action, which the recycle bin does well.

Leave a comment

(required)

(required)


.

Use [VBA] Your Code [/VBA], when posting code, cheers Ross x /


RSS feed for comments on this post | TrackBack URI