Closed Bug 829820 Opened 11 years ago Closed 9 years ago

[Messages] Ability to mark selected SMS threads as read/unread

Categories

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

All
Gonk (Firefox OS)
enhancement
Not set
normal

Tracking

(tracking-b2g:backlog, ux-b2g:2.2)

RESOLVED FIXED
tracking-b2g backlog
ux-b2g 2.2

People

(Reporter: MattN, Assigned: rishav_, Mentored)

References

Details

(Keywords: feature, Whiteboard: [needs UX][needs VD], ux-most-wanted-nov2014)

Attachments

(3 files, 9 obsolete files)

610.92 KB, application/pdf
Details
46 bytes, text/x-github-pull-request
steveck
: review+
Details | Review
120.69 KB, image/png
Details
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".
Whiteboard: v1.2
Keywords: feature
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?
Flags: needinfo?(aymanmaat)
Whiteboard: v1.2
(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
Flags: needinfo?(wmathanaraj)
Flags: needinfo?(noef)
Flags: needinfo?(aymanmaat)
Flags: needinfo?(noef)
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).
i will add to backlog doc and we need to scope after we finish any committed items for v1.3.
Flags: needinfo?(wmathanaraj)
blocking-b2g: --- → 1.4?
New feature, if someone has bandwidth to implement it please land it. Not a blocker.
blocking-b2g: 1.4? → ---
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?
Flags: needinfo?(wmathanaraj)
Flags: needinfo?(dscravaglieri)
backlog for future work - perhaps we can work on this as time permits and implement
blocking-b2g: --- → backlog
Flags: needinfo?(wmathanaraj)
clear ni?
Flags: needinfo?(dscravaglieri)
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?
Flags: needinfo?(wmathanaraj)
Whiteboard: [needs UX][needs VD]
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.
 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.
Flags: needinfo?(wmathanaraj) → needinfo?(jcheng)
ni? UX team, any idea on how we enable UX contribution as well? Thanks
Flags: needinfo?(jcheng)
Flags: needinfo?(ofeng)
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.
Assignee: nobody → rishav006
Status: NEW → ASSIGNED
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?
Flags: needinfo?(wmathanaraj)
Flags: needinfo?(cawang)
Attached file UX flow proposal (obsolete) —
Hi all
Here is the proposal for UX flow that i proposed.
Thanks
(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.
(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.
Flags: needinfo?(cawang)
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
Flags: needinfo?(wmathanaraj)
(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?
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
(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.
Flags: needinfo?(ofeng)
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
Flags: needinfo?(ofeng)
(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.
Flags: needinfo?(ofeng)
(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.
(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.
Flags: needinfo?(ofeng)
Attached file [1.5 Messages] Select Items v1.0.pdf (obsolete) —
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.
Flags: needinfo?(ofeng)
(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?
Flags: needinfo?(felash)
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
Flags: needinfo?(ofeng)
(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.)
Flags: needinfo?(ofeng) → needinfo?(wmathanaraj)
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.
Flags: needinfo?(felash)
(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.
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
Attachment #8430042 - Flags: feedback?(ofeng)
Attachment #8430042 - Flags: feedback?(francisco)
Attachment #8430042 - Flags: feedback?(felash)
Hi all
Here is all the screen shots of new functionality in action (in pdf form).
Thanks
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.
Attachment #8430042 - Flags: feedback?(francisco)
Attachment #8430042 - Flags: feedback?(jelee)
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!
Attachment #8430042 - Flags: feedback?(ofeng)
Attachment #8430042 - Flags: feedback?(jelee)
Attachment #8430042 - Flags: feedback+
> 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.
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
Flags: needinfo?(jelee)
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.
> 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!
Flags: needinfo?(jelee)
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
Attachment #8430051 - Attachment is obsolete: true
Attachment #8432821 - Flags: feedback?(jelee)
Attachment #8432821 - Flags: feedback?(gsvelto)
Attachment #8432821 - Flags: feedback?(felash)
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
Attachment #8432825 - Flags: review?(jelee)
Attachment #8432825 - Flags: review?(gsvelto)
Attachment #8432825 - Flags: review?(felash)
Comment on attachment 8432821 [details]
Screen shots for changes in Thread list

The visual style needs some modification, flagging Vicky for visual input.
Attachment #8432821 - Flags: feedback?(vpg)
Attachment #8432821 - Flags: feedback?(jelee)
Attachment #8432821 - Flags: feedback-
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.
Attachment #8432825 - Flags: review?(vpg)
Attachment #8432825 - Flags: review?(jelee)
Attachment #8432825 - Flags: review+
(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 ;) )
Attachment #8432821 - Flags: feedback?(vpg) → feedback-
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.
Attachment #8432825 - Flags: review?(vpg) → review-
Hi Vicky
Can you explain more? I didn't get you.what you mean by "overall multiple delete pattern"?
Thanks
(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
Flags: needinfo?(jelee)
Vicky, where can we find the current "multiple delete pattern"?
Flags: needinfo?(vpg)
(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.
Flags: needinfo?(jelee)
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
Attachment #8430042 - Attachment is obsolete: true
Attachment #8430042 - Flags: feedback?(felash)
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.
Attachment #8413152 - Attachment is obsolete: true
Attachment #8433373 - Flags: review?(jelee)
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...
Attachment #8432825 - Flags: review?(felash) → feedback+
Flags: needinfo?(mtsai)
Attachment #8432821 - Flags: feedback?(felash) → feedback+
Hi Julien, the "select" panel building block is the same behavior as current spec done by Omega. So nothing will be changed.
Flags: needinfo?(mtsai)
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.
Attachment #8433373 - Flags: review?(jelee) → review+
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!
(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?
Flags: needinfo?(vpg)
@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.
Flags: needinfo?(hhsu)
Flags: needinfo?(cawang)
Flags: needinfo?(wmathanaraj)
(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.
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
Flags: needinfo?(ofeng)
Flags: needinfo?(jelee)
(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.
Depends on: 1020306
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.
Flags: needinfo?(ofeng)
Flags: needinfo?(jelee)
Attachment #8432821 - Attachment is obsolete: true
Attachment #8432821 - Flags: feedback?(gsvelto)
Attachment #8432825 - Attachment is obsolete: true
Attachment #8432825 - Flags: review?(gsvelto)
Attachment #8433373 - Attachment is obsolete: true
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.
Flags: needinfo?(hhsu)
Hi Harly
you mean 'icon'  for everything : Select all,Deselect all,Mark As read/unread,Delete ?
Thanks
Flags: needinfo?(hhsu)
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
Flags: needinfo?(hhsu)
Attached file [1.5 Messages] Select Items v1.1.pdf (obsolete) —
Updated wireframe, adding select itmes> delete in message thread view.
Attachment #8417921 - Attachment is obsolete: true
Hi jenny
I think you forgot to include this case : long press on message
Thanks
Flags: needinfo?(jelee)
(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!
Flags: needinfo?(jelee)
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
Flags: needinfo?(jelee)
(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!
Flags: needinfo?(jelee)
The latest UX spec.
Attachment #8441862 - Attachment is obsolete: true
Flags: needinfo?(cawang)
Summary: Ability to mark selected SMS threads as read → Ability to mark selected SMS threads as read/unread
Blocks: 1037650
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
Mentor: gsvelto
No longer blocks: 1037650
Attached file WIP (Work in progress) (obsolete) —
Hi
Work is in progress.Read/unread functionality
Thanks
Hi Gabriele
Here is the patch. Have a look and give your feedback on this :)
Thanks
Attachment #8460808 - Attachment is obsolete: true
Attachment #8474223 - Flags: feedback?(gsvelto)
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.
Attachment #8474223 - Flags: feedback?(gsvelto) → feedback-
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
Attachment #8474223 - Flags: feedback- → feedback?(gsvelto)
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
Flags: needinfo?(jelee)
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
Attachment #8474223 - Flags: feedback?(gsvelto)
Depends on: 1040875
No longer depends on: 1020306
Depends on: 1020306
(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!
Flags: needinfo?(jelee)
(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!
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
Flags: needinfo?(jelee)
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
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.
Flags: needinfo?(mtsai)
Flags: needinfo?(hhsu)
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
Of course we can; but as I said, when we need to change the API, it's painful and expensive.
(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!
Flags: needinfo?(jelee)
Blocks: 1067275
Hi Stephany,
I was involved with the design of message multiselect mode, and it fits our current pattern design.
Thanks
Flags: needinfo?(mtsai)
Flags: needinfo?(hhsu)
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?
Flags: needinfo?(btseng)
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).
Flags: needinfo?(btseng) → needinfo?(jelee)
(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 ;)
Flags: needinfo?(jelee)
Attachment #8474223 - Flags: feedback?(gsvelto)
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
Hi Julien
It will be nice if you too have a look on PR.
Thanks
Blocks: 1096862
ux-b2g: --- → 2.2
Whiteboard: [needs UX][needs VD] → [needs UX][needs VD], ux-most-wanted-nov2014
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
Attachment #8474223 - Flags: feedback?(felash)
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 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
Attachment #8474223 - Flags: review?(schung)
Attachment #8474223 - Flags: feedback?(gsvelto)
Attachment #8474223 - Flags: feedback?(felash)
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.
Attachment #8474223 - Flags: review?(schung)
(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!
Flags: needinfo?(jelee)
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
Flags: needinfo?(schung)
*How to change the status of thread in UI (not in backend, as it's already done in messagemanager).
Hi Steve
That Problem solved :)
Thanks
Flags: needinfo?(schung)
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
Attachment #8474223 - Flags: review?(schung)
(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!
Flags: needinfo?(jelee)
Depends on: 1090026
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!
Attachment #8474223 - Flags: review?(schung)
No longer depends on: 1090026
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
Attachment #8474223 - Flags: review?(schung)
Reminder ni?me : Bug 1112028 and Bug 1090026, once this bug land.
Flags: needinfo?(rishav006)
Hope this patch is fine now,
Flags: needinfo?(rishav006) → needinfo?(schung)
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!
Flags: needinfo?(schung)
Attachment #8474223 - Flags: review?(schung)
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
Attachment #8474223 - Flags: review?(schung)
Flags: needinfo?(schung)
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.
Flags: needinfo?(schung) → needinfo?(rishav006)
Done.
Flags: needinfo?(rishav006)
Hope it won't get merge conflict for some time :)
Flags: needinfo?(schung)
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.
Flags: needinfo?(schung)
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
Flags: needinfo?(schung)
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)
Flags: needinfo?(schung)
Rishav, I think the error message was quite obvious "optipng not found". Sometimes you need to find the solution by yourself...
Yeah.. i will. Actually i was unware of term "optipng", that it's a package. so... :)
Attached image 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?
Flags: needinfo?(rishav006)
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?
Flags: needinfo?(rishav006) → needinfo?(schung)
Hi steve
Nits on github and visual issue are fixed now. Hope it's ok now.
Thanks
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.
Lag issue fixed now :) 
Everything seems all right now ;)
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 :)
Flags: needinfo?(schung)
Attachment #8474223 - Flags: review?(schung) → review+
After long time it's finally Done :) 
Thanks Steve, Oleg, Julienw, Gabriele, jenny, Fang and everyone who helped me in this :)

Thanks
Mentor: schung
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
\o/ 126 comments later :) thanks a lot
Depends on: 1124696
Depends on: 1128337
blocking-b2g: backlog → ---
Summary: Ability to mark selected SMS threads as read/unread → [Messages] Ability to mark selected SMS threads as read/unread
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: