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.
Remove the cancel with outsaving and...
Jack of all
The Windows standard way, while hugely flawed, is to ask a question and give options for Yes | No | Cancel.
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.
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.
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...
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).
Why is your database application working like Word and Excel and not like a database.
Thanks for the replies, everyone.
The way you save is simple, If the transaction is complete then the data is saved automatically. If it's not then rollback occurs.
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.
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.
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.
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.
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.
Fire your scientists and get smarter ones
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 confusion comes about because diffrent types of apps act in different ways.
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.
Terry B. Barry
Fog Creek Home