3 ms·

> Appropriately applied anything is good. I am disputing whether this is an appropriate application. Ok, explain why this animation is not an appropriate appli

> 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.

James_K 3y ago
> Read the comment I wrote initially 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.
- chefandy 3y ago
  >>> 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.

James_K 3y ago

> Read the comment I wrote initially 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.

chefandy 3y ago
>>> 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.