4 ms·

It might be an over-adjustment from the software designers. In the early days of software, there was a larger fraction of power users, who wanted lots of option

by yccs27 5y ago

It might be an over-adjustment from the software designers. In the early days of software, there was a larger fraction of power users, who wanted lots of options and were willing to fiddle with them. However, settings were often an excuse for not having sensible defaults, auto-detection, context-sensibility and other things for a fluid user experience. Then came a wave of companies focusing on UX with great success, who often dropped settings to focus on "magic" functions etc. This means UX becomes correlated with less settings, but removing options does not help users - on the contrary! But unfortunately it gives the impression that settings are bad for UX.

tormeh 5y ago
Options do become dangerous to the team building the UI, though. It's easier to add another option and the keep the previous behavior as default than to do the hard work of figuring out what the best behavior is and then, if the new behavior is better, having the courage to change the default. Having no options is good for discipline as it removes the temptation of doing it the easy way. There's also the problem of bugs. Software with more settings have more code paths. It's harder to test, and harder to refactor.
- nirvdrum 5y ago
  These are all valid concerns, but UX is purportedly concerned with serving the user. Reducing expenses is a competing concern. Together, they influence the design, but I don't think it follows that removing options leads to a better user experience. It could, but it's not a given. > It's easier to add another option and the keep the previous behavior as default than to do the hard work of figuring out what the best behavior is and then, if the new behavior is better, having the courage to change the default. Having no options is good for discipline as it removes the temptation of doing it the easy way. Ideally, you already knew what the trade-offs are before you built the feature. That should have come out of a user study. Human psychology simply doesn't change as substantially or as frequently as modern UX seems to suggest. Of course, things can fall through the crack and you can learn new things (even that previous conclusions were misguided). But, setting up all options as a choice you need to make for the user isn't necessarily helping the user experience. Some portion of the world prefers a 12 hour clock, some portion a 24. If you're adamant about only showing one of those and it's not configurable, you haven't helped the people with a different preference. You're inflicting your design on people without really taking their cultural norms into account. I'd go a step further and suggest changing defaults on people is something that should never be taken lightly because the user experience isn't a point-in-time thing. Changing workflows on existing users is a negative user experience in many cases. As a concrete example, the ReasonML language forked into another language call Rescript. The code formatting tool in Rescript works almost identically to the one in ReasonML and that's by design, since it's supposed to facilitate migration. But, for whatever reason, the new formatter dropped the option to configure line width. So, if you used to set your line width to 120 characters, too bad. You have to use 80 characters or don't use the tool. Also, you need to chance your workflow and any configurations using the old flag. Having the option to change a numeric variable is not some overwhelming burden. Forcing a fixed value isn't some courageous decision and it's not based on any human factors studies. It feels like an overreach of "opinionated software" that ultimately made my code harder to read (both languages use annotations that artificially increase line length). In the end I abandoned the migration, which I suppose means if they poll community members, they'll have something of an echo chamber. > There's also the problem of bugs. Software with more settings have more code paths. It's harder to test, and harder to refactor. This sounds like a failing of software engineering to me. To the extent that this field's raison d'être is to make computers perform work for humans with minimal fuss, our tooling should be geared towards supporting that goal. Dropping functionality that would be beneficial to people because it's more difficult to support sounds like trying to mold people to the machine rather than the machine to people. Certainly, you can have a product that functions, but it's similar to all the other things we have to put up with because a better option doesn't exist. This take isn't drawn from the book I mentioned, but I think the book has influenced my opinion on the matter. If settings/options lead to a better user experience but our tooling and development processes make adding settings/options difficult, we should try to improve our tools and processes. With that said, we have to operate with the constraints we have. I just don't think we should convince ourselves it makes for a better user experience. That sort of thinking tends to snowball.
  - MrStonedOne 5y ago
  - ethbr0 5y ago
    The central problem of modern UX is the same existential crisis architecture had in the 1980s -- whether it's a discipline of artists or scientists. Nobody wants to admit they're a scientist who follows experimental data at cocktail parties. Everyone dreams of being introduced as a creative genius. That yearning metastasizes into hubris, which ultimately leads to people making arbitrary changes, just because they can. Which isn't UX's, or architecture's, fault as a discipline, but is to say that the scientific process runs perpendicularly to our egotistical, flawed selves. And that the only way to avoid it is constant vigilance and pragmatism about what's actually driving a change request.
    - selestify 5y ago
      So how did the debate in architecture get resolved?
      - maccolgan 5y ago
        It didn't, now we have Walt Disney Concert Hall.
  - CRConrad 5y ago
    > In the end I abandoned the migration, which I suppose means if they poll community members, they'll have something of an echo chamber. Harking back to the survivorship-bias example above (reinforce warplanes in the bits that weren't all shot up on the ones that returned), if they define "community" as the users of the new language, they'll never realise line length was a significant problem: You and all the others like you aren't there to answer the question "Was line length in the code converter a problem for you?" with a resounding "Yes!", they'll get only "No" answers, and not realise what a huge impediment it is.
