I got two options in my application:
Auto save on close
Confirm saving
I believe both options are obvious in their functionality, but what should I do when the user wants saving to be confirmed, but also wants auto saving on application close?
Should I still ask the user "Would you like to save?" when the application closes or should I not bother the user since he said "Hey, I want to save automatically when the application closes anyway"?
I wouldn't assume that the user always wants to save his changes. I can only speak for myself, but sometimes I open up documents to try something (without saving) and if it doesn't look / work out they way I expected it, then I close it without saving.
I'd say the most common default (what the users are most likely to expect) would be to confirm saving.
On the topic of auto-saving in general, check out this related thread and the answer from Glen Lipka:
In Marketo, the app auto-saves everything. We have very few "Save" actions.
However, interesting side-effect. In the email editor, some users were so panicked that there was no "Save and close" button, that we added one. It's already saved so the button only closes the window, but it made the complaints go away. We have generous feedback saying the information was saved, but it didn't matter enough.
It's an issue of trust really. Did the system hear me? Am I sure that I am sure?
Generally, our sales department considers it a major advantage in closing deals.
Case 1 If your application allows the user to serialize information (e.g. by producing a file which can be manipulated with the file system and other applications), always offer a manual save. And instead of an autosave on close, offer a restore-on-open-after-close-without-saving which does not overwrite the user's file by default. Example: Microsoft Word.
The reason for that: in this case, the user wants to own her information, and to reuse it outside of your application, or at least outside of the application instance which produced it. And while she would hate to lose information in a crash, she would also hate it when she tries some changes, doesn't like them, and finds out that closing without saving does not work to revert her changes. (Yes, we'd all have an easier time if users would use version control systems for all of their documents. But they don't.)
Case 2 If your application manages data, but doesn't allow the user to serialize it (iPad applications and many cloud applications work this way), use autosave on close. You may add a save button for the secure feeling or, on a web application, for cases where the server side of the application may not detect the change immediately. Example: Evernote.
A note on this second case: I can confirm that many users dislike this model, there is close to zero acceptance for it for a cloud application with a desktop client frontend. In 2012, I ran two separate studies getting users to vote on proposed features of an application, and adopting this model was the one most hated feature of all proposed ones in both studies. Some applications can pull it off, especially games, without losing acceptance, but in the general case, it is an uphill battle. It is much more accepted in cloud solutions with a web frontend (example: Remember the milk), or in a mobile context, including Android - despite the fact that it is possible to serialize data as files on Android. If you are going to follow this model, a Save button will really appease your users even if it does nothing, as in Andreas Johansson's example.
Case 3 If your application doesn't manage data, and all a save does is to save the state of the application, let the user choose with a setting whether there should be an autosave or not. If the user chooses to not have an autosave, still offer a restore-state function for when the application exited by a crash and not by the user closing it. Example: Firefox and saving the tabs from the last session.
Case 4 (hybrid) If you have something in the middle between case 1 and case 2, choose which method fits your specific case better. Example Wordpress: Wordpress will let the user create a mostly self-contained piece of information, like Case 1. It can also be serialized if needed, by exporting the resulting web page as a HTML file. But it actually works more like case 2, with the user input being persisted in a database and reused within the application instance only. In this case, there is no general recipe what to offer to the user, it depends on how much you will rely on the file metaphor.
Some relevant info here could be: Why would users want to autosave on close, in this particular app? And why would they want to confirm saving? What kind of app is this?
The normal behavior is asking to save on close, if the user has not saved changes before closing. But most apps like, say text editors, do not autosave your file quietly, even if they are keeping all changes somewhere (in a system file, to be used or recovered as needed). And most do not confirm Save button clicks. So I get curious about the needs of your particular users?
Without more info, I can see two solutions:
A. If the options aren't mutually exclusive, and a user excplicitely has asked for confirmation on save, then you should definitely pop the save confirmation every time a save is about to be done, even when autosaving on close.
B. If you make the options mutually exclusive, so that you can pick one, or none, but not both, I think interaction will be more natural: Users may have the need of never caring about saving things themselves, or they may have a big need of controlling exactly what is written to disk, but it is hard to imagine both needs at the same time.
