Hello all,
Yesterday evening I tweeted about the idea of Umbraco being to auto save content in the background as you type or blur fields.
This has seemed to have sparked a great discussion on twitter however discussing it on our.umbraco.org is far more beneficial for all.
So what are your thoughts on this, is it a good or bad idea and why?
If you think it's a good idea what would be the bestow ya to implement this, as I personally feel for this to be done right the implementation has to be thoug about first.
My concern about this is (the fact?), that when people edit pages, they often regret it and want to just discard everything. Or perhaps they are writing on a text, mark a part of the text, hit a wrong button that messes up or deletes the text and then in panic accidentally press a button that blurs the field, whoops. I mean, just think of all the times where you pressed something in error and really needed a ctrl-z option. I know that there will be revisions available, but imho, the revision system is not really editor friendly.
I am assuming, that the need for auto save is to prevent users from accidentally leaving a page without saving. Though, what I would much more like to see is a default warning system when you try to leave a page without saving your changes first.
The first thing to think about is wether or not auto saving is good UX for a CMS? There are semantically two things that happen when you save your document. First thing is obviously that the data is persisted. The second thing is that the user confirms his intention to update the document.
Autosaving removes the user intent that tells the system "Ok, i'm done now. Please store this". For example, have you ever tried opening a node, start editing som properties, and the you realize you're not doing the right thing, or (god forbid) the datatype crapped out on you. Today, that is not really a problem, because you just click the node in the tree, and presto, you're back to where you were before.
That option goes away with auto save, because it is effectively "auto overwrite", since a new version of the document is not (and should not be?) created on each save.
Validation
How would validation work with auto saving? If a save is performed on blur, then it would not make sense to suddenly show validation for all fields. That would give a "STFU, I'm not done yet" reaction. But if the user only edits half of the fields, which are auto saved, then he will never know about validation on the other fileds, unless he tries to publish, at which point he might go "WTF, why didn't you tell me this before?". So there needs to be a good way of handling this. Again, the problem is that we cannot get the user intent of "I'm done, validate this document".
Event paradigm
Today we have the save events, and the publish events. If auto save is enabled, then the save events are rendered more or less useless, since the would fire all the time, and the event would not be catching user intent. If the document always aouto saves, then the only user intent we can get is publish, unless a new thing is introduced such as "check in" or similar.
Consistency
What happens with media? Media is not published, but will it auto save? If I have auto save in content, surely media will do so as well? Except, media would be publicly available straight away, and so I need to make sure that I fix all the properties really fast, so they are not in conflict with eachother.
Those are my initial concerns with auto saving content.
Autosave can be a plus, but indeed only if it is revertable by the user (when correcting changes etc)
I would store the changes by autosave in a temp cache or something. Let the end user still click the save button to confirm his/her changes.This has also the advantage that you still can perform validation at that moment, trigger the on save handlers, upload media, ... In the UX this would have to be very clear indicated that some changes are autosaved but still waiting for confirmation by the user.
The autosave would then be in fact a solution for changes that were made and the user browsed away from the page (by accident or delibared). When he/she returns to the page a message can inform him/her that some changes were saved but still needs confirmation. If he/she don't want the changes he/she can click the revert button.
A complete autosave on blur or on type with persistence directly to the database would work contra productive (for all reasons stated in the posts above)
This package stores state in local storage, then prompts to restore it when returning to the page (ie if the browser crashes, power cut, etc). So no autosave, due to versioning, but enables restoring the unsaved changes. This means that if for any reason we lose the server, the local version can be restored later. This is a property editor for rescuing content changes developed by Nathan Woulfe.
IDEA: Auto Save Content in Umbraco
Hello all,
Yesterday evening I tweeted about the idea of Umbraco being to auto save content in the background as you type or blur fields.
This has seemed to have sparked a great discussion on twitter however discussing it on our.umbraco.org is far more beneficial for all.
So what are your thoughts on this, is it a good or bad idea and why?
If you think it's a good idea what would be the bestow ya to implement this, as I personally feel for this to be done right the implementation has to be thoug about first.
Thanks,
Warren
Hello Warren
My concern about this is (the fact?), that when people edit pages, they often regret it and want to just discard everything. Or perhaps they are writing on a text, mark a part of the text, hit a wrong button that messes up or deletes the text and then in panic accidentally press a button that blurs the field, whoops. I mean, just think of all the times where you pressed something in error and really needed a ctrl-z option. I know that there will be revisions available, but imho, the revision system is not really editor friendly.
I am assuming, that the need for auto save is to prevent users from accidentally leaving a page without saving. Though, what I would much more like to see is a default warning system when you try to leave a page without saving your changes first.
Cheers, Mads
UX
The first thing to think about is wether or not auto saving is good UX for a CMS? There are semantically two things that happen when you save your document. First thing is obviously that the data is persisted. The second thing is that the user confirms his intention to update the document.
Autosaving removes the user intent that tells the system "Ok, i'm done now. Please store this". For example, have you ever tried opening a node, start editing som properties, and the you realize you're not doing the right thing, or (god forbid) the datatype crapped out on you. Today, that is not really a problem, because you just click the node in the tree, and presto, you're back to where you were before.
That option goes away with auto save, because it is effectively "auto overwrite", since a new version of the document is not (and should not be?) created on each save.
Validation
How would validation work with auto saving? If a save is performed on blur, then it would not make sense to suddenly show validation for all fields. That would give a "STFU, I'm not done yet" reaction. But if the user only edits half of the fields, which are auto saved, then he will never know about validation on the other fileds, unless he tries to publish, at which point he might go "WTF, why didn't you tell me this before?". So there needs to be a good way of handling this. Again, the problem is that we cannot get the user intent of "I'm done, validate this document".
Event paradigm
Today we have the save events, and the publish events. If auto save is enabled, then the save events are rendered more or less useless, since the would fire all the time, and the event would not be catching user intent. If the document always aouto saves, then the only user intent we can get is publish, unless a new thing is introduced such as "check in" or similar.
Consistency
What happens with media? Media is not published, but will it auto save? If I have auto save in content, surely media will do so as well? Except, media would be publicly available straight away, and so I need to make sure that I fix all the properties really fast, so they are not in conflict with eachother.
Those are my initial concerns with auto saving content.
My 2 cents,
Autosave can be a plus, but indeed only if it is revertable by the user (when correcting changes etc)
I would store the changes by autosave in a temp cache or something. Let the end user still click the save button to confirm his/her changes.This has also the advantage that you still can perform validation at that moment, trigger the on save handlers, upload media, ... In the UX this would have to be very clear indicated that some changes are autosaved but still waiting for confirmation by the user.
The autosave would then be in fact a solution for changes that were made and the user browsed away from the page (by accident or delibared). When he/she returns to the page a message can inform him/her that some changes were saved but still needs confirmation. If he/she don't want the changes he/she can click the revert button.
A complete autosave on blur or on type with persistence directly to the database would work contra productive (for all reasons stated in the posts above)
https://www.nuget.org/packages/Preserver.Umbraco/
This package stores state in local storage, then prompts to restore it when returning to the page (ie if the browser crashes, power cut, etc). So no autosave, due to versioning, but enables restoring the unsaved changes. This means that if for any reason we lose the server, the local version can be restored later. This is a property editor for rescuing content changes developed by Nathan Woulfe.
is working on a reply...