At the same time, for localization a verb needs to be translated into XX languages. The default Yes/No/Cancel text is already translated. Of course that's not much of an argument since you'd have to translate the rest of your program too but is there something to be said for helping people not familiar with English to be able to use your untranslated program?
These kinds of things can be life or death in airplanes.
It used to be in the Air Force that full throttle was called "takeoff power". Then one day a jet was making a landing, and the copilot decided they needed to abort. The first thing you do on abort is go to full power, so he yelled "takeoff power". The pilot chopped the throttle, thinking he meant "take off power", causing an accident.
The offical phrase for full throttle was then changed to "full power" (or "maximum power", I forgot).
I don't think that's the case. It's very possible to be a good programmer and care deeply about your work, but at the same time be a terrible UX designer. Unfortunately a lot of software companies don't realize this and give UX the priority it deserves; instead they make their coders guess about it, which leads to things like this dialog.
Oh sure, I'm a living disaster area at UX. I meant more that whoever is the "designated responsible individual" (if one even exists -- doubtful) has given the fuck up.
For some reason I didn’t read “the fuck” as emphasis, but as a direct object—the person had had a fuck previously, but have since given up that fuck.
I’m going to use that as an example of why UX is hard: not only are people generally not paying attention, but sometimes they misfire even when they are.
or even that the message makes perfet sense to the person writing it, because they are not reading the message, but reading what they thought the message was in their head!
and he simply missed the unfortunate dialog box that resulted in one of those cases. An oversight, but when the subtitles of the user presentation is so decoupled from the code it can be easy to miss.
I actually prefer the idea of using "Don't" instead of "Cancel." When combined with always using a verb instead of "Yes" or "OK", I think it makes for completely unambiguous dialog.
Not completely unambiguous, though. I've seen plenty of software with negations in their dialog messages ("Don't delete x?") Particularly egregious with driver installations. Everything considered, buttons with actual verbs seem the most foolproof.
State of California used to allow 5 in healthcare reporting: male, female, indeterminate, unknown, and other.
The first two are largely self-explanatory, self-identification issues largely not considered. "Indeterminate" means that evidence is present but it's not possible to distinguish. "Unknown" means evidence isn't present (and hence it's not possible to make a determination. Example: unidentified human remains found and either grossly mutilated or partial to the point of not being able to determine sex. "Other" means that evidence is present, and it's possible to make a determination, but it doesn't fit any of the previous categories.
My absolute favorite on this one is a dialog that pops up if an assertion fails in a .NET program. It has three buttons whose names have a distinguished provenance: Abort, Retry, Ignore.
Those names don't exactly describe what the buttons do. Fortunately, though, someone at Microsoft noticed the problem and fixed it. So now the title bar reads, "Assertion Failed: Abort=Quit, Retry=Debug, Ignore=Continue"
If you have trouble convincing someone of this, I wrote a little helper application you can install on their computer. It pops up a focus-stealing "WARNING: Are you sure? [Ok] [Cancel]" dialog at random every 10-40 minutes, irrespective of what they are doing at that time. A day of that, and they should get the point. Executable and source download at the bottom of the rant: http://www.expert-overflow.com/areyousure/
I once held a meeting for higher-ups (I was rather a peon) to decide whether a single switch should be labeled "online/offline" or "remote/local". 6 managers attended. The meeting lasted 3 hours.
Small surprise that once $14B/yr company just sold its remaining patent portfolio for $500M.
Sounds kind of like the real issue was how the two modes should be communicated to the user throughout the product. Either the real issue was being ignored, or it was just the representational case for a valid UX question (although that process still sounds like overkill).
Abort would terminate the entire process, whereas Fail would return an error code to it. Older (pre-2.x?) versions of DOS did not support the concept of I/O error codes at all, so the Fail option wasn't present: instead, you had the charming 'Ignore', which would pretend the operation had succeeded, returning the I/O buffer with (partially) corrupted information.
One problem is that the standard Windows API for creating a MessageBox only has standard options for the button labels. If you to use custom text you have to create your own form.
This is due to localisation. Standard dialogues with limited and clearly defined text options can be automatically localised by the system, but if you put arbitrary text on your buttons and you want localisation, you have to provide translations yourself.
I had this same problem once upon a time, so I created a WPF clone of the standard Windows/.NET MessageBox which allows for custom strings for button text (OK, OK/Cancel, Yes/No, YesNoCancel).
My favourite was a disk backup program for MacOS (non-X) called Silverkeeper, which was included with LaCie external drives: http://i.imgur.com/VMlQH.jpg
Or in ASCII art (spelling and punctuation as shown):
+----------------------------------------------------+
| [ Nah! ] [ Somewhat ] |
| |
| Are you sure you want to permanently remove backup |
| of files in Set "Desktop > Sneech" |
| |
| Thsi will completely remove |
| any reference to these file.? |
+----------------------------------------------------+
A random idea, maybe an alternative is to label the buttons w/ the actions themselves, i.e. no message + Y/N,Ok/Cancel labels.
For Example, instead of:
Would you like to cancel this transaction?
{Yes,No}
just have:
{Continue Transaction|Stop Transaction}
Ah, yes indeed. I suppose yes/no scheme may be applicable to command line tools where the user actually has to type, in the model ui world, it's not really applicable.
Yes, the UI is the mechanism that pops up the messaging, but the UX is the consideration of how the message will be used or misused by the user.
Ha, a terrible sentence. That's why I'm a back-end not a UX person :)
It's definitely a blurry line a lot of the time but having worked with a UX guy who was part of our design department, he definitely added a lot of value to the design process.
I think UI is a subset of UX. UI design is the choice, arrangement, and labeling of widgets on screens, whereas UX design also includes more abstract decisions such as whether to require that the user sign up before they start using your website or whether to provide permalinks to individual pieces of content or only have a link for collections. In this case, choosing labels of buttons on dialogue boxes is related to the UI, so it’s both UI design and UX design.
I remember a site on MacOS vs Windows dialog boxes from way back in the late 90's, a time in which many confusing UI patterns abound. It's too bad it's still not around as it is a great guide on how to display the question to the user correctly.
It went on to display a few common(windows 95 I think) dialogs that would leave most users confused. Then showed the Mac dialog in similar operations where it was very clear what the intended outcome of each button would be.
If you ever stumble across it, I'd love to take a look at it. That sounds like a great resource.
I'm currently writing my first "big" GUI for work where I serve as both the main programmer and the UX designer. Things such as button ambiguity are things that, until this point, had never crossed my mind.
The problem is that too many dialogs are designed to require reading an overly verbose message when in reality the vast majority of the time the 2 or 3 words on an appropriately named button are all the context a user needs.
If I initiate a format on a drive volume I don't need a lecture on what a format does and what the risks are, I know them already, I just need a confirmation step.
> If I initiate a format on a drive volume I don't need a lecture on what a format does and what the risks are, I know them already, I just need a confirmation step.
When I was 12, I compressed drive C:\ in the hope more free space will be available. I think I'd have benefited from a lecture in the application.
I'm not quite clear on your point here. Did the compression cause problems? Did it keep reserved space so you still didn't have any free? Compression on a slow hard drive should generally improve performance and at the very least shrinking files means fewer fragmentation problems.
If you wanted the software to warn you it was buggy before you turned it on, haha good luck.
I don't recall all the details, but it was Windows 95 times. This embedded system utility basically zipped the root directory and rendered the computer unable to boot. I could have saved my parents a headache if I had been aware of the consequences.
My point was that there are scenarios where data can be lost and a quick ok/cancel dialog with a short summary is not enough. Even when we know what we're doing a reminder of consequences is sometimes helpful to look at.
You know what formatting means, my grandmother does not. For the sake of less tech savvy users there should be a warning if the operation is dangerous in the sense that it will delete data. Maybe not as part of the question but as a sentence before, in another paragraph, so that you can easily skim it, while others may read it.
That's exactly the point though - you want to make the UI deep. Ideally when I hit "Format" I should get a confirmation dialog warning that I'll irreversibly erase things, with an "expand" button for more information. But, as a power user the correct button to hit should be self-evident without actually reading the dialog at all.
This way the user can go as deep or shallow as they want without losing context.
Agreed. 2/3 words on a button allows those who know what they're doing (or think they know) to make the decision quickly, and leaves the dialog text to give a bit more explanation for those that need it and would choose to read it.
a very interesting and valid point about mixing the text with graphics. Though I standard of PLAY/PAUSE/STOP/FWD/BACK icons on VCR a is a example of a standard that is embraced and known globaly, no text involved. That said the old stories of people having problems programming there VCR may well have roots in the iconic only introduction only to be dumped into the non-standard programming interfaces that changed from model to model.
I certianly do believe signs/symbols when known have a very intuative communication medium and once adopted and used the comfort value is as good and if not better than some words which are after all a collection of symbols in themselfs. Road sighs would be another area which has at least some universal symbols, maybe those would be more adoptable for a user interface.
Perish the thought that one day we have a computer that you set up and asks you how you the user would like certain common dialogues to be handeled and propergated that customised standard across all applications running upon them. I'm all for graphic symbols to indicate across languages the actions available as apposed to limiting to words alone, which are in themself (for English and many other languages) only a collection of 26 or so symbols combined in themself.
The example you give about the word Save with a icon with a floppy disc is very common in alot of applications, though I do wonder for a new user who is starting out with computers if they would even be able to identify with the image of a floppy disc, let alone know they ever existed and there use. So some symbols are, if not thought out limited in there use and some are timeless classics that still endure today, like some roadsigns. It is also worth noting that colours play a important part and with that also have limitations. If you saw a road stop sign in green instead of red you would think it was a go sign and not a stop one; So careful use is wise. With that the mix you say of text and symbols is perhaps not that bad an approach after all, albiet language biased it would still allow say a user of a mobile phone to navigate the menu's using the symbols to change the menu language back to say English with ease having been comfronted with russian text due to a child changing the settings or the like.
I wish the position of the positive or negative action was standardised i.e. YES/OK/Secure Empty Trash (positive) always on the right, Cancel(Negative) on the left.
Buttons & Labels: http://developer.apple.com/library/mac/#documentation/userex...
Alert Dialogs: http://developer.apple.com/library/mac/#documentation/userex...
edit: It's also cool to see how much has (and hasn't) changed over the years. Here's a 1995 version of the Macintosh HIG: http://dropbox.scripting.com/dave/misc/appleHumanInterfaceGu...