170 replies
14h5m
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
Nothing. It's a technical demonstration. The delay is also overemphasized to make the difference more apparent.
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.
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.
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.
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.
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.
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.
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.
Or use a checkbox and stop trying to make toggles a thing, since they just don't translate to digital as well.
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.
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.
There are not many animations on iOS nor MacOS. What they are is movement that corresponds to the users movements. Like opening exposé 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.
User research feels differently, but with numbers.
See my point about technical people and their usage perspectives.
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.
On second thought, re-read the whole comment.
Actually I think you should re-read my comment. I'd also love to actually see the research you're talking about here.
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?
Ok, done. Still didn't see anything beyond assertions based on nothing but your own preference, and countering things I said without any support.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
Do you have any actual evidence for the assertion that Blender's UI designers don't actually drive the usability of the software?
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.
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.
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.
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.
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.
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).
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.
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.
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.
Fixed that for you.
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.
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.
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.
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.
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.
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.
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
I agree, for on/off a checkbox would work better
Somtimes. Checkboxes work for "yes" or "no", but they're not idiomatic for other "a" vs "b" selections.
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.
Do you have any support for anything you've said that isn't based entirely on your own assumptions and feelings about designers?
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.
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/
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.
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?
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.
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.
Details?
So? The justification is still substantive. What would change in a real slider that turns real setting on/off?
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.
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)
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.
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.
You're substituting assumption for knowledge.
Most novices can't distinguish poor practice from poor practitioners from poor general concepts.
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.
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.
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.
Spot on. Devs have on average extreme levels of confidence in unrepresentative opinions (space bar heating) and think UI is beneath them.
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.
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.
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.
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.
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.
the color choice is the problem, not the toggle.
If you had red or green, which one is on?
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
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
Properly so.
Imagine every real-world appliance power toggle was labelled "Power?".
Real world appliances dont use checkboxes to power toggle
Checkbox is nearest in equivalence.
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.
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.
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.
But, making UIs tuned for colorblind people make it easier also for others - colors should be distinguishable easily.
Adding extra differentiators also helps people with other kinds of vision problems. The benefits of accessibility often go beyond the initial target audience.
lets ask someone who's colorblind
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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).
Wow just did what you suggested and indeed it feels much faster. I was sceptical at first but this is actually better.
Thank you for this. I didnt know I wanted disabled animations until I tried it just now.
More like "for the same reason a fish needs a bicycle".
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.
Isn't shadowed and flat sort of the opposite of each other?
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.
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.
Isn't that the effect you get when you have a large diffuse light source directly above?
Not with a "flat piece of paper of zero height"
Exactly. "Environmental cue" my ass :)
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?"
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.
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.
Try to disable/reduce animations in your OS via accessibility settings, you will see that you really don’t lose much.
I have a different definition of what a "need" is.
I miss old school checkboxes for UI toggles. They're crisp and clear and don't entice bored people to animate them.
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?
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.
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.
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.
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.
If it only were that way, we wouldn't complain. But it's not.
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.
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.
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.
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.
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.
UI has become the domain of marketing and branding.
Checkboxes and switches serve different functions and shouldn't be used interchangeably: https://www.nngroup.com/articles/toggle-switch-guidelines/
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.
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?
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.
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.
I beg to differ. Quick search shows that people animate checkboxes too:
https://stackoverflow.com/questions/44876144/how-to-style-th...
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...
Or you could just use a checkbox
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.
Checkboxes can usually be toggled by clicking/tapping on the label. That may not resolve all criticism, but I'm just saying.
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.
Preferably both. Make it a checkbox for clarity, and animate it for input feedback.
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?
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?
Microsoft's Android RDP client does this, the biggest issue is that it's not expected behaviour.
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).
> 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.
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.
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.
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
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.
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.
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.
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.
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?
Or they simply realized that so many practitioners are to blame that the distinction barely matters anymore.
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.
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.
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
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).
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.
Big disagree on that. Sound and haptic feedback are clearly inferior solutions to the obvious one: an animation.
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.
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.
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.
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)
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.
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.
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
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)
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.
You were so close to reading the part where it explains why that's happening and how to fix it.
The jittering was an anti demo i think
“Accessibility > Reduce animations” is the magic trick to make modern UIs feel snappier and less distracting. I wish web UIs would respect it.
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.
I use this on iOS and it still leaves a lot of animations that could be sped up.
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
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.
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.
Remember that time when the ios calculator was messing up with simple arithmetic due to the animations?
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.
I think the map example is better. Without the animation, you have to figure out visually how far the map moved.
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.
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.