To return to the previous menu you have to press the < icon to the left of the category. This lends itself to a poor UX if you are scrolled beyond the category. Since there is no snapping to top (a la iOS) the user has to scroll to the top to then be able to go to the previous menu. Additionally (and I can file a separate bug for this) it may be helpful if the sub-category would stick below the category as it is passed. For example at the top level of Settings the first sub is Network & Connectivity. The former should always be present and the latter should stay there up to the next one, Personalization, where it would be replaced by it. This gives the user a visual reminder of the section the setting is under.

Headers are supposed to always stay visible, ensuring that Back buttons also stay visible. If there are exceptions, then we should fix those. I believe there is already a bug out there to address this. Kaze, can you confirm?

I confirm, and the bug should be fixed already. If not, please assign me.

It seems to be fixed in the second level menus, but the main Settings header still scrolls with the content.

Thanks Kaze, assigned to you.

Do we really want the main Settings header to stay fixed? That removes some vertical screen estate and there’s no « Back » button on this header, obviously.

(In reply to Fabien Cazenave [:kaze] from comment #5) > Do we really want the main Settings header to stay fixed? That removes some > vertical screen estate and there’s no « Back » button on this header, > obviously. We'd prefer to err on the side of system-wide consistency. The current Settings header feels "off" because it's inconsistent with the behavior of headers everywhere else in the UX.

OK. This also means that this rule should be part of the Building Blocks rather than defined on a per-app basis.

As this is a BB- item I can't work on it right now, but that could be a job for the UX branch. :-) Please re-assign if you want it for v1.

(In reply to Fabien Cazenave [:kaze] from comment #7) > OK. This also means that this rule should be part of the Building Blocks > rather than defined on a per-app basis. Sounds reasonable to me. Are we sure it's not already part of the header BB? Other apps already seem to implement this correctly. (In reply to Fabien Cazenave [:kaze] from comment #8) > As this is a BB- item I can't work on it right now, but that could be a job > for the UX branch. :-) > > Please re-assign if you want it for v1. Dumb question: does it involve Javascript? UX Branch is supposed to be limited to primarily HTML & CSS tweaks.

No JS involved, it’s just a matter of using “position: fixed” instead of “position: absolute” in the CSS. And no, it’s not part of the BB thing…

Sam, can you take a look at this?