879143 - (messaging-drafts) [Meta][Messages] Add support for saved message drafts

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::SMS, defect, P2)

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.121
 Firefox os  v1.0.1
 Mozilla build ID:20130527070203
 
 DEFECT DESCRIPTION:
 When writing an SMS, not found option to save as draft.
 
  REPRODUCING PROCEDURES:
 1.  Click on the message icon (bottom of the screen, second icon from the
 left), press the “New SMS” icon (top of the screen, second icon from the
 right), write some text on the Text Box.
 
 2.  Write some text
 
 3.  Press “Back” icon (top of the screen on the left)  
    
  EXPECTED BEHAVIOUR:
 should offer the possibility to save a SMS as draft   
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

triage with tef: this is feature request. koi? for future consideration

Comment 4

[Jack Liu]

This feature is very important to end user, why not have it implemented in v1.2?

Comment 5

[Jack Liu]

Sorry for urging you, but it really needed by v1.1.

Comment 6

[Rick Waldron [:rwaldron]]

(In reply to Jack Liu from comment #5)
> Sorry for urging you, but it really needed by v1.1.

This is not spec'ed and not trivial to implement, especially if we're expected to persist many "drafts" until they are sent or deleted.

Comment 7

[Andrew Overholt [:overholt]]

Sorry, it's too late for new features in v1.1.  Jason mentioned that it may even be too late for v1.2 features ...

Comment 8

[Joe Cheng [:jcheng] (please needinfo)]

add to backlog 891754
likely a dupe

Comment 10

[kenzo Ohta]

Attachment: sample879143patch

Hi All

When user is writting MMS message, Battery gets low.
In this case we think draft feature is need.
So my team just try to implement draft feature.

Now sms app saves messages to Gecko's indexedDB by each thread,
so draft information can be saved to the same DB, like a send message.

We tried to implement sample code.
The code implements are ...
- add the draft param to mozMobileMessage.send
- add the draft param to mozMobileMessage.sendMMS
- add the function of saving draft information to Gecko's DB
Could anybody check the sample code?

Note: Our code is a sample. We have to separete draft interface from send.

BRs,

Comment 11

[Julien Wajsberg [:julienw]]

adds the API URL. I don't find where drafts are supposed to be saved there, but there is a specific state for these messages.

Comment 12

[Vicamo Yang [:vicamo][:vyang]]

(In reply to kenzo Ohta from comment #10)
> Created attachment 800605 [details] [diff] [review]
> sample879143patch
> 
> Hi All
> 
> When user is writting MMS message, Battery gets low.
> In this case we think draft feature is need.
> So my team just try to implement draft feature.
> 
> Now sms app saves messages to Gecko's indexedDB by each thread,
> so draft information can be saved to the same DB, like a send message.
> 
> We tried to implement sample code.
> The code implements are ...
> - add the draft param to mozMobileMessage.send
> - add the draft param to mozMobileMessage.sendMMS
> - add the function of saving draft information to Gecko's DB
> Could anybody check the sample code?
> 
> Note: Our code is a sample. We have to separete draft interface from send.

Hi, Kenzo,

We clearly understands the necessity of draft messages.  Actually we had tried to sale it in mid 2012, but it was rejected.  The reason is, if I recall correctly, saving draft is really a responsibility of the application, not the API implementation -- Gecko, in our case.  API implementation provides a common way to access a certain technology.  In Mozilla, we may even take a step further to implement only standards that is openly available.  Draft message is not even a standard.  It's an user interface actually, and we don't want to bury a UX design into Gecko.  As you can see we have bug 898364, moving conversation thread database to Gaia, for exactly the same reason.

However, it seems both draft messages and message conversation are now included in W3C Messaging API editor's draft[1], but the way to save a draft SMS/MMS message into database is left undefined.

By the way, saving draft messages by calling "send" along with additional parameters sounds like a work around.  A separate API would be more preferable for me.

[1]: http://messaging.sysapps.org/#enumerations

Comment 13

[Caio Lima(:caiolima)]

I agree with the idea of each application implement your draft feature. The idea of save drafts using the API doesn't sound good to me. Sorry to ask, but what's the motivation to provide drafts operations in the Messaging API?

Comment 14

[Julien Wajsberg [:julienw]]

Vicamo, do you think the draft feature should be only done in Gaia ? I support this solution too, and if we agree on this, we could start working on a solution.

Kenzo, do you want to work on this ? Otherwise Caio Lima expressed interest in this too.

Comment 15

[kenzo Ohta]

(In reply to Caio Lima(:caiolima) from comment #13)
> Sorry to ask, but what's the motivation to provide drafts operations in the Messaging API?

I hope that draft message is saved in DB.
Now all message data(need to save) is stored in Gecko DB, 
and draft message is need to associated with conversation thread as a UX specification.
There is conversation thread objectstore in Gecko DB, so we provide drafts operation in the Messaging API.

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #12)
> As you can see we have bug 898364, moving conversation thread database to Gaia,
> for exactly the same reason.

If conversation thread objectstore is moved in Gaia, I am favor of modification only in Gaia.

Comment 16

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Julien Wajsberg [:julienw] from comment #14)
> Vicamo, do you think the draft feature should be only done in Gaia ? I
> support this solution too, and if we agree on this, we could start working
> on a solution.

Julien, like what I've said before, Borja and I had tried to bring draft messages to Gecko database but didn't have strong enough reasons for DOM peers and it was turned down.  I understand saving draft message in Gecko db will be a life saving method in comparison to saving in Gaia, but that's really not my call.  You have to raise a API discussion on webapi-dev mailing list instead.  I can help for the Gecko part whenever it becomes necessary.

Comment 17

[Caio Lima(:caiolima)]

Attachment: Pototype of a draft implemented on Gaia

So guys, this is a prototype of what I'm thinking in terms of draft implementation on Gaia layer. It's only a first proposal, so, I would like to know what you think.

The idea is:

1. Each conversation thread has a draft saved if the back button is clicked;
2. When the user return to the conversation thread, we load the draft saved;

I have a questions:

1. There is a way to listen when an application is being closed in Gaia, as the Android Activity lifecycle?

So, that is it!

Comment 18

[Jack Liu]

Dears, it should be implemented in v1.2, there is already draft saving feature in email app.

Comment 19

[Julien Wajsberg [:julienw]]

(In reply to Caio Lima(:caiolima) from comment #17)
> Created attachment 804833 [details] [diff] [review]
> Pototype of a draft implemented on Gaia
> 
> So guys, this is a prototype of what I'm thinking in terms of draft
> implementation on Gaia layer. It's only a first proposal, so, I would like
> to know what you think.
> 
> The idea is:
> 
> 1. Each conversation thread has a draft saved if the back button is clicked;

we should do that also on page visibility hidden.

> 2. When the user return to the conversation thread, we load the draft saved;
> 
> I have a questions:
> 
> 1. There is a way to listen when an application is being closed in Gaia, as
> the Android Activity lifecycle?

see previous comment :)

We should figure if it's being triggered when the user displays the task switcher.

If it isn't triggered in that case, we could decide that if the user kills manually the app, we won't have a draft. But maybe it's triggered and in that case it's all good :)

Comment 20

[Julien Wajsberg [:julienw]]

Comment on attachment 804833 [details] [diff] [review]
Pototype of a draft implemented on Gaia

Review of attachment 804833 [details] [diff] [review]:
-----------------------------------------------------------------

I haven't tried it but this looks very good, I like it :)

Some comments already, I tried to stay general but I've also added some nits (because I can't help it ;) )

