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! 🙂