1148719 - [Messages][Drafts] Improve UX for the case when user removes all messages from Conversation with existing draft

Status: RESOLVED WONTFIX

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

Description

[Alissa（leave from Mozilla）]

Attachment: logcat2.txt

[1.Description]:
[Nexus 5 v2.2&3.0][Flame2.2][Message]While we new a message, try to delete all the message of the number, the contents you editted will be saved as draft, but the recipient cannot be saved(this function is available in android).
Found at:16:42
see attachments:logcat2.txt, video2.3gp.

[2.Testing Steps]: 
1.Launch message.
2.Selecte a tread containing some message.
3.Input some words in content inut box.
4.Tap menu and select "Select Messages".
5.Tap "Select all" -> Delete-> Comfirm Delete.
6.A prompt page to save as draft pops up, then tap "Save as Draft".
7.Back to message list view and tap the draft message agian.
[3.Expected Result]: 
7.The recipient should be saved.

[4.Actual Result]: 
7.You can see the recipient is not saved.

[5.Reproduction build]: 
Device: Flame 2.2[Affected]
Build ID               20150327162502
Gaia Revision          473cd63f53c855299b719285d9b95e3f2910782f
Gaia Date              2015-03-27 20:14:43
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/b358619def45
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150327.194944
Firmware Date          Fri Mar 27 19:49:53 EDT 2015
Bootloader             L1TC000118D0

Device:Nexus5 3.0[Affected]
Build ID               20150327160203
Gaia Revision          9cc496cecc37d7a29f9279827cdf6e4891211f67
Gaia Date              2015-03-27 13:55:18
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/44e454b5e93b
Gecko Version          39.0a1
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150327.192727
Firmware Date          Fri Mar 27 19:27:40 EDT 2015
Bootloader             HHZ12d

Devicce:Nexus5 2.2[Affected]
Build ID               20150327162502
Gaia Revision          473cd63f53c855299b719285d9b95e3f2910782f
Gaia Date              2015-03-27 20:14:43
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/b358619def45
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150327.195950
Firmware Date          Fri Mar 27 20:00:03 EDT 2015
Bootloader             HHZ12d
[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
Free Test

Comment 1

[Alissa（leave from Mozilla）]

Attachment: 2.3gp

Comment 2

[Julien Wajsberg [:julienw]]

Interesting bug, good finding ! thanks :)

Comment 3

[William Hsu [:whsu]]

Hi, Alissa,

Can it be reproduced on v2.1?
Thanks.

Comment 4

[Julien Wajsberg [:julienw]]

I don't think so because this comes from the new behavior introduced in bug 918970 that landed in v2.2 only.

Comment 5

[Alissa（leave from Mozilla）]

Hi william & julien,
This issue has been failed verified on Flame 2.1 build:
Device: Flame 2.1
Build ID               20150406001204
Gaia Revision          87e55a7ec688138812181747f690fd188d2a0668
Gaia Date              2015-04-03 21:43:01
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/747b6132c44d
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150406.034925
Firmware Date          Mon Apr  6 03:49:36 EDT 2015
Bootloader             L1TC000118D0

Comment 6

[William Hsu [:whsu]]

This bug doesn't only happen on the latest v2.2 build but also occur on v2.1.
Suggest to enhance it.

Many thanks.

Comment 7

[Oleg Zasypkin [:azasypkin]]

There is one more similar use case here: 

