[HN Gopher] Apple has gone to extraordinary lengths to make scro...
___________________________________________________________________
Apple has gone to extraordinary lengths to make scroll bars
invisible
Author : edward
Score : 499 points
Date : 2021-03-10 18:59 UTC (4 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| comprev wrote:
| First thing I do on a new mac account is enable "always on"
| scrollbars. They give me visual clue as to how much of the
| information I am reading - am I 10% down the page or 80%?
| SavantIdiot wrote:
| > I have a really hard time believing anyone would chose this
|
| I did.
| intrasight wrote:
| The issue with MacOS is a lack of user choice. One reason that I
| gave it up 20 years back.
| sbuk wrote:
| This changed is Mac OS X 10 years ago. You've literally been
| able to configure this behaviour in system Preferences ever
| since.
| fogof wrote:
| This is especially a problem for me, since I use an extension to
| make my websites dark. To fix this, I recently downloaded the
| Rescroller Chrome extension. Not only are my scroll bars now
| visible, they are a fun lime green (users pick color)!
|
| https://chrome.google.com/webstore/detail/rescroller/ddehdnn...
| mdoms wrote:
| I really don't understand it - they refuse to implement a touch
| screen on their laptops but continue to design for touch
| interactions.
| blackrock wrote:
| I've often made mistakes from not seeing extra data, because the
| data required you to scroll down to see it.
|
| It's a really infuriating situation. And quite a terrible UI
| design.
|
| And by hiding the side scroll bars, it removes your ability to
| quickly page jump down to the bottom of the page, or to anywhere
| else on the page, from clicking on the white space of the scroll
| bars.
| FreakyT wrote:
| An interesting output of this is, if you keep scrollbars visible,
| you'll find that a lot of websites end up with weird extra
| scrollbars on random elements.
|
| What often causes this is some HTML element overflowing by one
| pixel, but no one saw it during the QA process because all the
| webdevs were using Macs, which have invisible scrollbars by
| default. I always enable visible scrollbars on my dev computers
| specifically so I can catch problems like this.
| preommr wrote:
| > * { overflow: hidden }
|
| _defeated dev noises_
| scabbycakes wrote:
| I call it Made-By-A-Macitis because it's so common in this
| industry since MBP's are issued by default almost in web dev
| companies, which inevitably leads to weird scrollbars here and
| there on their startup websites until someone else finally
| reports it or a dev finally breaks down and tests it on any
| other non-Apple device.
| FireBeyond wrote:
| Remember all the "Made for / Works Best in Internet Explorer"
| buttons from the early 90s/early 00s?
|
| We've gone through a long period of "Works on my Safari".
| erwinh wrote:
| mac user & web dev here, I often employ a trick where I wrap my
| scrolling div in another div which has overflow hidden just to
| hide the scrollbar. QA & usability engineers must hate me :p
| CharlesW wrote:
| > _QA & usability engineers must hate me :p_
|
| "Hate" is a strong work, but humble users like myself also
| dislike you (or rather, your choices).
| deft wrote:
| Why? Stop making bad software and laughing about how it
| screws people over.
| distalx wrote:
| How? can you please share some example?
| ShroudedNight wrote:
| This comes across as smugly prideful at being explicitly
| user-hostile. What's the upside here?
| jacurtis wrote:
| I honestly think that this is the main reason that Apple hides
| scrollbars by default. I have turned on "always visible"
| scrollbars before and it really does ruin the internet
| experience.
|
| Now I'm not sure if you blame the OS maker (Apple/Microsoft),
| the browser makers (Apple again, Google, Microsoft, Mozilla),
| or the web developers of the websites. But regardless of who
| accepts or deserves the blame, it is hard to dispute that the
| experience is far worse with scrollbars forced always on. It
| shouldn't be this way, but as of right now, it ruins the
| experience.
|
| Like you mentioned, some websites simply don't work or don't
| work how they should. You end up with scrollbars on elements
| that aren't even form fields because of weird hacks that web
| developers are doing with overflow elements or strange CSS
| anomalies.
|
| I'm not sure how you address this issue. But it is definitely
| more deeply seeded than the OS level, and I think web
| developers (a lot of us here) should take some of the
| responsibility for ruining scrollbars. It is our company's apps
| and sites that drove Apple to this decision.
|
| I suspect that one of the reasons for hidden scrollbars by
| default is because the teams at Apple have tried to use the web
| with "always-on" scrollbars and didn't want their users
| experiencing the web that way. Remember also that defaults are
| important. Most people will never change the setting, even if
| it was obnoxious. Most Mac users are going to use the default
| setting, regardless of whether the default is always on, always
| off, or auto. Whatever the default is, that will be how most
| people use the computer and just accept it as "how it works".
| So Apple has to choose the best option (between three bad
| choices) that will best best for MOST people. Not everyone, but
| MOST.
|
| I also think that MOST people are used to automatic scroll bars
| at this point. Again, my Mom is the person that will never
| change a setting. So she will always use whatever the default
| is. And she is used to automatic scrollbars. She knows that if
| she wants to see the scrollbars, she has to do a micro-flick of
| the scrollwheel (or her finger on mobile/touch) to reveal the
| scrollbar. It requires minimal-to-no effort and most people
| have grown accustomed to it now. Is it flawless? No. But I do
| think it is the best option MOST of the time.
| jakub_g wrote:
| > I have turned on "always visible" scrollbars before and it
| really does ruin the internet experience.
|
| You have scrollbars everywhere precisely because they're
| hidden from developers who don't even know about them, and it
| seems ~all developers use Macs for web dev those days.
| trinovantes wrote:
| I've seen so many broken web components do this:
|
| 1. Hover over an element that enables the visibility of
| something else
|
| 2. Trigger an overflow and cause scrollbar to show up
|
| 3. Scrollbar shifts the original element
|
| 4. Original element is no longer being hovered so new element
| gets hidden
|
| 5. Scrollbar disappears and original element moves back
|
| 6. Repeat
| mrtranscendence wrote:
| This is annoying in macOS, but I do prefer having no scrollbars
| in iOS. There's limited screen real estate, and messing with a
| scrollbar with my finger doesn't feel any better than just
| scrolling to where I want to be.
| _Microft wrote:
| Learning never stops! I did not not know that you could
| actually use iOS scrollbars as real scrollbars. They are
| extremely fiddly indeed but I am pretty sure I am going to use
| them from time to time. I always thought they were simply a
| sort of dumb progress bar.
| throw7 wrote:
| The mistake Apple made was that they should have made them candy
| coated.
| mschuster91 wrote:
| It's not just Apple. Android is the same - good luck "catching"
| the scrollbar to read a long document in Chrome.
| smoe wrote:
| > I have a really hard time believing anyone would chose this as
| opposed to some design lead at Apple pushing a weird personal
| preference for tidyness on their entire user base
|
| 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.
| userbinator wrote:
| A modern smartphone has a much higher screen resolution than a
| typical desktop PC of the 90s. Yet you can't spare the few
| pixels needed for a scroll indicator, while the page content
| itself is full of useless whitespace like it often is?
| zepto wrote:
| The scrollbar is useless and distracting if you aren't using
| a mouse.
| ShroudedNight wrote:
| [Citation Needed]
|
| The scrollbar is the only way to scrub/seek through a large
| page's content efficiently.
| smoe wrote:
| I can dislike overuse of white space and scroll bars at the
| same time. Also I like my phones to be as small as possible,
| not the size of a baking tray.
|
| 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.
| root670 wrote:
| Messed up a college entrance exam form once that used a small
| <textarea> with several lines requiring a response. Thought
| there was only 2 or 3 questions when the remaining 5 or so were
| out of view. Without the scroll bar I had no way of knowing I
| wasn't viewing the entirety of the element. An example of bad
| form design, but still.
| jacurtis wrote:
| Wouldn't a "submit" button be located at the bottom of the
| form?
|
| 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.
| root670 wrote:
| The whole editable portion of the form was just a list of
| questions in a single <textarea> (you'd give your response
| under each one). Below the <textarea> was a submit button,
| so it was unclear that more text was in that element than
| was immediately shown. Obviously they should have created a
| proper form with separate inputs for each question.
| WorldMaker wrote:
| > It is usually clear enough that there is more to see below
| the fold.
|
| 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.
| TeMPOraL wrote:
| > _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._
|
| 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.
| stjohnswarts wrote:
| It makes sense on mobile, it doesn't really make very much
| sense on desktop. At least there's an option to make them
| always visible. One of the first things I do when I get on an
| apple machine. Along with turning off all the autocorrect junk
| in textedit.
| inetknght wrote:
| > _on mobile I certainly prefer having a bit more space than a
| always visible scrollbar._
|
| 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
| vidanay wrote:
| Modern UI is a seething cauldron of non-intuitiveness and
| undiscoverability.
| notriddle wrote:
| With mobile UI, that's kinda necessary. You don't have a
| whole lot of space to work with there. It's either really
| tightly packed touchscreen interfaces, or its horribly
| overloaded buttons ("when you're in the email app, press
| the Hang Up button to delete a message").
|
| There is no excuse for it on desktop except blindly
| imitating mobile UIs.
| kitsunesoba wrote:
| > With mobile UI, that's kinda necessary. You don't have
| a whole lot of space to work with there. It's either
| really tightly packed touchscreen interfaces, or its
| horribly overloaded buttons ("when you're in the email
| app, press the Hang Up button to delete a message").
|
| 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.
| simonw wrote:
| Mobile touch screens aren't really the issue here - the problem
| is mouse users on laptops, where they don't get to touch the
| screen to discover elements and they need to be able to
| interact with a visible scrollbar in order to scroll.
|
| I'm not a mouse user so this issue caught me completely off
| guard!
| Kranar wrote:
| Need to is pretty strong. My company did UX testing on scroll
| bars and the overwhelming majority of our users on laptop
| scroll using the keyboard or the scroll wheel (which on
| laptop is done using two finger dragging). I forget the exact
| number but it was less than 10% of users actually interact
| with the scrollbar.
| lhorie wrote:
| Would be curious to see the results controlling for page
| size and for type of task. For example, I normally don't
| use the scrollbar... until I do (because I'm scrubbing a
| huge page looking for some specific thing). And then I get
| annoyed that grabbing the darn scrollbar handle with a
| touchpad feels like a dumb peekaboo game.
| simonw wrote:
| It's that 10% I'm worried about!
| garmaine wrote:
| Not all mice have scroll wheels.
| munk-a wrote:
| Ah I see you don't work at CD Projekt Red - where they
| decided to hard-bind "use" in Cyperpunk 2077 to the
| middle mouse button which many mice have problems
| detecting due to prioritizing wheel smoothness over
| clickability. My partner had to borrow a different mouse
| to make it through the tutorial - after which it allows
| you to rebind the button.
|
| This is a very underappreciated point.
| alpaca128 wrote:
| The game doesn't let you rebind keys until after the
| tutorial? That's insane. So anyone who needs some
| unconventional control setup cannot play the game. Not to
| mention the tutorial is supposed to be the part that lets
| you test out the settings and familiarise yourself with
| the basics.
|
| 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.
| The_rationalist wrote:
| I am not interacting with the scrollbar but I regularly
| semi-incousoucly look at it as it give me crucial feedback
| of where I am.
| nonameiguess wrote:
| As a user of a laptop, the reason I use arrow keys to
| scroll is because of infinite scroll. Websites with that
| feature are effectively unusable via the scrollbar because
| it gets hijacked as you're in the middle of using it, move
| from 50% to 25%, and suddenly you're pressing down on 50%
| of double the original lines and get jerked past a quarter
| of the open entries in your feed. It's a terrible
| experience that forces you to use arrows or the scroll
| wheel as a workaround, not because that is an actual
| preference.
| bombcar wrote:
| Not interacting with it doesn't mean you don't use it - I
| glance at it to see if there is more content and where in
| it I am, even though I use the scroll wheel to move.
| SamBam wrote:
| Not only that, but seeing the scrollbar tells you that
| there is _more content that you can 't see_.
|
| 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.
| Kranar wrote:
| Yes, the solution we went with, which Apple also uses, is
| to display the scrollbar while scrolling.
| eptcyka wrote:
| For us, it was vocal Windows and Linux users that were
| asking for the scrollbars to be visible 100% of the time.
| naikrovek wrote:
| I would be one of those users.
|
| 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.
| jacobsenscott wrote:
| This is how chrome does it to. The first time you scroll
| a little you see how long the page is. You don't need to
| keep seeing something that doesn't change.
|
| 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.
| int_19h wrote:
| Is that how it works on macOS? If so, it's plainly
| 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.
| pseudalopex wrote:
| It's an option on macOS. I think the default is the same.
| chipotle_coyote wrote:
| macOS can be set to either behave the way you're
| describing when you click above or below the scroll
| thumb, or to navigate to that point in the document when
| you do that (e.g., click 80% of the way down the
| scrollbar and jump to the 80% point in the document).
| Jedd wrote:
| On GNU/Linux systems, at least, you middle-click to say
| 'go to this place'.
|
| I love my scrollbars, and I want them always visible. I
| don't use the mouse often, and I certainly don't want to
| have to use the mouse just to _see context_.
|
| Chrome implemented even worse nasties on GNU/Linux with
| scrollbars though, including forcing a snapback to
| original position if you drag the scrollbar but happen to
| move the mouse a few pixels too far left or right of the
| scrollbar [1]. Apparently that's how Microsoft Windows
| users do things. So now we have to as well.
|
| [1] https://bugs.chromium.org/p/chromium/issues/detail?id
| =377191
| TeMPOraL wrote:
| Scrollbars aren't meant to be clicked ever since the
| invention of the mouse wheel. Their primary job is to
| tell you that you _can_ scroll, because there 's more
| content. If you hide the scrollbar until you scroll, then
| users often won't scroll, because they won't know there
| is more to see.
|
| 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.
| pasc1878 wrote:
| Well hat is wrong vi wild look at the scrollbar to see if
| it was worth scrolling
|
| Or use the scrollbar to jump to the top, you are forcing
| me to do extra things
| Kranar wrote:
| The scrollbar is still there if you really want to use
| it, it's just not always visible. You can always move
| your mouse over to it and use it like always, but it's
| not going to appear unless it's being engaged in some
| way.
| naikrovek wrote:
| My eyes looking for the scrollbar counts as "being
| engaged" I would think. Do you hide text from a user
| unless it is being engaged?
| Kranar wrote:
| In many cases yes we do that too. Text is hidden until
| the user performs an action, types something in, or
| hovers/focuses over an element (think tooltip).
| naikrovek wrote:
| Why... (Tooltips I understand, as those are often
| something you only need a single time.)
|
| 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.
| Kranar wrote:
| For the simple reason that we want to present to the user
| only the information that is necessary for them to
| accomplish their immediate goal, and nothing more.
|
| 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.
| kybernetikos wrote:
| Do you show an affordance so that the user knows it's
| there if they want to use it?
| eckmLJE wrote:
| I think the point is that I don't necessarily know by
| looking at a page that there is anything to scroll to
| without seeing the scroll bar. I may land on a page that
| contains enough content "above the fold" that it appears
| that's all the content available, so I navigate away
| without scrolling down to discover the additional content
| below.
| Kranar wrote:
| It's possible the first time you go to a page or use new
| software that this is true, but for desktop productivity
| software that is repeatedly used on a daily basis, you
| usually come to identify multiple cues to know if there
| is more content, so hiding one specific cue in a specific
| circumstance won't inhibit your ability to use our
| software.
|
| 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.
| naikrovek wrote:
| This makes no sense to me. Why can't I look at the
| scrollbar(s) and see where I am in the document without
| scrolling? Why is it important that this information be
| hidden from me?
|
| 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.
| crazygringo wrote:
| > _Don 't hide things from the user that provide the user
| with information._
|
| 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.
| TheOtherHobbes wrote:
| The use case didn't disappear. If you're looking at a
| very long list - could be a document, could be a list of
| files - it's simply quicker to scan it by scrolling than
| by finger-gliding. Especially with the Magic Mouse.
|
| 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.
| basscomm wrote:
| > 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.
|
| 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.
| stjohnswarts wrote:
| I highly doubt that a scroll bar will overwhelm a user.
| Kranar wrote:
| You can do that to, moving your mouse over the window
| reveals the scrollbars, as does scrolling.
|
| 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.
| toast0 wrote:
| > You can do that to, moving your mouse over the window
| reveals the scrollbars, as does scrolling.
|
| 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?
| bakatubas wrote:
| In addition, it tells folks how much available content.
| And you can eyeball an action like "go to approximately
| 80% down the page."
| SilasX wrote:
| Don't worry, they're killing that too, with infiniscroll!
|
| 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 ...
| alpaca128 wrote:
| > less than 10% of users actually interact with the
| scrollbar.
|
| 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.
| Kranar wrote:
| To be honest most of our tests for UI components are
| fairly abstract which has pros and cons. The way we test
| UIs is by creating multiple prototypes that differ in
| various ways (hidden vs. not hidden scrollbar), giving
| the user time to familiarize themselves with the
| prototype, and then asking them to perform a series of
| tasks. For example after asking them to familiarize
| themselves with an abstract spreadsheet like software, we
| might ask them to find a specific data item and we check
| how they go about it. Or we might give them a form and
| ask them to fill it out and we see their usage. Or we
| might present to them a large set of changing data, ask
| them to mentally keep track of any numbers that change to
| be between 100 and 200, and after 2 minutes we ask them
| how many numbers did they see and measure that, then we
| change the UI (increase information density) and have
| them repeat it and see what the effect is.
|
| 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.
| markrages wrote:
| My mouse has no scroll wheel (it's a trackball) and there
| are some websites that I basically cannot use.
| dkonofalski wrote:
| If you're on a Mac with a trackball, the scroll bars
| would show up all the time the same way they would if you
| were using a mouse. Unless the trackball says it has a
| scrollable function to the OS, you'd see the bar.
| smoe wrote:
| I never used a trackball, but I would have expected there
| to be either a button on the mouse or some key you could
| hold to turn the ball into scroll mode?
| dingaling wrote:
| Some high-end trackballs have scroll rings but every one
| I've used for the past 30 years just has the standard two
| click buttons
| reaperducer wrote:
| _I forget the exact number but it was less than 10% of
| users actually interact with the scrollbar._
|
| What industry are you in where you can ignore 10% of the
| user base?
| throwaway894345 wrote:
| It would be crazy to ignore 10% of the user base--to
| provide them no means to use your product or some
| features therein. _However_ , it's not crazy to
| reprioritize their _preferences_. This happens all the
| time, and rightly so--if you can choose between
| delivering real functional value for a supermajority of
| users or cater to usability preferences of 10% of users,
| the former should win every time.
|
| 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.
| reaperducer wrote:
| _if you can choose between delivering real functional
| value for a supermajority of users or cater to usability
| preferences of 10% of users, the former should win every
| time_
|
| Not "every" time. I work in healthcare. I don't have the
| luxury of leaving ANYONE out.
| throwaway894345 wrote:
| I'm talking about preferences, not accessibility
| requirements. And healthcare is one of the most dramatic
| examples of giving no shits about preferences (I also
| work in healthcare, but on the provider side, not the
| consumer side)--my major hospital chain's web portal
| deliberately breaks on browsers (and versions) that it
| doesn't explicitly support. You certainly don't have to
| support scrollbars unless they're billed as an
| accessibility requirement.
|
| Healthcare is certainly a "fun" space, but catering to
| scrollbar purists isn't usually part of the gig. :)
| ShroudedNight wrote:
| > I'm talking about preferences, not accessibility
| requirements.
|
| 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?
| garmaine wrote:
| Nearly every industry. Pareto optimization implies that
| in almost all circumstances you get more bang for the
| buck investing in improving the experience of your 90% of
| users than the remaining 10%.
| rasz wrote:
| Not if the neglected 10% are the whales, or influencers.
| reaperducer wrote:
| That all sound very theoretical and tech-bubble.
|
| Try telling the sales people that their bonus checks will
| be cut 10% because you can't be bothered to build for
| every customer.
| smoe wrote:
| Seems a bit hypocritical to me, since I have hardly ever
| met a startup programmer/sales person that cares about
| the accessibility for disabled people of their product.
| Kranar wrote:
| Quantitative finance where information density is of the
| utmost importance and our interest isn't in getting the
| most number of users, it's retaining the most skilled
| users.
|
| 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.
| TeMPOraL wrote:
| But unlike Apple or most other replies in this thread,
| your case has a valid justification: omitting scrollbar
| _increases_ information density and usability, which are
| good things. I 'm also guessing you train new users, so
| that there's no possibility they won't realize some table
| isn't scrollable just because there's no scrollbar.
| mc32 wrote:
| Interesting!
|
| 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).
| Judgmentality wrote:
| > This goes against the rule of thumb where if 5% of
| attendees are vegetarian you serve vegetarian and
| omnivores will adjust to it
|
| 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.
| Kranar wrote:
| No because it's not as extreme as that. What you are
| talking about something that Taleb talks about which is a
| kind of minority rule [1] where for example kosher people
| will not eat food that isn't kosher, but non-kosher
| people will eat food that is kosher and so the end result
| is that Coca-cola, Pepsi, etc... all ensure their
| products are kosher even though only like 1 percent of
| their customers care about it.
|
| That is a very important principle in UI design and we
| certainly adhere to it and take it into account, but this
| has nothing to do with that. We're talking about
| scrollbars here, and unfortunately the people who prefer
| to always see a scrollbar are not going to ditch your
| product strictly on that one single criteria.
|
| [1] https://medium.com/incerto/the-most-intolerant-wins-
| the-dict...
| throwaway894345 wrote:
| If the business is "restaurants", but if it's
| "programming language conferences" I don't think
| vegetarians are going to start picking up C++ because
| PyCon didn't have a vegetarian option. No one is picking
| software based on scrollbar preferences just like no one
| is picking software conferences based on their dietary
| restrictions.
| 627467 wrote:
| I'm amazed that "less than 10% of users" is considered NOT
| a "pretty strong need" for ux.
| codemac wrote:
| > (which on laptop is done using two finger dragging)
|
| How did you determine this difference? I use a mouse _with_
| my laptop, because work only gives us laptops.
| stjohnswarts wrote:
| I think it's pretty rare to get a desktop these days. I
| know I've received laptops for my work for vendors for
| the past 12 years at least.
| stjohnswarts wrote:
| 90% of users don't use the scrollbar on laptop/desktop? I
| find that hard to believe unless your apps don't really
| need a scrollbar to see all the options.
| [deleted]
| efwfwef wrote:
| That is because most pages are short... Now when you deal
| with long pages you get infuriated if you can't use the
| scrollbar directly.
| rasz wrote:
| You didnt run eye tracking experiments tho, did you?
| Kranar wrote:
| We absolutely did. As I indicated in another reply, we
| develop quantitative trading software and we use our own
| software internally as a trading firm. While we're not
| perfect by any means, we take UX research quite
| seriously.
| pilif wrote:
| Has macOS changed the default setting for scroll bars? In the
| past, whenever a mouse was connected, it would switch to
| always showing scroll bars.
|
| At least on Catalina, the default (System Preferences >
| General) is still set to "automatically based on mouse or
| trackpad"
| zozbot234 wrote:
| I don't exactly like invisible scrollbars either (and it
| sucks that Gtk+3/Adwaita has adopted thin/invisible
| scrollbars in Linux) but modern mice have dedicated scroll
| wheels.
| brundolf wrote:
| I enable persistent scrollbars on any machine where I'm doing
| front-end web dev, so that I can better see what (some of) my
| users will see (not doing this has bitten me when it affected
| layout). But on my personal laptop I leave the scrollbars
| off. I virtually never drag them with the mouse these days
| and they just clutter my visual landscape; I'm glad the
| option is there to hide them (and dear god would they get in
| the way on the already-limited real estate of a phone
| screen).
| epriest wrote:
| I think mouse users don't generally suffer from this problem:
| by default, MacOS always shows a scrollbar in all contexts if
| you have a mouse plugged in to your computer.
| breakfastduck wrote:
| Only if it's a third party mouse
| pmontra wrote:
| A customer of mine was surprised to see some extra VMs in
| vSphere a few days ago. He never tried to scroll a list
| somewhere in the app and always missed the extra content
| because his Mac doesn't display the scrollbar. He has a
| laptop, so no mouse. I tweaked my Gnome desktop to always
| display a transparent scrollbar (only the outline is
| visible) so I could see that the list had extra elements.
|
| 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.
| chrisseaton wrote:
| > by default, MacOS always shows a scrollbar in all
| contexts if you have a mouse plugged in to your computer
|
| 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.
| banana_giraffe wrote:
| https://imgur.com/a/Z97cDc9
|
| 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.
| thebean11 wrote:
| I don't think so? I remember having to enable that feature
| neolog wrote:
| > I'm not a mouse user
|
| I'm curious about what tools you use to manage mouseless
| workflow?
| andylynch wrote:
| Probably a trackpad? They are ok with his kind of scrolling
| but mice are tricky, especially for horizontal movement
| martyvis wrote:
| I love my new Logitech MX Master 3 mouse with its thumb
| wheel
| smoe wrote:
| Not GP, but I pretty much only ever use the mouse/trackpad
| for testing from a user perspective or in some apps that
| don't have good keyboard support.
|
| 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.
| simonw wrote:
| Mac laptop trackpad - where double finger scrolling feels
| so natural to me I forgot that it could be harder with a
| mouse.
| mercurysmessage wrote:
| So you don't use a monitor either?
| mercurysmessage wrote:
| This site is way too fickle
| rhn_mk1 wrote:
| There's nothing stopping the mouse from dragging exactly like
| with the finger: click, move, release.
|
| In addition to that, most mice have a scroll wheel.
|
| I don't think I understand the issue you're referring to.
| plorkyeran wrote:
| My mouse's scroll wheel does not tell me that there's more
| content available to the right.
| simonw wrote:
| I've had two separate users tell me that they use a mouse
| and they can't my scroll tables horizontally without first
| scrolling to the bottom of the page.
| wongarsu wrote:
| I can scroll horizontally on my touchpad, but on a mouse
| it doesn't work. Horizontal scroll wheels are rare (the
| Logitech Master series has them, but that's about it).
| Most apps allow you to hold ctrl while using the scroll
| wheel to scroll horizontally. Some implement some kind of
| drag-mechanic, but that feels incredibly awkward with a
| mouse and is unusable with a touchpad.
| pseudalopex wrote:
| Don't most scroll wheels tilt horizontally?
|
| The Windows and macOS apps I tried zoomed or scrolled
| vertically with Ctrl.
| wongarsu wrote:
| > Don't most scroll wheels tilt horizontally?
|
| 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.
| wayneftw wrote:
| I like a UI that lets you scroll in every direction by
| clicking and holding the middle mouse wheel/button down.
| This is a more precise gesture than any trackpad can
| offer. Plus, with a vertical mouse you won't be killing
| your rotator cuff.
|
| 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.
| pseudalopex wrote:
| Auto scrolling is anything but precise in my experience.
| wayneftw wrote:
| It's a precise gesture, meaning that it happens when you
| want it to happen and not any other time.
|
| 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.
| nprescott wrote:
| As a specific example I routinely ran into forms that rendered
| like this (hidden scrollbars in three different browsers
| concealing content, though Safari rendered _just_ enough text
| that it might indicate there was more to see):
| https://nprescott.com/public/no-scroll-bars.png
|
| 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.
| smoe wrote:
| Ok, I haven't thought of this inline case since I haven't
| seen it in a while. But to be honest I'm not sure I would
| have noticed the scroll bars if those were full width
| elements. Personally I'd prefer some other visual indicator
| at the bottom of a cut off element or page.
| opk wrote:
| Scrollbars are terrible UI. You have to drag them in the opposite
| direction to the way the way you want things to move. How far you
| need to drag the bar to move a certain distance is dependent on
| the length of the whole document. In general, I think many
| mistakes were made on early GUIs that simply became entrenched
| and it is now hard for people to imagine them being any
| different.
|
| I long ago disabled scroll bars in my terminal and text editor
| and I never miss them.
| Rapzid wrote:
| > You have to drag them in the opposite direction to the way
| the way you want things to move
|
| In my mind I'm just moving the viewport down. I'm scrolling
| _down_ the page, not moving the page up.
| pnt12 wrote:
| Drag down to see the content below, up to see above. Total
| scroll height is 100% of the page and the bar will have an
| height equivalent to the portion of page you're seeing,
| allowing to predict from a simple glance how long a page is.
| I'd say it's quite beautiful in its functional simplicity.
| aylmao wrote:
| I usually have them disabled too, yeah. I think with modern
| cursor devices they become redundant-- you don't need a UI
| element to move around the document with the mouse/trackpad,
| because the mouse/trackpad usually has built-in scrolling with
| a wheel or gesture. I can see how in the past they were a
| necessary element though.
| jonny_eh wrote:
| They're useful for at least knowing what IS scrollable and
| how much more distance there is left to scroll.
| hieu229 wrote:
| I remember working on a panel, allows users to choose an element.
| Without visible scrollbar, it'd sometimes look like there is no
| more items.
|
| I think it is important to signal there is more content. And how
| much more to the end of the page
| ar_turnbull wrote:
| Designers call this a "false bottom" and try to make sure it
| doesn't happen, but it can be a near impossible task to make
| sure there's never one given variation in screen sizes /
| orientations.
|
| Often you see websites with hero areas and panels that fill the
| full screen on standard desktop sizes, but attentive teams will
| make sure something is cut off so that the page looks
| unfinished and people scroll.
|
| For what it's worth, I've also seen data that Apple users are
| more likely to scroll by default simply because they've made
| the scrolling experience so pleasant.
| hieu229 wrote:
| Interesting. Would you suggest to have the scrollbar visible?
| notriddle wrote:
| Doesn't help. Even huge Windows 95 scrollbars will reside
| in the users' peripheral field of vision, so they won't
| notice it and won't look at it.
| trefoiled wrote:
| Or maybe they're scrolling by default because they're used to
| not knowing whether or not content is scrollable?
| ar_turnbull wrote:
| Yup, that's possible too. Probably a bit of both TBH.
|
| Though again, from user testing sessions I've observed, I'd
| say that "not knowing whether or not content is scrollable"
| can be a universal problem, not limited just to Mac users.
| BitwiseFool wrote:
| One of Apple's core design philosophies is that when something is
| not in active use it should be hidden from view. Through this
| perspective it makes sense that they would hide scrollbars when
| the user isn't doing any scrolling.
|
| That being said, I would rather have it always be visible because
| I'm not that much of a minimalist and I still think that non
| active information has value at a glance.
|
| Edit: This doesn't mean Apple tries to hide everything that isn't
| in active use. It's a design convention, not a law.
| pseudalopex wrote:
| I'd call it a trend not a core philosophy.
| wk_end wrote:
| I wonder how long it'll be before the iconic global menu bar is
| gone from macOS when not in use?
| inetknght wrote:
| Browsers on mobile devices already do this and it's
| infuriating
| whichdan wrote:
| Having to scroll to get any controls to appear is such a
| mediocre UX
| adolph wrote:
| I just tap the address part of the top bar and it
| appears. This is different from a top of screen tap which
| scrolls to the top.
| whichdan wrote:
| huh, I never realized tapping the address was separate
| from tapping the top of the screen
| inetknght wrote:
| > _I just tap the address part of the top bar and it
| appears_
|
| Yet another unintuitive undiscovered feature because
| Apple decided to change 20 years of best practices
| tomku wrote:
| That's already an option you can set, since at least El Cap.
| tokamak-teapot wrote:
| I would guess the reason that auto-hide is not switched on
| by default is that it's jarring and ugly to have it appear
| and disappear.
|
| With scrollbars, auto hiding /re-appearing isn't even
| something I notice happening.
| prionassembly wrote:
| This was possible back in 10.5 and 10.6 already.
| FigmentEngine wrote:
| i don't have a mac - but a scroll bar does two things, allow
| scrolling and show scroll position.
|
| does the mouse cursor disappear when not being moved? does the
| text in a terminal disappear when not being edited?
|
| seems like dual function elements where one function is
| indication should be exempt...
| robin_reala wrote:
| On macOS the convention is for the mouse cursor to disappear
| when you start typing.
| doodpants wrote:
| I miss this behavior all the time when using Windows. I
| recently discovered that Windows actually has a setting to
| enable this behavior, but it's up to each individual
| application to check for the setting and implement the
| behavior. And as far as I can tell, literally no one does.
| [deleted]
| godshatter wrote:
| On a similar note, I get annoyed with how Excel won't show
| the highlighted row or cell when moving focus to another
| window. Sometimes I want to look at that specific row while
| using another program, and it's hard to find the data that
| was just highlighted when that disappears. I don't for the
| life of me understand what problem that behavior is supposed
| to help with.
| inetknght wrote:
| > _when something is not in active use it should be hidden from
| view_
|
| My mouse isn't over it or clicking on it but it's still being
| actively used.
| [deleted]
| Descon wrote:
| This explains why I can never find anything in XCode...
| heavyset_go wrote:
| It also explains why discoverability on iOS is incredibly
| poor for those who haven't used it often or before.
| BitwiseFool wrote:
| I'm glad I'm not the only one. I feel like I'm always
| jockeying tabs and panes looking for buttons to click. I
| waste so much time doing this.
| [deleted]
| throwaway4good wrote:
| They are converging their desktop ui towards their mobile ui.
|
| The scrollbar is learned functionality; if users know it, they
| know what to do. If you haven't seen it before, then it is not
| obvious and it is not an obvious way to interact compared to a
| scroll gesture on trackpad or a touch screen.
|
| Apple can see that more user will be coming that are used to
| mobile os'es than users experienced in classic desktop ui's.
|
| Apple is correct in hiding the scrollbar.
| tablespoon wrote:
| > Apple can see that more user will be coming that are used to
| mobile os'es than users experienced in classic desktop ui's.
|
| Modeling a desktop UI off of a mobile UI is just as dumb as
| modeling a mobile UI off a desktop UI. Each platform has
| totally different constraints and strengths, shoehorning one
| into the other will always be a failure.
| disposekinetics wrote:
| I think another part of this problem is that websites are aloud
| to change scroll bar colors via CSS. The scrollbar is a UI
| element, not a part of the page and it adds to the problem.
| VectorLock wrote:
| I think the scroll bar getting smaller is a by-product of it
| being less prevalent as a usable control since swipe and multi
| touch scrolling is the fashion now.
| timvdalen wrote:
| Is this the correct link? The text appears in this thread, which
| has much more context:
| https://twitter.com/simonw/status/1369705219110498304
| makecheck wrote:
| Also part of a trend to add more "hover and wait" elements
| pointlessly:
|
| - Can't see scrollbar without hovering and waiting.
|
| - Can't see folder drag icon in window title without hovering and
| waiting.
|
| - Can't interact with notifications without hovering and waiting.
|
| - Can't see full menu of options on Full Screen window button
| without hovering and waiting.
|
| Dear Apple: this is a _fundamentally backwards_ design trend that
| creates _major_ productivity hits. These were arbitrary changes
| that made things harder to use. In short: there was no "design"
| happening here, it was just "fiddling".
| userbinator wrote:
| The worst part is when some app implements that poorly, so you
| end up with a scrollbar that _disappears while you 're still
| hovered_, causing your click to fall through and hit something
| you didn't want.
| ectopod wrote:
| Or you're trying to select text from the last line of a text
| file but the horizontal scrollbar keeps popping up and
| getting in the way. This absurdity happens in the default
| text editor in Mint Cinnamon.
| divbzero wrote:
| One of my pet peeves with the HTML title attribute is that it
| requires "hover and wait" to view the content as a tooltip. MDN
| [1] links to a wonderful guide [2] on how to avoid tooltips
| whenever possible and make them accessible if needed. For some
| reason, the accessible tooltips require custom implementation
| and is not the default browser behavior for the title
| attribute.
|
| [1]:
| https://developer.mozilla.org/docs/Web/HTML/Global_attribute...
|
| [2]: https://inclusive-components.design/tooltips-toggletips/
| efwfwef wrote:
| Oh my... these macos notifications are driving me crazy, you
| can't just go and close them.
|
| I think we should create some rules:
|
| - if there's an animation/wait time to get to a UI, it's crap
|
| - if users have to be fast to get to a UI, it's crap
| Toutouxc wrote:
| > Can't see full menu of options on Full Screen window button
| without hovering and waiting.
|
| So it's not just me! Correct me if I'm wrong but I don't think
| this is used anywhere else in macOS. It's obviously a button
| and it opens a normal vanilla macOS list-menu (don't know the
| term they use) without you clicking it. The hidden folder icon
| for dragging is a bit annoying, but this infuriates me for some
| reason.
|
| I liked the Mavericks fullscreen button the most, but even the
| click-and-hold solution was better than this crap.
| Klonoar wrote:
| A weird but possibly relevant question: is this more of a factor
| for mouse users on macOS?
|
| e.g, I use a magic trackpad... it feels very natural to swipe on
| anything and expect it to move a little (or a lot). You lose this
| interaction with a mouse, or it's not as simple to do.
|
| I actually very much dislike scrollbars after being trackpad only
| for some years.
| squarefoot wrote:
| Not just Apple. Windows 8 and beyond horrors aside, I have this
| friend of mine to whom I already installed three Linux machines
| in the past (1 x XFCE and 2 x Mate) who was 100% satisfied with
| them. Having brought a new faster laptop for reinstall, I wanted
| to give him something prettier which wouldn't slow down. Turned
| out he came back frustrated because of the asinine way KDE Plasma
| desktop menus behave, literally hiding things from view based on
| mouse position and not following a click, which is against every
| rule of good UI programming.
|
| Please stop following bad designs just because they're new and/or
| come from big names; Windows XP UX still beats everything out
| there both in usability and intuitiveness. If users have to read
| a manual even to do the most basic things with a new user
| interface, I call it a failure.
| quacked wrote:
| When I was 8-10, I absolutely sailed through new programs in
| Windows XP. Now that I'm 25, every new thing I want to do in a
| "new" app (Discord, Slack, Facebook, Zoom, etc.) is precluded
| by "Google, how do I..."
|
| There's so little conceptual integrity in modern applications.
| I can't stand it.
| jacurtis wrote:
| Since you mentioned Discord and Slack together here, I have
| to point out that one of the worst design choices a company
| can make is hide CRITICAL interaction elements behind a hover
| state.
|
| Slack and Discord are both incredibly guilty of this. Lots of
| important things that you do everyday is only visible to the
| user if they are hovering over a certain element on the page.
| For some of us this isn't as big of a deal. For me, I tend to
| move my mouse around as I investigate a UI and try to figure
| out how to do something.
|
| But when I watch my mom interact with a website, she works
| entirely differently. For example if she wanted to edit a
| message, she wouldn't naturally hover over the message and
| see the gray pencil appear on the far right of the message in
| a light gray bubble, and then think to click on the pencil.
| She is looking for something that says "edit". And she will
| stop, lean back, take her hand off the mouse, and start
| looking around with her eyes to the various parts of the app.
| She will NEVER find the edit button. Even if she is hovering
| she would probably see the pencil and not have it register
| that the light gray pencil means, "edit".
|
| Furthermore, neither of these apps like to use "buttons". So
| when you do various things like editing a message or writing
| a room description, and stuff like this, they just assume you
| will press the ENTER key. There is no button to save or
| submit. In discord, light gray text shows up on the bottom
| that says "Press ENTER to save", but many people won't notice
| that.
|
| Zoom is equally guilty, but not as bad. Zoom seems a little
| more logical in most places and they tend to use brighter
| colors on buttons and messages as opposed to Slack and
| Discord that want to use 50 shades of gray (and not in the
| sexy way) as the color palette throughout their app. Although
| I will admit, about once a week I forget how to leave a Zoom
| call. Zoom makes it far too complicated to do something that
| every Zoom user will do on every Zoom call, which is
| inevitably leave the room.
| passivate wrote:
| Can someone explain how this works? For e.g. Can an app choose to
| have always-visible scrollbars?
| gowld wrote:
| My Mac shows scrollbars, because I toggled the preference
| setting.
| simonw wrote:
| Some more context on this: the actual problem I'm trying to solve
| here is displaying "wide" tables in Datasette - for example this
| one: https://global-power-plants.datasettes.com/global-power-
| plan...
|
| I want the table to scroll horizontally so that the map can stay
| visible.
|
| The two complaints I've had from users about this are:
|
| 1. They didn't realize it could be scrolled, so they missed out
| on the extra columns. I'm probably going to fix this using some
| kind of visual indication - maybe a shadow.
|
| 2. Mouse users have to scroll to the very bottom of the page in
| order to find the horizontal scrollbar. I'm looking at adding a
| duplicate scrollbar at the top of the table using the trick
| implemented by
| https://github.com/avianey/jqDoubleScroll/blob/master/jquery...
| (re-implemented not to depend on jQuery)
|
| It's really frustrating how tricky this is.
| zo1 wrote:
| Mouse users can't even scroll to the bottom of the page because
| the entire-width map hijacks the scrolling when you scroll over
| it.
| widforss wrote:
| Using the horizontal scroll wheel on my mouse is oddly slow on
| your site. Do you know why that is?
| synthmeat wrote:
| WRT #1, we've used a shadow and users seem to like it.
|
| https://www.livecoinwatch.com
| simonw wrote:
| That's a really nice example, thanks!
| pseudalopex wrote:
| It's very subtle. I wouldn't have known what it was.
| robocat wrote:
| If you decide to use a second scrollbar:
|
| 1. Consider using Excel style sticky headers and sticky left
| columns to give users column and row headings. Here's a proof
| of concept: https://output.jsbin.com/qiqozum (sorry my example
| isn't larger than viewport like your example, but it can be
| made to work with a large scrollable body on a smaller screen).
|
| 2. You can make the second scrollbar position:sticky so that it
| sticks to the bottom of the viewport (I think your idea of
| putting it at top would confuse users)
|
| 3. You can measure the "thickness" T of a scrollbar by looking
| at the difference between content height and container height
| for a div with a forced scrollbar at bottom.
|
| 4. I think you can get the second scrollbar to hide using CSS
| when the real scrollbar comes into view. You could use a
| container div with overflow:hidden and a negative margin at the
| bottom of height T, and put the scrollable div within, with an
| extra margin at the bottom of of it if T. Put the
| position:sticky scrollbar inside the container div. Edit:
| IGNORE this bullet point - it's only relevant for small
| scrollable area, not whole body viewport.
|
| 5. You now run into the problem where the user doesn't know
| they can scroll vertically to see more. Perhaps add an extra
| 20px of transparency below the sticky scrollbar, perhaps a
| little dark opacity, so user can see scrollbar is floating and
| that there is more data.
|
| Things to watch for:
|
| 1. NEVER use the fake scrollbar as a 100% replacement for a
| real scrollbar... they are janky (JavaScript cannot provide
| smooth scrolling) and there are many many ways for the
| scrollbar to not show properly and screw the user over.
|
| 2. Scrollbar thicknesses can change dynamically. You can detect
| this as an event, but it isn't necessarily simple.
|
| 3. Page zooming can cause troubles. Pinch zooming can cause
| troubles - needs lots of testing on touch laptops or Windows
| tablets.
|
| 4. Only Chrome, Safari and Firefox engines. Microsoft Edge
| before Chrome transplant is your enemy - nothing will work
| right. You can get everything above to work well in IE11
| including jankfree sticky column and row headers, by using
| JavaScript, but it takes tricks that are not well known.
|
| 5. Test in Safari on Mac by switching on scrollbars in
| preferences.
|
| 6. Take a _lot_ of care to ensure the second scrollbar never
| occludes the real scrollbar (bottom or right) - there is a risk
| the user can no longer scroll.
|
| 7. I haven't had much experience using a fake scrollbar to
| scroll the viewport as needed by your example. I am fairly sure
| I am missing a couple of difficulties because my experience is
| mostly for scrollable elements rather than a scrollable body,
| and I know there are some troublesome differences between the
| two.
|
| 8. Keeping the scrollbar synchronised to content is not always
| as easy as you might think. Use non-blocking onscroll event so
| jank is not introduced.
| elliottkember wrote:
| I think you might need a visual hint. A little flag or button
| that says "more data this way".
|
| Sideways scrolling is so rare on the web that it might just be
| easiest to add a little affordable at the right of the screen.
| pasc1878 wrote:
| Oddly enough there is a commonly used standard UI widget that
| shows exactly this.
|
| It is called a scrollbar
|
| Sideways scrolling is common. That might be because I need
| large fonts and so zoom pages
| ar_turnbull wrote:
| If you can, try to cut off the content as the visual indication
| at the edge of the page. You might try bumping up the contrast
| of the headings as well so that the cutoff is more obvious.
|
| Not quite as complex a dataset, but the NHL + MLB have done a
| reasonable job of making their various stats & standings tables
| responsive: https://www.nhl.com/standings/2020/division
| philsnow wrote:
| re #1 that's one of my pet peeves on ios, but for vertical
| scrolling components.
|
| Because there's no affordance that says "there's more
| scrollable content down there!", I never know if the last item
| that I can see is actually the last item or if there's more. If
| the height of the scroll area is nearly exactly a multiple of
| the height of each item in the area, these can hide all over
| the place, so I end up trying to swipe up on tons of things
| that aren't actually scrollable.
|
| ios has all kinds of affordances for accessibility ("button
| shapes" and "on/off labels" as two examples that actually
| change how apps look), why not one more toggle that makes
| standard scrollable views end with a fade-out effect or
| something if there's more stuff in that direction?
| SloopJon wrote:
| Even with scroll bars always visible, as they are on my system
| (Firefox on macOS 10.15), I can't see that there's a horizontal
| scrollbar until I go down several pages.
|
| If I change from "Always" to "When scrolling", the only way I
| can make the horizontal scrollbar appear is to start scrolling
| by pressing my mouse wheel to the side. It's otherwise utterly
| invisible, even when I hover over that region. Edit: the table
| doesn't initially have focus, but if I click it, I can also use
| the arrow keys.
|
| When I wrote a page to display a very information-dense table,
| I tried very hard to avoid horizontal scrolling. I abbreviated,
| used icons and colors, and allowed wrapping. You're
| implementing a general purpose utility that can have
| arbitrarily many columns, so you can't really control that.
|
| I'm not much of a web dev, so I may be off base, but I think
| part of the problem is that you're mixing a page-wide vertical
| scrollbar with a div- or table-specific horizontal scrollbar.
| j-pb wrote:
| Sorry but horizontal scrolling is just abhorrent UX for
| everything but maps, and I'd argue that that interaction is not
| actually perceived as scrolling by the user.
|
| I'm glad that it hidden scroll bars make that more
| inconvenient, feels like a win win situation to me.
|
| As for your datasette use case: Why not have explicit buttons
| to move between colums at a time, or the ability to toggle and
| reorder individual columns, so that they become more wieldable,
| or both.
| rhn_mk1 wrote:
| > horizontal scrolling is just abhorrent UX for everything
| but maps
|
| Why? It seems to get the job done in spreadsheets.
| j-pb wrote:
| Compare the scrolling behaviour of OPs example table, with
| the scrolling behaviour of Excel or Numbers.
|
| With OPs version you get immediately lost in the grid
| because the headers don't float along with the scrolled
| view, which makes this best case useless, worst case
| harmful (e.g. confusing important columns).
|
| If you have thousands of columns you're not going to do
| manual eyeballing of values anyways, you'll lose track
| because scrolling is not accurate enough, so you might as
| well represent rows as documents which densely shows the
| fields/columns and values, and which can then in turn be
| shown in a vertically scrollable list.
| notriddle wrote:
| If you have both horizontal and vertical scrolling,
| gesture-scrolling systems (like touchscreen and two-finger
| trackpad) behave weirdly. It either wobbles back-and-forth,
| or it locks to a particular direction.
|
| Also, mice with physical scroll wheels can only scroll in
| one direction.
| simonw wrote:
| I'm planning on adding the ability to toggle columns, but the
| whole goal of Datasette is that you can point it at ANY data
| - including some crazy government data CSV file with a
| hundred columns in it - and start exploring it without having
| to do any customization first.
| reaperducer wrote:
| _Sorry but horizontal scrolling is just abhorrent UX for
| everything but maps_
|
| Sounds like you've never had to build anything where people
| want to compare a set of three or more choices.
| j-pb wrote:
| It's exactly because I had to build such things.
|
| You can have pretty much as many things as you want in one
| dimension, but the other dimension has to be limited in
| turn, or people will get lost and confused.
|
| If your users start to hold a piece of paper up to their
| screen to not loose their row you've failed as an UX
| designer.
|
| Give them the ability to make sub-selections, and to
| reorder data. And compress the rest into interdependent
| interactive charts where selecting a data point in one,
| highlights the corresponding values in the others.
| reaperducer wrote:
| That's awesome that your suppositions work for your use
| case. But they are not universal truths.
|
| Try comparing five Medicaid plans, in a method that is
| easy for people with an eighth-grade reading level to
| understand, that will also pass the scrutiny of three
| different government agencies.
|
| Sub-selections, reordering data, and all the other things
| you list won't matter a whit.
| j-pb wrote:
| Neither will an unlabeled grid with data values that you
| scrolled into and are lost in.
|
| That MIGHT actually pass government scrutiny, but if
| anything that's a good metric for how bad government
| approval is of a metric.
|
| Also we're not talking about 5 columns here, but about
| 50.
|
| Good luck comparing 50 medicaid plans by continuously
| scrolling back and forth between them.
|
| How does that not immediately evoke a cartoon-ish
| ridiculous scene in your mind?!
| wlesieutre wrote:
| I'm in Firefox on Windows and would not have noticed that the
| table is scrollable either.
|
| The horizontal scrollbar is way down below row 100 (about 6
| pages of vertical scrolling to get there), and since column
| sorting is set at the top you don't go down to the bottom of
| the table unless you're looking at it thinking "I wonder what
| dam has the 100th largest capacity?"
|
| Maybe different for someone taking a serious look through the
| data, but for anyone getting a glanced impression off of it
| they're going to sort by X and look at the top 10-20 rows.
| simonw wrote:
| Yeah that's the exact problem I'm trying to solve.
| crisnoble wrote:
| If you constrain your table with respect to the viewport,
| with overflow scroll, your horizontal scrollbar will show
| at the bottom of the screen if enabled (similar to how
| google sheets does it). Either way having a shadow to
| indicate more content this way on the right side would
| indicate to touch users and scollbar hiders that this
| element can be scrolled. If you pin your header row in
| place your table will become a lot more scannable.
| [deleted]
| wlesieutre wrote:
| Found this for a non-jquery top scrollbar:
| https://jsfiddle.net/nsG5w/3/
|
| No license, but looks simple enough to implement.
|
| As for the Mac people with no visible scrollbars, I don't
| know if there's a fix. Maybe you just rely on 95% of them
| being on trackpads where they're much more likely to notice
| a horizontal scrolling table than people with scroll
| wheels.
|
| I wish we had some standard but more compact UI affordance
| to indicate scrollable content without needing a scrollbar.
| Like an ellipsis for truncated text. But touchscreen phones
| have definitely driven user behavior to "just try scrolling
| everything, if it doesn't scroll that's how you know it's
| not scrollable."
|
| Not great for scroll wheels, and I'm sure there are plenty
| of phone users who have issues with this too. Not everybody
| is constantly touching everything to see if it works. But
| the only thing you'll see is sometimes there's a line of
| text that's only half visible. And with the amount of
| whitespace everywhere lately, that's not even likely to
| happen most of the time.
| masswerk wrote:
| Maybe, something like `max-height: 90vh;` helps. (So, without
| interfering too much with the browser UI, a user should
| eventually see the entire viewport of the table. It even
| provides some extra space for a textual hint, which is
| obviously, how we do usability nowadays.) Moreover, the table
| head may be a classic use case for fixed or even sticky
| positioning inside a scrollable element.
| dbetteridge wrote:
| Can you paginate your tables to fit the window height?
|
| That would obviously fit less data by default, but allows
| people to see the scroll bar and you can just offer an option
| to increase the number of rows (at the bottom of the table)
| vmception wrote:
| Articles and papers should have dates and an indication of how
| long it is
| c-smile wrote:
| I'd like us to look on this from different angle:
|
| Layout of visible scrollbars, to be precise scrollbars that take
| space off scrollable, may oscillate - not always has a determined
| solution in case of `overflow:auto;`, steps:
|
| 1. You start layout width without any scrollbars to determine
| height of the content;
|
| 2. If content height exceeds height of the scrollable you will
| need to show v-scrollbar, and so goto #1;
|
| 3. While reducing available width at #2 you may have content
| width overflow width of scrollable container minus v-scrollbar,
| so you need to show h-scrollbar that reduces available height,
| and so goto #2;
|
| There are conditions at particular content/container sizes and
| layout algorithms when the solution oscillates.
|
| So `overflow:auto;` (show scrollbars only when needed) is a)
| quite expensive (layout happens multiple times) and b) not that
| easy to implement.
|
| Floating scrollbars that appear on top of scrollable content and
| so do not take screen space are technically better.
| shaggyfrog wrote:
| This has always drove me bananas, too. I still have 10.14 but
| `defaults write NSGlobalDomain AppleShowScrollBars -string
| "Always"` has worked for me for years now. Does it work in 10.15?
| naikrovek wrote:
| I really think that Windows 2000-era Windows Forms had the user
| experience nailed perfectly. It wasn't the prettiest UI paradigm
| ever, but it was the most functional and easiest to teach.
| Nothing was omitted, and the user was shown everything they
| needed to see in order to get a complete idea of the state of the
| application.
|
| 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.
| systemvoltage wrote:
| This is just the symptom of a larger, deeper and more insiduous
| problem - design education, short-term corporate targets,
| discipline, anti-functionalism, celebration of aesthetics,
| marketing overreach, lack of rigorous criticism and unwilling
| to convince users.
|
| 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.
| core-questions wrote:
| > celebration of aesthetics
|
| 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....
| ShroudedNight wrote:
| To the ether: Pardon my ignorance, but is there something
| obviously wrong about the parent comment? It comes across
| as reasonable to me, but seems to be fairing poorly in the
| opinions of others.
| core-questions wrote:
| I post dumb things people don't like in other threads and
| usually they go into my comment page and downvote
| everything else I've said. Comes with the territory,
| doesn't bother me
| trilinearnz wrote:
| Very interesting insights here - thank you. I think you
| could write an extended version of this post as a very
| engaging blog article (maybe with some example
| screenshots), if you were ever so inclined :)
| [deleted]
| trilinearnz wrote:
| Agreed. Steve Jobs once expounded the notion of
| 'discoverability' with the Macintosh UI - in particular the
| use of drop-down menus - which was a response to the keyboard
| shortcut-heavy applications of the IBM ecosystem.
|
| 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.
| hootbootscoot wrote:
| Don't forget "dark patterns" that serve deliberate goals.
| It's often perfectly functional for a company to force you
| into certain courses of action due to apparent mistakes that
| aren't.
| entropicdrifter wrote:
| "Oh dang, where's the opt-out of cookies button?"
| karaterobot wrote:
| I agree with a lot of what you say, but let's take a step back
| and acknowledge that, on the whole, desktop and mobile UI
| design has improved a lot in the last 20 years.
|
| 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.
| kibwen wrote:
| How do you feel about the infamous Microsoft Office ribbon?
| Compared to standard 2000-era UI design it made a lot more
| things visible (by taking things that were "hidden" in
| File/Edit/etc. dropdown menus and making them into persistent
| toolbar buttons), but that didn't keep it from being maligned
| at the time.
| TeMPOraL wrote:
| I like it when I'm using my sidearm in tablet mode, because I
| get big touch targets (I learned to appreciate the ribbon in
| Explorer in particular).
|
| 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.
| im3w1l wrote:
| That's now how I remember it. Before the ribbon you had a
| huge amount of tiny icons on toolbars, then came the ribbon
| and replaced with a small number of big icons. Many tools are
| hidden, because they are in different ribbon-tabs from the
| one you currently have open.
| minikites wrote:
| You didn't ask me, but I think the ribbon is brilliant and
| very effective.
| birdman3131 wrote:
| The ribbon is both good and bad. For low to medium skilled
| users it increased their ability and speed.
|
| 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.
| chronogram wrote:
| I personally love that ribbon. It's so functional. It's like
| a tree-based menu.
| RHSeeger wrote:
| They weren't "hidden" in the menus. It's always been very
| clear that commands live in the menus. They weren't up front
| and center, but you knew where they were if you wanted them.
| The fact that there is a menu bar makes it very clear that
| there's more you can do.
|
| 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.
| bombcar wrote:
| The ribbon changes where things are depending on how big it
| is! Even reading the instructions online is embarrassing; I
| do love the fact that Office for Mac still has a working
| normal menu bar in addition to the ribbon.
| lambda_obrien wrote:
| I love the Office 'ribbon' because it has icons whereas the
| menus don't. It makes it very easy to quickly pick the tool
| I need by muscle and visual memory. Also, MS does icons and
| design well, IMO, because they don't make everything too
| flat or hidden, they give very intuitive indications of
| mouse position and such, like with a slight popping-up of
| the button or whatever. With the menus, I have to engage my
| language part of my brain rather than just looking for an
| icon and clicking it.
| trilinearnz wrote:
| A big beef a lot of users had (myself included) was that
| those menus were so convoluted it was difficult to find the
| appropriate option for a given scenario. Made worse by the
| modal nature of the UX: upon clicking an option which was
| deeply hidden, the menu 'breadbrumbs' would immediately
| disappear.
|
| 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).
| qayxc wrote:
| It's a a double-edged sword really.
|
| 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.
| qyph wrote:
| The problem I always had with it is that the little symbols
| are inscrutable, and mouse-over for a description is
| inconsistent. Because of this I found the ribbon far less
| discoverable than text based menus.
| trinix912 wrote:
| I generally like the ribbon, the only thing that bothers me
| is the occasional little arrow in the lower right corner
| because it's kinda hard to spot.
| WalterSear wrote:
| I hated it, and still do. The cluttered mess of icons makes
| it harder to find things rather than easier.
| Reason077 wrote:
| System Preferences > General > Show Scroll Bars > _Always_
|
| It's right there, people!
| chipotle_coyote wrote:
| I'm puzzled by this, too. But I _think_ Willison (the linked
| tweeter) is complaining about a web-specific manifestation of
| this, when a web page has a sub-section that needs to scroll
| independently of the larger page that it 's contained within.
| (The list of messages in Gmail is a good example of when this
| is useful.) Having said that, though, I'm not actually sure
| under what conditions his lack of scrollbar is occurring.
| Personally, I've noticed this can be more of an issue on iOS
| devices, where sometimes the contents of a <div> are meant to
| be scrolled, but it's almost entirely nondiscoverable due to
| iOS's lack of scrollbars.
| naikrovek wrote:
| That doesn't work in the browser, which is what the tweet
| linked by this story is discussing.
| kingnothing wrote:
| In which browser? I have scrollbars in Safari, Firefox, and
| Chrome from either that setting or an in-browser setting.
| weaksauce wrote:
| That works to show it in safari/chrome/firefox for me...
| did they disable this in recent versions of the OS?
| robotresearcher wrote:
| I'm reading in Safari with that setting on 'always' and I
| see the scrollbar handle right there next to your comment.
| naikrovek wrote:
| Then tell that to the user in the linked tweet. I'm sure
| they would be happy to know you've solved their problem.
| pfortuny wrote:
| And the philosophy of having them off "by default "? That is
| the issue here.
| zepto wrote:
| They coincided with using trackpads by default on the
| desktop.
|
| 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.
| TeMPOraL wrote:
| Scrollbars aren't visual noise, they are an indicator
| that tells you a) that there's more stuff than fits on
| the screen, b) where you are spatially, in relation to
| all that stuff, and c) how much more stuff there is,
| relative to what's shown on your screen. Hiding them
| leads to users often not figuring out that there's more
| stuff, and scrolling will get them there.
| chipotle_coyote wrote:
| IIRC, the default setting for "Show scrollbars" is
| "Automatic based on mouse or trackpad": if you have a mouse
| connected, they're always visible, while if you have a
| trackpad, they only show up when you're scrolling. (There
| is no "never visible" setting.)
| cybrjoe wrote:
| | 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
|
| 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.
| btach wrote:
| I don't quite disagree, but yet I do. A toolbox organizes
| your tools so you know exactly where they are (and take much
| less space). You may not see the tools, but each drawer may
| have a label (should you choose to slap one on) fully visible
| at any time. That they are not transparent is an effect of
| their material. A transparent toolbox seems like it would be
| more difficult to construct with the same strength and the
| same inexpense.
| [deleted]
| Flow wrote:
| Windows 10 in dark mode is just horrible. Overlapping windows
| are really hard to see where one begins and another ends.
|
| 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.
| bluedino wrote:
| Dark mode is a horrible trend that I can't wait to see go
| away.
| johnmaguire2013 wrote:
| Dark modes don't need to be implemented horribly.
| brokenmachine wrote:
| I love dark modes for every app - but this is just bad
| implementation.
|
| There's no reason dark mode should make things invisible.
| keyringlight wrote:
| Personally I found that a general issue with windows 10 when
| they reduced borders down to a 1 pixel line. The invisible
| zone to 'grab' it with the cursor is still a bit larger, but
| the actual graphical representation of "this is the window"
| is practically nothing.
| patrickthebold wrote:
| I got a new macbook pro for a new job. I had to use hdmi since
| I didn't have a usb-c to displayport adapter. I wanted to check
| the refresh rate. You have to hold 'option' when you click one
| of the radio buttons, and then you have to click a check box
| with some label about 'low resolution modes' to see the refresh
| rate option.
|
| Litterally impossible to do without googling.
| FireBeyond wrote:
| Apple just doesn't care if you're not using a ProDisplay XDR.
|
| 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.
| tonymet wrote:
| I agree. Designers are favoring "looks nice" over usability. It
| takes multiple taps to even show the UI, then taps to
| manipulate it. With tap-failures, you're talking 5-6 taps to
| get work done on the device.
|
| 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
| int_19h wrote:
| And the funny thing is, Win32 circa 2000 was basically just
| well-polished IBM CUA.
| makecheck wrote:
| To this day I am embarrassed to discover _entire options_ in
| apps I had been using for ages, that were hidden behind
| invisible scroll regions. I even reported a bug once because I
| thought a feature was _removed_ in an update, when in reality
| it was just a stupid default clipping issue with no visible
| scrolling.
|
| 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_.
| jonplackett wrote:
| We were doing one of those online escape rooms the other day
| and I had this problem. We couldn't figure anything out and
| then finally realised the invisible scroll bars were hiding
| the fact there was A LOT more clue!
| dimitrios1 wrote:
| Needing that many controls to begin with is the real failure.
| tablespoon wrote:
| > Needing that many controls to begin with is the real
| failure.
|
| 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.
| naikrovek wrote:
| I agree. I have a UHD monitor and I get _angry_ when I
| have to scroll to read the second sentence on a web page.
| That is not an uncommon thing anymore, and it sickens me.
| zarq wrote:
| I get angry when there's not a single letter on the first
| page of a web page, just a lead graphic.
| gumby wrote:
| The modern day splash screen. Pathetic.
|
| 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.
| FpUser wrote:
| I feel exactly the same. I stare at full screen picture
| of some political correctness and then to have scroll all
| the way to find standard links where I can find anything
| related to real info.
|
| 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.
| justapassenger wrote:
| It'd be cool if real world was simple. Until that happens,
| apps that operate in it need to be very often complex.
| pfortuny wrote:
| The adoration of minimalism has become the curse of user
| interfaces. Design not for the user but for beauty.
|
| Needless to say, controls of dangerous machinery stay clear,
| loud and accessible.
| toiletfuneral wrote:
| "don't hide UI elements from the user"
|
| ok but Windows hides everything in right click which is
| actually not great at all
| silicon2401 wrote:
| I agree about older Windows UI. In my opinion, the worst is the
| increasing abstraction of UI elements like icons. Floppy disk
| and folder icons may be small, but if you can see them then
| it's easy to relate to the real world. It's been difficult
| explaining modern smartphone icons to my >80yo grandma after I
| got her a phone, when everything is a flat and abstract symbol.
| ptsneves wrote:
| Do you think that the problem is your grandna is 80 year old?
| I am in the early thirties and cannot understand the Google
| Drive and Google photos icons in my phone. Even the Gmail
| icon is so similar to all other Google icons I actually need
| to think hard about what I want, to press the right one.
| Often I just stare at the icons for 5 seconds. It used to be
| obvious. Maybe I am mentally challenged :(
| gundmc wrote:
| I see the same problem with elderly relatives who struggle to
| use technology. I am hoping that things like activity blocks
| on Android [1] become more streamlined and I can use those to
| make a simplified interface to help make it more navigable.
|
| https://blog.google/products/android/accessibility-
| updates-h...
| TeMPOraL wrote:
| Accessibility is the one thing that can save us right now.
|
| 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.
| Swenrekcah wrote:
| I agree 100%.
|
| 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.
| basscomm wrote:
| Floppy disks are still in use for a lot of legacy systems
| that can't be easily upgraded or replaced for a variety of
| reasons (mostly it's some combination of they still work
| for their intended purpose and/or the manufacturer went out
| of business 20 years ago).
|
| Manila folders are still sold at office supply stores, so
| I'm pretty sure that they're still in widespread use.
| dkonofalski wrote:
| As long as you realize that this isn't how the majority of
| people work, I see nothing wrong with this. The vast majority
| of users, though, are easily overwhelmed by excessive options,
| especially those that are infrequently used. It's been proven
| in study after study that progressive disclosure is the most
| discoverable paradigm. I'm not saying that Apple is getting
| this right (they have screwed it up several times) but seeing
| every option you have is rarely useful for the average user.
| Case in point - the Office Ribbon interface. It's terrible and
| somehow uses both progressive disclosure (new tabs show up in
| context) while also showing you ever possible option in the
| most non-intuitive groupings.
| breakfastduck wrote:
| 2000 era windows forms are literally the worst UI ever. A
| design language where it's developers seem compelled to put a
| million fields and buttons on one page.
| naikrovek wrote:
| Perhaps you've forgotten what computers are for.
|
| A computer is a tool that a user employs to accomplish one
| or more tasks. Computers are not a design statement.
| Computers are tools.
| breakfastduck wrote:
| Yes, and making a tool that's so counter intuitive that
| most users find it a confusing mess is a bad idea.
|
| 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.
| indymike wrote:
| I'm pretty sure that it doesn't matter how nice your form
| library is, businesses and government will find a way to
| make it ugly and overstuffed with fields and buttons. The
| funny part is the team that did the winforms project was
| replacing horrible some horrible text-mode database form
| that users said all the same things about.
| pseudalopex wrote:
| It's always Windows forms because that's how people made
| line of business apps in that era.
| TeMPOraL wrote:
| > _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._
|
| 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[0]. 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).
|
| --
|
| [0] - or watching cat videos, or doing personal stuff, or
| chilling out - ways of keeping sane and improving morale,
| which raises overall productivity too.
| naikrovek wrote:
| Don't blame the hammers when you find your valuables
| shattered. Blame the people wielding the hammers.
|
| 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.
| naikrovek wrote:
| I would say that the vast majority of users can adapt to
| anything you throw at them. Users are not delicate flowers
| which need to be coddled and babied.
|
| 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.
| bbarnett wrote:
| Current UI/UX dogma comes from endless studies, done at the
| dawn of wide scale adoption.
|
| 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.
| TeMPOraL wrote:
| > _Current UI /UX dogma comes from endless studies, done
| at the dawn of wide scale adoption._
|
| 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.
| pfortuny wrote:
| The basic window controls are universal and have not changed
| their functionality in ages.
| not2b wrote:
| It isn't just Apple, I'm seeing an increasing number of web sites
| where the scroll bars disappear, and only re-appear if you click
| or maybe hover in just the right place. A couple of times I've
| wasted time not knowing that there was more content the next
| screen down, or that I needed to scroll some iframe or other
| object to reveal additional content.
|
| Apparently designers have decided that scroll bars are ugly and
| should disappear when possible, and they get "when possible"
| wrong sometimes.
| whywhywhywhy wrote:
| Worst thing about this, for me is at least 5 times a year since
| this started I have to go back to our engineers and tell them
| that users can't tell whats scrollable because on windows all the
| scrollbars are hidden, or appearing in weird places where they
| shouldn't because the dev team who only tests in Chrome on Mac
| can't see any scrollbars anyway.
| el_don_almighty wrote:
| give back my scroll bars just like my 'esc' key!!!
| Koshkin wrote:
| The Gnome desktop has done something (similar?) to the scrollbars
| (and I hate it).
| ryandrake wrote:
| Visible scrollbars should be a user preference. If you're on
| macOS, it's easy to set: System Preferences > General > Show
| scroll bars. Done. Set it once and move on with your life.
|
| If you're a web site, you need to respect the user's preference.
| Don't play tricks trying to jam a visible scroll bar onto your
| site if the user has it off in their preferences. Also please
| don't try to use tricks to hide a scroll bar if the user has it
| on in preferences.
|
| Can't these web sites just focus on their content and not always
| be worrying about what magical 50 lines of JavaScript they can
| use to override the user all the time? Maybe I like to browse in
| a really long 4096 x 256 pixel window, and use a pink background
| color and Comic Sans font. Deal with it!
| jackson1442 wrote:
| Websites that mess with my scrollbar preference always break
| scrolling since they implement their own version of scrolling
| for no discernible reason.
| stjohnswarts wrote:
| One of the first things I do is make scroll bars always on. I
| wish it was opt out rather than opt in but I never lost my mind
| over it.
| rootusrootus wrote:
| On my iPhone, not only do I have invisible scrollbars, but when
| they do show up, it's in the middle of the screen. And not always
| exactly at the same spot.
|
| Someone said it's a bug, and goes away if you don't use 'reduce
| motion' under accessibility settings. But it's been around for
| several versions of iOS, so I don't know that it's a priority to
| fix.
| llarsson wrote:
| Plus, is not "reduce motion" a very common setting to get away
| from useless animations? I recall using that setting to make
| the whole iPhone feel snappier.
| lucasmullens wrote:
| You can use ::-webkit-scrollbar and ::-webkit-scrollbar-thumb to
| force the scrollbar to be visible. It seems to be the easiest way
| to make sure the user knows a div is scrollable, even if it is
| fairly hacky.
| runjake wrote:
| You can change this behavior in System Preferences -> General->
| Show scroll bars -> Always
|
| This isn't some snarky comment.
|
| 1. A lot of people don't know about this setting.
|
| 2. When you set it to "Always", telemetry gets sent to Apple. If
| enough people do this, they may consider changing the default
| behavior.
| [deleted]
| tengbretson wrote:
| I think it's pretty clear at this point that OS X is meant to be
| interacted with using a trackpad, and that anything else is
| getting a second-class experience.
| disposekinetics wrote:
| As someone with a hatred for touch based controls this
| frustrates me, but I think you're wholly correct.
| smoldesu wrote:
| +1 for this. One of the most frustrating parts of MacOS is how
| miserable it is to use it with a mouse. Turning off mouse
| acceleration needs to get a settings menu entry, stat.
| swiley wrote:
| It's in the default gnome theme too and changing themes on gnome
| is kind of a bitch if you're not actually using it as a DE (plus
| the devs hate it.) Now I have to run some kind of theming daemon
| (WTF?) just so I can have scroll bars. Sometimes it eats escape
| keys and launches random crap (occasionally an entire DE) just to
| throw a full screen modal dialog box telling me that escape isn't
| mapped to any shortcuts.
|
| Defaults should be sane, not fashionable and many people still
| expect and even need scrollbars.
| kmfrk wrote:
| One thing I agree on wrt removing scroll bars is that scroll bars
| make a lot less sense now for articles, because you'll think
| you're 20% through an article, only for it to turn out that 60%
| of the article is ads and other crap. In that sense, it feels as
| if they've lost some of their meaning.
|
| For articles, it might be interesting to do something to inform
| the user that not all content is alike, possibly through
| metadata.
| robin_reala wrote:
| Obviously if you're trying to solve this for your consuming users
| then we're down to website hacks.
|
| But if you just want scrollbars on macOS for your own use, that's
| trivial. System Preferences / General / Show scroll bars /
| Always.
| heavyset_go wrote:
| They're also an accessibility nightmare.
| my123 wrote:
| It can be disabled freely by the user in System Preferences ->
| General on macOS.
| [deleted]
| GeekyBear wrote:
| Even a bargain bin mouse has a scroll wheel these days, track
| pads use a two finger gesture to scroll.
|
| If those options don't work for you, change the system
| preferences back to always showing the scroll bar.
| jedberg wrote:
| After I learned of this issue a while back, I activated always on
| scrollbars on my Mac. It's amazing how many websites are clearly
| designed only by people on Macs, who don't realize all the extra
| scrollbars they have.
| wait_a_minute wrote:
| Does anyone really want to see scrollbars even when we'll be able
| to scroll with our eyes and even mind?
| tbihl wrote:
| Yes. The scroll bar is primarily for showing progress.
| godshatter wrote:
| On the topic of scrollbars and UX, I like it when a program shows
| a mockup of the rest of the window in the scrollbar area. For
| example, Kate from KDE does this. It's helpful not just to know
| where you are, but to see the basic structure of the document
| that's left to view.
| dilap wrote:
| Well, while we're griping...
|
| I don't mind disappearing scrollbars, but Gmail on iOS takes it
| even further, and completely eliminates the scrollbar! This is
| indeed rather annoying.
|
| And even worse, amazingly annoyingly, long-ish emails are not
| downloaded in their entierty by default! So you get part way
| through the email, and then have to tap "view entire email" to
| get the rest. And extra super annoying, the rest is not cached,
| so if you're without internet, too bad for you -- you don't get
| to read the entire message.
| tokamak-teapot wrote:
| I recommend Spark as mail client on iOS. It doesn't do anything
| crazy with its UI so I find it easy to use.
| dilap wrote:
| Thanks! I'll give it a try.
|
| So far, I've always ended up coming back to Gmail for one
| reason or another -- while there are lots of little UI
| annoyances, it always gets the fundamentals right, which is
| better than my experience w/ 3rd party clients so far.
| Fingers crossed for this one. :-)
| jacurtis wrote:
| I also tried various 3rd party clients and would always end
| up going back to gmail's app. My dad kept recommending
| Spark to me and I just didn't have the energy to try
| another 3rd party app. I eventually gave in and tried Spark
| and I haven't gone back to Gmail since. That was about 18
| months ago.
| littlecranky67 wrote:
| On macOS as well iOS and AFAIK also Android, there is a rubber
| band/bouncy effect when you scroll to the bottom and reached the
| end. So you DO get a visual indicator when you are at the end.
| When you scrolled down and didn't get that "bounce" you know
| there is more to scroll to. Additionally, the scroll bar will
| show during scroll and indicate your position in the page.
|
| Not saying this is good UX or in any way intuitive, just pointing
| it out. I think its a matter of taste and long-learned habits.
| Similar to "natural scroll" that is now the default for macOS.
| Being >20years a computer user, natural scroll felt just wrong to
| me, I always switched it back and thought Apple was just plain
| stupid. This changed when I introduced my father, who had long
| gotten away with not using computers, to a PC. When I showed him
| that he can use two-finger scroll on his laptop's trackpad on a
| website to get down, he said "oh, but its the wrong way!". I was
| puzzled, and he insisted and told me that its just the wrong way,
| reaching out to a piece of paper showing me that the content at
| the bottom would move UP into his view, if he puts 2 finger on
| the paper and moves them up, too. That was when I realized that
| "natural scrolling" is actual the physical way of doing it, and
| my hatred against it was just based that I was used to it in 20+
| years of computers being the other way around.
|
| It is also the same with Y-Axis in computer games, basically the
| default setting of the first computer game you ever played
| determines how you set your controllers (non-) inverted Y-Axis
| for life :)
| therealdrag0 wrote:
| I've been using the "rescroller" plugin in Chrome for years now.
| Nice to force a fixed solid grey scroll bar.
| whalesalad wrote:
| I love it. I just dislike how when I plug in an old-school mouse
| to my Mac an old-school scrollbar returns. The scrollbar only
| needs to be visible during a scroll event.
| ncw96 wrote:
| Go to System Preferences -> General and change "Show scroll
| bars" to "When scrolling" to get the behavior you want.
| foobarbecue wrote:
| I recently noticed that the Facebook android app never has
| scrollbars when you're reading a post (not in an infinite-
| scrolling situation), and I haven't found a way to make them
| appear.
| samatman wrote:
| > _I have a really hard time believing anyone would chose this as
| opposed to some design lead at Apple pushing a weird personal
| preference for tidyness on their entire user base_
|
| I strongly prefer the invisible scroll bars in about 95% of
| cases.
|
| I'm either using a trackpad or a scroll wheel on my trackball. In
| the former case, it's trivially easy to jog the screen up and
| down or sideways, to see if there's missing content. In the
| latter case, yeah, horizontal scrolling is challenging, but I'm
| going to be on a widescreen monitor, so my response is to fill
| more of the window with the content (quick shout-out to Moom,
| which makes this easy).
|
| It very occasionally happens that I won't notice that there's
| more content available, and scroll bars would help with that. But
| I'd rather optimize for the usual case, and get the cleaner lines
| and extra real estate which go with it.
| efwfwef wrote:
| Good luck scrolling to the bottom of a very long page. And then
| going back up.
| smnscu wrote:
| You can always click on the scroll bars -- invisible doesn't
| mean they don't exist, they simply go out of the way when
| they're not needed (i.e. most of the time / when not
| scrolling). You can do that on iOS and Android as well, tap
| and hold on the scroll bar to quickly scroll through an
| entire document.
| breakfastduck wrote:
| How exactly is that an issue?
| nikisweeting wrote:
| Scroll has acceleration on macOS touchpads, doing it with two
| fingers is just as fast if not faster than dragging a
| scrollbar with the mouse.
| Toutouxc wrote:
| This is actually a non-issue (or at least a minor issue for
| extremely long pages) on a Mac, because macOS has system-wide
| kinetic scrolling and all Apple input devices use touch
| sensitive surfaces for scrolling.
|
| Not saying you're wrong, it's certainly annoying on mobile
| devices (compounded by the narrow screens and responsive
| content).
| jackson1442 wrote:
| It's trivially easy. Just put your mouse at the edge and move
| the scroll wheel. You can then click it. There is also an
| option in System Preferences to change this behavior and
| always show the scroll bars. Since this motion is more
| intuitive on a trackpad than on a mouse, scrollbars always
| show when using a mouse by default.
|
| https://i.imgur.com/LTg81eW.png
| samatman wrote:
| Ah you're right, just yesterday I sprained my pinky hitting
| command-up and command-down!
|
| You got me on that one!
| jbj wrote:
| my big issue with invisible scrollbars are particularly when they
| dont appear in small boxes and I dont realize I am passing a
| scrollable area
| efwfwef wrote:
| I really hate it too, I don't understand why they do this... Even
| using Chrome on mac I can't scroll properly if I'm not fast
| enough to catch the scrollbar after a light scroll.
| nikisweeting wrote:
| Why not just set "Always show scrollbars" in System Preferences
| if you don't like it that way?
| eyelidlessness wrote:
| I personally prefer auto-hiding scrollbars for my own general
| use.
|
| But I was recently in the same position as OP trying to make
| horizontally scrollable sections more discoverable and it's
| really a pain.
|
| OP is using JS so there's a lot of options, but my use case was
| CSS-only and I ended up giving up on the scrollbar visibility and
| using a "scroll shadow" instead--where overflowing content
| displays a small shadow over the content which fades out at the
| end of the scroll.
|
| It's not as clear as an explicit scrollbar but it's a fairly
| common pattern users do often recognize.
| sandos wrote:
| Hidden scrollbars are cancer. Me, as a developer, using computers
| pretty much at least 8 hours per day still struggle with finding
| that god-damn scrollbar several times per week!
|
| What about all the ones with even less know-how, or less
| patience?
| thih9 wrote:
| This seems easy to solve; at least on MacOS: "System Preferences"
| -> "Show scroll bars" -> "Always".
|
| Update: Ah, I now realise that the goal is to make sure that an
| app always displays scroll bars. I hope that's impossible;
| personally I don't mind either scrollbar setting but I do want
| consistency and I do want apps that respect my OS settings.
| taylodl wrote:
| I haven't thought about scroll bars in years! I just use the two
| finger gesture on my trackpad to scroll. In System
| Preferences/General you can select Always for 'Show scroll bars'
| if you so desire. At least Mojave provides that option.
| [deleted]
| smaccona wrote:
| On macOS, I have scrollbars always show. The setting is in System
| Preferences -> General -> Show scroll bars -> "Always".
|
| On iOS, I definitely prefer no scrollbars, but I don't think
| there's a way to always display them.
| josho wrote:
| Visible scrollbars are unnecessary with proper design.
|
| Eg. Reading the Twitter thread I intuitively know that I can
| scroll to see more because the last line of text is partially cut
| off by the edge of the screen. This signals to my brain that
| there is more, and I can scroll.
|
| Whereas as I type in this text box as I reply the box is sized
| perfectly to 6 lines of text and I don't have the same visual
| accordance informing me that content exists outside the viewport.
| jpalomaki wrote:
| Scrollbar also tells how much hidden content there is.
| xtracto wrote:
| Exactly, I find it funny how now I have to download
| additional 1MB of Javascript for a webpage to show me the
| place in the document I am at the moment.
| lucasmullens wrote:
| It's a lot of work to get the elements on the page to always
| space themselves such that one element is cut off. I think it's
| pretty impressive if a site bothers with that, but it's hard to
| call that "proper design".
| kemonocode wrote:
| I feel like designers at Apple at large with others following in
| tow to emulate them have been waging a silent war against the
| scroll bar for a while now.
|
| Making it less and less visible until it ultimately disappears
| sounds reasonable when infinite scrolling (and heavens forbid,
| scroll hijacking) has rendered it far less useful.
| SloopJon wrote:
| I don't like the hidden scroll bars either, so I've set "Show
| scroll bars" to "Always". If I understand correctly, Simon wants
| his web site to display a scroll bar on a system that isn't so
| configured. I'm not sure why--does it mess with the viewport
| width or something?
|
| Edit: simonw just posted more information on this thread.
| gherkinnn wrote:
| > I have a really hard time believing anyone would chose this
|
| Speak for yourself. I love it. And it works like a charm with
| magic-y input devices like screens and touch pads.
|
| It's a bit shit with discreetly scrolling mechanisms and on OS'
| that don't do it right.
| wyuenho wrote:
| The Mac's hidden scroll bar is normally quite usable in Safari
| and Firefox, when you move the cursor to the side and start
| scrolling, it'll automatically pop up, with a thick bar that you
| can hold on to with the pointing device. That is, unless you are
| trying to figure out the exact behavior on Chrome or some
| Electron app, which is half the most used desktop apps on the
| macOS these days, and took you a while to figure it's actually a
| bug in Chrome.
|
| https://bugs.chromium.org/p/chromium/issues/detail?id=678537
| tacker2000 wrote:
| On mobile it makes sense, since the user has much more direct
| control over the scrollable area and the area is quite small. The
| thing is, apple has been trying to converge the desktop and
| mobile UI into one single interface, and this is a prime example
| where this approach fails. A visible scrollbar is extremely
| important to the desktop user, but not really so to the mobile
| one.
| masswerk wrote:
| To be honest, nobody needs text unless they read it. Moreover,
| all these different typefaces, sizes and tints are a serious
| threat to any corporate UI identity and professional UX.
| Especially, as texts from various sources are fighting for the
| display and user attention. Let's get rid of visible text, unless
| you hover or swipe on it! Much cleaner UIs and smooth UX are
| guaranteed, which is exactly what customers want!
|
| (Disclaimer: this is obviously in the sarcasm category, but is
| still meant to provide viable food for a thought experiment.)
___________________________________________________________________
(page generated 2021-03-10 23:01 UTC)