Last Comment Bug 829820 - [Messages] Ability to mark selected SMS threads as read/unread
: [Messages] Ability to mark selected SMS threads as read/unread
Status: RESOLVED FIXED
[needs UX][needs VD], ux-most-wanted-...
: feature
Product: Firefox OS
Classification: Client Software
Component: Gaia::SMS (show other bugs)
: unspecified
: All Gonk (Firefox OS)
-- enhancement (vote)
: ---
Assigned To: kumar rishav (:rishav_)
: mbarone
:
Mentors: Gabriele Svelto [:gsvelto]
Steve Chung [:steveck]
: 961341 (view as bug list)
Depends on: 1020306 1040875 1124696 1128337
Blocks: 1067275 1096862
  Show dependency treegraph
 
Reported: 2013-01-11 15:43 PST by Matthew N. [:MattN] (PM if requests are blocking you)
Modified: 2015-10-26 13:29 PDT (History)
23 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
backlog
2.2


Attachments
UX flow proposal (343.32 KB, application/force-download)
2014-04-26 00:04 PDT, kumar rishav (:rishav_)
no flags Details
[1.5 Messages] Select Items v1.0.pdf (558.59 KB, application/pdf)
2014-05-06 02:52 PDT, Omega Feng [:Omega] [:馮於懋]
no flags Details
Refactor the existing edit mode to use Omega's proposal but w/o additional features (i.e. delete only). (83 bytes, patch)
2014-05-28 06:38 PDT, kumar rishav (:rishav_)
jelee: feedback+
jelee: feedback+
Details | Diff | Splinter Review
Collections of screen shots of new functionality in action (145.81 KB, application/pdf)
2014-05-28 06:52 PDT, kumar rishav (:rishav_)
no flags Details
Screen shots for changes in Thread list (177.54 KB, application/pdf)
2014-06-02 15:03 PDT, kumar rishav (:rishav_)
jelee: feedback-
felash: feedback+
vicky.bugzilla: feedback-
Details
Screen shots for changes in messages list of each thread (122.04 KB, application/pdf)
2014-06-02 15:07 PDT, kumar rishav (:rishav_)
jelee: review+
vicky.bugzilla: review-
felash: feedback+
Details
Screen shots for changes in messages list (Sent and Received)of each thread (79.86 KB, application/pdf)
2014-06-03 07:54 PDT, kumar rishav (:rishav_)
jelee: review+
Details
[1.5 Messages] Select Items v1.1.pdf (722.80 KB, application/pdf)
2014-06-17 23:02 PDT, Jenny Lee
no flags Details
[1.5 Messages] Select Items v1.2.pdf (610.92 KB, application/pdf)
2014-06-19 18:31 PDT, Omega Feng [:Omega] [:馮於懋]
no flags Details
WIP (Work in progress) (46 bytes, text/x-github-pull-request)
2014-07-23 03:46 PDT, kumar rishav (:rishav_)
no flags Details | Review | Splinter Review
Bug 829820 - Ability to mark selected SMS thread as Read/Unread (46 bytes, text/x-github-pull-request)
2014-08-17 06:41 PDT, kumar rishav (:rishav_)
schung: review+
Details | Review | Splinter Review
2015-01-21-00-38-54.png (120.69 KB, image/png)
2015-01-20 09:03 PST, Steve Chung [:steveck]
no flags Details

Description User image Matthew N. [:MattN] (PM if requests are blocking you) 2013-01-11 15:43:49 PST
Since I use Google Voice, I also receive my SMS through their web interface and via email.  If I already read the SMS on another device, I don't want to have to click on each thread, go back to the thread list and repeat for each SMS marked as unread.

It would be nice to be able to mark multiple threads as read like I can do for deletion.  That way I can go into checkbox mode and choose "Select all" or check the unread threads and then tap a button to "mark as read".
Comment 1 User image Corey Frang [:gnarf] 2013-09-30 09:45:30 PDT
Need to figure out how to get this into the interaction specs.

Should we somehow add a "Mark Read" to the select interface from the Thread List UI?
Comment 2 User image ayman maat :maat 2013-10-02 03:55:18 PDT
(In reply to Corey Frang [:gnarf] [:gnarf37] from comment #1)
> Need to figure out how to get this into the interaction specs.
> 
> Should we somehow add a "Mark Read" to the select interface from the Thread
> List UI?

I think that this is a great functional addition to the UX of the messaging app and bang in line with where i want to evolve the multiple selection feature. At the moment the multiple selection feature is just for delete, it should offer other pragmatic bulk functions like forward (when actions from within message thread), mark as read/unread (when actions from within inbox)

I am not in a position to dictate in which version we incorporate such bulk functionality.. but i am going to raise it to product to put it on their radar so they can add it to the road map. so...

ni? to wilfred and noemi with David and Joe on CC

ni? me if you require further input
Comment 3 User image Julien Wajsberg [:julienw] 2013-10-03 08:15:50 PDT
I don't know if this is the right place, but I think we sohuld have another way to select messages/threads than "tap them one by one", "select all", "deselect all", and eg be able to select all messages more than 7 days old (which would be a must for me).
Comment 4 User image Wilfred Mathanaraj [:WDM] 2013-10-08 04:15:50 PDT
i will add to backlog doc and we need to scope after we finish any committed items for v1.3.
Comment 5 User image David Scravaglieri [:scravag] 2014-01-30 00:12:21 PST
New feature, if someone has bandwidth to implement it please land it. Not a blocker.
Comment 6 User image Julien Wajsberg [:julienw] 2014-01-30 08:53:11 PST
Hey David, before "having bandwidth to implement it", we need UX and visual work.

David, Wilfred, how should we handle such cases? UX and Visual work for non-blocking features?
Comment 7 User image Wilfred Mathanaraj [:WDM] 2014-02-19 04:01:22 PST
backlog for future work - perhaps we can work on this as time permits and implement
Comment 8 User image David Scravaglieri [:scravag] 2014-02-19 06:24:08 PST
clear ni?
Comment 9 User image Julien Wajsberg [:julienw] 2014-02-19 10:44:40 PST
Still my question holds: if we can't do this work, maybe a contributor could. But then we need some UX before. How can we handle this?
Comment 10 User image Gabriele Svelto [:gsvelto] 2014-02-20 00:12:58 PST
I'm actually mentoring a contributor who wanted to pick this bug for his GSoC among other SMS improvements; so if we could have the necessary UX here in a reasonable time it would be nice.
Comment 11 User image Wilfred Mathanaraj [:WDM] 2014-03-03 05:20:38 PST
 we are happy to take any items from the backlog and a contributor can contribute to it. once the work is reviewed we can plus it based on the testing performed on the feature.

this should not change whether its a blocking item or target or backlog item for a release. 

we need to NI the right UX person for this component.
Comment 12 User image Joe Cheng [:jcheng] (please needinfo) 2014-03-03 20:35:24 PST
ni? UX team, any idea on how we enable UX contribution as well? Thanks
Comment 13 User image Gabriele Svelto [:gsvelto] 2014-04-25 11:26:30 PDT
I'm assigning the bug to Kumar Rishav, one of our contributors who will be working on this bug as part of his recently approved GSoC project to improve the user interaction with the SMS app.

We're trying to solve the UX issue in a novel way: Kumar will post a proposal for this bug's UX flow modeled on the existing flows and we'll ask feedback on that. Hopefully this should speed up the process of getting the UX flow done and might pave the way to similar contributions in the future.
Comment 14 User image Stephany Wilkes 2014-04-25 13:06:36 PDT
This should be re-evaluted internally as to whether or not this is a feature that UX and Product believe is good for Firefox OS. The user story that prompted this (in regard to Google Voice) does not necessarily appear to be one that face on Firefox OS today, and seems to be more about bulk-select-and-do-something generally.

Please be aware, too, that Ayman is no longer working on Firefox OS. The Comms UX is now being led by Carrie Wang in our Taipei office, added here.

If there are issues with the creation of Comms UX flows being delayed, as mentioned in comment #13, that's a distinct issue that I expect UX would have heard from Wilfred about.

Wilfred, hopefully UX and Product can have a conversation about whether this is a feature we want to add to the backlog for 2.1 (since 2.0 is already underway), possibly during our May work week?
Comment 15 User image kumar rishav (:rishav_) 2014-04-26 00:04:29 PDT
Created attachment 8413152 [details]
UX flow proposal

Hi all
Here is the proposal for UX flow that i proposed.
Thanks
Comment 16 User image Gabriele Svelto [:gsvelto] 2014-04-26 03:18:26 PDT
(In reply to Stephany Wilkes from comment #14)
> This should be re-evaluted internally as to whether or not this is a feature
> that UX and Product believe is good for Firefox OS. The user story that
> prompted this (in regard to Google Voice) does not necessarily appear to be
> one that face on Firefox OS today, and seems to be more about
> bulk-select-and-do-something generally.
> [...]
> Wilfred, hopefully UX and Product can have a conversation about whether this
> is a feature we want to add to the backlog for 2.1 (since 2.0 is already
> underway), possibly during our May work week?

Thanks for the clarification Stephany. To tackle the issue of when or if this feature should land I had considered the following possibility: the feature could be added behind a pref and land pref'd off by default. This is a common practice in Gecko and I thought it would a good idea in this case as it would allow Kumar to go ahead with his GSoC while leaving us the time to decide when we'd like to enable this.
Comment 17 User image Omega Feng [:Omega] [:馮於懋] 2014-04-27 20:21:30 PDT
(In reply to kumar rishav from comment #15)
> Created attachment 8413152 [details]
> UX flow proposal
> 
> Hi all
> Here is the proposal for UX flow that i proposed.
> Thanks

Hi Kumar, IMHO, we will have 2 or mabye more bulk actions (Delete messages & Mark as read), so we should use select-items-and-then-decide-what-to-do pattern.
So, the menu would look like:

Select Items
Settings
------------
Cancel

After tapping "Select Items", it enters select mode.
Select mode might need some modification, like:

X Edit
---------------------------
[ ] MSG1
[ ] MSG2
[ ] MSG3
---------------------------
[Mark Read/Unread] [Delete]  <--icons

After selecting some items, it looks like:

X 2 Selected
---------------------------
[v] MSG1
[ ] MSG2
[v] MSG3
---------------------------
[Mark Read/Unread] [Delete]

Tapping "X", it goes back to message list.
Tapping "Mark Read/Unread", it makes the selected items as read/unread, and stays at select mode.
Tapping "Delete", it deletes the selected items, and goes back to message list.

However, this proposal changes select mode a lot. We need to decide if we should do this way.
Comment 18 User image kumar rishav (:rishav_) 2014-04-28 04:49:06 PDT
Hi Omega,
Yeah, you proposal is good and kind of new.It will be better if we have unread messages on the top of message list.Also,what about "Select all" and "Deselect all" option?
Thanks
Comment 19 User image Gabriele Svelto [:gsvelto] 2014-04-28 06:11:10 PDT
(In reply to Omega Feng [:Omega] from comment #17)
> However, this proposal changes select mode a lot. We need to decide if we
> should do this way.

I see some benefit in this design but as Kumar pointed out it's got the issue of not scaling very well: there's only so much space at the bottom of the page and we currently have the select all / deselect all buttons there. We could put the icons in the top bar instead but there wouldn't be much space either, and using icons instead of text might hurt discoverability.

Do we have other applications facing a similar issue? How is e-mail dealing with this for example?
Comment 20 User image kumar rishav (:rishav_) 2014-04-28 06:23:45 PDT
Hi ofeng
Will it not be annoying for user, that we will have so many pages/options for selections for different things at one place? like : Select Between select items and setting option,then select the messages,select what to do i.e delete or mark read,then,also where will be select all and deselect all option.

For user, ui-flow should be simple and easy to understand, otherwise user will get so many option at one place.So i think adding one option to Present design/ux-flow is better instead of changing whole.
Currently only two option is there i.e delete and setting .adding one more option should be a problem.If in future we are getting 5-6 option then we should find another way for this.

Thanks
Comment 21 User image Omega Feng [:Omega] [:馮於懋] 2014-04-28 20:34:14 PDT
(In reply to kumar rishav from comment #18)
> Hi Omega,
> Yeah, you proposal is good and kind of new.It will be better if we have
> unread messages on the top of message list.Also,what about "Select all" and
> "Deselect all" option?
> Thanks

Thanks for pointing out, I just missed it.
It should look like:

X Edit    [Select/Deselect All]
-------------------------------
[ ] MSG1
[ ] MSG2
[ ] MSG3
-------------------------------
[Mark Read/Unread]     [Delete]


(In reply to Gabriele Svelto [:gsvelto] from comment #19)
> Do we have other applications facing a similar issue? How is e-mail dealing
> with this for example?

Email do the same as my proposal, but without "Select/Deselect All".


(In reply to kumar rishav from comment #20)
> Hi ofeng
> Will it not be annoying for user, that we will have so many pages/options
> for selections for different things at one place? like : Select Between
> select items and setting option,then select the messages,select what to do
> i.e delete or mark read,then,also where will be select all and deselect all
> option.

We can add one more way to trigger select mode: long-press on list item, and then go to select mode. That will decrease the steps.

> For user, ui-flow should be simple and easy to understand, otherwise user
> will get so many option at one place.So i think adding one option to Present
> design/ux-flow is better instead of changing whole.

I think your design works, but, since we have "Mark messages as read", it makes sense to add another one: "Mark messages as unread". However, that means there are 3 bulk actions in the menu. That will make your design complicated.


In current FxOS, we have 2 design patterns for select mode:
1) Email/Gallery/Video
  X Title
  ---------------------------
  [ ] Item1
  [ ] Item2
  [ ] Item3
  ---------------------------
  [Action1][Action2][Action3]

2) Messages/Contacts
  X Title            [Action]
  ---------------------------
  [ ] Item1
  [ ] Item2
  [ ] Item3
  ---------------------------
  [Deselect All] [Select All]

We definitely should have consistent pattern in our OS. I prefer 1) because the visual flow is smooth ↓↓→, not ↓→↑ like 2). And, actions are more important than select/deselect all, so they should locate at bottom. That's easier to reach for fingers.
Comment 22 User image kumar rishav (:rishav_) 2014-04-28 21:08:21 PDT
Hi Ofeng
Is it necessary to have "Mark as unread"?Why any user will mark any message as unread after reading (generally).If user control all actions like Mark read/mark unread, then Will it good for sms service/sms app.As there should some default things/property of any app(user shouldn't control each and everything of any app).Hope you get, what i want to say :) . We are planning to include "Mark as read " because we saw case in description as Matthew told.
Thanks
Comment 23 User image Omega Feng [:Omega] [:馮於懋] 2014-04-29 03:23:09 PDT
(In reply to kumar rishav from comment #22)
> Hi Ofeng
> Is it necessary to have "Mark as unread"?Why any user will mark any message
> as unread after reading (generally).If user control all actions like Mark
> read/mark unread, then Will it good for sms service/sms app.As there should
> some default things/property of any app(user shouldn't control each and
> everything of any app).Hope you get, what i want to say :) . We are planning
> to include "Mark as read " because we saw case in description as Matthew
> told.
> Thanks

Hi Kumar,
For better UX, when we add an new action, we usually add the reverse one as well. For example, when we have "create folder" action, we should have "delete folder" one; when we have "import multiple contacts", we should have "delete multiple contacts" (otherwise, you can imagine if I accidentally import 100 contacts, and I have to delete them one by one...) That's one reason why I'd like to add "mark as unread" action.
The other important reason is that users really need this feature as my quick survey. Unread messages works as to-do reminders for them, just like what Email behaves.
Actually I just want to change Messages UI, not the messaging service. So the unread status doesn't need to sync to server.
Comment 24 User image Gabriele Svelto [:gsvelto] 2014-04-29 06:57:30 PDT
(In reply to Omega Feng [:Omega] from comment #23)
> The other important reason is that users really need this feature as my
> quick survey. Unread messages works as to-do reminders for them, just like
> what Email behaves.
> Actually I just want to change Messages UI, not the messaging service. So
> the unread status doesn't need to sync to server.

Good point; making this more e-mail like sounds like a good idea to me but would require more work so a couple of questions on this:

- If we follow this direction shall we split this in multiple bugs? I'd imagine at least a refactoring bug to offer the current functionality in the new format and this bug to add the mark as read / mark as unread functionality

- Also before we proceed I think we should involve the SMS owners/peers in the discussion as well as the product managers to decide if this is the direction we want to follow. Could you cook up a prototype of the UX flow to show them what we're trying to achieve?

Personally I like this quite a bit and I'm convinced the changes would be manageable.
Comment 25 User image Omega Feng [:Omega] [:馮於懋] 2014-04-30 02:27:59 PDT
(In reply to Gabriele Svelto [:gsvelto] from comment #24)
> - Also before we proceed I think we should involve the SMS owners/peers in
> the discussion as well as the product managers to decide if this is the
> direction we want to follow. Could you cook up a prototype of the UX flow to
> show them what we're trying to achieve?

Sure I can.
We have holidays this Thursday and Friday this week, so I will do this next week.
Comment 26 User image Omega Feng [:Omega] [:馮於懋] 2014-05-06 02:52:19 PDT
Created attachment 8417921 [details]
[1.5 Messages] Select Items v1.0.pdf

Here is the draft UX spec.

Notice that in p.5 it leaves Select Mode after tapping Mark as Read/Unread. It's consistent with the current implementation of Email. However, as I mentioned in comment 17, I prefer staying at Select Mode after tapping Mark as Read/Unread, but I'm still fighting with Productivity team (Email) and Framework team (Building Blocks) UX owners.
Comment 27 User image Gabriele Svelto [:gsvelto] 2014-05-06 09:13:37 PDT
(In reply to Omega Feng [:Omega] from comment #26)
> Notice that in p.5 it leaves Select Mode after tapping Mark as Read/Unread.
> It's consistent with the current implementation of Email. However, as I
> mentioned in comment 17, I prefer staying at Select Mode after tapping Mark
> as Read/Unread, but I'm still fighting with Productivity team (Email) and
> Framework team (Building Blocks) UX owners.

I find this excellent even though it exceeds the scope of this bug. There's one feature in your draft which I find particularly important and that's the ability to undo an action, something we're currently missing. If we accept this proposal I'd like to open separate bugs for the various bits, we'll probably need a meta-bug too to track the whole change.

The only real issue I see here is that we're going to have two different modes for editing threads and messages; maybe that would also need some harmonization.

Julien, what do you think about this?
Comment 28 User image kumar rishav (:rishav_) 2014-05-06 09:49:10 PDT
Hi omega
What if user Select 3-4 messages, let say to 'delete' ,then if he wants to deselect all (what he selected), then how he will do this as per your proposal.But we can do this with currently existing design.
What are blue and red dots in your proposal.
I think it will be better if after entering select mode, all the unread messages should on the top.
I know it's different from email thing.User usually want the unread messages first.
Thanks
Comment 29 User image Omega Feng [:Omega] [:馮於懋] 2014-05-06 20:46:08 PDT
(In reply to kumar rishav from comment #28)
> What if user Select 3-4 messages, let say to 'delete' ,then if he wants to
> deselect all (what he selected), then how he will do this as per your
> proposal.But we can do this with currently existing design.
He can:
1) tap "Select All" and then tap "Deselect All",
2) or tap "X". (it leaves select mode as well.)

> What are blue and red dots in your proposal.
Blue dot means unread message.
Red dot means sending-failed message.

> I think it will be better if after entering select mode, all the unread
> messages should on the top.
If sorting is a user story, I'd like to do this not only in select mode, but also in normal mode.
ni? Wilfred. How do you think about "sorting" feature?

(In reply to Gabriele Svelto [:gsvelto] from comment #27)
> The only real issue I see here is that we're going to have two different
> modes for editing threads and messages; maybe that would also need some
> harmonization.
We should also change the select mode of thread view just like inbox view. (However, it's not in the UX spec now because of time issue. I can do this later if you're all agree.)
Comment 30 User image Julien Wajsberg [:julienw] 2014-05-07 06:09:10 PDT
There is some things missing in the spec IMO, coming from my dogfooding habits.

I think we need easier ways to select messages older than <n> days:

In the thread list (inbox):
* select all threads (and/or messages) older than <n> days.
  - if we can select "messages older than <n> days", this means we could select only part of 
    a thread. But that would be very useful to clean up old messages from my PoV.

In the thread view:
* select all messages older than <n> days

We could make <n> modifiable by the user, or always use a fixed count, like "7".

I'd agree to move this to another bug, but this is something that I miss a lot. Actually the "select all" case is useful for marking as read, but not so much for deleting. A normal user barely needs to delete all messages.

Here is a proposal:
* the "select all" button would cycle through these behaviors:
  - when "select mode" is displayed, the button would be "select older than 7 days"
  - when clicked once, the button would then be "select all"
  - when everything is selected, the button would be "select none".


Another thing missing is searching threads according to the name/phone number, but this could go in a broader search feature.
Comment 31 User image Gabriele Svelto [:gsvelto] 2014-05-23 09:22:21 PDT
(In reply to Julien Wajsberg [:julienw] from comment #30)
> Here is a proposal:
> * the "select all" button would cycle through these behaviors:
>   - when "select mode" is displayed, the button would be "select older than
> 7 days"
>   - when clicked once, the button would then be "select all"
>   - when everything is selected, the button would be "select none".
> 
> Another thing missing is searching threads according to the name/phone
> number, but this could go in a broader search feature.

These are all interesting ideas and I'm particularly fond of search functionality (when you have years of messages it can be quite useful) but this bug has already outgrown it's original scope quite a bit so I was thinking of splitting it up to make it actionable. The idea would be to split it in the following bugs:

- Refactor the existing edit mode to use Omega's proposal but w/o additional features (i.e. delete only), this would include the thread edit mode too (UI should be rather compatible)

- Add mark-as-read mode to the thread list edit mode

- Add undo for both delete and mark-as-read in both modes. This can be tricky, we'll probably need some help from Gecko or the datastore API available

To this we could add:

- Add range selection (older than 7 days, etc...)

- Add search by name/number

I'm splitting these two last bugs from the others because they don't necessarily depend on them. I think we could implement both with the existing UI.
Comment 32 User image kumar rishav (:rishav_) 2014-05-28 06:38:29 PDT
Created attachment 8430042 [details] [diff] [review]
Refactor the existing edit mode to use Omega's proposal but w/o additional features (i.e. delete only).

Hi all
I have attched the PR and screen shots of new functionality in action.This is  prototype implementation of Omega's proposal with only the delete functionality and no icons.The unit-tests might not work.I am working on that.
Thanks
Comment 33 User image kumar rishav (:rishav_) 2014-05-28 06:52:22 PDT
Created attachment 8430051 [details]
Collections of screen shots of new functionality in action

Hi all
Here is all the screen shots of new functionality in action (in pdf form).
Thanks
Comment 34 User image Francisco Jordano [:arcturus] [:francisco] 2014-05-28 08:34:32 PDT
Comment on attachment 8430042 [details] [diff] [review]
Refactor the existing edit mode to use Omega's proposal but w/o additional features (i.e. delete only).

Julien's feedback here is better than mine.

Thanks.
Comment 35 User image Jenny Lee 2014-05-28 23:23:48 PDT
Comment on attachment 8430042 [details] [diff] [review]
Refactor the existing edit mode to use Omega's proposal but w/o additional features (i.e. delete only).

Hello Kumar, it's looking good! A few comments:
1)On p.1 middle screen, please modify the string "Select Messages" to "Select Thread", as it is actually threads being selected here (in comparison to the "Delete Messages" from the menu of single thread page).
2)On p.1 right screen, please also show the read status for each thread so that user would know which are the read/unread threads.
3)On p.1 right screen, you can only see half of the title, please change the title to "Select". Once 1+ item is selected, show " (#of selected item) Selected", ex, 3 items selected, title would be "3 Selected".  
Thanks!
Comment 36 User image Jenny Lee 2014-05-28 23:46:34 PDT
> I think we need easier ways to select messages older than <n> days
> 
> Another thing missing is searching threads according to the name/phone
> number, but this could go in a broader search feature.

Hello Julien, we agree that there's need to select messages older than <n> days (for delete), but since this action is unlikely to happen frequently, it's better to make this function accessible elsewhere like in settings. There could be a setting that clears old messages automatically under certain conditions say when the storage limit is met, or when the messages are sitting in inbox for over a month, user can set the rules as they like.  
We think search is a nice to have feature, it can be filed as another bug for further discussion.
Comment 37 User image kumar rishav (:rishav_) 2014-05-28 23:54:18 PDT
Hi Jenny
I think your second point is already there.Unread messages (p.1 left screen: a blue dot and p.1 right screen : messages timing in blue) can be seen in blue color.Also Same thing in current functionality (i.e Delete message) too.
Thanks
Comment 38 User image Steve Chung [:steveck] 2014-05-29 00:53:04 PDT
Hi kumar, please note Julien took PTO this week and you can just keep working on the select behavior refactoring. This task should be complicated enough and we can split these items into different bugs. You could follow Omega's spec except for the undo part since we might need more detail discussion about the implementation just like Gabriele said in comment 31. 

About the undo action, maybe we can use can trick in gaia side and no gecko api changes is needed. When user select delete/mark read, message app could:
1) Just update the UI
2) Crate/dislay toaster with undo callback(to resume the UI)
3) While timeout or page leaving, dismiss toaster and call delete/mark api to update the message database.
Comment 39 User image Jenny Lee 2014-05-29 01:18:03 PDT
> I think your second point is already there.Unread messages (p.1 left screen:
> a blue dot and p.1 right screen : messages timing in blue) can be seen in
> blue color.Also Same thing in current functionality (i.e Delete message) too.

Hello Kumar, the screen on the right is missing the blue dot in front of the thread (like the screen on the left). I am aware of this is how it's currently implemented and this is something we should make a change. The blue dot is more noticeable than the the color change of time stamp, naturally, as user scans through the list in select mode, she would gain more visual aid from the dot and complete the action (mark as read) faster. Tks!
Comment 40 User image kumar rishav (:rishav_) 2014-06-02 15:03:01 PDT
Created attachment 8432821 [details]
Screen shots for changes in Thread list

Hi jenny and all
I have implemented all the changes you suggested.I think now it's fine.Please have a look on attached screen shots and PR (though PR is not clean, i will do it later).
Thanks
Comment 41 User image kumar rishav (:rishav_) 2014-06-02 15:07:08 PDT
Created attachment 8432825 [details]
Screen shots for changes in messages list of each thread

Hi 
This is screen shots after implementation on message list for each thread.Previous one was for thread list.Please have a look on attached screen shots and give your suggestions on this.
PR:https://github.com/kumarrishav/gaia/compare/sms-interaction
Thanks
Comment 42 User image Jenny Lee 2014-06-02 23:33:40 PDT
Comment on attachment 8432821 [details]
Screen shots for changes in Thread list

The visual style needs some modification, flagging Vicky for visual input.
Comment 43 User image Jenny Lee 2014-06-02 23:44:19 PDT
Comment on attachment 8432825 [details]
Screen shots for changes in messages list of each thread

Hi Kumar, can you also include the message "sent out" in the screen (right now it's only the ones received)? Tks! 
Flagging Vicky for visual input.
Comment 44 User image Victoria Gerchinhoren [:vicky] 2014-06-03 02:10:57 PDT
(In reply to Jenny Lee from comment #43)
> Comment on attachment 8432825 [details]
> Screen shots for changes in messages list of each thread
> 
> Hi Kumar, can you also include the message "sent out" in the screen (right
> now it's only the ones received)? Tks! 
> Flagging Vicky for visual input.

Hi Jenny, please use "need info" at the bottom of the page and not review, as review is to say ok or not ok, but not to give input.
Thanks! (I know you're new on bugzilla ;) )
Comment 45 User image Victoria Gerchinhoren [:vicky] 2014-06-03 02:12:53 PDT
Comment on attachment 8432825 [details]
Screen shots for changes in messages list of each thread

This doesn't follow the overall multiple delete pattern, please stick to the building blocks.
Comment 46 User image kumar rishav (:rishav_) 2014-06-03 03:56:19 PDT
Hi Vicky
Can you explain more? I didn't get you.what you mean by "overall multiple delete pattern"?
Thanks
Comment 47 User image kumar rishav (:rishav_) 2014-06-03 05:05:43 PDT
(In reply to Jenny Lee from comment #43)
> Comment on attachment 8432825 [details]
> Screen shots for changes in messages list of each thread
> 
> Hi Kumar, can you also include the message "sent out" in the screen (right
> now it's only the ones received)? Tks! 
> Flagging Vicky for visual input.

Hi Jenny
I didn't get you.Can you explain little bit more?
Thanks
Comment 48 User image Julien Wajsberg [:julienw] 2014-06-03 07:16:25 PDT
Vicky, where can we find the current "multiple delete pattern"?
Comment 49 User image Julien Wajsberg [:julienw] 2014-06-03 07:25:04 PDT
(In reply to kumar rishav from comment #47)
> (In reply to Jenny Lee from comment #43)
> > Comment on attachment 8432825 [details]
> > Screen shots for changes in messages list of each thread
> > 
> > Hi Kumar, can you also include the message "sent out" in the screen (right
> > now it's only the ones received)? Tks! 
> > Flagging Vicky for visual input.
> 
> Hi Jenny
> I didn't get you.Can you explain little bit more?
> Thanks

Jenny would like to see the design with a sent message, not only received messages.
Comment 50 User image Julien Wajsberg [:julienw] 2014-06-03 07:25:48 PDT Comment hidden (obsolete)
Comment 51 User image Julien Wajsberg [:julienw] 2014-06-03 07:27:26 PDT Comment hidden (obsolete)
Comment 52 User image Julien Wajsberg [:julienw] 2014-06-03 07:31:35 PDT
Comment on attachment 8430042 [details] [diff] [review]
Refactor the existing edit mode to use Omega's proposal but w/o additional features (i.e. delete only).

seems obsolete now
Comment 53 User image kumar rishav (:rishav_) 2014-06-03 07:54:32 PDT
Created attachment 8433373 [details]
Screen shots for changes in messages list (Sent and Received)of each thread

Hi jenny
It was working good for both (sent and received).Sorry i forgot to include both type of message.Now i attached new one where you can see the design for both received and sent.
Thanks
Thanks juliew for the clarification.
Comment 54 User image Julien Wajsberg [:julienw] 2014-06-03 07:56:55 PDT
Comment on attachment 8432825 [details]
Screen shots for changes in messages list of each thread

can't review a screenshot, but this looks good according to what's been said in this bug.

Now there is an ongoing and offline discussion about this screen. Mike, is there an open bug about how the "select" panel building block is about to change? Because everything that happens here is related to this...
Comment 55 User image GoodMike 2014-06-03 19:38:55 PDT
Hi Julien, the "select" panel building block is the same behavior as current spec done by Omega. So nothing will be changed.
Comment 56 User image Jenny Lee 2014-06-03 19:53:03 PDT
Comment on attachment 8433373 [details]
Screen shots for changes in messages list (Sent and Received)of each thread

The screen is ok, tks! 
Flagging Vicky for visual input.
Comment 57 User image Jenny Lee 2014-06-03 20:21:52 PDT
oops forgot to check the ni box!
(In reply to Jenny Lee from comment #56)
> Comment on attachment 8433373 [details]
> Screen shots for changes in messages list (Sent and Received)of each thread
> 
> The screen is ok, tks! 
> Flagging Vicky for visual input.

oops forgot to check the ni box!
Comment 58 User image Victoria Gerchinhoren [:vicky] 2014-06-03 20:52:06 PDT
(In reply to Jenny Lee from comment #56)
> Comment on attachment 8433373 [details]
> Screen shots for changes in messages list (Sent and Received)of each thread
> 
> The screen is ok, tks! 
> Flagging Vicky for visual input.

Hi.
The failed status of the bubble is not ok but I think this must be solved in the visual refresh. Also the empty bubble should be shorter. This is the visual input I can give but what specifically do you want my input about? Can you specify?
Comment 59 User image Omega Feng [:Omega] [:馮於懋] 2014-06-03 21:02:47 PDT
@Harly,
It's something needing system-wise consistency, so could you have some comments on the multi-selection design?

@Carrie,
If so, Contacts and Call Log also need to change to new behaviors, let's have some discussion and see your feedback.
Comment 60 User image Victoria Gerchinhoren [:vicky] 2014-06-03 23:37:21 PDT
(In reply to Julien Wajsberg [:julienw] from comment #48)
> Vicky, where can we find the current "multiple delete pattern"?

You should ask interaction designers for this. In the wiki page I think and just by using other apps that are not SMS. It's good to play around and see how the rest of apps do the same or similar actions to understand what the user would expect to do in your app.
Comment 61 User image kumar rishav (:rishav_) 2014-06-04 04:45:23 PDT
Hi Omega and Jenny

Can you clarify me the commment#58 ? I am not getting exactly what vicky said? what Vicky said, IS that in scope of your proposal/bug.As everyone flagged Vicky for visual input, Can you please clarify me on this.What's her feedback so that i can proceed accordingly?

Thanks
Comment 62 User image Gabriele Svelto [:gsvelto] 2014-06-04 06:37:10 PDT
(In reply to kumar rishav from comment #61)
> Can you clarify me the commment#58 ? I am not getting exactly what vicky
> said? what Vicky said, IS that in scope of your proposal/bug.As everyone
> flagged Vicky for visual input, Can you please clarify me on this.What's her
> feedback so that i can proceed accordingly?

I think that Vicky meant you should look how other apps handle this case (the deletion of multiple elements, for example multiple e-mails). I assume there is a document describing how this is supposed to work in the building blocks but I don't know where to find it. Comment 55 seems to suggest that what you've currently implemented is OK.

BTW I'm going to rename the bug to reflect the work being done here and I'll split off the other parts that were discussed into other bugs.
Comment 63 User image Gabriele Svelto [:gsvelto] 2014-06-04 06:56:27 PDT
OK, scratch what I said in comment 62. Let's keep mark-as-read as the scope of this bug: I've opened bug 1020306 to track the edit mode changes. Please let's move the patch and discussion there.
Comment 64 User image Harly Hsu[:harly] 2014-06-05 00:49:18 PDT
The multi-select design in Omega's spec is what the Framework team agreed on for the next generation Building Blocks, the only concerns the Framework team have is the localisation for string "Select All" & "Deselect All", and it would be great if we can have an icon instead of using text.
Comment 65 User image kumar rishav (:rishav_) 2014-06-05 06:00:59 PDT
Hi Harly
you mean 'icon'  for everything : Select all,Deselect all,Mark As read/unread,Delete ?
Thanks
Comment 66 User image Hubert Lu[:hlu] <hlu@mozilla.com> 2014-06-05 11:26:47 PDT
*** Bug 1019398 has been marked as a duplicate of this bug. ***
Comment 67 User image Harly Hsu[:harly] 2014-06-05 21:18:02 PDT
Hello Kumar,
I am only suggesting to use icon for select all and deselect all, as the available space on the header seems limited. But now you mentioned, it would be great to have mark as read/unread & delete button on the bottom of the screen all icons, but this will depend on the visual designer. Thanks
Comment 68 User image Jenny Lee 2014-06-17 23:02:44 PDT
Created attachment 8441862 [details]
[1.5 Messages] Select Items v1.1.pdf

Updated wireframe, adding select itmes> delete in message thread view.
Comment 69 User image kumar rishav (:rishav_) 2014-06-18 00:28:30 PDT
Hi jenny
I think you forgot to include this case : long press on message
Thanks
Comment 70 User image Jenny Lee 2014-06-18 04:01:34 PDT
(In reply to kumar rishav from comment #69)
> Hi jenny
> I think you forgot to include this case : long press on message
> Thanks

Long press on message is irrelevant here since it will trigger a context menu from which user can choose to forward, view message report or delete. Tks!
Comment 71 User image kumar rishav (:rishav_) 2014-06-18 04:24:42 PDT
Hi jenny
Then what about current long press functionality. 
Currently we have three option on long option : Forward, View message report ,Delete
Should we remove delete option (on long press) or leave as it is.
Thanks
Comment 72 User image Jenny Lee 2014-06-18 04:40:14 PDT
(In reply to kumar rishav from comment #71)
> Hi jenny
> Then what about current long press functionality. 
> Currently we have three option on long option : Forward, View message report
> ,Delete
> Should we remove delete option (on long press) or leave as it is.
> Thanks

Leave as it is, tks!
Comment 73 User image Omega Feng [:Omega] [:馮於懋] 2014-06-19 18:31:08 PDT
Created attachment 8443189 [details]
[1.5 Messages] Select Items v1.2.pdf

The latest UX spec.
Comment 74 User image kumar rishav (:rishav_) 2014-07-11 14:15:10 PDT
Hi
I have filled new bug for implementing the Undo action and removing the current confirmation box. (as per omega proposal).
As this Undo action is out of scope(also, title of bug) of this bug and We have to implement Undo action for both Delete action as well as Mark Read/Unread action.So it's will be better to track this change in new bug.
Bug 1037650  ( https://bugzilla.mozilla.org/show_bug.cgi?id=1037650 )

Thanks
Comment 75 User image kumar rishav (:rishav_) 2014-07-23 03:46:51 PDT
Created attachment 8460808 [details] [review]
WIP (Work in progress)

Hi
Work is in progress.Read/unread functionality
Thanks
Comment 76 User image kumar rishav (:rishav_) 2014-08-17 06:41:21 PDT
Created attachment 8474223 [details] [review]
Bug 829820 - Ability to mark selected SMS thread as Read/Unread

Hi Gabriele
Here is the patch. Have a look and give your feedback on this :)
Thanks
Comment 77 User image Gabriele Svelto [:gsvelto] 2014-08-18 04:30:41 PDT
Comment on attachment 8474223 [details] [review]
Bug 829820 - Ability to mark selected SMS thread as Read/Unread

I've left my comments in the GitHub PR. For now the patch is quite rough and there's quite a few things that needs changing but it's nice to see it work so that we can have a look at how the new functionality feels.
Comment 78 User image kumar rishav (:rishav_) 2014-08-21 21:51:11 PDT
Comment on attachment 8474223 [details] [review]
Bug 829820 - Ability to mark selected SMS thread as Read/Unread

Hi Gabriele
Patch updated and github commented issue fixed.
Thanks
Comment 79 User image kumar rishav (:rishav_) 2014-09-25 04:02:13 PDT
Hi Jenny
After landing of Gaia Header, there is data-icon attribute , and for "more" button (which is there horizontal dots ---- see top right corner in thread list view) there is data-icon="more".  
As per proposal, there is tick mark with three vertical dots.
So my question is what should be now i.e current one or three vertical dots with tick marks (as per proposal).

Thanks
Comment 80 User image kumar rishav (:rishav_) 2014-09-25 05:52:49 PDT
Hi jenny
What if user selected some threads which has only outgoing messages or thread which has only draft or  error message and user want to "Mark as unread".?
Thanks
Comment 81 User image Jenny Lee 2014-09-29 03:08:59 PDT
(In reply to kumar rishav (:rishav_) from comment #79)
> Hi Jenny
> After landing of Gaia Header, there is data-icon attribute , and for "more"
> button (which is there horizontal dots ---- see top right corner in thread
> list view) there is data-icon="more".  
> As per proposal, there is tick mark with three vertical dots.
> So my question is what should be now i.e current one or three vertical dots
> with tick marks (as per proposal).
> 
> Thanks

Hi Kumar, please use the more icon (3 horizontal dots) on upper right of header (just like what we have now), tapping on the more icon will trigger option menu which should include select items and settings. Thanks!
Comment 82 User image Jenny Lee 2014-09-29 03:39:43 PDT
(In reply to kumar rishav (:rishav_) from comment #80)
> Hi jenny
> What if user selected some threads which has only outgoing messages or
> thread which has only draft or  error message and user want to "Mark as
> unread".?
> Thanks

Hi Kumar, this is unfortunately something we can't quite avoid. Let's do if user selects only the draft or error message, gray out the mark as unread button. If the selected messages contain read messages and draft(or error ones), user can mark as unread, however, the function will have no effect on draft or error messages. Thanks!
Comment 83 User image kumar rishav (:rishav_) 2014-09-29 04:05:35 PDT
Hi Jenny
What if..let's say, User selected 5 threads in which two threads are having only dratfs or error messages and other 3 threads are fine (i mean..it has incoming message)..In this case too, disable(gray out) the mark as unread button.
Thanks
Comment 84 User image Julien Wajsberg [:julienw] 2014-09-29 10:40:25 PDT
Note that it's difficult to know information about the content of threads from this view.

Basically, you can find in [1] what's easy to display or check. Anything else will have performance implication.

This can chance once we'll have an in-gaia database for SMS, as we'll be able to add easily indices, but this is not happening right now. In the mean time, any new information we need needs to change the API, and that's painful to do.

[1] http://mxr.mozilla.org/mozilla-central/source/dom/mobilemessage/interfaces/nsIDOMMozMobileMessageThread.idl
Comment 85 User image Stephany Wilkes 2014-09-29 10:49:51 PDT
Also flagging Harly on patterns given suggested changes to edit mode becoming multiselect (just in case the pattern decisions will have impact here). 2.2 planning is a convenient time for thinking about this not just as patch review, but as design in line with patterns.
Comment 86 User image kumar rishav (:rishav_) 2014-09-29 11:39:19 PDT
Hi 
Shouldn't we have an api that return the Status of a thread/message(having different parameters) from gecko.
As this will be helpfull here, i.e first update the gecko and then get status from here using this api and update it locally (i.e ThreadUI) .
Thanks
Comment 87 User image Julien Wajsberg [:julienw] 2014-09-29 11:41:37 PDT
Of course we can; but as I said, when we need to change the API, it's painful and expensive.
Comment 88 User image Jenny Lee 2014-09-29 19:56:12 PDT
(In reply to kumar rishav (:rishav_) from comment #83)
> Hi Jenny
> What if..let's say, User selected 5 threads in which two threads are having
> only dratfs or error messages and other 3 threads are fine (i mean..it has
> incoming message)..In this case too, disable(gray out) the mark as unread
> button.
> Thanks

If user selects multiple threads that contains both regular message and the ones that can't apply "mark as read/unread", the "mark as read/unread" button will still be actionable, not gray out. Thanks!
Comment 89 User image Harly Hsu[:harly] 2014-10-01 18:12:24 PDT
Hi Stephany,
I was involved with the design of message multiselect mode, and it fits our current pattern design.
Thanks
Comment 90 User image Julien Wajsberg [:julienw] 2014-10-14 07:12:23 PDT
Hey Bevis,

in this bug, we'd need to know what's inside a thread; especially we need to know if it has at least 1 incoming message. Do you think this is something easy to do?

If you'd want to change the API, then knowing the full size of incoming/outgoing messages could be really nice too, unless that's more difficult to do for you.

What's your thought about this?
Comment 91 User image Julien Wajsberg [:julienw] 2014-10-14 07:57:57 PDT
Hey Jenny, 

After discussing with Rishav on IRC, we think that it makes sense to "mark as unread" also threads that have only outgoing messages. This can be an handy reminder for the user.

Moreover, it's a lot easier to do with the current code and API :D

What do you think?

(removing NI for Bevis until we have the answer).
Comment 92 User image Jenny Lee 2014-10-15 03:41:15 PDT
(In reply to Julien Wajsberg [:julienw] from comment #91)
> Hey Jenny, 
> 
> After discussing with Rishav on IRC, we think that it makes sense to "mark
> as unread" also threads that have only outgoing messages. This can be an
> handy reminder for the user.
> 
> Moreover, it's a lot easier to do with the current code and API :D
> 
> What do you think?
> 
> (removing NI for Bevis until we have the answer).

Hi Julien,
I think it's a rare use case, but the rule specifies that when the selected items are all read messages, show “Mark as unread" button. Technically, a thread that contains only outgoing messages (which are read) fits the criteria. So go ahead with it ;)
Comment 93 User image kumar rishav (:rishav_) 2014-10-20 00:30:40 PDT
Hi Gabriele
Finally after long time,hope it's complete and fine now. Added proper unit test and other change.
Couldn't test on device due to some issue while pushing it to device.
Please have a look on PR and give your feedback. May be some :nits will be there.
Thanks
Comment 94 User image kumar rishav (:rishav_) 2014-10-20 00:32:47 PDT
Hi Julien
It will be nice if you too have a look on PR.
Thanks
Comment 95 User image kumar rishav (:rishav_) 2014-11-15 01:50:53 PST
Hi Gabriele
It will be great if you give your feedback on this patch :)
I will be back by 18th nov, so that i can resume the work on this patch.
Thanks
Comment 96 User image kumar rishav (:rishav_) 2014-11-20 02:36:17 PST
Though unit test and linter test failed, i will fix it soon. My intention of asking feedback is mainly on code so that i can modify it as per your suggestion.
Feedback on Github will be nice. :)
Thanks
Comment 97 User image kumar rishav (:rishav_) 2014-11-24 08:40:58 PST
Comment on attachment 8474223 [details] [review]
Bug 829820 - Ability to mark selected SMS thread as Read/Unread

Hi Steve
As per Suggestion of Julienw, Please review the PR. Hope everything in patch is  okay this time.
Thanks
Comment 98 User image Steve Chung [:steveck] 2014-11-27 01:11:38 PST
Comment on attachment 8474223 [details] [review]
Bug 829820 - Ability to mark selected SMS thread as Read/Unread

Hi Kumar, I've replied some suggestion on github. There's one major issue about the selection item control. Since we're trying to get rid of the dependency between DOM element and data in Bug 1074732. Please utilize the Threads which contains all the treads data for selection data. Besides the issue, there is still some small issues that different from the spec. Please request review again once you complete, thanks.
Comment 99 User image Steve Chung [:steveck] 2014-11-27 02:43:15 PST
(In reply to Jenny Lee from comment #82)

> Hi Kumar, this is unfortunately something we can't quite avoid. Let's do if
> user selects only the draft or error message, gray out the mark as unread
> button. If the selected messages contain read messages and draft(or error
> ones), user can mark as unread, however, the function will have no effect on
> draft or error messages. Thanks!

(In reply to Jenny Lee from comment #88)

> If user selects multiple threads that contains both regular message and the 
> ones that can't apply "mark as read/unread", the "mark as read/unread" button
> will still be actionable, not gray out.

Hi Jenny, these comments seems different from what you told to me today, could you please confirm your idea again here and update to the spec? Thanks!
Comment 100 User image kumar rishav (:rishav_) 2014-11-27 22:24:27 PST
Hi Steve
I left some comments on github about How to change the status of thread.
As we are setting data action by unReadCount of message in thread, but we are updating the class of thread only for UI..i.e no change in status of message. How  to change it in UI.
One way is to render all the threads (at least threads on which unread/read action is done) from Gecko, so that status of message get change.
Hope i explained, what i want to ask.
Thanks
Comment 101 User image kumar rishav (:rishav_) 2014-11-27 22:26:22 PST
*How to change the status of thread in UI (not in backend, as it's already done in messagemanager).
Comment 102 User image kumar rishav (:rishav_) 2014-11-28 01:28:55 PST
Hi Steve
That Problem solved :)
Thanks
Comment 103 User image kumar rishav (:rishav_) 2014-11-28 23:36:22 PST
Comment on attachment 8474223 [details] [review]
Bug 829820 - Ability to mark selected SMS thread as Read/Unread

Hi Steve
Updated the patch.
Assuming comment 82 and 88.
Thanks
Comment 104 User image Jenny Lee 2014-12-11 02:15:23 PST
(In reply to Steve Chung [:steveck] from comment #99)
> (In reply to Jenny Lee from comment #82)
> 
> > Hi Kumar, this is unfortunately something we can't quite avoid. Let's do if
> > user selects only the draft or error message, gray out the mark as unread
> > button. If the selected messages contain read messages and draft(or error
> > ones), user can mark as unread, however, the function will have no effect on
> > draft or error messages. Thanks!
> 
> (In reply to Jenny Lee from comment #88)
> 
> > If user selects multiple threads that contains both regular message and the 
> > ones that can't apply "mark as read/unread", the "mark as read/unread" button
> > will still be actionable, not gray out.
> 
> Hi Jenny, these comments seems different from what you told to me today,
> could you please confirm your idea again here and update to the spec? Thanks!

Hi Steve and Kumar,

Let me list out the cases below:
1. Only drafts are selected - mark as read button gray out.
2. Only messages with error are selected - mark as read button gray out.
3. Only read messages are selected - mark as unread button actionable.
4. Only unread messages are selected - mark as read button actionable.
5. Select a combination of 1, 2, 3/1, 3/2, 3 - show mark as unread button, the function will have no effect on draft or error messages.
6. Select a combination of 1, 2, 3, 4/1, 3, 4/2, 3, 4 - show mark as read button, the function will have no effect on draft or error or unread messages.   
7. Select a combination of 1, 2, 4/1, 4/2, 4 - show mark as read button, the function will have no effect on draft or error messages.

Thanks!
Comment 105 User image Steve Chung [:steveck] 2014-12-15 08:18:05 PST
Comment on attachment 8474223 [details] [review]
Bug 829820 - Ability to mark selected SMS thread as Read/Unread

Hi Kumar, I've left some comments on github. Except one scenario you have to ignore in selection list(sorry about the UI limitation :-/), please avoid to get thread information from DOM element's class or dataset. In the future we will cache all the data instead of rendering all the threads to the list for better performance, and we already refined this for thread deletion part. Please ping me if you're not clear about this part of changes, thanks!
Comment 106 User image kumar rishav (:rishav_) 2014-12-20 08:42:27 PST
Comment on attachment 8474223 [details] [review]
Bug 829820 - Ability to mark selected SMS thread as Read/Unread

Hi Steve
Updated the patch.

As one of the reason for marking unread, is for reminder. So i think for this comment, we can include that once bug 1112028 get land. So for now it will be okay to not ignore this case (this comment).
https://github.com/mozilla-b2g/gaia/pull/22957#discussion-diff-21817367R316

Thanks
Comment 107 User image kumar rishav (:rishav_) 2014-12-20 08:45:49 PST
Reminder ni?me : Bug 1112028 and Bug 1090026, once this bug land.
Comment 108 User image kumar rishav (:rishav_) 2014-12-23 04:29:07 PST
Hope this patch is fine now,
Comment 109 User image Steve Chung [:steveck] 2014-12-23 22:56:49 PST
Hi kumar, the selection part looks fine now, but I found another issue about the markAsRead in message_manager(please ref github and sorry about the late discover :( )

About the draft and unread issue, Jenny has different thought that we shouldn't display unread icon and draft icon at the same time. The list item should represent the latest message or draft. She will reply more in Bug 1112028.

If she insists her idea for the thread list status, that means we still need to check if the latest item is draft or message, and the thread is not selectable if the latest item is draft. So let's wait for her reply, thanks!
Comment 110 User image kumar rishav (:rishav_) 2014-12-24 07:34:34 PST
Comment on attachment 8474223 [details] [review]
Bug 829820 - Ability to mark selected SMS thread as Read/Unread

Hope now it's fine. May be there will some nits.
Thanks
Comment 111 User image Steve Chung [:steveck] 2015-01-06 03:13:37 PST
Hey Kumar, sorry for the late reply. Your patch seems got some conflicts. I also gave some comments about css and unit tests, but the overall js part looks ok now.
Comment 112 User image kumar rishav (:rishav_) 2015-01-09 03:10:54 PST
Done.
Comment 113 User image kumar rishav (:rishav_) 2015-01-13 23:33:11 PST
Hope it won't get merge conflict for some time :)
Comment 114 User image Steve Chung [:steveck] 2015-01-15 07:59:30 PST
It looks fine and I'll do final round for testing. About the image assets, please use png recompressing tool in tools folder (./png_recompress.sh IMAGE_FILE) to make sure the size is as small as possible, thanks.
Comment 115 User image kumar rishav (:rishav_) 2015-01-17 05:53:02 PST
Hi Steve
Those nits on github are done now.
But i am unable to use png recompressing tools.
I used like this:
opensource@opensource:~/firefoxos/gaia/tools$ ./png_recompress.sh ../gaia/apps/sms/style/images/icons/delete.png 
error: optipng not found

Thanks
Comment 116 User image Steve Chung [:steveck] 2015-01-18 22:50:03 PST
Hi kumar, sorry that I forgot to notify you that it requires 'optipng' and 'advpng' tools (from the 'optipng' and 'advancecomp' packages on most Linux distributions as well as macports/homebrew for Mac)
Comment 117 User image Julien Wajsberg [:julienw] 2015-01-19 00:02:37 PST
Rishav, I think the error message was quite obvious "optipng not found". Sometimes you need to find the solution by yourself...
Comment 118 User image kumar rishav (:rishav_) 2015-01-19 00:29:47 PST
Yeah.. i will. Actually i was unware of term "optipng", that it's a package. so... :)
Comment 119 User image Steve Chung [:steveck] 2015-01-20 09:03:11 PST
Created attachment 8551871 [details]
2015-01-21-00-38-54.png

Hope is my last comment on github, but I found a weird visual issue in thread ui view. There is a small gap between delete tab and message bubble. I can only reproduce this on flame and it's fine on desktop. Kumar, could you reproduce this issue on your side?
Comment 120 User image kumar rishav (:rishav_) 2015-01-20 09:20:51 PST
Thanks steve, i am able to reproduce it on my flame too. fix it soon by tonight.
Is it everything okay now in patch other than those nits?
Comment 121 User image kumar rishav (:rishav_) 2015-01-20 12:33:12 PST
Hi steve
Nits on github and visual issue are fixed now. Hope it's ok now.
Thanks
Comment 122 User image kumar rishav (:rishav_) 2015-01-20 13:39:20 PST
Hey steve
Can you feel the lag in diappearing of tab, after cancelling or clicking read/unread button.
I don't how suddenly it appear :( i didn't notice this before.
Comment 123 User image kumar rishav (:rishav_) 2015-01-21 00:55:34 PST
Lag issue fixed now :) 
Everything seems all right now ;)
Comment 124 User image Steve Chung [:steveck] 2015-01-21 22:05:56 PST
Comment on attachment 8474223 [details] [review]
Bug 829820 - Ability to mark selected SMS thread as Read/Unread

Just one nit and the rest looks good and please flag checkin-needed when ready! Thanks for all the great work :)
Comment 125 User image kumar rishav (:rishav_) 2015-01-22 02:39:47 PST
After long time it's finally Done :) 
Thanks Steve, Oleg, Julienw, Gabriele, jenny, Fang and everyone who helped me in this :)

Thanks
Comment 126 User image Autolander 2015-01-22 03:19:17 PST
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/859bfdf1f2a5b4c943ccf009422a8a0d1d8698ae
Comment 127 User image Julien Wajsberg [:julienw] 2015-01-22 03:56:01 PST
\o/ 126 comments later :) thanks a lot
Comment 128 User image Julien Wajsberg [:julienw] 2015-08-31 09:43:46 PDT
*** Bug 961341 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.