UCID: Email-139 User Story: As a user, when composing an email, I want a draft of my email to be saved when I leave the compose view (within the app or when minimizing the app) or when the device goes to sleep (or is put into a lock state) to allow me to return to complete the email at a later time.

There is some outstanding UX spec work that needs to happen on drafts, but I am going to get started on the back-end aspect of the local-storage only draft persistence. If things go splendidly we can try and upgrade this to server-persisted for the next sprint. Related bugs: Bug 834646: TEF_REQ bug similar in nature to this one about the desire to save drafts. I'm going to use it as the implementation bug to leave this user story bug clean-ish. Bug 796674: ActiveSync drafts back-end support; not going to work yet Bug 799822: IMAP drafts back-end support; not going to work yet

First draft of spec: https://www.dropbox.com/s/p8akqlkcvhjokyg/saving-drafts-in-email.pdf Looking for your feedback, guys.

The spec looks good! Notes: - The background sending stuff starting from the 2nd card on page 7 is describing background mail sending which is distinct from draft saving. Bug 834774 logs this feature request. There is currently no e-mail feature id assigned to that work. (One might argue that email-052 or email-053 could imply it, but we declared those code complete, although there's somewhat mooted by the blocking mail sending approach we implemented when we fell back from background sending.) - Since we are initially targeting local draft saving with this bug, we will have the situation where we have our local-only drafts folder, plus there will very likely be a server drafts folder. This problem won't exist if we go all the way and implement saving to the server (and being able to edit drafts from other clients), but we need to figure out what to do with the 2 of them. Options seem to be: - Ignore the server folder and pretend our local folder is the only folder. - Label the server drafts folder as "Drafts (Server)" and treat it like a normal folder that we can't resume editing the messages in the folder, and then also have our own "Drafts (Local)" folder. In a previous mail I indicated concern about the proximity of the draft saving and discard buttons. The undo option proposed I think addresses the danger factor and I'm fine with that as proposed. But just for the record, I proposed always saving drafts if the compose window was not blank and having the notification banner/toaster then provide the ability to go back to the draft and somehow potentially provide a way to just delete the draft. Our screen width is such that we barely have space for a single button, let alone two, so the current way probably works better even if it feels a little awkward at first glance.

(In reply to Andrew Sutherland (:asuth) from comment #3) > The spec looks good! Notes: > > - The background sending stuff starting from the 2nd card on page 7 is > describing background mail sending which is distinct from draft saving. Bug > 834774 logs this feature request. There is currently no e-mail feature id > assigned to that work. (One might argue that email-052 or email-053 could > imply it, but we declared those code complete, although there's somewhat > mooted by the blocking mail sending approach we implemented when we fell > back from background sending.) Okay. Is showing a full screen dialog that shows progress/busy indicator the only option that we have for now? (I will update the specs based on your thoughts.) > - Since we are initially targeting local draft saving with this bug, we will > have the situation where we have our local-only drafts folder, plus there > will very likely be a server drafts folder. This problem won't exist if we > go all the way and implement saving to the server (and being able to edit > drafts from other clients), but we need to figure out what to do with the 2 > of them. Options seem to be: > - Ignore the server folder and pretend our local folder is the only folder. > - Label the server drafts folder as "Drafts (Server)" and treat it like a > normal folder that we can't resume editing the messages in the folder, and > then also have our own "Drafts (Local)" folder. Amongst these two, I like the first option better as it's more easy for the user to understand. Another alternative: we can just have "Drafts" and show the drafts from the server listed there and any drafts modified or added new by the user from his mobile will have an indication that says 'local only'. Any thoughts on this? > In a previous mail I indicated concern about the proximity of the draft > saving and discard buttons. The undo option proposed I think addresses the > danger factor and I'm fine with that as proposed. But just for the record, > I proposed always saving drafts if the compose window was not blank and > having the notification banner/toaster then provide the ability to go back > to the draft and somehow potentially provide a way to just delete the draft. > Our screen width is such that we barely have space for a single button, let > alone two, so the current way probably works better even if it feels a > little awkward at first glance. Noted :) Thanks Andrew!

(In reply to Arun Balachandran Ganesan [:abc] from comment #4) > (In reply to Andrew Sutherland (:asuth) from comment #3) > > The spec looks good! Notes: > > > > - The background sending stuff starting from the 2nd card on page 7 is > > describing background mail sending which is distinct from draft saving. Bug > > 834774 logs this feature request. There is currently no e-mail feature id > > assigned to that work. (One might argue that email-052 or email-053 could > > imply it, but we declared those code complete, although there's somewhat > > mooted by the blocking mail sending approach we implemented when we fell > > back from background sending.) > > Okay. Is showing a full screen dialog that shows progress/busy indicator the > only option that we have for now? (I will update the specs based on your > thoughts.) We can fix it, but it's a largely separate implementation issue which is its own feature that has not been targeted at 1.1. > Another alternative: > we can just have "Drafts" and show the drafts from the server listed there > and any drafts modified or added new by the user from his mobile will have > an indication that says 'local only'. Any thoughts on this? This is more complicated; it would either require the unified folder logic that we haven't implemented yet, or it would be very similar to doing the implementation to upload to the server (but without the upload). I will keep this in mind while implementing in case I find a really easy way to implement this. It would be great if you could figure out what visual affordance you would use for that, because it is something that we may need for when we do get to uploading the drafts to the server.

Thanks, Andrew! (In reply to Andrew Sutherland (:asuth) from comment #6) > (In reply to Arun Balachandran Ganesan [:abc] from comment #4) > > (In reply to Andrew Sutherland (:asuth) from comment #3) > > > The spec looks good! Notes: > > > > > > - The background sending stuff starting from the 2nd card on page 7 is > > > describing background mail sending which is distinct from draft saving. Bug > > > 834774 logs this feature request. There is currently no e-mail feature id > > > assigned to that work. (One might argue that email-052 or email-053 could > > > imply it, but we declared those code complete, although there's somewhat > > > mooted by the blocking mail sending approach we implemented when we fell > > > back from background sending.) > > > > Okay. Is showing a full screen dialog that shows progress/busy indicator the > > only option that we have for now? (I will update the specs based on your > > thoughts.) > > We can fix it, but it's a largely separate implementation issue which is its > own feature that has not been targeted at 1.1. Gotcha. > > > Another alternative: > > we can just have "Drafts" and show the drafts from the server listed there > > and any drafts modified or added new by the user from his mobile will have > > an indication that says 'local only'. Any thoughts on this? > > This is more complicated; it would either require the unified folder logic > that we haven't implemented yet, or it would be very similar to doing the > implementation to upload to the server (but without the upload). > > I will keep this in mind while implementing in case I find a really easy way > to implement this. It would be great if you could figure out what visual > affordance you would use for that, because it is something that we may need > for when we do get to uploading the drafts to the server. Sure. I will redo the specs accordingly and post it.

Andrew: I'm adding indicators to the 'sending mail' screens and I need the following info: How long does it typically take to send an email without any attachments? If we send an email with attachments and it takes time, is there anyway to know i) how long it will take in seconds ? ii) or how much percentage of it is sent to show progress? Also, I think we will need an Outbox (local only will be good enough) to save the unsent emails that users can send later. Do you have any specific thoughts on that?

(In reply to Arun Balachandran Ganesan [:abc] from comment #8) > How long does it typically take to send an email without any attachments? These are all questions about mail sending, which is bug 834774. I'll reply there.

Thanks for digging into the details on this. Just a heads up (Arun also mentioned it at the end of the spec): Undo (of deletion of draft), while important, will not block the release.

Thanks, Andrew. I'm working on updating the specs and meanwhile have few questions. i) This question is mainly to clarify the current functionality and limitations. I assume that we can retrieve drafts from the server. Will the user be able to edit the draft and send it? I know that we cannot sync it back with the server. ii) What type of email protocols are we supporting? Does email drafts work/behave differently (for syncing or anything else). Arun

(In reply to Arun Balachandran Ganesan [:abc] from comment #11) > i) This question is mainly to clarify the current functionality and > limitations. I assume that we can retrieve drafts from the server. Will the > user be able to edit the draft and send it? I know that we cannot sync it > back with the server. We can retrieve them, but point 2c from https://bugzilla.mozilla.org/show_bug.cgi?id=799822#c5 still stands. > ii) What type of email protocols are we supporting? Does email drafts > work/behave differently (for syncing or anything else). We support IMAP/SMTP and ActiveSync accounts. For draft-saving purposes, although the back-end implementation varies extremely between them, we don't currently expect this to manifest in a user-visible way. But since we are only doing local draft storage right now, we 100% expect there to be no difference because the server is not involved at all.

Great! Thanks, Andrew. Cheers, Arun

Andrew: Draft for the specs are here — IMPORTANTLY, it is pending UX review. I'm putting it here to gather some thoughts from you after which I will be making any changes necessary ASAP based on your feedback. https://www.dropbox.com/s/7s0xwktx3v18o8l/saving-drafts-in-email.pdf Thank you! Cheers, Arun

The import stage isn't needed for local drafts. When we do server drafts, what happens will still just count as synchronizing messages, so no special UI affordance is required for that. The minor change to the sending flow to add a banner/toaster at the bottom that the message was sent seems fine.

Thanks, Andrew. I will update it. One more question: How we handle the following situations when the user has an unfinished draft (i) When the mobile turns off, say because of battery drain when the user is composing a draft (ii) goes to sleep/idle state (iii) When the app crashes (iv) When the OS crashes For sleep/idle and battery drain, I think it would be nice if when the user returns & unlocks the phone it shows him the draft. For app/OS crashing, I think if the draft is automatically saved that might be nice. Thoughts?

I think there are 3 discrete ideas here: - Save periodically. Covers battery drain (i), and crashes (iii, iv). We also want to avoid killing the user's battery, so we probably want to kick-off a dirty time if one isn't already active whenver we get any text field input/add a contact. Of course, if we save state for some other reason, we then want to cancel the timer. - Save when the OS gives us a hint that something notable is happening that might result in our app being killed. This could be partially covered by periodic saving, but if we get backgrounded we immediately become much more vulnerable to the OOM killer, so it would be good to accelerate our timer and just save. - Restoring app state when the app is started. We don't do this at all right now, so that needs to be filed as another bug after double-checking we don't have a bug on this already. This isn't fundamentally hard, but there are a lot of edge cases relating to the ability of state to change out from under us which is why we haven't dealt with it yet.

Thanks, Andrew! Never knew so much happened within my mobile :D Sounds good. I will include it with the specs. One clarification: when mobile enters sleep state, and returns to unlock screen, he should see the draft where he last left it — do you see any problems or edge cases with that? P.S: Did I ever say how awesome you are?

(In reply to Arun Balachandran Ganesan [:abc] from comment #18) > Sounds good. I will include it with the specs. One clarification: when > mobile enters sleep state, and returns to unlock screen, he should see the > draft where he last left it — do you see any problems or edge cases with > that? No problems. The draft should still be there in that case since the e-mail app is unlikely to get killed. > P.S: Did I ever say how awesome you are? Thanks! :)

Andrew: Can you take a look? Updated specs: https://www.dropbox.com/s/horrqigw3co3mjh/Email-drafts.pdf Cheers, Arun

I think the revised specs look fine.

Thanks, Andrew. Just to confirm: (i) There is no need for a refresh button in the drafts view? (ii) When user multitasks by pressing the home button and returns, the draft should be retained in it’s original form. User should return to the app, to find it left untouched. For this, the draft does not have to be saved. Any thoughts?

(In reply to Arun Balachandran Ganesan [:abc] from comment #22) > (i) There is no need for a refresh button in the drafts view? It doesn't make any sense for local-only drafts, although for simplicity we might leave it around in the implementation since it should be relatively harmless. > (ii) When user multitasks by pressing the home button and returns, the draft > should be retained in it’s original form. User should return to the app, to > find it left untouched. For this, the draft does not have to be saved. Any > thoughts? With no effort on our part, this is what will happen. In practice we can't control the out-of-memory killer, so we should be trying to save when that happens. But that will likely end up being a spin-off bug.

I still haven't obtained clear details about the deadline, but as far as prioritization goes I'd argue that (if needed) we should drop: - the tapable "Mail saved in Draft" banner - the undo feature and keep "save draft when the app goes into the background" in the scope of the first patch. (In reply to Andrew Sutherland (:asuth) from comment #23) > In practice we can't > control the out-of-memory killer, so we should be trying to save when that > happens. But that will likely end up being a spin-off bug.

Those simplifications all sound reasonable. They indeed can all be follow-on patches.

The version of the UX spec posted on Mar 11 is still valid (no changes) because all items needing clarification from Andrew are complete (based on the comments above). No other issues remain open from the UX side at this time. Here is the spec again (just added a date to the file name): https://www.dropbox.com/s/ucvcuqvalsdy7bs/Email-drafts_13Mar2013.pdf

Naoki - We have test case coverage for this I believe, right?

Does anything else need to happen on this? We have passed our 03/29 date for being feature complete on the P1/leo+ user stories (excluding MMS) and this is one of those nine bugs that are still open. Are there any major blockers to closing this?

test case 6563 has been created. Still waiting for landing. It looks like we're waiting for the backend to land, Stephany. Bug 851227 : https://bugzilla.mozilla.org/show_bug.cgi?id=851227#c5

oops. accidentally marked needinfo. clearing.

Only working on the UI part on bug 851227

Thanks etienne. Asuth, who should be the appropriate owner for this bug?

landed on gaia/master: https://github.com/mozilla-b2g/gaia/pull/9027 https://github.com/mozilla-b2g/gaia/commit/62577d0908e2c0e54cda1ecc49c79e1c24758445

oh, and landed on gaia-email-libs-and-more/master: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/171 https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/171

Uplifted commit 62577d0908e2c0e54cda1ecc49c79e1c24758445 as: v1-train: 157ec9935f17d56f9501c9fd9937b8ac12bd1a66

Note that I've uplifted the back-end fixes of this bug to v1.0.1 for the tef+ bug 858618. The back-end changes to support drafts have no effect on v1.0.1 since it lacks the UI, but leaves the v1.0.1 branch in a less buggy state and more friendly to future correctness and performance uplifts. See https://bugzilla.mozilla.org/show_bug.cgi?id=858618#c16 for commit refs and more details.

verified fixed on Leo with: Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/0c71cbc5fe0c Gaia a7b0810580afc734f3d5e441914fe895f9c1923e BuildID 20130508230207 Version 18.0