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:
Yes there should.
Visible scroll bars are an affordance "this page is scrollable"
Without visual hints such as this the functionality might be missed.
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.
As a mouse user, I abhor scrollable content that doesn't give me a view of and access to scroll bars.
The scroll bar is a control. It allows me to quickly navigate large pages no amount of finger-scrolling, scroll-wheeling, etc. can compare with. It also gives me more precision for most pages than my scroll-wheel.
The scroll bar gives me information. It allows me to quickly determine how long it will take to read the content on the page (presuming a decent scroll bar whose handle: gutter ratio is equal to the screen: page ratio) and tells me how far through the page I've gotten. It also gives me an index to determine where I'm at on the page if I want to quickly scroll to the top and back down.
The scroll bar takes up an insignificant amount of space. Right now, my screen is at 1920 x 1080 = 2.1 Mpx. The Firefox window with this page in it is at 1125 x 905 = 1.0 Mpx. The scrollbar is 16 x 816, taking up 13 Kpx total, or 1.3% of my screen. My monitor is pretty close to me because I use it for gaming, so I tend to keep my window narrower than the monitor anyways, so the scrollbar is effectively taking up no space at all.
There are occasions when I don't even know the content is scrollable, though I tend to try scrolling with the wheel without even checking the bar, so I doubt this is a huge issue for web pages. For desktop applications that don't typically scroll, it would be a bigger problem.
If you want a hideable scrollbar, it should appear any time I manually scroll (via mouse wheel, keyboard keys, trackpad, etc.), and any time I move my mouse towards the right edge of the screen.
Mobile devices are trickier, since the scrollbar takes up such a large amount of space, especially if it's big enough to use.
A. I typically solve the issue by switching to desktop view (I've yet to see a website whose mobile version is as good as, let alone better than, the desktop version, so I default to desktop view anyways). Then I zoom way out, scroll down, then zoom back in. It's faster and more precise than trying to scroll, scroll, scroll while zoomed in, and doesn't require a grabbable scrollbar. (It also allows me to zoom in for better views of images, diagrams, etc., which most mobile sites inexplicably refuse to allow.)
B. Firefox on Android has a non-accessible scrollbar to tell me what part of the page I'm on (for both desktop and mobile versions of a site), as does the default "Internet" browser. I use these just like I would on a desktop browser with a mouse for indexing and determining page length.
C. I also tend to only view large webpages on a proper monitor, so it's much less likely I'm on a mobile device trying to scroll through a 900-page .pdf or something. If your web-app never gets more than two or three screens long, scrolling is much less of an issue.
D. It's also worth noting that touchscreen finger-scrolling is typically both faster and more precise than using the mouse wheel, so a page has to be much larger before it's hard to navigate quickly.
Conclusion
For mouse (or trackpad or trackball) setups, I think the scrollbar should always be visible and grabbable. As a minimum, it should appear when scrolling or when moving the mouse near the scrollbar.
For mobile touchscreen setups, I think the scrollbar should always be visible when scrolling, but doesn't need to be grabbable, and should probably hide when not scrolling to reduce wasted space.
I haven't messed with tablet / iPad or larger touchscreens, so I'm not sure how I feel about those.
Of course, having the option to change visual styles (either through temporary cookies or through stored user settings, depending on whether your user is a guest or has an account) is the best bet, but you should default to something functional.
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:
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.
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.
The removal of scroll bars in my view is another example of the idiotic and shallow ideology of putting style over functionality. This is back to front to how it should be and is indicative of the dumbing down of society to me. Scroll bars serve an important functional purpose that other alternative methods cannot always replicate. I think the change is partly based on the notion that people use touch screens so it is therefore not needed, but many people still do not. Many alternative methods require extra concentration and finesse to manipulate which is a drain of energy I'd rather spend on doing work, rather than fighting with a bad user interface. Traditional scrolling methods usually go together with keyboard scrolling by pressing the arrow down key, which I find much easier than other methods that require more concentration, but with scroll bars being removed, keyboard arrow scrolling also sometimes disappears with it which should be a BIG no-no! An example is The big F social network has caused irritation constantly with it's "dynamic' scrolling style whilst scrolling up through msg history, and where you don't know whereabouts you are in the conversation while scrolling up, but then you scroll up past a certain point and suddenly an extra load of conversation history is loaded and you end up jumping far ahead of where you wanted to be.
I think it's also partly ignorance, and partly a desire to save resources and bandwidth on the servers to save companies money at the expense of user experience. It's also about dumbing things down for idiots to make things "easier" to use for very basic commands, at the expense of making things more troublesome for anyone who is not dumbed down and might want to do something ever so slightly out of the ordinary. I hope blockchain heralds the end of this era of sacrificing user experience to save money, and we can have systems that work quickly and are hassle-free for both basic and advanced users.
For example, wouldn't it be great if software like skype and F messenger let you instantly scroll to the very beginning of your msg history instead of waiting forever for section after section to load?! I've always suspected that is to save resources of loading the whole lot at once. However, if someone with a bit of intelligence and nuanced thinking were designing this,(more common in blockchain circles than corporations I hope), we could all have our cake and eat it. We can save resources (which is still not a trivial thing even in the blockchain), and get the info we want instantly without having to put up with this hideous page by page loading system.
Simply layout the framework of the whole timeline history on a scroll bar along with dates that pop up as you scroll. As soon as you let go on the mouse button or strop scrolling, that particular section can load. If you want to go right back to the beginning, scroll right to the top and only the first page needs to load. If you do need everything to load straight away though, to search a keyword for example, then just provide a simple button that can be pressed if necessary to get the whole msg history or history of whatever it is you were scrolling through.
If someone signals specifically it is necessary for all that to load, then the blockchain should accommodate the resources. This is the difference between it and corporations on the old model, who I suspect would be reluctant to allow even those that specifically need everything to load, to be able to do so to protect their resources for their filthy profit motive and screw the user. This is why we need blockchain, and preferably the open version.
As a mixed point of view...
Horizontal scroll bars are usually a bad thing. It may mean you've optimised for the screen width of a PC monitor, which doesn't translate well to mobile devices. When scrolling down, reading the entire page needs lots of left-right scrolls each screen of content. And conversely those sites will have wasted space on larger screens. (Older readers, remember websites saying "Best viewed at 1024x768"? Yeah, those.) We shouldn't have to put up with that in 2019 -this isn't the 1990s and we're not still using Netscape Navigator. Just don't go there.
Vertical scroll bars on the other hand are fine. We're intuitively used to scrolling down something - think of how you'd read a paper newspaper, for example. The whole page is easily visible with just up/down scrolls.
There's a school of thought that more than 2 or 3 screen fulls of content is too much though. After that it gets hard to find stuff. So whilst scroll bars work, don't let it lead you to unlimited length pages!
Yes, scrollbars should be visible, if for no other reason than for the sake of accessibility.
There are many instances where hiding a scroll bar makes your site/program anywhere between frustrating and borderline unusable:
Visible scroll bars are an easy way to avoid all of these problems. If your colleague's primary argument is that other sites are doing it, then don't even listen to him. Peer pressure is not a valid argument unless accompanied by a significant, meaningful reason why doing it is a good idea. That sort of thinking is how the <blink> tag became popular.
Also for the sake of accessibility, don't implement your own scrollbars. Use the ones provided by the system. Assistive technology can't always identify homemade scrollbars and operate them as such.
A scroll bar is extremely useful
You have no idea how many times I was pissed and lost because some crappy designer thought that deleting the scroll bar is a good idea.
To add to MichaelS’ answer,
On tablets and iPads, a non grabable scrollbar, that hides when not scrolling, is preferable. As he said, scrolling on touch devices is much more precise, and visible, grabbable, scroll bars are clunky and annoying. However, depending on the page length, a back to top button would be welcome.
Also, whilst writing this on StackExchange using a 12.9 inch iPad pro, I noticed that adding a decent (~1cm) amount of padding, in a sligthly different tone, is helpful as it allows scrolling without accidentally opening links.
An interesting question, my 2c coming from a developer but UX lead and also having designed interfaces with several internal scrollable areas.
A few points:
overflow: auto for example). In this case it can be easier to put a disabled scrollbar to indicate that this is a scrollable area, but the content isn't yet large enough to enable this behaviour.Is the designer talking about replacing scrollbars with a floating scroll down/up button? I think it's reasonable because that's a mobile-first approach and I've seen it being used successfully in certain contexts, but those buttons can't replace scrollbars in a grid.
