Closed Bug 1637652 Opened 4 years ago Closed 4 years ago

Reader mode semitransparent overlay is distracting

Categories

(Toolkit :: Reader Mode, defect, P1)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
mozilla78
Tracking Status
firefox78 --- verified

People

(Reporter: yoasif, Assigned: Gijs)

References

(Blocks 1 open bug, Regressed 1 open bug)

Details

Attachments

(6 files)

The reader mode introduced in bug 1550836 is distracting while reading because it obscures text directly in the view of the content that a person is reading.

Previously, the omnipresent sidebar was better, since a user could simply ignore/be blind to the sidebar.

Suggestions for improvement:

  1. Put view options in a popover like the bookmarks popover. Safari does something similar. The existing book icon could be used for the popover, much like the bookmarks star is used for the bookmark popover.
  2. New and old Edge have toolbars in the content area that appear and disappear when a user mouses over or clicks in the area. This is not great; I'd prefer something like the autohide address bar in Fenix that appears on scroll - this feels like a common interaction. Upon review of other comments, I agree that the show/hide on scroll isn't super native to desktop, so this might not be the best idea.
  3. A button over the content that calls up an overlay - Fennec does this. This feels like a variation of #1 above.

I realize that a horizontal omnipresent (nontransparent) toolbar is also distracting, and the transparency seems to be a nod to that, but the toolbar is very hard to ignore and doesn't feel clean like the reader modes in Safari, Edge and mobile Firefoxes.

This is even worse in full screen mode.

Depends on: 1550836
Regressed by: 1550836

(In reply to Asif Youssuff from comment #0)

  1. Put view options in a popover like the bookmarks popover. Safari does something similar.
  2. New and old Edge have toolbars in the content area that appear and disappear when a user mouses over or clicks in the area. This is not great; I'd prefer something like the autohide address bar in Fenix that appears on scroll - this feels like a common interaction.
  3. A button over the content that calls up an overlay - Fennec does this. This feels like a variation of #1 above.

I realize that a horizontal omnipresent (nontransparent) toolbar is also distracting, and the transparency seems to be a nod to that, but the toolbar is very hard to ignore and doesn't feel clean like the reader modes in Safari, Edge and mobile Firefoxes.

Abe, do you think we should change anything here?

This is even worse in full screen mode.

Why does full screen mode make any difference?

Flags: needinfo?(yoasif)
Flags: needinfo?(awallin)
No longer regressed by: 1550836

(In reply to :Gijs (he/him) from comment #1)

This is even worse in full screen mode.

Why does full screen mode make any difference?

Compared to Fennec or Safari or Edge, the reader modes in those applications are full reading experiences, like an eBook reader. Any distraction in full screen is magnified - likely a reason that the global menu bar is not present in full screen modes in macOS, for example.

The new toolbar acts like the global menu bar on macOS - except that goes away in full screen.

Flags: needinfo?(yoasif)

Hi there, I concur that the semitransparent overlay interferes with the text.

I made this mock-up (see attachment) to show what a toolbar on the left side of the window could look like. In my opinion, "left" is the preferable choice given the many widescreen monitors and laptops and the fact that the text gets centered in Reader Mode.

A popover with settings like the bookmarks popover won't be accessible when the user activated full screen (F11). The left toolbar is to remain visible, even in full screen mode. It can be shrunken horizontally if necessary.

Another idea is to put a "full screen" button in the toolbar (for those who didn't remember F11).

Just my 2 cents. Thanks for reading!

One of the goals for the redesign was making the features (Type control, Listen, and Save to Pocket) more visible as our research showed these we're often missed. There's a balance to making people aware of these while maintaining a clean and distraction free reading environment.

@Gijs can we slide the menu away when scroll down begins and then slide it back in on scroll up?

Flags: needinfo?(awallin)

(In reply to Abraham Wallin from comment #4)

@Gijs can we slide the menu away when scroll down begins and then slide it back in on scroll up?

And what if the user wants to interact with the toolbar? Scrolling up for displaying the toolbar in that case sounds counter-intuitive to me.

(In reply to Itiel from comment #5)

And what if the user wants to interact with the toolbar? Scrolling up for displaying the toolbar in that case sounds counter-intuitive to me.

Hiding/showing a menu bar on scroll up/down is a fairly established UI pattern. In this case most of the interactions with the controls in the menu are likely to occur when a user first opens reader mode. One instance where this may not be the case is when using the 'listen' feature. So, when playing an article we should keep the menu sticky at the top of the screen so they controls remain accessible.

Hiding/showing a menu bar on scroll up/down is a fairly established UI pattern.

Not for the purposes of a Reader Mode which is mostly necessary for users or in situations where such interactions are difficult or annoying.

The screenshots shown by Ruben are a clear indication of which one is better: It's the bottom one because it shows more text, it's easier to use, and advertises more clearly these Reader functions.

(In reply to Abraham Wallin from comment #4)

One of the goals for the redesign was making the features (Type control, Listen, and Save to Pocket) more visible as our research showed these we're often missed. There's a balance to making people aware of these while maintaining a clean and distraction free reading environment.

@Gijs can we slide the menu away when scroll down begins and then slide it back in on scroll up?

We could, yes. However, I agree with Itiel:

(In reply to Abraham Wallin from comment #6)

(In reply to Itiel from comment #5)

And what if the user wants to interact with the toolbar? Scrolling up for displaying the toolbar in that case sounds counter-intuitive to me.

Hiding/showing a menu bar on scroll up/down is a fairly established UI pattern.

I think the scroll effect is common on mobile, but not on desktop, and it would be hard for users to discover. I think the mobile scroll/swipe-based behaviour exists because there are no mouseover events on mobile, which is how this used to be done in desktop apps (and still is to show toolbars in full screen, for instance).

Unfortunately going the mouseover route would not be keyboard accessible, and would also be a little messy in that mousing to the top of the content window is more likely to mean the user wants to interact with the address bar or other toolbar controls, not with the reader mode toolbar.

Are there other mechanisms we could consider to re-show the toolbar? We could collapse it into a single button in the top left / top right, and reopen it when the user clicks or hovers that, perhaps? The button could be fixed-positioned so that it would always be immediately accessible.

In this case most of the interactions with the controls in the menu are likely to occur when a user first opens reader mode. One instance where this may not be the case is when using the 'listen' feature. So, when playing an article we should keep the menu sticky at the top of the screen so they controls remain accessible.

I'll keep this part in mind either way; I agree there should be a constant indicator of the narration being active, also to ensure that users can quickly play/pause the narration, and change the narrate position.

Flags: needinfo?(awallin)

In bug 1550836 I read:

One of the goals for the redesign was making the features (Type control, Listen, and Save to Pocket) more visible as our research showed these we're often missed.

(In reply to :Gijs (he/him) from comment #8)

Are there other mechanisms we could consider to re-show the toolbar? We could collapse it into a single button in the top left / top right, and reopen it when the user clicks or hovers that, perhaps? The button could be fixed-positioned so that it would always be immediately accessible.

I don't get how an auto-hiding horizontal toolbar, that is semitransparent (which makes the buttons harder to see), will make the Reading Mode features more discoverable compared to the old design?

@awallin I'd like to politely ask you to reconsider the vertical toolbar solution with bigger buttons (see mock-up), or a similar design. That way, settings are always within reach, don't interfere with text and are better discoverable. Are there any disadvantages that speak against the vertical toolbar (apart from some rework)?

Thanks!

(In reply to Ruben from comment #9)

In bug 1550836 I read:

One of the goals for the redesign was making the features (Type control, Listen, and Save to Pocket) more visible as our research showed these we're often missed.

(In reply to :Gijs (he/him) from comment #8)

Are there other mechanisms we could consider to re-show the toolbar? We could collapse it into a single button in the top left / top right, and reopen it when the user clicks or hovers that, perhaps? The button could be fixed-positioned so that it would always be immediately accessible.

I don't get how an auto-hiding horizontal toolbar [...] will make the Reading Mode features more discoverable compared to the old design?

Having the items at the top makes them more prominent and easier to spot than having them at the side, IMO, and is a familiar pattern on the web (heck, even on this bugtracker, even though here too, the main content is centered). Hiding them after scrolling down is what everyone in this ticket seems to want so they're not "in the way", but yes, obviously that means they're then less prominent, just like they were in the sidebar. On the other hand, having them appear/disappear with animation would help make it more obvious for new users that there's something there (though we'll continue to respect animation preferences).

It's all a trade-off, you cannot make all of the people happy all of the time, etc.

Assignee: nobody → gijskruitbosch+bugs
Severity: -- → S2
Status: NEW → ASSIGNED
OS: Unspecified → All
Priority: -- → P1
Hardware: Unspecified → Desktop

Did the original investigation of the problem consider using some sort of onboarding mechanism (like an initial highlight, pop over, something that would immediatelly gain user's attention; moving the control to the top is not as prominent as these ideas) instead of changing how the controls are displayed? It was already stated that the problem is "controls discoverability" when in Reader mode, however that seems like something that happens only for new users that have never used this mode before. After that, the whole purpose of moving this to the top of the content's screen is not worth worsening the overall experience (or straight up - no longer valid). Even after that, you can still make it just a bit more prominent, but not too distracting, by (as already suggested) making the icons biggers, or even by slightly differentiating the background of the control bar to stand out from the content's background.

For me personally, it's not about the wasted vertical space, but it's about the distraction that the top bar introduces. With the bar on top, I'm constantly distracted by its existence, where with the bar on the left side I haven't even noticed it (probably because it was far away from the actual content that I was reading). Reader mode is supposed to be "distraction free", so an attempt to "market its features better" with a permanent change doesn't feel right.

For comparison, on Edge, the menu appears when you first enter the reading view. It then disappears after 3 seconds. You can make the menu reappear by clicking anywhere on the page.

(In reply to :Gijs (he/him) from comment #8)

Unfortunately going the mouseover route would not be keyboard accessible, and would also be a little messy in that mousing to the top of the content window is more likely to mean the user wants to interact with the address bar or other toolbar controls, not with the reader mode toolbar.

On Edge, the menu is shown/hidden when the page is clicked. For keyboard navigation, I can make it show by hitting tab enough times and cycling through all the toolbar buttons. Once the focus gets to the first button on the reading menu, the menu reappears if it is currently hidden.

(In reply to :Gijs (he/him) from comment #8)

Are there other mechanisms we could consider to re-show the toolbar? We could collapse it into a single button in the top left / top right, and reopen it when the user clicks or hovers that, perhaps? The button could be fixed-positioned so that it would always be immediately accessible.

This made me think of the old setting sidebar for the new tab page. This feels more like desktop software and gets out of your way (with a fixed position/sticky), with an easy way to get the settings back if you want.

Something else to consider.

We need two-page mode. Like in coolreader.

Attached image cr3.png

(In reply to Asif Youssuff from comment #15)

Created attachment 9149240 [details]
sidebar from new tab page.png

(In reply to :Gijs (he/him) from comment #8)

Are there other mechanisms we could consider to re-show the toolbar? We could collapse it into a single button in the top left / top right, and reopen it when the user clicks or hovers that, perhaps? The button could be fixed-positioned so that it would always be immediately accessible.

This made me think of the old setting sidebar for the new tab page. This feels more like desktop software and gets out of your way (with a fixed position/sticky), with an easy way to get the settings back if you want.

Something else to consider.
Interesting suggestions. However, I see two problems with the "single button" and "settings sidebar" solutions.
The moment the toolbar or sidebar is hidden...

  1. ... the user may not find the "Done" button to exit Reader Mode
  2. ... discoverability of settings is reduced, which was a goal of the redesign.

That's why I think a vertical, fixed toolbar with slightly larger buttons (and button text), possibly combined with an onboarding process, is still the superior solution.

The strength of today's Reader Mode is you press F9, and instantly gets a clutter-free, animationless, "quiet" reading environment.

Hi,
I've read the reasons which lead to move from a vertical to an horizontal toolbar.
I don't like it for optimum space considerations but I can understand it.
However I can't explain why, on top of that, the new horizontal toolbar is so big : why not choose the same size that in the other Reader mode : the pdf reader mode ?
Thanks

Hi All, thanks thanks for the feedback. I'm reminder why it's great to have Nightly to gather early feedback on changes.

We explored new options for the menu and believe we found a version that balances the need to provide distraction free reading while at the same time aids novice users in discovering these features when they first enter reader mode.

These changes move the menu back to a sidebar to maximize vertical real estate and minimizing distractions while scrolling/reading. The sidebar is pinned closer to the content area and is a bit more prominent when first entering reader mode but quickly fades on scroll to be less of a distraction.

There are some challenges making this work at all sizes (specially small browser widths) and when actively using controls (width adjustment) but we think we have good solutions for these. The changes should be available soon and we'd appreciate any feedback you have about your particular experience with them.

(In reply to Abraham Wallin from comment #23)

Hi All, thanks thanks for the feedback. I'm reminder why it's great to have Nightly to gather early feedback on changes.

We explored new options for the menu and believe we found a version that balances the need to provide distraction free reading while at the same time aids novice users in discovering these features when they first enter reader mode.

These changes move the menu back to a sidebar to maximize vertical real estate and minimizing distractions while scrolling/reading. The sidebar is pinned closer to the content area and is a bit more prominent when first entering reader mode but quickly fades on scroll to be less of a distraction.

There are some challenges making this work at all sizes (specially small browser widths) and when actively using controls (width adjustment) but we think we have good solutions for these. The changes should be available soon and we'd appreciate any feedback you have about your particular experience with them.

Looking forward to testing the new version!

Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/3017e4a90448
switch back to a sidebar in reader mode, r=eeejay
https://hg.mozilla.org/integration/autoland/rev/8f9d7916be01
switch to a sticky-position and deal with the content moving while dropdowns are up, r=eeejay
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
Flags: needinfo?(awallin)
Blocks: 1638223

I just did a few tests. This is a huge improvement. Great job!

Two minor remarks (I don't know if I should make bugs for these):

  • Users may think the close button (x) will only close the vertical toolbar. Maybe the 'quit' icon from the hamburger menu could be used for Reader Mode as well? (and change text to "Quit" instead of "Close")?
  • In the Dutch version, the "Dark" text ("Donker") falls beneath the radio button, whereas the other options have the text next to the radio button. Also, the text of the three options is rather small. Is it possible to decrease margins/padding or something?

Thanks!

Regressions: 1640410
Regressions: 1640438
Blocks: 1641266
Regressions: 1642510
Flags: qe-verify+

In an attempt to verify the issue, I was unable to "get the affected builds(2020-05-12-Nighlty)" to manifest the transparency.
Was it hiding behind a pref by any chance or are there some settings for it?

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Cristian Fogel, QA [:cfogel] from comment #28)

In an attempt to verify the issue, I was unable to "get the affected builds(2020-05-12-Nighlty)" to manifest the transparency.
Was it hiding behind a pref by any chance or are there some settings for it?

There was no pref. The transparency was visible when scrolling down while in reader mode - see e.g. attachment 9148141 [details]. Does that help?

Edit: note that bug 1550836 landed on 2020-05-13, so the 05-12 nightly won't have that change.

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(cristian.fogel)

Oh my ... indeed, with 78.0a1 (2020-05-13) the reported issue can be noticed.
Marking as verified - after checking with 78.0b8.

Thank you for the input on this! :D

Status: RESOLVED → VERIFIED
Flags: needinfo?(cristian.fogel)
Flags: qe-verify+
Regressions: 1650922

Blocks: 1658211

Regressions: 1658211

Regressions: 1649666

Regressions: 1649666

Hiding/showing a menu bar on scroll up/down is a fairly established UI pattern.

If you're referring to the widespread use of position:sticky headers, then, like most show/hide animation, it's also a migraine trigger. fairly established =/= good.

Duplicate of this bug: 1649666
No longer duplicate of this bug: 1649666
You need to log in before you can comment on or make changes to this bug.