::: apps/sms/js/draft_helper.js
@@ +7,5 @@
> +
> +  },
> +
> +  saveDraft: function dh_saveDraft(id, content) {
> +    var request = indexedDB.open('DraftTestDB', 2);

put the version number in a constant: DraftHelper.DB_VERSION for example

Use just "messages" as db name and use a constant for this too: DraftHelper.DB_NAME.

Version should be 1 :)

I think that in the future we'll have several objectstores, so maybe you can move all generic DB operation (like upgrade, open) in a separate object (IndexedDBHelper), and we'll use this separate object in DraftHelper.

Maybe DraftHelper should simply be called Drafts :)

@@ +9,5 @@
> +
> +  saveDraft: function dh_saveDraft(id, content) {
> +    var request = indexedDB.open('DraftTestDB', 2);
> +    request.onsuccess = (function(event) {
> +      this.db = request.result;

why do you save the db in this ? Probably a left over from a previous work, right ? :)

@@ +16,5 @@
> +      var objectStore = transaction.objectStore('drafts');
> +      var aRequest = objectStore.add({id: id, message: content});
> +    }).bind(this);
> +
> +    request.onupgradeneeded = function(event) {

make this function a method of DraftHelper, maybe DraftHelper._doUpgrade

@@ +17,5 @@
> +      var aRequest = objectStore.add({id: id, message: content});
> +    }).bind(this);
> +
> +    request.onupgradeneeded = function(event) {
> +      this.db = event.target.result;

don't save db in `this`, this looks unnecessary

@@ +30,5 @@
> +      var db = request.result;
> +      db.transaction(['drafts'], 'readwrite').
> +        objectStore('drafts').
> +        delete(id);
> +    }).bind(this);

you don't need to bind :)

@@ +41,5 @@
> +      db.transaction('drafts').
> +        objectStore('drafts').
> +        get(id).onsuccess = function(event) {
> +          oncomplete(event.target.result);
> +        };

in the final implementation we'll need to handle onerror, at least to output an error to the console

@@ +42,5 @@
> +        objectStore('drafts').
> +        get(id).onsuccess = function(event) {
> +          oncomplete(event.target.result);
> +        };
> +    }).bind(this);

you don't need to bind :)

Comment 21

[Julien Wajsberg [:julienw]]

I'll send a mail to the webapi ML tomorrow.

Comment 22

[Rick Waldron [:rwaldron]]

Comment on attachment 804833 [details] [diff] [review]
Pototype of a draft implemented on Gaia

Review of attachment 804833 [details] [diff] [review]:
-----------------------------------------------------------------

