UI Question
-
I think I prefer the Task Dialog approach where you give people better choices. You pretty much chose your button texts with: Close without saving Save and close Save without closing
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
MehGerbil wrote:
Close: Close without saving.
Cancel: Close without saving.Why have duplicate buttons? :confused:
For those times when you really want to close without saving.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
MehGerbil wrote:
Close: Close without saving.
Cancel: Close without saving.Why have duplicate buttons? :confused:
-
Greetings, I'm building a new application template and I'm not sure how to handle one part of the User Interface. If a user has a configuration screen open and they wish to close it I don't know what buttons I should include. Theoretically, you could have 'Close', 'Cancel', 'Ok', and 'Apply' - which seems a bit much. Close: Close without saving. Cancel: Close without saving. OK: Save then close. Apply: Save but don't close. It used to be that I'd just follow what Microsoft does but I've found the 'OK' button confuses people. They usually end up pressing 'Apply' and then 'OK'. There comes a point when multiple options just confuse people. I'd like to reduce the number of buttons. Maybe 'OK' and 'Close' where the user gets a warning message if 'Close' would result in changes being lost. What do you think?
-
Greetings, I'm building a new application template and I'm not sure how to handle one part of the User Interface. If a user has a configuration screen open and they wish to close it I don't know what buttons I should include. Theoretically, you could have 'Close', 'Cancel', 'Ok', and 'Apply' - which seems a bit much. Close: Close without saving. Cancel: Close without saving. OK: Save then close. Apply: Save but don't close. It used to be that I'd just follow what Microsoft does but I've found the 'OK' button confuses people. They usually end up pressing 'Apply' and then 'OK'. There comes a point when multiple options just confuse people. I'd like to reduce the number of buttons. Maybe 'OK' and 'Close' where the user gets a warning message if 'Close' would result in changes being lost. What do you think?
Cancel: close without saving. Apply: save without closing. Save: save and close.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I once had to create a way of allowing a user to start something big happening on the server. It needed no feedback, just had to kick the thing off. I went for a screen with a very large button in the middle that had the text Make Thingy Go Now! It did the job.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
Greetings, I'm building a new application template and I'm not sure how to handle one part of the User Interface. If a user has a configuration screen open and they wish to close it I don't know what buttons I should include. Theoretically, you could have 'Close', 'Cancel', 'Ok', and 'Apply' - which seems a bit much. Close: Close without saving. Cancel: Close without saving. OK: Save then close. Apply: Save but don't close. It used to be that I'd just follow what Microsoft does but I've found the 'OK' button confuses people. They usually end up pressing 'Apply' and then 'OK'. There comes a point when multiple options just confuse people. I'd like to reduce the number of buttons. Maybe 'OK' and 'Close' where the user gets a warning message if 'Close' would result in changes being lost. What do you think?
Well, if we take a page from Microsoft's best practices: Cancel - brings up a dialog "You will lose your changes, are you sure?" OK: Dialog 1: Apply changes and close dialog? Always ask me? If you answer "no, don't ask me anymore" the assumed behavior = Cancel If you answer "yes", you get: Dialog 2: Your changes will affect the usability of the application. Proceed?" If you answer "yes": Dialog 3: This change requires administrator privleges. Please enter the username and password of the admin." Dialog 4: Registry permission violation. Changes will be lost. Press OK to proceed." Dialog closes, changes are not saved. Marc
My Blog
The Relationship Oriented Programming IDE
Melody's Amazon Herb Site -
Greetings, I'm building a new application template and I'm not sure how to handle one part of the User Interface. If a user has a configuration screen open and they wish to close it I don't know what buttons I should include. Theoretically, you could have 'Close', 'Cancel', 'Ok', and 'Apply' - which seems a bit much. Close: Close without saving. Cancel: Close without saving. OK: Save then close. Apply: Save but don't close. It used to be that I'd just follow what Microsoft does but I've found the 'OK' button confuses people. They usually end up pressing 'Apply' and then 'OK'. There comes a point when multiple options just confuse people. I'd like to reduce the number of buttons. Maybe 'OK' and 'Close' where the user gets a warning message if 'Close' would result in changes being lost. What do you think?
Typical configuration screens of this type have Cancel, Apply and OK buttons, although the OK button would be better titled 'Save and close' because you don't expect to see Apply and OK together. And if you have pressed Apply then Cancel becomes Close (because you can't revert to the state when you first opened the window).
-
Greetings, I'm building a new application template and I'm not sure how to handle one part of the User Interface. If a user has a configuration screen open and they wish to close it I don't know what buttons I should include. Theoretically, you could have 'Close', 'Cancel', 'Ok', and 'Apply' - which seems a bit much. Close: Close without saving. Cancel: Close without saving. OK: Save then close. Apply: Save but don't close. It used to be that I'd just follow what Microsoft does but I've found the 'OK' button confuses people. They usually end up pressing 'Apply' and then 'OK'. There comes a point when multiple options just confuse people. I'd like to reduce the number of buttons. Maybe 'OK' and 'Close' where the user gets a warning message if 'Close' would result in changes being lost. What do you think?
I would go for OK and Cancel - most users are used to them. However, I would also use the MouseHover event to swap the text between them... :-D
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
MehGerbil wrote:
Close: Close without saving.
Cancel: Close without saving.Why have duplicate buttons? :confused:
-
Greetings, I'm building a new application template and I'm not sure how to handle one part of the User Interface. If a user has a configuration screen open and they wish to close it I don't know what buttons I should include. Theoretically, you could have 'Close', 'Cancel', 'Ok', and 'Apply' - which seems a bit much. Close: Close without saving. Cancel: Close without saving. OK: Save then close. Apply: Save but don't close. It used to be that I'd just follow what Microsoft does but I've found the 'OK' button confuses people. They usually end up pressing 'Apply' and then 'OK'. There comes a point when multiple options just confuse people. I'd like to reduce the number of buttons. Maybe 'OK' and 'Close' where the user gets a warning message if 'Close' would result in changes being lost. What do you think?
Bugger the lot of 'em. Always use verbs to describe the action that will take place when a button is pressed. Okay is not a verb. I prefer "Commit" of "Save" for general dialogs and "Exit" to close it. The reason becomes clear when you have a dialog to close an account, the commit button should be "Close" [the verb of the action] so the no commit action has to be "Exit".
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Bugger the lot of 'em. Always use verbs to describe the action that will take place when a button is pressed. Okay is not a verb. I prefer "Commit" of "Save" for general dialogs and "Exit" to close it. The reason becomes clear when you have a dialog to close an account, the commit button should be "Close" [the verb of the action] so the no commit action has to be "Exit".
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
I think I prefer the Task Dialog approach where you give people better choices. You pretty much chose your button texts with: Close without saving Save and close Save without closing
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
0 - Close 1 - Save and close 2 - Save without closing 3 - Self detonate
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) "It is the celestial scrotum of good luck!" - Nagy Vilmos (2011) "But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012) -
Cancel: close without saving. Apply: save without closing. Save: save and close.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
+5 on this answer, I don't know what the others have been drinking or smoking, but - Cancel, - Apply and - Close or Save are the common set of buttons you'll find in nearly all applications. "close without saving" "close with saving" How do you want to integrate THAT into an application? What's next? A button labeled "try-out-and-do-not-use-further-more-when-not-working"? I have translations in my applications that make a single word into a complete sentence kind of thingy (Arabic wording, don't ask me why). I don't want to know what a "close without saving" button would do to my layouts...
regards Torsten When I'm not working
-
Greetings, I'm building a new application template and I'm not sure how to handle one part of the User Interface. If a user has a configuration screen open and they wish to close it I don't know what buttons I should include. Theoretically, you could have 'Close', 'Cancel', 'Ok', and 'Apply' - which seems a bit much. Close: Close without saving. Cancel: Close without saving. OK: Save then close. Apply: Save but don't close. It used to be that I'd just follow what Microsoft does but I've found the 'OK' button confuses people. They usually end up pressing 'Apply' and then 'OK'. There comes a point when multiple options just confuse people. I'd like to reduce the number of buttons. Maybe 'OK' and 'Close' where the user gets a warning message if 'Close' would result in changes being lost. What do you think?
"Save" and "Cancel". Always use verbs. Having "Close" and "Cancel" without "Apply" does not make sense to me as they are the same. Having both "Cancel" and "Apply" is confusing: will "Cancel" undo an earlier "Apply"?? OK is only OK when the dialog isn't related to a user action (and then it would be the only button, and "Close" would be equally OK). FWIW: I don't like "Apply" much, either it is an inexpensive operation and it should apply immediately (and be undone upon "Cancel"), or it is an expensive one and then it only happens upon "Save". :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Greetings, I'm building a new application template and I'm not sure how to handle one part of the User Interface. If a user has a configuration screen open and they wish to close it I don't know what buttons I should include. Theoretically, you could have 'Close', 'Cancel', 'Ok', and 'Apply' - which seems a bit much. Close: Close without saving. Cancel: Close without saving. OK: Save then close. Apply: Save but don't close. It used to be that I'd just follow what Microsoft does but I've found the 'OK' button confuses people. They usually end up pressing 'Apply' and then 'OK'. There comes a point when multiple options just confuse people. I'd like to reduce the number of buttons. Maybe 'OK' and 'Close' where the user gets a warning message if 'Close' would result in changes being lost. What do you think?
Will the settings have an immediate effect when the user "apply" them ? or does the user needs to close the dialog before they become effective ? Personally, I prefer the simple "Ok" and "Cancel" buttons.
Watched code never compiles.
-
+5 on this answer, I don't know what the others have been drinking or smoking, but - Cancel, - Apply and - Close or Save are the common set of buttons you'll find in nearly all applications. "close without saving" "close with saving" How do you want to integrate THAT into an application? What's next? A button labeled "try-out-and-do-not-use-further-more-when-not-working"? I have translations in my applications that make a single word into a complete sentence kind of thingy (Arabic wording, don't ask me why). I don't want to know what a "close without saving" button would do to my layouts...
regards Torsten When I'm not working
There's a reason that the TaskDialog was introduced by MS, and why it provides the option to give more descriptive options. What you have described is a technology-centric view of the world, and may not reflect the actions that users expect. The theory goes that you should be able to drop somebody with no computer experience in front of your application and they should be able to use your application immediately without guidance. Just because we, who use technology every day, know what these terms mean in this context doesn't mean that my father would - and I pick him because he's one of the stubbornest technophobes I've ever met. You can capitalise the word THIS all you like but it doesn't get away from the fact that it's only your opinion that this is correct.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
There's a reason that the TaskDialog was introduced by MS, and why it provides the option to give more descriptive options. What you have described is a technology-centric view of the world, and may not reflect the actions that users expect. The theory goes that you should be able to drop somebody with no computer experience in front of your application and they should be able to use your application immediately without guidance. Just because we, who use technology every day, know what these terms mean in this context doesn't mean that my father would - and I pick him because he's one of the stubbornest technophobes I've ever met. You can capitalise the word THIS all you like but it doesn't get away from the fact that it's only your opinion that this is correct.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
Pete O'Hanlon wrote:
only your opinion that this is correct.
Please, sir, me, sir!!! (Frantically waves hand in the air to get the teachers attention). I think so too!!! :-)
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
Greetings, I'm building a new application template and I'm not sure how to handle one part of the User Interface. If a user has a configuration screen open and they wish to close it I don't know what buttons I should include. Theoretically, you could have 'Close', 'Cancel', 'Ok', and 'Apply' - which seems a bit much. Close: Close without saving. Cancel: Close without saving. OK: Save then close. Apply: Save but don't close. It used to be that I'd just follow what Microsoft does but I've found the 'OK' button confuses people. They usually end up pressing 'Apply' and then 'OK'. There comes a point when multiple options just confuse people. I'd like to reduce the number of buttons. Maybe 'OK' and 'Close' where the user gets a warning message if 'Close' would result in changes being lost. What do you think?
I use OK and Cancel. I generally don't like Apply -- like Luc, I expect a Cancel to undo an Apply. For an app I've been working on I have a Settings (modal) dialog with OK and Cancel. The dialog does not set the settings, it does not know what they mean or where they go, that's handled by the calling Form upon exitting the dialog with OK. This makes persisting the settings into the config file easier as well.
-
Greetings, I'm building a new application template and I'm not sure how to handle one part of the User Interface. If a user has a configuration screen open and they wish to close it I don't know what buttons I should include. Theoretically, you could have 'Close', 'Cancel', 'Ok', and 'Apply' - which seems a bit much. Close: Close without saving. Cancel: Close without saving. OK: Save then close. Apply: Save but don't close. It used to be that I'd just follow what Microsoft does but I've found the 'OK' button confuses people. They usually end up pressing 'Apply' and then 'OK'. There comes a point when multiple options just confuse people. I'd like to reduce the number of buttons. Maybe 'OK' and 'Close' where the user gets a warning message if 'Close' would result in changes being lost. What do you think?
Quote:
Close: Close without saving. Cancel: Close without saving.
When you see the redundancy, (if you don't have a very good reason for it) you must eliminate it. Go with OK, Cancel, and Apply I say.