1. Let's assume we have a thread with few messages and already saved draft;
2. We enter thread, select all messages and delete them;
3. Currently draft is silently removed as well (no prompt since we didn't edit it), even that user doesn't see it in selection mode (composer is hidden in selection mode).

Hey Jenny, 

Could you please advise what will be the best way to handle this from UX point of view?

Thanks!

Comment 8

[Jenny Lee]

Hello Oleg,

We definitely want to keep the draft and the recipient, so if user deletes all the messages from a thread with saved/unsaved draft, we will always keep the thread with recipient and draft. Note that when user goes into a thread like this, there will only be one option (add subject or remove subject) in the more menu, if user then delete the draft and go back to inbox level, this thread will be removed. Thanks!

Comment 9

[Julien Wajsberg [:julienw]]

We can't really do that currently, because the threads are managed at gecko level (currently) while the drafts are managed at gaia level.

I'd suggest to postpone this edge case until we have a DB in Gaia.

Comment 10

[Oleg Zasypkin [:azasypkin]]

(In reply to Julien Wajsberg [:julienw] (PTO April 6th) from comment #9)
> We can't really do that currently, because the threads are managed at gecko
> level (currently) while the drafts are managed at gaia level.

Maybe we can just append draft with recipient and save it in such cases, at least we'll have plain draft with one recipient and content.
 
> I'd suggest to postpone this edge case until we have a DB in Gaia.

Agree, looks like an edge case anyway

Comment 11

[Julien Wajsberg [:julienw]]

(In reply to Oleg Zasypkin [:azasypkin] from comment #10)
> (In reply to Julien Wajsberg [:julienw] (PTO April 6th) from comment #9)
> > We can't really do that currently, because the threads are managed at gecko
> > level (currently) while the drafts are managed at gaia level.
> 
> Maybe we can just append draft with recipient and save it in such cases, at
> least we'll have plain draft with one recipient and content.

Yep but it's a quite weird UX :/

Comment 12

[Oleg Zasypkin [:azasypkin]]

Just wanted to note that bug 1176976 is landed, and now when all messages are removed from conversation, we remove conversation, keep draft as the thread-less one including conversation recipient.

Comment 13

[Julien Wajsberg [:julienw]]

So I wonder if the bug is still valid ?

Comment 14

[Oleg Zasypkin [:azasypkin]]

(In reply to Julien Wajsberg [:julienw] (away Oct 1st, 2nd) from comment #13)
> So I wonder if the bug is still valid ?

I left it open mostly because you thought that it was weird UX in comment 11 :) But if you think we don't have to do anything here to improve UX, let's dupe it :)

Comment 15

[Julien Wajsberg [:julienw]]

Let's have Morpheus try latest master and decide :)

hey Morpheus, can you try the STR now that bug 1176976 landed and tell us if this looks good or if UX should be improved ?

Comment 16

[Morpheus Chen [:morpheus] UX]

Had a discussion with Evan and got a conclusion.
Ni UX designer Evan for elaborated details.

Comment 17

[Evan Hsu]

Hi all, after discussing, we tend to keep the recipient and draft when users removed all messages from thread. There are two reasons we take into account:

First, refer to IOS and Android system, the both keeps the draft and recipient despite the messages are all removed from the thread. Second, when users in the page that selecting the message to remove, there are no options for users to delete or keep the draft explicitly in our manner. In this case, if the draft is deleted automatically after removing all messages would be a little confused. 

If there are any concerns, please let me know,thanks.
Evan

Comment 18

[Oleg Zasypkin [:azasypkin]]

(In reply to Evan Hsu from comment #17)
> Hi all, after discussing, we tend to keep the recipient and draft when users
> removed all messages from thread. There are two reasons we take into account:
> 
> First, refer to IOS and Android system, the both keeps the draft and
> recipient despite the messages are all removed from the thread. Second, when
> users in the page that selecting the message to remove, there are no options
> for users to delete or keep the draft explicitly in our manner. In this
> case, if the draft is deleted automatically after removing all messages
> would be a little confused. 
> 
> If there are any concerns, please let me know,thanks.
> Evan

Thanks for your reply, Evan! I think now we all agree that we should keep draft :)

I believe the only confusing thing that Julien was talking about in comment 11 was:

1) User enters conversation with draft (let's say we have conversation with number +123, and draft contains message "Text"), selects all messages and removes them;
2) When deletion is completed, user is forwarded to Inbox;
3) In Inbox user sees newly created draft with "+123" recipient and "Text" content;
4) Once user enters this draft - it looks like an ordinary _conversation-less_ draft - the same if user enters New Message view, types in "+123" as recipient and "Text" to message input.

