Closed Bug 989810 Opened 7 years ago Closed 7 years ago
[User Story] Email - Quick-to-Top action
User Story: As a user, I want a mechanism to quickly take me to the top of the message list so I can immediately action new emails that I receive. Acceptance Criteria: 1. When a new email arrives, there is an action which results in the user being brought to the top of the email list. 2. Utilizing the action will result in the user immediatly being brought to the top of the email list. 3. Ignoring the action will allow the user to remain at the current point in the list.
2.43 MB, application/pdf
2.70 MB, application/pdf
124.44 KB, application/zip
46 bytes, text/x-github-pull-request
|Details | Review|
No description provided.
User Story: (updated)
Whiteboard: [ucid: Productivity20, 1.4:P2, ft:productivity ] → [ucid: Productivity98, X.X:PX, ft:productivity ]
Spec updated: - Change the design from banner to an icon - Added "New message" behaviour
I did a quick pass of this in this branch (compare view), not fit for review yet: https://github.com/jrburke/gaia/compare/bug989810-email-top-action it only implements the "if past two screens worth of messages, show a tap link to go to the top", and does not try to integrate the stories and ux flows around new messages. Sample zip, generated for flame-type resolutions: http://jrburke.com/work/gaia/email-top-1.zip I got confused a bit when I would be scrolling up in the "two screen length from top" dead-zone where the top action button does not show up, particularly if it had been showing up just before because I just happen to be a bit more than two screens and it was showing for a bit until I reversed scroll directions. That may have not been described well, but my main concern was that I had to keep reminding myself that it would not show up for those first two screens, so I expect we would get QA bug reports and confusion from users about that. It may just make sense to always show the top action once the user scrolls past the very first or first part of the list. Also, given the APZC async scrolling, it is possible to get into situations where the menu jumps or blinks in and out real quick. At least, I think that is my first thought on that behavior. In any case, not committing yet to this work, since the trickier parts are the "new messages" bar style integration and behavior. Just had a thought on how to do the basic mechanism, so wanted to try it out.
Attached quick to top visual spec. Thanks!
feature-b2g: --- → 2.0
Target Milestone: --- → 2.0 S3 (6june)
There is an updated app zip that should be feature complete with the spec, with the following changes: 1) I went with a static animation to show and hide the top action/new message. When trying to match the scroll speed exactly, it was either choppy, or if I placed the div in the scrolling area, jumped around (due to what I believe is APZC async notification of scroll changes vs what is visible on screen). I think it looks nice, but UX/VxD will need to be the final judge. 2) Tapping on the top button jumps the user to the top of the message list. It is a straight jump at the moment. The previous N New Message top banner would try to show the visual scroll to the top, but if you were at the bottom of the list, it could take a while, and had some unevenness to it. So this was was just --- From what I could tell from the fps and layer drawings, it does not seem to adversely affect scrolling vs. what was there before. They both perform similarly. However, something has changed with scrolling in general in master: now, when I scroll fast, I can get a very blurry image of the items, then it snaps in with the appropriately painted display. I am seeing that on hamachi and flame, so thinking it is something general that has changed in the platform. Happens with our without the changes in this ticket. Perhaps if :asuth is talking to graphics people this week, perhaps there is some info that can be gathered about that. If this is not known, then I can file a separate bug about that. In any event, right now, it seems perf is about the same, so I think now it is more about getting UX and Visual Design feedback, so will needinfo them. Juwei and Fang, does this zip satisfy your requirements? Link to app zip (made for flame type devices, but works fine on hamachi type devices too): http://jrburke.com/work/gaia/email-top-2.zip
(In reply to James Burke [:jrburke] from comment #6) > However, something has changed with scrolling in general in master: now, > when I scroll fast, I can get a very blurry image of the items, then it > snaps in with the appropriately painted display. I am seeing that on hamachi > and flame, so thinking it is something general that has changed in the > platform. Happens with our without the changes in this ticket. This is probably progressive / low res tiling which appears to have landed as part of bug 993473. I haven't talked to any graphics peeps about it yet, but I can certainly ask them what we can do to mitigate
:kats indicated the blurry stuff is intentional and has UX sign-off/was requested by UX, specifically Gordon Brander. We end up with a 'displayport (margin)' around the visible area that gets full resolution pre-render, and then beyond that there is the critical displayport that gets low-resolution. I think the idea is that in general we should never show white in this case. There may be tweaking required; :kats indicated there are some bugs and things may get changed/backed out.
Thanks for the update on the fuzzy drawing. For email at least, it looks more like a graphics drawing bug though. For me, the occasional white area was preferable, seemed to blend in more with the background. In any event, I went ahead and filed bug 1020530 track that issue as related to email, it is a separate issue from this bug.
This feature is close but not quite ready in time for the 2.0 feature deadline -- bumping to 2.1.
feature-b2g: 2.0 → 2.1
It looks good to me! Thank you James!
Whiteboard: [ucid: Productivity98, X.X:PX, ft:productivity ] → [ucid: Productivity98, X.X:PX, ft:productivity ][tako]
Target Milestone: --- → 2.1 S2 (15aug)
See pull request for notes on the changes, and see comment 2 for UX expectations on the behavior. Notably, the "N New Messages" topbar display does not show up when user is already at the top of the message list, and when the user manually taps sync, the list should jump towards the top if there are new messages. If the sync is done via periodic sync or other background processes though, it should not jump, but show the top bar notification, if the user is not already at the top.
Attachment #8462843 - Flags: review?(m)
Comment on attachment 8462843 [details] [review] GitHub pull request Looks good to me. Tested locally on device, seems to work as designed. Nice work!
Attachment #8462843 - Flags: review?(m) → review+
Merged in master: https://github.com/mozilla-b2g/gaia/commit/584c831c6b562c6e0dd4517282ab565e149e0ee4 from pull request: https://github.com/mozilla-b2g/gaia/pull/22183
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: 2.1 S2 (15aug) → 2.1 S1 (1aug)
QA Whiteboard: [COM=Gaia::E-Mail] → [COM=Gaia::E-Mail][2.1-feature-qa+]
QA Whiteboard: [COM=Gaia::E-Mail][2.1-feature-qa+] → [COM=Gaia::E-Mail]
Whiteboard: [ucid: Productivity98, X.X:PX, ft:productivity ][tako] → [ucid: Productivity98, X.X:PX, ft:productivity ][tako][2.1-feature-qa+]
[Environment] Gaia 3584b2723412ed3299c6761f465885d80651c87e Gecko https://hg.mozilla.org/mozilla-central/rev/e7806c9c83f3 BuildID 20140820160201 Version 34.0a1 ro.build.version.incremental=94 ro.build.date=Tue May 20 09:29:20 CST 2014 [Result] File 2 bugs because these are not fulfill UX spec.
You need to log in before you can comment on or make changes to this bug.