The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Handling Cancel buttons in a web appp.


Thursday, September 09, 2004
 
 
Looking for thoughtful feedback on "best practice"...

The situation
=============
In my web app there is a list of companies. The user clicks on one to go to an "Edit" page/screen. After completing the edit the user clicks "OK", the data is saved, and the user returns to the list of companies.

Company List --> Edit Company --> Company List

So far, so good...

The client wants a "Cancel" button too. This goes straight to the list of companies without saving. (Note: It doesn't use the brower's history)

The problem
===========
A tester said if the "Cancel" button is clicked and the user will be losing changes (ie, the data is dirty) then as per stand-alone apps, the user should be asked if they want to discard changes.

Is this worth doing? Ultimately the user can close the browser, click on links, use the "back" and "forward" buttons and lose their changes and I don't think I can trap that. So is it worth being clever on the "Cancel" button?

PS
==
* Would you use a different design?
Herr Herr Send private email
Thursday, September 09, 2004
 
 
It doesn't sound like a big deal to have a little javascript popup window ask for confirmation. You can't catch every way the user can leave the page, but you can fix what your client considers a significant potential problem.

That said, I'd take a close look at the requirements and see if this is an increase in scope (i.e. who pays for your time to make the change); I really don't getting requirements changes from a tester after the code is written. It becomes an endless loop of "that's nice, now I want this and this and this..."
Tom H
Thursday, September 09, 2004
 
 
I use this event in my buttons (normally submit buttons) to confirm an operation.

onClick="if(!confirm('Are you sure?')) { return false; }"
Matthew Lock Send private email
Thursday, September 09, 2004
 
 
Actually most dialog boxes on Windows don't bug you if you hit Cancel with some changes.

DOCUMENTS prompt you if you CLOSE THEM without saving.

The difference is that you really may have put a lot of working into composing/editing a document, but a dialog box with a couple of small fields is no big deal to lose.

I don't think anyone has an expectation that a button labeled CANCEL will prompt to save changes (except your tester), and this can be really irritatating if you're hitting cancel because you got into the dialog by mistake.

If the screen has a lot of stuff to edit, instead of Cancel/OK change your buttons to "Save" and "Exit Without Saving" or something like that, then Exit can prompt.

If the screen is like a dialog with a few small fields, do OK/Cancel without prompt.
Joel Spolsky Send private email
Thursday, September 09, 2004
 
 
Do NOT use Cancel buttons in a web app unless, God forbid, you're displaying your form in a pop-up.

In a desktop app these are necessary because there's this new dialog window in front that needs to be canceled. But there's nothing to cancel on a web page - user will just click a link and leave.
Egor
Thursday, September 09, 2004
 
 
It depends on the data you are collecting, and the likelihood of your users spending a lot of time crafting the data that is going into your input fields.

For instance, we have a project management application where the user can enter comments as they make progress on a given project.  The field is timed, so users tend to leave the page open while they are doing whatever.  Some write part of their comment, do some work, write more of their content etc.

Before we added a "are you sure/do you want to save this data" if leaving that screen, there were a couple of instances where a user would spend several hours entering stuff without saving, only to lose the whole shebang when they accidentally clicked on something they didn't mean to.  So our rule of thumb now is that if the form contains a text area or if it is time consuming to fill out, then *if the data has changed* we prompt the user to save. We also frequently add Javascript to disable the "back space = back in the browser" button because we've had so many reports of users inadvertently changing their focus, beginning to type, inevitably hitting the backspace key and losing the page altogether.

Incidentally, someone commented that you can't catch every way a user can leave the page - but I would dispute that.  There are tricks you can use to prevent accidentally leaving the page if that is important - for instance in one of our applications (inventory management), the user should not simply quit entering a job order in the middle or they will end up with a disfunctional job order.  So when creating the job order they don't have access to the navigation, only the job order creation information, the back button and a cancel button. And the back button can be disabled or trapped to act as a cancel button pretty easily.
Phibian
Thursday, September 09, 2004
 
 
I'm sorry, but having to rely on tricks like this to make web application work is a sure sign of fundamentally broken design.

"user should not simply quit entering a job order in the middle or they will end up with a disfunctional job order"

What if their browser, or another program, crashes, and they have to just reboot the machine? Or someone just pulls the power cord while walking by? A disfunctional job order every time this happens, or are there "tricks" too?

