Mdt Autosave Manual

[Ambra Piszczek]

Ialways use manual save, as i know when to save, and ive never lost anything in years. And it doesnt matter the game type, the sooner you save after a change, the better. Auto-Save is (to me) an annoyance, an un-needed, redundant, useless task. And the last thing is, do you have source control?.

One thing regarding save systems that drive me nuts is save systems which force a game mechanic to happen at the same time that may not be desirable. As an easy to point to example, farming games like Stardew Valley where you can only save by going to bed, which forces you to jump to the next morning.

I like both but when a manual save has just been done auto save delay should be reset, in some games this is not the case and then it can happen that you save in a difficult situation, you screw up and auto-save comes and deletes your safe point.

I agree, having both options is a good idea. Most of the games I played on the sega dreamcast years ago, had both options. And the auto save feature, would have an on and off switch too, which always came in handy.

At first it is definitely awkward and the user can feel like they have less control, but if widely adopted this could make everyone's lives easier. Of course we should still offer a "Save as" or "Create a copy" type option to allow them to manually save a copy.

If we (Windows and other platforms) do not adopt this new convention, it will certainly create an even larger gap between Windows and Mac users. People who have only used Macs or grow up using them from here on out will not be used to saving. People who use Windows will be driven crazy by Macs (some not all) because they will constantly want to save.

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.

Although the technical objections are largely obsolete, I think there is still a UX-based objection to auto-save. Other answers have alluded to the relationship between versioning and auto-save. @sova talks about them as alternatives, but I believe they are essential complements. Without versioning (or at least persistent, traditional undo), auto-save has an important potential downside.

In a document-based interaction model, all changes to a document are temporary until the document is saved. The ability to close without saving provides a course-grained undo capability, since the user can always revert to the last saved version. This form of undo has very poor usability compared to even CTRL-Z/-Y style undo/redo, but it still gives users a "panic button" safety net. Auto-save takes this option away from users. Without a compelling replacement, this arguably may be a net loss of data safety.

Google Docs and the new OS X Lion versioning feature provide an alternative, more powerful form of undo/redo based on a timeline, rather than the traditional command history stack. Both systems anchor versions to the timeline and allow the user to pull older state ahead into the present in whole or in part. This is vastly better than the single-version revert provided by a manual save document model. This removes the potential downside of auto-save.

@andrew-neely reminds me of another important case. Many business transactions have a significant transition between data entry and execution. The document model is inappropriate in those situations, and another metaphor must be used. However, it is still possible to protect against data loss.

For example, a system might be engineered to restore the state of the UI upon relaunch after a crash or power failure. The user can then choose to cancel or proceed with the transaction without repeating the data entry. Storing the state of the UI is a form of auto-save, but this would be transparent to the user.

A timeline-based history mechanism is also somewhat less appropriate for active editing interactions in this situation. The more traditional undo/redo may be better suited to a UX with short, transactional interactions. The short duration means that managing a command stack will be less of a burden, and the transactional nature means that reverting back past a transition point may not be possible in any case.

Versioning in a transactional system would still be possible, but it would take on a different character. Instead of displaying the full state of the transaction at each point during editing, it might focus on only persistent changes and present them as a sequence of state transitions in an audit log. A transaction is not so much an artifact in itself as a symbol of an ongoing process. A log of transitions better reflects this active workflow nature.

It's partly historical - when saving meant sending data back to the server it was an expensive operation, and when it meant overwriting what you already had without the chance to roll back it needed to be under the user's control.

Google already have auto saving in Google Docs, and now with Apple moving that way there will be a general trend to having autosaving everywhere. If it's in enough places then people will start to demand it.

I suspect that Microsoft will bring it in with the next version of Office - after all OneNote already auto saves, and Word etc. do auto save already, but only to a temporary file. Having it save to the actual document is the next logical step.

One area where it might take longer is database applications where records have to be complete to be valid. Partial saves are possible, but it's not as straightforward as something like a word processor or even spreadsheet application.

First, inadvertent editing (mistakes): If a user brings up a document for viewing and makes a mistake, the auto-save would overwrite the good copy with the invalid data, and require the user to take additional actions to undo the mistake.

We have a data entry system that was designed with auto-save, and I can't tell you how many times records are damaged because somebody's input focus was in the wrong window, and they over-typed the information. It's true versioning and rollback can mitigate this issue some, but it complicates the system, increases storage requirements, and adds additional features the user must learn to use.

Second, Lack of Control: I like the idea of having the user commit writes on purpose. I'm all for Auto-saving to a temp file and prompting the user when they are about to abandon the changes, but I want the user to say "Yea, I meant to do that."

Example 2 I often use notepad to store temporary information I don't wish to retain for longer than a few moments. Auto-save would force me to clean up a mess of these files for no good reason.

Example 3 If I document an issue with one of my subordinates, I prefer to type it as my handwriting is not very neat. If I use a word processor, our HR section only wants paper, and doesn't want me to save the document anywhere. If I save the document, then the whole computer (or network) is open for discovery in case of a grievance.

Example 4 Often, when copying formatted data from one source to another, I will copy the data to notepad to strip all formatting, the copy it again to paste into the target document. I don't want that information to be saved.

Second thing to note is the modeless feedback given. The user needs to be able to see that whatever she is working on has indeed saved. Google documents does this better than any interface I have ever seen.

Third is the "Save now" feature. If I need to go do something I don't want to have to wait until the document blinks a "I just saved" at me, I want to know that it was saved before I continue. Regardless of weather the software will definitely save if I navigate away to something else or upon it being closed, I want that "I know this is saved" feeling.

Fourth, beyond Save A Copy there should be rename functionality. If you have a word document open and want to name it something else, you have to close the document, go to the file and rename it there. That functionality should be provided where I can get at it easily.

And finally, you should always preserve the undo stack across sessions so that I can undo forever even if I close the program/browser and then open it back up in three months and realize something I didn't want was saved.

I think users are becoming more comfortable with the auto-save and I definitely have been personally relieved when a program crashes and I know I haven't lost anything because all of the saving has been taken care of for me. So to summarize, read the About Face section on this and check out Google Docs.

Every one talks about it from a document point of view. Your question states "should everyone start adopting the convention of auto-saving?" I have to agree with others that if you don't offer versioning, it's useless. To me, being a photographer, autosave alone would be the worst feature to have ever existed. We sometime spend hours "destroying" a picture in Photoshop to find out that we made to much, scrap everything and start again.

That much holds for any creative field I can think of. When you create, you often experiment, and you have to have the option to go back to the original quickly if you realize you don't like what you've done.

I don't think this has been mentioned by anybody, but one instance when you must NOT implement the Auto-Save functionality is when you're working with files opened from a USB memory stick. Although not widely known, but USB drives have a very limited amount of read-write cycles, sometimes as low as 3000-5000 (see Wikipedia: USB flash drive)). If your application saves often, say every second, it would essentially destroy the user's device within an hour or so.

3a8082e126