| Date: | September 11, 2006 / year-entry #308 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060911-02/?p=29783 |
| Comments: | 63 |
| Summary: | I was talking with someone last year who had a gripe about a music organizer program. Suppose you create some playlists and then decide, "Oh, nevermind, I don't like this playlist." You highlight the playlist and click "Delete". You then get a dialog box that asks, "Do you want to move the songs in this... |
I was talking with someone last year who had a gripe about a music organizer program. Suppose you create some playlists and then decide, "Oh, nevermind, I don't like this playlist." You highlight the playlist and click "Delete". You then get a dialog box that asks, "Do you want to move the songs in this playlist to the Recycle Bin?" "Well, no, I don't want you to recycle those songs. I want to keep the songs. Just delete the playlist," you say to yourself and you click "No". Unfortunately, the program was asking you, "Do you want to move the songs to the Recycle Bin or delete the songs permanently from your computer?" The program had already decided that you wanted to delete the songs themselves when you deleted the playlist. It just wanted to know whether you wanted them gone immediately or just tossed into the Recycle Bin. Fortunately, my friend had backups of the songs that had mistakenly been purged from the computer, but it was still quite shocking to see all the music just plain disappear when there was no expectation that anything of the sort was going to happen. When programs put up Yes/No dialogs, they usually don't have a problem explaining what will happen when you click Yes. But they also have to make sure users understand what will happen when they click No. Window Vista's new Task Dialog makes it easier for programs to make it clearer to users what will happen as the result of pushing a button on a dialog box. Instead of being limited to just "Yes" and "No", you can put more meaningful text on the buttons such as "Save" and "Don't Save", or you could use command buttons and provide an explanatory sentence for each option. Now, programs could always have built custom dialogs with these more descriptive buttons, but doing so meant designing a dialog box from scratch, positioning the buttons precisely according to dialog box layout guidelines, and then writing a custom dialog procedure to handle this new custom dialog. Most people just take the easy way out and use Be careful, however, not to fall into the same trap with task dialogs. The original dialog might have been converted to a task dialog with the buttons "Recycle" and "Don't Recycle", which would not have solved the problem at all. |
Comments (63)
Comments are closed. |
The given program broke one much more important (but very unofficial) rule: "Yes branch should do potentially dangerous things, no branch should not do anything dangerous". That way you don’t have to understand what the question really mean, and still keep yourself "safe". "Do you want to open britney.jpg.exe", well, don’t think, just press "No" for every yes/no question etc.
I am 100% certain that only beginner can break such programming rule.
There is one traditional rule breakage, however: "DO YOU WANT TO SAVE? Yes/No". Such question, in such form, shouldn’t exist in modern software.
Sounds like the choices were bad to begin with, not just the wording. Even if your friend had clicked "Yes" instead of "No", the songs would have been sent to the Recycle Bin, when the ideal behavior would have involved neither binning nor outright deletion.
“Window Vista’s new Task Dialog makes it easier for programs to make it clearer to users what will happen as the result of pushing a button on a dialog box.”
Great, but nobody will use it for at least the next 5 years or until they decide that it’s safe to break XP compatability.
Hopefully some third party will build a .dll that will provide similar functionality for XP apps. (Of course it will be a custom implementation that won’t use the built-in functionality even on Vista.)
Also, why has it taken Microsoft so long to do this!?
Apple wrote this sort of thing into the OS X HIG and many apps were already doing it on OS 9 (I’m also pretty sure I’ve seen this sort of thing as far back as System 7).
And does it really take a custom dialog template just to change the text on the buttons!? Whose idea was that one?
Sounds like three buttons are needed:
Cancel | Send to Recycle Bin | Delete Permanently
Here is a link to a page about the TaskDialog API. The link in Raymond’s article is to an article about dialogboxes. Nice, but I wanted to see about the task dialogs.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/UxGuide/UXGuide/Resources/WhatsNewInVista/TaskDialogs.asp
Couldn’t you create a message box with custom buttons by setting a timer before creating it, and changing the button text when the timer fires?
@Vince P
>> what is the point of stating that?
and what is the point of your attack to that argument ?
this is a comment page, and stating that a new feature will realistically simply not be used for some years is .. what ? a COMMENT!! and not a stupid one, too.
So, there is this article TODAY about a feature which most programmers will be able to use, say, in 2012. If you are among the lucky ones who are already developing Vista only application, enjoy the new API. If you are a common programmer, you probably have to keep compatibility with XP (at least, if not 2000) so talking about it, is not, say, offtopic.
>> Why are you asking completely stupid and irrelevent questions?
He is not complaining about timeliness but about the choice of priority – let’s say for the sake of argument that he would have chosen a smart messagebox instead of a dancing dog in the search dialog.
That said, I’m pretty sure that if he’s complaining about something he might be either 1) interested in the opinion of one microsoft developer who owns this blog
2) just complaining for the sake of it
Either way a fanboy defending his idol with the stupidest arguments ever heard on this blog would not improve the comment quality neither the XP messagebox inner workings.
That Save/Don’t Save combination reminds me of Gnome’s HCI for some reason.
At least I’m glad Microsoft’s taking a stand on usability, regardless of where they "steal" the idea :)
No offense.
The problem isn’t with a yes/no box, it’s that the question is inherently not one with two mutually exclusive answers. It’s not asking the wrong question, it’s asking the question wrong, and I think that while more verbose buttons help, careful design is necessary to fully ameliorate the problem.
So, Stu, would you care to enumerate the "monumentally bad" design decisions that caused you to reach your hypothesis? Because I’m sure you have a deep understanding of the problem domain and your valuable expertise is too insightful to overlook.
At a former place of employment, we had a custom MessageBox form (it was a VB Classic application).
The rule was, MsgBox was only used for DEBUG code (when developing). All user messages were to use the custom form.
This form gave us the ability to put whatever text on the command buttons we wanted. Saved a lot of crazy messagebox grief.
I will check into the DialogBox and TaskDialog API’s and see how they work now.
The GNOME desktop Human Interface Guidelines heavily recommend against using Yes/No buttons on the grounds that users rarely read the dialog itself and assume they know what the buttons do.
As an example, the delete confirmation is ‘Are you sure you want to permanently delete "foo’?" with the buttons "Cancel" and "Delete".
Well, "are you sure you want to quit without saving" is just as bad as "do you want to save". Both are product of brainwashed programmers/managers who don’t understand how the software should interact with humans (duh).
Starting question with "are you sure" is also a special symptom. Heck, why should I even think in the domain of "how sure I am"?
But just imagine: it’s darned 2006, you turn your two thousand dollar computer which can store the whole Encyclopedia Britannica in RAM, not to count that the hard disk has space for, uhm, 100 of those, you start the 500 dollar word processor, developed for years and years, used by millions of users. You spend the whole day writing your document. After more hours of work, you’ve done for this day — and one stupid dialog which lets you err in just one click destroys all you’ve done for a whole day. Ta-dah!
The question at this point should just not exist.
There are lots of situations where you want to know information about all of the ramifications of each option.
When I was first setting up an Active Directory system, and picking the local domain name, the MSDN documentation said "if you have a public domain name, you can use that".
I expected the next sentence to say "And if you don’t, you can …" But no, there was NO CLUE or suggestion for what to use as the Active Directory domain name if you don’t have a public Web domain name.
If there are two choices, and the doc says "if blah blah, then blah blah", it should follow up with "else, blah blah".
I try to keep this in mind when I am writing documentation or dialog boxes.
(Side note: Many people have suggested not to use your public domain name for your internal A.D. domain unless you are running the authoritative DNS server for the domain, or whatever. I am not a domain expert. This is a side issue to the failure of the documentation to be complete.)
Yes, the dialog box should have said "We already decided that you want to delete the songs; should we put them in the recycle bin or delete them permanently?"
That would make it clear that the program had already decided on a course of action that the user didn’t want. From the information given, it’s clear that there was no way for the user to say "don’t delete OR recycle the songs". That’s simply bad programming.
I also don’t like the "are you sure" questions. Programs that just display things to you (where there is no risk of data loss) sometimes ask "are you sure you want to quit?" when you click the X to close the program.
In the very few cases (or never) where I didn’t want to quit, I can restart the program; but in the 99.9% of the time when I really wanted to quit, I have to deal with the annoying question. Some programs don’t have an option to turn off this nag.
I guess the programmers can’t imagine that you really wanted to quit their lovely program.
ac: You don’t like "Are you sure you want to quit without saving" and you also don’t like "do you want to save".
What do you suggest the program should say when you have worked all day on your program and you click Exit?
Usability experts basically all agree that verb-based buttons are much better than "Ok"/"Yes"/"No". Interestingly, "Ok" comes from testing on the Macintosh. The buttons originally said "Do it!" in Smalltalk verb button tradition. However, when they put it in front of testers, one of them complained that the computer was calling them a "Dolt" because the i looked like an l. The Macintosh designers changed it to "Ok" and the rest is history.
Jonathan: "you could deal with this by making the normal exit command and ‘x’ close window function go to a "Save or Cancel" dialog"
No! "Save or cancel" is still way too much. Why should I be forced to give the name to something, while I still work on it? The stupid thing should just keep on the hard disk that what is already there (most of the darned applications open some "temporary file" the moment you open the document anyway, happily write there — and then even more happily nuke it when you’re too tired to control where you clicked).
So the next time I start the application, it should show me exactly the same state of the document I left the last time. If I want to rename the darned "New document" to something more sensible, I should be able to do so at any later moment, but until then, it should still preserve my work.
The answer to "How to avoid updating files the user didn’t want updated" is: there should be a possibility to undo the whole updating action. There are more than enough resources for something like that.
"Instead of being limited to just ‘Yes’ and ‘No’, you can put more meaningful text on the buttons such as ‘Save’ and ‘Don’t Save’, […]"
It’s been long overdue, but it’s good to finally see support for this. The best (i.e., worst) dialogs are the ones where you try to cancel some long operation and the dialog box says:
—————————
DumbApp
—————————
Do you really want to
cancel?
—————————
Yes No Cancel
—————————
Of course, "Cancel" cancels the cancel, and after the 50th time trying to Cancel the user has to be physically restrained to avoid defenestrating his computer.
Offtopic, but I think this blog needs more bright colors and better color combinations.
The correct answer here is not to post a dialog box at all. Put the songs in the Recycle Bin AND allow the use of the Undo command in the Edit menu to bring them back from the Recycle Bin to wherever they were originally.
Don’t bug the user with stupid non-decisions. If I want those songs gone, just get them out of my face. Don’t ask me what to do with them! I already told you what to do with them! If I made a mistake in deleting those songs, let me get them back easily, and in a standard way.
I don’t like buttons with text other than OK and Cancel, or Yes and No.
I think the dialog are hard to read, and it makes more clusters of text to read that need to be related by the user. User slows down, panic sets it. There is more text to read, actions abbreviated to fit on a small button.
Sure, you want to ‘force’ me to read the dialog and understand it, but the standards like "Do you want save changes" yes/no/cancel are totally NOT broken, and the keyboard acceleration for the buttons are very good.
Please note : Interaction design is NOT only for begining users and dialog that happen only once, or the first experiences in general.
It is it also for repeated and prolong use, and it does NOT rule out the user being trained. It is about making the software easier for the user it’s for.
I’m usually pro microsoft here, but this new API is ironic as MS really dropped the bomb on user interaction design in the last few years, with Vista being full of dialog boxes, complex warnings, etc. It doesn’t look like they are going in the right direction. This API they are adding are simply nuturing that : putting more documentation on screen to read.
The 20 year old guidelines of OK and Yes being the safest choices for all users, without requiring fully understanding the message, still stands.
Writting a book of explaination about the dialog is not a solution. Eliminating the questions, and keeping the ones that are necessary short and based around accepted patterns is.
If you have complex choices, use a dialog with a radio button to select the action, and keep the Ok, Cancel paradigm. The interface translators will thank you later. Cryptic verbs on small buttons are NOT helping.
IMHO,
Microsoft, as part of interface guidelinesm should just provide samples for the most common cases of message boxes, for example the save-on-exit case..
This is how developement works at small and big companies, they look at what’s in office and VC++ and the apps they have on their computers. Some apps are bad examples.
My point is, the wording of the message and the choices is the biggest problem, and many programmers simply need to have better samples to base their promtps on.
Windows Vista’s new Task Dialog finally allows the use of verbs on action buttons. Jeff Waugh will be pleased. (He doesn’t put his slides online, but everyone in the universe has seen the talk I’m referring to by now, right? :-)…
"The correct answer here is not to post a dialog box at all. Put the songs in the Recycle Bin AND allow the use of the Undo command in the Edit menu to bring them back from the Recycle Bin to wherever they were originally.
Don’t bug the user with stupid non-decisions. If I want those songs gone, just get them out of my face. Don’t ask me what to do with them! I already told you what to do with them! If I made a mistake in deleting those songs, let me get them back easily, and in a standard way."
That’s great, except that in this case it’s not songs that are being deleted, it’s a playlist. Personally, I would NOT expect deleting a playlist to delete the songs that it references.
Sort of offtopic, but if there is one thing worse than those Yes/No/Cancel dialog boxes, it’s when they lie.
I’m forced to use this tool that is an MDI app. I bring up a child element and start typing into it, but saving it in an unfinished state, though possible, is bad.
I also accidentally click the X in the top right of the maximized parent when my optical mouse goes a little wonky. It brings up the great: Do you want to save changes, Yes/No/Cancel?
I don’t want to click Yes, because I’m not done yet and things might be upset by a partial entry. Clicking No will discard my changes and close the program. I’ll click Cancel.
Nope, Cancel evidentally Cancels The Program instead, causing me to lose my stuff anyway.
I just type it up in a text editor now and paste it, less harrowing.
Although this change is a very good thing, Acorn RISC OS (developped by the now defunct British company Acorn Computers Ltd; although you can still buy computers with RISC OS, for example the Castle Iyonix pc) had this guideline since 1991.
(I’m talking about meaning full buttons in message dialogs – so MS is very late with this change in its Windows OS guidelines)
You know, Raymond, there ought to be a metablog or discussion board called The Off Topic Thing, where spin-off discussions can take on a life of their own without cluttering up your comments. There are a lot of ideas and topics that come up here that I’d love to take further, but I hate contributing to off-topic content (like I’m doing now). Heck, I’d even host it.
PMP
There is something missing from this discussion, and that is the localization implications of having buttons which say something other than Yes/No/Cancel.
With Yes/No/Cancel you translate the question text and put that on a window with buttons that have text that has been translated once and which is guaranteed to fit on the button space provided for all languages supported by the OS.
If you begin allowing verbs or phrases as button text, you must now deal with questions like "will ‘Do Not Recycle’ fit on the same sized button once its been translated into language X?" and more importantly "who is going to pay to translate all of these verbs or phrases I’ve added to hundreds of dialogs in my app".
I would suspect that when translating dialog text, it is much easier to create a question to which the localized Yes/No/Cancel answers make some sort of sense than it is to produce both dialog text, and verbs or phrases for buttons, which continues to convey the original meaning from the original language, make sense in whatever language it is translated into, and fit on the button space provided.
I would imagine this additional effort for localization, more than any other reason, is why Windows chose to use the Yes/No/Cancel approach.
Wow! You mean Windows is taking an idea from Mac OS? Who would have ever thought?! :)
Nice to see this fuctionality in Vista, whats also nice to see is in the documentation, there are "wrong" examples that other Microsoft departments have done over the years.
My bloody word. How do you put up with it Raymond? You write a perfectly good article.. pick an example to illustrate a point.. and are then inundated with IDIOCY in the comments.
Really Raymond.. if you can somehow figure out how to get IE to shoot stupid people I’d be all for it.
-Boo
Another thing to worry about is the action that "Enter" and "Esc" have on the dialog. "Enter" should be a rough equivalent of "Yes" or "OK", and "Esc" should be "Cancel" or "No."
In fact, sometimes when I can’t figure out which is the appropriate choice in a dialog, I’ll hit Esc to be safe.
I don’t agree that Win32 is fatally flawed, but it has definitely got its share of ugliness. Like Stu said, it’s a bit silly that having two windows on the same desktop represents an open attack vector between them. The solutions of using separate desktops or a job object for containment aren’t pretty or well supported.
One of the things that aggravates me about Win32 is error messages; Win32 tends to condense several underlying error codes into a single inaccurate error. For example, I was trying to create a section (a file mapping) and Win32 was giving me the error ERROR_BAD_EXE_FORMAT: "%1 is not a valid Win32 application." It didn’t make any sense until I discovered that the real error was STATUS_INVALID_FILE_FOR_SECTION (the filesystem didn’t support memory mapping) but was lumped in with several other status codes. Just look at how many distinct errors are under the categories of ERROR_INVALID_PARAMETER and ERROR_ACCESS_DENIED:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q113996
Another thing is how different APIs report errors in many different ways, some with BOOL for success, sometimes with a special return value (e.g. INVALID_HANDLE_VALUE), and some require you to call GetLastError() every time to tell the difference between an error and special success. I will say that GetLastError() is almost always the way to retrieve the error code when there is one. In comparison, every NTAPI function returns NTSTATUS, which neatly combines error, warning, informational and success result codes.
The way heap memory is allocated for various functions and how it’s freed and by whom is very inconsistent.
The existence of dangerous and unusable functions like IsBadWritePtr.
The way that the windowing system requires heavy use of casting to get anything done. Sending of WM_GETMINMAXINFO before WM_NCCREATE. The fact that there’s no generic way to supply IsDialogMessage() processing without maintaining a list of dialog boxes, i.e. when you’re running a message loop for someone else’s windows and dialogs.
The lpCommandLine parameter in CreateProcess not being const because CreateProcess can’t afford to double buffer it before parsing.
The inability for two Win32 processes to have multiple consoles or use console handles for many file operations because console handles are not real file handles.
Win32 has no way of querying the name of a kernel object (file, key, event, etc.) given only a handle to it. Underlying support exists with NtQueryObject.
The need to use a special syntax (\?) to open paths longer than 255.
It’d be nice to know how DeviceIoControl distinguishes between device and fs control and have a version that lets me queue an APC upon completion like ReadFileEx or Nt[Fs/DeviceIo]ControlFile does. For that matter, a method for async directory enumeration like NtQueryDirectory allows.
I’m sure that many of these things had their reasons at one time, I know you’re not responsible for them, but at this point the best solution seems to be a new API; one NOT built upon Win32, one that is designed with the future in mind, like the NT api.
As another example, Mozilla’s XUL has an interface to do this sort of thing (prompt-service), and I’ve found it’s tremendously useful. I’m glad Windows will soon be providing this at the API level.
@ac:
> So the next time I start the application, it should show me exactly the
> same state of the document I left the last time.
But what happens if I open two documents in the "scratch" state, close both and open a new one again – which one does it show? What happens to the other one?
Here are a couple of “monumental mistakes” in Win32:
* Win16 source compatibility *in the core API*.
I have no problem with Win16 compatibility per se, source or binary, but it was taken to such extreame lengths in the design of Win32 that it has simply become a burden to Win32 programmers.
I can see why it was done, no need to retrain programmers, etc, but the massive changes to the underlying archetecture make so much of Win16 no longer make sense in a pre-emptive, 32-bit, flat-memory-model world, that Win16 compatibility should have been placed in a seperate series of libraries and helper applications (but still allowing the combining of Win16-style code with ‘proper’ Win32 code). Win32 should have been as legacy-free as possible.
*The Windows message passing/events/signals system.
I know this was designed back when all programmers were trustworthy and resources were scarse, but the Windows message passing system really is a POS.
No way to distigush an ‘artifical’ message from a real user input? Messages that *activate* controls, rather than simulating a user click? A message that basically tells an app to jump to an arbitary location and begin execution (WM_TIMER)? Was anybody thinking at all!?
It’s not like these things were new. UNIX/X had already shown the world a better way(tm).
You’ve got me going now.
Consistency – we’ve heard of it.
Open multiple documents in Word. You get multiple document windows (no more MDI). Click the X in the top-right of one window. That window closes.
Open multiple spreadsheets in Excel. You get multiple document windows. Click the X in the top-right of one window. Excel exits, all windows close.
AAAgh!
I like it but it needs to be consistence. An example: user experience consistency in Windows Vista…
– notepad does it right (save, don’t save, cancel)
– wordpad doesn’t
– paint doesn’t
Need to say more? Please fix this (feedback ID 163263 on Microsoft Connect)!
-Bart
@Hayden: That wasn’t my point. I was talking about the "scratch" stuff that AC mentioned as a way to avoid the "Save/Don’t Save" question altogether – what happens if you have two documents in the "scratch" state.
I do agree that the Excel behaviour is "strange" to say the least.
It’s been possible to create fancy verboid Message Boxes for years. Can’t recall if you can do it in MFC, but it’s doable in VCL (via Delphi or CBuilder). I bet you a unit of your currency of choice there are at least a dozen 3rd party DLLs that let you do this. If you’ve wanted to do it, you have been able to for years for essentially chicken feed.
[grid controls are always a favourite 3rd party widgit, should a comprehensive one be built into the OS?]
What we don’t need is any sort of new widget whose API document has no [references to] UI guidelines.
"That Save/Don’t Save combination reminds me of Gnome’s HCI for some reason.
At least I’m glad Microsoft’s taking a stand on usability, regardless of where they "steal" the idea :)"
Yeah, because Gnome were the *very first* to come up with that idea. I mean, I didn’t work on a Windows app ten years ago that followed this guideline because at the time it was already a well-known principle. A quick check reveals that Gnome wasn’t even started until two years after we shipped, and we were hardly the first to use this rule.
Damn Gnome fanboys, think they invented everything :-)
goodness, MS are just catching up to JOptionPane?
"Usability experts basically all agree that verb-based buttons are much better than "Ok"/"Yes"/"No". "
This is interesting, because personally I find them harder to use – I can’t glance at the buttons and click the one I’m aiming for, instead I have to read them all because every button says something different and less predictable for every dialog.
Vista strikes me as good for beginners, in this regard, because it explains everything in detail, but already I am resenting the extra reading I’m having to do for familiar operations that I used to be able to do on ‘autopilot’ (particulary when the text is soft and fading in and out and changing colour and making my eyes throb if ClearType is on).
Of course the original fault described was that the designer of the program did not understand what the concept of a playlist was or how it would be used. Having a better set of tools is no substitute for having a good craftsman.
I agree completely with the flurry of nitpicks about Windows quirks in response to Raymond’s article. It’s obvious that we should all be using AmigaDOS, with its perfect OS and GUI, and then all our problems would be solved.
(Oops, sorry, wrong decade for that one).
As some commenters observed, some commenters have been as vicious as I am sometimes, but I don’t quite see what reason some commenters might have for their viciousness on this topic. If someone might say what their reason was, it might be understandable.
It looks to me like the base note is kind of saying three things: (1) Design sensible dialogs. (2) Call DialogBox() instead of MessageBox() so that you can display sensible dialogs. (3) Five years in the future you’ll be able to call some Vista APIs that will be simpler than DialogBox().
It looks like the base note neglected to mention: (4) Let’s hope some of Mr. Chen’s colleagues will read the base note. (For example IE has some message boxes that allow yes and no but forgot to allow cancel. For example Visual Studio 2005 has a lot of dialog boxes that were well designed but some that weren’t.) Readers who haven’t followed this blog for a long time might not be aware that Mr. Chen hopes some of his colleagues will learn from his postings. Maybe there would have been fewer vicious comments if this fact had been mentioned.
On the other hand we have this:
Monday, September 11, 2006 9:24 PM by Hayden
> Open multiple spreadsheets in Excel. You get
> multiple document windows. Click the X in the
> top-right of one window. Excel exits, all
> windows close.
>
> [This may come as a surprise to you, but I
> don’t work on Excel. -Raymond]
I think Hayden has the same wish that Mr. Chen and others have, we hope that some Excel designers/programmers will read Mr. Chen’s blog.
I hope some Adobe designers/programmers will too, because Acroread does the same thing. If you’re very careful then you can avoid doing that in Acroread, but it would be nicer if they had copied the way Word does it instead.
My two cents:
1) What we all need is a place where to expose all stupid thing done in software. AND, with names clearly written. For example, this program your collegue refer to…maybe one of us will use it and delete all his songs? So, why not tell the entire world?
(I still remember an old entry about the complexity of the "avoid application bug" code MS has to insert into Windows to mantain backward compatibility…)
2) Yes, no, retry, cancel and a proper written text is what a messagebox really needs.
My only rule for msgboxes is to never use negatives sentences, for the user needs to rethink each time if no is yes and yes is no, even more because 90% of msgboxes have positive questions.
http://thedailywtf.com/forums/thread/90807.aspx
Also look in the blogroll on the right.
"Wouldn’t you not like to not delete all the songs?"
[Yes] / [No]
"I do agree that the Excel behaviour is "strange" to say the least."
I like Excel’s Multiple Document Interface operation. Word 2000 is strange in that it doesn’t have an option to not put an icon for each document in the TaskBar, but still, under the Window menu item you can see all documents and switch to any one.
This thread has gotten offtopic; sorry.
David Walker – No other app or office version than Word 2003 & Excel 2003 do display a taskbar button for every opened document. This behavior is non-standard and confusing and have made me and other lose hours of work. Other top level windows like control panel applets should on the other hand be displayed as an task button, but they aren’t.
The non-distinction between top level windows and processes some programs do are not helping either, a user should be able to kill a distinct active program without losing work in open documents at random. Explorer is an example of a bad program in this case, the user don’t know how many explorer windows will die when he kills an explorer process.
I prefere OK/Cancel to Yes/No because Esc key only work in OK/Cancel dialogs. Therefore I usually word the question to comply with a OK/Cancel answer.
Pressing Escape without reading the question I do alot – it should always be harmless.
http://philg.hates-software.com/2003/11/03/093638f3.html
I suspect programs (programmers!) ask "are you sure…" to be able to blame the user when things go wrong.
ac: The answer to "How to avoid updating files the user didn’t want updated" is: there should be a possibility to undo the whole updating action. There are more than enough resources for something like that.
Ok, that could work.
Just make sure it is absolutely bit perfect. If I have to revert to undo changes (possibly accidental changes) I want to get back exactly the file I started with.
(Wouldn’t want to accidentally break any digital signatures on that original file.)
Seems that everyone has missed a point.
There should be separate "Delete Playlist" and "Delete songs" options instead of single "Delete" option which doesn’t explain what will be deleted.
So I am afraid that new dialogs with fancy strings won’t help a bit.
PingBack from http://www.yes-no-cancel.co.uk/2007/07/19/yes-no-cancel-causes-aspirin-sales-to-soar/
PingBack from http://www.ja-nein-abbrechen.de/2007/07/19/ja-nein-abbrechen-treibt-aspirin-verkaeufe-in-die-hoehe/