::: apps/sms/js/draft_helper.js
@@ +1,3 @@
> +'use strict';
> +
> +var DraftHelper = {

Since the plan is to potentially have many drafts at a time in memory, then a constructor with prototype definition is more appropriate than a plain object "singleton".

function Draft() {
...initialize.
}

Draft.prototype.save = function() { ... }

Draft.prototype.delete = function() { ... }

@@ +7,5 @@
> +
> +  },
> +
> +  saveDraft: function dh_saveDraft(id, content) {
> +    var request = indexedDB.open('DraftTestDB', 2);

Couldn't the simpler asyncStorage api be used...?

@@ +29,5 @@
> +    request.onsuccess = (function(event) {
> +      var db = request.result;
> +      db.transaction(['drafts'], 'readwrite').
> +        objectStore('drafts').
> +        delete(id);

There is not and cannot be a bound function named "delete"—is this meant to be the operator? If so, then this line can be removed because it doesn't do anything: 

function foo(id) { 
  delete id;
  return id;
}

foo(1); // 1

Comment 23

[Julien Wajsberg [:julienw]]

(In reply to Rick Waldron from comment #22)
> Comment on attachment 804833 [details] [diff] [review]
> Pototype of a draft implemented on Gaia
> 
> Review of attachment 804833 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: apps/sms/js/draft_helper.js
> @@ +1,3 @@
> > +'use strict';
> > +
> > +var DraftHelper = {
> 
> Since the plan is to potentially have many drafts at a time in memory, then
> a constructor with prototype definition is more appropriate than a plain
> object "singleton".
> 
> function Draft() {
> ...initialize.
> }
> 
> Draft.prototype.save = function() { ... }
> 
> Draft.prototype.delete = function() { ... }

And a static Draft.load(id) then ?
Why not !

> 
> @@ +7,5 @@
> > +
> > +  },
> > +
> > +  saveDraft: function dh_saveDraft(id, content) {
> > +    var request = indexedDB.open('DraftTestDB', 2);
> 
> Couldn't the simpler asyncStorage api be used...?

Mmm why not, I forgot this existed. But I think that in the long run we'll need a real db anyway (we'll store the threads in Gaia, and we'll do the contacts search in Gaia).

> 
> @@ +29,5 @@
> > +    request.onsuccess = (function(event) {
> > +      var db = request.result;
> > +      db.transaction(['drafts'], 'readwrite').
> > +        objectStore('drafts').
> > +        delete(id);
> 
> There is not and cannot be a bound function named "delete"—is this meant to
> be the operator?

You missed the final dot on the previous line ;) Of course for readability it should be at the start of the line instead but I didn't want to report such nits at this stage.

Comment 24

[Caio Lima(:caiolima)]

Thank you for the preview. So, I'm goint to continue working on it. Sorry for some badly named or badly used of something, I was only thnking in prototype firstly.

(In reply to Rick Waldron from comment #22)
> @@ +7,5 @@
> > +
> > +  },
> > +
> > +  saveDraft: function dh_saveDraft(id, content) {
> > +    var request = indexedDB.open('DraftTestDB', 2);
> 
> Couldn't the simpler asyncStorage api be used...?

I didn't get it. You mean to use a sync API? I didn't know that it exists, And I prefer to use a sync API instead =)

Comment 25

[Caio Lima(:caiolima)]

One more point. In this prototype I'm only considering to save the text of a SMS. I'm not use to use MMS, so, IS necessary a different way to create drafts for MMS, or only te text is enougth?

Julien, Why not implement all draft operations like save, delete and load as static methods?

Comment 26

[Julien Wajsberg [:julienw]]

(In reply to Caio Lima(:caiolima) from comment #24)
> Thank you for the preview. So, I'm goint to continue working on it. Sorry
> for some badly named or badly used of something, I was only thnking in
> prototype firstly.
 
Please wait, we need UX input _and_ WebAPI input :)

> (In reply to Rick Waldron from comment #22)
> > @@ +7,5 @@
> > > +
> > > +  },
> > > +
> > > +  saveDraft: function dh_saveDraft(id, content) {
> > > +    var request = indexedDB.open('DraftTestDB', 2);
> > 
> > Couldn't the simpler asyncStorage api be used...?
> 
> I didn't get it. You mean to use a sync API? I didn't know that it exists,
> And I prefer to use a sync API instead =)

Rick was referencing https://github.com/mozilla-b2g/gaia/blob/master/shared/js/async_storage.js, which is a thin wrapper around indexedDB reproducing a localStorage functionality in an asynchronous way.


(In reply to Caio Lima(:caiolima) from comment #25)
> One more point. In this prototype I'm only considering to save the text of a
> SMS. I'm not use to use MMS, so, IS necessary a different way to create
> drafts for MMS, or only te text is enougth?

You're right, I'm quite sure we'll want draft for MMS too ;) But we can also do this in a separate patch, keeping this in mind of course.

> 
> Julien, Why not implement all draft operations like save, delete and load as
> static methods?

Because it's useful to have a Draft object approach. Maybe we can decide we can use it quite early to modelize an in-progress message inside Compose.js, and merely call "save" on it afterwards, whereas using a DraftHelper approach is more procedural and will probably lead to more rigid/spaghetti code.

Comment 27

[Julien Wajsberg [:julienw]]

NeedInfo Ayman as a reminder flag for the draft functionality.

Comment 28

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #27)
> NeedInfo Ayman as a reminder flag for the draft functionality.

wireframes landing nextweek
leaving ni? to me until i post them here

Comment 29

[ayman maat :maat]

Attachment: FFOS_MessageDraft_V1.3_20130920_V1.0.pdf

**RELEASE NOTE**
new wireframes
- none

updated wireframes
- none

deleted wireframes
- none

new flows
- New message : Save as draft from within app
- New message : Save as draft from outside of app

updated flows
- none

deleted flows
- none

Comment 30

[Caio Lima(:caiolima)]

(In reply to ayman maat :maat from comment #29)
> Created attachment 807812 [details]
> FFOS_MessageDraft_V1.3_20130920_V1.0.pdf
> 
> **RELEASE NOTE**
> new wireframes
> - none
> 
> updated wireframes
> - none
> 
> deleted wireframes
> - none
> 
> new flows
> - New message : Save as draft from within app
> - New message : Save as draft from outside of app
> 
> updated flows
> - none
> 
> deleted flows
> - none

I liked this proposal. I have doubt about the |draft badage| that will be shown in Thread List. Has it already done? If yes, where could I found It? 

Julien, I guess we can continue the work then.

Comment 31

[Julien Wajsberg [:julienw]]

Ayman, here are some comments:

* no flow when editing existing threads
* when pressing home: I think we should save the draft as soon as the user presses "home" (a "visibilitychange" event will be sent), but of course we should not discard. I think we can't do this when the app is killed. So maybe you'd need to adjust the wireframe for this.
* in your "message list" view, there are several lines for the same user (non draft + draft SMS + draft MMS); but I think we agreed we'd have only one draft per user. Maybe your wireframe would be more accurate with different names on these lines.
  I do agree that we could have other drafts for the messages with several recipients though.

One question to confirm something:
* in the message list view, when there is the "draft" mention, we don't have a summary of the message text. Is that right ?

Also, we'll need to see what events we have when the user reboots the phone.

Caio: we'll need Visual Design at least for the "draft" mention. We'll also need more information from Ayman, but you can already try to design a "Draft" object that you'll use throughout the application. Keep in mind that we need to be able to save SMS, MMS, and several recipients messages.

Comment 32

[Julien Wajsberg [:julienw]]

Also, I got an answer from Jonas Sicking, and he thinks we should do the Draft feature in the app only, not in the gecko API.

Comment 33

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #31)
> Ayman, here are some comments:
> 
> * no flow when editing existing threads

True, but i perceive the it will be the same as specified for new message - just with an existing thread view. Let me know if you see any differences before i update the wireframes with this missing flow.

> * when pressing home: I think we should save the draft as soon as the user
> presses "home" (a "visibilitychange" event will be sent), but of course we
> should not discard. 

I am happy to do this as soon as home is pressed.

> I think we can't do this when the app is killed. So
> maybe you'd need to adjust the wireframe for this.

Before adjusting the wireframes can i ask what the dev overhead would be for introducing 'save draft' at the point when the app is killed ?


> * in your "message list" view, there are several lines for the same user
> (non draft + draft SMS + draft MMS); but I think we agreed we'd have only
> one draft per user. Maybe your wireframe would be more accurate with
> different names on these lines.

Yeh, thats lazy wireframing from me ;) ..We would only have one draft per contacts phone number. Will update to ensure no confusion

>   I do agree that we could have other drafts for the messages with several
> recipients though.

I agree with this, but we need to see if we can handle this in SMS and MMS mode. Would Vicamo be the person to ask?

ni? Julien regarding that question

> 
> One question to confirm something:
> * in the message list view, when there is the "draft" mention, we don't have
> a summary of the message text. Is that right ?

No summary of the message. we don't have room to display this in portrait mode (however it is extra information could *consider' showing when orientated into landscape mode, maybe..) 

> 
> Also, we'll need to see what events we have when the user reboots the phone.
> 
> Caio: we'll need Visual Design at least for the "draft" mention. We'll also
> need more information from Ayman, but you can already try to design a
> "Draft" object that you'll use throughout the application. Keep in mind that
> we need to be able to save SMS, MMS, and several recipients messages.

Comment 34

[Caio Lima(:caiolima)]

I have another question. What about the case when we:

1. Click on new message;
2. Write the message;
3. Don't put the recipients;
4. The user exit the application(Because of a new call or another notification.);

Comment 35

[Caio Lima(:caiolima)]

I have another question. What about the case when we:

1. Click on new message;
2. Write the message;
3. Don't put the recipients;
4. The user exit the application(Because of a new call or another notification.);

I guess that we can still save a draft with no recipients yet. What do you think about this?

Comment 36

[ayman maat :maat]

(In reply to Caio Lima(:caiolima) from comment #35)
> I have another question. What about the case when we:
> 
> 1. Click on new message;
> 2. Write the message;
> 3. Don't put the recipients;
> 4. The user exit the application(Because of a new call or another
> notification.);
> 
> I guess that we can still save a draft with no recipients yet. What do you
> think about this?

Well the way i have specified this is that if the user moves away from the app, the app remains in the same state it was in when they moved away, therefore there is no need to put the message into 'draft mode'. so, if a message was in compose mode (either in thread view or new message view), and the user moves away form the app (presses the home button or receives an incoming call etc etc) the app in the background remains in the compose view, and when called presents the compose view (this is the same behaviour as we have currently). The added part where drafts come in would be that if the user then called the app via another rout (say contact list > contact detail > select message icon) thus triggering a new view of the message app, the message that was already in compose view would be saved as a draft. likewise if the user killed the message app the message that was in compose view would be saved as a draft before the app closed.

Does that cover your query? let me know and let me know if this mechanism does not work for you so we can revise.

Comment 37

[Caio Lima(:caiolima)]

Ayman: Yes. I guess that using the "visibilitychange", as Julien said, will solve most of our cases to save the draft.

Comment 38

[Julien Wajsberg [:julienw]]

(In reply to ayman maat :maat from comment #33)
> (In reply to Julien Wajsberg [:julienw] from comment #31)
> > Ayman, here are some comments:
> > 
> > * no flow when editing existing threads
> 
> True, but i perceive the it will be the same as specified for new message -
> just with an existing thread view. Let me know if you see any differences
> before i update the wireframes with this missing flow.

It will look the same but will be way easier in the code, as we have a thread id to associate the Draft with.


> > * when pressing home: I think we should save the draft as soon as the user
> > presses "home" (a "visibilitychange" event will be sent), but of course we
> > should not discard. 
> 
> I am happy to do this as soon as home is pressed.
> 
> > I think we can't do this when the app is killed. So
> > maybe you'd need to adjust the wireframe for this.
> 
> Before adjusting the wireframes can i ask what the dev overhead would be for
> introducing 'save draft' at the point when the app is killed ?

The problem is that I think we really can't. When the app is killed, we probably get the "unload" event (I'm not even sure), and we can't do much in this event. We could experiment using localStorage which is synchronous but I don't think this is worth it.


> 
> >   I do agree that we could have other drafts for the messages with several
> > recipients though.
> 
> I agree with this, but we need to see if we can handle this in SMS and MMS
> mode. Would Vicamo be the person to ask?

Since we'll handle everything in Gaia, Vicamo won't care much ;-)

We can do whatever we want.

> > 
> > One question to confirm something:
> > * in the message list view, when there is the "draft" mention, we don't have
> > a summary of the message text. Is that right ?
> 
> No summary of the message. we don't have room to display this in portrait
> mode (however it is extra information could *consider' showing when
> orientated into landscape mode, maybe..) 

Agreed :)


And Re: comment 36, I don't think you're saying what your wireframe is saying. In the second part of the wireframe ("save from outside" whatever that means ;) ) you're saying that if there is no valid recipient the message should be discarded when the app is killed. I think that was Caio's question.

Also, please remember the app can be killed because of memory pressure, not only when the user explicitely requests it. I think the memory pressure case is more frequent too.

Comment 39

[Julien Wajsberg [:julienw]]

Caio will check if we get the visibilitychange event in all cases:

* short pressing home to display homescreen
* while the app is displayed, long pressing home to display the card switcher, and switch back to the app
* starting an activity
* restarting the device while the app is displayed

Am I missing a flow for moving out of the app ?

Comment 40

[Caio Lima(:caiolima)]

Well, Today I had a discussion with Julien and Rik Waldron about the implementation of this feature.

1. We've decided to store a draft for each conversation's thread, that will be implemented using the async_storage and with the following archtecture: "TrheadID" as key => "Draft Content" as value. This way, We can easily load the draft of a conversation thread.

2. Another object store that we will use is to persist the summary of wich conversation's thread has a draft saved. It'll be used by thread_list to inform the user about the saved draft(as we can see on wireframes).

3. And finally, we will store the content of a new message as a draft using the following way "generated_key" as key => "{recipients: values, content: aContent}" as value.

BTW, the draft will be saved when the Messaging app visibility change to "hidden".

However, I stayed with a doubt about the 3rd case. I didn't understand the user flow in this case. Imagine this situation:

1. The user clicks on new message;
2. Start to write a new message;
4. The user fills the recipients with a contact that doesn't have a Thread yet;
5. the user closes the app;
6. Before it, we save the draft.

1. What will happen after? We saved the draft, and when the user click on new message agin, It'll be filled with the last draft(including the recipients)?

2. If have the recipients already have a conversation's thread, Will we save this draft in this thread? Julien, could you tell me if it's possible?

Comment 41

[Caio Lima(:caiolima)]

Attachment: visibility_test

Comment 42

[Caio Lima(:caiolima)]

(In reply to Julien Wajsberg [:julienw] from comment #39)
> Caio will check if we get the visibilitychange event in all cases:
> 
> * short pressing home to display homescreen
> * while the app is displayed, long pressing home to display the card
> switcher, and switch back to the app

I've tested these cases above and they peformed well.

> * starting an activity
I didn't understand this case. Start wich activity?

> * restarting the device while the app is displayed
I'm not sure if I can test it, because I'm using the emulator. So, could anybody else test it?
 
> Am I missing a flow for moving out of the app ?
Maybe when we are in the messaging app and recieve a notification and click on it.

Comment 43

[Caio Lima(:caiolima)]

(In reply to Caio Lima(:caiolima) from comment #42)
> > * restarting the device while the app is displayed
> I'm not sure if I can test it, because I'm using the emulator. So, could
> anybody else test it?

When the device is restarting, this method is being called either.

Comment 44

[Rick Waldron [:rwaldron]]

(In reply to Caio Lima(:caiolima) from comment #40)
> Well, Today I had a discussion with Julien and Rik Waldron about the
> implementation of this feature.
> 
> 1. We've decided to store a draft for each conversation's thread, that will
> be implemented using the async_storage and with the following archtecture:
> "TrheadID" as key => "Draft Content" as value. This way, We can easily load
> the draft of a conversation thread.
> 
> 2. Another object store that we will use is to persist the summary of wich
> conversation's thread has a draft saved. It'll be used by thread_list to
> inform the user about the saved draft(as we can see on wireframes).
> 
> 3. And finally, we will store the content of a new message as a draft using
> the following way "generated_key" as key => "{recipients: values, content:
> aContent}" as value.
> 
> BTW, the draft will be saved when the Messaging app visibility change to
> "hidden".
> 
> However, I stayed with a doubt about the 3rd case. I didn't understand the
> user flow in this case. Imagine this situation:
> 
> 1. The user clicks on new message;
> 2. Start to write a new message;
> 4. The user fills the recipients with a contact that doesn't have a Thread
> yet;
> 5. the user closes the app;
> 6. Before it, we save the draft.
> 
> 1. What will happen after? We saved the draft, and when the user click on
> new message agin, It'll be filled with the last draft(including the
> recipients)?

This is what I assumed.


> 
> 2. If have the recipients already have a conversation's thread, Will we save
> this draft in this thread? Julien, could you tell me if it's possible?

This is possible, but seems overly complicated. I would limit it to this:

If a thread already exists with this recipient, move the draft to that thread (it's likely what the user intended anyway)

Julien, what do you think?

Comment 45

[Caio Lima(:caiolima)]

Attachment: draft-prototype

I've started to work on draft implementation. =)

Comment 46

[Julien Wajsberg [:julienw]]

Just discussed avec Ayman, he will provide new wireframes shortly.

But in the mean time, I can now answer some questions and add details :)

* we will save drafts that have no recipients
* we'll be able to have several "new message" drafts for the same recipients (or with no recipients), but only one draft per existing thread
* tapping on the "new message" button will always trigger an empty "new message" view
* we'll add the timestamp when we save/update a draft. On the thread list view we need to show the drafts according to the timestamp (and same for an existing thread that contains a draft -- timestamp of that thread is the latest of the latest message's timestamp and the draft's timestamp)


> 1. What will happen after? We saved the draft, and when the user click on new message agin,
> It'll be filled with the last draft(including the recipients)?

Nope. The draft will be shown in the message list, like a conversation, except it will have the "draft" tag on it.


> 2. If have the recipients already have a conversation's thread, Will we save this draft
> in this thread? Julien, could you tell me if it's possible?

As we discussed with Ayman, if the draft only has one recipient, and that recipient already has a thread, we'll save this draft as that thread's draft. But beware the following cases:
* If that thread already has a draft, I think we'll need to ask the user if he wants to discard the old draft or the new draft.
* If we're in a situation where we can't ask the user (eg the user pressed "home"), then we should save the draft like a multi-recipient/zero-recipient draft (or like this recipient has no existing thread yet).

Ayman, advice about the 2 previous points ?

Comment 47

[Al Tsai [:atsai]]

[QA] Remove burirun1 because it's v1.3 feature

Comment 48

[Caio Lima(:caiolima)]

ping Ayman?

Comment 49

[Caio Lima(:caiolima)]

(In reply to Caio Lima(:caiolima) from comment #48)
> ping Ayman?

Sorry for this comment above, I was going to ask someting that has already been answered. =)

Comment 50

[Julien Wajsberg [:julienw]]

Caio, for your information, Ayman is currently drafting (ah ah) flows for the Draft support. I think this should be ready in this week !

Comment 51

[ayman maat :maat]

removed ni? to me by mistake whist doing some bug admin. reinstating it now

Comment 53

[Rick Waldron [:rwaldron]]

(In reply to Wilfred Mathanaraj [:WDM] from comment #52)
> 
> *** This bug has been marked as a duplicate of bug 919971 ***

This is where all of the work for draft support has taken place.

Comment 54

[Joe Cheng [:jcheng] (please needinfo)]

triage: 1.3+, its a commited feature in v1.3

Comment 55

[Caio Lima(:caiolima)]

Any updates?

Comment 56

[Julien Wajsberg [:julienw]]

Hey Caio,

is it ok if you focus on the notification bug, and the Bocoup team is taking over here ?

Comment 57

[Caio Lima(:caiolima)]

No problem to me ;)

Comment 58

[Julien Wajsberg [:julienw]]

This bug was made a meta, see the dependencies for the actual bug where work will be done.
Reseting the assignee here then.

Thanks Caio :)

Comment 59

[ayman maat :maat]

Attachment: FFOS_MessageApp_V1.3_20131031_V6.0.pdf

**RELEASE NOTE**

new wireframes
- Drafts : Inbox
- Drafts : Save/discard layer
- Drafts : Draft message module options
- Drafts : Message thread
- Drafts : Inbox options

updated wireframes
- none

deleted wireframes
- none

new flows
- Drafts : Save as draft from within messages app
- Drafts : Save as draft when navigating away from messages app
- Drafts : Opening draft messages from within thread

updated flows
Subject Flows section divider
- correct bug now cited. (i was referencing the wrong ones)

deleted flows
- none

Comment 60

[Victoria Gerchinhoren [:vicky]]

Attachment: Visual Design. Inbox Draft ALL tab on

Comment 61

[Victoria Gerchinhoren [:vicky]]

Attachment: Visual Design. Inbox DRAFTs tab on

Comment 62

[Victoria Gerchinhoren [:vicky]]

Attachment: Visual Design. Thread Draft

Comment 63

[Victoria Gerchinhoren [:vicky]]

Attachment: Visual inbox spec

Comment 64

[Victoria Gerchinhoren [:vicky]]

Attachment: Visual thread spec

Comment 65

[Victoria Gerchinhoren [:vicky]]

Attachment: Draft Icon inbox

Comment 66

[Rick Waldron [:rwaldron]]

Thanks Victoria!

Comment 67

[Adam Hyland [:protonk]]

Attachment: Proposed draft flow

The current [spec for Drafts](https://bugzilla.mozilla.org/attachment.cgi?id=825308) incorporates a requirement to save multiple draft messages per recipient by creating a tab for drafts and messages in the thread and thread list UIs. We feel this creates a few problems.

* We add needless complexity to the UX/UI while targeting unlikely edge cases--no other platform splits drafts from messages in an entirely new tab (in the thread list or especially the thread view itself).
* If I begin composing a reply in an ongoing thread, then navigate away, the following things have to happen for me to navigate back and send the drafted reply after I tap on the thread in question:
  * If the drafts tab has focus;
    * Long press on a draft message where you are presented with a menu offering 4 choices--send, edit, delete and cancel;
    * Press send.
  * Tap on the drafts tab to bring it into focus;
* The model and new UI element represent a considerable effort which may adversely effect the timeline of the drafts feature. 

Our proposed solution 

While composing a message--any message--a user navigates away and the message is stored as a draft. The saved draft may be associated with an existing thread or be associated with a new thread which only contains the draft.

Navigating to a thread view with 1 draft will populate the message composer with the draft content. The user can then send or edit the draft just as they would with a normal message

Navigating to a thread view with 2 or more drafts will show the drafts inline in the thread view (at the bottom, not interleaving past message). The user can then select a draft to edit, send or discard.

We feel 0-1 drafts per recipients is the modal use case and our implementation should make those interactions as smooth as possible. Added friction in an application built around instantaneous communication is nearly always bad from a user perspective

For someone texting, drafts are just messages they haven't sent yet. And in the text message convention, messages the user hasn't sent yet are sitting in the message composer.

Details are available as an attachment

Comment 68

[Julien Wajsberg [:julienw]]

Adam, Ayman, I think something is missing in the wireframe:
* we should see the drafts in the 'all messages' tab too, ordered by the timestamps of messages and drafts.

Adam, would that solve your issue?

Comment 69

[Adam Hyland [:protonk]]

I think our desired path is to show draft messages (where it is appropriate to show them in the timeline) inline and dispense with the drafts tab entirely. If the drafts tab itself is required, then drafts should appear in both places. 
(In reply to Julien Wajsberg [:julienw] from comment #68)
> Adam, Ayman, I think something is missing in the wireframe:
> * we should see the drafts in the 'all messages' tab too, ordered by the
> timestamps of messages and drafts.
> 
> Adam, would that solve your issue?

Comment 70

[Julien Wajsberg [:julienw]]

(In reply to Adam Hyland [:protonk] from comment #67)

> Our proposed solution 
> 
> While composing a message--any message--a user navigates away and the
> message is stored as a draft. The saved draft may be associated with an
> existing thread or be associated with a new thread which only contains the
> draft.
> 
> Navigating to a thread view with 1 draft will populate the message composer
> with the draft content. The user can then send or edit the draft just as
> they would with a normal message

* What happens if the user simply wants to compose a new message for this recipient? Populating with the draft content goes in the way of this use case.

> 
> Navigating to a thread view with 2 or more drafts will show the drafts
> inline in the thread view (at the bottom, not interleaving past message).
> The user can then select a draft to edit, send or discard.

* What happens once there is a lot of draft messages ? (a lot could be 3 when the keyboard is displayed). This goes in the way of displaying the history when answering.

That's why interleaving using timestamps and having a separate tab to display all drafts is desirable.

Comment 71

[Adam Hyland [:protonk]]

We don't have to assimilate recipients for new draft messages necessarily. In this case we could create a new 'thread' with the draft message. 

(In reply to Julien Wajsberg [:julienw] from comment #70)
> (In reply to Adam Hyland [:protonk] from comment #67)
> * What happens if the user simply wants to compose a new message for this
> recipient? Populating with the draft content goes in the way of this use
> case.

We can interleave drafts. I'll see if I can think of a way to do this without creating a drafts tab.

>
> > Navigating to a thread view with 2 or more drafts will show the drafts
> > inline in the thread view (at the bottom, not interleaving past message).
> > The user can then select a draft to edit, send or discard.
> 
> * What happens once there is a lot of draft messages ? (a lot could be 3
> when the keyboard is displayed). This goes in the way of displaying the
> history when answering.
> 
> That's why interleaving using timestamps and having a separate tab to
> display all drafts is desirable.

I think broadly our goal is to have the user interaction match the expectations of the medium and be minimally disruptive to the most common use cases. Preloading the composer for most situations feels like the minimally disruptive solution and it has the added bonus of making sure the program works to present the same state (in the eyes of the user) when you return after switching away.

Comment 72

[Rick Waldron [:rwaldron]]

Julien, 

The problem is that the current spec for the "drafts" feature is way too complex and doesn't really belong in a Messaging app—more like an Email app. We had a call with Ayman and he's informed us that Drafts incurred a set of requirements directly from Mozilla that are undesirable to him and happen to also be undesirable to us. We're committed to implementing whatever Mozilla wants, but the "Drafts" tabs and the fact that any conversation can have infinite drafts associated with it are just plain _awful_. What happens when there are 100 drafts for 100 conversations and each draft has 100 images in it?

Comment 73

[Julien Wajsberg [:julienw]]

> I think broadly our goal is to have the user interaction match the expectations of the medium 
> and be minimally disruptive to the most common use cases. Preloading the composer for most 
> situations feels like the minimally disruptive solution and it has the added bonus of making 
> sure the program works to present the same state (in the eyes of the user) when you return 
> after switching away.

In the proposed wireframe (assuming the draft are interleaved in the "all messages" tab, this situation is just one tap away... I don't see how this is disruptive.

That said, in the future, we could have some heuristics like "if the draft is less than x minutes old, and no messages has been sent or received since then, let's prefill". But we can refine this later, this is just a detail.

> What happens when there are 100 drafts for 100 conversations and each draft has 100 images in it?

I don't think anything different would happen than for normal conversations...

I don't mind expiring drafts after a delay or after an arbitrary count. However, I feel that for 1.3 we can do just what the WF is saying, and refine in later versions.

Anyway I'm just answering for Ayman here, I'm open to whatever Ayman decides. I don't understand the "Mozilla requirements" part as my understanding is that the wireframes come from a discussion between Ayman and me, and a TEF validation.

Comment 74

[Adam Hyland [:protonk]]

I think we have an opportunity to use drafts to make messages less complex, not more. Right now if I navigate to a thread and type a message then navigate away to the inbox (not pressing the home button), I am interrupted by a prompt requiring I discard the message or 'cancel' to return to the message composer. If we preload draft content in the message composer we can eliminate this prompt entirely. I can compose a message, navigate to the inbox and then return to the thread and send the message without a single dialog box. That's how iOS does it, it's how Windows Phone does it, it's how Android does it. It is cold comfort that a drafts tab represents marginally more complexity when our UI is already more complex than other messages apps on the market.

(In reply to Julien Wajsberg [:julienw] from comment #73)
> > I think broadly our goal is to have the user interaction match the expectations of the medium 
> > and be minimally disruptive to the most common use cases. Preloading the composer for most 
> > situations feels like the minimally disruptive solution and it has the added bonus of making 
> > sure the program works to present the same state (in the eyes of the user) when you return 
> > after switching away.
> 
> In the proposed wireframe (assuming the draft are interleaved in the "all
> messages" tab, this situation is just one tap away... I don't see how this
> is disruptive.

Also, under the v6 spec, there is no positive action a user can undertake to generate a draft. If the goal is to provide multiple drafts as a feature (and as Rick said, we're not inclined to believe this is a feature), then the workflow must include some action to save a message as a draft, i.e. not through exiting the message composer. Otherwise if our user stories include a user who wants to store multiple drafts, the mechanism to do so is composing a new message, navigating away, returning and composing another message.

Comment 75

[Julien Wajsberg [:julienw]]

I think we can remove the "discard" dialog even when not prefilling the composer.

I already made that remark to Ayman, and we had a compromise where we would keep this dialog in 1.3, but we can revisit this choice later.

Ayman, I'd very much like that you comment here ;)

Comment 76

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #75)
> I think we can remove the "discard" dialog even when not prefilling the
> composer.
> 
> I already made that remark to Ayman, and we had a compromise where we would
> keep this dialog in 1.3, but we can revisit this choice later.
> 
> Ayman, I'd very much like that you comment here ;)

Yeh it can go.

Comment 77

[Rick Waldron [:rwaldron]]

(In reply to ayman maat :maat from comment #76)
> (In reply to Julien Wajsberg [:julienw] from comment #75)
> > I think we can remove the "discard" dialog even when not prefilling the
> > composer.
> > 
> > I already made that remark to Ayman, and we had a compromise where we would
> > keep this dialog in 1.3, but we can revisit this choice later.
> > 
> > Ayman, I'd very much like that you comment here ;)
> 
> Yeh it can go.


Shall I bug-morph #935177 to be a "removal", instead of "update"?

Comment 78

[Rick Waldron [:rwaldron]]

Sorry, that's https://bugzilla.mozilla.org/show_bug.cgi?id=935177

Comment 79

[Julien Wajsberg [:julienw]]

Haven't followed everything but if now we want to remove this dialog, then yes, please go ahead

Comment 80

[ayman maat :maat]

Attachment: FFOS_MessageApp_V1.3_20131119_V7.0.pdf

**Release note***

new wireframes
- Subject : maximum length of subject reached
- Subject : maximum length of message reached
- Subject : subject field
- Message report : outgoing message report

updated wireframes
- none

deleted wireframes
- none

new flows
- Message report : View report for received message

updated flows
Delivery / Read report : Setting reports from within phone settings
renamed: ‘Message report : Setting reports from within phone settings’

Delivery / Read report : Setting reports from message app inbox
renamed: ’Message report : Setting reports from message app inbox’

Delivery / Read report : Setting reports from within new message
renamed: ‘Message report : Setting reports from within new message’

Delivery / Read report : Setting reports from within message thread
renamed: ’Message report : Setting reports from within message thread’

Delivery / Read report : View report from thread
renamed: ‘Message report : View report for outgoing message from thread’
- ‘View message details’ CTA removed from frame ‘2. Message module options menu’
- annotation to frame ‘3. Message Report’ updated to reflect agreement in email thread

Delivery / Read report : View delivery report from notification
renamed: ’Message report : View delivery report from notification’

Delivery / Read report : View read report from notification
renamed: ‘Message report : View read report from notification’

deleted flows
- none

Comment 81

[ayman maat :maat]

Attachment: FFOS_MessageApp_V1.3_20131125_V8.0.pdf

**Release note***

new wireframes
- none

updated wireframes
- none

deleted wireframes
Drafts : Message thread
Due to removal of specification for saving multiple drafts in a message thread

Drafts : Draft message module options
Screen obsolete due to removal of specification for saving multiple
drafts in a message thread

new flows
- none

updated flows
Drafts : Save as draft from within messages app
Removal of specification for saving multiple drafts in a message thread

Drafts : Save as draft when navigating away from messages app
Removal of specification for saving multiple drafts in a message thread

Drafts : Opening draft messages from within thread
Removal of specification for saving multiple drafts in a message thread

deleted flows
- none

Comment 82

[Evelyn Eastmond [:evhan55]]

(In reply to ayman maat :maat from comment #81)
> Created attachment 8337617 [details]
> FFOS_MessageApp_V1.3_20131125_V8.0.pdf
> 
> **Release note***
> 
> new wireframes
> - none
> 
> updated wireframes
> - none
> 
> deleted wireframes
> Drafts : Message thread
> Due to removal of specification for saving multiple drafts in a message
> thread
> 
> Drafts : Draft message module options
> Screen obsolete due to removal of specification for saving multiple
> drafts in a message thread
> 
> new flows
> - none
> 
> updated flows
> Drafts : Save as draft from within messages app
> Removal of specification for saving multiple drafts in a message thread
> 
> Drafts : Save as draft when navigating away from messages app
> Removal of specification for saving multiple drafts in a message thread
> 
> Drafts : Opening draft messages from within thread
> Removal of specification for saving multiple drafts in a message thread
> 
> deleted flows
> - none

Just to confirm:

1) On page 36, the two 'Save as draft' dialogs are no longer necessary right? Based on your confirmation above in this thread to remove them?

2) On page 38, panel 6, are we now adding a new 'Replace existing Draft' dialog?

Comment 83

[Julien Wajsberg [:julienw]]

Hey Evelyn,

yep, I think you're right, we forgot this.

And therefore, I'd say, no "replace existing draft" dialog either.

Let's wait for Ayman's answer though!

Comment 84

[ayman maat :maat]

(In reply to Evelyn Eastmond [:evhan55] from comment #82)
> (In reply to ayman maat :maat from comment #81)
> 
> Just to confirm:
> 
> 1) On page 36, the two 'Save as draft' dialogs are no longer necessary
> right? Based on your confirmation above in this thread to remove them?

We have brought them back because if we are saving multiple draft new messages it is felt that the act of removing an automatically saved draft or avoiding a draft from being automatically saved has more user overhead than the perceived time saved (for the user) by removing these screen screens and automatically saving drafts. Consider it from this PoV: The sheet model afforded by Haida means that any page can be book marked. This means that the new message composer can be bookmarked and therefore accesses from where the bookmarks are kept without having to got through the message app itself. If the new message composer is launched from the bookmarks and information is input into the ‘to field’ and into the ‘message field’ and we do not have these screen that offer the user the choice of saving or discarding has only one option to avoid the message being automatically saved as a draft:

- manually delete the content of the ‘message field’ and the ‘to field’ then close the new message composer

which takes more time than interacting with this layer.

If the message is automatically saved as draft the user has to do the following to remove the unwanted draft from their inbox:

1) close the new message composer with content in the ‘message field’ and/or the ‘to field’ (draft is saved)
2) manually navigate to the message app short cut and select it to open the message app
3) in the message app inbox long press the draft that the user wishes to delete
4) select delete message from the layer (i deleted this page from the wireframes by mistake yesterday, but you can see it in page 42 of FFOS_MessageApp_V1.3_20131119_V7.0) 

Which also has far more time/effort overhead for the end user.

…so though on paper the the two 'Save as draft' dialogs On page 36 may seem unnecessary for the reasons above, at the moment, we feel it is a time saving step. We would like to see the draft functionality with these screens in action before deciding to remove them

> 2) On page 38, panel 6, are we now adding a new 'Replace existing Draft'
> dialog?

yes

Comment 85

[José Vittone]

Attachment: Visual Design – Drafts in Messages Inbox

Since the wireframes have changed, this visuals reflect the update.

Comment 86

[José Vittone]

Attachment: Visual inbox spec

Comment 87

[Evelyn Eastmond [:evhan55]]

(In reply to ayman maat :maat from comment #84)
> (In reply to Evelyn Eastmond [:evhan55] from comment #82)
> > (In reply to ayman maat :maat from comment #81)
> > 
> > Just to confirm:
> > 
> > 1) On page 36, the two 'Save as draft' dialogs are no longer necessary
> > right? Based on your confirmation above in this thread to remove them?
> 
> We have brought them back because if we are saving multiple draft new
> messages it is felt that the act of removing an automatically saved draft or
> avoiding a draft from being automatically saved has more user overhead than
> the perceived time saved (for the user) by removing these screen screens and
> automatically saving drafts. Consider it from this PoV: The sheet model
> afforded by Haida means that any page can be book marked. This means that
> the new message composer can be bookmarked and therefore accesses from where
> the bookmarks are kept without having to got through the message app itself.
> If the new message composer is launched from the bookmarks and information
> is input into the ‘to field’ and into the ‘message field’ and we do not have
> these screen that offer the user the choice of saving or discarding has only
> one option to avoid the message being automatically saved as a draft:
> 
> - manually delete the content of the ‘message field’ and the ‘to field’ then
> close the new message composer
> 
> which takes more time than interacting with this layer.
> 
> If the message is automatically saved as draft the user has to do the
> following to remove the unwanted draft from their inbox:
> 
> 1) close the new message composer with content in the ‘message field’ and/or
> the ‘to field’ (draft is saved)
> 2) manually navigate to the message app short cut and select it to open the
> message app
> 3) in the message app inbox long press the draft that the user wishes to
> delete
> 4) select delete message from the layer (i deleted this page from the
> wireframes by mistake yesterday, but you can see it in page 42 of
> FFOS_MessageApp_V1.3_20131119_V7.0) 
> 
> Which also has far more time/effort overhead for the end user.
> 
> …so though on paper the the two 'Save as draft' dialogs On page 36 may seem
> unnecessary for the reasons above, at the moment, we feel it is a time
> saving step. We would like to see the draft functionality with these screens
> in action before deciding to remove them
> 
> > 2) On page 38, panel 6, are we now adding a new 'Replace existing Draft'
> > dialog?
> 
> yes

Hi Ayman,

Thank you for the clarifications, sounds good.

One more question, what about the cases where the user leaves the app completely (closes the app from the task manager, hides the app, or turns off the phone).  Right now, drafts are saved automatically in these cases without a dialog box asking if that's desired.

I am not sure if we are able to intercept the 'onVisibilityChange' event to show a dialog in this instance.  I can check more closely.

You don't mention a dialog for these cases in the spec, but I am pointing out that this would be inconsistent across the app.  Sometimes (within app), there is a dialog asking if you want to save the draft, and sometimes (leaving the app), the drafts would save automatically.

Thoughts?
Evelyn

Comment 88

[Adam Hyland [:protonk]]

I'll admit to being a little confused as to the reasoning here. We're going to ship 1.3 phones and they will contain a dialog box that only makes sense for a specific use case (bookmarking the new message composer) which isn't possible until 1.4. In the meantime number of users for whom this dialog will be beneficial is by definition 0.

Is there a user story for 1.3 which motivates this dialog? If not, how is this superior to tracking the behavior of the new message composer in a 1.4 bug? 

(In reply to ayman maat :maat from comment #84)

> We have brought them back because if we are saving multiple draft new
> messages it is felt that the act of removing an automatically saved draft or
> avoiding a draft from being automatically saved has more user overhead than
> the perceived time saved (for the user) by removing these screen screens and
> automatically saving drafts. Consider it from this PoV: The sheet model
> afforded by Haida means that any page can be book marked. This means that
> the new message composer can be bookmarked and therefore accesses from where
> the bookmarks are kept without having to got through the message app itself.
> If the new message composer is launched from the bookmarks and information
> is input into the ‘to field’ and into the ‘message field’ and we do not have
> these screen that offer the user the choice of saving or discarding has only
> one option to avoid the message being automatically saved as a draft:

Comment 89

[Julien Wajsberg [:julienw]]

Adam, Evelyn,

talking with Ayman, I understood that the reasoning here is that it's something rather easy to add/remove, and since we have a dialog now, we might as well keep it and see if this feels right. We might as well remove it before shipping 1.3 if we finally all agree that it's not right.

I think the best UX should be a notice with an undo system (Gmail style), which will work both in "pressing back button" and "hiding the app" cases, but this is not happening now.

Comment 90

[ayman maat :maat]

removing ni? to me.. i think Julian covers this in comment 89.

Comment 91

[Julien Wajsberg [:julienw]]

José, Ayman, I have a question for you about the Inbox Visual Design.

We can have these drafts:
* a "pure draft", that is a "new message draft", has is semi transparent and has the pencil icon
* a "thread draft" has the pencil icon but is fully opaque
* a normal thread does not have the pencil icon and is fully opaque.
* A normal thread can have the unread icon.

Now, what should we have for threads that have a draft but there is an unread message in it? If I'm not mistaken, this means the most recent message in the thread is more recent than when the draft was created (because when the draft is created, all messages are read).

This is both a UX+Visual Design issue, hence my request to you here :)

Comment 92

[José Vittone]

(In reply to Julien Wajsberg [:julienw] from comment #91)
> We can have these drafts:
> * a "pure draft", that is a "new message draft", has is semi transparent and has the pencil icon
> * a "thread draft" has the pencil icon but is fully opaque
> * a normal thread does not have the pencil icon and is fully opaque.
> * A normal thread can have the unread icon.
Yes.


> Now, what should we have for threads that have a draft but there is an
> unread message in it? If I'm not mistaken, this means the most recent
> message in the thread is more recent than when the draft was created
> (because when the draft is created, all messages are read).
We discuss this with Ayman, and the rule would be: "The last event is the most important". So, in this case, if there's a new message and draft, the new message is indicated. If new message is read and draft still exists, show draft.

Please ask if it's not clear.

Comment 93

[Julien Wajsberg [:julienw]]

This is clear, thanks!

Should be easy to do in CSS only.

Comment 94

[Rick Waldron [:rwaldron]]

Feature branch merged https://github.com/mozilla-b2g/gaia/pull/14847

Comment 96

[Jason Smith [:jsmith]]

This was already moved to 1.4 & we're no longer taking features for 1.3, so clearing blocking flag.

Comment 97

[buri.blff]

Sorry to urging you, but our leader wants this feature on v1.3.

Comment 98

[Julien Wajsberg [:julienw]]

I'm sorry, this is not really possible.

We're still fixing bugs (just look at the dependency line!), and we didn't have a whole QA run on this feature yet. So this would be terribly risky.