For anyone (cough, elderly parents) who aren't adept at discovering hidden features, these things can be utterly mind-boggling and frustrating. Even I was stumped for a good minute the first time trying to print/save/download a PDF when that "feature" came out.
I don't really need the small sliver of menu space in PDF view to be reclaimed -- and for what, a "clean" look? Those are real and important functions I desire. What I actually need is for news and blog sites to stop covering 1/4 of their vertical window space with hovering frames, ads, and banners asking me to subscribe. Which, by the way, subsequently don't properly calculate into that now hidden scroll bar's movement and cause you to overshoot the displayable area when paging down. End rant.
You don't even have to be elderly.
The 20-somethings in the office (pre-pandemic) had no idea that on an inconsistent smattering of Apple apps, if you pull down, a hidden search bar magically appears.
How did that conversation go?
Dev: Where do you want the search bar to go?
Designer: Put it somewhere that no one will ever see it, or ever think to look for it.
Who thought that was a good idea?
I think people in the SV/HN bubble play the "what about the elderly?" card too often, because we're afraid to admit that we, too, don't know how stuff works anymore.
Over time, they started hiding it by default and require you to scroll up to access it.
I think that, at a general level, this principle of development is reasonable: things that used to require being extremely explicit can become more implicit over time as users become adapted to it. Computers used to feature tons of skeuomorphic design to make it obvious what everything was (so you could think about your computer with the same lens as you thought about your desk, for instance), and now we've mostly done away with that because the vast majority of users don't need it.
Where Apple fails in this regard is two things, I think:
1. They assume prior familiarity among groups who won't have it.
2. They do not leave any affordances to even suggest the presence of something hidden for those who won't know it (or have forgotten).
For the scroll bar issue, I think they could introduce an affordance in the form of, say, a couple small horizontal bars at the top of the page that kind of indicate "you can pull down on this". While early versions of this same design were pretty large and could be considered intrusive, I think users are familiar enough with the "tactile" touchscreen elements that we could develop a smaller version to use for these things.
---
Your point in general still stands, though. Apple has become more and more egregious about this over time. Things used to be very discoverable, and now there's tons of hidden functionality in most of their apps (both mobile and desktop). I think they've succumbed to more feature creep over the past couple of decades than they want to admit.
One of the common responses I see when I complain about a bad UI is someone saying "no it's easy you just do ____". It's frustrating because that's not the point - the point is that I had to do research to find the answer!
There are cases, especially with specialized tools for complex tasks, where you are expected to spend time learning how to use the tool effectively. Photoshop is a great example. Vim is a great example. Figuring out stupid stuff like whether that grayish light blue vs dark gray fill on the checkbox means "enabled" or "disabled" is not an example.
I know my willingness to explore UIs went down a lot when
1) All the buttons became icons instead of text that clearly explained what was going to happen and
2) My phone became the place where all of my social media accounts were always logged in and all my internet activity was centralized. It became easy to accidentally share between different worlds.
I type the konami code as soon as I discover a web app supports keyboard input. I have no problem pulling-to-reveal and shaking to undo. In fact, it makes me feel awesome to know all this little secrets and have people all like: Wait! how did you do that?
But when I design software I don't do it for people like me. I want my users to feel awesome and delighted without being UI spelunkers. Good design doesn't make you think.
It all sucks. I'm convinced that devs are trying to frustrate me, and it's working.
Don't get me started on the icons-without-text design shit.
If an application isn't either essential to me or incredibly obvious to use, I am unlikely to learn it's fancy new UI. Why bother?
This extends to APIs and DSLs too since there are often so short lived.
Perhaps but even when I don't know how an app works I can usually figure it out, either by trying different things or just googling. Older generations tend to be afraid of "breaking" the device and avoid doing anything they dont already know.
A designer. Probably the same person who wanted to turn links from blue-and-underlined to same uniform gray with zero indication
I suspect I don't know some crucial (in Apple designers' mind) swipes on my iOS devices, because they're just hard to discover.
It's a leftover from when iPhone screens where much smaller: https://postimg.cc/WFdqPwfd
Pull down for search is something that it maybe Apple is trying to cement (and only for mobile, I guess?), but hasn't crossed (and maybe won't) to Android devices. Apple is known for doing stuff like this and pushing changes, sometimes it takes, sometimes it doesn't (e.g. no floppy in laptops, no CD-ROM in laptops, no Mic jack, etc)
I'm know my tech and I can't figure out how to reliably get Safari on IOS to display the bar at the bottom.
Makes me crazy
On Chrome I could't get the button to appear so I can save the PDF on my drive. Completely frustrating.
I notice that becomes something of a tic of iOS users, if you watch others, in that just about every new screen or panel there's often at least a squiggle of pushing the screen or panel around just to figure out the boundaries.
One of the things I thought was brilliant about early Windows 8-era "metro" design: it was the only era Windows briefly experimented with going scrollbar free (it went back to scrollbar "light" soon after) and when they did so they absolutely made sure that the application grids never lined up with viewport. If there was something to scroll, it would stick out a bit, always that little hint that there was something more further down or right.
It got some flak, especially from macOS design fans, for not being "clean enough", but you'd have apps with no visible scrollbar and you knew whether or not there was anything to scroll just looking at them. You didn't have to squiggle your finger around (or fiddle with the scroll wheel) to check.
https://www.fastcompany.com/3053406/how-apple-is-giving-desi...
"Once upon a time, Apple was known for designing easy-to-use, easy-to-understand products. It was a champion of the graphical user interface, where it is always possible to discover what actions are possible, clearly see how to select that action, receive unambiguous feedback as to the results of that action, and have the power to reverse that action–to undo it–if the result is not what was intended.
No more. Now, although the products are indeed even more beautiful than before, that beauty has come at a great price. Gone are the fundamental principles of good design: discoverability, feedback, recovery, and so on. Instead, Apple has, in striving for beauty, created fonts that are so small or thin, coupled with low contrast, that they are difficult or impossible for many people with normal vision to read. We have obscure gestures that are beyond even the developer’s ability to remember. We have great features that most people don’t realize exist.
The products, especially those built on iOS, Apple’s operating system for mobile devices, no longer follow the well-known, well-established principles of design that Apple developed several decades ago. These principles, based on experimental science as well as common sense, opened up the power of computing to several generations, establishing Apple’s well-deserved reputation for understandability and ease of use. Alas, Apple has abandoned many of these principles. True, Apple’s design guidelines for developers for both iOS and the Mac OS X still pay token homage to the principles, but, inside Apple, many of the principles are no longer practiced at all. Apple has lost its way, driven by concern for style and appearance at the expense of understandability and usage."
What's most telling is how even Apple often does an astonishingly bad job at it - it really sets the precedent regarding diminished importance.
As an exercise: Browse the App Store for a while and count the number of different ways it implements "go back one step".
I changed the setting to Mac OS always shows scroll bars, but I have no idea how someone thought hiding them was a good idea.
The fundamental difference with modern user interfaces is that you now have to tap, drag your finger across the screen in different directions, drag both fingers across the screen in different directions, pinch, unpinch, and whatever other gestures seem to be relevant to the situation. For good measure, try gestures that don't seem to be relevant either because the software may surprise you!
Now I know that a lot of these user interface decisions do offer value, but they are only valuable if you know that they exist.
I works a surprising amount of the time!
I can't live without firefox's reader mode, which is pretty much Gopher-for-html.
And for Nuke Overdrive mode, add a check for position: sticky, i.e.
(function () {
var elpos,i, elements = document.querySelectorAll('body *');
for (i = 0; i < elements.length; i++) {
elpos = getComputedStyle(elements[i]).position;
if (elpos === 'fixed' || elpos === 'sticky') {
elements[i].parentNode.removeChild(elements[i]);
}
}
}
)();I've considered writing an extension to kill them all by default, but I'm afraid I'll break some site in a way that really confuses me and end up wasting more time figuring out what happened than I save with the extension.
I'm in my mid-30's and I find Apple awful at discoverability.
Take using Apple Pay. I don't use it often, but covid has had me wanting to. I can't ever seem to remember what sort of hand waving I need to do to get it open. I seem to occasionally bring it up when I don't want to. (It's triple press the home button when the display is off, long press is Siri.)
My first instinct was to flick it up from the bottom, but that brings up the recents switcher. Next instinct was to try flicking it off to the right, but it just moves a bit and springs back. While trying more times to fight the spring I noticed a short bar at the top and realized it was probably a drag handle. Grabbed that and tried to flick it downwards. No luck, but it moved in a way that made it seem like dragging down more would do it, but nope of course that wasn't it either. How about a flick to the right? Nope. Dragging it to the right? Agh! It's trying to dock into split screen mode! I dragged it around some more hoping for different behavior before dropping it back into place and again trying a flick to the right using the handle at the top. And that FINALLY did it. Apparently I didn't put enough enthusiasm into the first flick I tried... What a pain in the ass.
I don't like how sensitive to speed some of the actions are. I have similar issues with bringing up the dock. I usually end up going to the home screen instead.
You set the phone next to the terminal and the card comes up when radio contact is made.
My computer is an 11-inch MacBook Air.
That means that even if I run Safari full-screen, which is inconvenient, I have only 680 vertical pixels for content.
It's amazing how many web sites I run into that throw up fixed-position pop-ups that are bigger than that, and I can't close them or scroll to see their content because the designers or middle managers decided that every person on the planet is rocking a 27-inch 5K display.
Usually I just close the window and never visit the site again. If it's important, I break out the dev tools and start invoking display:none until I hit the right element.
I detest scroll bars. When I work on my windows machine I cannot stand seeing them plastered all over the screen.
It’s actually quite fascinating to read all these comments - it’s so weird to see people complaining about how they don’t know when a scroll is available. Just scroll and see!
No negative feelings toward people who prefer them - it’s actually quite interesting to see the comments, I assumed everyone agreed they were better hidden until today! (Which, as a Mac user, is obviously part of the problem being expressed!)
Why should I try scrolling everywhere all the time instead of having the UI indicate to me that there is more content? Especially if it isn't clear by having a word or sentence cut of. Maybe the scroll area ends with a paragraph and it's not clear there is more. Why put aesthetics over usability?
Some other comments here claim iPhone users develop some kind of swipe tic where they instinctively try to scroll around on every screen that opens. Would be a pretty sad testimony to this UI concept.
I feel the same way about other "unspecified functionality" services, like fancy hotels with "personal butlers." What does the butler do? "Whatever you need" is not an answer. I don't have familiarity with butlers, I don't know what is and is not a reasonable request.
There are valid reasons for both sides of the equation, it is just difficult to find the balance to satisfied the myriad of different perspectives.
How about people (designers) start thinking about their users and some some strict adherence to someone else's opinion about Material Design. I hope we see Material Design like we see touch screens in vehicles. An embarrassing mistake at best and potentially fatal at worst.
Design should always serve the user. If it doesn't, it needs to go away.
We used to achieve this balance with a manual.
A printed manual. Not a URL printed in 3 point Helvetica in light gray on a white background on a tiny leaflet in amongst a dozen similar-looking regulatory leaflets that will all go into the recycling bin when the new shiny shows up.
So I connect to it via RDP for the first time, and it is using XFCE. I'm not a big user of the desktop, I have no idea what the choices are or what features are offered in Gnome or KDE, or whatever. I just sometimes need a GUI to do some random things.
I open a window, and decide I need to resize it.
There's no cursor change when you move the mouse over the edge, or the corner. It just doesn't let you resize the window. There's no three-lines things in the corner either, you just can't grab the corner to resize it.
I ended up having to google that you need to ALT+RMouse to do this.
I don't know why that would be the default. It seems crazy.
- select non-maxmised open window
- keyboard shortcut Alt+Space. Then M. to move.
- use arrow keys to move windows offscreen, say to the right. Don't touch the mouse!
- Hit Enter key to confirm position.
From now on. Anything but "full maximise from the taskbar" makes the window "disappear" without a trace. "Restore" from the taskbar doesn't help.
And assuming you even know exactly happened, you still have to guess which direction they took the window and how far...
How is it there is no "Position Reset to 0,0" option?
- From the keyboard WIN+{Left|Right} resizes and pins the window to the side of the screen
- From the keyboard WIN+Up to maximize the window (or right click on the task bar and select maximize. Now, drag the title bar from the top and the window will unpin from the screen and move with the mouse
- Right click on the task bar and choose any of the windows arrangement options (Stack, tile, cascade)At least on macOS, all the mouse-like input peripherals that Apple will sell you (both the Magic Mouse and Magic Trackpad), and all the inputs for their laptops, have two-finger "natural" scrolling.
Apple seems to expect/assume that you've scrolled a touchscreen at some point in your life (in fact, many people have scrolled more touchscreens than desktop computers at this point—including many old people!) and has built the OS around the idea that, just like on a touchscreen, scrolling is a gesture that you can attempt to apply anywhere, whether there's an affordance for it built into the app or not—i.e. that scrollability is a universal, system-level operation, not something up to the application. Every application in macOS/iOS is inherently built in terms of having some kind of "viewport" with a "document" loaded into it; and scrolling moves the "document" around within the "viewport." Even if that's a pointless thing to do, it still attempts to perform the operation.
(Though in terms of feedback, iOS has a more coherent responsivity to "attempted" scrolling than macOS does. You can "tug" at the top and bottom edges of the screen in pretty much any iOS app and get some extra out-of-document blank space, with a snapback when you let go. Whereas, in macOS apps, this only happens for "content" regions; whereas for "chrome" regions—e.g. the top-level icon listing in System Preferences—the region will only have snapback if the window is small enough for the region to be scrollable. If the window is large enough that everything is presented, your scroll gestures just go unacknowledged, as if the window wasn't a "document" in a "viewport" at all. Interestingly, you also can't resize such all-chrome windows; you only ever get a scrollbar on them if running on a computer with a too-low display resolution.)
What is missing, though, is a visual indication of whether scrolling will do anything, before you try it. Scrollbars used to help with this, yes. But the fix isn't simply reintroducing them. The world scrollbars were built for no longer exists: both web apps and modern native apps now do progressive loading/"infinite scroll", where the view-controller isn't necessarily aware of whether more content will be discovered when it tries to demand another chunk of data from its backend. Even when you force-enable the scrollbar, the size and relative position of the "scroll-thumb" now communicates no information about your "actual" scroll position in many apps.
As well, there are now real infinte-canvas apps (like Maps) where a scroll "position" wouldn't even be a coherent concept, because the document under the viewport is a self-connected torus. Universal gesture scrolling adapts well to this concept; scrollbars don't.
IMHO, I'd like to see a slight fade-to-black or 3D "bend away from camera" applied to the inner edges of the scrollable viewport, whenever the document in the viewport is not sitting flush with that edge of the viewport. This would provide a visual affordance of "scrollability" without providing any often-misleading information of relative scroll-position. Infinite-scroll documents would just always be "faded out" on all edges. Seems obvious?
> I don't really need the small sliver of menu space in PDF view to be reclaimed -- and for what, a "clean" look?
Nah, it's for shitty low-end laptops that still to this day have 1366x768 displays. Stick a title/tab bar, tool bar, and maybe an always-on bookmarks bar on top of the window, and an always-on start menu at the bottom, and you'll find that the PDF only gets about 400px of viewport real-estate. And now you want the PDF's own controls to steal more of that? There's a reason that Chrome first made the status bar into an overlay, and then merged the title bar with the status bar — it's trying to reclaim vertical space for exactly these constrained scenarios.
We had scrollbars on 640x480 both ways and liked it. Even SGIs with 1280x1024 monitors had scrollbars, and it wasn't a burden that some folks today seem to think it was.
Edit: Thinking further about this, the affordance for maps is a change in the cursor to a grabbing hand. You have to learn that, but there's a clear visual difference in the cursor to show that something differnt happens there.
[1] http://sergeykish.com/side-by-side-no-decorations.png
[2] https://chrome.google.com/webstore/detail/convert-to-popup/i...
[3] https://github.com/sergeykish/hide-scrollbars # chromium, firefox has another rule:
html {
scrollbar-width: none
}So users should purchase new equipment to suit designers? Or maybe - crazy idea, I know - designers should design for the equipment people actually have and not whine or look down their noses because not everyone makes designer salaries.
That's a really poor excuse. If that "awareness" is missing then the code is structured wrong, probably because somebody cargo-culted a design pattern without ever once thinking of the user.
Even you? Wow!
But srsly, that's not a snide comment but rather a hint that your personal sensibility may not reflect broad sensibilities. And of course, there may not even be a single broad sensibility -- look at the political parties in the US, both the major divisions and the subdivisions within each. Sometimes, the maker of something has to make a design choice consistent with their [market success proven] direction.
> I don't really need the small sliver of menu space in PDF view to be reclaimed.
When I'm on my laptop, I do. Every inch of vertical space is precious. On my display monitor, not so much, but having the buttons reveal rather than permanent doesn't detract in the slightest.
Then I opened Adobe After Effects for the first time and it suddenly made sense to me, the UI I found intuitive was just years of practice. How is an x in a corner a close button? What's so intuitive about swiping up to see a menu?
It's to stop the offset shift. Pages with scrollbars and pages without have different document widths but the same viewport width.
When you click between the two, the page "shifts" half a scrollbar width if it's centered.
To fix this, Apple made the scrollbar an overlay. That stops the shifting. But then everything on any page with a scrollbar looks off-center.
To fix that, Apple made it disappear when it's not being used.
Lot of fancy homepage with scroll animations are awful on anything that isn't scrolling as smoothly as a MacBookPro touchpad.
Example: https://www.apple.com/ipad-pro/ is horrible to use on anything that isn't a mobile device or a Mac.
I guess this is an example of being in my own bubble, but I can't stand touchpads. I've used the touchpad on MacBook, like, twice in 2 years.
One demographic I would expect traditional mouse usage from would be gamers. When I play a first person game I always use my trusty old intellimouse. Otherwise, I use the trackpad unless I'm simultaneously using my mechanical keyboard, but if my keyboard had an attached trackpad I'd probably be using that. But mousing in general just isn't a very important to my workflows and trackpads work just as well as mice for nearly all tasks. Arguably they work better for some since you don't have to move your hand far from the laptop's keyboard to use the trackpad, while using a dedicated mouse means taking your hand completely off the keyboard.
When I scroll down, I expect one thing to happen: content on the page moves from the bottom to the top, revealing previously un-seen content on the bottom. That's it. Please stop trying to make scrolling do something else!
[1]: https://i.imgur.com/PGdyt1c.jpg [2]: https://i.imgur.com/AXLi4Yu.jpg
Annoying. The only fix is to hover over the scroll bar itself (and I have macos -> system prefences -> general -> show scroll bars: always)
a) find out how big the page is b) scroll more precisely
I don't even understand why they would remove them? Who ever complained of a scroll bar?
I have never seen that to be the case unless in an environment with very heavy constraints like embedded. If anything, a competent programmer 10-15 years in would skew towards more descriptive and clear variable naming as they've been burned in the past by having to maintain some of that "leet" code.
If those coders are like me their code becomes more verbose, less clever, more obvious, less dependent on the quirks of the programming language I use. The reason is that it's easier for me and the other developers in the team to read and understand what it does.
On my way to here I really hated many geeky clever and brilliant pieces of code I found in projects I inherited. They made me and my customers lose days at decoding all that brilliance.
What are you talking about? I've been programming a long time, and clean, readable code with clear, descriptive variable names gives me a stiffy. It suggests a more meticulous mind than mine wrote it.
You know who writes the worst Gordian-knot code? Engineers from other disciplines who learned programming as a means to do other engineering calculation. Smart guys, but it's a pain keeping track of what i1, i2, i3, and i4 mean, or their 1970s FORTRAN program flow.
Literally in this case :)
IMO it's all part of this push to combine mobile and desktop UI. On mobile there is a legitimate case to be made for removing them because screen real estate is so precious. But desktop gets clobbered as an unwanted side effect.
Hidden scrollbars recently caused me an extra day of work. I was documenting all options in hundreds of html select boxes (dropdowns) on a legacy product being rewritten.
Many of these dropdowns were vertically scrollable, but macOS using Chrome did not display a scrollbar. I had no idea they were scrollable and missed many options in my documenta3.
I could not look at the html for it as it was minimized and not easily searchable.
In Chrome:
1) Right click on element you want to grab all of the contents of, and select Inspect Element. NOTE: If this element is the sort that isn't properly placed in the DOM and/or disappears when focus/mouse leaves, you can freeze the current DOM...but the right way to do that will depend on your context.
2) In Elements tab in Dev tools, the element should now be highlighted. You may need a parent or child element. But hopefully you can find it nearby and verify you have the right one with the Inspect tooling.
3) Right click on the element that has all your data in the DOM. Select Copy. Sometimes it will be enough to just Copy Element and paste it somewhere where you can start organizing the data. But for your task, it sounds like you might want to write a script for this so you can do it across multiple Elements. So, try Copy > Copy JS Path.
4) You now have access to the DOM element, even if it was created dynamically by JS and exists in the Shadow DOM. Try "paste" in the Console tab of Chrome DevTools.
5) The thing you grabbed might not be exactly the right one. Navigate down to the level you want to iterate across with the "children" attribute. Example:
const myStuff = document
.querySelector("#output > shadow-output")
.shadowRoot.querySelector("div > ul > li:nth-child(2)")
.children[0].children
console.table(myStuff, ["innerHTML"])
const stuffArr = [...myStuff]
const mappedStuff = stuffArr.map(x=> { /* transform each thing */ }
console.table(mappedStuff)
Just to extend a touch—I use CMD+Shift+C or CTRL+Shift+C countless times in a day while debugging, or sometimes for this very reason. The shortcut is the same across browsers—at least Chrome/Edge/FF/Safari.
Instead of right clicking, it'll give you a "target" for selecting an element and highlight it before clicking.
In the console the selected element will be immediately accessible by `$0`.
Eg,
$0.innerHTML;Give the Chrome dev tools a try. It "un-minifies" the html making it viewable and easily traversable.
https://developers.google.com/web/tools/chrome-devtools/dom/
https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
We need a new set of units that excludes document scrollbars. Or a constant like env(scrollbar-width) that represents the scrollbar width so that you can subtract it yourself, which would be useful in a few other places as well (instead I’ve done the likes of `var(--scrollbar-width, 20px)` and calculate and define --scrollbar-width on the root element in JavaScript).
That was fun to fix because I had to rebuild the entire header since a ton of other webflow-generated CSS depended on that thing being static.
The thing was: We catered for gamers which means Chrome or Firefox on Windows was the norm. We got a lot of bug reports like “hideous scrollbars in shop item description” or “hideous scrollbars in menu” where the devs were puzzled about the bug reports.
Yes your giga HD retina Mac displays these colours perfectly, I'm sure it looks great. On my screen however I can't read a damn thing.
How one can tell whether what you capture/develop is what you will see without testing it on a second monitor? What is the subject I must do research on to learn more about this?
I'm not just talking about color spaces, but also how these multiple software communicate image data in a lossless way, how window modes (fullscreen, borderless, windowed) affect these flows, where HDR stands in this.
System Preferences -> General -> Show scroll bars to Always.
System Preferences -> Keyboard -> Modifier Keys
Also watch out for people from marketing and the like who put pressure on the UX people to do that sort of thing. People who don't actually know how to make anything work, and don't have to actually use it to get work done, tend to be obsessed with how it looks.
A few casual users who don't actually need to get anything done will usually support this kind of time-wasting idiocy, and the offenders will point to their feedback for validation. Unfortunately people who write reviews are often in that category, since they rarely make practical use of what they're reviewing.
I think it's called using a scrollbar. :) That's typically how they work.
To spare readers the content marketing piece: tap and hold to grab it.
This "feature" has been available on every Windows, Linux and Android device I have ever used.
I'd take that one step farther - no matter what platform you code on, test your UX on all the others.
One of the best things I think I've done for quality purposes is require all developers, QA team members, and project managers have scrollbars turned on at all times. It's sent the number of sites with hidden overflow in production down to near-zero for us. Someone, somewhere down the line will end up seeing that your page is 300px wider than the viewport before it hits production. And because that usually indicates other problems (often related to accessibility), it usually has a domino effect of discovering other issues that need to be fixed.
It has definitely made a marked improvement to the quality of our work, and I recommend everyone require their teams using Macs to require scrollbars be set to "Always"
All you need is one Windows or Linux-based developer in your team to catch those kind of issues. But so many dev teams are macOS-only those days, whereas, apart from US and 2-3 other rich countries, 80%+ or even more of actual desktop users are Windows-based.
(There are many other problems with macOS monoculture, for example, the spread of ultrathin fonts that look nice and crisp on retina macbook but result in very low contrast rendering on Windows).
US-based devs: outside of your country (that is, >95% of humanity), most people do not have a Mac, an iPhone, nor use MM/DD/YYYY dates and 12-hour clock.
I think you mean outside of the Bay Area. For PCs/Desktop Apple has like 12% market share in the US. 7% globally.
I use Windows as my daily driver OS now for both native/web/mobile/devops work and I expect to see more and more developers making that same switch in the coming years.
A good set of examples is here
https://www.theguardian.com/lifeandstyle/2019/feb/23/truth-w...
Up until Android and iOS mostly phones and tablets, we had a monoculture Intel and Windows. Windows is still almost 90% of actual laptop/desktop users. [1]
I am an ex-Mac developer. I do not have a modern Mac, I do not have an iPhone, and I set the date/time format to pretty much whatever I want on Linux, Windows, and 15 year old Mac OS X. And, I just have to deal with broken date/time interfaces on the web. For far too long, I would go along with the Intel / Windows developer monoculture of "good enough" software, and comments like Mac? Linux? What's that?
[1] https://www.netmarketshare.com/operating-system-market-share...
This is an unsubstantiated claim, why bring up and bundle the entire United States to support your claim? I was with you until this.
I don't even live in US. But this culture certainly exists here too.
The world does have a variety of options, so users need to live with the fact that they're going to have to discover things, and designers are going to have to live with the hassle of designing for users with a variety of experiences. That makes the best possible UX worse than it would otherwise be. It's a necessary evil, but it's not surprising that a lot of developers try to wish it away, especially when they can get away with that, at least initially.
Recently, we were doing a bug safari for a new product feature that was about to launch. I noticed that an element had a scrollbar when it shouldn't, and filed a bug. One of the developers picked it up, and first said "not a bug. I don't see it on my computer." I showed him the bug on my machine, and he looked at it for a few minutes before saying "I don't know how to fix it." I pointed out that the overflow-x was set to "scroll" in the CSS for that component, and he could just set it to "auto" to fix the behavior (since the scrollbar should never show up in normal usage of that feature). It turns out that he didn't even know "auto" existed.
On NTFS you can hide an arbitrarily large file in the "Alternate datastream" of any file. Explorer doesn't show you alternate datastreams and certainly doesn't show you they are possible.
You can use VLC to play a bluray from what appears to be a 1kb text file in Explorer.
If you have that on a USB stick, the properties of the USB stick will reflect the capacity loss of the bluray image. But Explorer won't show you why or which file has it...
https://blog.foldersecurityviewer.com/ntfs-alternate-data-st...
- Discoverability: You don't even know if a container is scrollable at all until you try.
- Orientation: You don't know where you are in a document until you scroll to make the bar appear, and then you have to notice it before it disappears
- Usability: It's much harder to target the scroll thumb to drag it. To find it you need to again scroll first, then notice it, then target it with the mouse, all under time pressure before it disappears.
If you're on MacOS, do yourself (and your users) a favor and set them to always show.
That's not enhanced at all, it's horrible, and scrollbars should be more contrastful and bigger again
The actual useful UI left is “does this thing scroll”, “where on the page am I”, and “the grab and flick” gesture on touch to scroll faster.
In hindsight I think the mistake was having scrollbars be part of the document flow instead of hovering invisibly over the content until they’re needed.
I don't mind having to move my mouse to the scrollbar and drag it to scroll documents or webpages (when I can't use the keyboard for that already).
This was fine until a few years ago when scrollbars starting to hide or become super thin. I should not have to concentrate to be able to target scrollbars with my cursor.
If you're working on UX/UI design, please remember that not everyone has or uses a scrollwheel on their mice.
And I think this is a trend in the open-source that developers reject Windows patches, or never really try to fix the bugs.
Now a lot of tools are only designed for MacOS first. Linux is extra because it's easy to migrate. For example, Facebook Watchman. It's about 5 years but still unstable for Windows I think.
And many web tools, even Android development, I found it's no errors in MacOS but have to fix the config or do extra yourself to get it to work properly.
I don't think hiding scrollbars can really be termed an enhancement; 'mistake' at best or 'user-hostile behavior' at worst seem more appropriate.
The original Macintosh GUI succeeded so well because it made it so easy to see what was possible. It laid an awful lot of stuff out right there on the screen in front of the user, and what was hidden was easy to get at. They spent a ton of time testing an improving usability. Modern macOS, OTOH, just doesn't feel right anymore; I suspect it is designed to look good, not to be usable.
More recently, a few weeks ago we had a bug in our app that was caused by an India time zone. Our company is fully U.S.-based so nobody noticed. Since then I've kept my computer in the India time zone so that time zone issues are readily apparent. I've already caught another one since then.
There's a more general principle here of "user empathy": configuring your environment so that you're in the same boat as your users.
I think there are two parts to the problem: ① a popular developer platform using overlay scrollbars; and ② the fact that `overflow: scroll` sounds like what people want, when it’s actually not (as you say, they wanted `overflow: auto`). If I could rewrite the history of just this one property, I’d rename `scroll` to `always-show-scrollbar` or `show-scrollbar-even-if-insufficient-content-to-scroll` or similar. Or maybe split `overflow` in two and use `scrollbar-show: always;`.
Hmm. I wonder if we could convince browser makers to kill off `overflow: scroll`, making it equivalent to `overflow: auto` due to rampant abuse (there’s precedent for this sort of thing), and replace it with a new, more clearly-named property `scrollbar-show: always`. (And `scrollbar-{x,y,inline,block}-show` to go with it.) Maybe `always` wouldn’t be quite the right keyword, given that it wouldn’t be affecting the behaviour of platforms with overlay scrollbars. But this actually sounds both reasonable and feasible to me, given that `overflow: scroll` is subject to rampant abuse due to misunderstanding and was basically only a tiny quality of life thing for certain corner cases in layouts anyway.
It was much more rigorous than other design content I watch (e.g. skillshare, youtube), which are usually based on how something looks (emotion) and not the actual efficiency or usefulness of the design.
In the industry we really should distinguish between UI Architects and Aesthetic Designers.
I have on idea what school of thought has brought forth the no-UI UI but I absolutely think they are idiots.
<body style="overflow: scroll;">
<div style="overflow: scroll;">
<div style="overflow: scroll;">
<div style="overflow: scroll;">Makes me wonder if I'm missing the point of the fairly simple post?
When I first saw it the first thing I did was to find a way to get rid of it. In Windows it's: Settings > Ease of Access > "Automatically hide scroll bars in Windows" > Off
This just reminds me of how lovely it would be to have complete interoperability between every browser, every OS, mobile or desktop... And how unlikely it is to happen in the near future.
They're undoing much of what Ive did to MacOS, it's time to include making scroll bars as big and useful as they used to be!
I felt absolutely ridiculous and ashamed after that. So, I make a point of designing all my software with visible scroll bars and other visible features that a user could reasonably expect to find without having to hunt or guess.
Sure, it doesn't look as "pretty" but it's so much more useable.
I misunderstood the intent and I thought that they were just replacing the scrollbar to style it, which as a side effect broke the behavior with a mouse in Windows/Linux, but it took me long to understand that it was because Mac OS removed them by default and it was not just designers being obsessed about styling the scrollbars...
That stuck with me for a long time, and I remembered it when MacOS and iOS first began departing from that philosophy with their modern looks. I would say Jony Ive contributed a lot to this transition from user-friendliness to design-led, form-over-function.
The fact that I can only toggle it at an OS level is pretty bad. I love the invisible scroll bars and I would prefer to have them in all apps I use myself, but I do respect the platforms and users who have visible ones, but I shouldn’t have to choose between my own user experience and testing for their user experience
In the Gmail Admin interface for users, the scrollbar vanishes unless I have my browser nearly maximized. Do the designers live in a world where their browser is always nearly full screen?
You'd think huge companies would notice and care about these things.
I remember on IRIX they were so bold, a real tool to be used. Same on Windows up to and including Windows 7. Now it's like you have a 2 pixel wide invisible border, hard to click, which may be the shadow of the window, or at the edge in the window; it's hard, specially when working over VNC. Nothing is gained by freeing up those 10 horizontal and vertical pixels.
I think this is a lost cause. A lot of macOS people are "zealots" and they feel that anyone who uses anything else is simply "wrong." I've long dealt with designers like this and realized I can't win.
It would be a lot nicer if, while typing a command, a list of options came up, along with a short explanation and example, and by clicking the option the full documentation for it would come up.
But that cannot happpen, console apps have no connection to a UI.
The amount of hidden-ness/clevery fuckery in OSX is maddening. I would implore every one to complain to Apple to fix their broken OS.
The web is fine, the garbage developers are putting out is because of the broken dumpster fire of OSX.
You'll notice that Apple loves to champion usability (HIG etc) ... except when it flies in the face of their minimalist aesthetic.
Solution: web developers should change how they do CSS to accommodate Apple.
Grab your ptichfors brothers and sisters, we have another heretic to burn at the stake!
I really like the hidden scrollbars that Apple settled on. They are easy to identify by hovering the cursor over scroll-able content and they just act as an overlay over the content. In windows, the content is actually shifted the width of the scrollbar which is terrible for UI consistency in some cases. There is the problem that hidden scrollbars remove the "discovery" aspect of traditional scrollbars, but I find this to be a very minor loss in practice. I don't miss having a sliver of a scrollbar for large content blocks.
I ultimately just settled on styling scrollbars in CSS, making them a bit slimmer and forcing that behavior on the Mac for consistency. Scrollbars look nice, match my UI look and feel, minimally shift content and look consistent across all platforms.
I threw away all of the custom JS approaches that try to mimic Apple's solution because none were perfect and, in every case, introduced new problems that disqualified them entirely.
Agreed.
> Alternatively, you can set the scrollbars to be visible at all times by setting System Preferences -> General -> Show scroll bars to Always.
Disagree. Now you're using a different UI layout than the vast majority of your users!
After all, the initial sentence also didn't imply checking _only_ some other platform.
Stop complaining about discoverability, everyone that knows how to browse the web knows how to scroll. It's like worrying whether the user will know how to use a mouse when you're designing a web page. Scrolling is not something like shortcuts or tabs - you need it to move around, which means you get to know it as soon as you start your computer and after the first knowing phase it's visual clutter.
Also, I would like to ask whether users will usually even want to click on the scrollbar to move around. Unless the small number of cases where the page is long and you want to move around quickly (and if you have ever been in that case, you know that even there using the scrollbar is pretty useless because it's too sensitive - you are usually less precise when you use a scrollbar, not more), there's virtually no reason to click it. Computer screen estate is precious because not everyone is using a 27-inch display (13-inch display here), so that's a pretty big reason to hide the scrollbar.
MacOS default UX w/ the hidden scrollbar represents a tiny portion of any consumer-facing web product's user base.
So what is the value of a development team, not experiencing the same UX as the vast majority of their users?
