Too easy to lose work by pressing Back

[JohnVeness]

At the moment, when entering a new issue or a comment (and maybe in other areas, but these are what I do most), if you press the device Back button, or the arrow in the top-left, anything you have typed in, maybe many paragraphs, is just thrown away. This could happen if you accidentally press Back twice instead of once to dismiss a keyboard.

It would be great if this could be avoided. The simplest thing would be a confirmation, but only if some text had been entered.

Nicer would be, instead of a confirmation, if entered text could be stored somewhere within the app as a draft. If the user went back in to open a new issue, or enter a new comment, the draft content could automatically appear.

There would be a danger of multiple drafts hanging around, and the user never re-entering a new issue or comment, so as some housekeeping you could remove drafts over X days old, or only keep the last Y drafts.

[Tunous]

Some ideas I have for this:

1. Tables for issue and comment drafts

One for issue drafts consisting of:

• Repository identifier
• Issue title
• Issue body

And second for comments:

• Repository identifier
• Issue/pull request identifier
• Comment text

Advantage of this idea is that users could write issues and comments for different repositories at the same time and never lose anything.
But it also has a bad side. If users started creating issue in wrong repository they would have to copy text from the other draft or start typing from beginning to move it to the other.

It seems like a nice idea at first but I think the disadvantage is stronger here. Myself I would prefer to have single draft for issues and comments and be able to access it from any repository.

2. Add few fields to shared preferences to store single instance of draft accessible from any repository

This is my preferred idea as it solves issue of starting writing issue in wrong repository/comment in wrong issue.

3. Create whole new screen for draft management

Most powerful but probably an overkill. It would allow for adding new drafts and accessing them from any repository.

---

Implementing any of these ideas would require one new thing. Button to discard current draft. In case of issue it is as simple as adding trash icon to the toolbar which would discard the trash. For the comments though there doesn't seem to be a nice place to add that button... I guess that would need a full screen comment editing first ;)

[Tunous]

So I have thought about this and changed my mind. The first option seems to be the best.

Something similar to that is implemented in Relay for Reddit and it works really well. Each comment is remembered separately for different posts or comments.

@maniac103 thoughts on this?

[JohnVeness]

If it can be done, I like option 1 the best too.

For another real-world example of this, I've seen this happen on web forums, where typing is autosaved and remembered, even if the user closes their browser. In this cases the save is server-side and the user can resume the comment even on another device but I assume this isn't possible for us, unless github has some temp storage we can use. Drafts living within one device is fine.

Option 3 seems extreme overkill, and although option 2 would be easier to code I don't think the user would expect that behaviour, and the times when it would be useful (starting typing in the wrong repo or issue) would be low.

As I mentioned in the OP, you probably want to housekeep the proposed table so it doesn't grow too much, so could add some date fields.

[JohnVeness]

Regarding user discarding of a draft, I'm not sure about adding a button for that. The user could just delete all text before pressing back.

[Tunous]

Improved table scheme, all drafts would be inside of a single table:

• type - commit comment / line comment / issue comment / new issue
• repository id - or alternatively repository name and user name separately
• id - commit id / file and line id / issue number
• text - for new issue that would be title\nbody
• timestamp

As I mentioned in the OP, you probably want to housekeep the proposed table so it doesn't grow too much, so could add some date fields.

Yeah, I think keeping like 5-10 drafts would be ok. They could be cleaned based on timestamp when saving.

Regarding user discarding of a draft, I'm not sure about adding a button for that. The user could just delete all text before pressing back.

Agreed 👍

[JohnVeness]

Sounds good to me. The only thing I would suggest would be to consider whether title should be a separate field (unused except for new issue drafts), rather than the first line of the body text, for ease of manipulation and copying into the completed issue.

[Tunous]

@maniac103 Thoughts? Perhaps we should go for the simplest way and just remember comment input in a single preference that is common for all input fields.
Users would have to manually clear the input if they leave something not sent. But I think that's acceptable.

[maniac103]

Looking at how other apps handle this, it looks like most use a confirmation. One example e.g. is Google+. I think I'd prefer that over storing a single comment, as the restore might come unexpected to the user. If we're going to do it, I think it would be better to ask the user to restore instead of the clear button ... although, thinking about it, from a UX perspective this would be virtually the same thing as a confirmation.

[smichel17]

+1 for option 1, with option 2 as a fallback if option 1 proves to be too much work. Another (easier?) way to implement option 1 would be to use sharedPreferences and create one sharedPreference per repo, each of which containsprefs: "issuetitle", "issuebody", "comment1", "comment2" (the number indicating which issue/pr it is saved on -- "comment358" for this one), etc.