Phibian, there's a nice little feature called transactions. For which your pathetic messing with JavaScript is a poor substitute.
Egor
Thursday, September 09, 2004
 
 
Is the wet and cold getting to you Egor?

"Messing with Javascript" provides some client side error trapping, not to mention a clear path through the application, which can be nice ;)

Obviously that doesn't mean that you only rely on the client to handle errors...

In the case of the job order, simply rolling back the transaction isn't good enough because the real problem was that the user didn't always realize that the job order process hadn't been completed. So then you have a job order that doesn't exist and a user with a clear memory of "creating it".  Which leads to frustration all around. I guess I could have said that but didn't think it really had anything to do with the original discussion (which after all, was discussing a client side feature...)

I still maintain that prompting the user when "cancelling" a transaction can avoid user confusion and frustration.
Phibian
Thursday, September 09, 2004
 
 
++The client wants a "Cancel" button too. This goes straight to the list of companies without saving. (Note: It doesn't use the brower's history)

ack, not a fan of this.  if he clicks cancel, there should be a popup verifying his request, then changing the contents of the edit box back to what it was before.  unless he clicked save/ok during his edit: in which case, revert back to the save point.

clicking cancel and returning to the listview makes you wonder if the changes were implemented or not...
Kenny Send private email
Thursday, September 09, 2004
 
 
+++In the case of the job order, simply rolling back the transaction isn't good enough because the real problem was that the user didn't always realize that the job order process hadn't been completed.+++

So what's wrong with making them realize that - by just noting it in plain English? Bold red font, if necessary. Why treat people like idiots and cripple their browsers? Not to mention that you need to be extremely creative to obfuscate such a common process as placing an order this much.

+++I still maintain that prompting the user when "cancelling" a transaction can avoid user confusion and frustration.+++

I'm not disputing that. If you can do it without resorting to trickery - fine. If not, you need to rethink your interface, and maybe read a basic book on web usability. There're tons of good examples of how to organize this kind of thing properly.
Egor
Thursday, September 09, 2004
 
 
Egor is somewhat right. In a web application the "Cancel" button is equivalent to leaving a particular screen without hitting the "Save" button.

This behviour is induced by the stateless nature of the request-response protocol at the foundation of any web application.
Dino
Friday, September 10, 2004
 
 
Egor--user's don't read.

BTW, the OnUnload event (or some such name) seems to work pretty darned well for trapping all the way a user can leave a page, at least in IE. You then cancel the event if the user says "oops", and the page doesn't navigate/the window doesn't close/etc.

Cancel can be useful because people are used to that model--it has a different meaning than 'just navigate away' because that might include some hidden autosave.
mb Send private email
Friday, September 10, 2004
 
 
Displaying a message after the fact is not what I call user friendly. ("oops - you goofed and lost all your data - ha! ha! sucker...") 

A cancel button inside a web application is handy because it provides more functional navigation for the user.  The browser "Back" button is unfortunately not programmable and in a web application of any complexity you are inevitably going to run into a situation where the user doesn't really want to return to the previous "page" but actually wants to go back to the previous menu.  In some cases, if the user goes "Back", there is a risk of duplicate entries.

Given that users often appreciate the provision of alternate navigation (such as cancel), but dislike losing data without warning and don't always realize when they haven't saved, we always prompt if unsaved data exists and the user is leaving the page.

Also, we have users that haven't figured out that the back button can be equivalent to cancelling a transaction.  "It's called 'Back'.  I don't want to go back - I want to cancel."  I kid you not.
Phibian
Friday, September 10, 2004
 
 
+++Egor--user's don't read.+++

They DO read, they just don't read everything. If they didn't read, they wouldn't be able to use websites. Getting an important message stand out and read isn't difficult, if the interface is clean and well thought out. But I agree that crippling the browser is surely easier and can be hooked up to any broken design in a second.

+++Cancel can be useful because people are used to that model--it has a different meaning than 'just navigate away' because that might include some hidden autosave.+++

When I'm using a website, "that model" is just the model of browsing the Internet. I don't think I ever seen such a "hidden autosave" anywhere, and I've placed hundreds of orders in a variery of online stores. So  really I don't see where you got the idea that this should be of concern.

+++In some cases, if the user goes "Back", there is a risk of duplicate entries.+++

Such cases are just a sign of developer's professional incompetentce. Some of us just don't bother to learn how to use POST, GET methods or redirects to create a proper web interface. Why do you think a POST-requested page is handled differently by the back button? HTTP spec will explain that to you, if you take time to read it.