- BurningFrog 5y ago
  Often options come from an inability to make decisions. Should we do A or B? There are decent sounding arguments for both, so... let's dump that decision on the user, and move on!
  - chii 5y ago
    but if they are either mutually exclusive, or that one must be selected for the operation to work, then the designer/developer has to choose a default. Often, the user don't even know what they want, and assume the default is the right choice, since it's "professionals" who have chosen it.
    - KeepFlying 5y ago
      Of often they'll be unaware the setting exists or even more likely be unaware that the setting even _might_ exist (and therefore don't even think to Google it). Though often still theyll be afraid to look around at settings for fear of breaking things.
      - fattegourmet 5y ago
        not making the settings accessible is a design failure, imo
  - tremon 5y ago
    Are the different laundry programs on a washing machine due to the design failure? My oven has separate knobs for temperature, heat distribution and grill; is that a design failure? My car has both a steering wheel and a separate indicator light control; rain sensors and a manual wind screen wiper setting; light sensors and a manual setting for the headlights. Are these all examples of designers' inability to make decisions?
    - BurningFrog 5y ago
      Those all seem reasonable designs to me.
blowski 5y ago
Perhaps users early in their journey with your product want it to “just work”, because they don’t want to fiddle with loads of settings they don’t understand only to find your product is rubbish. As they become more proficient with your product, if they can’t tweak behaviour in certain ways, they might consider changing to a different product. And that’s where settings become useful.

by yccs27 5y ago

tormeh 5y ago

Options do become dangerous to the team building the UI, though. It's easier to add another option and the keep the previous behavior as default than to do the hard work of figuring out what the best behavior is and then, if the new behavior is better, having the courage to change the default. Having no options is good for discipline as it removes the temptation of doing it the easy way. There's also the problem of bugs. Software with more settings have more code paths. It's harder to test, and harder to refactor.

