I don't think that efforts to hide UI elements that aren't in use is going to prove to be a good idea when we look back at today from the future.
Here's a good rule, in my mind: Don't hide UI elements from the user. End of rule. I do not care if it looks better without whatever UI element. The toolbox in my garage would look better if I could only see the tools I needed at the time I need them, and I would return that toolbox (or never buy it in the first place) because it is constantly lying to me about the state of the toolbox, which is absolutely insulting position for a toolbox designer to adopt.
We're not going to solve it. It requires complete scrub of how we think about building excellent products with deep understanding of humans (not users). Furthermore, needs overhaul on multiple fronts since great design doesn't sell apparently according to most rebuttals. Just look at Apple.com and see how loud it all is. Developers love Stripe design, but it is overrated - full of animations, bright colors, sexy transitions and for some reason they love diagonal lines. We need to revive some people like Paul Rand and Josef Muller-Brockmann, may be get Stankowski and a few others to do marketing. We don't celebrate great design anymore. If it wasn't for Elliot Noyes, no one would ever think of IBM in the same way.
We've gotten so worse, it is appalling and we should all be ashamed.
A lot has changed since then. GUIs are standard, touch-based 'appliances' like the iPad are the norm, and there are fewer people for whom computing is totally new to (a big issue back in the 80s and 90s that drove efforts of approachability you saw in the Macintosh and Windows 95). Despite this, I think there's still a timeless usability lesson in that early approach. Gestures, it could be argued, are just another form of the IBM keyboard shortcut.
At some point, they decided to toss all that out the window for aesthetics and shininess.
I feel like this could have been done much better by making theming a first-class citizen. Sure, put a pretty theme on by default, but let the user make every button look like a football and have the text blue-on-purpole if they want. If anything, this would further encourage developers to stick to established conventions and style guides, because they'd need to make sure it still looks and works fine when the user is running a theme that makes everything look like a particularly ugly Enlightenment theme.
This was very much the case for Classic Windows themes. Everything could have been set to any colour, font, style. Dare I say, it was more customisable for end users than any Linux UI today.
Including current UX people. They are young enough, digital-native enough to take things for granted ...
... whereas people originally building the interfaces from the "golden age" mentioned upthread could not assume anything, having to build, research, and test everything from scratch.-
Yes and no. Aesthetics are always going to be critical to the consumer experience of technology; the problem is that there are difference schools of aesthetics, and presently the high-status UX school is a minimalist one that values showing as little information as possible in order to look 'easy to understand' in screenshots and at-a-glance tours.
If Windows 2000 wasn't "aesthetic" then we wouldn't have Vaporwave, after all; look how that late-90s look is glorified now. There's no shortage of people (myself included) that will still defend it as being a pinnacle of sorts, though I'd point at NeXT as being the real high water mark.
I'd call that late 90s style Modern Desktopist, where the metaphor of being a 'desk' we may have seen in some 80s Classical Desktopist has been left behind and replaced with functional, well-designed UI widgets building on years of refinement. There was a reaction to this modernism, and it came first in the form of Late 2000s Skeuomorphist UI as on iOS and in many creative applications on desktops preceding it: the 90s style being seen as too corporate, too 'suit', we ended up with skinnable apps, and apps that mimic the real world (I'm thinking of Propellerhead Reason here as the king of these). What skeuomorphism added in terms of enjoyment was lost in terms of losing all of the expected conventions of normal desktop applications: drag-n-drop, multiple select, keyboard shortcut consistency, etc.
Skeuomorphism was rejected in favour of what some call "flat" or "material" design, first in the Microsoft Metro form emulating highway signs, and then in the Google form emulating... nothing. Developer laziness, perhaps? I call this Digital Brutalism, it's at once "function over form" but at the same time missing a great deal of the "function" that the previous era had. It's fundamentally a skeuomorphic UI evolved to lose the skin and to hide most of the controls.
We're honestly all just waiting for someone to come out with a drastically more efficient UI paradigm. There's still room to make a real difference with people who use a desktop from day to day....
Isn't vaporwave a self-consciously nostalgic aesthetic though? It's glorified because it captures a kind of ideal of human-computer interaction that wasn't recognized as such at the time.
Personally I don't mind material design (which is not really the same as flat design). I'd just like to see a little less padding and fewer hidden UI elements.
Skeuomorphs, by their technical definition, are a core part of art and design that goes far deeper than just "photorealistic icons and extraneous textured backgrounds." The modern iOS calendar and phone dialer are natural skeuomorphs, since they're carrying forward a familiar mode of interaction. There isn't any real reason why a calendar has to be a grid of dates, but it certainly is a lot easier to think about it that way due to generations of familiarity.
- popped-out button: available to press
- popped-out but greyed out - usable, but disabled in the current context
- popped-in - currently has the mouse button depressed on it, but will not fire until you let go. in case of the taskbar, the current selected application (radio button)
- flat/not 3D - not an interactive element, likely just a label
Far beyond being skeumorphic in appearance, they also had a unique visual language that communicated the state of a control. The modern flat UI interfaces entirely gave up on this, and created a simplified experience that also glosses over many UX affordances that people would subconsciously pick up on if present.
The supposition that modern UIs are based on is that they should be drop dead simple for a brand new user to pick up and use without training, but at the expense of flexibility and utility. You can't overwhelm them with options, even under menus, and you need to present large buttons for them to immediately identify and mash. Basically, Fischer-Price toys. However, you're only briefly a new user. You may be using a tool every day for months or years, so the obvious design philosophy should be focusing on efficiency (i.e. keyboard control, snappy response, advanced features) for the long term user.
Spend almost a decade building enterprise software and heard EXACTLY that a stressful number of times. On one hand, I think that maybe my customers (mostly Fortune 500) couldn't hire anyone with at least 90 IQ, because, shit, it had to be simple! And also, probably, those companies provided the worse customer service ever, since they wanted to have people operating their software with zero training.
Now, besides making the interface dumb, less productive, we had the problem that people were much more concerned with making things easier to use (and pretty) and not productive.
(and don't you think that they'd ever talk to the actual user...)
My conclusion is that these inefficient designs aimed purely at someone who is seeing the app for the first time are a result of two things:
1. Designers / UX "experts" generally have no clue what they're doing. I don't know why, but every single designer I've met has only designed trivial software. I've never met anyone who's designed complex systems, like MS Word, 3DS Max, etc, stuff that people use for hours every day to perform complex work. At the same time, half the developers I know have worked on very complex software at some point in their careers, so it's not like complex software does not get built at all. Does anyone know a single UI designer who has designed an app of that level of complexity? It's really strange that they literally don't seem to exist. So they've never worked on an app that users use extensively, daily, for years, to perform complex tasks, and their whole mindset is about "how will someone seeing it for the first time use it". So when you do bring UI experts on such an app, they have no clue what they're doing, and users complain about their design decisions. And people who get hired to design things are people who've designed e-commerce web sites and mobile apps in the past, because those seem to be the only people that exist.
2. If it's an app that will be demoed in person or demos will be provided as a part of marketing, anyone involved with sales in any way will push hard for this because it demos well. They're not demoing to the guy who's been using the app for 4 hours a day for 5 years, they're demoing to the guy who is going to be using the app, or not even to that guy, but to his boss who isn't even going to be using it. I regularly get requests like "can we make this automatic so the user can do it with 1 click" when it's an action the user will very rarely perform so it doesn't matter whether it takes 4 or 2 seconds, and it provides more flexibility to the user to do it in 2 clicks instead of the app making an assumption that joins 2 actions into one. The reason? They will do it in the demo and they can say "look you can do this with 1 click" even though from the perspective of actually using the application it's not helpful.
I am almost ashamed that I worked on an app where you upload stuff by having an "Upload" button on the main page, that you press, and then it guides you through the process of selecting where to upload and what to upload, and then it uploads. Think about how inefficient and cumbersome this is. I guess the point is that if you've never seen the app before, and want to upload, you see "UPLOAD" staring at you, so you press it and it guides you through the rest, there is basically no way to get confused. In fact every action in this app works through a "wizard" of some kind, there is no concept of freely navigating and contextually performing actions on objects as you navigate. If you want to perform an action, you start by pressing a button with the name of that action, then get guided through the rest over multiple pages. It's the literal opposite of how I would build an app if I was building it for myself.
Thats not a tereible thing to do, but the UI UX group has too many loud characters that are hell bent on applying this minimalist beauty to everything.
Casepoint is the recent update to Youtube android app. Earlier, when i would search something, on the top right corner was a small button that allowed me to filter the results. Now its hidden behind a menu. Why? God knows. The worst part is, its not like the menu has 10 items and the filter icon was moved into it. The menu has just one item and its the filter.
I hated Apples shift to minimalist design.
I hate apps that think minimal design is functional.
There is a place for minimal design, and its not everywhere.
When something looks like two simple controls in a small rectangle, and you have to accidentally shuffle your trackpad over it to figure out that it will move to reveal a dozen more controls, that is a failure of design.
Another bad one is Mac's "Do not disturb" option. Good luck finding that.
It would of course be much better to have the previous tweet partially on-screen, possibly under a small gradient.
This is the actual start of the thread:
That kind of thinking is why we can't have nice things.
I want apps that do things for me, not apps are crippled to satisfy some fashionable UX fad-dogma.
Worse is that apparently Medium requires the stupid, and often irrelevant pictures. Apparently some numbskull decided there would be more "engagement" if an article included pictures. So pictures there shall be, regardless of whether they add to the content or not.
They are the photos of procrustes.
What is even worse is that they've started dedicating yet another giant pic for each item/link.
It is a theft of one's time. Normally when
I see such design I would leave the site immediately but unfortunately I must actually read some.
I get to sit in many user testing sessions and while well-intentioned, the environment of observing someone who has never seen the system before do a few very basic tasks naturally selects for a design that optimizes for that use case. But in real life use, nobody gets to have less than an hour of experience with the system for more than one hour of their life. But now every subsequent hour spent using the system is hobbled by the limitations of that first hour.
Good thing for me that I mostly just still use emacs, mutt and zsh, or I'd go crazy.
This infantilization of users can be seen in industries far removed from software even. Look at sailboats from the 70s and 80s, mostly designed for usability at sea. Visit a boat show today and new boats are optimized for the initial 20 minutes someone spends touring them at the show, making them mostly terrible for life at sea.
I also agree on the google icons. After years I still get google photos and google drive confused, not to mention youtube and strava (both red/orange-ish icons). I think you're fine, it's design trends that are getting ridiculous
A version from a year+ or so ago used nice, colorful icons  in the sidebar to access the main functions. The late(st)? They made the icons grayscale... on a gray-ish background . It is really giving me a bad user experience, since I have to stop and read the text every time, instead using the RGB-shorthand (aka color) that is way faster to my brain.
This could have been fixed with a simple option in the configuration dialog, but TMK it is not.
I guess the flat icons are soon to follow, too.
It really shows how batshit insane UI/UX zeitgeist has become, when the only way to have usable user interface is to use accessibility features.
Just wanted to point out that neither a floppy disk nor a Manila folder have been in public use for almost two decades. Still they survive as these icons and I hope they’ll continue on for the next 500 years.
Manila folders are still sold at office supply stores, so I'm pretty sure that they're still in widespread use.
This comment has completely broken my brain. That's exactly what a toolbox with drawers does, hides tools. Until you, the user, pull a drawer out and select the tool you need. Because you probably put the tools in their place you also have a high likelihood of knowing where they are. Maybe that's the paradigm? Show everything and let the user hide?
The opposite of hiding tools in a toolbox is littering your workspace with tools that you can see, but you soon run out of real estate with any decent amount of tools.
When I wrote this, I was thinking of my time in a maker space where all tools belonged on a wall in a specific spot. You could see, at a glance, if the tool you needed was there, and you could see at a glance if any tools were gone at the end of the day.
I would not want to keep track of tools in a common-use area without a system like this. (I've only described a portion of the entire system.)
This at-a-glance inventory system is what I meant when I said "toolbox" and there was no way for you to know that.
What designers fail to understand is the difference between complexity resulting from disorganization vs. complexity resulting from logically laid out tools on the wall - all available for selection in a moment's notice. The latter is the complexity all humans can handle. We do this everyday when shopping groceries, driving cars to navigating airports.
Look at how much information is on a single page of literally any novel! Or a complex spreadsheet. All of it easily ingested when you just take the time required to see things in the required way(s).
Litterally impossible to do without googling.
Display Stream Compression, working on Catalina, is completely, absolutely broken on Big Sur, since beta 1, through 11.2.3.
Got a 4K 144Hz panel? Or HDR? Apple could not care less.
I long for Windows 3.11/OS2 Warp style window decoration with goofy distinct colors and a menu bar in every app. These days all apps in Windows hate the menu and hides it.
I just wish there was also a "prefer full-contrast body text" mode too. I want white-on-black and black-on-white, not gray-on-gray. Most OSes have some high-contrast accessibility modes, but they're not ideal because they tend to affect all text.
I dislike modes of any sort, but day and night are modes in the real world, and the device might as well accommodate that.
I would definitely be grateful to never again hear "When is X going to introduce dark mode?" for every single app and web site. Outside of that very specific instance where I'm required to have an app in my face while maintaining night vision, I'm perfectly happy to use "day mode" with the brightness adjusted.
There's no reason dark mode should make things invisible.
It's right there, people!
The scrollbar appears if you use a scroll gesture.
It’s obvious with web pages, and with most content when you can scroll, and removal of visual noise and increasing the content area is good.
I personally use a mouse, and so I have them turned on, but generally I like Apple removing unnecessary clutter.
It’s really no big deal at all.
It’s when the control displaying the content first appears on the actual display.
If nobody else is doing it, then perhaps it is Apple specific.
They are visual noise if that information isn’t relevant to you.
If you’re proofreading a long book, they are likely to be more useful than just browsing the web.
> Hiding them leads to users often not figuring out that there's more stuff
> and scrolling will get them there.
Really? With most content it’s fairly clear from the content itself.
I first turned on my ipad, then sat for several minutes staring at a box on the screen that clearly wanted input but had no continue button. Only slowly did it dawn on me that there was a hidden scroll region that would enable it.
Overall UI design has regressed heavily since the 90s. It's clumsy, counter intuitive, un-responsive and high-latency.
The latency alone drives me bonkers. My smart tv literally takes 5 seconds between tapping the remote and feedback on the UI
The ribbon design is in your face, it takes up valuable real estate, and (to this day) I still find it hard to locate the options I'm looking for. I find it to be a HUGE step down from the functionality of menus.
When you are at the point of muscle memory, menu shortcuts are far better -- because they have keyboard shortcuts associated with them that for power users with muscle memory are 5x faster than mousing around.
It is not by accident that MS has kept those menu keyboard shortcuts even when killing their discoverability by killing the menu bar -- because their most valuable power users still press ALT-D-F-F first when encountering a new table rather than hunting around the ribbon bar.
With menus, you have to use sub and even sub-sub menus for organization, and the user has to mouse over or use the keyboard to see the sub-options. Every sub(-sub) menu looks the same, maybe with a tiny icon to help find it. With the ribbon, every top level category naturally has major sub-groupings (horizontally), within which more important / commonly-used items can use larger icons, split buttons can be used to show a default action with related actions in a drop-down, and option-groups can be presented as a dropdown or expanded to show them all at once (think "view layout" in a file explorer).
I have to admit I had a negative reaction to the ribbon initially, but especially with the thoughtful integration into Windows Explorer it's really grown on me since. I'm not sure it's appropriate to replace every use of a conventional menu bar but I think it's the best fit in a lot of places.
MS Office had accumulated thousands of features, most of which were beloved by a tiny fraction of users, and completely useless to the rest. That tiny fraction wanted instant access without having to memorize keyboard shortcuts, but no two wanted the same one.
Ribbons are about the best way I can think of to accept that premise. Aggravating at first, but you and it gradually learn what you do most often, and reach a steady state.
But better is to reject those features, put up a simple interface that captures the things you do 99% of the time, eliminates the .9% of fancy flashy stuff that some people use occasionally but everybody else is grateful to have gone, and just tells you to suck up the remaining .1% of stuff that you might actually use sometimes but can't have.
There are still days when I have to boot up LibreOffice or MS Office for some document that just absolutely positively needs something extra. Today, it's edit marks on a document, and being able to switch back and forth between the original and edited form, restoring old edits. But that's a special use case and I'm just as glad to not have to be ignoring that feature most days.
I think it was a good change. Anecdotally, I noticed a big drop in people not being able to find particular functions since it's introduction (if you exclude the spate of complaints about the shift to the ribbon itself, which fizzled out over time as people got used to it).
On the one hand it's a much more approachable and user-friendly design (especially the preview feature), on the other hand it blocks valuable screen real-estate; this is especially an issue ever since the 16:9 trend took over the mainstream laptop and monitor markets.
The issue most users had at the time (and some still do to this day) was that they felt it unnecessary and obtrusive. Personally, I welcomed the change since the old menus weren't as discoverable and obvious to me.
Since the shortcut keys stayed compatible (I think?) and the ribbons could (and still can) be hidden by default, I never really understood the bad reception of this feature by many (old-school & power-)users.
On a 9:16 or 10:16 portrait display, it would be perfect, but an element like that should probably be on the side for a newer laptop. A very quick google image search suggests that isn't a configuration option.
ToolTips also work very consistently. Hover, and a box appears, in most cases containing a full description and keyboard shortcut(s), and sometimes even helpful graphics.
I think you just don't like it because it's different to what you were used to.
I hate it when I'm in laptop mode, or on my desktop PC. My biggest problem is that their layout is unstable - it's context-dependent, size-dependent and seems to magically change with time from one use to another.
The second thing that annoys me is that the ribbon only shows a configurable subset of actions - which means I have no easy way to tell if the feature I'm looking for does not exist, or is just not assigned to ribbon.
For users like myself it was a step back as I skim read incredibly fast and have a hard time with remembering icons. I could vertically scan a drop down menu for what text I want 5X faster than finding the same option on a ribbon menu with half the items.
I was the same person who absolutely hated the vista and up start menu. I had about 4 columns on my xp start menu and could find anything I wanted very fast just skim reading it. Vista+ was horrible until I got an ssd as the search was always several seconds long.
Now I like the search on a ssd these days but until they worked the kinks out and I got an ssd it was way slower than a popout style menu.
Remember that the majority of the computer usage growth of the past 50 years was on home computers that booted to a command prompt when powered on. Certainly the earliest days, when adoption was most vulnerable and the most difficult.
Saying that users can't learn something complex or intricate is just not true, and if you look for it, you'll see that users almost always take pride in their ability to wield a complex piece of software.
I'm not saying that good design is wasted effort, mind you. I'm not saying that good UX is bad for anyone. I'm saying that a user will often (always?) opt for an option that they believe will make their lives easier, because people almost always underestimate what they are capable of.
Simplifying a UI so much that you decide to hide scrollbars is simplifying to the point that you think your users are boneheaded idiots who cannot learn and who are confused by slight movement or strange noises. It's insulting and denigrating, even if this is the outcome that UX/UI testing reveals.
Yes, many users between the late 90s, and early 2000s, were a mass of people which had never, ever used computers. They bought them for the Internet, and as their workplace adopted them, to work at home.
Many of these users grew up without televisions, calculators, you name it. Yet all new users today are essentially using a tablet or phone at age 5.
Users are not as easily confused as they were in the 90s. I mean really, Amazon's website has more complexity than most desktop apps.
That's the late 90s / early 2000s UI/UX dogma. Research-backed and sane.
Current UI/UX dogma is based on taking designer opinions and throwing them into A/B testing blender, optimizing for conversions. What comes out isn't something that delivers value to the user - it's something that streamlines their journey through the sales funnel.
It's been A/B tested and optimised to death not to empower the user, but to disempower them. The push to get the user to click on the "subscribe"/"buy now" button, or to stay engaged with the app so that you can keep pouring ads down their eyeballs, is an overriding concern.
In contrast, 90s/2000s research was all about empowering users, acknowledging psychological limitations so that you can work around them to let people work more efficiently, and making your workspace/playspace your own. Modern UI/UX is a near opposition of that.
I would agree with this statement but only outside of academia. UI/UX dogma in academia is still about proper user experience design and it's simply being taken advantage of by companies looking to cash in on users. That doesn't make the dogma flawed but I can see how that would make you say it's tainted.
What are you basing this on? Current research does not agree with this and, anecdotally, my daily experience also doesn't agree with this. People can buy things on Amazon easily because Amazon has optimized for that. Anything outside of that (account management, returns, etc.) are still not intuitive for most people.
A computer is a tool that a user employs to accomplish one or more tasks. Computers are not a design statement. Computers are tools.
In every place I've worked, a major project has been replacing a grey forms application with every screen so stuffed with information even users who sit and use the software every day are confused by it.
It is always win 2000 forms.
That's just one big exercise in burning money. The end result of these major projects is software that is significantly less efficient to use.
Information density is good. Seamlessly filtering out irrelevant things and focusing on important ones, and switching these filters on the fly, is the one thing human visual system is good at. Information density plays to our natural strengths. Meanwhile, our working memory is limited, so splitting things into multiple screens plays into our weaknesses.
When you replace an information- and functionality-rich screen with a bunch of sparse screens connected by buttons, doing everything takes longer - there's extra operations, a switch delay in the UI, and working memory delays. This scales with use - so when talking about software used every day by salaried employees, that's literally setting company dollars on fire. People do their jobs slower, doing less work, getting increasingly frustrated, wasting time they could spend on something else. It's hard to see such major projects as anything else than sabotage.
Yes, information-dense software has steeper learning curve. But that's a solved problem - people using such software at work are usually trained in using it. They get leveled-up to proficient very fast. Information-sparse software doesn't even offer the option of becoming a proficient user, because there's nothing to skill up in (except patience for loading screens).
 - or watching cat videos, or doing personal stuff, or chilling out - ways of keeping sane and improving morale, which raises overall productivity too.
WinForms can only do what they're told, and they can only look how they're designed to look. Blame the people creating the user interfaces that suck instead of the tool they chose to use to build the bad UI. It isn't the UI's fault.
The absolute best and most useful user interfaces that I have ever used were windows forms. They were designed my people who understood how their program was to be used by its users, and who understood what information a user needs at any point in the workflow.
Great tech that makes it incredibly easy for shit developers to create monsters.
Amazing at giving the masses a platform to create content-driven sites that's been abused to all hell by shitty devs to create monsters.
Needless to say, controls of dangerous machinery stay clear, loud and accessible.
Interfaces are generally more standardized than they were back then. The type and layout hierarchies are clearer. There are better patterns (and better technologies) both for orienting and getting help when you're lost. There's better feedback from the UI when there's an error or a state change. And that's not even getting into accessibility improvements.
It's definitely not better across the board, and the MacOS scrollbars are a good example of that. But, on the whole, it's a lot better than it was, and I wouldn't want to go back and unlearn all the things we've learned in the last 20 years.
Desktop, no way. Windows 2000/Office 2002 usability by beginners was head and shoulder above today's versions, even at 10x less dev effort and 100x less HD/RAM/CPU usage (yes the functionality was lesser, but the UI wasn't).
And add to that the counterfactual of 200,000 man years of development within sane UI paradigms that don't live under the pretense that every Windows PC is a touchscreen tablet, and you could have so much more!
When we entered the “an artist designed everything in Flash” era and its successor flat design we saw a big hit to discoverability (I still routinely witness people being amazed at core app functions existing because they hadn’t realized that plain black text was a button, etc.) and some specific usability hits which disproportionately affect certain users: click targets requiring very high precision, lack of or inconsistent keyboard navigation and shortcuts, contrast/color/size choices which are hard for many people to read.
iOS is interesting for the degree to which you can re-enable functionality but non default options definitely get less testing.
One big reasons was to get better scrollbars. They used to have buttons to scroll a single line/item, but the modern scrollbars do not have it anymore, very annoying. It got the buttons back in all programs, except for Firefox.
I think it might have been the Andrew system - https://www.cs.cmu.edu/~AUIS/ - but given it hasn't been touched since 1997 judging by the datestamps, I'm guessing it won't be an easy apt-get to experiment with.
Maybe I don't understand completely what he is referring to, but on mobile I certainly prefer having a bit more space than a always visible scrollbar. It is usually clear enough that there is more to see below the fold.
Scrollbars used to be sometimes useful to get a sense of how much content there is. But everyone using infinite scroll broke that, not apple.
I'm not a mouse user so this issue caught me completely off guard!
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.
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.
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.
> 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.
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.
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.
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.
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
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 . Apparently that's how Microsoft Windows users do things. So now we have to as well.
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.
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.
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
 is an image comparing a list of trades with and without the scrollbar. The scrollbar literally hides an entire column's worth of data.
 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.
If you don't know AHK then it's difficult to pull apart what it's doing. AHK syntax is weird, toe anyway.
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).
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.
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.
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.
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.
It appears, at least from all the evidence I can gather, that trackballs without a scroll option is a very rare exception and would need to be from a model older than 10 years.
How did you determine this difference? I use a mouse with my laptop, because work only gives us laptops.
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.
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.
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.
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.
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.
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.
I feel like the big argument here is that it is often not clear. Maybe a scroll bar "wastes" too much space, but watching mobile device users you can sort of see there needs to be some sort of system-wide scroll indicator. A lot of mobile users have nervous habits/tics of randomly scrolling every screen of every application they use. It doesn't waste a lot of time in a day, but it makes everyone look nervous or mentally ill and it's a bunch of papercuts better interface design could solve.
When Microsoft briefly flirted most directly with hidden scrollbars by default in Windows 8 their design guidelines required that grids never align perfectly to available viewport so that stuff always "peaked out" if there was something to scroll into view. A lot of people found that aesthetically displeasing for whatever reasons, but it certainly was a good scroll indicator. Even mobile devices could use something to avoid the "random swipe syndrome" that seems to plague mobile users.
And that was good advice. Because whenever there's a thread on Apple and scrollbars on the Internet, I can find someone telling a story of how they never knew some app was scrollable, because the grid aligned perfectly with their iPhone/iPad viewport.
I very much disagree. On all of the mobile devices I've used it has never been clear that scrolling is a thing unless there's a scrollbar.
I didn't even know you could "pull down" menus or pull up some app status thing until I called support and asked how to close background apps or turn off wifi
There is no excuse for it on desktop except blindly imitating mobile UIs.
Or using a PDA-like UI with miniaturized desktop UI elements, but that style requires a stylus to use which is why the simpler, chunkier smartphone touch UIs became popular in the first place.
In which case, in order to submit the form you would scroll down until you see the button, and would therefore have scrolled past all the fields?
It sounds like the form itself had a lot of problems. Either there wasn't enough contrast on the fields to know they existed, or the submit button was located above fields that needed to be saved, which is an inexcusable interface design choice. Also one could argue that there should be form validation as well to alert the user of critical unfilled form fields. Then again, we can't rule out simple user error.
I don't know, it just sounds like a lot of stuff was going on here. I doubt a scroll bar on the side of the webpage would be the critical element that solved all of the problems. I have no problem criticizing Apple, but its hard to put the responsibility of the entire internets' usability problems solely onto their shoulders.
In this specific case it is probably obvious enough that hey maybe I need to try scrolling randomly to find "baccalaureate" but the particular form that drove me to capture the above was littered with similar cases where it wasn't at all obvious. More than anything though the invisible scrollbars just meant I had to second guess every single form I ever submitted.
Ever gone to motherboard/RAM/etc manufacturer websites? Unmitigated disaster. Is this the same ram stick model? Why are there 3 million variations and no explanation of the distinction between them? How is it that there are 5 different filters and none of them seem to filter for the thing you’re looking for? Why does the marketing page take me to a different sub domain for this one product, but not for the other? On and on.
I’m not an Apple user on desktop, but even there I have scroll bars disabled everywhere including the IDE. Why use the space for something I never use.
And btw, I’m not saying it should be like this for everyone. From my perspective this should be configurable. Same as I wish apps and sites would offer a dense mode toggle to reduce white space.
The scrollbar is the only way to scrub/seek through a large page's content efficiently.
On iOS the scrollbar is only invisible when you aren’t scrolling.
Whether it’s visible or not, you can drag it with directly with your finger just like dragging desktop scrollbar. No need to induce any strain.
The same is true on the Mac.
This entire issue is only about the default at rest behavior.
Scrollsbars are visible during scrolling, and if you want them the whole time, that’s a setting.