So this is how it works now, but as far as I understood in comment 8 and comment 9 Jenny and Julien had a bit different suggestion on how such conversation should look like:

Once all messages are removed, user stays in the same conversation (not redirected to Inbox, hence there is no recipients input like in New Message view, just header with contact name/number), draft content is preserved. The only differences here are:

* (Improvising :)) Instead of message list, maybe user could see some placeholder text/image (like "hey, start conversation with xxxx");
* We don't have "Select messages" item in "..." menu.

We can't really do this currently and it will require some work, but the question is: do we need this kind of improvement at all or current state is already good enough?

If yes, we'll mark this as a feature and move to backlog to get back to it once we have dedicated DB in Messages app, if not - let's close this bug :)

Thanks!

Comment 19

[Evan Hsu]

Thank you Oleg. Your reply is really detailed and helpful for us.
After our discussion, we have considered the following points:

(1) In the current state, if the user had typed the Text and selects all messages to remove, system will pop out a dialogue to confirm whether saving the draft or not. And the page will be forward to Inbox list automatically if the user chooses the option "save as draft". We think this is no big problem if the recipient and "Text" message is still be kept and showing on the Inbox list (but now the recipient is missing and it should be solved).

(2) In a feasible way as you mentioned, we had considered on this and gave a new flow:
When users had typed the Text and select all messages to clear, it will not pop out the saving draft dialogue and stays in the same conversation (no recipients input but just header with contact name/number). And until user taps on the back arrow to leave the page, the saving draft dialogue will be shown at the moment. We thought this would be a preferable manner while we are not sure whether it is difficult on the technique or require some work and time.

(3) As second point, placeholder text/image would be nonessential cause there is no placeholder text/image in a new message besides the header will show the contact name/number already. Thus we intend to keep a consistent manner would be better.
 
If the second point is more preferably, maybe we could make it as a feature and move to backlog. Thanks! 

Evan :)

Comment 20

[Oleg Zasypkin [:azasypkin]]

(In reply to Evan Hsu from comment #19)
> Thank you Oleg. Your reply is really detailed and helpful for us.
> After our discussion, we have considered the following points:
> 
> (1) In the current state, if the user had typed the Text and selects all
> messages to remove, system will pop out a dialogue to confirm whether saving
> the draft or not. And the page will be forward to Inbox list automatically
> if the user chooses the option "save as draft". We think this is no big
> problem if the recipient and "Text" message is still be kept and showing on
> the Inbox list (but now the recipient is missing and it should be solved).
> 
> (2) In a feasible way as you mentioned, we had considered on this and gave a
> new flow:
> When users had typed the Text and select all messages to clear, it will not
> pop out the saving draft dialogue and stays in the same conversation (no
> recipients input but just header with contact name/number). And until user
> taps on the back arrow to leave the page, the saving draft dialogue will be
> shown at the moment. We thought this would be a preferable manner while we
> are not sure whether it is difficult on the technique or require some work
> and time.
> 
> (3) As second point, placeholder text/image would be nonessential cause
> there is no placeholder text/image in a new message besides the header will
> show the contact name/number already. Thus we intend to keep a consistent
> manner would be better.
>  
> If the second point is more preferably, maybe we could make it as a feature
> and move to backlog. Thanks! 
> 
> Evan :)

Just few corrections:

(1) - we should already keep recipient on the latest master, the only difference is that we don't have save/discard draft dialog anymore.

(2) - nice, it will be possible once we have DB in gaia, but same thing here - we won't have save/discard dialog in this case as well.

(3) - got it, not a big deal anyway :)

So assuming you don't have any objections to absence of save/discard/replace dialog (see the rationale behind that and spec in bug 1176976, also we're going to have "undo" toasts in the future that will improve UX even more), I'm adjusting bug title and mark it as a feature that we can work on once we have MessagesDB in gaia (I'll put corresponding bug to dependencies once I find one).

Thanks!

Comment 22

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 23

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(