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...
-
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...
Henning Dieterichs wrote:
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?Yes; it would cancel "anything" within the container. Can be as easy as "NOT" committing the transaction. You are using transactions?
Henning Dieterichs wrote:
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)?
As a user, I wouldn't understand this. The technical limitation that you cannot save childobjects without having a parent is your problem, not the users.
Henning Dieterichs wrote:
Does it matter that each edit form is shown in a new browser window?
No.
Henning Dieterichs wrote:
Does it matter that it is a web application?
No.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
-
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...
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')
-
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...
"Cancel" should reverse any changes made that have not been explicitly saved - but if these are big it's nice to have a "Are you sure? this will remove all your changes since...blah blah" dialog to confirm it. But if it does that, it's also nice to have an "Apply" button, which commits any changes up to that point.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
-
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...
This question has long plagued me, without me ever arriving at an answer. What I do is have the top cancel button only cancel changes to the top form, and put a text under the button stating this.
-
Henning Dieterichs wrote:
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?Yes; it would cancel "anything" within the container. Can be as easy as "NOT" committing the transaction. You are using transactions?
Henning Dieterichs wrote:
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)?
As a user, I wouldn't understand this. The technical limitation that you cannot save childobjects without having a parent is your problem, not the users.
Henning Dieterichs wrote:
Does it matter that each edit form is shown in a new browser window?
No.
Henning Dieterichs wrote:
Does it matter that it is a web application?
No.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
Thanks for your comment!
Eddy Vluggen wrote:
You are using transactions?
Not directly - when a form is initialized, the data model is cloned from the parent (deep clone), i.e. the top most form clones from the database, a child element clones from its parent etc. On save, the child data model is committed to the parent. The top most form will commit the data model to the database. On cancel, the current data model of the form will be forgotten. So, a "cancel" on a location will undo all changes made to its rooms, but earlier changes to rooms already committed to the current school (through saving the location) wont get lost, although the school has not be saved yet. The model which is decoupled from the database and the model attached to it have the same interface, so a form does not know whether it is writing to the database or not.
Eddy Vluggen wrote:
As a user, I wouldn't understand this. The technical limitation that you cannot save childobjects without having a parent is your problem, not the users.
I think you have misunderstood me: If the user had expected, that clicking on "cancel" saves the changes made to child elements, the UI would be inconsistent, if the user creates a new object, edits its child elements and does not click "Create School" but "Cancel" (i.e. aborts the creation) and the UI would discard the locations and rooms associated to this new but canceled object. 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.
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...
-
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')
_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...
-
"Cancel" should reverse any changes made that have not been explicitly saved - but if these are big it's nice to have a "Are you sure? this will remove all your changes since...blah blah" dialog to confirm it. But if it does that, it's also nice to have an "Apply" button, which commits any changes up to that point.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
What do you mean with "explicity saved"? Maybe the user thinks he saved the room (the child) explicity if he clicks "ok" on that window, and closes the location (the rooms parent) with [X], (ignores the possible warning), and presses "save" on the school window (the grandparent of the room) and does not understand why his room gets lost, although he clicked on "ok" on that window...
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...
-
What do you mean with "explicity saved"? Maybe the user thinks he saved the room (the child) explicity if he clicks "ok" on that window, and closes the location (the rooms parent) with [X], (ignores the possible warning), and presses "save" on the school window (the grandparent of the room) and does not understand why his room gets lost, although he clicked on "ok" on that window...
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...
OK is an explicit save - so if you are going to cancel it afterwards, then you probably need to remind the user that that is going to happen, and give him the option.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
-
Thanks for your comment!
Eddy Vluggen wrote:
You are using transactions?
Not directly - when a form is initialized, the data model is cloned from the parent (deep clone), i.e. the top most form clones from the database, a child element clones from its parent etc. On save, the child data model is committed to the parent. The top most form will commit the data model to the database. On cancel, the current data model of the form will be forgotten. So, a "cancel" on a location will undo all changes made to its rooms, but earlier changes to rooms already committed to the current school (through saving the location) wont get lost, although the school has not be saved yet. The model which is decoupled from the database and the model attached to it have the same interface, so a form does not know whether it is writing to the database or not.
Eddy Vluggen wrote:
As a user, I wouldn't understand this. The technical limitation that you cannot save childobjects without having a parent is your problem, not the users.
I think you have misunderstood me: If the user had expected, that clicking on "cancel" saves the changes made to child elements, the UI would be inconsistent, if the user creates a new object, edits its child elements and does not click "Create School" but "Cancel" (i.e. aborts the creation) and the UI would discard the locations and rooms associated to this new but canceled object. 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.
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:
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![^]
-
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...
If a window has OK and cancel buttons, I view them as "commit" and "rollback" respectively. Just like with databases, if you issue a rollback, you wouldn't expect any persisted changes.
-- Kein Mitleid Für Die Mehrheit
-
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...
Henning Dieterichs wrote:
What does the user expect
Disappointment and sorrow.
Henning Dieterichs wrote:
changes to the child objects ... be discarded too?
Yes.
Henning Dieterichs wrote:
about to create the object
That's details of implementation; the user neither knows nor cares.
Henning Dieterichs wrote:
Does it matter that each edit form is shown in a new browser window?
Don't do that.
Henning Dieterichs wrote:
Does it matter that it is a web application?
No, they all suck anyway. X| My own personal favourite is the Windows Start button -- right-click | Properties | Customize now you're on a new dialog , make changes , click OK now you're back at the parent dialog in my opinion Cancel should cancel any changes specified on the child dialog, but it doesn't. :sigh: I've gotten used to it. In your app, can you have a list of things awaiting save/commit? So the user knows exactly what is pending? Kind of like a shopping cart I guess.
-
Henning Dieterichs wrote:
What does the user expect
Disappointment and sorrow.
Henning Dieterichs wrote:
changes to the child objects ... be discarded too?
Yes.
Henning Dieterichs wrote:
about to create the object
That's details of implementation; the user neither knows nor cares.
Henning Dieterichs wrote:
Does it matter that each edit form is shown in a new browser window?
Don't do that.
Henning Dieterichs wrote:
Does it matter that it is a web application?
No, they all suck anyway. X| My own personal favourite is the Windows Start button -- right-click | Properties | Customize now you're on a new dialog , make changes , click OK now you're back at the parent dialog in my opinion Cancel should cancel any changes specified on the child dialog, but it doesn't. :sigh: I've gotten used to it. In your app, can you have a list of things awaiting save/commit? So the user knows exactly what is pending? Kind of like a shopping cart I guess.
PIEBALDconsult wrote:
My own personal favourite is the Windows Start button
Hmm, seems to be a bug: If you change anything in the child dialog, press "Ok", then, press "Cancel" in the parent window, and, as expected, Windows does not change anything. But if you go back to the child dialog, you see the value you have changed before... And Windows does not seem to be consistent: If you want to edit the owner of a file, you have multiple child dialogs, but pressing "Ok" in the deepest child dialog will submit the changes immediately...
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...
-
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
