Results of the latest perceived performance user study included mixed feedback on the dynamic bottom nav bar. We switched to a static nav bar until we investigate and re-design behaviour. This meta will track the re-design and all related issues.
Issues related to implementing dynamic bottom nav bar:
-UX completed
-User stories completed
-QA completed
https://github.com/mozilla-mobile/fenix/issues/2115
move address bar to bottom of homepage: https://github.com/mozilla-mobile/fenix/issues/1936
set position of search bar: https://github.com/mozilla-mobile/fenix/issues/466
bar moves around depending on context: https://github.com/mozilla-mobile/fenix/issues/562
@apbitner Assigning to you to consider while you look at nav.
@vesta0 can you define what you mean by 'dynamic nav bar' and 'static nav bar' in this instance?
@vesta0 is this labeled waiting b/c we need ux? if so, can we remove the waiting and ux feedback labels as Adam is already working on this. thanks!
For my own notes:
GV couldn't handle bottom overlapping nav bar w/ autohiding (and the resizing transition), so some changes were needed.
This could also be a good candidate for some UX/Eng collab, like suggested in #419 .
removed ux label -it's on our radar already as it's part of the Q3 plan
UX explorations on InVision: https://mozilla.invisionapp.com/share/W8SZ87HSN2G
The top desired options involve auto show/hide of toolbars, so UX work is currently on hold while feasibility and LOE of options is determined with GV team.
I like the options C and D. Make it either top or bottom, not both!
Not sure if my vote counts, but I'd vote for option D.
@apbitner could you give an update here? Are these proposals feasible with the GV options, or should we go with some fallbacks, or altogether deprioritize this until GV is ready?
@liuche We chatted with @vesta0 yesterday and GV said it would take months to implement the auto show/hide we're hoping for. Vesta is waiting on detailed documentation from GV including possible alternative options. UX has alternative options of our own but they would require getting rid of the QAB entirely.
Why not just get rid of the QAB if that helps implement a better nav bar? The QAB functionality is redundant as it is.
The QAB functionality is redundant as it is.
This is not true at all. Or how do you add bookmarks, open the reading mode or use the "open with app" feature? With the current implementation there is no other way to access these feature. Maybe these items could be added to the main menu but with the current menu design there is no space for more menu items on my device without hiding other items. So first a redesign of the menu needs to happen, then an integration of the QAB features into the main menu.
QAB is a great place to put WebExtension actions
@cpeterso what is the GV or Gecko bug related to this? I know this bug has been around forever but for some reason I can't find it 馃槄
what is the GV or Gecko bug related to this? I know this bug has been around forever but for some reason I can't find it 馃槄
You can't find the bug because there isn't one. 馃槃
We have a couple GV/Gecko bugs for dynamic nav bar issues (below), but we didn't open a bug for the big compositor rewrite because we decided against that approach. The rewrite might take about six months so we decided address individual Gecko bugs as Fenix finds them after re-enabling the dynamic nav bar.
Some known issues:
setVerticalClipping
API (to be fixed in September): https://bugzilla.mozilla.org/show_bug.cgi?id=1552608setVerticalClipping
API for WebRender: https://bugzilla.mozilla.org/show_bug.cgi?id=1583380QAB will be removed for now, and revisited once we have auto show/hide capabilities. This will make implementing a top nav easier, though we will have to make updates to the nav bar menu.
thanks @apbitner!
this is what i think is left to complete before passing off to eng. adam, please edit this list with whatever i missed!
I know nicole is doing some stuff in the menu, can you coordinate with her so we are getting all the changes we need in one spec/hand off? thanks!
@cpeterso i'm not totally following your comment and i just want to make sure we all have the same understanding :)
my current understanding is that GV will do the work needed to have the auto show/hide capabilities in Q1. is that your understanding too? thanks!
my current understanding is that GV will do the work needed to have the auto show/hide capabilities in Q1. is that your understanding too? thanks!
We have 2-3 known Gecko/GV bugs that block Fenix auto showing/hiding the dynamic nav bar. The GV team will be working on those bugs in early Q4. Fenix should be able to re-enable the dynamic nav bar in Fenix Nightly for some pre-release user testing in Q4.
Cool thanks!
As discussed during planning week, the actionable next step here is to provide users with the option to move nav bar to the top. Created #5694 and closing this one.
Turning on the dynamic bottom nav bar down the road will be addressed here: #4383
Removing the QAB will be addressed here: #5588
@lime124 and @apbitner let me know if I have missed anything.
The reference issue "bar moves around depending on context" #562 does not seem to be addressed. Did I miss something?
Most helpful comment
We have 2-3 known Gecko/GV bugs that block Fenix auto showing/hiding the dynamic nav bar. The GV team will be working on those bugs in early Q4. Fenix should be able to re-enable the dynamic nav bar in Fenix Nightly for some pre-release user testing in Q4.