AutoSave

Rationale

Since UsabilityDesignPatterns/LosingMyData is the worst thing an interface can do, it follows that it should do everything it can not to lose my data. Why risk the user forgetting to click "Save" - just automatically save at regular intervals.

With sufficiently good autosave, you can even phase out the "Save" command from the interface (See UsabilityDesignPatterns/NothingLeftToTakeAway). That's good because you can get rid of the "Are you sure you want to quit without saving?" UsabilityDesignPatterns/ConfirmationDialog and its three fear-inducing options.

Pitfalls

"Save" really means "Destroy one version, save another". The ability to choose 'not' to save, the "Save As" command, and the "Revert" command, all speak to the need to sometimes get back to an earlier version. If you provide autosave, then you need to also figure out how to let people get back to earlier versions: either the autosave needs to save to separate backup files (perhaps a ring buffer) or you need to provide a method of rollback such as UsabilityDesignPatterns/InfiniteUndo or some form of version control. The action of saving particular milestones could then be replaced with tagging those versions.

Teaching New Users

Many users have a habit of hitting "Save" as often as possible. This is comfortable. Taking away the "save" button creates a feeling of unease because the user doesn't know whether their work is saved or not. So you need to find a way of communicating to people that their work is already saved for them.