Wikimedia Meta-Wiki

Community Wishlist Survey 2023/Editing/Auto-save feature

< Community Wishlist Survey 2023 | Editing

Auto-save feature

  • Problem: When making larger edits, and in particular writing new articles, there is a possibility of data loss (possibly a few hours worth) due to:
    • a power outage,
    • a browser crash,
    • a network outage (if one chooses to preview their changes while network is temporarily offline),
    • accidental browser closure.
It is a fairly standard feature in modern software to auto-save user edits to guard against such incidents. Auto-saving is ubiquitous in cloud-based software, where it has the added (or perhaps main) benefit of allowing the user not to think about saving their work/to carry on working on the same document in multiple sittings/across multiple devices. (This would arguably be desirable to have on Wiki in its own right.) "Offline" software also often has an auto-save feature, though generally for crash recovery only (e.g. LibreOffice).
The code editor does not currently provide any kind of auto-save functionality, while the Visual Editor appears to have some sort of auto-save implemented, or so I gather based on phab:T57370 (I do not normally use Visual Editor, so cannot tell whether it is indeed present; if it is, then it appears to be both undocumented and hidden, with no indication in the UI that anything is being saved - so almost as good as if it wasn't there at all).
Some workarounds that users, especially those who have experienced data loss in the past, are likely to employ include:
  • periodically copying their work from the Wiki editor to an external program (e.g. Notepad) and saving it locally;
  • writing whole articles in an external program and only copying them into a Wiki editor once ready;
  • writing their article in their sandbox and saving regularly.
Each of these is inconvenient/time-consuming/decreases productivity.
  • Proposed solution: A reliable auto-save functionality which regularly saves user edits in the background, which works both in the code editor and the Visual Editor, which allows these edits to be restored in the 4 cases listed above.
Desirable:
  • An indicator in the UI of the editor which tells the user if or when the page they are editing was last saved - to reassure them that auto-save is indeed present and functioning, and thus they do not need to resort to any of the workarounds mentioned above.
  • Saving these edits online (to Wiki servers), so as to allow the user to carry on working on one page in multiple sittings/across multiple devices. (Just to clarify: until published by the user, these edits should remain private and not visible to anyone else than the user in question).
  • Who would benefit: All editors, but in particular:
  • those who write larger articles, and two groups which, I believe, Wikimedia is particularly keen to recruit/retain:
    • new editors, who are likely to be particularly discouraged if their hard work is lost,
    • editors in countries, where power outages/"load shedding" occur frequently, which are disproportionally likely to be in the Global South (such as India or South Africa, if media reports are to be believed).

Discussion

  • This already exists in the visual editor and 2017 wikitext editor, as a client-side only feature. Clearly it's not obvious though! The part of the request to extend this to the 2010 wikitext editor seems reasonable. Saving private drafts to the server is a really huge legal problem for obvious reasons. Jdforrester (WMF) (talk) 18:10, 25 January 2023 (UTC)[reply]
    • But it doesn't work (at least for me) when browser crashes or on power outage. It only seems to remember small changes, mostly when you don't need them - additionally you can't deny them, because they're automatically restored. Some more reliable process should be developed, even a manual one. MarMi wiki (talk) 20:32, 10 February 2023 (UTC)[reply]
    • I think that the major changes we could make to the existing autosave (without talk-to-Legal repercussions) are to add UI so it's more user-visible that it's happening, and to make it more durable -- it's currently in SessionStorage (which means it's great for the "oops I reloaded the tab / navigated-away / my browser crashed" cases but not for anything where you later come back in a different tab), which we picked because it mostly avoids us having to care about the many limits on LocalStorage. However, the new mw.storage API got added very-recently and automates this sort of expiry-needed case which might make it more appealing to use for us.... Adding it to WikiEditor is of course doable, albeit as an entirely separate implementation. Promoting 2017 out of beta (even without changing any defaults) would be another way to make this more accessible with minimal changes needed...DLynch (WMF) (talk) 19:05, 25 January 2023 (UTC)[reply]
      @DLynch (WMF) @Jdforrester (WMF), two questions:
      1. Is there something I need to do to turn this on in the 2017 wikitext editor? My drafts don't persist following a browser crash.
      2. For making it "more user-visible", is that something that an existing team would take on without needing a community vote?
      czar 22:13, 29 January 2023 (UTC)[reply]
      @Czar I don't know for sure, but it sounds like you might have a browser config/extension set that is clearing your local storage (inside your browser), which is where the draft is saved. There's no MW/VE preference involved. On the second point, I can't speak for the Editing team's planning, sorry! I imagine things will be clearer around what each team are doing once the Foundation's annual planning process is complete. Jdforrester (WMF) (talk) 17:08, 30 January 2023 (UTC)[reply]
      @Czar, you'd have to turn on the 2017 wikitext editor to get its features. It's the not-so-new "New wikitext mode" in Special:Preferences#mw-prefsection-betafeatures. Whatamidoing (WMF) (talk) 17:51, 31 January 2023 (UTC)[reply]
    • We have recently merged a patch to move to LocalStorage for DiscussionTools' reply tool which will be an improvement. The problem for doing this in full document edits is we have to store the original document state (to avoid data-parsoid corruption) which could be several hundred kb. Multiply this by a few edit sessions and you could quickly overwhelm the low limits on LocalStorage (a few mb). If we could find another way to reliably stash the initial document state, this would be fairly trivial to switch over to. ESanders (WMF) (talk) 12:33, 26 January 2023 (UTC)[reply]
      Also note that LocalStorage is used for caching ResourceLoader modules (ie. CSS/JS). Given it usually has low quotas (5MB or such, and even that might be shared between sites with the same parent domain), storing article drafts there would reduce the amount of CSS/JS that gets cached, and potentially hurt site performance. Tgr (talk) 00:19, 5 February 2023 (UTC)[reply]
      I noticed a clear improvement on Discussions. Chrome can suspend a tab, or I can open the same talk page in a new tab, and my reply will be there in the edit box. Extremely nice. DFlhb (talk) 00:24, 5 February 2023 (UTC)[reply]
    I don't think the reasons for not wanting to do that on the server side are all that obvious, so it might be worth spelling (one of?) them out: server-side data storage can be shared between multiple users by sharing account credentials, and that can be used for all kinds of illegal activities. This has happened in the past with similar features. Tgr (talk) 00:22, 5 February 2023 (UTC)[reply]
    I had a Safari crash which lost me hours of editing, with the Visual Editor; it's still not bullet-proof enough. If you can figure out how to get around LocalStorage restrictions, that'd be really great. I still feel the need to constantly copy-paste things into text files, even with the Visual Editor. DFlhb (talk) 00:27, 5 February 2023 (UTC)[reply]
  • For what is worth, there is a similar request from last year. DMaza (WMF) (talk) 18:19, 25 January 2023 (UTC)[reply]
    It is also known that there were a lot of votes in that proposal. Thingofme (talk) 03:40, 29 January 2023 (UTC)[reply]
    And in 2021, and in 2016 (36th and 31th, respectively). The relevant task is T75241. --Tgr (talk) 05:27, 5 February 2023 (UTC)[reply]
  • This seems like a reasonable proposal. A concern I have for implementation is that we make it VERY clear to editors that this is not for storing drafts of pages/sections. We don't want a new editor work on a section over a period of several days, then try to publish it, only to find out there was an edit conflict. Perhaps delete the auto-saved text after a certain length of time (and inform the editor of such). Libcub (talk) 06:54, 11 February 2023 (UTC)[reply]

Voting

Auto-save wish fulfilment, your input needed

translate

Hello Delta 51, and supporters of Auto-save feature wish, Community Tech is currently investigating this request and we need your input so our engineers can take decisions.

Please read the new project page we have created for the wish and then visit the talk page to give responses to some questions we have for you. –– STei (WMF) (talk) 18:07, 19 June 2023 (UTC)[reply]

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2023/Editing/Auto-save_feature&oldid=26164859"