UI Question
-
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?
Two buttons: "Save changes" and "Close dialog". "Save changes" also closes the dialog.
Software Zen:
delete this; -
How about a "Close but no cigar" button?
Henry Minute Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is. Cogito ergo thumb - Sucking my thumb helps me to think.
Not sure it fits the application, and then I try and avoid negatives as some people seem to get confused by them. Maybe "Apply Nicotine Patch" is more appropriate. :)
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?
One button. Only. It say's "I'm Done". When the user clicks it, close the dialog and then prompt the user for what action to take. If there are changes, prompt for whether to save them or not. It's pretty simple, much like indexes that start at zero. ;P
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
-
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
-
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?
To provide a consistent user experience throughout Windows please follow their UI guidelines: Apply - will apply settings immediately, button is optional. Only incorporate this button when options are changed that can be immediately reviewed (like changing fonts/colors etc). Including this buttons usually means extra code. OK - apply changes and close Cancel - discard changes and close. Please don't reinvent the wheel, every time the user sees a different text than those above he/she need to read and think about it. You should not change their order either.
-
"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?
Remove all buttons and save immediately. Apply/OK is doable when a ton of changes are prone to undo, in this case a wizard will be better. Let a Close button to do just close. Think what Mac does.
Nuclear launch detected
-
We should have FOUR options actually: 1. Close without saving (Close=true, Save=false) 2. Save without closing (Close=false, Save=true) 3. Save and close (Close=true, Save=true) 4. Don't save, don't close (Close=false, Save=false) (huh?)
krumia wrote:
Don't save, don't close
And just what would that button do? :doh:
I love go-o-o-o-ld!
-
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
The DevExpress XAF framework has a nice combo I try and copy, Save and Close and Save and New, where the latter, of course, really also closes, but then immediately invokes the New command, for smoother capture.
-
How about a "Close but no cigar" button?
Henry Minute Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is. Cogito ergo thumb - Sucking my thumb helps me to think.
I generally prefer Save - save , don't close Discard Changes - revert to original/clear or close without saving depending on behaviour of rest of system. Close - close, prompt for save if required If you click close and there are unsaved changes present a confirmation dialog The options NEVER CLICK THIS and Global Thermonuclear War are of course the other options
-
krumia wrote:
Don't save, don't close
And just what would that button do? :doh:
I love go-o-o-o-ld!
-
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?
MehGerbil wrote:
Close: Close without saving.
Cancel: Close without saving.
OK: Save then close.
Apply: Save but don't close.depends on what you want to ascertain; 1. close/ok; is fine for notifications like "check your mailbox" or "we accidently deleted your database", but no response is required really, its a nag prompt and can even auto close if its being ignored 2. cancel; system is about to perform an action that needs to be authorised/acknowledged, can use it for "non-repudiation" and even track as part of user activity. 3. [ok/yes/no]/cancel]; can be a little confusing for a user becasue they're not really sure if the action is going to execute correctly - cancel, revert while ignoring the requested task? yes, execute as planned? no, could mean...execute a variation on the task or dont execute at all in which case its now the same as cancel again. and also how many variations are there for the particular task? its fine for a simple confirmation like an action with one of two option like "would you like to register for our monthly newsletter" while saving their user profile, the profile gets saved anyway. i use a wizard for extremely complicated scenarios but for the most part it depends on the use cases being catered to. software dev is a complicated excercise and more often than not a single view could have multiple scenarios being catered for, so i use form input and layout to collect data for each scenario(i.e. click this and show/hide that...highlight these...re-load this grid) and simply prompt the user with an ok/cancel option - "you are doing this? ok/cancel?" and at this point pass or fail the whole scenario. if i then prompted the user with "you are doing this? yes/no/cancel?" i would be setting myself up for a moot point of my own doing because if they are not sure the we really should proceed and the whole scenario should fail...so no==cancel and we have the confusing recursion again and in most cases it because the developer is unsure/careless! it's really a language comprehension issue not a programming paradigm! know the outcome being catered for and prompt around the context of the desired outcome.
No one knows the things of a man except the spirit of that man; likewise no one knows the things of God except the Spirit of God whom we have received. He who is joined to the Lord, is ONE Spirit with him(Jesus) - 1Cor 2:10-16 & 6:17
-
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?
-
+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
Pete O'Hanlon wrote:
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.
Nobody wants to read the manual these days...
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
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 prefer the following as it hasnt raised any confusion for my users. Cancel - close without saving Done - close with saving In the experience that I have had, making it a 'plain enlish' as possible works the best. These two options are great for users as it's simple to understand. Now, if I needed a 'save without closing' option (and it has been rare) then I just label as 'save w/out closing' or similar.
-
Pete:
Close without saving Save and close Save without closing
One more, Close without opening. My 5.
Happy Programming
-
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?
Have you asked the USERS? Give them an option, one with and one without the Apply button. Let them tell you what they want to see and what works best for them.
-
Don't forget
Halt and Catch Fire
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
Lovely trip down memory lane :) Haven't come across that instruction since playing around with 8 bit micros!
-
Lovely trip down memory lane :) Haven't come across that instruction since playing around with 8 bit micros!