The fact that browser "Back" button isn't programmable is a very fortunate one. Messing with right click and browser status line that amateurs love so much is enought of an irritation.

+++Also, we have users that haven't figured out that the back button can be equivalent to cancelling a transaction.  "It's called 'Back'.  I don't want to go back - I want to cancel."  I kid you not.+++

Then I would suppose that the wording in other interface elements isn't clear enought. The text of submit button should make it clear that the action will only happen (begin) after it's pressed. If it's just "OK", or "Next", I can see it creating the confusion you describe.
Egor
Saturday, September 11, 2004
 
 
HTML was never originally intended to have forms or data input any more complicated than a few fields, mostly text and generally with a computer literate audience.

Forms in HTML are broken, no matter what you do to try and manage statefulness some gotcha will always get you at some point.  All you can do is minimise that.

If you use cancel the chances are that the user won't expect you to save the state, though if they hit cancel and they didn't mean to you can be sure it will be the form that they'll blame and not themselves.

So then its a question of whether its worth the work and possible annoyance of users who know perfectly well what they did and where the blame lies.
Simon Lucy Send private email
Sunday, September 12, 2004
 
 
"Displaying a message after the fact is not what I call user friendly. ("oops - you goofed and lost all your data - ha! ha! sucker...")  "

What is that a propos of? Certainly not the onunload event--that's a cancelable event.

E.g. on my form, if you navigate away for any reason (you hit the cancel button, close the window, IE decides that it wants to re-use the window), you get a dialog saying "do you want to lose your data?". If you say NO, then you don't lose your data, the window stays open where it is.

No, it's not ideal, especially since my dirty bit is very crude and gets set when you go back through the nav stack and it's not worth the effort to fix it (though possible). Yes, it works.

BTW, I agree that 'cancel' is the same as 'navigate away', but as someone points out, web *pages* and web *apps* really aren't the same thing, so you must make allowances for this.
mb Send private email
Monday, September 13, 2004
 
 
"What is that a propos of? Certainly not the onunload event--that's a cancelable event."

I didn't think onunload was cancellable?  What keeps advertisers from using that to preventing ad windows from closing?
Almost Anonymous Send private email
Monday, September 13, 2004
 
 
Someone mentioned that it would be annoying for a user to get a popup message if they got to the page on accident.  I agree with that.  One way to deal with that would be to use a little more javascript to detect if any of the fields were actually changed.  If so, set a flag variable.  Then on the cancel event you first look for the flag, and if it wasn't triggered, cancel without any popup.

Of course, this would also depend on the scope of your target audience.  I try to avoid using javascript that isn't completely necessary (read: nice to have but not crucial) on an app that will face outward to anyone on the internet.  If its on an INTRAnet and you know that the browser will be standard, go for it.  If its external, I would say this "feature" is not so important that you should make it rely on javascript.
Clay Whipkey Send private email
Wednesday, September 15, 2004
 
 
I think that if a pop-up is displayed when the user is leaving a changed, but unsubmitted form, most will find it annoying.

Every web-based software I have ever seen just forgets unsubmitted input, with message boards being a good example. Hotmail and Gmail won't bug you for that. Some designers just don't get one very important law of web usability: people spend 99% of their time on sites other than theirs. And consistency is critical to ease of use.
Egor
Wednesday, September 15, 2004
 
 
I've been out of town so maybe no one is following this anymore.

But I thought I should point out that the comment "people spend 99% of their time on sites other than theirs" doesn't always follow.

Going back to my inventory application example, our users tend to have it open all day, and most use it more frequently than email (and no, that doesn't mean they are infrequent email users).  The fact that it is a "website" is not that relevant to the users. They think of it as an application and not as a form that you fill out on some random website.
Phibian
Friday, September 17, 2004
 
 
If it's being used like a standalone app, then for god's sake make it one. The whole point of an app being web-based is moot in the scenario you are describing.

The main advantages of web apps are lack of need of installation and platform independence. But the price for those is heavy: several times slower development speed, crappy UIs, and insufficient control on the client side. If you're doing inventory management all day (as a job, I'm assuming), I don't see how this trade-off would make any kind of sense.

I've seen in-house web developers spend weeks on what would have taken a half-decent Delhpi coder days. And, of course, still not coming close to the ease of use of compatible desktop app. "If all you've got is a hammer, everything looks like a nail" syndrome at its finest.
Egor
Sunday, September 19, 2004
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz