Closed Bug 1215655 Opened 9 years ago Closed 7 years ago

[Messages] When selecting message and having a text inside a text box, mark as unread function does not work.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-master affected)

RESOLVED WONTFIX
Tracking Status
b2g-master --- affected

People

(Reporter: vbelonenko, Unassigned, Mentored)

References

()

Details

(Whiteboard: [2.5-Daily-Testing][Spark])

Attachments

(2 files)

Description:
Write a message to somebody and leave text inside the text box. When selecting a message Mark as Unread later. 

Repro Steps:
1) Update a Aries to 20151016122951
2) Select messages app 
3) type some text inside a text box
4) Go back to select messages and hold while pressing it.
5) Observe that when selecting messages and selecting  Mark as Unread option, the function does not work.

Actual:
Mark as Unread option does not work when user has a text inside the text box.

Expected:
Mark as Unread option inside the messages app should function properly or deleted.

Environmental Variables:
Device: Aries Master 2.5 kk full flash 
Build ID: 20151016122951
Gaia: 8999f0ba6326d815c8366e3c1155b7e4e9763b40
Gecko: ccf288f658211b6cfab33c458aaf033baed2375b
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (Master)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Repro frequency: 3/3
See attached: video clip and logcat
This issue occurs on 2.5 flame
Result: Mark as Unread option does not work when user has a text inside the text box.

Device: Flame Master 2.5 kk full flash
Build ID: 20151015030226
Gaia: 40ae7c292a36156458c66712b4bd61ecbe69272a
Gecko: e193b4da0a8c1025aa76a403c64663ff1cd41709
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (Master)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Flame 2.2 does not support this functionality in the latest build.
QA Whiteboard: [QAnalyst-Triage+]
Component: Gaia::System::Window Mgmt → Gaia::SMS
Flags: needinfo?(ktucker)
In the past it's been specified that when we have both states "has draft" and "has unread messages" for one conversation, the "has draft" state is displayed. It's very difficult to find a reference for this past decision :/
I think the rationale was that it was more useful to know about a draft than about unread messages.

Now we can decide to reverse this. However because we don't have a DB in Gaia, we need a "direct" rule that works for all cases (I mean, from states, have only one output).

I understand that when the user decides to mark a conversation as unread, it's weird it doesn't show up.

I also think it's weird if we receive a message in a conversation, and because this conversation has a draft, we see the "draft" indicator and not the "unread" indicator.

Last but not least it's not possible to create a draft and have unread messages in the same time (because when we create a draft we come from the conversation). So we wouldn't enter the conflict we're trying to resolve now.

So now, the last case is, the user launches the application. A conversation has both "unread" state and "has draft" state. But we don't know why or when it's "unread": because we received a new message ? Because the user has set it as "unread" ? What should we see in that case ?

So.. what do you think Bryant ? :)
Flags: needinfo?(bmao)
Flags: needinfo?(ktucker)
i guess i should grab some context of this function first, so what is the original reason for the "mark as unread" option?
Flags: needinfo?(bmao)
It was a request from a user. I think it's working like a tasklist: we want to come back later at this conversation and not forget about it.
Flags: needinfo?(bmao)
Thank for the explaining ~

So here are actually four states for the conversation (let's not consider the combination yet):
1. Unread: new message coming 
2. Mark as unread: reminder of following action 
3. Draft: still editing the message
4. Read: no more new message

Personally, I do think they are not equally important.
If there is going to have only one state a time, my priority will be 1 > 2 > 3 > 4

The reason i think "unread" is most important is because that is something you can't control and you don't know when it will happen. Therefore, whenever new message coming, user should know that immediately by the  changed state.

Then we look to the 2,3,4 which is fully control by you. when you mark something "unread", i guess it must be something important for you to take action, so it's more important than "draft" since the text won't go anyway but stay in the box. Finally, it comes the "read" state which i guess we all agree it's the most insignificant one.

So here is my suggestion:
1. Remove the "mark as unread" function, or give it a new new state (ex. a red dot)
2. Follow the priority to show conversation state, even if there is multiple states

What do you think Julien?
I think the "red dot" mark is reserved for marking a conversation that has a message in "error state" (which we don't do currently because it's too difficult to do with the current architecture -- but we should do it eventually). As a side, I think this "error state" should work like "unread": disappear when we enter the thread.

Otherwise what you say makes sense -- but we can't do it now (for the same reason we can't do the "error state"). The only states we get are from Gecko, and Gecko only has the "unread" state. Of course we can evolve it but it's some work to do :/
As a reminder, all our message DB is handled in Gecko currently. The only exception is the "drafts" functionality.

Ideally in the future we'd like to have an in-gaia database, that would hold all our data, and that would let us do UI changes that do not come from Gecko. It's a lot of work, we started but it won't be finished soon.

So currently we're stuck with:
* draft information that is stored in gaia -- we can do what we want here, it's already there, even if I would have liked to do it differently.
* unread information, comes from Gecko. We can control it by marking a message as read or unread.
* error information, comes from Gecko. But Gecko does not send it at the Conversation level, and we can't change it -- that's why we can't show it currently in the Inbox.

I hope it's clearer, and sorry for the constraints we have here.


So if I take your comment, I agree wih you on the order, so that would mean the "unread" state (both set by the user or received message) has more importance that the "draft" state, so it should "win". We wouldn't be able to distinguish between "unread" and "set as unread". But remember we also have a notification for a new message; it disappears when we enter the conversation (or if the user dismisses it).


Unrelated, for the 'mark as unread' functionality, do you think we should have it in the top right menu in a Conversation ? I realize I use this functionality a lot in Gmail.



(In reply to Julien Wajsberg [:julienw] from comment #6)
> I think the "red dot" mark is reserved for marking a conversation that has a
> message in "error state" (which we don't do currently because it's too
> difficult to do with the current architecture -- but we should do it
> eventually). As a side, I think this "error state" should work like
> "unread": disappear when we enter the thread.
> 

What do you mean about "error state"? like fail to send message or...?

> Otherwise what you say makes sense -- but we can't do it now (for the same
> reason we can't do the "error state"). The only states we get are from
> Gecko, and Gecko only has the "unread" state. Of course we can evolve it but
> it's some work to do :/
> As a reminder, all our message DB is handled in Gecko currently. The only
> exception is the "drafts" functionality.
> 

May I ask why the "draft" state host differently?

> Ideally in the future we'd like to have an in-gaia database, that would hold
> all our data, and that would let us do UI changes that do not come from
> Gecko. It's a lot of work, we started but it won't be finished soon.
> 
> So currently we're stuck with:
> * draft information that is stored in gaia -- we can do what we want here,
> it's already there, even if I would have liked to do it differently.
> * unread information, comes from Gecko. We can control it by marking a
> message as read or unread.
> * error information, comes from Gecko. But Gecko does not send it at the
> Conversation level, and we can't change it -- that's why we can't show it
> currently in the Inbox.
> 
> I hope it's clearer, and sorry for the constraints we have here.
> 

It's okay, I could understand
So, currently we can only have one state for "unread" and "mark as unread", and I right?

> 
> So if I take your comment, I agree wih you on the order, so that would mean
> the "unread" state (both set by the user or received message) has more
> importance that the "draft" state, so it should "win". We wouldn't be able
> to distinguish between "unread" and "set as unread". But remember we also
> have a notification for a new message; it disappears when we enter the
> conversation (or if the user dismisses it).
> 

Yes, and if we can only have 3 state (unread/draft/read) in this version, then I totally agree with you. 

> 
> Unrelated, for the 'mark as unread' functionality, do you think we should
> have it in the top right menu in a Conversation ? I realize I use this
> functionality a lot in Gmail.

I know it's common in mail, but I am not sure if message is the same. Personally, I might mark a mail as important or unread for easy retrieving and act like a reminder for further action, but I seldom do this in IM since most of the information inside are just chatting. Do you mark the message quite often?
Flags: needinfo?(bmao)
(In reply to Bryant Mao [:bryantmao] from comment #7)
> 
> 
> 
> (In reply to Julien Wajsberg [:julienw] from comment #6)
> > I think the "red dot" mark is reserved for marking a conversation that has a
> > message in "error state" (which we don't do currently because it's too
> > difficult to do with the current architecture -- but we should do it
> > eventually). As a side, I think this "error state" should work like
> > "unread": disappear when we enter the thread.
> > 
> 
> What do you mean about "error state"? like fail to send message or...?

Yes !

> 
> > Otherwise what you say makes sense -- but we can't do it now (for the same
> > reason we can't do the "error state"). The only states we get are from
> > Gecko, and Gecko only has the "unread" state. Of course we can evolve it but
> > it's some work to do :/
> > As a reminder, all our message DB is handled in Gecko currently. The only
> > exception is the "drafts" functionality.
> > 
> 
> May I ask why the "draft" state host differently?

Because we did not want to host the draft information in Gecko, so we created a specific DB in Gaia for this.
However the fact that we did this has a lot of issues that you can see when you start the app: the drafts are showing up after some time only.
That's an alternative, having a separate DB holding the information that are not in Gecko. But I'd rather not do it as this will not be efficient, and will be difficult to work with :/ We did it for the Drafts because we didn't have time to do otherwise and it was a needed feature.

> 
> > Ideally in the future we'd like to have an in-gaia database, that would hold
> > all our data, and that would let us do UI changes that do not come from
> > Gecko. It's a lot of work, we started but it won't be finished soon.
> > 
> > So currently we're stuck with:
> > * draft information that is stored in gaia -- we can do what we want here,
> > it's already there, even if I would have liked to do it differently.
> > * unread information, comes from Gecko. We can control it by marking a
> > message as read or unread.
> > * error information, comes from Gecko. But Gecko does not send it at the
> > Conversation level, and we can't change it -- that's why we can't show it
> > currently in the Inbox.
> > 
> > I hope it's clearer, and sorry for the constraints we have here.
> > 
> 
> It's okay, I could understand
> So, currently we can only have one state for "unread" and "mark as unread",
> and I right?

Yes I think so...

> 
> > 
> > So if I take your comment, I agree wih you on the order, so that would mean
> > the "unread" state (both set by the user or received message) has more
> > importance that the "draft" state, so it should "win". We wouldn't be able
> > to distinguish between "unread" and "set as unread". But remember we also
> > have a notification for a new message; it disappears when we enter the
> > conversation (or if the user dismisses it).
> > 
> 
> Yes, and if we can only have 3 state (unread/draft/read) in this version,
> then I totally agree with you. 
> 
> > 
> > Unrelated, for the 'mark as unread' functionality, do you think we should
> > have it in the top right menu in a Conversation ? I realize I use this
> > functionality a lot in Gmail.
> 
> I know it's common in mail, but I am not sure if message is the same.
> Personally, I might mark a mail as important or unread for easy retrieving
> and act like a reminder for further action, but I seldom do this in IM since
> most of the information inside are just chatting. Do you mark the message
> quite often?

No I don't do it myself in the SMS app.

Let's ask Kumar who wanted this functionality at first and implemented it.
Flags: needinfo?(rishav006)
Okay, After reading all the comments, Here it is, my views on it and suggestion.
1. According to description to bug (comment 0), yes that's weird and a bug too. That time we gave preference to latest one. so in that case, draft was latest. so, it shouldn't show 'mark as unread'.

2. I would like to suggest something else.
We should not prioritize between unread and draft. Both are equally important depend on scenario.
That's why i filed this bug long back https://bugzilla.mozilla.org/show_bug.cgi?id=1112028#c3
But according to Jenny, keeping both icon (unread and draft) are not pleasing.

So, i would like suggest,to find visual design solution for keeping both. As both information is important (unread and draft).
Either
-> Different solution to show read and unread msg/thread. (not icon based) 
[see thread 2 in given image link]

OR
-> Different solution to show draft. (not icon based, as we can have only icon at a time).
[see thread 1 in given image link]

I am in favor of keeping both (unread and draft) information, instead of prioritizing it.


Please see this image to suggested solution. http://i.imgur.com/brjR5tN.png

Thanks
Flags: needinfo?(rishav006)
Flags: needinfo?(felash)
Flags: needinfo?(bmao)
Why not, I'll follow the solution from our UX designer here :)
Flags: needinfo?(felash)
Rishav, you didn't answer the question though: why would you use the "mark as untead" functionality ?
Flags: needinfo?(rishav006)
Oh, Sorry..
I saw, you already gave the reply. :) 

Anyway here, is the exact answer:  (instead of pasting same thing, i am giving the link)

https://bugzilla.mozilla.org/show_bug.cgi?id=829820#c23

Thanks
Flags: needinfo?(rishav006) → needinfo?(felash)
Hey julienw, 
you can reopen this bug instead of filing new , and can follow up with designer here.
https://bugzilla.mozilla.org/show_bug.cgi?id=1112028

Thanks
Hi Kumar, Julien

Thanks for the links for me to garb some history of the bug :)

I agree with Jenny that showing the latest state is quite sufficient, and having both state icon on the tiny thread is not visually appealing. More information always means more distraction, we want to save the user's attention only for the necessary one. 

So is draft a necessary information in the message? That's a open question but I don't see this state quite often in other message apps. I think email and message are serving for two different social purposes, one is more official which take time to reply and revisit, the other is more casual, one-time use, and always in a instant fashion. I am not saying we should remove the draft state, or the "email-like" proposal is not fit. But does this draft state happen often and more importantly do users really care about it in the massaging context?

As for the "mark as unread" function, if someone have done the survey and the result is positive. I think we should keep this function for sure, then next question will be: where should we put it? We need to know when and how frequent user want to access the function to decide to place it in the chat room, on the thread or hiding in the long press like now. 

Both question require a survey to know, I'll try to do it and give you guys feedback soon!
Flags: needinfo?(bmao)
(In reply to Bryant Mao [:bryantmao] from comment #14)
> Hi Kumar, Julien
> 
> Thanks for the links for me to garb some history of the bug :)
> 
> I agree with Jenny that showing the latest state is quite sufficient, and
> having both state icon on the tiny thread is not visually appealing. More
> information always means more distraction, we want to save the user's
> attention only for the necessary one. 
> 
I agree with that showing both state icon on tiny thread is not visually appealing.
But 'more information always means more distraction' --> not always. It depends how we we visually representing it. That's why i proposed to have a new visual appearance of unread/read and draft (see http://i.imgur.com/brjR5tN.png)

Again, draft is important or not, depend on scenario. Sometimes i use draft to note down something for later use.
And all unread message need not to be read (like message from mobile company or ad message)

But anyway, it's good to have a survey to know more, what other user think.
It's really nice to have a new pair of eyes on old problems :) It's interesting to think whether the "draft" indicator is important at all. Maybe it is important to distinguish "real" "new message" draft, but not for the draft in a conversation.

Kumar, thanks for the link, I forgot the initial suggestion came from Omega :)
Flags: needinfo?(felash)
Assignee: nobody → rishav006
Summary: When selecting message and having a text inside a text box, mark as unread function does not work. → [Messages] When selecting message and having a text inside a text box, mark as unread function does not work.
Hey Julienw,
So, As per description of the bug, this bug currently exist and need to fix. 
It's better if we moved the discussion(comment 14, 15, 16) related to importance of draft icon to this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1112028. 

Thanks
Flags: needinfo?(felash)
Discussion related to importance of draft icon has moved to the https://bugzilla.mozilla.org/show_bug.cgi?id=1112028.
Comment on attachment 8681600 [details] [review]
[gaia] kumarrishav:Bug-1215655 > mozilla-b2g:master

Hey Julienw,
Here is minor patch. Do you expect unit test for each possible case?

P.S:- Bug 1207081 is getting fixed in this bug.

Thanks
Attachment #8681600 - Flags: feedback?(felash)
Hi Julien, Kumar,

Sorry for the late reply. Here is the summary of the quick survey from our 6 participants for your reference. 

For "mark as unread", 5 out of 6 people think it's a nice to have function. One participant consider it's not important at all. Many people point out that they use this function frequently in the email, but don't see strong need in the messaging context. 

As for the "Draft", half people think it's a nice to have state, another half of people consider not important at all. They all think message, unlike email, is working in a instant fashion which type and send is usually a continuous task. 2 people think they don't care about knowing if they've finish or send the message as long as the texts they've input keep staying in the box.

One participant give a interesting feedback that the two functions might depends on how we define our message app, is it a tool for more official or casual purpose? Official means people will use the message with caution, so email like features make sense to me. Otherwise we could just make it act like normal message app with out "mark as unread" and "draft" functions.

At the end, if we want to keep the minimum effort, I'll say we could show "draft" like email (kumar's proposal) to separate it from read/unread state, and keep "mark as unread" in the long press menu just like what we're doing now since it's a function people might seldom access to. 

Thank you!
Thanks a lot Bryant for this survey and great Feedback.

So, here is my final proposal/conclusion. See if this sound good to you.

1. As mark as unread is good feature but people seldom access it and doing it in bulk is very rare.
So, it's will better to keep 'mark as unread' only on long press (i.e thread specific).
'delete' - 'mark as read' on the bottom tab (during thread edit mode).

2. Regarding Draft, my proposal was to show both. i.e unread as well as draft. But showing both icon won't be a good as far as VD is concern.

So, i would like to have a different VD for Draft instead of icon (or a different place to show icon).
Even android message app show both info i.e unread as well as draft.

We can show draft something like Something like this http://i.imgur.com/brjR5tN.png

So, how this sounds to you julienw, Bryant ?
Flags: needinfo?(bmao)
Also, it will be nice if we can show no. of message in a thread. Currently to know this , we have to enter the thread and select all message, then on header you can see total number of message.
(currently we have to follow 3-4 steps to know this)

It will be nice if we can do something like this image.

See 6th thread in this image. http://i.imgur.com/brjR5tN.png

