Closed
Bug 919971
Opened 11 years ago
Closed 11 years ago
[User Story][Messages] Draft mode support
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: wmathanaraj, Unassigned)
References
Details
(Keywords: feature, Whiteboard: [ucid:Comms26, ft:comms])
Attachments
(1 file, 2 obsolete files)
(deleted),
application/pdf
|
Details |
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
Updated•11 years ago
|
Depends on: messaging-drafts
Updated•11 years ago
|
No longer depends on: messaging-drafts
Updated•11 years ago
|
QA Contact: isabelrios
Reporter | ||
Updated•11 years ago
|
Flags: in-moztrap?(jhammink)
Summary: [User Story] Draft mode support for SMS and MMS → [User Story] Draft mode support for SMS and MMS (FFOS 1.3)
Updated•11 years ago
|
Summary: [User Story] Draft mode support for SMS and MMS (FFOS 1.3) → [User Story] Draft mode support for Messages (FFOS 1.3)
Updated•11 years ago
|
Summary: [User Story] Draft mode support for Messages (FFOS 1.3) → [Messages] Draft mode support (FFOS 1.3)
Updated•11 years ago
|
Depends on: messaging-drafts
Updated•11 years ago
|
Summary: [Messages] Draft mode support (FFOS 1.3) → [User Story][Messages] Draft mode support (FFOS 1.3)
Updated•11 years ago
|
Whiteboard: [ucid:Comms26, 1.3:p1]
Comment 1•11 years ago
|
||
Change in-moztrap tag and start to work on test cases
Flags: in-moztrap?(jhammink) → in-moztrap?(pyang)
Updated•11 years ago
|
blocking-b2g: 1.3? → 1.3+
Comment 3•11 years ago
|
||
**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•11 years ago
|
||
Because the target milestone for bug 931095 is sprint 6, mark the target milestone for this bug to sprint 6 as well.
Target Milestone: --- → 1.3 Sprint 6 - 12/6
Comment 5•11 years ago
|
||
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•11 years ago
|
||
(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•11 years ago
|
||
Thanks, I'll fix the test cases based on that
Updated•11 years ago
|
Whiteboard: [ucid:Comms26, 1.3:p1] → [ucid:Comms26, 1.3:p1, ft:comms]
Comment 8•11 years ago
|
||
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.
Flags: in-moztrap?(pyang) → in-moztrap+
Comment 9•11 years ago
|
||
**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 #825309 -
Attachment is obsolete: true
Comment 10•11 years ago
|
||
> 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.
Flags: needinfo?(waldron.rick)
Flags: needinfo?(felash)
Updated•11 years ago
|
Flags: needinfo?(aymanmaat)
Comment 11•11 years ago
|
||
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.
Flags: needinfo?(felash)
Comment 12•11 years ago
|
||
**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 #8334458 -
Attachment is obsolete: true
Comment 13•11 years ago
|
||
(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•11 years ago
|
||
(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 :)
Flags: needinfo?(waldron.rick)
Comment 15•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
(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•11 years ago
|
||
(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•11 years ago
|
||
(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•11 years ago
|
||
(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•11 years ago
|
||
removing ni? to me as we are on track as per comment 20
Flags: needinfo?(aymanmaat)
Updated•11 years ago
|
blocking-b2g: 1.3+ → 1.4?
Summary: [User Story][Messages] Draft mode support (FFOS 1.3) → [User Story][Messages] Draft mode support
Whiteboard: [ucid:Comms26, 1.3:p1, ft:comms] → [ucid:Comms26, ft:comms]
Target Milestone: 1.3 Sprint 6 - 12/6 → ---
Comment 22•11 years ago
|
||
team decided to move this to 1.4
Updated•11 years ago
|
No longer blocks: comms_1.3_committed, 937014
Reporter | ||
Updated•11 years ago
|
Blocks: 1.4-comms-committed
Comment 23•11 years ago
|
||
This bug's dependency tree is now cleared.
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 25•11 years ago
|
||
clear 1.4? because it has already landed and it is a requested feature
blocking-b2g: 1.4? → ---
Updated•11 years ago
|
No longer blocks: 1.4-comms-committed
You need to log in
before you can comment on or make changes to this bug.
Description
•