Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drafts: save contents of the text field to local storage/server-side user-specific storage #1446

Open
urbansheep opened this issue Sep 8, 2021 · 2 comments

Comments

@urbansheep
Copy link

There's a common issue of losing typed text in the form field (post or comment) when browser state is somehow disturbed by browsing away, reloading or crashing/offloading on mobile devices. This brings a certain amount of frustration in users and is usually mitigated by a number of solutions:

First layer of persistence: local storage, where draft can be kept as text after a certain amount of seconds or type events has occured, along with page URL/text container ID. With URL or text container ID we could restore lost state from the drafts buffer after page reload or browser crash, automatically when browser enters the same page and/or activates a certain container (post or comment form).

Multiple drafts could be introduced, but it doesn't seem feasible due to added interface complexity. So the first solution should be rather basic and help with most common case of losing most recently typed text.

Use case:

  1. User activates a post form, types some text.
  2. User navigates away or loses browser state somehow (bypassing unload alert).
  3. User comes back to the page and activates the very same post form.
  4. Post form is autofilled from the local draft, if one is found. Copy of the text stays in the buffer.
  5. After a while unclaimed drafts are discarded.

Edge cases:

  • If text field already contains some text (saved by browser state), it should not be automatically overwritten.
  • If user had several unsaved posts/comments, in basic case with a single draft buffer they would be overwritten by each other in the draft storage, unless each of them is saved to local storage as indexed list, bound to posts/threads by ID.

Second layer of persistence: server-side drafts. This could be deployed as an addition to user-settings storage, with an option to select from a fixed number of last saved drafts, synced from/to local storage occasionally.

While significantly more complex, server-side drafts would allow users to keep their drafts across sessions and devices, and feel safe even on the go when connection is unstable.

@n1313
Copy link
Contributor

n1313 commented Sep 9, 2021

I often lose interest in the middle of composing a post or a comment, especially when writing on a hot topic, and deliberately navigate away from the page to clear the form and do something else. I personally would not appreciate it if a corpse of my unwritten post would reappear to haunt me at a later time, especially if I wrote something stupid or embarrassing. Storing a draft and asking me if I want to return to it, or offering to restore it would be helpful, but I would not like it if it happened automatically. See https://twitter.com/twittersupport/status/1291146855586443267?lang=en.

And if we could drop the "are you sure you want to leave" prompt after implementing this feature, that would be great too.

@urbansheep
Copy link
Author

urbansheep commented Sep 9, 2021

My initial aim was to help with involuntary loss of entered text, which, I suppose, is one the most painful issues with web-apps.

Asking "Hey, there's an auto-saved text for this thread, care to recover?" might be a polite thing to do, but this would require some way to get back to the draft if you were too quick to dismiss the "Recover?" question without reading or thinking. Otherwise it would mean that you lose your draft forever just by hating those confirmation popups.

Otherwise, if this was a sidenote/footnote, easy to note and optional to react to, it might actually work.

Here, I made a quick pic for fun and proof of UI.

2021-09-09 13 14 59

Footnote can be placed immediately under the text-area, or further below post controls. It doesn't really matter as long as it's in the vicinity of the user's focus of attention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants