Cancel Buttons
I was talking with Jerry Carter last week on the subject of Cancel buttons on the web. What should they do in a document in edit mode was the question. Should it return the user to read-mode or to the view itself? My reply was that it depended on how much like a Notes client application he wanted to make the web browser application.
If you want to keep thinking like a Notes developer then the cancel button should close the page and open the view. I've written about this before here. That was more than 3 years ago though. Back then I was a Notes developer working on the web. Now I like to think I am a web developer who just happens to use Notes/Domino. I think different now. It's been just as many years, in fact more, since I made a client app. I no longer use the Notes paradigm when it comes to designing my Domino apps.
The ensuing discussion had me trying to convince Jerry it's possible to do without the Cancel button altogether. If the site were designed well in the first place you could simply have a link that returned straight to the view (or the document in read-mode) without the need for a cancel button.
Jerry replied by saying that users are used to Cancel buttons, as they appear on almost all dialog boxes. True. But these buttons really do cancel something - a form submission for example. A cancel button on a webpage doesn't cancel anything. If anything it should be called a Close button, and even then it may cause confusion and should probably be left off all together.
What I am trying to get across is that it's important to "think different" on the web. Don't start trying to mimic every feature you are used to squeezing in to a Notes database GUI.
Skip to the 
You can subscribe to an individual
Jake, I was pondering this myself last week (before I got distracted...)
Imagine a user has opened a document in edit mode and made some changes but not submitted them. How can they be sure that their changes have not been registered (and saved) without a 'cancel' button? Sure, we know that without submitting the changes are not saved, but frankly I don't think most users know this. If users made changes in a Notes app, and then chose 'close' or 'exit' or even just hit the escape key, they would be warned about saving their changes.
I'm constantly amazed by the enormity of the gap between developers' understandings of the way in which applications (and computers) work, compared to the understanding of even quiet proficient end-users. I take this gap to be even greater when one is dealing with internet applications - with intranets at least there is likely to be some training/feedback that would narrow this gap.
We need to do everything we can to make the users of web apps sure about the effects of their actions - especially if we are going to be deducting money. (I say this having once being £150 out of pocket following an error with a back button incident...) The online banking apps I've used make me verify my changes multiple times just to make sure I know what is happening.
As to whether or not users are returned to the document in read-mode, or back to some view - doesn't it depend on what they are doing? Returning them to the view assumes that they have finished reading that document. This assumption can surely only be true of some users, and at certain times. Also, I think it is quite easy for users to get lost in the structure of a site/application. Letting them go back in the steps that they came up to a point helps them feel more sure about the structure (I think breadcrumbs are good in this context, as the user can even see a visual representation of their tracks, although I don't think that is so useful if the representations is too cluttered, or if their understanding of the link text does not gel with their understanding of each step's purpose).
One can always use some other kind of navigation structure that is within easy reach to let them decided that backing-out is too laborious, and they would prefer to jump elsewhere.
Of course, I'm commenting as a relative novice, so I could be completely off the mark :-)
Bernard
On the contrary, Bernard, you are spot on. It all depends on the context the user is in.
We use a B-to-C app where we provide all the buttons, next, back, save and cancel. It is important (like the banking apps) that a user know for sure when they are submitting a purchase request. The click of the cancel button brings a second prompt of 'Are you sure?'. Same is true for the save button.
Other apps, say a blog with a Post It! button, are not in the same context and don't require the same level of concern.
BTW, Jake, I guess that you don't have to worry about any calls from 3M since your button does not have the '-' like the little yellow stickies :-)
Perhaps the best way I know of to redirect people is using breadcrumbing at the top of forms and the $$ViewTemplateDefault form. It gives users a solid idea of where they came from and a way to get back there with a click.
However, it truly depends on the app you are developing - and the user audience's expectations - as to whether a "Cancel" button makes any sense. None of the apps I develop now need that, but if it became a requirement, I'd sure as heck program it.
I agree with Jake: I look at myself as a web developer who happens to use Notes/Domino. I still do some client-based work, but that's not much anymore. 90% of what I do is for the web.
Most of my time is spent figuring ways to make apps look LESS like Notes on the web. The security is the only thing that's kept me developing in this arena and not moving on to ASP or Cold Fusion.
Just my $0.02 (American)
Kelvin
Can't imagine my users getting along with no "Cancel" button!!!!! Oh the humanity!!!!
This is mostly an issue because there are not really any accepted standards for how forms submission is handled in most UI's. Most people don't realise for instance that switching tabs in a tabbed dialog box commits any changes on that page - or at least that is the way Microsoft intended it to work - other apps may not do this. Yet this is an example of a bad precendent, because there is no clue to the user that switching tabs will commit changes.
On the web, you typically don't pop up a new window over an existing, which is the typical dialog/form metaphore of Windows apps. When you start an action that pops open a new window, the use of save, close and cancel are partly implied in that you are reversing or completing that transaction.
You can do popups on the web, but of course many people don't, they stick with a single page metaphore, and therefore context must be given in the UI. Breadcrumb trails are a good example of how to give context to actions. i.e. if I cancel this, where do I go back to.
Of course there are other widgets that can be used, such as tooltips, so that people understand the deeper context of a button. ie. you have a button called 'save' but the tooltip reads 'save the document and return to the view' or whatever. This of course assumes that the document can only have been accessed from a view context, and not just any old place, even via a direct URL from a book mark.
All of this comes down to the importance of the whole UI design and setting the users expectation and context. Its not a question of the cancel button, but of how the users perceives the sequence and consequence of events.
Many banking type sites have a logout button - but many don't have any contextual hint as to what happens when I click the close window box. A little script would be all that is needed to warn me that my session may still be cached if I do that, and that logout is the correct, secure way of leaving the site.
Jacob Nielsen and others have proven that users' habit is to click the browser [Back] button anytime they don't want to do something, get into trouble, etc. His research shows that even if you do give them a [Cancel] they aren't likely to use it.
Alternatively (sort of) Jeff Raskin says that computers should always store everything we enter -- never needing an explicit [Save]. If that were true, would you even need a [Cancel]? The only example of this that I can think of is the TaxCut web application. My first thought is that this would require a lot of frontend logic, which for many reasons is not something I'd normally recommend.
My personal experience has shown that the most important thing is to be consistent. Web application standards are still being developed and learned, so try this approach:
1. Educate yourself on related usability topics.
2. Based on your enlightened view of the issue, develop a few simple prototypes.
3. Perform quick and cheap usability tests to determine what is the best way.
Do it the same way every time, and your users will learn it and probably never complain.
Keep in mind that "doing it the same way every time" doesn't mean that on EVERY screen you always either have [Cancel] or you don't. If you can categorize some situations where they are beneficial, and others where they are not, then that is fine. Just be sure there is enough within the user experience to keep the user aware of what's up.
For example, I never user [Cancel], except in wizard situations. For those, I still rely on the methods from the old Microsoft Windows User Experience reference book. Apple UI Guidelines takes a slightly different approach, but Sun's Java UI guidelines are pretty close to the Windows methods. Besides, my users have Windows desktops, so given any overriding web standard, its usually not a bad idea to fall back to the Windows standards.
PS
Tooltips have their place but they are slow to display and most people don't think to try them. A more promonent identifier for "more info" has shown to work well for me.
Also, lots of "Are you sure?" prompts that can't be turned off get REALLY annoying after you've learned the application. So if its an app that someone will use often enough, you might think of an alternate solution or just allow them to be turned off.
I'm with David F on this one. The cancel button is effectivly obsolete in the web world. On individual pages there is no need. The only place you ever need a cancel is on dialog box (or the web equivalent - popup windows)
As for the Tabs issue... I think that is wrong anyway. The only Tabs I have in my applications are effectively mouse-overs that hide/unhide DIVs to make it appear that the tabs are changing contents. There is only one save button. If you need to cancel, you go back. Using Domino based tabs on the Web is wrong. They work entirely differently and should not be confused. If you're in a Notes app, use tabs. If you're in a Domino app DO NOT use the Notes tabs. Plain and simple. Think about the interface.
Cancel is not needed. Same, in my opinion, for that stupid "reset" form option.
I like the cancel button - or at least save and close as options. It just makes it clear that the field changes the user has entered are not going to be put into the database.
Clicking back on the browser is not always the option people choose in my experience.
Each to his own I guess - it sounds like a big deal over nothing to me.
"I am a web developer who just happens to use Notes/Domino"
I used to keep telling myself that, but in reality the Notes/Domino disease always afflicts you more than that. My only excape was to leave development for my new role as "Senior Support Analyst", which is the same as "Support Analyst", only three years older.
As for Cancel buttons, I agree with Ian O'Rourke entirely. They're not redundant to novice users at all, and when I edit something only to find there's no cancel button I get nervous. "Back" is OK, up to a point, but there have been times wher I've just closed the window in the hope of my activity never being recorded. Novice users know where they are with a Cancel button. Long live basic usability.
I actually just recently completed a very short contract job where the main requirement seemed to be for the purely notes application to look exactly like the company's web application. That was a first for me.
The incongruity of the request caught me as funny at the time.
People dont just use software at work anymore. Most people are becoming very internet savy at home. They instinctively know a "sight" that is intuitive and easily navigable from one that is not--cancel button or not.
A Cancel action should terminate the most recent user action. Thus, if the user Edits a document from a view, Cancel would return to the view. If a user switches from reading a document to editing that document, Cancel would return to Reading.
In our application CANCEL button calls agent, that unlocks current document and returns into reading mode. Going into edit-mode, document will be locked (for other users no edit-button)
I also think it depends on situation. It is true that the BACK button is a web staple, but I do think this is not a universal law. People are used to the BACK button while browsing, and quite often browsing is associated with looking through a magazine, etc. In short, when referencing BACK is the logical choice.
I think this changes when people start doing transactional style working - such as editing and posting changes. At this time other options become more viable and often expected in some cases.
Now that plenty of folks have had a say, here's what I wound up doing after Jake's consultation.
I replaced my 'Cancel' button with a 'Parent View' button. In the context it's intended (proficient users administering settings of a website) this seemed a good compliment to Submit and Save. Submit saves and redirects to the view. Save does just that and puts you back to read mode. Parent View does nothing but redirect to the view. Close, in the end, seemed too vague to me.
And, I still think Cancel is appropriate, but only in dialog situations. Close is more appropriate for forms if it's expected, with the possible extension of ' without Saving'.
As Don Callaway noted, it really comes down to what the customer is expecting. In my case I'm the customer, but I hope to get others to use it, so I have to do what I think makes sense to the most folks.
I agree that I don't want my web app to look like a Notes app -- most of the web audience has never used a Notes app.
But I think there's a place for the Cancel button <<sometimes>>.
Recently, I finished a web app. At first, I did NOT include a Cancel link on the form, only a "Return to View" link. I didn't think I needed a Cancel button.
But after I used the app a bit, I changed my mind and included a Cancel link (with the "Are you sure you want to cancel your changes?" message)
The biggest reason was that I had all my links nicely grouped together in one spot on the form...I found myself reaching for that menu for every action, instead of the Back button. So, I included a Cancel.
And I agree with Ian about the transactional situation -- In some situations, I think folks are more satisfied that they are able to cancel a transaction instead of just hitting the back button.
My adagium: stick to the standards. It is what people are used to that makes something easy to use. The first cars looked like carriages.
The earliest and most used webforms containing at least two fields on the net were probably the Hotmail or Yahoo email forms. Both have a Cancel button.
The second most used webforms containing at least two fields are maybe MovableType and Pivot for weblogs. Both don't contain in the standard installation a Cancel button, but a Preview button. A Preview button implicitly means that if I didn't hit the Post button yet, nothing is posted yet. Even after previewing, there still is no Cancel button. Since people are becoming more used to the web, standards can shift: cars don't have to look like carriages anymore, but I still prefer a steering wheel above a joystick.
Other reasons for in- or excluding a cancel button:
- how important is the information I enter? If I enter creditcard information to pay, I sure as hell want to have a Cancel button, and mostly there is.
- is the information editable? I don't need a Cancel button on Notes.net, since I know I can edit my entries afterwards.
- do I get, or do I know I will get, feedback on what I entered. With a blog comment, I can immediately see what I entered. Entering some information without seeing the result of it makes me insecure and makes me opt for a Cancel button.
So it all depends. In most cases I would opt for the mail standards of including a Cancel button.
For me it comes down to risk management:
Risk #1:
Placing a Cancel button on a web-form risks losing the work the user entered - because you can't use the Back button to recover from an accidental click of the Cancel button. This risk increases with the quantity of fields on the form.
If we counter risk #1 by adding "Are you sure?" warning messages, then we incur Risk #2: Annoying our users with warning messages. And sometimes a user will click the OK on the warning message without reading it. So even with warning messages, we still have risk #1 (losing work).
Question:
When is it appropriate to place Cancel buttons on a web-form?
Answer:
When they add enough value to the user to out-weigh risk #1 (losing work). For example, popup dialog boxes where the Cancel button makes it easier for the user to close the popup window.