Fog Creek Software
Discussion Board




What should I name this button?

Hi all. I am developing a little database application and having trouble with the wording of a "Cancel" button. I have this form set up so that if the user clicks the "X" button at the top-right of the window, they get prompted with a "You have unsaved changes. Would you like to save them?" (so it behaves like Word, Excel, etc.). I ALSO have a button on the form for cancelling without saving [users are used to it this way -- who am I to argue?]. Anyway, I normally would name the button "Cancel". BUT when the prompt comes up upon hitting the "X" button, it uses the term "Cancel" to mean that it should cancel the close operation (i.e. go back to the form -- don't close it). I have no idea what to call the button. Calling it "Close" might imply that some saving is going on. I don't want to call it "Save without Closing" because that's lame. For the time being, I am just calling it "Forget It", which, while accurate, is not very "professional" sounding.
Anyone have any suggestions?
Thanks.

  -Jordan

Jordan Lev
Friday, May 07, 2004

Remove the cancel with outsaving and...

You have unsaved changes. Would you like to save before closing?

YES | NO | CANCEL

Jack of all
Friday, May 07, 2004

The Windows standard way, while hugely flawed, is to ask a question and give options for Yes | No | Cancel.

If you were writing for a Mac, your buttons would be: Don't Save | Cancel | Save.

Rhys Keepence
Friday, May 07, 2004

Perhaps "discard" is the word you're looking for?  Although I am beginning to think more verbose button titles are the way to go.  How about "Close and discard changes"?  I used to like everything to be short and 'efficient', but I realize that's doesn't make a lot of sense from a usability perspective.  We have more screen real estate nowadays anyway.

A dictionary and theasaurus is a crucial tool of any developer. http://dictionary.reference.com/

blank
Friday, May 07, 2004

I'm not a MAC user but I'm in for Rhys' suggestion. SAVE | DON'T SAVE | CANCEL is a fine way to do it.

Peter Monsson
Friday, May 07, 2004

Jack of All has it right. Word and Excel don't have Cancel buttons, let the user Close and ask if they have unsaved changes. You can improve the Windows behavior if you let them recover the changes even if they accidentally close without saving; but that would be getting more like something you'd find on a Mac...

Tom H
Friday, May 07, 2004

I think your best bet is to stay conventional. You are explaining to us that "Cancel" would be confusing because if the user hits the X button another cancel button will come up with a potentially confusing different action. What about the user who hasn't yet hit the X button? Maybe he never changes anything or always saves first. Why should that poor guy have to spend 2 seconds wondering why your cancel button says "Forget It"? I say stick to the most common convention. If you must have a cancel button on the form, it should say "Cancel". If the user hits X and has unsaved changes, do something like, "Do you want to save changes?  Yes | No | Cancel" because that also follows Windows convention. If the user has used Windows enough, the user would know that cancel in this context means to cancel the last operation (i.e. closing the window).

David M
Friday, May 07, 2004

Why is your database application working like Word and Excel and not like a database.

You don't need to save data changes in a database, and any application that requres it is going to be a disaster.

Stephen Jones
Friday, May 07, 2004

Thanks for the replies, everyone.
I like the idea of a "Discard" button (and I never even thought to look in a thesaurus!).

As for the "Save | Don't Save | Cancel" option, while I agree with Apple's convention that button labels should be action words, this is a windows application, and hence I think it is better to go with the consistent "wrong" approach, than the strange (to these users) "correct" approach.
And Stephen -- I disagree that "you don't need to save changes in a database". If the user runs a query to find customers, for example, and notices that they need to change a phone number, they click a button that says "Edit Data" (or shortcut keys/right-click/menu/etc.) and a little form comes up with the customer's information to edit. Sometimes they want to cancel the changes because they need to go do something else. As far as "any application that requires it is going to be a disaster", well, this is actually a specific request from the users because they are all used to using Word/Excel/etc. where you can get away without even knowing about the "Save" button/Ctl-S because whenever they hit the "X" button, they get prompted to Save. Previously, some people were thinking they saved the data when actually they were cancelling out of it! This is their application, not mine, so who am I to argue?
But I am curious -- how do you handle these situations without having a "Save" command or button?

Thanks.

  -Jordan

Jordan Lev
Friday, May 07, 2004

The way you save is simple, If the transaction is complete then the data is saved automatically. If it's not then rollback occurs.

As far as changing the telephone number comes you would save the changed data automatically when you changed to the next field. or exited the record.

What your customers are asking is a way to make sure they don't close without saving. Make saving automatic and the button won't be necessary.

Stephen Jones
Friday, May 07, 2004

Therin lies a problem which exists w/ more than just databases.  If you save data based on a field exit, then what happens if the application closes but the field has not been exited?  Your data winds up disappearing.

I ran across this with Java's JTables.  Users would enter data into a row, however unless they clicked off of the cell or table into a new field, then the data wasn't saved.  So if the user clicked the "X" button, then the field never had a focus change (the I bar is still flashing in the field) and thus it didn't update.

Now this may just be a java problem, because in my eyes when you clicked on that X, you just changed your focus, and thus the save should occur, but alas it didn't.  Fortunately I didn't write it, and I didn't have the pleasure of debugging it so I can't give many specifics. . .

Elephant
Friday, May 07, 2004

In fact it isn't Java specific - both Access and SQL Server Enterprise Manager seem to do roughly the same thing. Although they *do* appear to commit the change when the window is closed, if you just change a cell and then leave the window open you don't see the change unless you move your insertion piont top another row form the one you just changed.

Steve Holden
Friday, May 07, 2004

I *hate* it when the computer questions me for stupid things like this... If I am about to make a mistake, it makes sense I guess, but if I am not making a mistake 99% of the time, it is an annoyance.

If there are unsaved changes, then save them to a temp file like <nameofthefile>.<ext>~ and if pop up a message box telling me that the unsaved changes have been saved to <nameofthefile>.<ext>~ in case I need them. This way I don't have to make a (stupid) decision. If I care to go back to my unsaved changes, I will use the saved temp file.

grunt
Friday, May 07, 2004

You know, the whole idea of explicitly saving has always struck me as slightly dumb. I'm currently building an App for OS X where in the user can independently edit fragments within the containing file. These fragments appear document-like; but do not have an explicit save option, nor is there any double guessing a closed window. The on-disk version of the fragment is always kept up to date and includes sufficient information to undo actions from a previous editing session.

So far, user testing has shown this to be more natural than the explicit save model. I have often noticed that users are confused about why they can't undo changes from a previous editing session in applications like MS Word.

Jeff Watkins
Friday, May 07, 2004

Can anyone provide links to research (actual data) on user actions with a "Save" button?  My personal observation is that scientists around here are very uncomfortable with auto-save that never gives them a chance to press a "Save" button.  (EndNote, FileMakerPro) They don't trust that data are saved, unless they explicitly do so.

We had the same problem with a Java app and fields not saving unless the cursor had moved.  I think the developer in that case made it so the text of the field would turn pink when you edited it, until you had clicked elsewhere to "commit" your changes... that way you could see at a glance "it's still pink, it's vulnerable/not saved".

Biotech coder
Friday, May 07, 2004

Fire your scientists and get smarter ones

no good
Friday, May 07, 2004

Jeff - nice approach. With disk space and processor power becoming so cheap, I can see the save button becoming extinct within a number of years.

The Java IDE that I use, IntelliJ IDEA, also works in this way. The entire history of a file is stored in some type of internal SCM system, in such a way that you can view, diff and rollback between various versions. It also performs saves on the go.

Rhys Keepence
Saturday, May 08, 2004

The confusion comes about because diffrent types of apps act in different ways.

Databases normally commit automatically. Most don't write direct to disk but to a buffer in memory, and the final result is committed when the window closes or whatever.

With Word or Excel it's different. When you open a new document or spreadsheet there is no file location specified so until you have saved it once and  specified where the document or spreadsheet doesn't actually exist. Also you are likely to open a large document, start it, and then leave it unfinished - in that state you won't want to override the previous version. Also you sometimes open a document with the intention of using it as a template so you won't want your other document overwritten.

The problem comes when a contenr management system or whatever mixes up the two paradigms.

Stephen Jones
Saturday, May 08, 2004

Alan Cooper wrote up a strong plea against Save /  Save As...  and Yes / No / Cancel in his most recent book "About Face 2.0." He recommends you ditch the message boxes and write your software so it autosaves and saves on demand, with smart undo and smart defaults in case you want to back up to a previous version.

The terminology he recommends for what you are looking for is "Abandon Changes." Cancel is ambiguous.

Terry B. Barry
Monday, May 10, 2004

*  Recent Topics

*  Fog Creek Home