6 ms·

> you didn't put in any kind way to configure it. I have often found that in many projects I have worked on that there are always UX compromises that are made

> you didn't put in any kind way to configure it. I have often found that in many projects I have worked on that there are always UX compromises that are made for good reasons (typically to make the primary use cases as usable/simple/easy as possible etc, often at the expense of "power users"). Things that can be configured often never get done purely due to time/resource constraints, rather than due to any maliciousness or lack of foresight. You can bet your bottom dollar that the engineers building the system will have brought up the fact that something can/should be a user preference/have a power-user shortcut/etc etc during early stages of design & development (since the engineers tend to fall into the "power user" category due to their familiarity with the software they're making) However, I have found that once the primary use case gets marked as done, it is never updated to allow power users to shortcut/configure bits and pieces "because agile" (i.e. you are off to the next feature and there is never a time to go back and look at tech-/UX-debt). For what it is worth, I don't think this is a bad thing. Often the "power users" with some niche workflows are typically a) a very, very small percentage of your users, and b) a very, very vocal percentage of your users. Most of the users will just get on with their life when using your software, but it is the "power users" who will make sure that you're aware of how much your team's work sucks. When the "power users" are a significant proportion of your users, only then is it worth formally recognising their needs as part of the formal design, otherwise it generally seems to be a lot of work to support the niche needs of literally a handful of users at the opportunity cost of adding features for the other 99.99995% of your users.

jcelerier 7y ago
> Most of the users will just get on with their life when using your software, but it is the "power users" who will make sure that you're aware of how much your team's work sucks. It is enough that one make a viral blogpost detailing why he thinks your software sucks, for a lot of people to instantly put your software in the "won't touch" category though.
- FalconSensei 7y ago
  possibly 'a lot of people' meaning other power users though. How much blog posts about software do you think regular folks read?
  - airstrike 7y ago
    > How much blog posts about software do you think regular folks read? Zero, probably, but one might argue that opinions of power users have somewhat of a disproportionate weight in that they influence close friends and family much more than those of average users.
  - jcelerier 7y ago
    There is no such thing as "regular folk". People with an interest in photography will follow photography blogs, people with an interest in music will follow music websites, etc... e.g. music making forums such as GearSlutz / KVR have 380k / 390k members. DPReview, for all things photography has millions of posts. And only a small portion of people are active, the immense majority just reads without registering an account - for instance the current ratio in gearslutz is 8:1 (714 members and 5929 guests).
    - FalconSensei 7y ago
      I was talking about this: > It is enough that one make a viral blogpost detailing why he thinks your software sucks, for a lot of people to instantly put your software in the "won't touch" category though. People in general just want an app that does what they want to be done. A lot just install the first search result, some will look at options and comparisons. But saying one blog post will make a lot of people put a software in the 'dont touch' category doesn't seem that realistic
    - bartaxyz 7y ago
      Case in point. Music notation is a good example. There's Sibelius, which is the most widely known software for transcribing music. And it's been on top for a long time. But since everybody in the music community dislikes its UX, many people will jump it straight over and go to the second google result.
kd5bjo 7y ago
> You can bet your bottom dollar that the engineers building the system will have brought up the fact that something can/should be a user preference/have a power-user shortcut/etc etc during early stages of design & development As a developer, I’ve come to respect the curse of dimensionality w.r.t. testing and quality control: every binary option doubles the number of possible user configurations, and thus the testing load. In a very concrete sense configurability leads to more buggy code, and I usually err on the side of reliability.
- freepor 7y ago
  Best description of this is from Jack Dorsey: you have to get the details perfect, and the only way to do that is to limit the number of details.
- marcosdumay 7y ago
  > every binary option doubles the number of possible user configurations, and thus the testing load Only if you assume your software is the worst possible variety of spaghetti. Configurations do increase the software complexity. By how much is a very complicated question.
  - jerf 7y ago
    In theory, every additional binary configuration item doubles your state space, because you have all the old state space, but now both with that value on and off. It is tempting to say that in practice the result is less than this, but in practice, it isn't. Adding a binary option may seem not to double the state space because it only modifies a small portion of the original space. e.g., imagine an option that the user sets to force all emails to be in ALL CAPS. Strong abstractions can mostly contain that state space increase in a principled manner to just that email code, for instance. But if you've been doing this for ten+ years, you've almost certainly encountered the moral equivalent three other supposedly equally-well contained things interacting to produce a bug. Maybe if the user set this setting to true, and was using your UI in Armenian, and all the other settings on the page are in their longest possible form in Armenian, and your UI guy used a fixed-size frame ever so slightly incorrectly, your setting disappeared off the UI entirely, just to draw one example out, even though you had a "proof" that this setting couldn't affect anything but the email code. Any number of other ways this could go wrong. None of our tools are good enough to fully contain the exponential state space explosion exponentially correctly, and it will sooner or later push through your best efforts to contain it. One of the best ways to prevent this is just not to feed the exponential monster.
deleted 7y ago
[deleted]
hinkley 7y ago
In general I have enjoyed the sparseness of the OS X UI, and I knew that there was a key you could hold down to give you more dangerous options in the right-click menu (like run this software you just downloaded). But only very recently did I learn that there are a bunch of hidden options scattered throughout the System Preferences that work the same way. I have mixed feelings about this, and I wonder if I would almost rather have the about: menu solution.

jcelerier 7y ago

> Most of the users will just get on with their life when using your software, but it is the "power users" who will make sure that you're aware of how much your team's work sucks. It is enough that one make a viral blogpost detailing why he thinks your software sucks, for a lot of people to instantly put your software in the "won't touch" category though.

FalconSensei 7y ago
possibly 'a lot of people' meaning other power users though. How much blog posts about software do you think regular folks read?
- airstrike 7y ago
  > How much blog posts about software do you think regular folks read? Zero, probably, but one might argue that opinions of power users have somewhat of a disproportionate weight in that they influence close friends and family much more than those of average users.
- jcelerier 7y ago
  There is no such thing as "regular folk". People with an interest in photography will follow photography blogs, people with an interest in music will follow music websites, etc... e.g. music making forums such as GearSlutz / KVR have 380k / 390k members. DPReview, for all things photography has millions of posts. And only a small portion of people are active, the immense majority just reads without registering an account - for instance the current ratio in gearslutz is 8:1 (714 members and 5929 guests).
  - FalconSensei 7y ago
    I was talking about this: > It is enough that one make a viral blogpost detailing why he thinks your software sucks, for a lot of people to instantly put your software in the "won't touch" category though. People in general just want an app that does what they want to be done. A lot just install the first search result, some will look at options and comparisons. But saying one blog post will make a lot of people put a software in the 'dont touch' category doesn't seem that realistic
  - bartaxyz 7y ago
    Case in point. Music notation is a good example. There's Sibelius, which is the most widely known software for transcribing music. And it's been on top for a long time. But since everybody in the music community dislikes its UX, many people will jump it straight over and go to the second google result.

kd5bjo 7y ago

> You can bet your bottom dollar that the engineers building the system will have brought up the fact that something can/should be a user preference/have a power-user shortcut/etc etc during early stages of design & development As a developer, I’ve come to respect the curse of dimensionality w.r.t. testing and quality control: every binary option doubles the number of possible user configurations, and thus the testing load. In a very concrete sense configurability leads to more buggy code, and I usually err on the side of reliability.

freepor 7y ago
Best description of this is from Jack Dorsey: you have to get the details perfect, and the only way to do that is to limit the number of details.
marcosdumay 7y ago
> every binary option doubles the number of possible user configurations, and thus the testing load Only if you assume your software is the worst possible variety of spaghetti. Configurations do increase the software complexity. By how much is a very complicated question.
- jerf 7y ago
  In theory, every additional binary configuration item doubles your state space, because you have all the old state space, but now both with that value on and off. It is tempting to say that in practice the result is less than this, but in practice, it isn't. Adding a binary option may seem not to double the state space because it only modifies a small portion of the original space. e.g., imagine an option that the user sets to force all emails to be in ALL CAPS. Strong abstractions can mostly contain that state space increase in a principled manner to just that email code, for instance. But if you've been doing this for ten+ years, you've almost certainly encountered the moral equivalent three other supposedly equally-well contained things interacting to produce a bug. Maybe if the user set this setting to true, and was using your UI in Armenian, and all the other settings on the page are in their longest possible form in Armenian, and your UI guy used a fixed-size frame ever so slightly incorrectly, your setting disappeared off the UI entirely, just to draw one example out, even though you had a "proof" that this setting couldn't affect anything but the email code. Any number of other ways this could go wrong. None of our tools are good enough to fully contain the exponential state space explosion exponentially correctly, and it will sooner or later push through your best efforts to contain it. One of the best ways to prevent this is just not to feed the exponential monster.

deleted 7y ago

[deleted]

hinkley 7y ago

In general I have enjoyed the sparseness of the OS X UI, and I knew that there was a key you could hold down to give you more dangerous options in the right-click menu (like run this software you just downloaded). But only very recently did I learn that there are a bunch of hidden options scattered throughout the System Preferences that work the same way. I have mixed feelings about this, and I wonder if I would almost rather have the about: menu solution.