Mfcttrf

I recently heard a designer say something to the effect that modern web designs don't use visual scrollbars - or at least they're only visible when scrolling. I'm a front-end developer and hadn't really heard this. Is there any truth to this? Specifically my question is:

For a web app, when content is scrollable:

1. Should there ever be visible scroll bars (and why)?


2. Should there ever not be visible scroll bars (and why not)?

Some modern design guidelines certainly disprefer persistently-visible scrollbars, but not all. For example, in the Material Design guide, for menus, if a menu is scrollable, it should show a scrollbar. In any case, if your content is scrollable, it should be clear from looking at it that it affords scrolling.

It's up to an individual designer or guideline whether that affordance is cued by a scrollbar that clearly indicates how much you can scroll down (traditional), a "read more" link or arrow pointing down-screen (like on many modern app homepages or blogs), or a fade-out as you approach the edge of the content area that implies that you can move that direction to see more or more clearly, but the affordance itself is the necessary component. It would be poor design to present content that can be scrolled but not indicate that scrollability to the user. It could frustrate the user or cause them to miss important information or calls to action.

Yes there should.

Visible scroll bars are an affordance "this page is scrollable"

Without visual hints such as this the functionality might be missed.

This viewpoint comes primarily from the Mac environment, where scrollbars are typically displayed briefly when content first appears, then fade out. When scrolling occurs (user triggered or otherwise), the scroll bar reappears. Only the handle is visible (as a semi-transparent rounded black bar); no arrows or gutter. If the cursor is over the scroll bar when it appears, it becomes wider and allows dragging with the cursor. At no point does the content change size; it behaves as if the scrollbar were not present, and the scrollbar is rendered on top.

This applies when using trackpad or trackpad-like input mechanisms (i.e. a laptop). Regular scrollbars are still displayed by default when using a mouse.

Of course, this also extends to mobile; iOS uses almost identical behaviour (minus cursor interaction). In fact I think it started on iOS (where scrollbars would be too small to tap reliably) and migrated to MacOS.

Overall, this has advantages and disadvantages:

• Not needing to make space for scrollbars simplifies the page design (fewer distracting elements) and allows more space for the content, especially when there are multiple places which can scroll.


• Users on mac are accustomed to this behaviour and expect it.



• There is no jump in content size when an area suddenly becomes scrollable, which also fixes a common ambiguity where a scrollbar can be needed so long as it is visible, and not needed if it is hidden (e.g. due to text wrapping).




• On the negative side, as has already been mentioned, you need to come up with another way to indicate the content is scrollable. Not such an issue for the main part of a webpage because this is expected anyway, but can be an issue for internal content depending on user expectations. The initial flash helps, but is not always enough.



• The user interaction for jumping to another location in the document is clunky; the user must move their cursor to where the scroll bar will appear, scroll slightly with the mouse wheel or "2-finger scroll", grab the scroll bar when it appears, and drag to the desired location. Momentum scrolling helps to avoid this in some cases.


• Because the scrollbar appears on a transparent background, if the background is dark it can be hard to see. MacOS provides a white alternative scrollbar which can be used in this case (I believe browsers automatically switch to this if the background is sufficiently dark, but it isn't 100% foolproof). Also it gives the bar a subtle glow (or shadow) as a just-about-good-enough fail-safe.

If possible, of course, stick to browser-native components for this sort of thing. They will ensure each user gets a natural experience for their platform (I've certainly seen a lot of websites try to replicate momentum scrolling and elastic scrolling with atrocious end results). Mac users won't thank you for forcing visible scrollbars where they wouldn't expect them, and Windows users won't thank you for hiding scrollbars where they would expect them.

Generally, scroll bars should not be shown since the overwhelming majority of the users know that the pages can be scrolled (1, 2) and, thus such a component can be omitted.

The scroll bar should be visible when it's not obvious that the content contained within them can be scrolled (so the user can understand that it can be scrolled) or the content is actually being scrolled (so the user can see the relative location of the current viewport).

There are exceptions, of course, e.g., the scroll bars that are shown due to some generic design guideline widely applied in a web app.