Call me an elitist, but I've no use for users who don't know what "yes" and "no" mean.
It's not that they don't know what "Yes" and "No" mean, it's that it's clearer and easier if they don't have to connect the "Yes" and "No" with choices given by the message in the dialog.
But slavish adherence to out-of-ass usability rules just so slashdot posters are happy is something I won't do.
As a UI designer, your job is to make it easier for all levels of users to use the application.
But I am not going to design my dialogs with the assumption that my users are idiots. I have too much respect for them to do that.
You're not assuming that the users are idiots. You're offering the user affordances to help him navigate, which ends up helping all levels of users. By forcing the user to figure out what your dialog means, you're disrespecting your user by making them use a hostile UI.
Most confirmation dialogs can be written as boolean functions, and even used within if statements. Yes==true ; no==false. Getting away from this perfect mapping is dangerous, because if we're asking a boolean true/false question, we should be getting a boolean true/false answer back.
It's still a boolean function regardless of what the two buttons have on them.
So why not put the entire dialog text into a button? That's the result if you keep following your chain of logic.
No, you don't get it: You're not trying to fill up the buttons with as much information as possible. You're goal as a UI designer is to provide the user with affordances to make navigating the UI easier and quicker. Clearly labelled buttons provide an affordance for the user, whereas "Yes/No" choices do not.
Because you're assuming that the user will never read the actual dialog text. Well if not, why put it there at all?
No, I'm making the choices that the dialog box offers explicit, which makes the action that will be performed obvious to the user. The message should still provide additional information that will help the user make the decision.
To reiterate, if my dialog text has bad grammar, is confusing, or does not lend itself to a simple boolean yes/no answer, then log a bug and I'll fix it.
Again, it's not about defects, it's about making the UI easier to use.
Your example is a bit disingenuous -- we could just as easily magine a dialog box with two buttons labelled "expurgate another drive instead of C" and "do not expurgate another drive instead of C", versus a dialog with a message of "Erase C ?" with "Yes" and "No" buttons. Which is easier to use?
No, you're not getting it. You've zeroed in on the fact that a developer could obfuscate a UI, but this is not what I was trying to illustrate. Thus you've simply succeeded in illustrating two examples of bad UI design. My example was not about the possibility that a UI could be obfuscated, but rather that even if a dialog's message was hard for the user to understand, properly designed choices would succeed in helping the user. That is why I made a contrived example. Understand?
The point I am trying to get across is that no matter how unclear the message is to the user, the choices he is shown should be unambiguous in relation to that message. The goal of designing a good UI is to make it painfully obvious to the user what the UI actually does. A dialog box with a simple "Yes/No" choice does not succeed in this, because it offers no affordances for what action the dialog will take.
Aaargh! We've dumbed down the UI to the level of the flatworm! Why don't we just have a dialog box that has a nice smiley face and single button labeled "okey dokey"?
It's not "dumbing down the UI", it's making the user's choices explicit to help him avoid mistakes. This should be the goal of all UIs. Think about it. Is it easier and less time consuming to use an unambiguous UI? Sure it is. Wouldn't you much rather use a simple to understand UI? Sure you would.
The user shouldn't have to figure out what the developer means by "Yes" or "No" in relation to the message in the box. Dialogs with a Yes/No choice are hostile to the user and time consuming for even expert users (i.e. you can't just click a button without checking if it's the correct one first even if you've encountered the dialog before). When the buttons explicitly tell the user what the choice is going to do, it is easy for the user to pick out the correct choice without having to think about whether "Yes" means one thing or another. Furthermore, when the choices are explicit, expert users can move through the dialog much easier.
Maybe an example would help. Consider if the following horribly screwed up message was displayed by a dialog box:
Would you prefer to not expurgate another drive instead of drive C?
First imagine this message with buttons labelled "Yes" and "No", and then imagine it with buttons labelled, "Erase C" and "Don't Erase C".
Do you see how it's explicitly obvious what is about to happen with the second set of buttons no matter how screwed up the message in the dialog box is? The user does not have to figure out what action the button is going to perform in relation to the message, because it's obvious.
Do you see that no matter how complicated the choices are, it's always easier for the user if the actions are explicitly labelled?
Pardon me for being dense, but what the fsck is wrong with that?
What's wrong with it? It violates proper UI design!
A properly designed dialog box does not force the user to think about what the choices will actually do. Dialog boxes with a long string of ambiguous text and Yes/No buttons violate this concept, because the user has to read the text very carefully before he makes a choice. This forces the user to stop thinking about what he was trying to actually accomplish with the application in the first place and forces him to figure out what the developer actually meant. This leads to both mistakes and a loss in user productivity. If the buttons are clearly labelled with what the choice will actually do, the user is less prone to make a mistake.
An explanation of why a lab in Taiwan has UK power sockets would be in order
They aren't. If you look closely at the pictures, they are Class I grounded 15 amp plugs and sockets (i.e American NEMA 5-15 or Canadian CS22.2 standards).
Taiwan uses North American type plugs/sockets and 110V/60Hz electricity.
I think there are two of them. I think this one doesn't know his alphabet. The other one knows a lot of words but grammar, punctuation and capitalization is beyond his/her/it abilities.
Their supercilious obloquies are both jejune and otiose. They are fatuous mammothrepts whose nugatory caterwauls are less piquant than an ululation from their own fundaments. Their only pursuit is a perverted predilection to plumb a porcine paramour's plenitudinous posterior.
Slashdot Mirror
It's not that they don't know what "Yes" and "No" mean, it's that it's clearer and easier if they don't have to connect the "Yes" and "No" with choices given by the message in the dialog.
But slavish adherence to out-of-ass usability rules just so slashdot posters are happy is something I won't do.
As a UI designer, your job is to make it easier for all levels of users to use the application.
But I am not going to design my dialogs with the assumption that my users are idiots. I have too much respect for them to do that.
You're not assuming that the users are idiots. You're offering the user affordances to help him navigate, which ends up helping all levels of users. By forcing the user to figure out what your dialog means, you're disrespecting your user by making them use a hostile UI.
Most confirmation dialogs can be written as boolean functions, and even used within if statements. Yes==true ; no==false. Getting away from this perfect mapping is dangerous, because if we're asking a boolean true/false question, we should be getting a boolean true/false answer back.
It's still a boolean function regardless of what the two buttons have on them.
So why not put the entire dialog text into a button? That's the result if you keep following your chain of logic.
No, you don't get it: You're not trying to fill up the buttons with as much information as possible. You're goal as a UI designer is to provide the user with affordances to make navigating the UI easier and quicker. Clearly labelled buttons provide an affordance for the user, whereas "Yes/No" choices do not.
Because you're assuming that the user will never read the actual dialog text. Well if not, why put it there at all?
No, I'm making the choices that the dialog box offers explicit, which makes the action that will be performed obvious to the user. The message should still provide additional information that will help the user make the decision.
To reiterate, if my dialog text has bad grammar, is confusing, or does not lend itself to a simple boolean yes/no answer, then log a bug and I'll fix it.
Again, it's not about defects, it's about making the UI easier to use.
That was completely uncalled for. :p
So true. That's an excellant point, and definitely something to keep in mind when designing UIs.
No, you're not getting it. You've zeroed in on the fact that a developer could obfuscate a UI, but this is not what I was trying to illustrate. Thus you've simply succeeded in illustrating two examples of bad UI design. My example was not about the possibility that a UI could be obfuscated, but rather that even if a dialog's message was hard for the user to understand, properly designed choices would succeed in helping the user. That is why I made a contrived example. Understand?
The point I am trying to get across is that no matter how unclear the message is to the user, the choices he is shown should be unambiguous in relation to that message. The goal of designing a good UI is to make it painfully obvious to the user what the UI actually does. A dialog box with a simple "Yes/No" choice does not succeed in this, because it offers no affordances for what action the dialog will take.
It's not "dumbing down the UI", it's making the user's choices explicit to help him avoid mistakes. This should be the goal of all UIs. Think about it. Is it easier and less time consuming to use an unambiguous UI? Sure it is. Wouldn't you much rather use a simple to understand UI? Sure you would.
The user shouldn't have to figure out what the developer means by "Yes" or "No" in relation to the message in the box. Dialogs with a Yes/No choice are hostile to the user and time consuming for even expert users (i.e. you can't just click a button without checking if it's the correct one first even if you've encountered the dialog before). When the buttons explicitly tell the user what the choice is going to do, it is easy for the user to pick out the correct choice without having to think about whether "Yes" means one thing or another. Furthermore, when the choices are explicit, expert users can move through the dialog much easier.
Maybe an example would help. Consider if the following horribly screwed up message was displayed by a dialog box:
First imagine this message with buttons labelled "Yes" and "No", and then imagine it with buttons labelled, "Erase C" and "Don't Erase C".Do you see how it's explicitly obvious what is about to happen with the second set of buttons no matter how screwed up the message in the dialog box is? The user does not have to figure out what action the button is going to perform in relation to the message, because it's obvious.
Do you see that no matter how complicated the choices are, it's always easier for the user if the actions are explicitly labelled?
Yes, that's exactly what I mean. That didn't come across the way I phrased it.
What's wrong with it? It violates proper UI design!
A properly designed dialog box does not force the user to think about what the choices will actually do. Dialog boxes with a long string of ambiguous text and Yes/No buttons violate this concept, because the user has to read the text very carefully before he makes a choice. This forces the user to stop thinking about what he was trying to actually accomplish with the application in the first place and forces him to figure out what the developer actually meant. This leads to both mistakes and a loss in user productivity. If the buttons are clearly labelled with what the choice will actually do, the user is less prone to make a mistake.
I was talking about the clothes, wankstain. Why, what were you thinking?
I made sure it was Asus *BEFORE* I clicked. The goatse link that made it to the front page has forced me to be more conservative.
They aren't. If you look closely at the pictures, they are Class I grounded 15 amp plugs and sockets (i.e American NEMA 5-15 or Canadian CS22.2 standards).
Taiwan uses North American type plugs/sockets and 110V/60Hz electricity.
Your girl has a really nice set of... Um, creations.
(Yeah, that's it.)
A freudian slip is where you say one thing and mean your mother^W^Wanother.
This is awesome! I'm can't wait to use a bunch of these to build my paper clock.
Where did you find a Gnome with a built-in clock?
Their supercilious obloquies are both jejune and otiose. They are fatuous mammothrepts whose nugatory caterwauls are less piquant than an ululation from their own fundaments. Their only pursuit is a perverted predilection to plumb a porcine paramour's plenitudinous posterior.
Look on the bright side: He hasn't changed any dialogue.
He still understands that there is a subtle difference between, "Luke, I am your father", and, "Luke, who's your daddy?"
Oh my!
Someone did in a way.
Now we'll really be ready when the dead rise from the grave.
An additional £25 million ($45 million) in funding will go toward adding the obligatory gin.
That way somebody will mirror it and others will provide torrents.
Information wants to be free!
Yeah, that was kind of the problem. I was unable to find the requisite nudie pics on the net.
However, I was able to find places that sell the actual magazine issue. So, you could buy the print version, and have a collector's item!
They were aware of that, and "Simba" originally *was* going to be Kimba's name.
They changed the "S" to a "K", because there were possible trademark issues involving the merchandising rights.
It's a joke. The Lion King very closely resembles Jungle Emperor in certain respects.
Tim Skelly was the designer. Scott Bodden actually programmed "Star Castle".
Scott traced the starfield from the February 1980 issue of OUI magazine.
I don't know which model it was, Cleo Bergssen or Nelia Cozza.