919971 - [User Story][Messages] Draft mode support

Status: VERIFIED FIXED

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

Description

[Wilfred Mathanaraj [:WDM]]

User Story:

As a user I want to be able to save SMS/MMS, as a draft, while composing. 


Acceptance Criteria:

AC 1: I want to be able to save multiple messages in draft mode.

AC 2: As  a user, when I open the messages app,  I want to see the saved draft messages indicated differently to the sent/received messages.

AC 3: As a user I want the sms/mms app to auto save messages that i compose at regular interval in draft mode

Comment 1

[Paul Yang [:pyang] (away)]

Change in-moztrap tag and start to work on test cases

Comment 3

[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 4

[Kai-Chih Hu [:khu]]

Because the target milestone for bug 931095 is sprint 6, mark the target milestone for this bug to sprint 6 as well.

Comment 5

[Paul Yang [:pyang] (away)]

hi Ayman, do you think we need to have save/discard layer? since return to homescreen will save draft automatically, should the user behavior be the same?

Comment 6

[ayman maat :maat]

(In reply to Paul Yang [: pyang] from comment #5)
> hi Ayman, do you think we need to have save/discard layer? since return to
> homescreen will save draft automatically, should the user behavior be the
> same?

as i just indicated in comment 76 of bug 879143, the save/discard layer can be removed.

Comment 7

[Paul Yang [:pyang] (away)]

Thanks, I'll fix the test cases based on that

Comment 8

[Paul Yang [:pyang] (away)]

https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-tag=2352

Test cases for draft mode, please help to see if anything concern.

Comment 9

[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 10

[Evelyn Eastmond [:evhan55]]

> AC 3: As a user I want the sms/mms app to auto save messages that i compose
> at regular interval in draft mode

What does 'regular interval' mean?  Is it necessary for drafts to be saved automatically?  The only case I can think that matters if when the phone runs out of battery and you don't have time to exit the app, maybe? -> https://bugzilla.mozilla.org/show_bug.cgi?id=879143#c10

Otherwise, we are following the steps in https://bug879143.bugzilla.mozilla.org/attachment.cgi?id=8334459 pages 36 and 37 for when to save the draft.

Comment 11

[Julien Wajsberg [:julienw]]

Evelyn, I agree with you here, I don't think it's necessary to save at regular interval, we should have got all the cases of moving out of the composer.

Comment 12

[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 13

[Evelyn Eastmond [:evhan55]]

(In reply to Julien Wajsberg [:julienw] from comment #11)
> Evelyn, I agree with you here, I don't think it's necessary to save at
> regular interval, we should have got all the cases of moving out of the
> composer.

Okay, thank you!

Comment 14

[Rick Waldron [:rwaldron]]

(In reply to ayman maat :maat from comment #12)
> Created attachment 8337618 [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

Ayman,

Need a clarification on:

- Page 36, #2
- Page 38, #7, #8

These views still display multiple "no recipients" drafts (ie. drafts for "new message" without selected recipients), despite the change to a single draft model—where the last "new message" draft content will be shown in the "new message" compose view. Can you confirm?  

Displaying non-thread list content inline with thread list content will be particularly complicated with respect to re-rendering thread list items upon receipt of new messages, updating the "time" headers and the complete list re-rendering that occurs in the app (each full render will have to renegotiate the placement of this disparate data). This was one of the cases I had made during the group call. 

I'm guessing that the change was just overlooked? I understand that you have a massive amount of work on your plate right now and really appreciate your confirmation here :)

Comment 15

[Julien Wajsberg [:julienw]]

Hey Rick,

we discussed about that IRL before, and it doesn't work well to have the composer automatically filling in in that case. When the user presses the new message button, chances are he really wants an empty message, and prefilling stuff are in the middle of his way.

I also made the case that it wouldn't be that much work because there is no layout change:
* there is no full re-rendering now in the current master, except at the very first load or when this is initially empty (search for renderThreads in the app)
* finding the correct place is currently done using the DOM and dataset properties, therefore it should work perfectly well with non-thread elements too. In long term (or maybe now) we'll have an object holding the exact same information, so it's also a non-concern IMO.

That said, I agree this is more work than just prefilling the composer, but I'm confident this is needed work and that it's possible to do it in this timeframe.

Tell me if I'm wrong here and I can discuss with Ayman today.

Comment 16

[Julien Wajsberg [:julienw]]

About the first full rendering, I think this would be enough to:
* first display all the drafts we have with all the necessary metadata
* then loads the threads and insert them at the right place (which will just work when the dataset medatata are set on the drafts)

Comment 17

[Rick Waldron [:rwaldron]]

(In reply to Julien Wajsberg [:julienw] from comment #15)
> we discussed about that IRL before,

Do you mean before or after the conference meeting?  

> When the user presses the new message button, chances are he really wants an empty message, and prefilling stuff are in the middle of his way.

Originally I thought otherwise, but I can see your point and begin to agree.

Comment 18

[Rick Waldron [:rwaldron]]

(In reply to Julien Wajsberg [:julienw] from comment #16)
> About the first full rendering, I think this would be enough to:
> * first display all the drafts we have with all the necessary metadata
> * then loads the threads and insert them at the right place (which will just
> work when the dataset medatata are set on the drafts)

This works well until you reach "Edit Mode" and "Delete".

Comment 19

[Julien Wajsberg [:julienw]]

(In reply to Rick Waldron [:rwaldron] from comment #17)
> (In reply to Julien Wajsberg [:julienw] from comment #15)
> > we discussed about that IRL before,
> 
> Do you mean before or after the conference meeting?  

I mean after the meeting, when Ayman was moving the spec to single draft. (Full disclosure) Wilfred originally wanted things like you, but in the end we agreed that for the new message drafts, having several drafts was more natural.

> 
> > When the user presses the new message button, chances are he really wants an empty message, and prefilling stuff are in the middle of his way.
> 
> Originally I thought otherwise, but I can see your point and begin to agree.

;)

(In reply to Rick Waldron [:rwaldron] from comment #18)
> (In reply to Julien Wajsberg [:julienw] from comment #16)
> > About the first full rendering, I think this would be enough to:
> > * first display all the drafts we have with all the necessary metadata
> > * then loads the threads and insert them at the right place (which will just
> > work when the dataset medatata are set on the drafts)
> 
> This works well until you reach "Edit Mode" and "Delete".

I don't exactly see the point here.

Drafts will have something like "isNewMessageDraft=true" in a dataset, or have an id like "draft-#" where # is the draft id which will allow us to find it in an internal db to get information, or "draft-#" itself will be the key to find it in the internal db (we can imagine that we'll be able to do the same later for messages with a key "message-#").

I agree this is a little more work, however this is not difficult work nor massive work in my opinion. But tell me if you disagree and Ayman/we can coin a yet simpler spec.

Comment 20

[Rick Waldron [:rwaldron]]

(In reply to Julien Wajsberg [:julienw] from comment #19)
> > 
> > This works well until you reach "Edit Mode" and "Delete".
> 
> I don't exactly see the point here.

TBH I was just teasing you a little :)

I've implemented with your approach and have full "Edit Mode"/"Delete" support, everything is moving forward nicely.

Comment 21

[ayman maat :maat]

removing ni? to me as we are on track as per comment 20

Comment 22

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

team decided to move this to 1.4

Comment 23

[Rick Waldron [:rwaldron]]

This bug's dependency tree is now cleared.

Comment 24

[Paul Yang [:pyang] (away)]

Good job, thanks.

Comment 25

[David Scravaglieri [:scravag]]

clear 1.4? because it has already landed and it is a requested feature