how applications 'talk' to users, especially in messageboxes and other dialogs, sets the tone for an application and colours the user experience.
the first question is usually - who is 'talking' here? the computer, the program, or the developer? sometimes it's hard to tell. for example this message from itunes/windows: "itunes has detected that it is not the default player for audio files." itunes is referring to itself in the third person, as is the norm. this is one source of the confusion that dialogs can cause - generally users will attempt to determine the source of a popup by the text, rather than the subtle clues that distinguish operating system dialogs from application dialogs, and windows would refer to itunes in more or less exactly the same way that itunes refers to itself. no wonder it causes confusion: but none of the other choices are appealing, either: using the first person - "i've got a problem", or avoiding that by using a passive sense of self - "a problem has occurred" - both fail to identify the program at all, unless visual branding is used, which is often not practical (especially with low-profile applications). remembering that to users it's their computer that is trying to communicate with them (rather than a program or programmer) helps to get the tone right.
many of the factors influencing text choices tend to encourage terseness - the desire for a simple interface, allowing that localization can make text longer, or there's never quite enough space allocated by the designer on the dialog to put as much text as you might want. this can lead to a situation where any words deemed as superfluous are excised in order to achieve a clipped quasi-military precision: applications which are overly terse run the risk of appearing to be issuing orders to the user, but excess verbiage must also be a avoided: "experienced ui designers literally try to minimize the number of words
on dialogs to increase the chances that they will get read." -- spolsky
microsoft's vista ui guidelines are comprehensive (if not yet complete) and i was interested to see they have put much thought about this basic but crucial part of human-computer interaction and done a whole article on text and tone and using the vista tone is rule 9 in the top rules for vista applications (where it is defined as "clear, natural, concise, and not overly formal".) these guidelines are primarily intended for consumer applications, but they apply equally to corporate environments where applications often get away with terse, incomprehensible and sometimes outright rude messages because users don't have a choice whether to use them or not. programs should at the very least be polite and respectful and try to be helpful, and treat users as intelligent beings who might appreciate a little assistance with a task or decision.
of course, it's equally important to decide what messages should be presented and how: messageboxes are hopelessly intrusive, and neither vista's task dialogs or mac os's sheets really solve any of the problems, as they are still modal, still covering your application's user interface (possible even covering the source of or reason for the message), and still much too easy to simply disregard without reading. if a data entry application presents a messagebox that says "your changes have been saved" every time the user saves some data, are they really expected to process it every time? i wait hovering over the enter key, ready to tap it as soon as the dialog appears: and if the save goes arse-over-tip and i'm unexpectedly presented with a failure dialog instead, then i'll probably press enter when that pops up, and i've made an unknown decision. oops: hope the default action was well chosen.
one common use case of messageboxes is when a problem or 'situation' has occurred and the user has to make a 'decision'. while this may be valid, if a mesage is really important it's worth considering an alternative approach by using your application's own ui to describe the situation and to elicit the user's choice. a common mistake is to assume that modality simply means being always-on-top, but it doesn't: modality means that the application has different modes, where the same actions have different results. this definition of a modal dialog box reconciles the two, as "a modal dialog box puts the user in the state or 'mode' of being able to work only inside the dialog box." when a modal dialog is open (notably system dialogs like opening or saving a file, or showing a messagebox) the application in a new mode where it's normal functionality is unavailable: there might be different key bindings, no access to the application's inbuilt help (though that can be accessed from a messagebox in vfp9 using the new bindevent functionality) or any application tools. when notifications are handled within the application interface, there is no incentive for the user to immediately dismiss the dialog in order to return to normal application mode, as they have never left it. it's not always practical (or desirable) to do this, but it's worth working to minimise messagebox usage to improve application flow and usability.
there's a list of the top violations of the vista ui guidelines, which includes many real examples from the current version of windows. the daily wtf have some amusing collections of terrible dialogs; although they haven't been updated for a long time the user interface hall of shame (and hall of fame) are very instructive. i'm also looking forward also to content appearing in the error message section of the vista guidelines.