For comments: +1 for always saving the contents with no UI to discard (just delete the saved contents).

For new issues, I think that UI is not very intuitive and would instead propose: change the back icon to an X. Tapping the X opens a dialog asking if you really want to discard the issue. Pressing the keyboard/hardware back button goes back and saves automatically with no dialog (asking if you want to save is pretty silly -- the answer is always yes, or else you'd have chosen to cancel instead).

Added bonus: this behavior would be fully compliant with the material guidelines.

[JohnVeness]

There's a recent move away from confirmation buttons to an "allow undo" paradigm, which was why I suggested the save feature. But I don't really mind how you implement it!

[maniac103]

Yeah, undo snackbars would be the perfect solution, but it's hard to undo with the activity already being closed.

@smichel17 That SharedPreferences solution would be more complicated than a DB ;-) What 'back icon' are you referring to?

[JohnVeness]

I meant "undo" in a more general sense, in that pressing back would be non-destructive and the user could easily retrieve their draft issue or comment without having to do anything special. In fact, if implemented well, the user would hardly have to think about it, with the draft just naturally reappearing "where they left it". I wasn't suggesting having an actual "undo" bar visible.

[smichel17]

@maniac103 The one in the upper left of the screen. For example, here's how we do it in Simpletask:

If you're using the support actionbar library, that's this:
(kotlin code, but it's close enough to the java)

supportActionBar?.setDisplayHomeAsUpEnabled(true)
supportActionBar?.setHomeAsUpIndicator(R.drawable.ic_close_white_24dp)

Bonus points if it's the normal back icon when both fields are empty, and changes to the X when the user has entered text.

---

@JohnVeness You're right, but you also need to consider the reason that undo is better than confirmation dialogs: warning fatigue.

When you repeatedly have to click through a dialog, you stop thinking about it and those 3 clicks turn into a longer version of the single click, so the dialog isn't serving its purpose any more.

In the version I propose, pressing the keyboard/hardware back button (blue box, after the keyboard is hidden) automatically saves a draft, exactly what you propose. However, because new issue creation is two separate fields, imo it'd feel awkward if you needed to delete the text in both just to discard the issue. So, in addition to saving on back button press, we're giving the user a quick shortcut to discard the issue (red box). This isn't something they'll do very often, so there's not as much risk of warning fatigue.

I was working within the constraint of "we don't want to add a new button to the UI". Without that constraint, we could keep the back button where it is (and make it save a draft, no dialog) and add a separate discard button (with a confirmation dialog).

edit: marked up the screenshot

[Tunous]

Confirmation would be a bad implementation IMO, especially for comments.

Currently I'm often hit with that situation:

1. Start typing a comment
2. Now I need to reference a commit, other issue, etc.
3. To do that I copy whole text I already typed to not lose it
4. Hit up arrow to go to other screens and fit what I need
5. Paste my text to other app so I can copy the thing I want to reference and add it to text
6. Return to original issue
7. Get my old text back from the other app and continue editing

With discard confirmation there would be no real benefit for me. I would just get a reminder to copy my text, which I already got used to and never forget. That's why I much prefer automatic saving of drafts as described in my other comments.

@maniac103 The back icon he is referring to is the up arrow in issue creation screen.

[smichel17]

@Tunous You are missing the point in the above where pressing the hardware/keyboard back button (blue box) does exactly that.

edit: also that I was proposing confirmation only for discarding issues, not comments; comments don't need a button to discard since it's easy to just delete the text.

[Tunous]

@smichel17 I really like that idea 👍

[Tunous]

My comment was about @maniac103's idea for confirmation dialogs. Not a response to your idea.

[smichel17]

Oh, missed that, sorry. If anyone is interested in seeing how my suggested implementation would feel, you can try the add task interface from simpletask, as pictured in the screenshot. The only difference is that simpletask actually saves your task when pressing back (ie, blue and green are the same), whereas here it would save a draft, not publish the issue (duh).

[Tunous]

Though there is one conflict. Currently that up arrow has a slightly different behavior than system back button. Using system back button goes back to where you were previously (other app, or other screen in current app), while the up arrow always goes to issues list of a repository (Following suggested behavior by Google). We would lose that behavior if we changed back to close.
But that is probably not that bad to lose since issue creation screen is more of a fullscreen dialog than an activity. It doesn't need to have a parent it leads to.