It will be great if i can get UI/UX - VD specs for same.

Thanks
(In reply to kumar rishav (:rishav_) from comment #22)
> Thanks a lot Bryant for this survey and great Feedback.
> 
> So, here is my final proposal/conclusion. See if this sound good to you.
> 
> 1. As mark as unread is good feature but people seldom access it and doing
> it in bulk is very rare.
> So, it's will better to keep 'mark as unread' only on long press (i.e thread
> specific).
> 'delete' - 'mark as read' on the bottom tab (during thread edit mode).
> 
> 2. Regarding Draft, my proposal was to show both. i.e unread as well as
> draft. But showing both icon won't be a good as far as VD is concern.
> 
> So, i would like to have a different VD for Draft instead of icon (or a
> different place to show icon).
> Even android message app show both info i.e unread as well as draft.
> 
> We can show draft something like Something like this
> http://i.imgur.com/brjR5tN.png
> 
> So, how this sounds to you julienw, Bryant ?

Sounds great to me, but just wanna to know what is the reason to see total number of message?
Flags: needinfo?(bmao)
umm, not any strong reason. Just to show more info about thread. 
But this is not necessary. we can have it via add-on (currently working on it).

So, For Draft icon (or new solution) should i ask Fang (VD) or you will provide the same? 

Thanks
Flags: needinfo?(bmao)
Hi Fang,
Can we have your input on this? New design to show draft info.
I proposed something like this -> http://i.imgur.com/brjR5tN.png
(we can have icon instead too)

Thanks
Flags: needinfo?(fshih)
(In reply to kumar rishav (:rishav_) from comment #25)
> umm, not any strong reason. Just to show more info about thread. 
> But this is not necessary. we can have it via add-on (currently working on
> it).
> 
> So, For Draft icon (or new solution) should i ask Fang (VD) or you will
> provide the same? 
> 
> Thanks

Hi Kumar,

I've told Fang about this, but now our VD is quite busying with Mozlando presentation. She might need couple days to provide the icon or you.
Flags: needinfo?(bmao)
(In reply to kumar rishav (:rishav_) from comment #23)
> Also, it will be nice if we can show no. of message in a thread. Currently
> to know this , we have to enter the thread and select all message, then on
> header you can see total number of message.
> (currently we have to follow 3-4 steps to know this)
> 
> It will be nice if we can do something like this image.
> 
> See 6th thread in this image. http://i.imgur.com/brjR5tN.png

It's difficult currently, because we only show the information we have on the "thread" object from gecko; without this there is nothing we can do quickly for now.


It could be possible to do it from the Conversation view, or from a "thread details" view, where performance is less important.


(In reply to Bryant Mao [:bryantmao] from comment #21)
> Hi Julien, Kumar,
> 
> Sorry for the late reply. Here is the summary of the quick survey from our 6
> participants for your reference. 
> 
> For "mark as unread", 5 out of 6 people think it's a nice to have function.
> One participant consider it's not important at all. Many people point out
> that they use this function frequently in the email, but don't see strong
> need in the messaging context. 
> 
> As for the "Draft", half people think it's a nice to have state, another
> half of people consider not important at all. They all think message, unlike
> email, is working in a instant fashion which type and send is usually a
> continuous task. 2 people think they don't care about knowing if they've
> finish or send the message as long as the texts they've input keep staying
> in the box.

I think it's interesting. Latest changes to the behavior make the draft functionality less visible and less intrusive but just as efficient.

Maybe we should just remove the "draft" icon for conversations, and keep it only for "new message"-style drafts (the ones that are saved from the "new message" panel, as opposed to the drafts saved from a conversation) ?

What do you think Bryant ?

> 
> One participant give a interesting feedback that the two functions might
> depends on how we define our message app, is it a tool for more official or
> casual purpose? Official means people will use the message with caution, so
> email like features make sense to me. Otherwise we could just make it act
> like normal message app with out "mark as unread" and "draft" functions.

I feel strongly we need to keep the "draft" functionality. No special advice for the "mark as unread" functionality.

> 
> At the end, if we want to keep the minimum effort, I'll say we could show
> "draft" like email (kumar's proposal) to separate it from read/unread state,
> and keep "mark as unread" in the long press menu just like what we're doing
> now since it's a function people might seldom access to. 

why not, but also see my previous proposal.
Flags: needinfo?(felash) → needinfo?(bmao)
Sorry, But i am not in favor of hiding any info of thread from user. IMO we should show the info as much as possible (keeping the ui/design in mind). 
Personally, i have used message draft as a note to save something, as it's faster than the note app (and everyone need not to have note app, even it is there, it's complex, i.e take 4-5 action to save note)
(In reply to kumar rishav (:rishav_) from comment #29)
> Sorry, But i am not in favor of hiding any info of thread from user. IMO we
> should show the info as much as possible (keeping the ui/design in mind).

All I'm proposing is removing the "draft" icon for the drafts that are for Conversations (not for "new message"-type drafts). Otherwise keep everthing as is.

The rationale is that the user doesn't really care that there is a draft or not. This is a useless information.

> Personally, i have used message draft as a note to save something, as it's
> faster than the note app (and everyone need not to have note app, even it is
> there, it's complex, i.e take 4-5 action to save note)

Do you use a "new message" note, or a conversation for this ?
umm, okay if you are saying it's a useless information. Then fine :) we won't show draft icon for conversation.

Most of time, i use a 'conversation' for this, because it's easy in conversation case. In new message case, you have add recipient also.

I will summarize the final conclusion after bryant reply :)
Hey guys,

Sorry for the late reply.

We all agree that we should keep the draft function, so let's just separate it from the read/unread state like our final proposal, and show the state in both new message and conversation since this will make the indication more consistent.
Flags: needinfo?(bmao)
Hi Bryant,
Thanks for the reply.
So, I assume, we need a new VD spec for read/unread - Draft icon.
Will wait for fang's reply.

Thanks
Hi Kumar,

I've just found that the indication of draft state is quite different in our email app, in order to keep overall UI consistency, I would like to sync with Juwei (who is response for the app) first, and make the decision later. After that, Fang will deliver the spec for you if needed. Is that okay for you?
Yeah, sure :) no hurry at all.
Thanks
After offline discussed with Bryan. I'll deliver the visual spec after Bryan sync with Juwei. Thanks!
Flags: needinfo?(fshih)
Status: NEW → ASSIGNED
Comment on attachment 8681600 [details] [review]
[gaia] kumarrishav:Bug-1215655 > mozilla-b2g:master

Let's wait for a visual update before moving forward here.
Attachment #8681600 - Flags: feedback?(felash)
Mentor: felash
Hey Bryant, could you sync with Juwei ?
Flags: needinfo?(bmao)
Hi all,

After sync this bug with Juwei, we found that currently there are different strategies for dealing with "Draft" in email and message app. For email, they had a local folder to contain all the drafts and it does not mark anything if you create a draft (Correct me if i am wrong). Meanwhile, in the message app, we don't have a folder to collect all the drafts (it's not necessary as well), but we do consider to put a draft icon in the inbox thread instead.

So, I propose two solutions here. Solution 1, if there are texts inside the box, we also mark it as "unread" (green dot). At this point, the meaning of the indication change from "unread message" to "something new in the inbox" which indicate user to take action. Solution 2, if there are texts inside the box, shaw draft icon beside the contact name just as what kumar mentioned above. 

Probably solution 1 cost little efforts to do, what do you guys think?
Flags: needinfo?(bmao)
Sorry, I didn't get solution 1 completely.
You meant, show draft using same green dot (unread icon).
Correct me if I am wrong.
Flags: needinfo?(bmao)
Exactly(In reply to kumar rishav (:rishav_) from comment #40)
> Sorry, I didn't get solution 1 completely.
> You meant, show draft using same green dot (unread icon).
> Correct me if I am wrong.

Exactly!
Flags: needinfo?(bmao)
Bryant, I don't really like these solutions.

About solution 1: as a (specific) user, I actually don't really care about the "draft" indicator (speaking about conversation draft here, "new message" drafts are another subject). But the "unread" indicator is really useful. So mixing them in "one indicator to rule them all" would be confusing for me-as-a-user.

About solution 2: as you said this is likely a bigger work.


Here are other solutions, tell me what you think:

3 - Never show the draft icon for conversations. This is a useless information.

4 - Show the draft icon only if all messages are read. If 1 message is unread, show the "unread" indicator instead of the "draft" indicator.


These 2 solutions comes from my feeling that the "draft" indication is not useful for conversations. (it _is_ useful for "new message" drafts).

Rishav, I know you were insisting on keeping the "draft" indicator. Could you explain why ?
Bryant, what do you think ?
Flags: needinfo?(rishav006)
Flags: needinfo?(bmao)
Neither i liked solution 1.

Julienw, i am not insisting on it :) I just felt this is very common to a user (almost all device consider draft, a useful info), nothing more. I am fine with considering draft as useless info for conversations.

Thanks
Flags: needinfo?(rishav006)
Hi Julien, Rishav,

Alright, let try to nail down the discussion.

Solution 1 is trying to keep the consistency with email app(That's how it behave now, but not necessarily good). On a system level, we hope user to interact with the same function (ex. draft) with similar style, if not equal. 

Under this principle, even solution 2 is inconsistent with the email app, since currently there is no such "draft" icon on the email thread. So as our survey revealed that draft are less important information and a nice to have option. I'll say let's support for the solution 3: Never show the draft icon for conversations, except for "new message draft".

What do you guys say?
Flags: needinfo?(bmao)
Solution 3: Never show the draft icon for conversations, except for "new message draft"
I am okay with it.

ni? julien for reminder as he is busy in other project.
Flags: needinfo?(felash)
Assignee: rishav006 → nobody
Status: ASSIGNED → NEW
Mass closing of Gaia::SMS bugs. End of an era :(
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Mass closing of Gaia::SMS bugs. End of an era :(
Flags: needinfo?(felash)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: