[HN Gopher] My favourite animation trick: exponential smoothing ...
___________________________________________________________________
My favourite animation trick: exponential smoothing (2023)
Author : atan2
Score : 609 points
Date : 2024-03-08 03:27 UTC (19 hours ago)
(HTM) web link (lisyarus.github.io)
(TXT) w3m dump (lisyarus.github.io)
| ggm wrote:
| I continue to marvel at how often simple non linear tricks add
| some joy to interactions online. Or, in the case of colour
| perception are fundamental to understanding why two colours may
| not be perceptibly different enough to some people.
|
| The odd thing is that humans do not always understand
| acceleration. Don't run away from a fire uphill, in a belief it
| travels as fast (semi constant) across level ground: fire
| accelerates up hills.
|
| Kids rapidly learn the rate of movement across ground for a
| thrown ball but not always just how fast it will be moving under
| gravity when it smacks into your hands.
| sleepybrett wrote:
| everything old is new agin, dozens of this exact article in the
| flash era.
| spicybright wrote:
| We lost a lot of collective wisdom when flash died IMO
| sleepybrett wrote:
| Not really, the openframeworks/processing/thi-ng umbrealla
| crowd never forgets.
| nico wrote:
| Great write up, love how much detail it goes into, and the
| interactive examples really help illustrate the points
| Hnrobert42 wrote:
| Is it just me, or does a little square flash around the toggle. I
| am on FF Focus. It totally derails the exploration of the
| smoothing variants.
| grugagag wrote:
| Similar experience in Safari on IOS
| mediumsmart wrote:
| Me too. Orion on iOS. So the border radius has a light leak?
| seemaze wrote:
| I noticed halfway through this article I was just clicking away
| furiously. Is this a clever ruse by $MEGA_INPUT_DEV_MFG to wear
| out my mouse clicker quicker..?
| tadfisher wrote:
| A generalized version of this is Hooke's Law, also known as the
| spring function. It works well for UI animation because it
| maintains velocity as the target x changes, instead of
| stopping/restarting like an eased tween would.
| frfl wrote:
| Really great write up. The demos seems to work fine in Chrome,
| but on Firefox they freeze up and cause they page to stop
| rendering completely as you scroll.
| zellyn wrote:
| Yeah, I had the same issue and came to the comments to find out
| it it was just me.
| shahar2k wrote:
| it's funny, the thing that got me to understand calculus
| initially in class was seeing the graphs, somehow my brain
| immediatly "got" the difference between acceleration and movement
| and the shapes of those formulas... these days I think it might
| be a type of kinesthetic synesthesia! helps immensely since I
| work in animation and always had an easy time figuring out just
| the right math for procedural animation :)
| eviks wrote:
| > Animations are not just a fancy visual thing, they help the
| user understand what's going on. Instead of teleporting the
| toggle indicator to its new position, let's move it smoothly
|
| Unfortunately it is, just a fancy thing that too often makes it
| worse or just focuses on the wrong thing.
|
| Like in this case, what exactly is "going on" that requires this
| visual delay? It looks worse vs the original instant response,
| why does the user need to care about intermediate movement of
| this binary toggle?
|
| Then this is the fanciness that detracts from solving the major
| flaw of these sliders: you can't easily tell whether it's off or
| on
| gleenn wrote:
| While in small doses it's a bit nice to affirm to the user they
| didn't blink while the state changed, it adds significant
| complexity. Nearly every one of the animations in that website
| flicker and the map rendering actually has a bug where it
| doesn't stop jittering back and forth very visibly
| indefinitely. Definitely makes me _not_ want to implement stuff
| like this.
| recursive wrote:
| You were so close to reading the part where it explains why
| that's happening and how to fix it.
| BriggyDwiggs42 wrote:
| The jittering was an anti demo i think
| zbrozek wrote:
| I miss old school checkboxes for UI toggles. They're crisp and
| clear and don't entice bored people to animate them.
| max_k wrote:
| Me too, agree with you and GP. And I can't keep wondering why
| this opinion is so unpopular. Today's UIs are bloated with
| unnecessary animations (which adds latency). But worse than
| animations is that UIs are horribly inconsistent; took me a
| while to figure out those toggles should be clicked, not
| dragged; or: what is even clickable, how do I scroll, ...? I
| could go on forever, and probably so can you.
|
| Why do only old nerds complain about this, when today's UIs
| are so "easy" that every toddler can use the smartphone? Are
| we just living in the past, getting old; are we the problem,
| why is our opinion unpopular?
| zbrozek wrote:
| I'm old now, and I won't dismiss that the new stuff is
| aesthetically nice. It's also not that hard to use. But I
| just don't like the visual polish more than I like the
| clarity and responsiveness of the old UI elements.
|
| I just don't care if my computing experience is beautiful.
| I care if it's snappy, productive, and reliable.
| max_k wrote:
| > I just don't like the visual polish more than I like
| the clarity and responsiveness of the old UI elements.
|
| Agree, that sums my opinion well.
|
| And much software doesn't even look like they preferred
| eye candy over clarity; it rather looks like they forgot
| about clarity completely.
| josephg wrote:
| > why is our opinion unpopular?
|
| I think other people do feel a vague sense of anxiety using
| modern software from not quite knowing what all the
| interaction patterns are. When you click that hamburger
| menu on the website, what will it do, exactly? But most
| people from outside the software world just blame
| themselves for "not being very good with computers".
|
| The problem is that it's not fashionable any more amongst
| designers to use built in controls. Everyone wants to think
| of themselves like Apple, and build their own beautiful
| design language. Even if it's just for their own website or
| app. And it sort of makes sense given modern apps end up
| needing to be built for the web, iphone, iPad, Android, and
| the desktop. It makes sense to tie all of those pieces of
| software together with a cohesive visual language and
| style.
| jalfresi wrote:
| UI has become the domain of marketing and branding.
| tetha wrote:
| I mostly find the way the opinion presented in this thread
| by many people exhausting.
|
| You're doing it there too: You're throwing every bad point
| of every bad UI you ever encountered into a bucket and
| throw all of that at this article by concluding "Animations
| in UI are terrible and just bloat everywhere". That's very
| close to a strawman.
|
| I have worked and AB-tested in UIs for games and such
| dealing with just that and I would much rather say: Bad UIs
| are bad, yes. And animations don't help bad UI not being
| bad. But if you have a good, understandable UI, adding
| animations smartly - without impeding the user and in
| subtle fashion - on top of that UI... that can increase the
| overall aesthetics of the UI a lot and make the UI much
| more pleasing to use.
| max_k wrote:
| I agree with that; animations can be OK, but when I have
| a configuration setting, I usually disable them because
| input latency drives me crazy.
|
| My post replied to "checkboxes vs UI toggles", and
| replying to that aspect was my main point. That's
| slightly off-topic, of course. It has to do with
| animations only because checkboxes wouldn't really
| benefit from animation, whereas toggles are an obscure
| visual representation for the same control, and adding
| animation is a feeble attempt to make it somewhat less
| obscure, even though it doesn't even try to address the
| main problem: what does toggle "left" and "right" really
| mean?
|
| I believe checkbox not benefting from animation is a good
| thing: it's so clear and obvious that you don't need to
| animate it.
| tetha wrote:
| > what does toggle "left" and "right" really mean?
|
| Nothing, because that's not the point of the article.
|
| It's weird to me that this is such a big point here.
|
| In an actual UI, you will have labels or indicators
| telling you what the toggle means and what the options
| are - "Safety door unlatched" vs "Control motors
| engaged". That's a toggle between two choices and having
| it a toggle like that would be safer than checkboxes.
|
| Otherwise your checkbox without labels is equally bad UX
| because what does "on" and "off" mean for an unlabeled
| checkbox? I could give enough examples from work how
| vaguely labeled checkboxes like "remote authentication"
| are terrible UX.
| max_k wrote:
| > that's not the point of the article.
|
| Of course not. The post you're replying to explicitly
| said the discussion was off-topic. That means it's not
| discussing the point of the article.
|
| > In an actual UI, you will have labels or indicators
| telling you what the toggle means and what the options
| are
|
| If it only were that way, we wouldn't complain. But it's
| not.
|
| > checkbox without labels is equally bad UX
|
| Of course, I agree. But nobody asked for that.
|
| Your post ignores the things that were said and replies
| to things that were not said.
| Propelloni wrote:
| For toggling between mutually exclusive choices please
| use radio buttons. Checkboxes, and less obvious variants,
| are for enabling/disabling clearly labeled options that
| are not mutually exclusive.
|
| That used to be Interaction Design 101 back in the olden
| days, ie. 1990s.
| josephg wrote:
| I'm quietly obsessed with the idea of rebuilding a lot of
| modern user interfaces just using classic controls that we've
| had since the 90s. Checkboxes, radio buttons, labels and text
| input elements. I don't know if it would be as _good_ as what
| we have now, but there would be something so relaxing about
| all of my applications looking like they're part of the same
| world.
| max_k wrote:
| Back in the days, you had a UI toolkit, and everybody would
| use those native controls; they looked and felt the same in
| all application, and you had a central place where you
| could customize the look. Now every application/website has
| customized controls for everything; everything looks and
| works differently. (And don't even get me started with
| websites implementing their own scrollbars with JavaScript.
| Uh!)
|
| Custom list control: do Home/End buttons work? How to
| select multiple items, does Shift-Cursorkeys work? Does
| Ctrl-Click work? Of course not.
|
| Custom text control: does Ctrl-Left/Right for word jumping
| work? Does Ctrl-Up/Down for paragraph jumping work? Can I
| select everything with Ctrl-A or does it select the whole
| website? Can I select everything from cursor until the end
| with Ctrl-Shift-End work? Does Copy/Paste work at all? (I
| have never figured out why Copy/Paste in Teams simply
| doesn't work. Apparently I'm the only one with this
| problem.)
|
| Custom dropdown control: does Alt-Down work? Can I scroll
| the list with the usual keys?
|
| If (web) developers would just use standard controls,
| everything would work the same, and they wouldn't have to
| reimplement all the basic things from scratch (or not at
| all). Web devs could write forms that work without
| megabytes of JavaScript.
|
| Hamburger menus. Those horrible things didn't need to exist
| even in old times with small monitors and 640x480 (or less)
| - but now they exist everywhere on my 32" 4K monitor for no
| reason.
| anon373839 wrote:
| Checkboxes and switches serve different functions and
| shouldn't be used interchangeably:
| https://www.nngroup.com/articles/toggle-switch-guidelines/
| layer8 wrote:
| This is a rationalization after the fact. Checkboxes used
| to be used in contexts where they are effective immediately
| too, and nobody was confused by that. The real reason
| switches were introduced was to be able to line them up on
| the right side in iPhone OS Settings, whereas checkboxes
| would have to be on the left side, costing too much extra
| margin space on the then-small iPhone screen.
| anon373839 wrote:
| Did you read the linked article? I think toggle switches
| are a superior metaphor for controls that move a system
| between two states. Checkboxes are superior for opt-in
| items that can be skipped over.
|
| Consider the "kitchen lights" illustration here:
| https://learn.microsoft.com/en-
| us/windows/apps/design/contro...
|
| Do you really think a checkbox has the right affordances
| for this action?
| srg0 wrote:
| I beg to differ. Quick search shows that people animate
| checkboxes too:
|
| https://stackoverflow.com/questions/44876144/how-to-style-
| th...
| saretup wrote:
| > It looks worse vs the original instant response
|
| I think that's an unpopular opinion. The instant response looks
| janky, exponential smoothing looks well polished as long as
| it's not too slow.
| starspangled wrote:
| It didn't improve it for me. I don't want a switch animation
| that looks (like the designer thought) a physical switch
| might move. I want a widget to indicate and change some
| option.
|
| It's not a great type of widget for that anyway, as others
| said. But either way the animation adds nothing except time
| the designer could have used to think about a better
| interface.
|
| The snappy "instant" and simple UIs for Windows 95/2000 era
| were the best, IMO. It might take a bit to get used to non-
| animated updates it if you have never experienced it before
| and seem a bit janky, but it doesn't take long and at least
| for me feels much nicer.
|
| Quarter of a century of "UX experts" and useless animations
| and transparency and complicating things has resulted in an
| objectively worse experience. It's slow, clunky,
| inconsistent, constantly changing, and doesn't even look
| good. The technical parts of the drawing, scaling, font
| rendering, color management, etc are much better of course,
| but not the overall experience.
|
| UI design was of huge importance to the industry (Apple and
| Microsoft) when GUIs were first coming in, many people were
| still getting into the world of computers, and many of those
| who were using them were not comfortable with them. Improving
| the experience could be worth a fortune in new market. That's
| why usability, intuitiveness, and consistency were priorities
| and it was taken seriously as a discipline, there was
| research, and changes were made with (at least in part)
| quantitative data and study.
|
| That field of UI design has basically died in the industry
| now. At least, it is much smaller and less impactful than it
| was. Most of it seems to have shifted to getting people to
| look at and interact with things that they otherwise would
| not have. I guess shiny new things would help with that,
| maybe that explains the baffling direction things have gone
| in.
|
| EDIT: BTW., don't take this as criticism of the linked post.
| Back when I did a bit of graphics programming I loved
| tinkering around to make things visually pleasing and behave
| in interesting ways. The post is fun and interesting, and
| presented in a way that itself is a nice experience and must
| have taken a lot of work. And I don't think the author was
| passing it off as an end to end guideline for a user
| interface design. And I do accept that a lot of people do
| like more visually interesting and diverse interfaces.
| They're wrong, of course, but entitled to their opinion (/s)
| lenkite wrote:
| Disagree - the instant response was alert and immediately
| observable and didn't take valuable time away from a limited
| mortal life.
|
| Its like saying a web-page that loads and displays instantly
| is "janky" versus a web-page with a busy symbol that makes
| you pause and wait.
|
| If you had 20 of these toggles to check, you would prefer
| your "janky" version anytime.
| Animats wrote:
| > the major flaw of these sliders: you can't easily tell
| whether it's off or on
|
| That's the whole point. That's why the primary use of sliders
| on desktop is opt-out of something no user really wants.
|
| This is often combined with scroll windows with some sliders
| offscreen and invisible scroll bars.
| indigane wrote:
| I'm working on a Git GUI for myself, in which one of my top
| priorities is making it more understandable than Git's own UI.
|
| I usually dislike animations. I used to disable transitions
| whereever possible, as they made the UIs feel sluggish. And I
| still do.
|
| But working on the project made me for the first time really
| appreciate in practice how much amimations help with
| understanding. I paid a high price in complexity to add
| transitions whenever the state of the visual graph changes, and
| suddenly it was really obvious what was happening. Commits and
| whole branches were sliding into their new position, and I
| would go "a-ha! I see" instead of "wtf just happened, what am I
| looking at now?".
|
| EDIT: Fair warning, it's heavily WIP
| https://gitlab.com/indigane/visual-git
| dclowd9901 wrote:
| I think this is the trick. Animations as a visual tool for
| teaching the outcomes of complex behaviors are a very valid
| usage of animation. There's that one site that pops up on
| here occasionally with the fabulous educational topics and
| tons of animations to relate concepts that I think really
| drives that point home.
|
| Minimizing animations are nice for showing you where things
| "went" when you minimize them. But apart from that, most
| other UI annimations are just eye candy.
| chefandy wrote:
| > Like in this case, what exactly is "going on" that requires
| this visual delay?
|
| Nothing. It's a technical demonstration. The delay is also
| overemphasized to make the difference more apparent.
|
| > The this is the fanciness that detracts from solving the
| major flaw of these sliders: you can't easily tell whether it's
| off or on
|
| That's because they don't represent anything. Toggles don't
| always represent on or off, either-- they could represent a
| binary choice between any number of things.
|
| > Unfortunately it is, just a fancy thing that too often makes
| it worse or just focuses on the wrong thing. > It looks worse
| vs the original instant response, why does the user need to
| care about intermediate movement of this binary toggle?
|
| Putting aside the functionality that animations can add,
| because others have addressed it, even "feel" does matter to
| most users. Many people would choose soft-close cabinets over
| regular spring loaded hinges even if noise wasn't a concern.
| You'd never see them in a commercial kitchen, though-- people
| just move too fast and that extra bit just gets in the way. It
| would be rather absurd for someone in a professional kitchen to
| assume home cooks have the same requirements and use cases for
| cabinets that line cooks do. Similarly, people who spend most
| of their days doing technical things using technical tools made
| by and for technical people interpret interfaces differently
| than most people. To developers, UIs are a little part of an
| application to expose the functionality to users, and the less
| distance between the application and the user, the better. But
| more often than not, that approach yields results far more
| useful to someone with a working mental model of how software
| operates under the hood. To most people,the UI _is_ the
| application, and the application is an appliance. Having smooth
| interactions that 'feel' nice to use are much more desirable.
|
| As someone with a good amount of professional experience both
| as a developer and a designer, I'm consistently surprised by
| how quick so many developers are to assume their personal usage
| habits, osmosis-gained knowledge from projects, and folk wisdom
| about design trumps the expertise of seasoned credentialed
| professionals in the field. The reason most end-user-facing
| FOSS projects (that don't have foundation-funded UI teams like
| Blender or Mozilla) are used almost exclusively by other
| developers is because non-technical users usually find the
| experience unpalatable at best, and unusable at worst.
| dz08dl wrote:
| >As someone with a good amount of professional experience
| both as a developer and a designer, I'm consistently
| surprised by how quick so many developers are to assume their
| personal usage habits, osmosis-gained knowledge from
| projects, and folk wisdom about design trumps the expertise
| of seasoned credentialed professionals in the field.
|
| Exactly! Too many people think that their personal preference
| is the best. Sometimes, the best solution is to have plain
| HTML where the user chooses their favorite font and size,
| like in the early Netscape era. However, that's not always
| the case.
| eviks wrote:
| > It's a technical demonstration
|
| So? The justification is still substantive. What would change
| in a real slider that turns real setting on/off?
|
| > delay is also overemphasized
|
| That's only true for those slowed down by a factor of 8.
| Otherwise it's not, I see the exact same issue in real-world
| sliders on web sites and in apps.
|
| > Toggles don't always represent on or off, either
|
| But they mostly do, add they do in this case ("turned_on").
| The other use cases would have different issues like the
| choice of colors (green is for on)
|
| Then you overly general description forgets to prove that
| slower and more confusing control (which some generic non-
| tech users try to actually slide by holding a mouse button
| and moving the mouse instead of clicking) is actually
| preferable because it "feels" nice to them
|
| Also, these > seasoned credentialed professionals in the
| field.
|
| are the same people who put these garbage sliders in the OS
| settings menus (as well as maintaining many other common
| decades-old UI bugs), so color me unimpressed by their
| credentialed osmosis degrading user experience at scale (poor
| FOSS designs notwithstanding)
| chefandy wrote:
| > So? The justification is still substantive. What would
| change in a real slider that turns real setting on/off?
|
| No it's not. Whether or not a design accomplishes its goals
| is exclusively based on what it's trying to communicate.
| This is trying to communicate animation curves.
|
| > That's only true for those slowed down by a factor of 8.
| Otherwise it's not, I see the exact same issue in real-
| world sliders on web sites and in apps.
|
| What you notice in apps is probably noticeable because it
| was done poorly. In the vast majority of instances, these
| things are done well so they help your eye adjust but don't
| stick out as animations.
|
| > But they mostly do, add they do in this case
| ("turned_on"). The other use cases would have different
| issues like the choice of colors (green is for on) Then you
| overly general description forgets to prove that slower and
| more confusing control (which some generic non-tech users
| try to actually slide by holding a mouse button and moving
| the mouse instead of clicking) is actually preferable
| because it "feels" nice to them
|
| You're substituting assumption for knowledge.
|
| > Also, these > seasoned credentialed professionals in the
| field. are the same people who put these garbage sliders in
| the OS settings menus (as well as maintaining many other
| common decades-old UI bugs), so color me unimpressed by
| their credentialed osmosis degrading user experience at
| scale (poor FOSS designs notwithstanding)
|
| Most novices can't distinguish poor practice from poor
| practitioners from poor general concepts.
| tetha wrote:
| > Most novices can't distinguish poor practice from poor
| practitioners from poor general concepts.
|
| Off-topic, but this made me chuckle. My current progress
| into learning instruments and music is greatly helped by
| the fact of knowing a few musicians who understand my
| problems better than I do because they had those problems
| 15 years ago, haha.
| bongodongobob wrote:
| I think parents reaction might be due the amount of shit
| software with pretty UIs. In the last 10 years it really
| feels like software has leaned towards form over function. I
| personally miss, simple, snappy Windows NT type UIs that were
| a megabyte and didn't contain a gig of custom icons or hit
| the GPU to like fade a window or something.
|
| I think most people would trade opacity and fancy buttons for
| MS Teams to be able to load in under a minute.
| anon373839 wrote:
| That's a fictitious trade, though. Opacity and fancy
| buttons are computationally very cheap, and they aren't the
| reason for Teams's poor performance.
| wizzwizz4 wrote:
| If Microsoft Teams were made in Windows Forms, it would
| not have the fancy look it has now, and it would be a lot
| faster. "The reason" is complicated.
| johnnyanmac wrote:
| >I think most people would trade opacity and fancy buttons
| for MS Teams to be able to load in under a minute.
|
| It's a paradox. If you don't make it look fancy, smooth,
| and appealing, you lose out to those that do. Even if you
| have a better product, that doesn't mean you can sell it on
| merits of being more technically efficient. Especially to
| more casual consumer or to business heads to make the
| purchases.
|
| besides, the minute loading times aren't because it's
| caching all those animations and assets. That's a different
| division with different problems. Probably a mix of
| security checks, inefficient networking, and _maybe_ some
| choice in framework like Electron as a distant 3-5th (not
| that Teams uses Election).
| Shorel wrote:
| We don't use Teams because it is fancy, or smooth or
| appealing.
|
| We use Teams because the company that pays our salary
| tells us to use Teams. End of story.
|
| And I would definitely trade opacity and fancy buttons
| for a client that loads and runs fast.
| jdiff wrote:
| Unfortunately, you can't, because it isn't the opacity
| and fancy buttons making it slow in the first place. It's
| still a false dichotomy.
| johnnyanmac wrote:
| >Especially to more casual consumer or to business heads
| to make the purchases.
|
| I covered that yes. Your company isn't made of people who
| will objectively measure the best product for the
| employees.
| faceplanted wrote:
| Microsoft teams doesn't load slowly because of the
| animations, you can turn all of them off if you mess around
| with the settings and your windows registry enough. It
| loads slowly because MS have a huge incentive to keep
| adding features and almost no incentive to optimise it
| because the software is almost always purchased by large
| institutions, half of whom have vendor lock in already, and
| imposed on the people who actually use it day to day, who
| have no power to change it.
| majewsky wrote:
| > It loads slowly because MS have a huge incentive to
| keep adding _telemetry and ads_ and almost no incentive
| to optimise it
|
| Fixed that for you.
| Philip-J-Fry wrote:
| I still love a nicely designed Winforms UI in 2024.
|
| No weird colours or anything. Just mostly standard
| controls, unless it's necessary to create a custom one.
| chefandy wrote:
| Most developers look at old interfaces through rose colored
| glasses. If you separate nostalgia from what most people
| find usable, they just don't hold up.
| anon373839 wrote:
| > I'm consistently surprised by how quick so many developers
| are to assume their personal usage habits
|
| To be fair, developers coming from math and CS backgrounds
| may not have had any HCI/UX/design training. For those who
| have, "You are not the user" [1] was drilled in as a
| foundational concept.
|
| [1] https://www.nngroup.com/articles/false-consensus/
| vidarh wrote:
| Most frontend developers _also_ don 't have much - if any -
| HCI/UX/design training. My experience is that a lot of
| people who _should have had_ that instead see design as
| "above" that in a way that is worse by far by showing
| active disdain for user feedback. Often, in fact, by
| dismissing input from a user perspective from developers
| with a "oh, but you're not typical users". Which is on one
| hand usually fair, but on the other hand dismissing that
| they also _are_ users, and often there is no such thing as
| a "typical" user.
|
| If one segment of your users reports something as a
| problem, you need to at least try to understand _why_ and
| whether it is possible to reconcile with what your other
| users want, or whether in fact your other users _also_
| would agree but just haven 't been vocal about it.
| sabellito wrote:
| Your point has truth in it of course, but the main theme gp
| was pointing out is the hubris of people, often in our
| field, to think that they know better than someone
| specialised on a given field.
| zarathustreal wrote:
| Are you conflating "hubris" with "reasoning"? Or are you
| saying that appealing to authority is a _good_ thing?
|
| Is any evaluation of any field you're not an expert in
| hubris? Or is it possible to use basic logic to identify
| contradictions in the assertions made by experts outside
| your field?
| injidup wrote:
| Binary toggles are everywhere in web UX. They are almost
| always used where a simple dropdown menu with WORDS
| indicating the chosen state would be better. However
| designers hate that because then they can't write fancy
| animations on creamy toggle widgets.
|
| A dropdown with the words enabled/disabled indicating the
| state will always be better than a toggle with some subtle
| animation and colour signalling the state.
| aembleton wrote:
| Why is it better to use a dropdown? A drop down doesn't
| show me all of the options until I click on it; so I have
| to perform an action to see what my options are, rather
| than having them presented in front of me.
|
| They're fine if there's going to be loads of options such
| as country name, but if its left handed or right handed, I
| just want to see a toggle/radio button that lets me switch
| and makes it clear which state its currently in.
| injidup wrote:
| The problem is that you don't know if ``on`` mapped to
| what you think it does.
|
| https://i.imgur.com/cflIbUv.png
|
| for example. Light grey is disabled. Light blue is
| enabled. It's not accessible. It's not obvious. It's not
| great for colour blind people. It's probably in this case
| a deliberate dark pattern. The only case where a toggle
| is ok is if the word for the each state is to the left
| and right of the toggle.
|
| https://i.imgur.com/skPP5Cu.png
| aembleton wrote:
| I agree, for on/off a checkbox would work better
| chefandy wrote:
| Somtimes. Checkboxes work for "yes" or "no", but they're
| not idiomatic for other "a" vs "b" selections.
| injidup wrote:
| A checkbox should always have a label which should always
| be a question. The checkbox should be a tick not a cross.
| Then there is not ambiguity.
|
| Toggle switches should have two labels to the left AND
| right which are binary enumerations.
|
| yes (O----) no
|
| vanilla (----O) chocolate
|
| off(O----) on
|
| The problem is that designers with their bias towards
| animation and colors get it wrong. They do things like
|
| Turn on? (O----)
|
| And then toggle the color of the background between two
| different pastel shades which is aesthetically pleasing
| to the eye but delivers you halfway towards a reactor
| pile meltdown when the operator gets it wrong.
| chefandy wrote:
| Do you have any support for anything you've said that isn't
| based entirely on your own assumptions and feelings about
| designers?
|
| > A dropdown with the words enabled/disabled indicating the
| state will always be better than a toggle with some subtle
| animation and colour signalling the state.
|
| Oh yeah way better except for not being able to see all of
| your options or even how many options there are without
| interacting with it, at least double the number of
| keystrokes to operate, more cognitive load to parse and
| operate, not being idiomatic for the interaction, etc. etc.
| etc. There are lots of uses that dropdowns work better for,
| but saying they're simply _better_ is asinine.
| cardanome wrote:
| > Similarly, people who spend most of their days doing
| technical things using technical tools made by and for
| technical people interpret interfaces differently than most
| people.
|
| Most "non-technical" people use computers, especially
| desktops, in a professional setting. Navigating those UIs is
| part of their jobs and they will spent hours upon hours doing
| so.
|
| Pretty animations may make a good first impressions but they
| get old and annoying very fast. It is a huge mistake in UI
| design to only optimize for smooth on-boarding of new users
| and not for long term productivity.
|
| > The reason most end-user-facing FOSS projects (that don't
| have foundation-funded UI teams like Blender or Mozilla
|
| Blender has great UI because they are dog-fooding their own
| software through blender studio. Meaning because they are the
| users and develop UI based on their own needs, contradicting
| your theory.
|
| Firefox UI has gotten significantly WORSE over time and the
| browser is becoming irrelevant based on market share. Now
| that is not all the fault of the UI but it is still worth
| noting that the height of firefox popularity was when it had
| a very power-user friendly UI that all that fancy "UI
| experts" would hate. Maybe they should replace the
| "foundation-funded" UI team.
|
| As for commercial software, modern UI is so bad that many
| "non-technical" users actively hate using computers and feel
| absolutely powerless when errors occur. Modern UI is actively
| user-hostile.
| Certhas wrote:
| Several years ago, the number one complaint you could read
| on this forum on Firefox was that Chrome felt snappier.
|
| Firefox is irrelevant today because the supposedly highly
| sophisticated users decided based on feel.
|
| Smooth animation performance was a major point of iOS over
| Android for years.
|
| I see plenty of evidence of sophisticated users deciding
| based on the factors you dismiss.
| akoboldfrying wrote:
| Smooth animations > janky animations, always, but that's
| not the issue here -- the issue is whether something that
| doesn't need to be animated should be animated.
|
| I prefer programs I perceive as "snappier" -- and to me,
| a part of "snappiness" is choosing not to animate things
| unnecessarily.
| buran77 wrote:
| Some animations can be essential for user experience. One
| of them is demoed in the page: the page scroll animation.
|
| If you've ever looked at a wall of text or other high
| entropy information displayed on the screen, especially
| if it was on a shared screen so the image is all you can
| see with no hints about the scroll direction, keeping up
| with the motion can be nigh impossible. You have the
| whole image jumping up and down several lines or even a
| full page at a time and you spend all your brain power
| trying to find an "anchor" reference point to realize
| what that movement was, instead of focusing on the
| content.
|
| In such cases even the most subtle of animations that
| tells me how the image moved is a treasure.
| mrob wrote:
| The vast majority of scrolling is done for the benefit of
| the person initiating it. It's a good point that you
| might want an optional animation mode for the the benefit
| of spectators, but it should be disabled by default. My
| short term memory lasts more than one second, so I don't
| need to be reminded that I just scrolled down after I
| scroll down.
| chefandy wrote:
| User testing disagrees. Most people find an instantly
| refreshing screen of text to be quite dazzling.
| Developers look at screens of text all day long-- they're
| much more tolerant to those sorts of transitions than
| most people are, and basing defaults on their usage
| styles is one of the reason most people find FOSS
| interfaces completely awful.
| mrob wrote:
| Most users only see animated scrolling at work (not
| genuine "smooth scrolling" tied to continuous touchscreen
| or touchpad input, which is unobjectionable, but playback
| of canned animations following completed input events).
| They have an obvious incentive to like it: they're
| getting paid for doing nothing.
| chefandy wrote:
| > They have an obvious incentive to like it: they're
| getting paid for doing nothing.
|
| Oh good lord: what an incredibly patronizing sentiment.
| If design makes an interface slower for its users to use,
| it's a bad design. What developers-- used to looking at
| entirely text-based interfaces and command lines-- expect
| in interface feedback is much different from what others
| expect from it. If it's a tool for which developers are a
| core group of users, it should communicate using their
| expected set of visual signals.
| mrob wrote:
| It's an major confounding factor in all productivity
| studies, and IMO underappreciated because UI researchers
| generally don't want to get involved in politics. Social
| status depends more on relative wealth than absolute
| wealth. When the owning class takes approximately 100% of
| the generated wealth from improvements, the direct
| effects of improved productivity only hurt the worker.
| (They gain indirectly, because improved productivity
| helps society as a whole, but the marginal gain to the
| worker from any individual improvement is always small,
| so there's a tragedy of the commons here and the
| incentive is always to resist improvements.)
| chefandy wrote:
| What an astonishingly bizarre non sequitur. Are you
| implying that someone's socioeconomic status affects how
| they perceive animations in interfaces?
| mrob wrote:
| Yes. I believe professionals are less tolerant of time-
| wasting UIs, in part because they stand to gain a larger
| proportion of the wealth produced by productivity
| improvements. If a faster UI just means you do more work
| while your boss gets richer, why would you want one?
| buran77 wrote:
| > They have an obvious incentive to like it: they're
| getting paid for doing nothing.
|
| My friend, this is weapon's grade ignorance, and this is
| a very, very charitable characterization. Your big idea
| is that people want these continuous transitions because
| they can waste a few minutes per day looking at them and
| be paid for it?
|
| Any person working together with someone else on large
| documents and their endless reviews, and definitely
| anyone who often has to follow documents on a shared
| screen knows the benefits of transition between states.
| Something that allows the eyes and brain to track the
| motion. Objects in real life don't jump between locations
| instantly so nothing about people is trained to follow
| such instant transitions. The fewer the cues about how
| things moved, the harder it is to follow.
| mrob wrote:
| The users' fingers don't jump between locations
| instantly. That already provides the motion cue. UI
| animations are _additional_ motion added after the
| natural motion has already completed.
|
| And I already agreed that animation can be beneficial to
| spectators, who don't have access to the natural motion
| cue, but that's a small fraction of total use.
| chefandy wrote:
| > Most "non-technical" people use computers, especially
| desktops, in a professional setting. Navigating those UIs
| is part of their jobs and they will spent hours upon hours
| doing so.
|
| Yes, but they still reason about those interfaces totally
| differently. This isn't a quantitative difference in
| competence, it's a qualitative difference in approach.
|
| > Pretty animations may make a good first impressions but
| they get old and annoying very fast. It is a huge mistake
| in UI design to only optimize for smooth on-boarding of new
| users and not for long term productivity.
|
| Animations that stick out as 'being animated' are rarely
| desirable. I assure you that you don't notice most of the
| animations you benefit from in your usage.
|
| > The reason most end-user-facing FOSS projects (that don't
| have foundation-funded UI teams like Blender or Mozilla
|
| > Blender has great UI because they are dog-fooding their
| own software through blender studio. Meaning because they
| are the users and develop UI based on their own needs,
| contradicting your theory.
|
| Do you have any actual evidence for the assertion that
| Blender's UI designers don't actually drive the usability
| of the software?
|
| > Firefox UI has gotten significantly WORSE over time and
| the browser is becoming irrelevant based on market share.
| Now that is not all the fault of the UI but it is still
| worth noting that the height of firefox popularity was when
| it had a very power-user friendly UI that all that fancy
| "UI experts" would hate. Maybe they should replace the
| "foundation-funded" UI team.
|
| You're substituting your opinion for fact. Mozilla's design
| team publishes a lot of stuff. If you think it's wrong,
| there's lots of specifics available for you to counter.
|
| > As for commercial software, modern UI is so bad that many
| "non-technical" users actively hate using computers and
| feel absolutely powerless when errors occur. Modern UI is
| actively user-hostile.
|
| This is a common trope among developers who think their
| feelings about interface design carry more weight than the
| research that actually tests these things. It holds about
| as much weight as any other feelings vs facts argument.
| cardanome wrote:
| > I assure you that you don't notice most of the
| animations you benefit from in your usage.
|
| I assure you, I do notice them. I am disabling them
| everywhere I can. I disable them in my Desktop
| Environment, I disable them on my Android smartphone. I
| am way more productive without them.
|
| Now, I don't hate animations per se. On the contrary as I
| dabble in game dev I find them crucial to "juice up" a
| game. They have their place but that is not productivity
| software that people are forced to use daily. They are
| for play not work.
|
| > This is a common trope among developers who think their
| feelings about interface design carry more weight than
| the research that actually tests these things. It holds
| about as much weight as any other feelings vs facts
| argument.
|
| Many open source devs are users of their software. You
| are making a false dichotomy where developer are some
| special creatures with totally different needs. I like
| what I like. There is no such thing as an "average user".
| People have different needs. Making software for the
| lowest common denominator will create UI that will be
| miserable for everyone to use.
|
| Now I am willing to listen to actual academic studies
| about UI design and productivity but your acting like
| some corporate internal studies are actually legit
| science is silly. We all know this things are are more
| drive by corporate politics.
| chefandy wrote:
| > I assure you, I do notice them. I am disabling them
| everywhere I can. I disable them in my Desktop
| Environment, I disable them on my Android smartphone. I
| am way more productive without them. Now, I don't hate
| animations per se. On the contrary as I dabble in game
| dev I find them crucial to "juice up" a game. They have
| their place but that is not productivity software that
| people are forced to use daily. They are for play not
| work.
|
| a) Ok so you disable mouseovers on all interface elements
| to indicate whether or not you're going to hit a click
| target, indicators of where windows are moving when you
| drag them and click indicator animations to show that you
| clicked on it, the minute amount of fadeout during the
| click animation on a number pad so you can enter values
| quickly while still seeing what keys you pressed,
| indicators for where something minimizes to or maximizes
| from, progress bars, blinking cursors, notifications...
| sure thing. If you think most UI animations are even
| remotely comparable to game UI animations, we're
| definitely not talking about the same animations
|
| > Now I am willing to listen to actual academic studies
| about UI design and productivity but your acting like
| some corporate internal studies are actually legit
| science is silly. We all know this things are are more
| drive by corporate politics.
|
| I'm not talking about internal corporate usability
| studies. Ideally, you should probably google something
| before you try explaining a field to a professional that
| works in that field.
|
| > Many open source devs are users of their software. You
| are making a false dichotomy where developer are some
| special creatures with totally different needs. I like
| what I like. There is no such thing as an "average user".
| People have different needs. Making software for the
| lowest common denominator will create UI that will be
| miserable for everyone to use.
|
| Firstly, judging whether or not software is usable by
| looking at the handful of people that already use it and
| built it is like polling people to see if the dinner they
| cooked themselves last night should win a cooking
| competition. If the goal of your software is only to
| serve the people that wrote it, then it doesn't matter.
| But the vast majority of open-source software is made for
| _other people to use,_ too which is why they _post it
| publicly on the internet._ I 've contributed probably 10k
| hours of coding time to FOSS projects, all of which had
| the specific goal of serving people outside of the small
| pool of maintainers.
|
| Secondly, you accuse me of treating developers like
| they're special but then say that design which doesn't
| focus on developers' workflows is coding to the lowest
| common denominator. Gotcha.
|
| Thirdly, the entire point of the discipline of interface
| design is breaking the idea that there is an average
| user. How do we accomplish that? By not letting people
| make unilateral decisions about design based on their
| assumptions and folk wisdom, consult existing data that
| influences how we proceed, and test our assumptions on
| the people who actually use the software. If you're
| saying that developers unilaterally making design
| decisions are _more open_ to different usage styles than
| a designer that is specifically looking at people 's
| usage, I'm not really sure how to address that.
| James_K wrote:
| > even "feel" does matter to most users
|
| And I think most users would prefer software that does stuff
| instantly. Attaching little animations to everything is just
| silly and distracting. It only happens because someone had
| nothing better to do but still had to look busy. These things
| almost universally degrade the interface and I've yet to see
| the actual benefit of them, aside from the fact that they
| draw attention to themselves and make people think "someone
| put some work into that". When you think about it, that is
| the opposite of good interface design. A good interface is
| one you do not notice - it puts as little as possible between
| user and machine.
| motoxpro wrote:
| Almost no Apple interactions are without animation. It's
| actually hard to find something that's NOT animated on
| Android AND iPhone. For most users, the iPhone is one of
| the gold standards for "good feel".
|
| Some people like the unrealistic jumping of no animation,
| which is totally fine. Some people want it to "feel like a
| computer" not how things actually behave in the real world.
| It's taste. Animations that are too long or too noticeable
| are bad taste. But animations themselves are not bad.
| James_K wrote:
| Switches in the real world tend to snap almost instantly
| from one end to the other. That is the defining feature
| of switches - that they don't have a slow transition
| between the states. This animation stuff isn't realistic,
| and even if it was that isn't an argument for it.
| Slartie wrote:
| But when you move a switch like the ones demonstrated
| here in the real world, you have the haptic feedback of
| moving the pin physically, of it "snapping" into place.
| And that's how you know that your switch toggling was
| successful.
|
| The "digital switch" does not have that. You usually
| don't even "move" it, as in "move the finger over the
| screen", but you just touch it. And your finger obscures
| the UI component in the moment you touch it, without any
| haptic feedback (except for your finger hitting the
| screen somewhere, but that does not necessarily mean that
| the switch has toggled). The animation replaces this
| missing haptic feedback, by your eyes seeing the switch
| moving, when you remove your finger after touching the
| screen.
| kkoncevicius wrote:
| I agree more with James K on this, but see your point
| too. Maybe this should be abstracted away such that each
| person can set their own preference which would be
| applied across all websites. Similarly how some of them
| respect your theme (dark vs light), they could be made to
| respect the animations, so that all toggles behave the
| same way (fast animation / smooth animation / instant).
|
| I would choose instant thou.
| d0gbread wrote:
| Or use a checkbox and stop trying to make toggles a
| thing, since they just don't translate to digital as
| well.
| andrewaylett wrote:
| I don't know about your switches, but mine definitely do
| need to pass through the intervening space between
| states.
|
| That's not an argument for _slow_ transitions, but _some_
| transition is realistic.
| mrob wrote:
| The transition is already there, on the actual switch (or
| the deformation of the fingertip with touchscreens). The
| animation is a _second_ transition played after the first
| one is already complete. That is not realistic.
| carlosjobim wrote:
| There are not many animations on iOS nor MacOS. What they
| are is movement that corresponds to the users movements.
| Like opening expose with the touchpad on MacOS is not an
| animation, the windows follows the movement of your
| fingers. Likewise scrolling is not an animation, because
| it follows the users movements.
| iainmerrick wrote:
| _And I think most users would prefer software that does
| stuff instantly_
|
| Hmm, users certainly prefer software that's fast, but I
| don't know about "instantly".
|
| Feedback is important. A button that gently clicks so you
| know it took effect is better than a touch sensor with no
| feedback. Animations can serve the same purpose as that
| click. (And of course they can be overdone, just like a
| button can be overly stiff or loud.)
| chefandy wrote:
| > And I think most users would prefer software that does
| stuff instantly
|
| User research feels differently, but with numbers.
|
| > These things almost universally degrade the interface and
| I've yet to see the actual benefit of them
|
| See my point about technical people and their usage
| perspectives.
|
| > When you think about it, that is the opposite of good
| interface design.
|
| Having been a professional software designer, I assure you
| I've thought about this. And explored it, researched it,
| tested it, prototyped it, interviewed people about it,
| built it, rebuilt it, and then did it all over again to
| improve it. Re-read the last paragraph in my comment.
|
| > A good interface is one you do not notice - it puts as
| little as possible between user and machine.
|
| On second thought, re-read the whole comment.
| James_K wrote:
| Actually I think you should re-read my comment. I'd also
| love to actually see the research you're talking about
| here.
|
| > I assure you I've thought about this. And explored it,
| researched it, tested it, prototyped it, interviewed
| people about it, built it, rebuilt it, and then did it
| all over again to improve it.
|
| Oh, sorry, I didn't realise I was talking to the world
| expert on button animations. So do users prefer quadratic
| or exponential smoothing on their switches?
| chefandy wrote:
| > Actually I think you should re-read my comment.
|
| Ok, done. Still didn't see anything beyond assertions
| based on nothing but your own preference, and countering
| things I said without any support.
|
| > Oh, sorry, I didn't realise I was talking to the world
| expert on button animations. So do users prefer quadratic
| or exponential smoothing on their switches?
|
| Of course I didn't say I was the world expert in button
| animation, but I'm far beyond the age where I feel
| compelled to pretend random developers' uninformed
| opinions on design are as useful as mine. Lots of
| developers get really mad when people point out that that
| their software development expertise doesn't make them
| experts in all other fields, but that's a _you_ problem.
| James_K wrote:
| > I'm far beyond the age where I feel compelled to
| pretend random developers' uninformed opinions on design
| are as useful as mine.
|
| Yet your opinions are also uninformed. Or you've done
| precious little to convince people otherwise. Perhaps you
| should make arguments instead of just saying you have
| experience and it makes you correct. Does acting
| conceited often convince people of your perspectives? No?
| Then why do it? Surely telling me your thoughts would be
| much more convincing than simply asserting that you've
| had them.
|
| > and countering things I said without any support
|
| You are the one claiming to have numerical evidence to
| support your conclusions and failing to provide it. I
| think it is unreasonable to expect me to give that which
| you cannot.
| chefandy wrote:
| > You are the one claiming to have numerical evidence to
| support your conclusions and failing to provide it. I
| think it is unreasonable to expect me to give that which
| you cannot.
|
| That appropriately applied animations are a valuable part
| of interface usability is not controversial. A four
| second google search will confirm that and I'm not going
| to do that for you just because you refuse to look.
| Anyone dismissing the idea out-of-hand based on their own
| preferences and assumptions has the burden of proof.
|
| > Yet your opinions are also uninformed. Or you've done
| precious little to convince people otherwise. Perhaps you
| should make arguments instead of just saying you have
| experience and it makes you correct. Does acting
| conceited often convince people of your perspectives? No?
| Then why do it? Surely telling me your thoughts would be
| much more convincing than simply asserting that you've
| had them.
|
| Yes. How conceited of me to not scramble to go grab
| citations for a bunch of people in a completely different
| field asserting that they know more about design than
| designers. Surely if you stumbled upon a bunch of
| designers making sweeping, arrogant, unsupported
| declarations about software development and the
| incompetence of developers, you'd trip over yourself to
| gather any evidence they demanded to prove your point
| when you corrected them on their foundational misgivings.
| Surely you wouldn't just tell them to go google it for
| themselves.
|
| _" Am I out of touch with the current state of design?
| No: it's the designers who are wrong."_
| James_K wrote:
| > appropriately applied animations
|
| Appropriately applied anything is good. I am disputing
| whether this is an appropriate application.
|
| > How conceited of me to not scramble to go grab
| citations
|
| This what not conceited. There is nothing wrong with not
| having the numbers for something, you should just try to
| avoid claiming you do if you can't actually find any. The
| conceited bit was your general attitude. Writing many
| lines of text about how much experience you have, how
| everyone else is stupid and has worthless opinions, etc.
|
| > Surely if you stumbled upon a bunch of designers making
| sweeping, arrogant, unsupported declarations about
| software development and the incompetence of developers
|
| I would likely agree with them. Most software is quite
| bad, and most of it isn't designed much better. When I
| say a lot of designers are wasting time on this stuff, I
| base this on developers doing the same thing. If the
| people making these claims were incorrect about
| something, I would simply explain why that is rather than
| saying "I have a bunch of experience that you don't have
| and there are some studies that prove your silly little
| feelings wrong. Your opinions are worthless compared to
| mine." The reason I wouldn't say this is because it's
| conceited and it doesn't convince anyone of anything.
|
| > "Am I out of touch with the current state of design?
| No: it's the designers who are wrong."
|
| I am more concerned with what users think than I am with
| the current trends in design. Anyone can be a designer,
| that doesn't mean they know what they're talking about.
| chefandy wrote:
| > Appropriately applied anything is good. I am disputing
| whether this is an appropriate application.
|
| Ok, explain why this animation is not an appropriate
| application of this animation in a technical
| demonstration of this animation.
|
| > I would likely agree with them. Most software is quite
| bad, and most of it isn't designed much better. When I
| say a lot of designers are wasting time on this stuff, I
| base this on developers doing the same thing.
|
| Copout.
|
| > If the people making these claims were incorrect about
| something, I would simply explain why that is rather than
| saying "I have a bunch of experience that you don't have
| and there are some studies that prove your silly little
| feelings wrong. Your opinions are worthless compared to
| mine." The reason I wouldn't say this is because it's
| conceited and it doesn't convince anyone of anything.
|
| Read the comment I wrote initially, where I explained, at
| length, why the comment I responded to was not correct.
|
| > I am more concerned with what users think than I am
| with the current trends in design. Anyone can be a
| designer, that doesn't mean they know what they're
| talking about.
|
| Yes, anybody can be an anything, and luckily we've got
| gobs of Dunning-Kreuger mountaineers in the software
| business to assess their competence.
| usrusr wrote:
| > A good interface is one you do not notice
|
| A good animation is one you do not notice. Subtlety that
| succeeds in loading off its feedback payload in your brain
| without exposing the transmission mechanism to the
| conscious level of perception.
|
| Chances are you are only complaining about the subset of
| animations that failed to stay under that threshold. Yes,
| slow, elaborate animations are bad.
| James_K wrote:
| I agree. I don't have any issue with animations that I
| don't notice. So why bother with them? It seems like the
| best way to avoid me noticing something is not to put it
| there to begin with.
| arnorhs wrote:
| >As someone with a good amount of professional experience
| both as a developer and a designer, I'm consistently
| surprised by how quick so many developers are to assume their
| personal usage habits, osmosis-gained knowledge from
| projects, and folk wisdom about design trumps the expertise
| of seasoned credentialed professionals in the field.
|
| Same here, and couldn't agree more. Except that I'm not
| surprised.
|
| The thing is, developers with this pov have often been
| exposed to really shitty UIs where there's poor design
| aesthetics, matched with no understanding of the user's
| problems, coupled with fancy effects, that end up getting in
| the way and breaking in subtle ways - and ultimately don't
| represent what the developer is trying to do.
|
| People have a varying level of being exposed to such UIs, but
| professional developers, esp. dealing with enterprise portals
| and internal systems have been really burnt by this.
| chefandy wrote:
| > poor design aesthetics
|
| Sorry to be nitpicky-- I largely agree with your comment--
| but I always must point out that interface design is a
| communication medium, not an aesthetic medium. Like
| technical writing, it's a communication medium even if
| there are some secondary aesthetic considerations.
| ratiolat wrote:
| When has the switch been toggled though and how can I know in
| each implementation?
|
| 1. Is it when I pushed the toggle, regardless of when
| animation finishes? 2. Is it when the animation finishes
|
| This is necessary when flipping many toggles on one page and
| it needs to be done many times over. In case there's no
| animation, it simple and clear. In case there's animation you
| need the know is it case 1 or 2. If it's case 2 it will
| additionally slow you down as you now need to wait until all
| animations lengths * number of switches toggled has finished.
| layer8 wrote:
| > the expertise of seasoned credentialed professionals in the
| field
|
| Given how bad UIs in general have become, some scepticism
| over that expertise is warranted.
|
| To be clear, UIs weren't all great across the board 20 years
| ago. But there was a general agreement between UI experts and
| power users on how a good UI with standard desktop controls
| should look like and behave, whereas now it's a mess and
| there are significant disagreements.
| chefandy wrote:
| > But there was a general agreement between UI experts and
| power users on how a good UI with standard desktop controls
| should look like and behave, whereas now it's a mess and
| there are significant disagreements.
|
| Details?
| klabb3 wrote:
| > I'm consistently surprised by how quick so many developers
| are to assume their personal usage habits, osmosis-gained
| knowledge from projects, and folk wisdom about design trumps
| the expertise of seasoned credentialed professionals in the
| field
|
| Spot on. Devs have on average extreme levels of confidence in
| unrepresentative opinions (space bar heating) and think UI is
| beneath them.
|
| > FOSS projects (that don't have foundation-funded UI teams
| like Blender or Mozilla) are used almost exclusively by other
| developers
|
| Nobody is better at pissing away hard labor like devs. There
| are these amazing OSS projects with 10ks of man hours
| invested, that won't let designers near their cluttered
| prototype ui, if any. Designers are meme-famous as working
| for free - harnessing their power in FOSS would be akin to
| convincing a child to eat ice cream. Yet they're unable to.
|
| Note this is not only UI, but general theory of mind skills.
| How many times have you read a README on GitHub where it's
| written like the most over-cryptic nonsense, despite being
| quite general and straight forward projects under the hood?
| My working theory is UI skills and "explaining things" are
| fruits from the same tree. Most devs don't practice it, so
| they get deep into curse of knowledge territory. Even the
| smart have blindspots, maybe especially them.
| Anotheroneagain wrote:
| I feel like UI has changed to aim purely at the new user, at
| the expense of long term users. Its only focus is to be
| understandable as soon as possible, but cuts out everything
| that allowed to do things better once you understood it more
| in depth, as the depth isn't there. All that remains
| accessible are the black boxes that can be easily understood
| by someone new.
| adrianmonk wrote:
| Here's one practical benefit: the UI should make it obvious
| that your click did successfully register, and an animation
| does that because it's eye-catching.
|
| But the other side of the coin is that, _because_ it is eye-
| catching, animation can be distracting or annoying.
|
| Adding animation to your UI is like adding salt to your
| cooking: it's going to be pretty bland without it, but you can
| also ruin things by going overboard.
| chefandy wrote:
| Most people that complain about these things don't even
| realize how much of it is integrated into their daily lives
| and workflows because it's too natural to notice. You don't
| need experience to see when someone's done a shitty job,
| though; just like any other tool, inexperienced people often
| see poor outcomes as an indictment of a technique, tool, or
| approach when the practitioner is to blame.
| alpaca128 wrote:
| I think that's a bit of an exaggeration. Yes, animations
| are useful sometimes, but in at least 90% of cases they
| make the experience worse. If animations were so important
| and integrated everywhere then why didn't I notice any
| change when enabling "reduce animations" on all my devices,
| other than everything being suddenly faster?
|
| > inexperienced people often see poor outcomes as an
| indictment of a technique, tool, or approach when the
| practitioner is to blame.
|
| Or they simply realized that so many practitioners are to
| blame that the distinction barely matters anymore.
| chefandy wrote:
| > Yes, animations are useful sometimes, but in at least
| 90% of cases they make the experience worse. If
| animations were so important and integrated everywhere
| then why didn't I notice any change when enabling "reduce
| animations" on all my devices, other than everything
| being suddenly faster?
|
| You're confidently saying it makes the experience worse
| but you said you didn't notice a difference when it went
| away? There's a lot of data out there that says
| otherwise. Once again, developers use of interfaces
| differs from regular users as much as professional cooks
| use of kitchen equipment differs from home cooks. It's
| _very different._
|
| > Or they simply realized that so many practitioners are
| to blame that the distinction barely matters anymore.
|
| Sorry, no. Most shitty software design is done by
| developers that assemble interfaces based on their whim,
| most of the rest are done by developers trying to mimic
| what they think a designer might do (which most
| developers mistake for design,) and the small remainder
| are from either incompetent designers or genuine
| misfires.
|
| Ask any group of professional photographers how many have
| tried Gimp in an attempt to avoid Adobe's fees-- almost
| all of them will say they have. Ask how many actually use
| it? I'd be shocked to find a single one. Aside from the
| substandard graphic design tools for things like
| typography (which are totally reasonably not a focus for
| the project, especially when Inkscape is solid there,)
| Gimp is a competent photo editor. Who uses Gimp?
| Developers that need a photo editor. Developers making
| software that other developers like to use is not an
| indicator that they know how to make software that's
| tolerable for other people.
| alpaca128 wrote:
| > you said you didn't notice a difference when it went
| away?
|
| No, I said no difference "other than everything being
| suddenly faster". I'd say about 1-5% of animations are
| actually useful but I still wouldn't miss most of them.
|
| > There's a lot of data out there that says otherwise
|
| I would love to see that data. Not sure what your opinion
| on Gimp's UI design or its popularity has to do with the
| value of animations, or lack thereof.
| eviks wrote:
| Great UI goal, though what's catching is the change in visual
| state and colors, which also happens without extra animation,
| or you can add an extra highlight of the changed item to
| emphasize the change if state, so this doesn't address the
| specific issue
| ramesh31 wrote:
| Animation should enhance and enrich the UI, not make it "look
| fancy". Apple gets this perfectly. The squeeze animation on
| iOS's volume bar is a great example. Providing _feedback_ to
| the user in response to an action, in a manner that is expected
| and makes sense, can massively increase UX.
| youssefabdelm wrote:
| Exactly, to the OP of parent comment, this talk is a great
| overview of exactly this point:
| https://developer.apple.com/videos/play/wwdc2018/803
| eviks wrote:
| Apple is missing a few bites from its perfection:
|
| They use these sliders, realize they could be ambiguous, so
| add an accessibility setting for the on/off labels.
|
| Then they have these fancy animations where holding a slider
| even elongates the button "providing feedback", but this is
| just wasted since your finger is covering the button, and
| fingers have no eyes!
|
| But still, it's a slider, so you'd expect that if you slide
| your finger over it, it will move. Not so fast, this only
| works if your started sliding from the slider, not from a
| side outside it (which would still work in the "real"
| world.). But if you start at the slider, then there is no
| point in sliding, there is simply not enough width for that!
|
| Also if slider's button is to the left and you swipe from
| right to left, the sliders moves right! Take that, immediate
| fedback in the opposite direction, massive UX boost in a
| manner that's unexpected and doesn't make sense! (because
| it's not a real slider, just a check box of a different form)
| bobbylarrybobby wrote:
| Computer UIs need animations for the same reason they need
| shadows, gradients, and momentum: because these are aspects of
| the physical world that we already know how to interpert, so
| can be used "for free" to aid our understanding of the UI.
| _Not_ using animations would likely be more taxing on our
| visual processing because nothing in the world moves
| discontinuously, so that would be a new thing to learn when
| using a computer. The primary reasons not to use an animation
| should be technical: you can 't have it run in a short enough
| time and still look good, not drop frames, conserve battery
| life, etc.
| dietr1ch wrote:
| Well, some constructs need animation, but others can work out
| just fine without animation. When typing, I want the
| characters to show right away, and instead of using a switch,
| I could use a checkmark that I wouldn't mind getting checked
| too fast assuming that the context isn't full of checkmarks.
|
| I think that we have tools in the UX toolbox that are less
| reliant on animations than others, but yeah, if you can get
| animations to be neat, yet fast it's great unless battery
| life is also a big concern.
|
| TBH, animations only began to be acceptable to me once I got
| a high refresh rate screen and a fast computer, before that I
| knew they were speed bumps for my old hardware and maybe
| hated them a bit more than they deserved.
| croes wrote:
| Then a toogle button is a bad example. It's a replacement for
| checkbox and adds ambivalence that the checkbox doesn't have.
|
| Can you tell me which position of the toggle means on? Purple
| or green.
| chii wrote:
| the color choice is the problem, not the toggle.
|
| If you had red or green, which one is on?
| daniel_iversen wrote:
| If you were colorblind that could be harder to answer
| (plus, it seems like a lot of designs have color
| "themes"). Checkbox is probably best.
| waveBidder wrote:
| lets ask someone who's colorblind
| bongodongobob wrote:
| Red green colorblind checking in. In the case of a
| toggle, left is off, right is on. Up is on, down is off.
| Red tends to have less chroma, so dark is off, light is
| on if there aren't any other cues.
| vidarh wrote:
| While that seems to be _more common_ by a fairly large
| factor, in a quick search of images of toggle buttons
| there were at least two examples of left being on already
| in the top 10 for me.
|
| I also found a few that had _both variants_ in the same
| image, and a few examples where from the image alone I
| couldn 't tell if my life depended on it whether they are
| in the left or right position, and what that means
| because there's no shading or geometrical hint as to
| which part is meant to be the actual toggle.
|
| I wish you were right and that this was consistent, and
| when I read it I did that image search because I hoped
| you were and that I somehow just hadn't realist. But
| sadly it's not consistent.
|
| That said, the same image search also demonstrated people
| managing to mess up the equivalent of a checkbox too (by
| changing the label, so it's not clear if it needs to be
| "ticked" to _disable_ the state currently indicated by
| the label) so it 's clear the problem isn't just checkbox
| vs. toggle.
| rypskar wrote:
| >>Up is on, down is off
|
| That depends on where you are from, in some regions light
| switches are on when up and in other places they are off
| when up
| slimsag wrote:
| I am profusely colorblind, and it's infuriating when
| people only use colors to indicate something.
|
| Please for the love of god give me a checkbox over a
| red/green slider toggle. Shapes, please, shapes.
| bongodongobob wrote:
| I'm colorblind too but I don't pretend that it's a big
| deal, because it's not even a daily occurrence where I'm
| completely stumped by color and am blocked from doing
| something. Yeah, charts and graphs can be annoying
| sometimes, but I don't expect 90% of the world to bend
| around me because my sight is sub par. I loathe
| colorblind people who act like it's a disability. It's a
| slight inconvenience sometimes.
| eru wrote:
| Adding extra differentiators also helps people with other
| kinds of vision problems. The benefits of accessibility
| often go beyond the initial target audience.
| slimsag wrote:
| 300 million people with some form of color blindness, and
| for a minority of those it's much worse than others. It's
| great your vision doesn't affect you most days, I hope
| you live a happy life.
|
| For me, it's pretty annoying having to screenshot
| applications every few days, to be able to drag it into a
| color picker to be able to see what is actually on the
| screen.
|
| It's pretty annoying being in a Zoom call, in a tense
| customer call trying to debug something, and then having
| to screenshot a Grafana dashboard and drag it into a
| photo editor on the fly to understand what a customer is
| telling me - or have to divert the already tense
| conversation to 'sorry can you tell me what I'm looking
| at, my vision is fucked?'
|
| It's pretty annoying always being that inconvenience-to-
| others person asking for a link to the google slides,
| because I can't tell what is being shown on that pie
| chart.
|
| And I get it, I'm in a minority of minorities here. And
| it's not like 'wow colorblindness has ruined my life now
| I can't cook or clean myself!' - so I understand where
| you are coming from with 'it's not a real disability'
|
| But like, I'm not asking for you to go and construct a
| concrete pathway up a mountain here.
|
| I'm just asking that maybe when you are quickly adding 'a
| slider that indicates on/off using nothing other than
| color' to your shitty web app, that maybe you could just
| go with a checkbox instead? Or keep the slider and all
| the colors, but just add `on` and `off` labels to it too?
| Or add a hover text that says it's 'enabled'? Or at least
| steal Apple's slider colors instead of coming up with
| your own low-contrast ones?
|
| And yeah, I get it - we live in a world of 'omg wow I got
| glasses for christmas and now I can finally see color
| through my tears again!!!' social media garbage content.
| I just want to be able to know what a button is going to
| do when I click it.
| krzyk wrote:
| But, making UIs tuned for colorblind people make it
| easier also for others - colors should be distinguishable
| easily.
| function_seven wrote:
| Depends on what it's controlling. The tune of my car? Red
| = performance, green = eco-mode.
|
| The valve on a pipe? Red means "stop" (off) and green
| means "go" (on).
|
| What about a heater? Does red mean hot? Or stopped?
|
| Sibling comments cover colorblind users, but those
| concerns also apply to most e-ink users as well.
| idiotsecant wrote:
| In fact red and green are generally _not_ used for flow
| in a pipe because they have specific meaning for
| electrical equipment - green denotes an open circuit and
| red an energized one. This can be extremely confusing
| with something like an MOV so convention us to avoid red
| and green on valve position, pipe fill, etc.
| smaccona wrote:
| Am I wrong in thinking that
| checkboxes/tickboxes/whatever-one-calls-them are
| ubiquitously understandable across cultures from both an
| interpretation and interaction perspective? If so, it
| wouldn't be the first time I've made this
| assumption/mistake so I'd be happy to hear about it!
|
| If not (and I am right in thinking these are globally
| understood), then there's a clear advantage of the
| checkbox over the switch in that it doesn't depend on any
| color recognition to convey the current state. This is a
| huge win - I have definitely encountered UI controls
| where the current state was not at all apparent.
|
| I happen to use an iPhone, and haven't personally had any
| issues interpreting the "switch" state nor the checkbox,
| but what if you're color blind or from a culture where
| the color doesn't necessarily mean what you think it
| does?
|
| Edit: clarify intent
| jalfresi wrote:
| Checkboxes also have a fundamental dependency on the
| label to assist them with their affordance: a label for a
| checkbox should almost always be in the form of a yes/no
| question: "are you hungry? [ ]"
|
| The "checked" box is an affirmative, empty is a negative.
| A checkbox without a label is useless because it has no
| context.
|
| But I constantly see checkboxs without the question
| label. Think back to all those control panels and
| settings windows youve seen where the label for a
| checkbox is something like "animations [ ]". Does that
| mean they are on by default? Does checking the checkbox
| switch them on or off?
|
| Now compare with this "animations? [ ]" checking the
| checkbox has now become an answer to a question
| chrisjj wrote:
| > But I constantly see checkboxs without the question
| label.
|
| Properly so.
|
| Imagine every real-world appliance power toggle was
| labelled "Power?".
| jalfresi wrote:
| Real world appliances dont use checkboxes to power toggle
| chrisjj wrote:
| Checkbox is nearest in equivalence.
| krzyk wrote:
| Not color choice, but existence of color. Some people
| have trouble distinguishing between red and green.
|
| Black and white is easy - checkbox is understandable
| quicker than a toggle.
| dgellow wrote:
| Try to disable/reduce animations in your OS via accessibility
| settings, you will see that you really don't lose much.
| King-Aaron wrote:
| I have a different definition of what a "need" is.
| coldtea wrote:
| > _Computer UIs need animations for the same reason they need
| shadows, gradients, and momentum: because these are aspects
| of the physical world that we already know how to interpert,
| so can be used "for free" to aid our understanding of the UI_
|
| More like "for the same reason a fish needs a bicycle".
|
| > _Not using animations would likely be more taxing on our
| visual processing_
|
| And yet, Windows 2000 era UI was far more intuitive,
| consistent, and self-discoverable than today's animated,
| shadowed, gradient-filled, blurry transulcent, momentum-
| having flat crap.
| eru wrote:
| Isn't shadowed and flat sort of the opposite of each other?
| coldtea wrote:
| Amazingly, not in 2024.
|
| They put shadows on otherwise flat layers - for
| gratuitous effect, but also to get back some separation
| after they've flattenned everything.
| wolpoli wrote:
| The shadow is around flat piece of paper of zero height,
| levitating off the background, casting shadow 360 degrees
| all around. No physical lighting set up could produce
| this effect.
| coldtea wrote:
| Exactly. "Environmental cue" my ass :)
| ygra wrote:
| Isn't that the effect you get when you have a large
| diffuse light source directly above?
| coldtea wrote:
| Not with a "flat piece of paper of zero height"
| wolpoli wrote:
| If you have a diffuse light source, let's say 8dp,
| directly above the component and the component is also
| 8dp above the background, then it'll look right for one
| component.
|
| To account for the lack of parallex effect in the shadow
| when there are multiple components, you will then need a
| telephoto lens zoomed through the light source from a
| huge distance. I think we'll need a ring light.
| ulrikrasmussen wrote:
| Got any research to back up that claim? I always go to the
| developer settings and turn off all animations on my Android
| phones, and it makes a monumental difference in usability,
| exclusively for the better. I did it on my moms phone as
| well, and she instantly felt it got faster, so this is not
| just because I am a technical person.
|
| Some UI designers think animations are good, but they are
| not. They are a clutch that designers who don't know how to
| design good UIs rely on to indicate what is going on. We have
| never had faster computers than we do now, but we are
| collectively spending thousands of hours a day waiting for
| pointless animations to finish.
| geysersam wrote:
| Wow just did what you suggested and indeed it feels much
| faster. I was sceptical at first but this is actually
| better.
| arcastroe wrote:
| Thank you for this. I didnt know I wanted disabled
| animations until I tried it just now.
| alpaca128 wrote:
| > Some UI designers think animations are good, but they are
| not
|
| Imho animations are not a problem _in cases where they do
| not affect latency_. For example a visual click feedback to
| tell the user that it was registered & is being processed
| makes sense, especially for situations where the task may
| take a while. For example Mac OS' "eject drive" button
| would benefit from this, it has zero visual click feedback
| while ejecting the drive can take a whole minute for some
| reason. Yet at the same time Apple simply refuses to remove
| the 1 second long workspace switch animation even if
| blocked in the accessibility settings, they only swap the
| swiping animation with a fading animation.
|
| The problem is that often designers simply don't put any
| thought into it other than "make it smooth and look nice".
|
| In cases where the animation affects latency between user
| input and reaction to it there is no animation speed that's
| fast enough. It will always feel like wading through a
| swamp.
| ulrikrasmussen wrote:
| Completely agree. And in 99% of cases, an instant
| indicator is enough and you don't need an animation.
|
| The few places where animation makes sense are places
| where it is natural. For example, smooth scrolling and
| scroll acceleration in touch interfaces _have_ to be
| animated to work, and they actually improve usability by
| allowing the user to work less.
|
| I think most modern user interfaces are designed to look
| great for people who aren't actually using them, i.e. in
| demos and in stores where you pick up a phone to look at.
| In that case flat UIs with smooth transitions and shadows
| will, to the naive eye, look way more polished than UIs
| with proper contrast and no animations. This is also the
| reason that TVs come with ridiculous default settings for
| sharpening, contrast and frame interpolation, not because
| it actually is better, but because it looks better in the
| store and therefore sells better.
|
| But UIs that you use every day shouldn't look great, they
| should allow you to get actions done as quickly as you
| can think of them, and effectively serve as an extension
| of your thought process.
| mrob wrote:
| Feedback affects latency when working fast. Feedback is
| in the critical path because the user can't look away
| until they've confirmed they made their input correctly.
| To do otherwise risks desynchronizing their mental state
| from the computer's state.
| piyush_soni wrote:
| I would always do that on my previous (slower) Android
| phones, but it's NOT because they added to the usability,
| just that they slowed down the interaction significantly
| when the GPU etc. were not capable enough. On my latest
| Pixel, I don't do that anymore and just enjoy the
| animations because they don't slow down my daily
| interactions anymore. So your point does not actually
| convey that Animations are useless. They just have a toll
| on performance, yes. They always will. (I work in an
| industry where we spend a lot of time perfecting 3D
| geometry animations, because our users prefer it).
| eviks wrote:
| This appealing fallacy is part of the reason, but way too
| broad in general (and is also not reflected in the flat
| design land of today, but even before that almost nothing was
| really skeumorphically close to reality), so let's try to
| apply it to this specific case: you usually click on a
| slider, not drag it. So in this case, there is nothing
| "physical" on the user's intuition side that corresponds to
| the slider sliding. But that's exactly my question - what's
| the point of emphasizing the sliding? And taken your physical
| connection into account, the UI element should become a
| button
|
| And if you expect users to slide, then the slider should
| reflect the speed of your mouse like a physical control
| commongly would, not that of some random algorithm, no?
| jotaen wrote:
| > what's the point of emphasizing the sliding?
|
| Because the "knob" changes position. Like in the real
| world, objects can't disappear in one place, and then
| instantly appear in another. Animating a UI state change in
| terms of a move transition can help people to understand
| how both end-states are logically connected to each other.
| The animation resembles the mechanics of the slider knob
| being a "perpetual entity" that can move between two
| positions, rather than the slider control as a whole being
| some sort of static icon that is instantly swapped out for
| another static icon once I click on it.
|
| Whether or not animations are necessary might still be
| arguable. I suppose it depends on the complexity of the UI
| control, on personal preference, and certainly also on the
| general level of technical familiarity of the end-user.
| alpaca128 wrote:
| I don't know about you but I probably wouldn't notice if
| my light switch suddenly moved to the opposite position
| instantly instead of in 50ms or something.
|
| And animations wouldn't be quite as annoying if they
| actually were that fast.
| jotaen wrote:
| You might not consciously observe how your light switch
| transitions to the opposite position, but I'd argue that
| most people still have an immediate and intuitive
| understanding of how both end-states of a light switch
| are related to them applying physical force onto the
| switch.
|
| The toggle transition is supposed to resemble this
| notion, and aims to allow the user to build up an
| analogous mental model of cause and effect.
|
| To me, this sounds like a valid and worthwhile idea in
| general. That animations are not always appropriate or
| fitting, or that they sometimes are laggy and sluggish,
| is a different story.
| jalfresi wrote:
| Im not sure I agree with this, and its quite a common
| argument for animations in UIs. The fundamental weakness in
| this argument is that animations are not interactive. They
| have a beginning, middle and end. Any attempt to interact
| with the UI during this sequence would disrupt the animation.
| This is why animation makes UIs feel slow; clicking the
| widgets requires a period of time to transition from state A
| to state B via animation. The irony is that this is used to
| indicate a transition, to emulate what happens "in the real
| world sliders dont teleport to the next state", but this
| often always misses the fact that I didnt slide the slider to
| its new state: i clicked a mouse button. That is an immediate
| state transition. So all animations like the above do is slow
| the feedback of the state transition in a misguided attempt
| to emulate a real world slider when i never interacted with
| the UI in any way that resembles a slider.
| pupileater wrote:
| This is why we design animations in immediate actions to be
| below 100ms, any more than that and we start to feel
| "computer's reaction is slow maybe it's doing some
| calculations in the background?"
| mrob wrote:
| 100ms is more than enough to break the joyful feeling of
| the computer becoming part of my own body, like a hand
| tool or a bicycle. Humans are adapted to tool use, and
| don't need to consciously think of the position of tools
| they're using. But this effect only works if the tool
| moves like an ordinary physical object. If you move a
| pencil, it just moves. It doesn't move and then move
| again because a designer wanted to play an additional
| animation after your movement. Until we have direct
| neural interfaces, all UI animation playback is
| unrealistic, because it's adding to the physical movement
| of your fingers, not replacing it.
| wolpoli wrote:
| > Computer UIs need animations for the same reason they need
| shadows, gradients, and momentum:
|
| The thing about design principles is that the designer picks
| the one that justifies their decision, which is more like
| fashion than anything.
|
| For example: Windows 8 swept away shadow, and semi-
| transparent material in the name of flat design, making it
| resemble Windows 2.0. Windows 10 brought back shadow. Windows
| 11 brought back Semi-transparent material and also rounded
| corners buttons from Windows 2.0.
|
| Gradients have been banished and missing for a decade, but I
| am waiting for a come-back.
|
| > because these are aspects of the physical world that we
| already know how to interpert, so can be used "for free" to
| aid our understanding of the UI.
|
| The above could also apply to more than just shadows,
| gradients, and momentum.
|
| Skeuomorphic icons help users understand functions but we
| have shape & outlines resembling hieroglyphs. I doubt we are
| getting skeuomorphic icons back ever because font icons are
| just too awesome for designers.
|
| Most real world buttons are elevated off the surface to let
| us know it is pressable, but digital buttons now just have a
| white or colored pill shape around it. I can't recall the
| last time I saw a pill shaped button in the real world.
| faceplanted wrote:
| > Most real world buttons are elevated off the surface to
| let us know it is pressable, but digital buttons now just
| have a white or colored pill shape around it. I can't
| recall the last time I saw a pill shaped button in the real
| world.
|
| Well not really, real world buttons are elevated off the
| surface because of the practicalities of producing buttons
| and attaching them to a surface, some of the material has
| to be above the surface and some below for it to clamp on.
| Buttons are also usually produced as separate components
| and thus tend to be round or square because it's more
| mechanically simple and suits the most use cases, labels
| can be put around the button.
|
| Computers have completely different mechanics, all buttons
| can be a bespoke size and shape, and they're inherently not
| tactile, the pill shape is just the easiest way to allow a
| button with variable width for variable font sized text,
| because it's easier to put the text on the button itself
| digitally than irl.
| aembleton wrote:
| In the real world, toggle switches cannot jump instantly
| from one state to another but on a computer they can
| because of completely different mechanics.
|
| Either we want to resemble the real world or we don't or
| it depends on what is currently fashionable.
| dgellow wrote:
| "Accessibility > Reduce animations" is the magic trick to make
| modern UIs feel snappier and less distracting. I wish web UIs
| would respect it.
| morsch wrote:
| I was wondering if they even could. The answer is yes:
| https://developer.mozilla.org/en-
| US/docs/Web/CSS/@media/pref...
|
| My first thought was that the OS accessibility settings must
| not be available to websites without a permission toggle
| because the ad industry is just going to weaponize it and use
| it against people.
| greyhat wrote:
| I use this on iOS and it still leaves a lot of animations
| that could be sped up.
| jkaptur wrote:
| I think the map example is better. Without the animation, you
| have to figure out visually how far the map moved.
| ustad wrote:
| Remember that time when the ios calculator was messing up with
| simple arithmetic due to the animations?
| arghwhat wrote:
| The animation clarifies the change. A user, heck even I could
| be confused by an instantaneous touch toggle. Why? Because my
| finger covers it during the press, so I would not see the
| change happen - if my mindset was "change that setting", I
| might rapidly tap it again, thinking the press didn't register.
| Such confusion does not occur with a (fast) animated
| transition.
|
| The map example is much more important. With animation, your
| eyes and brain recognizes a single image sliding around, giving
| you automatic positional awareness. Without, you eyes and brain
| recognize a slideshow of independent images, and makes
| recognizing and navigating the map a conscious effort. By no
| means an impossible effort, but an entirely unnecessary one
| detrimental to the user experience.
|
| At the same time, navigation UIs that react as navigation-less
| updates also tend to have the double-whammy of bad UX in the
| form of blocking and discarding user input during updates.
|
| Bad UIs are not bad because animations are bad, they're bad
| because they were made poorly.
| y42 wrote:
| >> The animation clarifies the change
|
| Isn't that a problem that UI designes (sorry for
| generalisation) created by themself? Let's stick to the
| toggle element. It replaces the classic checkbox.
|
| A "checked checkbox" leaves no doubt. A toggle box does.
| pazimzadeh wrote:
| few things in the world are perceived as instantaneous,
| except maybe lightning. until recently people were not used
| to interacting with instantaneous objects. even a checkbox,
| in its original incarnation with pen and paper, would take
| a second to be filled. as long as the animation is
| interruptible, and the underlying change happens quickly
| (whatever the toggle is controlling) then animating the
| transition is usually better. I really like that their
| animation is interruptible.
| klausa wrote:
| >A "checked checkbox" leaves no doubt.
|
| It's absolutely not that simple. I actually think that the
| toggle design is _very_ clever, explicitly because it
| sidesteps a lot of cultural baggage that comes with
| existing symbols, and creates its own, fairly unambiguous
| one.
|
| Do you use "checkmark" to indicate that a choice is
| selected? In some cultures that indicates "wrong" answer.
|
| https://en.wikipedia.org/wiki/Check_mark
|
| Sure, just use "x" then, right?
|
| In _different_ cultures, that one indicates "no, I do not
| agree".
|
| https://en.wikipedia.org/wiki/X_mark
| vidarh wrote:
| This is a problem if using "tri-state" checkboxes. Don't.
| They're confusing.
|
| It is not a realistic problem for two-state checkboxes.
|
| I'm from nordic country, and yes, I too have seen the
| "checkmark" to indicate mistake on school work as listed
| on the Wikipedia page and attributed to Sweden and
| Finland. I've however also seen that on my son's school
| work in the UK. And I've seen it used for correct. And
| for just "I've checked this".
|
| _It is not culturally consistent, and usually appears to
| be more indicative of a personal marking style_.
|
| And _almost only in that kind of context_.
|
| Outside of that context, a checkmark is still mostly used
| as a positive confirmation across the Nordic countries
| too. You may want to make sure that the wording of the
| label does not give room for thinking you can tick it to
| answer "no", but that _equally applies for a checkmark_.
|
| To make sure I wasn't overlooking some difference between
| Norway (where I grew up) and Sweden, I just checked
| aftonbladet.se - one of Swedens largest newspaper, and
| their signup page for example uses checkmarks to
| positively indicate the presence of features in their
| Swedish ad copy.
|
| On a _form_ it certainly is consistently meant to
| indicate "selected", just as an "x" is, in those
| countries as well unless the form explicitly says
| otherwise or indicates you can use both.
|
| The only confusion arises if _both are valid states_
| because you 've used a tri-state checkbox. So don't.
| They're confusing _everywhere_.
|
| Maybe it's not universal, but the use of checkmarks
| _outside boxes_ to indicate "wrong" in some contexts is
| entirely irrelevant to the interpretation of checkmarks
| _in boxes on a form where the options are not-marked vs
| marked_.
|
| Sure, if you are designing a UI where you are displaying
| corrections to something, don't display a checkmark -
| probably irrespective of whether you include a box -
| without some additional indicator of whether it means
| right or wrong.
| oneeyedpigeon wrote:
| Contrary to what some of the replies imply (that a smooth
| animation is _always_ better than a discrete one), I have a
| solid example where animation definitely harms the UX.
|
| One of the language apps (either Hemingway or grammarly) had
| this issue stepping through search results. As you moved, it
| would change the colour of the matching text, but slowly and
| subtly, via animation. That makes it much, much harder to
| actually spot where, in a wall of text, the match actually is.
| An instant change is far more visible.
| ernstgnzlz wrote:
| > Unfortunately it is, just a fancy thing that too often makes
| it worse or just focuses on the wrong thing.
|
| For UI elements that try to replicate the physical world, such
| as toggles, switches, even some buttons, I find it that the
| animation makes the UI easier for the brain to understand.
| Kiro wrote:
| On mobile your finger is often obscuring the button you press
| and an animation is necessary feedback. This is especially
| important for things that are not booleans, for example a
| button to increase a value and you end up in "wait, did I
| change it to 5 now or was it 5 before with my press not
| registering?" (actual example from yesterday in a famous D&D
| helper app).
| James_K wrote:
| Surely this only happens because someone wasn't looking at
| the screen while they were making the input. They could just
| as easily miss whatever animation is attached to the number
| changing. The real solution here is to provide some kind of
| haptic feedback (phone vibration) or to play a sound.
| Kiro wrote:
| Big disagree on that. Sound and haptic feedback are clearly
| inferior solutions to the obvious one: an animation.
| James_K wrote:
| Can you back up this opinion with any kind of coherent
| argument? Because the problem is "people can't see the
| screen" so I feel like displaying something on the screen
| might not solve it. By contrast, you would definitely
| know if the phone buzzed when you clicked a button.
| Anyone who's ever used one of the iPhones with fake home
| buttons on them can attest to this fact.
| layer8 wrote:
| If the animation is so slow that it is still visible after
| your finger isn't obscuring the button anymore, I'd argue it
| has to be really slow and is not snappy anymore. It also
| doesn't behave like anything physical, because physical
| buttons/sliders only move while you're touching them.
|
| The gold standard used to be to make buttons large enough so
| they are never fully obscured (for toggles, the label can be
| included to be part of the button) and to highlight them when
| pressed and remove the highlight when released. (Like keys on
| a virtual keyboard mostly still behave.) That way, you have a
| clear indication of when you press something, and it
| coincides with what your finger is doing, and doesn't lag
| behind.
| valenterry wrote:
| Not really. A toggle is inspired by (and associated with) real-
| life knobs. When you imagine the manual gears in old cars, then
| when you move then knob it often moves non-linear in terms of
| visuals (because of the angle).
|
| That being said, those toggles are imho the wrong choice.
| Checkboxes (that actually have a check-mark) are nicer because
| they show a clear "yes" and "no" so I don't have to guess which
| position means what when it comes to a toggle.
| usrusr wrote:
| On a touch sreen, chances are the finger obscures the state
| change, or much of it. When you are not super focused ("I don't
| trust this thing!"), it's easy to miss the difference between
| before and after states. The animation serves as a low-
| threshold confirmation that the pixels are not just decoration
| and that the touch event has actually been registered.
|
| Requiring the user to mentally diff before and after states
| would be like a sailor only confirming captain's orders when
| explicitly asked "did you understand me?" instead of an
| unsolicited aye.
|
| Where the "on-state not as clear as with a checkbox" critique
| gets a resounding comeback is when slider-looking on/off states
| are introduced only because of fashion, but in a process where
| the language used in animations (e.g. screen mockup bitmaps) is
| completely unaware of animations and therefore they only happen
| if toolkit sliders match exactly. Yeah, don't ask...
| solardev wrote:
| Or you could just use a checkbox
| iainmerrick wrote:
| Preferably both. Make it a checkbox for clarity, _and_
| animate it for input feedback.
| usrusr wrote:
| Tends do get completely obscured and you're back to mental
| diffing. I know, I know, nothing a bigger checkbox could
| not solve, but they look weird when you only make them
| bigger horizontally.
| layer8 wrote:
| Checkboxes can usually be toggled by clicking/tapping on
| the label. That may not resolve all criticism, but I'm
| just saying.
| usrusr wrote:
| True. Ideally you put some "event received" indication
| across the whole trigger area, e.g. that little Android
| ripple animation. Certainly does not hurt to do the same
| (whole area clickable, and with visual feedback) even
| when your designer insisted on fashionable slider-
| toggles.
|
| Subtle things like that greatly reduce the mental
| background load for the user, but that's impossible to
| quantify. Chances are you don't consciously notice when
| it's missing even when in theory you are fully aware of
| the concept.
| ChrisMarshallNY wrote:
| _> On a touch sreen, chances are the finger obscures the
| state change, or much of it._
|
| Here's how I deal with that, in my app:
| https://imgur.com/a/6uQnuox
|
| It's accompanied by haptics.
| card_zero wrote:
| Why can't phones have mouse pointers? Drag anywhere on the
| screen (ideally _not_ where the pointer is) to grab the
| pointer. Do some kind of multitouch thing like tapping with a
| second finger to click. Then you can see what 's under the
| mouse instead of constantly prodding your fat finger into the
| object of interest. I guess that would be too slow, or
| something? Not simple enough?
| ripe wrote:
| Hmm, I must admit I had never thought of this idea by
| card_zero: why not drive a mouse pointer using touch at a
| distance? Does anyone with experience in this know why it
| wouldn't work, or whether it has been tried?
| andrewaylett wrote:
| Microsoft's Android RDP client does this, the biggest
| issue is that it's not expected behaviour.
| usrusr wrote:
| It could only ever be good for some interactions, e.g. it
| would be terrible for when the screen is just three large
| buttons for super quick access. Mode switching would surely
| be awkward.
|
| I think I remember some map apps experimenting in that
| direction, but I consider the locusmaps "magnifying glass"
| undisputed king of that hill (touch interaction for maps).
| memalign wrote:
| The resource I come back to often for animation curves:
|
| https://easings.net/
| paipa wrote:
| No example from the ultimate, infinitely differentiable
| tanh(tan(x))-like family? How disappointing.
| GauntletWizard wrote:
| PID Controllers for animations
| randomsolutions wrote:
| My thought too, or just a P controller.
| tnvmadhav wrote:
| thanks for sharing. this must've taken a lot of experimenting.
| qiller wrote:
| Standard easing has one advantage being frame rate independent.
| Spring functions need some extra care to prevent things from...
| exploding.
| demondemidi wrote:
| A lot of these don't seem to work on my iPhone and Firefox.
| iainmerrick wrote:
| Touch input in JS is a bit of a mess. You have to explicitly
| disable a lot of "helpful" default behaviour to make it work
| well, like auto-zooming on double tap or selecting on long
| press.
| nextaccountic wrote:
| Can this be done in pure CSS?
| DevoAKA wrote:
| `transition-timing-function: ease-in-out`
|
| This reminds me of Medium spending months to change the
| underline beneath a descender: https://medium.design/crafting-
| link-underlines-on-medium-7c0...
| skrebbel wrote:
| This isn't like ease-in-out at all. It resembles ease-out a
| little.
| rabuse wrote:
| Can probably try playing around with cubic-bezier, but not too
| sure.
| lausbub wrote:
| Something like this: https://easings.net/#easeOutExpo
| mxfh wrote:
| CSS has its own easing function customization shorthand
| notation. So you could just use that.
| https://developer.mozilla.org/en-US/docs/Web/CSS/easing-func...
| Animats wrote:
| You never get there with exponential smoothing. It takes infinite
| time to asymptotically approach the goal.
|
| Also, that page uses 100% of the CPU in Firefox.
| pixelesque wrote:
| The bottom half of the page doesn't even show in FF on MacOS
| for me... just white...
|
| Text selection also doesn't seem to work... is it all Canvas
| maybe?
| blt wrote:
| Also FF on MacOS, and same issue. Seems like a hang
| Izkata wrote:
| Firefox on Android, too.
| TomK32 wrote:
| and Firefox on Linux.
| unwind wrote:
| Seconded (Firefox on Linux), it worked fine with the
| toggles but once it came to the map-based examples it
| stopped. Never saw a map scroll, and continuing down the
| page started to blank out the (assumed to be) maps, so I
| closed the tab.
|
| Very nice-looking page, but perhaps a _smidgen_ over-
| engineered for what it wanted to show? :)
| Rallen89 wrote:
| Doesn't load with mobile browser bur if you change to
| 'desktop site' option it loads... but is very jittery and
| loads slow, a few visual bugs aswell.
| raybb wrote:
| Perhaps it's worth filing a bug report if this works on other
| browsers but not FF.
| xandrius wrote:
| Example of form over function.
|
| If the site doesn't even load, does it matter what function you
| use for the toggle in the settings page?
| Netcob wrote:
| For me the final few animations do some funky things...
| flickering, phasing out of bounds...
| kroltan wrote:
| Can reproduce. Almost like it's intentional...
| moffkalast wrote:
| It's nice, but it's not nice enough to warrant going beyond
| transition: all and timing cubic-bezier in css. Maybe if
| browsers ever add native support without having to add extra
| overhead.
| k4rli wrote:
| Same issue. Android FF just won't handle this "basic modern
| website". Probably 5+MB of js being loaded in.
| leetrout wrote:
| See also: Juice
|
| https://garden.bradwoods.io/notes/design/juice
|
| https://www.andy.works/words/the-most-satisfying-checkbox
| aappleby wrote:
| I've used this for decades. The sweet spot for ui components
| seems to be moving 90% of the way to the target every 80
| milliseconds.
| ramesh31 wrote:
| i.e ease-in
| gelatocar wrote:
| that's ease-out
| ustad wrote:
| Reminds me of that famous paradox.
| hn_acker wrote:
| Zeno's dichotomy paradox [1]. To travel a certain distance,
| you must cross half the distance. Then you must cross half of
| the remaining distance (one fourth). Then half again, and so
| on.
|
| [1] https://en.wikipedia.org/wiki/Zeno's_paradoxes
| iainmerrick wrote:
| That's a great rule of thumb, I'll remember that one!
| ramesh31 wrote:
| Never animate position. One of the number one reasons for jank on
| the web.
| bee_rider wrote:
| For some reason this makes me want a toggle that:
|
| * Moves slowly to about 75% of the way there while you hold the
| touch/click
|
| * Snaps the rest of the way on release
|
| I'm not sure what this could mean in terms of UX though. Maybe
| the setting is actually applied or saved at the end.
|
| Or it could be part of an "are you sure?" dialogue. The setting
| is applied as you hold, but you can hit escape to undo before it
| snaps into place.
| aimor wrote:
| https://jsfiddle.net/u1vybhqg/ input:checked +
| .slider:active:before { transform: translateX(8px);
| transition: 1s; } input:not(:checked) +
| .slider:active:before { transform: translateX(18px);
| transition: 1s; }
| PennRobotics wrote:
| This, but set closer to 200 or 100 ms (and for me, swapping
| the translate 8 and 18 so that the switch barely moves on
| mouseDown, because that's damn close to a real switch's
| behavior). This seems like it could be a good compromise to
| all of the people complaining about lag and others who
| understand that the visual system is powerful and movement is
| a huge part of that. Also, it's relatively simple as far as
| CSS animations go!
| tdudhhu wrote:
| I have seen a lot of (eldery) people try to slide the toggle
| but then nothing happens.
|
| So while your at it: also make it possible to slide the toggle.
| Or just use checkboxes.
| simon_kun wrote:
| I love blogs like this. reminds me of 2005.
| jdiff wrote:
| In a lot of ways we're just now reclaiming the good parts of
| the flash-dominated web. Fair bit of bad collectively as we're
| relearning, but things are trending in an interesting
| direction.
| omeze wrote:
| This is very cool, the camera over world example really
| highlights the difference
| mxfh wrote:
| Yes, but this seems to be convoluting two distinct problems.
|
| one is how to handle user inputs to a camera/world with inertia
| while moving whith a lot more variables to set for a certain
| desired feel, (why no long taps/mousedown to speed up the
| movement).
|
| While the button is just easing a fixed animation between two
| states with no intermediate input.
|
| Also what happens to the binary state of the app if the
| animation can be reversed before reaching final state, this is
| opening a can of worms for no obvious reason.
| saltyoutburst wrote:
| It's fascinating that easing, which is what this article mostly
| boils down to, is something that each new generation seems to
| need to (re)discover on their own. I remember being fascinated by
| Yugo Nakamura's experimental websites back in the late 90s
| because they were some of the first that I'd seen that had an
| organic feel due to liberal use of easing.
| https://www.youtube.com/watch?v=NLt7Gwnt3WY
| cl3misch wrote:
| Instead of the wall of text and equations, it would have been
| helpful to _plot_ the easing functions.
| coldtea wrote:
| > _However, this still looks a bit clumsy due to having a
| constant speed_
|
| Does it? Looks much better to me, and preferred to waiting for a
| animation to be given more time to speedup while looking "smooth"
| (they seldom seem to be given the same time as instant or linear
| animations, do they? For some reason we have to be forced to
| enjoy them in half time).
|
| In fact I'd take the "instant toggle" in a heartbeat too. Real
| life toggles don't "exponentially smooth" from one side to the
| other either.
| globular-toast wrote:
| I hate animations like that because they are intentionally
| slowing down the UI. I already clicked it, why are you spending
| several milliseconds to update your state?
|
| Animations, or anything else really, should only be used to
| improve things. Ask what the problem is, not what cool solution
| I should implement. It's ok to go to town if the page is
| _artistic_ , like your blog, but if I'm filling out a form? Get
| your art out of here.
| hoelle wrote:
| Beauty is often worth a little extra time. I'd rather walk a
| beautiful trail than a paved sidewalk beside 6 lanes of fast
| traffic.
|
| It's cool to choose the tools that appeal to your values.
| It's not cool to advocate for paving the planet in your quest
| for single-minded efficiency.
| coldtea wrote:
| > _Beauty is often worth a little extra time. I 'd rather
| walk a beautiful trail than a paved sidewalk beside 6 lanes
| of fast traffic_
|
| Beauty can be expressed with the toggle's design, with the
| window decoration, with the colors, with the wallpaper,
| choice of font, and so on.
|
| No need to be expressed with an animation.
|
| If your car did a little "song and dance" everytime you
| started it up that you had to wait to be able to drive it
| off, it would get annoying really fast.
| jdiff wrote:
| Nobody's waiting on a checkbox to finish filling on
| before moving onto the next.
| godshatter wrote:
| In this case, not necessarily. It's obviously designed to
| animate in a particular way. Why? Is it just for kicks,
| or is there a reason for it to animate as it's moving? Is
| it going to bounce back half-way through because the
| system realized you're not allowed to turn that thing on
| for example? I don't know, so I would wait for it to
| finish.
|
| I admire the dedication to do this, but I find it
| superfluous when designing something I need to actually
| use. Great for a game, not so great for a page of
| checkbox thingies I need to set to the right values to
| make something else work correctly. I don't really want
| it to animate well, I want it to work fast and to be
| obvious what it does and how it works. It doesn't have to
| be pretty, unless being pretty helps make it more clear
| what's what.
| pxtail wrote:
| > I'd rather walk a beautiful trail than a paved sidewalk
| beside 6 lanes of fast traffic.
|
| But would you still prefer it if alternative paved sidewalk
| is 5 times shorter AND you need to walk between same two
| points of interest multiple times per day, everyday?
| modeless wrote:
| The only problem with instant transitions is that sometimes you
| may not notice what changed. I would like to see a UI built
| around instant transitions but with subtle animations that
| happen _after_ to emphasize the change. Like the new content
| shines, or does a tiny bit of grow /shrink, but not in a way
| that prevents interaction. There's nothing I hate more than
| waiting for long transition animations (looking at you, macOS
| fullscreen button)
| Philip-J-Fry wrote:
| We've solved this problem already without animations.
|
| You just highlight the data that has changed and have an
| "Apply" button to save those changes.
| Difwif wrote:
| Toggle buttons are supposed to have an instant effect. It's
| an anti pattern to gate the effect on a submit.
| Philip-J-Fry wrote:
| According to who? It's a restyled checkbox.
| deathanatos wrote:
| Well, stuff like this used to be encoded in HIGs (Human
| Interface Guidelines). The GNOME HIG, back in the day,
| had the parent's recommendation, as well as the rationale
| for it: so that the feedback is immediate, and the user
| can then visually see the effect that that option has.
|
| Gating it on a submit forces a user who is looking for
| something & not finding it into a "try one thing, submit,
| evaluate, open settings, undo that, try different thing,
| submit..." loop, which is a _lot_ longer.
| buserror wrote:
| All of this work for buttons that toggle on a mouse/finger DOWN.
| How irritating that there is no intermediate state on the mouse
| DOWN and the toggle on the mouse/finger UP.
|
| Because it allows you to /cancel/ the action.. click, 'oops don't
| want that' drag mouse/finger out and release. No action taken.
| User is in control. Amazing.
| itishappy wrote:
| It's a toy example, not a polished UI. You can trigger this
| technique any way you like.
| mzs wrote:
| Animations like this give me a mildly nauseous feeling like a
| strobe light at an unsettling rate. The instant toggle does not.
| mati365 wrote:
| Your site crashes whole Firefox on Linux.
| ben-schaaf wrote:
| Works just fine here; also Firefox on Linux.
| ulrikrasmussen wrote:
| Just go with the instant toggle instead of wasting time making
| the UI worse by making users wait for pointless animations.
| jdiff wrote:
| Who is stuck waiting for a toggle or checkbox to finish
| animating? It's not blocking anything.
| ulrikrasmussen wrote:
| The user is. You usually wait for visual confirmation before
| you determine that the action you performed was indeed
| performed.
| jdiff wrote:
| The user isn't actually blocked from doing anything, a box
| is ticking, it's not a whole-screen state transition where
| you have to wait for things to settle before moving on. The
| box doesn't have to settle before you can recognize "oh,
| good, it accepted my input."
| __jonas wrote:
| I like those little animations, you do not, that's fine because
| there is a simple solution for it:
|
| Just respect prefers-reduced-motion when implementing
| animations and everyone is happy.
| begueradj wrote:
| Interesting that you got the idea to dive into animating a switch
| :)
|
| Maybe you could help the user to better distinguish the ON/OFF
| states by also colorizing the whole switch element, not only that
| "disc" (as it is done in Vuetify.js, for example, using the
| "color" prop: https://vuetifyjs.com/en/components/switches/
| huhtenberg wrote:
| Some of example animations are buggy -
|
| https://i.imgur.com/hQyh05s.gif
|
| https://i.imgur.com/So6KsMt.gif
| degun wrote:
| Same on my browser and system: Safari on iOS.
| mawax wrote:
| The author addresses this: "See this jittering after the
| animation completes?"
| Biganon wrote:
| This is explained _literally_ in the next sentence of the
| article.
| huhtenberg wrote:
| First one is, my bad.
|
| The second one is clearly a bug though.
| bartread wrote:
| I like this although I'm going to stick my neck out and say the
| author is objectively wrong that sqrt is better than cubic for a
| toggle switch, and that cubic is in fact the better choice for
| this situation simply because of the way real life toggle
| switches generally work.
|
| Think about the breaker switches on the electrical consumer unit
| on your house, or the kind of switches you often find on analog
| synths or other audio gear, generally stuff that's going for a
| particular aesthetic. I have a small Hughes & Kettner guitar amp
| that has two of these switches that are _very_ satisfying to
| use[0].
|
| When you use these kinds of switches in real life there's some
| initial resistance, and then they suddenly snap into the new
| position because of the way they're spring loaded. This is more
| closely modelled by the cubic function than it is by either the
| sqrt or the exponential smoothing function.
|
| Other than that absolute nitpick, I really enjoyed the piece. It
| well illustrates how animation can enhance a user experience when
| done well (with, for example, an appropriate easing function) or
| alternatively detract from it and be quite jarring if not
| implemented thoughtfully (thinking particularly of the linear
| interpolation examples).
|
| _[0] This does somewhat depend on the type of toggle switch,
| although even the variety that you find on something like a
| Minimoog (this isn 't some sort of gear flex, by the way - I
| don't own one of these!) exhibit this "resist then snap to the
| new position" behaviour that makes them so enjoyable to flick._
| asimpletune wrote:
| Intuitively I too preferred the feel of the cubic function. A
| mechanical toggle will have some inertia, and I guess that's
| what we're seeing with the cubic approach.
| exe34 wrote:
| Have you tried using a tick box?
| Biganon wrote:
| They don't serve the same purpose. A toggle switch has an
| immediate result, such as switching the website between light
| mode and dark mode. A checkbox is part of a form, and indicates
| a boolean choice that will only be taken into account once you
| submit the form.
| exe34 wrote:
| How do you enter text then? Do you re-implement the text box
| because input text is part of a form?
|
| Check boxes work just fine without a form btw:
| https://stackoverflow.com/a/50012963
| Biganon wrote:
| I'm not saying you CANNOT use a checkbox outside of a form.
| I'm saying they gradually became different UX widgets that
| serve different purposes.
|
| You can use pretty much any widget to store a boolean
| state. A select? It works. Radio buttons? Works. Checkbox?
| Of course. Typing "1" or "0" in a text input limited to
| integers between 0 and 1 inclusive? Why not. But semantics
| matter, and so does the principle of least surprise.
| Nowadays users expect an immediate result when toggling a
| toggle button. Not as much when they toggle a checkbox.
| sodimel wrote:
| Emotional design (https://en.wikipedia.org/wiki/Emotional_Design)
| as it's finest form, there's a lot to tell behind a tiny little
| animation.
| t43562 wrote:
| I think this was fun but I really hate those switch things - I
| find it confusing to know which position is on and which is off.
| Which colour is the "on" colour? A checkbox might be ugly but I
| do understand it at a glance.
| timvisee wrote:
| I don't like this kind of smoothing at all. It feels slow to me.
| Please just toggle without animations instead. And yes, I know
| these examples have been slowed down.
| Traubenfuchs wrote:
| An I the only one upset this is done by (excessive) JS usage?
|
| It would be my deepest displeasure to bring a button toggle
| animation to production that requires more than CSS.
|
| Quick example I found:
|
| https://hudecz.medium.com/how-to-create-a-pure-css-toggle-bu...
|
| Easing/Smoothing is possible with transition-timing-function.
|
| https://www.w3schools.com/cssref/css3_pr_transition-timing-f....
| tiborsaas wrote:
| Buttons are just examples because it's easy to understand. The
| point of the article is the math.
|
| Of course CSS could do it with less JS, but this would have
| been a totally different post.
| meehai wrote:
| Linear is perfect.
| whitehexagon wrote:
| hmm, could be my old FF (or hidpi) but many of the examples just
| dont work. Jittery scrolling on the landscape, and circles that
| start teleporting back and forth on the sliders, and one that
| vanishes to the left. To me that just highlights another reason
| to keep it simple... checkbox?
| d--b wrote:
| I wonder if there is some cultural preference for this.
|
| Looking at the map example, I find the cubic smoothing way
| "calmer". The exponential one feels a bit hectic and I am
| wondering if it's an American thing. It's got a "wheez" quality
| that is annoying to me, but that reminds me of hyper cartoons
| like powerpuff girls.
|
| It's still all very subtle...
| hellweaver666 wrote:
| I appreciate the effort that goes into animation like this, but I
| always have to wonder, especially in the context of the web if
| it's worth all of the additional code and development time for
| such a minor detail. Do our users even notice?
| Klaster_1 wrote:
| During my day job as a frontend developer, I have to cope with
| this quite often. When you raise a point with the manager that
| we could be fixing real bugs instead re-doing a non-essential,
| very subjective thing the designer came up with, they usually
| reply that they trust the designer as a professional and they
| know better - the developers don't have a choice.
| useless999 wrote:
| Author writes about useful easing concept, happens to use UI
| element purely for illustrative purposes, HN comment section
| turns into a 100+ comment jihad over animations in GUIs. Nothing
| substantial is discussed.
| jdiff wrote:
| So many people allergic to design and equating bad design with
| all design. Studies? Experts? What could they know? These guys
| have opinions on modern software and designers to throw under
| the bus for them.
| interloxia wrote:
| I can't down vote this so I'll reply to say that there is still
| value to be found amongst the noise and complaints, even in
| this thead. I found iainmerrick's comment insightful and
| worthy. A place to discuss the value of animations is of value
| some of time too. There are lots of other threads to
| participate in.
| baxuz wrote:
| This is actually a really good approach and a good proof of
| concept for an animation / easing technique. Reminds me a lot of
| Flickity:
|
| https://metafizzy.co/blog/initial-demos/
|
| https://metafizzy.co/blog/math-time-resting-position/
|
| https://metafizzy.co/blog/particle-to-slider/
|
| https://metafizzy.co/blog/flickity-begins/
|
| Especially this demo: https://codepen.io/desandro/pen/myXdej
|
| This technique isn't just useful for switches. Nor will you use a
| <canvas> element for a switch. Nor will you have 20 parallel
| requestAnimationFrame loops running on the entire site. Or
| intentionally broken elements. The site also doesn't have
| optimizations where the rendering stops once the delta is too
| small -- or probably dozens more of small tweaks that could make
| this production ready.
|
| The comments here show that people either haven't read the
| article and are making assumptions, or can't see the forest for
| the trees. Or are just simply so biased and cynical that they
| need to share their (unprofessional) opinion in order to appear
| smart.
|
| Since when has HN turned into Reddit?
| verisimi wrote:
| The cynicism doesn't seem that fair in this case.
|
| Re HN becoming like Reddit..
|
| Perhaps there is a generic 'cynical feeling' in the air with
| technology, with feelings of distrust about the intentions of
| governments and corporations over their use of the profound
| technology that is appearing, and how this is being constructed
| with the intention to constrain and manage the individual,
| rather than enabling greater freedom.
| cmplxconjugate wrote:
| I think maybe more that the users of this website, which is
| designed in a way that is intensely functional compared to
| other similar sites, just prefer less "useless" design
| features.
| actualwitch wrote:
| > Since when has HN turned into Reddit?
|
| That has been happening for a while, but people are not talking
| about it because it's explicitly against hn guidelines. Gee, I
| wonder why.
| amarshall wrote:
| > Since when has HN turned into Reddit?
|
| Read at least the last paragraph of
| https://news.ycombinator.com/newsguidelines.html
| baxuz wrote:
| I wasn't aware of that fine print, but in light of that, let
| me rephrase it:
|
| Certain topics on HN can induce commenting behaviour among
| seasoned HN users often attributed to Reddit users,
| including, but not limited to:
|
| - being contrarian without fully reading, understanding or
| contextualizing the article or comment in question
|
| - weaponizing downvotes
|
| - being overly cynical, lowering the overall quality of the
| discussion
|
| - repeating, or tersely acknowledging what has been said by
| most upvoted comments in order to gain more upvotes
| dahart wrote:
| There are indeed sometimes less than stellar comments, and
| some topics are more prone than others, those things are
| true. Yes people comment without reading sometimes, and yes
| people are contrarian sometimes. Sturgeon's law apples
| independently to any group or site, regardless of the
| average quality there. But, it is clear the average quality
| on HN is much higher and not very comparable to Reddit.
|
| That said, it's not a good idea to make assumptions about
| behavior or why voting is happening, it lowers the overall
| quality of the discussion to state those assumptions or
| complain about comments, and it generally doesn't work here
| to tersely acknowledge something to get upvotes. I don't
| know what weaponizing downvotes means, but I haven't seen
| much downvoting here that can't be explained by comments
| being either wrong about something or rude about something.
|
| In my experience, it does often help to patiently respond
| to contrarians without negative judgement and explain how
| and why you value good animation tricks, and what problems
| they solve. That will probably earn you upvotes much faster
| trying to repeat or agree with another comment.
| Retr0id wrote:
| In this case a lot of people are unable to read the article
| because it hangs most non-chromium browsers about a third of
| the way down the page.
| slumberlust wrote:
| Loaded fine for me on Firefox. What are you using?
| Retr0id wrote:
| Firefox
| m_st wrote:
| In relation to the formulas near the end of the article, I find
| it tragic that even in 2024 they are still PNG images.
| ano-ther wrote:
| It's funny how emotional discussions about UI choices are.
|
| I liked the article and its demonstrations because I learnt
| something.
|
| Personally, I switch off animations whenever possible, preferring
| snappy action over flashy effects. But they have their use, for
| example in the rubber band effect which would be quite jarring
| without motion smoothing.
| jonplackett wrote:
| I'm pretty much fine with the linear one
| mdw wrote:
| The animations are unfortunately broken on Mobile Safari :(
| KolenCh wrote:
| From the title I somehow expected Planck taper window which comes
| up in partition of unity.
|
| The property of this is that you won't find any discontinuity in
| any degree of derivatives. Ie it is smooth in the mathematical
| sense. If you want to make changes from a constant function (such
| as not moving at all) to something else (start moving), then this
| smoothness is a nice property.
| SSchick wrote:
| The animations are becoming.. violently choppy/vibrating over
| time and then my browser crashes, bad algorithm?
| YellowSuB wrote:
| Yeh got the same problem on firefox, had to kill it.
| seanalltogether wrote:
| This takes me back to old days of Flash programming and the
| infamous Robert Penner easing functions.
|
| http://robertpenner.com/easing/penner_easing_as1.txt
| burning_hamster wrote:
| > Yes I've made a whole procedural map generator & renderer just
| for this example, and I have zero regrets.
|
| You can be salty about excessive use of animations in modern UI
| all day long, but you have to respect that level of commitment.
| scld wrote:
| So this is why my computers feel the same as they did 25 years
| ago.
| rthnbgrredf wrote:
| I think it comes down to personal preference. I prefer instant
| and snappy interfaces with as minimal latency as possible. Please
| provide me with an option to disable all animations and I'm
| likely fine with your interface.
| iainmerrick wrote:
| I don't see much discussion here of the crucial point, which is
| that this isn't just another easing curve or smoothstep() between
| 0 and 1, it's a _stateless_ method that handles pretty much any
| inputs in a regular way. That 's really useful!
|
| If you've used CSS transitions you'll have encountered the
| problem this solves. Okay, my duration is 400ms -- but why 400?
| Shouldn't it depend on how far it has to move?
|
| As others have noted, exponential smoothing has a different
| problem, that it asymptotically approaches but never quite
| reaches its destination. The obvious fix is to stop animating
| when the step gets below some threshold, but that's inelegant.
|
| When using a similar method for inertial scrolling, I've found it
| useful to add a (pseudo-)friction term. This offsets the
| exponential, and effectively works as a minimum speed. Here it is
| in Desmos: https://www.desmos.com/calculator/98ufbuzxhj
| rav wrote:
| > If you've used CSS transitions you'll have encountered the
| problem this solves. Okay, my duration is 400ms -- but why 400?
| Shouldn't it depend on how far it has to move?
|
| It seems to me that the "speed" parameter in the exponential
| function has the same issue, does it not?
| iainmerrick wrote:
| If you use the version somebody else here mentioned, "move
| 90% of the way to the destination in 80ms", does that make
| more sense? (I think it's equivalent, just a change of
| units.)
| knappa wrote:
| > As others have noted, exponential smoothing has a different
| problem, that it asymptotically approaches but never quite
| reaches its destination. The obvious fix is to stop animating
| when the step gets below some threshold, but that's inelegant.
|
| This is off the cuff, but you might be able to fix this as
| follows: Interpret exponential smoothing as a ODE on the
| distance to the target. Call that distance D. Then exponential
| smoothing is the Euler update for dD/dt=-C*D. (the constant C>0
| being a speed parameter) The issue you bring up is basically
| the fact that the solutions to the ODE are D(t)=A*exp(-C*t),
| which is asymptotic to zero as t->oo, but never reaches zero.
| Now, the fix is to replace the ODE with one that goes to zero
| in finite time. e.g. dD/dt=-C*sqrt(D). (Solutions are half-
| quadratic. i.e. they are quadratic for a bit then stay zero
| once you hit zero.) The Euler update for this is stateless like
| you wanted.
| DinaCoder99 wrote:
| > The obvious fix is to stop animating when the step gets below
| some threshold, but that's inelegant.
|
| Why? It's simple, easy to implement and validate, and provides
| the desired visual impact. Seems perfectly elegant to me.
| tambourine_man wrote:
| On mobile Safari, I get a translucent gray square showing the hit
| target over the toggle whenever I touch it. That removes any
| subtlety the different animations may show
| tgv wrote:
| The 8x slow-down argument is so naive, it's bad. Perception and
| interpretation change with speed. Listen to a song you slowed
| down. It becomes something entirely different. Compare
| https://youtu.be/r2ozuCXpVJY?t=70 and
| https://www.youtube.com/watch?v=QspuCt1FM9M&list=PL19J-0p1Ir...
|
| If you can't see the difference at normal speed, there _is_ no
| difference.
| tambourine_man wrote:
| CSS animations are much lighter on battery and computing
| resources than JavaScript and potentially smoother too. Something
| to take into consideration.
| chrisjj wrote:
| I remember seeing how much better was iPhone than Android, having
| slick continuous sliders instead of old-hat binary switches.
|
| Imagine my disappointment when I found that the iPhone slider for
| mute didn't smoothly slide the sound volume to silence, as per
| the visual effect, but snapped it to zero just like the Android
| switch.
|
| ;)
| cranx wrote:
| Nice job, but it's math, not some magic trick. I would like to
| see the animation functions graphed to describe how the numbers
| change relative to time.
| bufio wrote:
| The instantaneous one is best.
| petters wrote:
| The first toggle button on the page is the nicest to use IMO.
| Retr0id wrote:
| See also: CSS transition-timing-function: cubic-bezier
|
| https://cubic-bezier.com/
| some1else wrote:
| You only need to smooth on approach. Something like `transition:
| left 200ms ease-out` in CSS should have you covered most of the
| time. Alternatively, you can build any kind of interpolation by
| replacing the `ease-out` function with the `cubic-
| bezier(...steps)` keyword: https://developer.mozilla.org/en-
| US/docs/Web/CSS/easing-func...
| hailpixel wrote:
| Love this article. I wrote basically the exact same technique
| almost 10 years ago. At the time I called it `lazy-easy` and
| still use it today. Sometimes you just want some nice smooth
| animation without all the state management:
| https://www.hailpixel.com/articles/lazy-animation-with-lazy-...
| krajzeg wrote:
| As a game developer, I find eased tweens with a preset duration
| better for most UI use cases. However, this other type of
| animation is extremely useful when you want to smooth a movement
| that is continuous/unpredictable, with no definite start/end
| point. Think for example a tile being dragged-dropped on a grid,
| snapping to the grid as the player moves the mouse, or indeed,
| the article's example of moving a camera around.
|
| For these cases, the exponential lerp trick is very useful, and
| not universally known. There are many games (some of mine
| included!) that use the less correct linear lerp and run into
| trouble with their animations feeling completely off once
| somebody runs the game on a 240 Hz monitor, or anything different
| from the 60fps that used to be standard.
|
| For this reason, I appreciate the article. It's usually hard to
| access this type of hyper-specific knowledge, as it is most often
| passed as an "apprentice-style" oral tradition from the senior
| people on a team to the more junior members.
| bogwog wrote:
| Whatever is on the second half of that article keeps completely
| freezing up Firefox for me.
| dig1 wrote:
| I don't want to be a party breaker, and the article is nicely
| written, but why are these animations pervasive these days? When
| I click a button in the real world, it changes the state
| instantaneously. It gives me an instantaneous feedback. Imagine
| you click the mouse button, and it slowly goes down and up.
|
| UI is becoming an art, but most people use computers to get their
| jobs done. And, to be honest, I still prefer checkboxes.
| wpm wrote:
| As the article says, and it seems like what a lot of designers
| feel as well: "Adding some animation to it would be cool!"
|
| I'm with you though. Most animation in UI is superfluous and
| annoying, if not down right rage inducing (like when the
| animation blocks input).
|
| A good example of an animation that I don't dislike is the
| window minimize animation on macOS where the window gets
| "sucked" into the Dock. It's useful because it relates a
| "where" that I can keep in my head. I click a button, where'd
| my window go? Down there, I just saw it get sucked down into
| the Dock.
| bayindirh wrote:
| Also some of these sliders are tri-state. When you touch it,
| it moves 3/4 way, becomes washed out, meaning "making the
| change, please wait", and either goes all the way & becomes
| green, or returns to its place and shows an error.
|
| Animations are tools. Use wisely, they inform and entertain.
| Use too much, they become boring.
| bayindirh wrote:
| > I click a button in the real world, it changes the state
| instantaneously.
|
| Actually it does not. Flick switches have travel, click buttons
| have depth. Electronic buttons have lag, bigger systems have
| startup time (hence the blinkenlights).
|
| My dishwasher starts in ~3 seconds after I press start. The
| button travel is so much that I'm never sure whether it
| registered the press or not until I hear the water pump start
| pulling water from the pipe.
|
| > It gives me an instantaneous feedback.
|
| It's just because you're touching a button, and feeling the
| pressure on your fingertip. Nothing is in an "instant" in the
| world.
| mynjin wrote:
| Let's just call miming physical switch travel and movement
| what it is: skeuomorphic animation
|
| And just like its design counterpoint, while some may enjoy
| the aesthetic, it's actually superfluous and we've mostly
| moved on.
|
| I get it, it's visual, it's easy to show one's boss domain
| knowledge; it doesn't do anything for accessibility and the
| _feel_ (dependable repeatable ui workflow).
| itishappy wrote:
| > When I click a button in the real world, it changes the state
| instantaneously. It gives me an instantaneous feedback. Imagine
| you click the mouse button, and it slowly goes down and up.
|
| Physical buttons have measurable response times, along with
| momentum and bounce. They're pretty quick, but get more
| noticeable as things get bigger.
|
| https://en.wikipedia.org/wiki/Switch#Contact_bounce
|
| The technique becomes even more powerful with additional
| degrees of freedom, like when moving the map from the article.
| It feels a lot better to have your view animate smoothly than
| jump around discontinuously.
| mrob wrote:
| The virtual buttons are controlled by physical buttons. My
| mouse button already "animates" because it physically moves
| when I click it (and it's optical, so no contact bounce). I
| don't need another animation playing after the physical
| movement finishes. That's just annoying time wasting.
| itishappy wrote:
| It's non-blocking. If those milliseconds are critical, you
| can be doing other stuff.
| mrob wrote:
| Controlling a computer at maximum speed inevitably means
| occasional fumbled inputs. If I don't detect these, my
| mental state will desynchronize from the computer's
| state, resulting in confusion and potential data loss.
| Therefore I can't look away from the checkbox until I
| confirm it changed state. Any animation slows down this
| confirmation, so it wastes my time.
| itishappy wrote:
| Professional StarCraft players take about 200ms per
| action, which is about the reaction time of the human
| visual system. If you set your time constant to that (1/e
| in 200ms, which would be an extremely sluggish UI) then
| your UI elements will have moved by 15% in 33ms. A more
| reasonable response (1/e in 50ms) will have moved by 50%
| in 33ms. My personal favorite curve is just "move 50% per
| frame."
|
| I'd love to see what your day looks like if you've
| optimized it to require professional Counter Strike
| reflexes to activate toggles.
| mrob wrote:
| That 200ms is the natural human delay. A "reasonable"
| 50ms animation is in addition to that, so it's equivalent
| to making the user 25% slower. It's similar to moderate
| alcohol intoxication.
|
| I personally use 72Hz keyboard autorepeat, which requires
| both low latency and predictable latency to use
| effectively.
| bmicraft wrote:
| How is it wasting time? It's not like you have to wait for
| the animation to complete
| mrob wrote:
| It's delaying the feedback I use to know if I clicked
| correctly.
| roywiggins wrote:
| I think the animations are more satisfying on touchscreens,
| where you don't have a mouse.
| mzs wrote:
| They are literally covered by my finger, I can't even see
| them.
| malfist wrote:
| Are they though? I usually use dev mode on my phone to
| turn off most animations because I find them needlessly
| distracting instead of satisfying. If I can't disable it,
| at least let me speed it up
| dahart wrote:
| This in insightful, IMO. When attaching animation to
| action, if the animation doesn't match the action, then
| there's a disconnect that can be frustrating or annoying,
| even when the delay is a small fraction of a second.
| Physical light switches feel "instantaneous" because there
| is no _added_ delay perceivable beyond how fast my fingers
| go. It does seem like some designers are sometimes so proud
| of their animations they run them too slowly. I do value
| designs that animate so quickly and smoothly that you don't
| notice them until you look for it, and I feel like the
| article does lean in that direction. The map scrolling one
| feels pretty good, for example.
| RunSet wrote:
| UI animation is largely intended to hide delays when loading
| dynamic content but its pervasiveness means it is more likely
| to contribute to delays when loading dynamic content.
|
| https://addons.mozilla.org/en-US/firefox/addon/disable-trans...
| crtasm wrote:
| One I often find funny/annoying is an icon next to items on a
| game menu that has a smooth movement (sometimes paired with a
| partial fade-out!) - this makes quickly selecting a option a
| few steps away so much slower and error-prone.
| Asooka wrote:
| The animations are useful when you can't easily see the
| instantaneous change, but I'm with you on the slowed feedback.
| I think the best feedback would be for the slider to move
| instantly, but with a fading motion blur effect. So if you're
| hard of seeing, or blink, or whatever and miss the change in
| state initially, there is still an animation playing that you
| can see to know that something changed, but at the same time
| the button is already at its new state, so you don't have to
| wait if you are paying attention.
|
| Or we can go back to normal checkboxes and radio buttons where
| the on/off state is obvious and no animation is necessary to
| help people see when they change state.
| a_cardboard_box wrote:
| You can also do quadratic smoothing without additional state, by
| moving towards the target with a speed proportional to the square
| root of the distance. Unlike exponential smoothing, this will
| actually reach the target.
| markisus wrote:
| The differential equations seem to show that this is a closed
| form implementation of a P (as in PID) controller. So the
| animation could be implemented without a call to exponential for
| small enough dt.
| castratikron wrote:
| This is just proportional control.
| https://en.wikipedia.org/wiki/Proportional_control
| IshKebab wrote:
| Yep. It is also known as exponential smoothing in other
| contexts.
|
| I wish the author had linked to the wikis for either of those
| things up front so people who had heard of it already (and know
| why you probably don't want to use it for your UI) could move
| on.
| 6510 wrote:
| My favorite is to take the difference between _current pos_ and
| _target pos_ then move the thing in steps of half that (rounding
| up).
| Levitz wrote:
| >Again, this begs us to add some animation.
|
| No, no it doesn't. Not at all.
|
| It's a MAP. It's there explicitly to display information, If I'm
| moving the map such a distance that an instant effect might not
| rely the information that place X is above place Y then yes,
| _maybe_ an animation is in order, since that gives me more
| information, but every single iteration after the first one is
| worse, way worse, and the last one is one of the worst of them,
| feels like trying to drag your feet through mud.
___________________________________________________________________
(page generated 2024-03-08 23:02 UTC)