I think MessageBox should be added to the list of banned API’s in Windows. I think it is overused and presents an easy but lazy way for a developer to ask questions that the user shouldn’t have to care about. People never read the text that is presented on them, and as a result the wrong things often happen.
As an example, consider the meeting I had with a CPA today*. I brought along a spreadsheet on a USB stick that detailed some of my finances. While he had it open, he inadvertently made a change to the spreadsheet (not a big deal – it was just a copy). When our discussion and meeting was done, he closed the spreadsheet so that he could return my USB stick. So he clicked on File, and then Exit, and was immediately presented with:
Most of us are used to this dialog and usually know what our answer will be even before we’re asked. We would click “No.” But here’s the interesting thing that I heard him say out loud:
CPA: “Yes, I want to close it.”
And then he clicked on the “Yes” button. The dialog was asking him to save it, not confirm his intent to close it. But for some reason he assumed the dialog was asking him to confirm his intent instead of serve a warning. I hardly blame it on a lack of intelligence, but rather on the usability of Excel, et. al. and the terrible “Yes, No, Cancel” pattern that [almost] all developers seem to be stuck on reusing.
If a task dialog pattern had been used instead, he may have clicked on the button that corresponded with his actual intent, which would have been to click “No”. For Paint.NET v3.0, I instituted these all over Paint.NET in an effort to improve usability.
In this case, “Yes” is replaced by “Save” and “No” is replaced by “Don’t Save”. It is much clearer what will happen when you click on them – there is less left to be assumed, extrapolated, or guessed at by the user. In the “Yes, No, Cancel” dialog above, it is not really clear what happens when you click “No” or “Cancel” – for the former, the changes are discarded and the application exits. For the latter, the changes are left in memory and the application stays open.
These dialogs require more code, but only because there are 8 string resources and 5 graphic resources to load or prepare. The code itself is still quite clear and easy to read, and easy to duplicate. I have a class called TaskDialog with a static function that takes all the text and graphics and then prepares a WinForms dialog that is shown modally. The button that was pressed is then returned to the caller.
Anyway, this was an interesting real-life story and I thought it was worth sharing.
* Yes, this is a true story! 🙂
paint.net blog 
This reminds me of a Firefox plugin I once saw, that replaced any instance of OK/Yes/Confirm with “whatever”
My favourite feature (well, favourite may be going a bit far, but I think it’s cool at least) of EditPad is it’s error messages. When it has trouble reading a file (e.g. permissions, locking, etc) instead of saying:
Could not open file: access denied
[OK]
It says:
Could not open file: access denied
[Bummer]
The Paint.NET dialog is quite similar to Vista’s new TaskDialogs. What do you think about supporting them when running on Vista instead of you own ones? It would better match Vista’s look and feel resulting in a more consistent UI which is good for usability.
Read this http://www.uxmatters.com/MT/archives/000242.php. The solution is not in banning them at all.
“Do you want to save changes you made to ‘xyz.xls’?” should be changed to something like
“Save document?”
Of course, this case can be defaulted to answer “Yes” every time, but that’s not true about every instance where ‘Yes/No/Cancel’ boxes are used.
If you, as a solo developer with a (great) niche product, can figure this out and implement it, then Microsoft have no excuse. And they’re not the worst by any means.
The Save/Don’t Save/Cancel dialog may have taken a fair bit of extra time to get to be as good as it is (a man-day? a couple?) but in the wild it must be displayed somewhere every few seconds, and the time it saves by being clear must be colossal.
Repeating someone else’s wisdom: to the user, the UI is the application, and the message to developers should be “go and do likewise”. Or better, in they can, so we can learn from them.
Wow… Very nice. I’m working on my own MicroISV product and this is a great little feature to implement. Thanks for the idea.
Thank you for the list of banned APIs. I’ve been looking for it for a while since I read Michael Howard’s security article. I don’t know why Search didn’t came up with it.
MessageBox-style dialogs do have one-strength, though: consistent keyboard shortcuts (Y, N, ESC) instead of varying ones for task-based dialogs.
Yeah, this is a very usability problem and your solutions is great! I think I’ll implement the same solutions in my Windows Forms application. Thanks
Never mind the buttons, who’s the hot chick? Hubba hubba. Me likey.
Brian – Megan Fox, duh! 🙂