> 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.
> 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.
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.
> 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.
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.
> 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.)
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?
> 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.
> 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.
> 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.
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.
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.
>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).
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.
>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.
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).
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.
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.)
> 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.
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?
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.
> 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.
> 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."
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.
> 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.
This is why I call you conceited – the only reason people can disagree with you is because they are stupid or because they haven't actually read what you said. You seem so confused by the fact that I have read it, and I find it to be unconvincing. You suggest that these switches exist primarily to look pretty, when as I understand it, their main purpose is to communicate that checking them has an immediate effect rather than only after form submission. I don't see them being used like that as much as I just see them jammed in random places, and even when they are I have to wonder if it would make more sense for the UI they are a part of to be made into a form. You dismiss the issue with state identification by saying they could represent "a binary choice between any number of things". The idea that a switch can have more states than just on or off is confusing to me, and that still doesn't help with the issue of determining their state unless you label both sides which is a waste in comparison to the simple checkbox, which draws on the user's existing knowledge from filling in forms on pen-and-paper.
> Copout
I'm sorry that I don't have the opinions you want me to have so that I'm wrong.
>>> 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.
>
Thought so.
> the only reason people can disagree with you is because they are stupid or because they haven't actually read what you said.
What I initially said is based in common industry practice and backed up by papers from academia, independent usability organizations like the Nielsen Norman group, and plenty of other independent entities. It's not secret-- lots of info is a quick google search away. It's nuanced. Lots of the info is in literature about accessibility-specific topics like designing for people with cognitive problems of various stripes, low vision, photosensitive epilepsy and similar conditions, motion sickness, and all sort of other less common neurological considerations. The default state of UI design is not adding anything unless it adds something specific and justifiable and doesn't kill any other sort of accessibility. Lots of interfaces violate those rules. Lots of interfaces are not designed by UI designers. Pointing to bad practices in those interfaces isn't an indictment of UI design or any of the practices that UI designers have. Your refusal to acknowledge all of this doesn't oblige me to gather empirical evidence to defend it.
I also wouldn't go gather a list of citations to defend the concept of OO programming to a crowd of non-or-slightly-technical designers subconsciously influenced by groupthink and a few clojure evangelists they'd worked with, citing code they saw in shitty wordpress plugins and ignorantly insisting OOP was the problem. Right, surely it would have been good code otherwise.
In this comment section, literally zero of the very critical people, you included, has responded with anything aside from some combination of personal preference, developer folk wisdom, and off-base assumptions, all buttressed with mistaken confidence. If you refuse to correct that with all of the info at your fingertips, that's your problem, not mine.
> I'm sorry that I don't havee the opinions you want me to have so that I'm wrong.
Ok let's break this down. A copout is avoiding responsibility for something, and in rhetoric, it's when you avoid addressing a direct point with nonspecific challenges to the premise, or by changing the premise to something that will still let you be right.
For example, "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."
This is a very cut-and-dried statement. Here's your verbatim response:
"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."
Rather than addressing the clear premise of how you'd respond to sweeping, arrogant, and unsupported criticism by arrogant laypeople, you change the premise to one where those designers are making criticisms you agree with. It completely avoids the obvious point, which is that you obviously wouldn't feel the need to cite your arguments in the face of baseless criticism from laypeople.
Go ahead and protect your ego by pretending I disregarded your legitimate response. Limber yourself up for some sort of 5 layer deep mental gymnastics about my being the one that was really changing the premise, or the like. But you're clearly not interested in honestly evaluating the veracity of anything you're saying, so I'm done here.
Most professionals get irritated when randos that think they're experts make a bunch of BS criticism of their professional practices. But developers are unique in that they get equally rankled by implications that knowing how to code doesn't give them expertise in everybody else's fields, too.
> Rather than addressing the clear premise of how you'd respond to sweeping, arrogant, and unsupported criticism by arrogant laypeople
Except I did address that in the next sentence[1]. Maybe you should read my comments before you write all this and accuse me of not reading yours.
> Thought so.
> The default state of UI design is not adding anything unless it adds something specific and justifiable and doesn't kill any other sort of accessibility
I did actually explain why it is not appropriate (that it communicates something specific which is contradictory to the way I often see it used). I'll add that it feels much worse than the native form widgets in websites where I often see it used, and it can degrade usability by being a non-standard input method. I also should point out that the null hypothesis doesn't need explaining. You've said yourself that the default state is not adding something, i.e. assume it is not appropriate until there is evidence to the contrary. The burden of proof is on you, and that is why I didn't deem that sentence worthy of specific reply.
> In this comment section, literally zero of the very critical people, you included, has responded with anything aside from some combination of personal preference
I don't control the actions of other people. That said, I did as you asked yesterday and looked it up, and the only study I could find said users didn't like toggles[2][3]. Wherever toggles are compared to binary non-toggle options, the other options are preferred though there is a degree of subjectivity to it. The only reason I didn't post it is because I assumed you were already familiar with the literature on the matter.
> Your refusal to acknowledge all of this doesn't oblige me to gather empirical evidence to defend it.
If it is as easy as you claim, it would be a lot less effort than writing all this and it would actually convince me you are correct (which I assume is your objective but it may not be). That seems like a much better option than calling me egotistical and stupid.
[1] "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."" - James K (2024)
[2] Plaisant, C., & Wallace, D. (1990). Touchscreen toggle switches: Push or slide? Design issues and usability study (CS-TR-2557, CAR-TR-521). University of Maryland.
[3] Alyaa Al-Jasim and Pietro Murano. 2023. Designing User Interface Toggles for Usability. J. User Exper. 18, 4 (August 2023), 175–199.
Those would be great citations of we were talking about that. This entire conversation and the article it's responding to are discussing UI animation and not the merit of any given UI widget. You're obviously just going to just keep claiming that whatever you kicked the ball into is the goal, so I'm washing my hands of this pedantic mess. Enjoy.
The fact that users prefer a non-animated widget to an animated one seems exceedingly relevant my statement that users prefer widgets that react instantly over animated ones. I would even call it a strengthened goal. If you accept this conclusion, then I have shown more than I needed to prove.
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.
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.
>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.
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.
> 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.
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.
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?
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.
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.
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.
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.
Bad design != Design. UI design is a communication medium, like technical writing. Within a weekend of fiddling, damn near anyone can operate the tools to assemble interfaces, but that does not mean they are interface designers. Failing to use color to appropriately communicate actions or state and thoughtlessly applied labeling are the actions of graphic designers trying to make things look pretty, or developers do to make things look 'designed.' That happens all the time and is no more an indictment of UI design than wordpress sites running janky homespun themes made from copy-and-pasted tutorial code are an indictment of web development.
> Failing to use color to appropriate communicate actions or state ....
No no no and no again!
Do not use color to to communicate actions or state unless that color can be used to statically differentiate between another color that is present in the UI at the same point in time. This is why syntax highlighting in code editors works because there is a state boundary between a word in one color and a word in another. It is why colors for toggle sliders indicating off and on do not work. What color is 'off' or 'go' or 'enable' or 'disable' or 'allow'. An animation of any type does not help and only adds CPU overhead and UI slowdown.
Animations can be useful only if they assist in disambiguating a transition between states. For example transfer of an item to a different position in a list. If the item animates across the screen the eye is guided to the new position. A toggle slider does not have this issue and should transfer to the new state immediately and the most important design question is how to interpret the current state of the toggle not the animation between the two state.
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.
> 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.
> 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.
> 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.
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)
> 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.
It's trying to communicate how to, among other things, apply animation curves to UI, just read it: "I use it for ... moving UI elements," "Speaking of UI, say"
I know it's easier to discuss generic things re. some Terra Design Incognita after erasing all of these specific details, but they do exist in the text even if you try to ignore context!
> 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 (they aren't and they do, and I know my experience better than whatever you can imagine about someone else) and an answer to a specific question for yet another generalization. Is Apple part of the vast majority? Check my other comment re. how the fundamental slider flaws appear in that impeccably unnoticeable design
> Most novices can't distinguish poor
And here you go again, incapable of demonstrating the value of a supposedly good general concept to address a general challenge in a case of a slider, instead veering off into an assessment of some generic group that's not present in this conversation.
> 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.
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.
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.