Closed Bug 1102967 Opened 5 years ago Closed 5 years ago
Need some way to mark an email as unread while viewing it
I find that the usability of reading emails has regressed since we lost the ability to mark an email as unread while reading it. My workflow is that I will often be reading email and want to mark it as unread. Navigating back to the email list, clicking the multi-select, selecting the email, then marking as unread is way too many steps. I would like to be able to mark an email as unread, then continue navigating to other messages directly from the current email, using the prev/next buttons.
Andrew, James - I'm assuming this was an intentional change. Could you by chance point me to the original bug that changed the behavior when we were able to mark an email as unread by tapping on the flag icon I believe? I'd like to find out the original reasoning for the change. Thanks!
Removing asuth from responsibility, I will track down the bug chain.
This is not a comprehensive but history, because I think the main question is, does it make sense now, since different motivations have morphed the discussion over time. Some light background. Bug 918303, landed in Dec 2013 brought the next/previous buttons, so it meant reply/forward was consolidated under one button in the bottom toolbar, where earlier reply was up in the header. That brought the lower reader button design to its current state. Marking read/unread has not been in there since at least July 3, 2013, but that is where we lost some direct file history due to some refactoring, and I am being lazy by not tracing back further, given the higher motivations I list later: https://github.com/mozilla-b2g/gaia/commits/master/apps/email/js/cards/message_reader.html The most recent unfixed bug related to changing the placement of actionable areas is bug 1023656, which is geared to make reply easier by surfacing forward as another button and moving the flag icon into the envelope area. It is hard to see a "mark as unread" getting wedged in if that is the case. --- But stepping back a bit, this question is about expected user flows for email management. This is a tricky subject since many people have many different preferences, so it is best for the UX folks to speak to what is desired for Gaia email given our target markets, so I have ni? Juwei for that as she is the ultimate owner for email UX. Here is how I see it though: we are targeting people that most likely do not have another way to view their email. Mark as unread I think works best if you have other more expansive email viewers on a laptop or tablet, where you might have more affordances for filtering and sorting. Given the limited real estate and not having a way to show only unread email, I can see the general guidance would be to favor workflows that use folders or tags to process email. Starring/flagging the email works since there is a "folder" listing for it, so it can be considered an alternative to using "mark as unread", and it works for gaia email since folder selection is the only filtering that is supported. Adding a "just show unread" in the message list would be hard to do given that the existing actions shown are likely higher value. Gaia email could likely use a "create new folder" at a minimum, to allow people to create a new tag for movement purposes, if using the flagging/starring was not desirable, and that could be added to the folder listing area. So I expect the goal is to favor those types of email processing over unread marking if I were to speculate on UX goals and constraints give target markets. But Juwei can give a more authoritative answer.
Flags: needinfo?(jrburke) → needinfo?(jhuang)
## History ## Wow, so this was bug 797635 which means it was gone by v1.1 and is a lot earlier than I thought. For historical context, this was intentional on the part of people who were not me, and probably did relate to whitespace availability ;) I think UX and product both agreed that people could do this from the message list if they wanted to. Being so long ago, we've gone through several UX and product people since then. Adding :swilkes as well since she is our new product manager (and also speaks UX :) ## High Level Rethink ## Given our limited screen real estate and varying personal flows, my personal fancy pants proposal for workflow/triage purposes would be to recognize that people have varying flows and provide configurable coverage (with reasonable default) to let them do what they want. ### Analysis ### At a high level, people presumably have these flows: - High priority: I care about this and I want to treat it as such, doing something special with it. - Not done with: I am unable to fully triage this here, I want to leave it alone. - Done, history: I have no reason to see this message anymore unless I go looking for it - Done, nuke: I never want to see this message again, including being able to search for it. Right now we have the following buttons and they potentially correspond to: - trash: "done, nuke" - flag: "high priority" - move: depends, arguably this enables the user to inefficiently do any of the options - (reply is for acting on a message, you still need one of the other buttons) - arrow buttons: "done, history" if you are the type of person who leaves everything in their inbox Bug 1023656 ("single step reply to email") calls for moving the flag icon up to the envelope area and having the buttons across the bottom be: trash, move, forward, reply all, reply. Arrow buttons are kept. ### For Kevin ### A possible workflow for Kevin could be: - high priority: flag, advance to next message in configurable direction that defaults to down - not done with: mark unread, advance to next message - done, history: perform gmail archive step, advance to next message - done, nuke: eh, if you've got gmail, why nuke? ### My Proposal ### To have the buttons to support this, and because I still disagree with what's going on on bug 1023656 at many levels (it's a waste of space to split the buttons out like that and I think taking UX directives from partners is a bad idea and doesn't scale), I would propose the following setup: - toolbar buttons are (from left to right): - done, nuke - done, history - high priority, done, history - menu - right header button is smart-ish reply that is configurable. Research has shown that humans are email-sociopaths who use reply all, so that will be the default. Settings can let the user choose to instead default to the safer "just reply". It doesn't particularly matter because once you show up on the compose page, we let you flip between reply/reply all/forward (as appropriate). We get rid of the up/down arrows, at least when configured for workflow mode involving auto-advancing. The arrows are biased to the use-case where you you just leave messages marked as read in place in your inbox. Inbox Zero types presumably would not use them, at least if they're treating their FxOS device as a serious device they use for more than skimming.
Er, and the customization for this would basically be something like: !!! Workflow Header !!! When I handle a message move... [to the next earlier messsage, which is down in the message list] (HIGH PRIORITY ICON) When I mark a message as high priority: [ ] Flag the message [ ] Mark it as unread ( ) Move it to folder [...] ( ) Ask me what folder to move it to ( ) Leave it where it is ... and advance to the next message (NOT DONE WITH ICON) When I am not done with a message: eh, same as high priority, maybe (DONE, HISTORY ICON) When I am done with a message for now and would still be able to consult it later: ( ) Archive it to the archive folder [... if not gmail and this could be sorta configurable but we still could perhaps autodetect this a bit ( ) Ask me what folder to move it to ( ) Leave it in this folder (DONE, NUKE ICON) When I am done with a message forever: ( ) Archive it to the archive folder [... if not gmail and this could be sorta configurable] ( ) Move it to the trash folder
(In reply to James Burke [:jrburke] from comment #3) > Adding a "just show > unread" in the message list would be hard to do given that the existing > actions shown are likely higher value. I do want to call out that adding a "quick filter" type mechanism like we implemented for Thunderbird is pretty easy for "unread" or "starred" using the existing searchfilter mechanism. "Is a contact" is also viable using a more efficient AuthorFilter that uses a set, assuming that the mozGetAll call doesn't explode us. (Longer term we may end up just consuming contacts via data store). The biggest effort in most cases would be implementing the UX and doing the BrowserContext refactoring so we can improve our slice handling in the front-end. Plus if we wanted to be able to maintain our position in the list if we were scrolled down we'd have to do some of that seek work we put off. > Gaia email could likely use a "create new folder" at a minimum, to allow > people to create a new tag for movement purposes, if using the > flagging/starring was not desirable, and that could be added to the folder > listing area. Context for everyone: please keep in mind that "folder = label" is a gmail-only thing and not how the traditional IMAP flags/keywords model works. And gmail does support flags/keywords on IMAP, they just don't show up in the gmail web UI. Also, gmail's X-GM-LABELS extension does let us see and manipulate gmail labels for a message like they were flags/keywords. (Like we don't have to play a game with moving messages between folders, we can just directly manipulate the label.)
The different workflow customization seems very interesting, but also much more complicated than I was hoping for. I'm looking for a simple way to mark email as unread from the email page here, I think this is a fairly common workflow as others have complained about the same thing to me. I'm not really looking to change my workflow here, and I think it would be trivial to add an option to do this from a few menus. Some ideas: 1 - Make the 'flag' option more of a menu with the option to mark as unread, or flag. I think this is what we had before? 2 - Stuff another option into the tabs at the bottom, making 5 icons across instead of 4. Maybe there's room for it? 3 - Even some hidden option would be better for me. E.g., swiping right on the bottom tabs could make another option appear. This would be like how the old home screen tray used to work. In any case I'll wait until UX proposes something for this.
Hi Kevin, Thank you for your suggestion! In fact, I did think about reorganising all actions on reading view in few months ago. I had few ideas about it: 1. Move flag icon away from toolbar and place it besides subtitle. User can tap on icon directly to flag/unflag the email on reading view. So an extra space can fill the "mark as read/unread" icon in. This is the best idea, I guess. Yet we need to re-layout the reading view since flag icon changes its position. 2. Squeeze the "mark as read/unread" icon on the tool bar. Then it will have 5 icons in toolbar. I'm not really recommend this idea, yet it can be an alternate solution if we only have short time. I think the idea you proposed on 1) is also good, yet I think it has some difficulty to have an icon represents for both "flag" & "mark as unread" Need info Stephany as she is PM and see if we have any plan on it :)
Juwei, are your suggestions only for Arabic, or do they apply to icon changes regardless of language? Otherwise, we should flag the Comms PM for this. I am not aware of any plans to make these changes.
(In reply to Stephany Wilkes from comment #9) > Juwei, are your suggestions only for Arabic, or do they apply to icon > changes regardless of language? Otherwise, we should flag the Comms PM for > this. I am not aware of any plans to make these changes. Did you comment on the right bug? It doesn't seem like anyone mentioned Arabic and that seems like an RTL bug discussion type thing.
Andrew, I did - I didn't understand why I was being flagged, as I'm not the PM for Comms, but I am for RTL, so figured that may have something to do with it. Flagging Wilfred.
Flags: needinfo?(swilkes) → needinfo?(wmathanaraj)
Ugh - sorry. Somehow I interpreted this as SMS and not Email, and I have no idea why. I have been very sick lately and am on a lot of cold medicine, so perhaps that's it. What exactly is the feature/change proposal here? It's very hard to follow from this thread.
(In reply to Stephany Wilkes from comment #12) > What exactly is the feature/change proposal here? It's very hard to follow > from this thread. I am requesting that we restore the mark as unread button while viewing an email. For more details, read comment 0.
So we're restoring the old UI?
(In reply to Stephany Wilkes from comment #14) > So we're restoring the old UI? That's what *I* want ;-) I'm not sure about UX/Product though.
And my comments 4 and 5 are more of a "what would be our idealized workflow mechanism?" with a proposal by me. More tersely, we're burning up a fair amount of button space on the next/prev buttons that might be mooted by a more explicit workflow. And we'll definitely burn up even more button space when we implement bug 1023656 and make there be 3 separate reply-ish buttons instead of one.
Likely a new UX spec that takes into account different req
Ugh, hit wrong key on keyboard, and was not going to send anything. Since I goofed, completing the thought: Likely a new UX spec for message_reader functionality that takes into account different requests from folks on desired functionality. In the broader picture, it might be good for UX to outline the workflows the email app is supposed to try to accommodate, similar to what comment 3 tries to express. It cannot be all things to all people, even though I personally use "keep unread" traditionally in my workflow. We have recently gotten some other UX requests around what actions and next navigation behavior should be, and having purpose document might help guide how we handle those requests. That is more of a meta thing though, does not have to be tracked in this bug, so that is why I decided to not send until I hit the wrong key.
Hi Steph, What I really want to ask you is that do we have plan to do new ux on 2.2 since the bug is talking about a new ux requirement. I don't think we're heading back to the old UI since it was the old UI caused some issues so that we were fixing them by current design. However, I think I have some better ideas, which are the proposals I mentioned on comment 8, to help us both fulfill old requirements and new requirements. So it's very simple now, 2 ideas only: 1. Move flag icon away from toolbar and place it besides subtitle. User can tap on icon directly to flag/unflag the email on reading view. So we got an extra space to fill the "mark as unread" icon. This is the best idea, I guess. Yet we need to re-layout the reading view since flag icon changes its position. 2. Squeeze the "mark as unread" icon on the tool bar. Then it will have 5 icons in toolbar. I'm not really recommend this idea, yet it can be an alternate solution if we only have short time. Regarding to the timeline and resource we have now, which idea do you think it's better and when do you think we can implement it? Let me know your thought :)
We did not have a plan for this, as this was not raised during 2.2 planning as a priority productivity feature we should include, and 2.2 has started. This would either be a 2.2 nice to have if there's time, or 2.3 or later. If a new UX spec is needed it's definitely for 2.3 at this point.
Hi Stephany - Any thoughts on the options in comment 20? These seem like they wouldn't be too difficult to implement, and we may not need a UX spec for them. If we can have some basic UX direction we may be able to find some contributor to implement the solution. To reiterate the current options from comment 20: 1 - Move flag icon from the toolbar, and place it next to the email subject it sounds like? 2 - Add the mark as unread to the toolmar, making five icons.
(In reply to Kevin Grandon :kgrandon from comment #23) > 1 - Move flag icon from the toolbar, and place it next to the email subject > it sounds like? > 2 - Add the mark as unread to the toolmar, making five icons. As I noted in comment 4, bug 1023656 (which from my understanding we are committed to implementing by an agreement with a partner, although that may have changed now) already calls for part 1 and already has plans to fill up the toolbar with 5 buttons that don't include mark as unread (delete, move, forward, reply all, reply). See the UX spec on attachment 8451515 [details].
Thanks for pointing that out Andrew :) Juwei - it looks like you've done the spec in bug 1023656, and it seems that this conflicts with the options in comment 20. Is bug 1023656 a requirement, and do you have any quick thoughts about how we can reconcile the design efforts between "reply all" and "mark as unread"?
Flags: needinfo?(swilkes) → needinfo?(jhuang)
Comment on attachment 8531359 [details] [review] [PullReq] KevinGrandon:bug_1102967_give_me_button to mozilla-b2g:master Here is a simple patch which restores the "mark as unread" button, giving us 5 buttons in the message reader. I think this looks fairly reasonable on a device. Opening this up for a review and UI-review. Let me know what you think!
Comment on attachment 8531359 [details] [review] [PullReq] KevinGrandon:bug_1102967_give_me_button to mozilla-b2g:master Looks good! We can go through this approach and if there's any chance to have further improvement in future release we can consider to move flag icon to the subject line. Great job Kevin !!
Attachment #8531359 - Flags: ui-review?(jhuang) → ui-review+
Comment on attachment 8531359 [details] [review] [PullReq] KevinGrandon:bug_1102967_give_me_button to mozilla-b2g:master I left some feedback in the pull request, flip review back when addressed, and I think it should be easy to finish out review.
Comment on attachment 8531359 [details] [review] [PullReq] KevinGrandon:bug_1102967_give_me_button to mozilla-b2g:master Thanks for the patch, that makes it awfully easy :) I'm happy with the implementation, re-flag for you to review. Thanks!
Comment on attachment 8531359 [details] [review] [PullReq] KevinGrandon:bug_1102967_give_me_button to mozilla-b2g:master Will try the autolander via checkin-needed.
Attachment #8531359 - Flags: review?(jrburke) → review+
https://github.com/mozilla-b2g/gaia/pull/26597 The pull request could not be applied to the integration branch. Please try again after current integration is complete.
https://github.com/mozilla-b2g/gaia/pull/26597 The pull request could not be applied to the integration branch. Please try again after current integration is complete.
Oops, I closed/reopened the PR to re-trigger gaia-try. Seems we may have found an autolander bug.
Ooh, this is happening because the tree is closed and Autolander has no write access. Interesting :) Will wait until the tree is re-opened.
Assignee: nobody → kgrandon
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/0cc7a9eaad6a03167584839e20e1db263c16ee72
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.