User Expectations for cancel button
-
Designing an UI for a web application I had an interesting but controverse talk to a friend: what does the cancel button discard on the top most form? I have two examples: Schools which consist of multiple locations which consist of multiple rooms; and users who consist of group-memberships. Each object, despite the membership, has multiple text based properties. What does the user expect, if he clicks on the cancel button (or closes the form window) on a school or user object? Should the changes to the child objects (locations and their rooms for schools and memberships for users) be discarded too? What does he expect if he is about to create the object (you cannot save the changes of child elements without creating the owning object)? Does it matter that each edit form is shown in a new browser window? Does it matter that it is a web application? Please consider only the user's point of view, it does not matter which one is more complicated to implement. Thank you in advance, Henning
If you find spelling- or grammer-mistakes, please let me know, so that I can correct them (at least for me) - english is not my first language...
A Cancel button should discard all changes made in a session, from the moment the user entered the function block. If an explicit "Save" has been performed, Cancel should discard any changes made since the Save operation.
Will Rogers never met me.
-
In my experience, users don't like multiple windows unless the app really, really calls for them to use two views simultaneously. More so with a web app as users don't tend to open more than one window - and most I have experience of don't even use multiple tabs unless they are nagged into it! So if you have a parent window open, then click "Add new Child" and it opens a child window, and then in that child window they can click a button to "add grandchild" I think most users would run around like headless chooks if they could get back to the grandparent window without first closing the parent and child - which is, I think, what you are suggesting? My way of handling it depends on the exact scenario and how often it is likely to occur. e.g. if the only time it happens is when you are creating a new school, and the software is generally run by a single school, then it's not too important - they are unlikely to create new school, add a location, add a room, then go back to the school and press cancel - so I don't let them. I would generally keep the object tree in memory until they save the school with all its children (if it's a relatively infrequent and small object graph) or write them away to the db but be prepared to go ahead and delete the whole tree if that's really what they want to do. The user, I think, doesn't expect anything abt creating hierarchies - that's not how they think - so I guess if they did create school, location and several rooms, save the room, save the location then cancel the school, they would expect it ALL to disappear - after an appropriate warning, I suppose!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
:thumbsup: Very good points there.
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
-
A Cancel button should discard all changes made in a session, from the moment the user entered the function block. If an explicit "Save" has been performed, Cancel should discard any changes made since the Save operation.
Will Rogers never met me.
Roger Wright wrote:
If an explicit "Save" has been performed, Cancel should discard any changes made since the Save operation.
I disagree with this. If there is a "Save" or "Apply" button, it should not be 'undoable'. If there is a cancel button anywhere, it should not discard the effects of a 'Save' or 'Apply.
-- Harvey
-
Roger Wright wrote:
If an explicit "Save" has been performed, Cancel should discard any changes made since the Save operation.
I disagree with this. If there is a "Save" or "Apply" button, it should not be 'undoable'. If there is a cancel button anywhere, it should not discard the effects of a 'Save' or 'Apply.
-- Harvey
That is exactly what I said. But anything after the last Save should be discarded.
Will Rogers never met me.
-
That is exactly what I said. But anything after the last Save should be discarded.
Will Rogers never met me.
-
Designing an UI for a web application I had an interesting but controverse talk to a friend: what does the cancel button discard on the top most form? I have two examples: Schools which consist of multiple locations which consist of multiple rooms; and users who consist of group-memberships. Each object, despite the membership, has multiple text based properties. What does the user expect, if he clicks on the cancel button (or closes the form window) on a school or user object? Should the changes to the child objects (locations and their rooms for schools and memberships for users) be discarded too? What does he expect if he is about to create the object (you cannot save the changes of child elements without creating the owning object)? Does it matter that each edit form is shown in a new browser window? Does it matter that it is a web application? Please consider only the user's point of view, it does not matter which one is more complicated to implement. Thank you in advance, Henning
If you find spelling- or grammer-mistakes, please let me know, so that I can correct them (at least for me) - english is not my first language...
The way I have handled this type of thing in the past is through work-flow design rather than function of the cancel button. My top most form would not allow a child form to be opened unless the parent record was saved first. So the buttons or links that allow adding locations or rooms would be disabled until the school was saved. Designing the work-flow this way eliminated the possibility of saving children before the parent was saved and then having to deal with the potential of cancelling the parent.
-
Designing an UI for a web application I had an interesting but controverse talk to a friend: what does the cancel button discard on the top most form? I have two examples: Schools which consist of multiple locations which consist of multiple rooms; and users who consist of group-memberships. Each object, despite the membership, has multiple text based properties. What does the user expect, if he clicks on the cancel button (or closes the form window) on a school or user object? Should the changes to the child objects (locations and their rooms for schools and memberships for users) be discarded too? What does he expect if he is about to create the object (you cannot save the changes of child elements without creating the owning object)? Does it matter that each edit form is shown in a new browser window? Does it matter that it is a web application? Please consider only the user's point of view, it does not matter which one is more complicated to implement. Thank you in advance, Henning
If you find spelling- or grammer-mistakes, please let me know, so that I can correct them (at least for me) - english is not my first language...
I do believe the Windows UI guidelines cover this... Provide a command button to halt the operation if it takes more than a few seconds to complete, or has the potential never to complete. Label the button Cancel if canceling returns the environment to its previous state (leaving no side effects); otherwise, label the button Stop to indicate that it leaves the partially completed operation intact. You can change the button label from Cancel to Stop in the middle of the operation, if at some point it isn't possible to return the environment to its previous state. From: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511268.aspx
-
Designing an UI for a web application I had an interesting but controverse talk to a friend: what does the cancel button discard on the top most form? I have two examples: Schools which consist of multiple locations which consist of multiple rooms; and users who consist of group-memberships. Each object, despite the membership, has multiple text based properties. What does the user expect, if he clicks on the cancel button (or closes the form window) on a school or user object? Should the changes to the child objects (locations and their rooms for schools and memberships for users) be discarded too? What does he expect if he is about to create the object (you cannot save the changes of child elements without creating the owning object)? Does it matter that each edit form is shown in a new browser window? Does it matter that it is a web application? Please consider only the user's point of view, it does not matter which one is more complicated to implement. Thank you in advance, Henning
If you find spelling- or grammer-mistakes, please let me know, so that I can correct them (at least for me) - english is not my first language...
I think your problem is not one of user expectations, but one of UX design. You have three distinct entities on screen at a time. Each one should have its own cancel button. Don't open three windows, use a framework which allows you to develop nice single page apps with modal dialogs. Some old UI design wisdom I encountered in an IBM tutorial says you should handle one business process in one screen. From what you're telling, editing a school/location/room are three distinct business processes, even if sort of subordinated to each other, so each one deserves a distinct window. Since your current design, afaict, is one where you only can edit locations from the school screen and can only edit rooms from the locations screen, modal dialogs make sense, IMO. Alternatively, you can depict everything as a tree, and have add/remove ops for locations/rooms as operations to the tree, acting on the currently selected school/location. This way, you can have a single window open at a time, with just one cancel button, and the problem with three simultaneously open windows goes away.
-
In my experience, users don't like multiple windows unless the app really, really calls for them to use two views simultaneously. More so with a web app as users don't tend to open more than one window - and most I have experience of don't even use multiple tabs unless they are nagged into it! So if you have a parent window open, then click "Add new Child" and it opens a child window, and then in that child window they can click a button to "add grandchild" I think most users would run around like headless chooks if they could get back to the grandparent window without first closing the parent and child - which is, I think, what you are suggesting? My way of handling it depends on the exact scenario and how often it is likely to occur. e.g. if the only time it happens is when you are creating a new school, and the software is generally run by a single school, then it's not too important - they are unlikely to create new school, add a location, add a room, then go back to the school and press cancel - so I don't let them. I would generally keep the object tree in memory until they save the school with all its children (if it's a relatively infrequent and small object graph) or write them away to the db but be prepared to go ahead and delete the whole tree if that's really what they want to do. The user, I think, doesn't expect anything abt creating hierarchies - that's not how they think - so I guess if they did create school, location and several rooms, save the room, save the location then cancel the school, they would expect it ALL to disappear - after an appropriate warning, I suppose!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
I agree with _Maxxx_,as a user after encoding a objects/records(rooms,classes,locations) and there is something he miss out and decided to cancel everything he puts up, then, there should be a warning message saying all the encoded data will be erased/not saved.. I think its only a matter of proper error message to the user, and not to complicate things in saving the current session/child which may lead to data redundancy and confusions. A linear transaction is what I'm suggesting.
-
Henning Dieterichs wrote:
I think you have misunderstood me
On purpose; users don't think in objects. When I cancel a form, any changes therein are dropped.
Henning Dieterichs wrote:
The UI have to discard these changes, because the temporary owning object (the school) has been deleted by the user.
It's a logical problem, not a technical limitation.It's a technical problem, not a problem; "temp"-objects? Those aren't relevant to a user. How and where you cleanup, is merely a technicality. Dropping the transaction is the easier way. Updating the references by hand is also an option, albeit a little harder. Third option, my favourite, is to have all changes only in memory, and write them on a "save" method. That case, cancelling is just a matter of not updating the database.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
Eddy Vluggen wrote:
Third option, my favourite, is to have all changes only in memory, and write them on a "save" method.
Indeed, this way you properly decouple the form(s) from the underlying models in proper MVC fashion.
Sometimes a fist in the face says more than a thousand honeyed words.
-
Duh. "Early onset alzheimers" moment. Sorry, you are right of course. I can read just fine, its my comprehension that is on the wane.
-- Harvey
:laugh: Happens to all of us with the passing of years. I recommend strong drink; it doesn't improve comprehension, but gives one a wonderful excuse. :-D
Will Rogers never met me.
-
_Maxxx_ wrote:
More so with a web app as users don't tend to open more than one window
Yes it is true, but there up to 700 schools, each school consists of 1 to 3 location with up to 100 rooms - so it is a handy feature to open multiple objects at the same time (e.g. if the user want to compare multiple schools or edit them simultaneously). But there are objects (e.g. public chatrooms), which never have more than three instances. But the UI should be as consistent as possible, so the way editing chatrooms should be the same as editing users or schools or locations...
_Maxxx_ wrote:
which is, I think, what you are suggesting?
This would be possible and is not recommended in general, but there are cases in which it is very usefull to see the parent window without having to close the child.
_Maxxx_ wrote:
so I guess if they did create school, location and several rooms, save the room, save the location then cancel the school, they would expect it ALL to disappear - after an appropriate warning, I suppose!
My opinion! But my friend had a different view and we both had not much objective arguments beside his implementation is easier, but that is not a point for the user...
If you find spelling- or grammer-mistakes, please let me know, so that I can correct them (at least for me) - english is not my first language...
Henning Dieterichs wrote:
so it is a handy feature to open multiple objects at the same time (e.g. if the user want to compare multiple schools or edit them simultaneously).
Is that an actual Use Case or just something you think could be useful? The term handy sounds more like it's the latter! I am under the impression that you're trying to put too much functionality into one transaction. No wonder you have trouble to frame the scope of a simple Cancel operation! Think small: For non-tech-savvy users, any application that requires you to keep track of more than one window simultaneously is bad. The less information a user needs to supply for completing a transaction, the better. An average human can hold about 7 individual items in short-term memory. That means you can expect your users to remember just a handful of extra bits of information while looking at a screen. And when I say screen, I mean what he sees on his monitor, not the part of a web page that he would first need to scroll to. For your application that means: find out what size of monitors your users will be using. If they're not tech-savvy, they may use outdated or non-optimal gear, and that might include a small screen, or one with bad contrast that requires bigger font sizes without serifs just to be readable. These screens define the usable limits of your forms! Next find out what type of users will be using that application: if there really are some that wish to compare schools (what for?), those may not be the same users as those that enter the data. In fact, those that enter the data may not be using the application beyond that at all - they may just be typists or secretaries doing the hard work of setting up the database for those who actually need it! Then find out the things that each type of users wish to accomplish. Don't think in schools or rooms - think in tasks. For each task, decide what objects are affected, and what information you need to display or inquire. Divide the task into individual steps that make sense from the PoV of the user, then create forms to accomplish these steps. At that point, the meaning of Cancel is unambiguous: it will revoke any changes made to the current step.