Bug 879143 (messaging-drafts)

[Meta][Messages] Add support for saved message drafts

RESOLVED FIXED

Status

Firefox OS
Gaia::SMS
P2
normal
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: sync-1, Unassigned)

Tracking

({meta})

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph
Bug Flags:
sec-review +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments, 11 obsolete attachments)

1.46 KB, patch
Details | Diff | Splinter Review
2.97 KB, application/zip
Details
52 bytes, text/plain
Details
1.28 MB, application/pdf
Details
71.59 KB, image/png
Details
88.29 KB, image/png
Details
(Reporter)

Description

4 years ago
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:

Updated

4 years ago
blocking-b2g: --- → tef?

Updated

4 years ago
Component: Gaia → Gaia::SMS
triage with tef: this is feature request. koi? for future consideration
blocking-b2g: tef? → koi?
Duplicate of this bug: 840519
Blocks: 891754
blocking-b2g: koi? → ---
Duplicate of this bug: 905560

Comment 4

4 years ago
This feature is very important to end user, why not have it implemented in v1.2?
blocking-b2g: --- → koi?

Comment 5

4 years ago
Sorry for urging you, but it really needed by v1.1.
blocking-b2g: koi? → leo?
(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.
Summary: [Buri][IOT]When writing an SMS, not found option to save as draft. → [Messages] Add support for saved message drafts
Sorry, it's too late for new features in v1.1.  Jason mentioned that it may even be too late for v1.2 features ...
blocking-b2g: leo? → koi?
add to backlog 891754
likely a dupe
blocking-b2g: koi? → ---
Duplicate of this bug: 911622

Comment 10

4 years ago
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.

BRs,
Attachment #800605 - Flags: feedback?(vyang)
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.
(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
Attachment #800605 - Flags: feedback?(vyang)
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?
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.
Flags: needinfo?(vyang)

Comment 15

4 years ago
(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.
(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.
Flags: needinfo?(vyang)
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;
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

4 years ago
Dears, it should be implemented in v1.2, there is already draft saving feature in email app.
blocking-b2g: --- → koi?
(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 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 :)
I'll send a mail to the webapi ML tomorrow.
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
(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.
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 =)
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?
(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.
NeedInfo Ayman as a reminder flag for the draft functionality.
Flags: needinfo?(aymanmaat)

Comment 28

4 years ago
(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

4 years ago
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
Flags: needinfo?(aymanmaat)
(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.
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.
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

4 years ago
(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.
Flags: needinfo?(felash)
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 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?
Blocks: 919971

Comment 36

4 years ago
(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.
No longer blocks: 919971
blocking-b2g: koi? → 1.3?
Ayman: Yes. I guess that using the "visibilitychange", as Julien said, will solve most of our cases to save the draft.
(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.
Flags: needinfo?(felash) → needinfo?(aymanmaat)
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 ?
Assignee: nobody → ticaiolima
Whiteboard: [mentor=:julienw]
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?
Created attachment 809418 [details] [diff] [review]
visibility_test
(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.
(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.
Whiteboard: [mentor=:julienw] → [mentor=:julienw], burirun1
(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?
Created attachment 809625 [details] [review]
draft-prototype

I've started to work on draft implementation. =)
Attachment #804833 - Attachment is obsolete: true

Updated

4 years ago
Blocks: 919971
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

4 years ago
[QA] Remove burirun1 because it's v1.3 feature
Whiteboard: [mentor=:julienw], burirun1 → [mentor=:julienw]
ping Ayman?
(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. =)
Caio, for your information, Ayman is currently drafting (ah ah) flows for the Draft support. I think this should be ready in this week !

Updated

4 years ago
Flags: needinfo?(aymanmaat)

Comment 51

4 years ago
removed ni? to me by mistake whist doing some bug admin. reinstating it now
Flags: needinfo?(aymanmaat)
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 919971
(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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Updated

4 years ago
Attachment mime type: text/plain → text/x-github-pull-request
triage: 1.3+, its a commited feature in v1.3
blocking-b2g: 1.3? → 1.3+
Any updates?
Hey Caio,

is it ok if you focus on the notification bug, and the Bocoup team is taking over here ?
Flags: needinfo?(ticaiolima)
Status: REOPENED → NEW
Whiteboard: [mentor=:julienw]
Depends on: 931083
Depends on: 931091
Depends on: 931095
Depends on: 931096
No problem to me ;)
Flags: needinfo?(ticaiolima)
Assignee: ticaiolima → nobody
Keywords: meta
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 :)
Attachment #800605 - Attachment is obsolete: true
Attachment #809625 - Attachment is obsolete: true

Comment 59

4 years ago
Created attachment 825308 [details]
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
Attachment #807812 - Attachment is obsolete: true
Flags: needinfo?(aymanmaat)
Depends on: 935177
Alias: messaging-drafts
Created attachment 829130 [details]
Visual Design. Inbox Draft ALL tab on
Created attachment 829131 [details]
Visual Design. Inbox DRAFTs tab on
Created attachment 829132 [details]
Visual Design. Thread Draft
Created attachment 829133 [details]
Visual inbox spec
Created attachment 829134 [details]
Visual thread spec
Created attachment 829212 [details]
Draft Icon inbox
Thanks Victoria!
Depends on: 936639
Depends on: 936641
Depends on: 936644
Depends on: 936645
Depends on: 936646
Depends on: 936647
Depends on: 936648
Depends on: 936649
Target Milestone: --- → 1.3 Sprint 5 - 11/22
Created attachment 829533 [details]
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
Flags: needinfo?(felash)
Flags: needinfo?(aymanmaat)
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?
Flags: needinfo?(felash)
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?
(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.
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.
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?
> 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.
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.
Depends on: 937565
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

4 years ago
(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.
Flags: needinfo?(aymanmaat)
(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"?
Flags: needinfo?(felash)
Flags: needinfo?(aymanmaat)
Sorry, that's https://bugzilla.mozilla.org/show_bug.cgi?id=935177
Haven't followed everything but if now we want to remove this dialog, then yes, please go ahead
Flags: needinfo?(felash)

Comment 80

4 years ago
Created attachment 8334459 [details]
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
Attachment #825308 - Attachment is obsolete: true
Flags: needinfo?(aymanmaat)
Target Milestone: 1.3 Sprint 5 - 11/22 → 1.3 Sprint 6 - 12/6
Summary: [Messages] Add support for saved message drafts → [Meta][Messages] Add support for saved message drafts

Comment 81

4 years ago
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
Attachment #8334459 - Attachment is obsolete: true
(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?
Flags: needinfo?(aymanmaat)
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

4 years ago
(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
Flags: needinfo?(aymanmaat)
Depends on: 943395

Updated

4 years ago
Attachment #829132 - Attachment is obsolete: true

Updated

4 years ago
Attachment #829134 - Attachment is obsolete: true

Updated

4 years ago
Attachment #829131 - Attachment is obsolete: true

Comment 85

4 years ago
Created attachment 8338543 [details]
Visual Design – Drafts in Messages Inbox

Since the wireframes have changed, this visuals reflect the update.
Attachment #829130 - Attachment is obsolete: true

Comment 86

4 years ago
Created attachment 8338588 [details]
Visual inbox spec
Attachment #829133 - Attachment is obsolete: true
Depends on: 943633
(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
Flags: needinfo?(felash)
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:
Flags: needinfo?(aymanmaat)
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.
Flags: needinfo?(felash)

Comment 90

4 years ago
removing ni? to me.. i think Julian covers this in comment 89.
Flags: needinfo?(aymanmaat)
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 :)
Flags: needinfo?(vittone)
Flags: needinfo?(aymanmaat)

Comment 92

3 years ago
(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.
Flags: needinfo?(vittone)
Flags: needinfo?(aymanmaat)
This is clear, thanks!

Should be easy to do in CSS only.
Depends on: 947211
Depends on: 947215
Depends on: 947217
Depends on: 946989
Depends on: 946996
Depends on: 946995
blocking-b2g: 1.3+ → 1.4?
Target Milestone: 1.3 Sprint 6 - 12/6 → ---
Depends on: 949524
Depends on: 949137
Depends on: 951331
Depends on: 951339
Depends on: 950914
Depends on: 952225
Feature branch merged https://github.com/mozilla-b2g/gaia/pull/14847
Status: NEW → RESOLVED
Last Resolved: 4 years ago3 years ago
Resolution: --- → FIXED
Duplicate of this bug: 957000

Updated

3 years ago
blocking-b2g: 1.4? → 1.3?
This was already moved to 1.4 & we're no longer taking features for 1.3, so clearing blocking flag.
blocking-b2g: 1.3? → ---

Comment 97

3 years ago
Sorry to urging you, but our leader wants this feature on v1.3.
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.
Flags: sec-review?(stephouillon)
Depends on: 963071
Flags: sec-review?(stephouillon) → sec-review+
Depends on: 972498
You need to log in before you can comment on or make changes to this bug.