User Interface (UI) / User Experience (UX) · Articles & templates · Created by
Krystalyn
closed
autosave user-experience
Hear me out before throwing negative points my way, okay? I've put a lot of thought into this and I'm really trying to cover all the bases to make as many people as possible happy with this.
Auto-save is a wonderful thing. Most of the time, I love it - it keeps me from losing work if my browser crashes or my computer restarts overnight. It saves me a click when I'm done working on something. It saves me from my own forgetfulness. Overall, it's really great, and I am NOT trying to say to get rid of it. Not even a little bit. I simply feel that allowing users more control over when and how it performs would be beneficial.
I am suggesting a fairly substantial overhaul of the auto-save functionality, with a few sub-parts. Plenty of us have had the auto-save functionality backfire, and some people just don't like not having control over how their content saves. So, in order of my own personal preferences, a few potential changes that I think could lead to some great quality-of-life improvement of the auto-save function:
1) Add an option for user-defined save intervals. - With how often the auto-save triggers now, I imagine that might be a fairly large load on the server. I'm not sure if it would be more or less of a load to have multiple different intervals, but I feel like it would be a lot less pressure if you could select to only save every two minutes, or better yet after a certain number of keystrokes, rather than the current state where it seems to save every time you type a single letter. Again, I do overall love the auto-save function, but for me at least the frequency can be panic-inducing – "Why are you saving? What did I just do? No, wait, I didn't mean to do that!" This is the reason I turn it off in literally every other program I have used that offers an auto-save option, even if it has the potential to turn around and bite me later. I personally need to be satisfied with something before it is in any way accessible by someone else, even as limited a someone as a single co-author on a private world who can clearly see something is still a WIP Draft.
2) The ability to turn it on and off. - One argument I've seen against this is that someone might forget to turn it back on. While that would be unfortunate, I don't entirely understand this argument - no one is forcing someone to EVER turn it off, but we are currently being "forced" to keep it on even if we don't want it. I am a strong believer in being given a choice in the creative process. So, I offer a "best of both worlds" solution – an article-specific toggle on the edit screen. Just like the Draft/Published and WIP/Done toggles, make it article specific where you can set an article to no longer auto-save once you feel it is "complete". This toggle would have auto-save on by default. Like "Draft", this should be red in color or otherwise stand out significantly when auto-save is disabled so that you clearly and immediately see that you will either need to change the toggle or save manually if you do make changes you want to keep, reducing the risk of someone forgetting to turn it back on.
3) Add a changelog. - Again, I've seen arguments against this and I do acknowledge that this could be a large amount of data and may just not be possible. But hear me out. Maybe the below might be ways to keep it minimal:
- Add a button for manual "archiving" if you know it will be a significant change and you want a chance to compare old and new prior to "accepting" changes. Alternatively, only add it to the changelog if the Save Changes button was manually used – since the auto-save happens so frequently, obviously you wouldn't want every single iteration in a giant database.
- Only create a changelog entry for a specific section of the article if the change was more than x words/characters – this would protect you from accidentally deleted paragraphs, but would again prevent excessive backlogs for minor edits.
- Allow Importing of Exported articles. I sometimes see people who are against a changelog suggesting to write in an external program and then copy into World Anvil, but that totally defeats the purpose of using World Anvil in the first place. It also makes it more difficult for people who use template specific prompt sections, as we either miss out on using them or else have to take that much more time to split our text out into the appropriate sections later on. You can write the initial iteration of the article, then export it in its current state, but if you export, make changes, then want to revert it to the initial state after making changes, you must do so manually. Since headers on the editor vs the export are not in the same order, it is not always clear which subsection a prompt is under, and BBCode is not included in the export, this can be complicated for very large/detailed articles. If one could import an unmodified export, either to completely overwrite or to bring up a sort of comparison tool and choose which sections to keep, this would mean no on-server backups but also less work for people who decide they do not like the changes they've made or who accidentally delete something they wanted to keep. This would, however, probably take the most amount of coding, especially if there is a comparison option.
- Implement a time limit for retaining article history – 24 hours, 1 hour, until the end of the current session, anything really would be fine to me. Additionally, prompt for a manual wipe – when you navigate away from an article's edit screen, prompt the user to confirm that they no longer need the article history and/or to download the changelog to save on their own computer rather than on the server (and give the user a setting that allows them to disable this prompt, which would then always wipe the history upon navigating away).
Once more I want to reiterate that I am so grateful that auto-save exists, and I don't want it to go away. If you like it in current state, great! But before downvoting, please consider that my proposed changes would not prevent you from continuing to use it as it currently works. I simply ask for more agency in how it performs for users who might want it to behave differently.