nirvdrum 5y ago
These are all valid concerns, but UX is purportedly concerned with serving the user. Reducing expenses is a competing concern. Together, they influence the design, but I don't think it follows that removing options leads to a better user experience. It could, but it's not a given. > It's easier to add another option and the keep the previous behavior as default than to do the hard work of figuring out what the best behavior is and then, if the new behavior is better, having the courage to change the default. Having no options is good for discipline as it removes the temptation of doing it the easy way. Ideally, you already knew what the trade-offs are before you built the feature. That should have come out of a user study. Human psychology simply doesn't change as substantially or as frequently as modern UX seems to suggest. Of course, things can fall through the crack and you can learn new things (even that previous conclusions were misguided). But, setting up all options as a choice you need to make for the user isn't necessarily helping the user experience. Some portion of the world prefers a 12 hour clock, some portion a 24. If you're adamant about only showing one of those and it's not configurable, you haven't helped the people with a different preference. You're inflicting your design on people without really taking their cultural norms into account. I'd go a step further and suggest changing defaults on people is something that should never be taken lightly because the user experience isn't a point-in-time thing. Changing workflows on existing users is a negative user experience in many cases. As a concrete example, the ReasonML language forked into another language call Rescript. The code formatting tool in Rescript works almost identically to the one in ReasonML and that's by design, since it's supposed to facilitate migration. But, for whatever reason, the new formatter dropped the option to configure line width. So, if you used to set your line width to 120 characters, too bad. You have to use 80 characters or don't use the tool. Also, you need to chance your workflow and any configurations using the old flag. Having the option to change a numeric variable is not some overwhelming burden. Forcing a fixed value isn't some courageous decision and it's not based on any human factors studies. It feels like an overreach of "opinionated software" that ultimately made my code harder to read (both languages use annotations that artificially increase line length). In the end I abandoned the migration, which I suppose means if they poll community members, they'll have something of an echo chamber. > There's also the problem of bugs. Software with more settings have more code paths. It's harder to test, and harder to refactor. This sounds like a failing of software engineering to me. To the extent that this field's raison d'être is to make computers perform work for humans with minimal fuss, our tooling should be geared towards supporting that goal. Dropping functionality that would be beneficial to people because it's more difficult to support sounds like trying to mold people to the machine rather than the machine to people. Certainly, you can have a product that functions, but it's similar to all the other things we have to put up with because a better option doesn't exist. This take isn't drawn from the book I mentioned, but I think the book has influenced my opinion on the matter. If settings/options lead to a better user experience but our tooling and development processes make adding settings/options difficult, we should try to improve our tools and processes. With that said, we have to operate with the constraints we have. I just don't think we should convince ourselves it makes for a better user experience. That sort of thinking tends to snowball.
- MrStonedOne 5y ago
- ethbr0 5y ago
  The central problem of modern UX is the same existential crisis architecture had in the 1980s -- whether it's a discipline of artists or scientists. Nobody wants to admit they're a scientist who follows experimental data at cocktail parties. Everyone dreams of being introduced as a creative genius. That yearning metastasizes into hubris, which ultimately leads to people making arbitrary changes, just because they can. Which isn't UX's, or architecture's, fault as a discipline, but is to say that the scientific process runs perpendicularly to our egotistical, flawed selves. And that the only way to avoid it is constant vigilance and pragmatism about what's actually driving a change request.
  - selestify 5y ago
    So how did the debate in architecture get resolved?
    - maccolgan 5y ago
      It didn't, now we have Walt Disney Concert Hall.
- CRConrad 5y ago
  > In the end I abandoned the migration, which I suppose means if they poll community members, they'll have something of an echo chamber. Harking back to the survivorship-bias example above (reinforce warplanes in the bits that weren't all shot up on the ones that returned), if they define "community" as the users of the new language, they'll never realise line length was a significant problem: You and all the others like you aren't there to answer the question "Was line length in the code converter a problem for you?" with a resounding "Yes!", they'll get only "No" answers, and not realise what a huge impediment it is.
BurningFrog 5y ago
Often options come from an inability to make decisions. Should we do A or B? There are decent sounding arguments for both, so... let's dump that decision on the user, and move on!
- chii 5y ago
  but if they are either mutually exclusive, or that one must be selected for the operation to work, then the designer/developer has to choose a default. Often, the user don't even know what they want, and assume the default is the right choice, since it's "professionals" who have chosen it.
  - KeepFlying 5y ago
    Of often they'll be unaware the setting exists or even more likely be unaware that the setting even _might_ exist (and therefore don't even think to Google it). Though often still theyll be afraid to look around at settings for fear of breaking things.
    - fattegourmet 5y ago
      not making the settings accessible is a design failure, imo
- tremon 5y ago
  Are the different laundry programs on a washing machine due to the design failure? My oven has separate knobs for temperature, heat distribution and grill; is that a design failure? My car has both a steering wheel and a separate indicator light control; rain sensors and a manual wind screen wiper setting; light sensors and a manual setting for the headlights. Are these all examples of designers' inability to make decisions?
  - BurningFrog 5y ago
    Those all seem reasonable designs to me.

blowski 5y ago

Perhaps users early in their journey with your product want it to “just work”, because they don’t want to fiddle with loads of settings they don’t understand only to find your product is rubbish. As they become more proficient with your product, if they can’t tweak behaviour in certain ways, they might consider changing to a different product. And that’s where settings become useful.