989810 - [User Story] Email - Quick-to-Top action

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Comment 1

[Juwei Huang[:juwei]]

Attachment: [Email] Top action.pdf

Spec attached.

Comment 2

[Juwei Huang[:juwei]]

Attachment: [Email] Top action_1.1.pdf

Spec updated:
- Change the design from banner to an icon
- Added "New message" behaviour

Comment 4

[James Burke [:jrburke]]

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.

Comment 5

[Fang Shih [:fang]]

Attachment: quick to top_spec.zip

Attached quick to top visual spec. Thanks!

Comment 6

[James Burke [:jrburke]]

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

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

(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

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

: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.

Comment 9

[James Burke [:jrburke]]

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.

Comment 10

[Dylan Oliver [:doliver]]

This feature is close but not quite ready in time for the 2.0 feature deadline -- bumping to 2.1.

Comment 11

[Juwei Huang[:juwei]]

It looks good to me!
Thank you James!

Comment 12

[James Burke [:jrburke]]

Attachment: GitHub pull request

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.

Comment 13

[Marcus Cavanaugh [:mcav]]

Comment on attachment 8462843 [details] [review]
GitHub pull request

Looks good to me. Tested locally on device, seems to work as designed. Nice work!

Comment 14

[James Burke [:jrburke]]

Merged in master:
https://github.com/mozilla-b2g/gaia/commit/584c831c6b562c6e0dd4517282ab565e149e0ee4

from pull request:
https://github.com/mozilla-b2g/gaia/pull/22183

Comment 15

[Edward Chen[:edchen]]

[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.