I read the article Never Use a Warning When You Mean Undo today, and it got me thinking about the plans I'd laid out for saving and undo before. I think I agree with the premise of the article, but I'm not sure how to apply it to the specific case of closing editor tabs in Moing, or closing documents generally.
Generally, when it comes to open documents in any application, people tend to use editor sessions like transactions: revert/close corresponds to a rollback and save to a commit. So, undoing a close is sort of like undoing an undo...
Provding UI for simply reopening a recently closed tab shouldn't be too hard, but what should appear in the tab by default? The most recently saved version, or a recovered unsaved version? Probably the latter if the "recently closed" UI is used. But otherwise? And what happens with the close confirmation dialog?
Maybe we could simply make saving implicit when the editor pane was closed; it fits well with our "live update" model for editing. The main question then is how we recover the "revert" safety net? "Oh no, I meant to save!" is more common than "Oh no, I messed up and saved over my last good version!" but the latter does happen sometimes. If we can address that one problem somehow, I'd feel pretty confident abandoning explicit saving.
Well, actually ... there's one obvious answer: persistent undo history. Disk space is cheap these days, right? Moing has enough of those "you must be insane!" ideas already; we may as well add one more.
Update: Mike's convinced me to go with our original save confirmation plans for now; doing something slicker well may require support from the OS that we just don't have right now.
2 comments:
This is indeed a tricky issue.
Really I think versioning support in apps should be saved for the time when more enlightened OSes are used.
Perhaps the best thing to do would be to store all unsaved assets, and inquire at startup. Well, maybe not. That'd just delaying the decision.
I can't think of a good solution for this, but the normal dialog isn't so bad.
Well, if we take the idea all the way, there is no "unsaved" asset to store/ask about; it's always saved, and you can always go back in the revision history.
The main remaining problem is whether a detailed revision history might get uncomfortably large. I'm not sure having the users manually prune it is a good solution.
Perhaps you're right -- sticking with the normal prompt isn't so bad, as long as we assume users are habituated to picking the "save" option.
Post a Comment