Fenix: FNX-5538 ⁃ Consider removing quick action bar "partially visible" state

[sblatz]

I think we should reconsider the UX on the quick action bar "peeking." As someone who will rarely use this feature, it feels bad that I will have to swipe it away every time I open a tab. Perhaps we could persist the swipe state between app launches (if I collapse it, keep it collapsed forever!)

Requiring our users to swipe away something that obscures content on every tab opening feels burdensome.

[cadeyrn]

I totally agree. It's nice for the first run so that people can discover this feature but once I know the feature and collapsed it I don't need to see it in every tab. That's a bit annoying.

[shorlander]

I think we should reconsider the UX on the quick action bar "peeking." As someone who will rarely use this feature, it feels bad that I will have to swipe it away every time I open a tab. Perhaps we could persist the swipe state between app launches (if I collapse it, keep it collapsed forever!)

Requiring our users to swipe away something that obscures content on every tab opening feels burdensome.

Can you elaborate on why it feels burdensome? It should just happen as a natural part of browser. Similar to how the main toolbar behaves.

[cadeyrn]

I want to add that one reason why it's so annoying for me is that the half visible state is distracting. The browser toolbar is not distracting at all, it's an expected element of the browser. But to see another element and only the half of it, that's unexpected, looks like an error and gets my attention.

(1) and (2) from the last comment would solve that in an elegant way (edit: the comment is no longer there, but you can read the points (1) and (2) in the next comment…). Yes, a bouncing effect is also distracting at first but with the bouncing effect it no longer looks like an error, it looks more like "Hey, did you see this? Try it!). And it's a good way to introduce something new. It's only annoying if it happens every time and on every tab.

I don't think an option to disable the bouning is needed. Just disable it after showing this _n times_ or after the user interacted with the quick action bar or after the user collapsed it manually. I guess once the user noticed the bar it is no longer necessary to make it permanently visible. It may be a good idea to show it more than once but at some point it should be enough.

[derfasthirnlosenick]

I think we should reconsider the UX on the quick action bar "peeking." As someone who will rarely use this feature, it feels bad that I will have to swipe it away every time I open a tab. Perhaps we could persist the swipe state between app launches (if I collapse it, keep it collapsed forever!)
Requiring our users to swipe away something that obscures content on every tab opening feels burdensome.

Can you elaborate on why it feels burdensome? It should just happen as a natural part of browser. Similar to how the main toolbar behaves.

Probably bc. it requires manual interaction and considering limited screenspace if you know the quick action bar already, you dont want it to take up space. Kinda like the EU cookie banners.

WRT the visibility of the quick action bar, here's a few ideas:

1. Make it "bounce" up and then vanish to the normal state
2. Disable the "bounce" for users that have used it once/multiple times (presuming they know the feature) and/or give the option to disable it (eg. a "highlight new features" toggle)
3. Include it in a "tour" of the app when users first install it (with any other features that are firefox-specific and/or new)
4. Test & measure how people respond to the various options (e.g. bounce vs. half-visible vs. invisible) both quantitative (i.e. frequency of use over time, how often does the panel get manually closed/opened) as well as qualitative (do people know the feature? do people like it? do they find it annoying?). The qualitative aspects could be requested at the end of the quantiative study before submitting the data package.

Edit: managed to post this with an old account, that's why the previous comment disappeared. Sorry for that...

[derfasthirnlosenick]

One more suggestion: for dynamic actions (eg reader mode) that aren't active on every site, it might make sense to trigger the visual cue as well upon load. This could be bouncing, or something more subtle like a colour hint (eg tinting the grab-bar thingy of the drawer in the color of the reader-mode icon).

[sblatz]

Of note: the bar already has a bounce animation I created that plays the first couple times you launch browser fragment. It's possible we could make that animation happen every 3 launches for the first 9 launches or something to make sure people see it if the concern is visibility.

[mcomella]

fwiw, I noticed that the "partially visible" bar will obscure the design of full screen web sites, potentially making touch targets harder to hit (see attached):

[lime124]

@apbitner for your consideration while you're looking at improving the discoverability for QAB

[sblatz]

For QA: The UX decision here was to restyle this as follows:

• Play an animation once the user opens the browser (the first two times).
• The animation should expand to show the quick action bar after the page has loaded and following a one second delay
• The animation should pause for a second expanded, then collapse.

If a user just taps the handle area, the quick action sheet should expand fully and stay like that.

[sv-ohorvath]

@sblatz
"Play an animation once the user opens the browser (the first two times)." - ATM if you open 2 tabs in one session the first time, it will show the animation on both tabs and won't show again if you start the browser a 2nd time.

Other issues found are about a11y: #2503

[sblatz]

@sv-ohorvath, that is the expected behavior. When I say "open the browser" I mean navigating to the browser view.

[sv-ohorvath]

Thanks for the clarification! Closing this then as verified.