Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at

  • Warren Buckley 2106 posts 4836 karma points MVP ∞ admin hq c-trib
    Jan 10, 2014 @ 09:33
    Warren Buckley

    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 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.


  • Mads Krohn 211 posts 504 karma points c-trib
    Jan 10, 2014 @ 09:47
    Mads Krohn

    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

  • Morten Bock 1867 posts 2140 karma points MVP 2x admin c-trib
    Jan 10, 2014 @ 09:57
    Morten Bock


    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.


    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.


    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.

  • Bart De Meyer 4 posts 54 karma points
    Jan 10, 2014 @ 10:45
    Bart De Meyer

    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)


  • DeveloperSha 2 posts 71 karma points
    Feb 06, 2020 @ 05:14

    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.

Please Sign in or register to post replies

Write your reply to: