|
Good Article on explaining how we can improve
|
|
|
|
|
I'm constantly a victm of this habit!
|
|
|
|
|
.. adapt to situation but remain lazy...
I mean, looking at the second screenshot, I'm pretty sure users facing this dialog will quickly get used to it and type in "UNDERSTOOD" without reading the long text...
Which means the attention you wanted to get is only there for the 2 or 3 first times the dialog pops up...
So if you wanted to make sure the user knows he is going to do a Restore or a Backup a the database, you better ask him to type in "RESTORE" and "BACKUP" depending on the action to be performed..
|
|
|
|
|
One of the best solutions I've seen to this problem is to have 2 dialog boxes, each requiring a DIFFERENT answer.
First dialog says "Are you sure you want to purge the database?", options Yes or No, selecting Yes CONTINUES.
Next dialog "This will delete all logically deleted data. Do you want to cancel?", options Yes or No. selection Yes will STOP the operation.
Yes, users seem to hate 2 dialogs, but then they'll also complain about any solution where they have to use their brain, but not as much as if they lose their data....
:rolleyes:'For every complex problem, there is a simple answer, and it's wrong.'
|
|
|
|
|
Maybe, you're right, but I think everyone remember the DOS command "Format c:", isnt'it? Well, that command, before to be executed, requires twice to be answered "Y". Great, but I have a friend of mine, a colleague, that in the past has been able to format his PC, instead of a floppy not once, but evenly 4 times in only 1 year!!! I'm not a ancient developer, but also during my normal working days, I have to fight against user that comes to me and says "French the application raised an error" and the answer is "Which was the message?"... Answer by the user: "I dont'know. I closed that window...I never read messages on the screen.". So, I decided, from now on to save somewhere (Db or Flag file) the error messages...
ad majora
the CreF
|
|
|
|
|
I think button order plays a role as well.
I'm use to dialogs with OK nearly allways at the topmost or leftmost.
If you change this order you can affect a defualt even for mouse users. They will hit the topmost or leftmost if in a hurry or not interested. MS Flight Sim 2002 has dialogs that have the OK on the right, which catches me out all the time.
Nigel Atkinson
|
|
|
|
|
How true.
Still, it only helps application users who won't read button labels.
Sure, dismissing a "redundant" dialogbox should at leadt be done on the rightmost
or topmost button. (actually, if it's redundant, why keep it?)
On the other hand, if I wanted to communicate with the application user, have
him - her read my text, then I am in trouble.
|
|
|
|
|
In addition to words (as few as possible, and directly relating to the event), use animation! Some Windows messages already use it. For example, when copying a file, you'd see a sheet of paper flying through the air to an opened folder, or when deleting a file, you'd see the sheet of paper disappear with a little bang at the other end of its journey.
For something that would cause severe damage and destruction, show something like a stick of dynamite that would explode (as part of the animation message), in addition to the words of warning or advice. For something more benign (like only requiring the "OK" button to be pressed), show a finger pressing the "Enter" button.
The point is, you don't need to have your messages become vanilla to your users after a while, because even if they don't take the time to read what the message contains, you will have caught their attention by the animation (or at least by the animation picture) that will immediately communicate to them the KIND of message they are seeing. In a way, the picture becomes the message!
William
Fortes in fide et opere!
|
|
|
|
|
Never has an article title disappointed me so much.
I was hoping this was going to be a Pocket PC version of the old Star Trek game.
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
I second that comment.
|
|
|
|
|
I third
I was actually loooking for a battleship game article
|
|
|
|
|
I wish I will not need to type in text confirmation ...
"C'ptain How do you spell "LOAD THE TORPEDO" " ?
I think it all depends on the level of "danger" that the operation will be.
Having clear, descriptive labels ( for the buttons and the message ) is enough for 90% of the time; as well as having the different warning logos.
Having a text confirmation is overkill for everyday confirmation, but for a really destructive operation that happens once every year, it can be acceptable. but on a daily frequency, I'm not sure.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
I agree that it is overkill for a simple "daily backup" operation.
I have used this pattern as-is, however, for a special function that allows one to "reinstall" the database from scratch.
This application option allows one to experiment with my application and get a good feel, trying all kinds of silly things, then dismiss it by restoring the application to a freshly installed state. It is faster and more friendly than actually uninstalling - deinstalling, but could be very dangerous if used by mistake. This is why I have used this design pattern.
For backups, I forsee that before the end of the week, I will come up with something from the suggestions from many of the messages I got in response form this article.
- Having small text with boldface emphasis
- Having "unstandard" button labels. (for MessageBox(), that is), with clear text, instead of "OK" "CANCEL".
- Having an icon with a pictogram or animation showing the user what's going on. (Still, It must be absolutely georgious. I don't think I can draw that, or even explain our resident c/g. expert on what should be drawn.)
- Changing the innerworking of my program to make it absolutely difficult to do something silly, like overwriting client A backup with client B data.
- Maybe I can "cheat" a little and keep a "hidden" backup that will be used to preserve what I had before. (So If my operator restores an obsolete backup on top of a good one, thinking he is backing up, a special "hidden" recovery procedure could be invoked. I don't know if I should eat hard disk space like that. A backup can easyly take 5 megabytes or 50, from what I have seen. Hmmm. I only have 40 gig right here, at home...?
|
|
|
|
|
Have a look at Interface Hall of Shame and scroll down to AK-Mail .
The better choice would be to present the Backup and Restore options in a visually distinct way. In particular, popup a warning dialog when doing a Restore, which says /!\ You are about to overwrite your current database with the backup created on dd-mm-yyyy. [Continue] [Cancel]
Anyone who expects a restore will be surprised by this dialog, and therefore take time to read it. This is because it differs from the normal, low-noise workflow. This is good GUI style, unusual events like Restore should require more user input than common tasks like backups.
|
|
|
|
|
Note: The actual dialog box sample shown in the article did not end up in my application.
My original problem was that the backup for client A over-wrote the backup for client B.
Using SQL server, I can't just provide a convenient path to the destination backup file. It works in a more indirect way. I must first create a "dump device", giving it a logical name.
Example:
run adddump_device name "main_file"device "C:\Backup\MainFile.bak"
run adddump_device name "history"device "C:\Backup\LogFile.bak"
Then the user selects "main_file" or "history" in the screen and press the "BACKUP" or "RESTORE".
I still have not found a perfect solution, but one is coming. Part of the original problem is that whatever directory is selected, the filenames (one for history and one for the main file) end up being the same. So, saving two distinct clients backup in the root of a single USB PEN type of disk gives me these problems.
A suggested solution (by my boss) is to encode the "logicalname" for the backup into the filename. But this is beside the point.
The goal of this article is to present to this community the fact that very often, message boxes will not be read. I offer one solution (forcing the user to read the text) as an example only.
I hope to see some comments that will help me reduce the possibility of errors and perhaps improove the end user's experience.
Note: I like your suggestion for a shorter text with some boldface in it. Too bas it's not supported by ordinary messageboxes. Maybe I can simulate this using rich edit control or some other interesting RTF formatting control seen somewhere in code project
|
|
|
|
|
Congratulations to your boss on overcoming his intellectual limitations to achieve guru status.
If you can't figure out that one backup is about to slam another (created by someone else?) or that a restore is going to blow away changes (more recent modified dates), you need to: Stop; Go for a walk; Get some coffee; Read the newspaper; And, chat with some friends. Then, sit down with a piece of paper and figure out what the f**k you're doing wrong.
Blaming the users is never the right answer.
|
|
|
|
|
Bamaco2 wrote:
the fact that very often, message boxes will not be read.
This is because all too often message boxes state the obvious, ask you dumb questions or a question I answered the same way 1000 times.
I particularly like the one in VC when I hit the button to debug and it states the executable does not exist would you like to rebuild it. I would like to answer NO do not rebuild it but I still want to debug so go ahead and generate a working executable that solves my problem so I can test it. And while you are at it I would like to add these features... I guess others would be upset if it rebuilt the executable automatically so I do see a need for it. Maybe they should have a never ask this again box.
Bamaco2 wrote:
Maybe I can simulate this using rich edit control or some other interesting RTF formatting control seen somewhere in code project
http://www.codeproject.com/dialog/tcxmsgbox.asp[^]
John
|
|
|
|
|
msalters wrote:
Have a look at Interface Hall of Shame
I agree I really hate these types of dialogs and I believe they should be avoided for the most part.
John
|
|
|
|
|
The problem is often not that the text in the message box is too long, but rather that the labels on the buttons are unclear.
In your example the message box contains "Save changes to Text1", but what the user sees is "bla bla bla". Then he presses the Yes button because that is in most cases the most obvious choice.
Instead of using Yes, No and Cancel, try to use more descriptive button labels, like: Save, Discard, Cancel. Now the user doesn't have to read the whole message box anymore, only the buttons.
One of the best (or worst) examples of non-descriptive button labels is shown in Excel, when you open a very old .XLS file and then try to save it. The text describes the meaning of the buttons somewhat like this:
- Press Yes if you want to save the file in the new XLS format
- Press No if you want to save the file in the old XLS format
- Press Cancel if you don't want to save
In this case it would be better to use the following buttons:
- Save as Excel 2000 file
- Save as Excel 4 file
- Cancel
If you program in C++, you get similar dialogs if you use asserts:
- Press Abort to stop the application
- Press Retry to go to the debugger (why is this Retry??)
- Press Ignore to continue with the application
So, my solution: always use descriptive button labels.
Enjoy life, this is not a rehearsal !!!
|
|
|
|
|
The top messagebox, by the way, is from MSVC6++
I agree that careful labeling of buttons may help, still, lots
of times, the button will not be read. User will read "blah blah" and click the "don't bother me with this" (leftmost) button.
Still, out of respect for those who will care to read the labl, from now on, I shall spend some time to find the most adequate 1 word button label. (This rule would disqualify "Save as XXX file" labels, I am afraid)
Back to your example. Pretending I wrote Excel 2000 (and I didn'y, of course), I would put in a "save type" combo-box in the save-as dialog, the default selection would be "appropriate". (If I can safely save all feature found in the modified document using older, original format, I would, otherwise, I would use the newer format, unless overruled by the application user by selecting the older type in the combo box.
Ahh, this is a tough job, having a quasi infinite number of alternative and choosing what is best.
Still, my point for this article is that there is such thing as a Klingon Battle Cruiser attitude toward messageboxes, and that smart programmers should not dismiss those attitude out of hand simply because the application user refuses to read the message.
|
|
|
|
|
Patje wrote:
In this case it would be better to use the following buttons:
- Save as Excel 2000 file
- Save as Excel 4 file
- Cancel
I' convinced the user would read:
- Save bla bla bla
- Save bla bla bla
- Cancel
Regards
Thomas
Disclaimer: Because of heavy processing requirements, we are currently using some of your unused brain capacity for backup processing. Please ignore any hallucinations, voices or unusual dreams you may experience. Please avoid concentration-intensive tasks until further notice. Thank you.
|
|
|
|
|
Of course, you are right.
In my enthousiasm I moved the problem of the long text to the buttons.
Providing the possible formats as a separate combo box (with an appropriate default value) would be much better.
Enjoy life, this is not a rehearsal !!!
|
|
|
|
|
Or, maybe the solution is to leave the file in the original format unless the user has modified it in an incompatible way (e.g. added objects not backward compatible). Alas, most desktop applications use object serialization semantics that make this difficult or impossible.
Once again, it's the software's limitations not the users' actions that define the real problem.
|
|
|
|
|
Patje wrote:
The problem is often not that the text in the message box is too long, but rather that the labels on the buttons are unclear.
In your example the message box contains "Save changes to Text1", but what the user sees is "bla bla bla". Then he presses the Yes button because that is in most cases the most obvious choice.
Instead of using Yes, No and Cancel, try to use more descriptive button labels, like: Save, Discard, Cancel. Now the user doesn't have to read the whole message box anymore, only the buttons.
From my experience it is not the button or dialog text that annoys the user, it is the appearence of the dialog per se and thus the break in his workflow. What I found to be quite effective is:
1) set the least destructive option as default button - most users tend to "machine gun" the CR-key
2) if the user selects the option from 1) notify him about the effects of his choice (for example, cancellation)
3) another way I ran into a few weeks ago: force a short delay (e.g. 5 secs) before enabling all buttons that dismiss the dialog. This might tip the user into reading button labels etc.
Bye,
Martin Friedrich
|
|
|
|
|