I'm not a mouse user so this issue caught me completely off guard!
Hiding relevant information from the user is a bad idea. The computer is a tool that the user employs to accomplish a task. Do not hide tools from people who need to use the tools.
A computer is a tool. It's not a design statement. It is not a canvas on which you paint. It is a toolbox full of tools a user needs to do work. Treat it as such, please.
The funny thing is, if scroll bars never existed and someone tried to add them they would be considered terrible UI.
You need to hit a tiny target with your mouse, that gets smaller and smaller in proportion to the size of the document. Missing the scroll bar, and hitting the gutter moves you to a random page with no simple way to get back.
On small documents a small mouse movement scrolls by a small amount, but on a large document a small mouse movement can scroll way too fast.
On some systems clicking the gutter is "page down". On others it is "move to this relative point in the document".
With a mouse wheel or track pad the scroll speed is consistent no matter the size of the document, and the user can scroll faster or slower very easily. And you have a huge target - the entire document. There is no chance of paging when you mean to scroll. Scrollbars are obsolete.
On Windows, and in every Linux GUI framework I can think of, clicking anywhere above or below the scroll thumb scrolls exactly one screen page up or down, for the very reason you've described. To navigate to an arbitrary spot, you're supposed to drag the thumb.
I love my scrollbars, and I want them always visible. I don't use the mouse often, and I certainly don't want to have to use the mouse just to see context.
Chrome implemented even worse nasties on GNU/Linux with scrollbars though, including forcing a snapback to original position if you drag the scrollbar but happen to move the mouse a few pixels too far left or right of the scrollbar [1]. Apparently that's how Microsoft Windows users do things. So now we have to as well.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=377191
The secondary job of the scrollbar is to tell you where you are in relation to the content, and how much of it there is, relative to what you see on your screen. Both of these roles are best fulfilled when the indicator is persistently visible.
You could make scrollbars transparent to clicks and they'd do 90% of their job already. The ability to click on them to quickly jump to a desired location is a useful bonus, even if not frequently used these days. What matters is that they're visible.
Do you have evidence for this, even if it's anecdotal? To be honest a statement like that sounds like a hypothesis and a reasonable hypothesis, but I am not joking when I say when we did user testing, it was absolutely never the case that someone actually didn't scroll because they didn't see a scroll bar. Now we didn't test specifically for that but I'd be surprised if a controlled experiment testing that hypothesis concluded that people will actually just never bother to scroll unless they explicitly see a scrollbar.
Scrolling is actually a very natural thing that people do without the need to visibly see a scrollbar. Using a dedicated scroll button or gesture is a very cheap and consequence free action to perform. I'd be very surprised if you have data that contradicts this and indicates that an actual human being would simply not scroll because the only visual cue/indicator that people use is a scrollbar, rather than the multitude of context specific information available to indicate whether more content is available.
- Almost every discussion on Apple and scrollbars I see on-line has someone telling a story of how they didn't realize some app was scrollable, because its visual grid happened to align perfectly with viewport size of their iPhone/iPad;
- I got caught myself by this a few times on PC, where the design of the page looked complete, scollbars were hidden, and I didn't realize I could scroll down;
- I've been the person to tell some confused non-technical people that they could scroll down to see more, because the layout of a webpage did not make this obvious, and without a scrollbar visible, they were just puzzled why there's so little information on the screen.
Plural of anecdote is not data, so I'm open to the possibility I may have just had peculiar luck, but I think it's fair to assign a low prior to that.
> that an actual human being would simply not scroll because the only visual cue/indicator that people use is a scrollbar, rather than the multitude of context specific information available to indicate whether more content is available
What these cases had in common was that there was insufficient context-specific information available to make it apparent the content is scrollable (and - anecdotally, again - in my experience, non-tech-savvy people don't have the nervous tick of just randomly scrolling on the wheel, to check if it does something). Sometimes, the only such contextual information was the feeling you got after reading everything on the page, that something is missing. But if your users have to reach that point to figure out they can try scrolling, the UI failed at its job, and wasted them a minute of their lives.
It is faster than scrolling with the wheel
But when a site tries infinite scroll, it is often broken
Or use the scrollbar to jump to the top, you are forcing me to do extra things
Yes I am a vocal opponent of hidden UI elements. Shame on me, I guess.
If I were the innocent target of a firing squad, I would be a vocal opponent of the actions being taken against me there, too. "It's just a vocal minority. Fire."
Being a vocal minority doesn't make me wrong. But it probably means I have thought about the problem space more than those who are not. At that point you put the A/B testing aside and you talk to the people and listen to them, and see if they are informed or if they are crackpots.
If you aren't scrolling, then the scrollbar provides little information in proportion to the amount of space it consumes. If you are scrolling, then the scrollbar is very important and it gets displayed. If you want to know where in a document you are, our experience is that users tend to already have a good idea of where in a document they are based on multiple cues including the fact that they are likely the ones who positioned themselves to that point in the document already. In the very rare moments where they need that cue, they can move their mouse (scrollbar appears when the mouse moves).
As screens are a finite resource, by minimizing information that isn't necessary towards accomplishing a goal, we can maximize the information that is.
I would genuinely love to see a UI where valuable information is unavailable without scrolling because of the presence of a scroll bar. I am not being sarcastic or snarky. I would love to see that UI
[1] is an image comparing a list of trades with and without the scrollbar. The scrollbar literally hides an entire column's worth of data.
[2] is an image of a typical trader's layout so you can get a sense of the context and how the size of a scrollbar can add up.
As you can see, given that the scrollbar consumes around 20% of the width of a trade list, by eliminating it a user can can add one additional trade window for every 5 that are open. That's literally money in their pocket and our pocket.
Some additional info is that the Windows 10 titlebar is too tall and those minimize/maximize buttons are enormous, so we redesigned a new title bar that is not only slimmer, but allows us to make better use of it while still retaining the functionality. I am not going to declare that we are the masters of UX and everything we decide is absolutely correct, but we do really care about these issues because they make a measurable impact on our performance.
That said, almost all of those windows in the "typical usage" image have space enough to display everything fully AND show a scrollbar. And I would imagine a trader would shrink those windows enough to allow another window or two in the row, and be very happy without a scrollbar.
On another topic, I have an AutoHotKey script that, with some modification, may be of extreme use to those people. Felt appropriate to inform you of it.
https://gist.github.com/naikrovek/b13a77d169de0e192bcf48fec0...
If you don't know AHK then it's difficult to pull apart what it's doing. AHK syntax is weird, toe anyway.
People's preferences about usability can change over the course of familiarizing themselves with your software, things that are friendly when they first use the software may end up being useless as they become more familiar with it. We obviously don't want to make our software hostile to new users, but for our purpose we want to ensure that people who are more familiar with our software have the optimal experience.
The scrollbar doesn't just let you know that you can scroll, it shows you the size of the content in relation to the size of your viewing window, and it shows you the location of the viewing window within the overall content, and it does this at a glance. A scrollbar is an extremely efficient use of screen space.
Don't hide things from the user that provide the user with information.
The reason we hide the scrollbars is because scrollbars are not the one and only consideration that we make when designing a page, information density also matters and so we have to weigh these options together and conduct user testing to see what the impact of various design decisions are. Certainly there is a vocal minority of people who are dead set that scrollbars must always be visible, and we can respect their choice, but we also have to optimize our software for the majority of our users who would rather see more content.
The balance we went with was if you want to see the scrollbar, you need to perform an action that engages it, which is moving your mouse over the scrollable area, or performing a scroll operation. We have other things too that we have to consider, like until the mouse approaches the scrollbar it appears very thin and when the mouse is within a certain distance it expands to allow it to moved.
Will every single user like this approach? No of course not. But based on our user testing, it optimized for metrics that we care about.
The problem with revealing scrollbars it that they then obscure whatever was shown there before. (Or reflow the page, dear god). If you use that space, well you can't see it when you're scrolling; and if you don't use that space why not show the scrollbar the whole time?
We already hide 99.9999% of things that provide the user with information. Thank god, because the real maxim should be don't overload the user with information.
We try to show only the things that show the most useful information at the times it's needed, and hide them the rest of the time.
Scroll bars used to be necessary primarily for scrolling. Once people switched to scroll wheels and trackpad gliding this the primary use case disappeared.
Knowing where in the document you are isn't usually that useful. You started at the top and already know how much you've read. For the infrequent moments where you really do need to know, just jiggle the scroll and you can see it instantly.
It's a very elegant solution. It really does work.
> We try to show only the things that show the most useful information at the times it's needed, and hide them the rest of the time.
Surely there's a middle ground between showing a user everything and showing a user practically nothing and then trying to guess what they might need.
Software that tries to figure out what I want instead of just letting me just pick what I want is, frankly, annoying. How does software handle a situation where an option I might want is hidden because I have a use case that the developers didn't anticipate?
> Knowing where in the document you are isn't usually that useful.
Disagree. If I'm reading a document on the Internet, I probably don't know how long it is before I start reading it (and those ridiculous tags that say an article is XX minutes long are almost always so wrong that they're useless for me). If I'm scrolling with my scroll wheel, I'm probably not paying attention to the scroll bar. If I've been reading said document for fifteen minutes and I want to know approximately how far into the document I've read (and if I have any hope of finishing it up in the time before I have to do something else) the position of the box in the scroll bar is a great way for me estimate that at a glance. Jiggling the page or moving the mouse all the way to the side or doing some other incantation to make it appear completely breaks my flow reading the document and can make me easily lose my place (especially if I'm in the middle of a paragraph). A quick glance at the scroll bar also breaks the flow, but not quite as badly, and it's a lot easier to resume where I left off.
Yes, that's what software already does. And a scroll bar that appears but only when you jiggle the scroll is that middle ground.
> Software that tries to figure out what I want instead of just letting me just pick what I want is, frankly, annoying.
That's literally all software though.
Otherwise every screen would be covered in every possible option, and would be unusable.
But in conjunction, they absolutely do. You can't look at anything in isolation.
Which is why, in UX, you have to be rigorous in removing everything that isn't absolutely necessary.
It's physically tiring to scroll through a long document with multiple finger drags on the surface of the mouse. And knowing how much there is left to look at is clearly useful.
Worse, the default MacOS micro-scroll bars are too narrow even when they're visible. I assume this is to encourage track pad and finger-drag use - but that's not a user-centric decision.
Mice with scroll wheels existed then, and were common, at least in Alaska, where I was at the time.
It's only in the last few years of computers with mouse-driven GUIs that suddenly the scrollbar is intolerable for UX people. Suddenly users are saying that a scrollbar is unacceptable? Really? Or are the survey questions worded to produce the results desired by the designer? The latter seems much more likely. (It's hard NOT to bias survey questions, if you don't know how easy it is to bias them accidentally.)
I can't believe that is the honest truth of the situation. I worked with my fair share of excellent designers, and I can't recall any of them ever groaning about any browser chrome, like a scroll bar, ever, with the notable exception of the viewable page space consumed by browser plugins which each added their own toolbar to the browser UI itself. What a horrid period of time that was...
If it is such an urgent need, where was that need 20 years ago? The web hasn't changed THAT MUCH. Scroll bars were an accepted thing; unquestioned. But today they're too intrusive? Or they consume too much space? What the?
I understand that the science of interactivity has matured, so I'm willing to admit that we know more about how users behave than we did 20 years ago. I still don't believe that any UI would ever benefit from hidden scroll bars over always visible scroll bars.
But how do I know I need to start scrolling to see the scrollbar, when I can't see the scrollbar so I know there is anything to scroll to?
This is especially useful if you made your modern front page super fancy so that the above-the-fold space looks like a tidy complete package. Or if you have a sub-panel containing a list of something.
I make web sites for students. I've frequently found that, if it's necessary to have a scrollable list of something, I need to dynamically change the height of stuff so that the list starts with some list item partially peeking out over the fold, otherwise half the users with hidden scrollbars won't know to scroll and find more stuff.
I suppose this has made "above the fold" more valuable, or perhaps mobile devices show so little content that everyone has to scroll ...
I just realized that the "mobile-first" web has made using a computer with large screens a super-power. I have 17m pixels (and many more if I wasn't using Retina-like resolutions to get crisper text) - others I work with are stuck at barely over a million pixels.
Seriously, that's another thing I hate about infiniscroll: if I come to a giant list where I know I've looked at the top 10% of, it makes it impossible to jump down approximately 10%, or otherwise to a region I know I haven't explored.
Edit: And, of course, if you do want to go n% down, there's no choice but to page down, wait, page down, wait, page down ...
However, that one I blame the browsers for. I distinctly remember the back button working differently, where it would reliably take you to the exact state of the previous page, just as if you had opened the current link a new tab and closed it, but it changed at some point, and most sites do something that destroys the state when you back into them as well.
What industry are you in where you can ignore 10% of the user base?
For our application we have many tables of data that are narrow in size, maybe two or three columns, and having a scrollbar constantly displayed takes up valuable screen real estate that could be used to display more tables.
It's also a fallacy to think that because we optimize our application for 90% of users, that we end up losing 10% of them. People are not static automatons that make binary decisions about using your product strictly on the basis of how scrollbars function. People are fairly flexible and can adapt, get used to new things, and balance many different factors against one another when making choices.
This goes against the rule of thumb where if 5% of attendees are vegetarian you serve vegetarian and omnivores will adjust to it, while if you served the omnivore option the vegetarians would likely go hungry (more likely go find something else nearby if possible).
I've never heard this before. 5% sounds incredibly low, I would think it would need to be 25% before omnivores would be okay with it.
If somewhere isn't serving meat, I don't want to be served there.
That is a very important principle in UI design and we certainly adhere to it and take it into account, but this has nothing to do with that. We're talking about scrollbars here, and unfortunately the people who prefer to always see a scrollbar are not going to ditch your product strictly on that one single criteria.
[1] https://medium.com/incerto/the-most-intolerant-wins-the-dict...
Note also the distinction between "prefers scrollbar" and "touched the scrollbar at all". At most 10% of users prefer scroll bar; the parent only claimed that 10% of users touched the scroll bar at all.
Not "every" time. I work in healthcare. I don't have the luxury of leaving ANYONE out.
Healthcare is certainly a "fun" space, but catering to scrollbar purists isn't usually part of the gig. :)
It's not clear to me that those two things are neatly separated. I have a ~25th percentile visual memory - my brain does very poorly having to process and retain images, but text is very easy. I can, eventually, navigate visually, but at a much higher energy cost than the average. Is my affinity for text a preference or an accessibility concern?
Try telling the sales people that their bonus checks will be cut 10% because you can't be bothered to build for every customer.
This is a very underappreciated point.
Those scrollwheels you described are definitely part of the problem too, though. I had the pleasure of using one like that and a few minutes were enough to generate the urge to throw it in the bin. It's already hard enough to find a decent mouse without worrying about the scrollwheel.
It appears, at least from all the evidence I can gather, that trackballs without a scroll option is the exception.
https://www.newegg.ca/p/pl?d=trackball&Order=1
https://www.bestbuy.com/site/searchpage.jsp?_dyncharset=UTF-...
I wonder whether this was tested with the average modern website or a well-designed UI. Or on a desktop, which usually does not come with a touchpad.
The main reason I rarely drag the scrollbar is that it's become a total pain: they're generally hard to hit with the mouse because they tend to get narrower every year(Fitts' law anyone?), they auto-hide or even when not hidden have such a low contrast that I have a hard time making out the edges, or they're simply in a half-broken state thanks to convoluted web design. All those things basically go against the whole purpose of scrollbars.
Please don't mess with the scrollbar and scrolling in general. It provides no benefit and breaks UX in ways nobody can predict. With so many operating systems, user interfaces and browser plugins it's often trivial to make many websites near unusable because they were built by people who think they know better than some boring standard.
After we give this to a bunch of our users, for our specific business, we split users up according to a bunch of criteria including people who performed the task the fastest in terms of time, performed it using the fewest actions, in terms of precision, sometimes eye tracking is important, and a host of things.
Now the next thing I will admit people will find distasteful but for our industry it matters a lot... we then design the software according to how the "optimal" users accomplished the task. Sometimes it's possible most users accomplished the task one way, but the optimal users accomplished it another way... in many cases we will then design our software for the optimal users even if they are a minority.
For this case we were predominantly interested in information density and the scrollbar was taking up about 10% of the width of a table (on 96 DPI the scrollbar is I think around 15px and the window as a whole is about 150px). The optimal users, and the vast majority of users overall tasked to find data in a table as well as the ones who did best in terms of keeping track of changing numbers, don't move the mouse over a scrollbar and use it directly. I don't have all the details off the top of my head although I could ask the UX researcher about it if there's a lot of interest, but I seem to recall that the small number of users who did drag the scrollbar are "clumsier" and slower.
Since I work in quantitative finance, it's better for our business to design our software to appeal to the so called optimal user and try to find ways to get the majority of our users to adopt more optimal usage patterns. That means if we can get our users to prefer using more precise ways of using our software through familiarity, training, or other means, we'd rather get them to do that instead of trying to design our software to accommodate usage patterns that they are currently comfortable with, but that we measure as being suboptimal.
None of this is perfect, we don't always get it right, but we do care about it and put quite a lot of effort into it and have seen a lot of substantive improvements in our users that translate to substantial earnings for our trading firm.
How did you determine this difference? I use a mouse with my laptop, because work only gives us laptops.
No it doesn't - and why would it? Any reasonable modern mouse has a scroll-wheel or touch area so you don't need to click the scrollbar.
Not only does it not show the scroll bar by default, but (not sure if this is a Chrome or Mac issue), when it does show up during a scroll operation, you have to have great reflexes to grab it with a click if you want to.
By the way, vSphere is part of the problem. It's one of those web applications that try very hard to look like a desktop application. It doesn't use the standard HTML behavior of building a page that scrolls. It clips everything at the borders of the screen. Ironically that reduced functionality probably cost them a lot of developer time.
At least on Catalina, the default (System Preferences > General) is still set to “automatically based on mouse or trackpad”
I'm curious about what tools you use to manage mouseless workflow?
For the browser I use the Vimium plugin to navigate and only need to use the mouse in the case the site is badly made and e.g. a button is not a button but some styled div element with an event listener attached.
Most of the other daily needs like functions of the tiling window manager (AwesomeWM), Editors (IDEA, VS Code, emacs), terminals, etc. come out of the box with good keyboard control support.
In addition to that, most mice have a scroll wheel.
I don't think I understand the issue you're referring to.
The Windows and macOS apps I tried zoomed or scrolled vertically with Ctrl.
On some mice they do, and it's a really useful feature. But it's fairly niche and mostly on the more expensive mice. I would feel pretty confident betting that over 99% of Windows users don't have a tiltable scroll wheel.
In web browsers this is referred to as "auto scrolling" and it works automatically on Windows but on Linux I have to install a chrome extension to get that feature in Chrome at least. It works in Firefox.
Not sure if it works on my Mac because I gave up trying to use third-party peripherals on Macs since they never work well.
I certainly cannot say the same for scrolling with a trackpad. If I happen to brush two fingers on the thing, things start scrolling when I don't want them to.