Comment by mattlondon | Hacker News Reader

Comment by mattlondon | Hacker News Reader

Parent Full thread

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

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

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

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.

If you look at what happens with Refactoring or Unit testing, instead of just listening to what people tell you is happening, you see that a lot of goes on is synthesizing one state from a small group of others, over and over again.

So for instance there may be five different criteria that decide whether you are qualified to receive a 10% off discount. You make a block of code that is responsible for emitting a single boolean, and the rest of the system only ever interacts with that single value.

Instead of an upper bound of 2^n you have one that is somewhere around n/3 factorial. Which is still a scary-big number, but might push out the dog leg a couple of years.

> instead of just listening to what people tell you is happening

Can you elaborate on what you’re referring to with this phrase? As far as I can tell, everyone here is reasoning from their personal experiences rather than adopting the opinions of others.

Ah, I meant 'in the literature' not in the thread. Just commenting on the frequent disconnect between 'why we do things' and why we do things.

> Only if you assume your software is the worst possible variety of spaghetti.

Gravity always wins.

The thing about exponentials that if the constant is > 1 the trend line essentially looks the same, the X axis just changes a bit. So maybe a boolean doesn't double the surface area, maybe it's only 1.5, that still results in compound interest. Even at 1.1, it only takes 7 booleans to double your surface area.

Yet, everything interesting happens on the border where things are falling but still not irreversibly so.

Yes, if you leave them wild options will overwhelm your code. The entire field of software engineering is focused on solving that exact problem; what people can do, with varying degrees of success.

The initial cost is quite low and there are techniques to reduce the growth factor, but I’ve seen no evidence of anything that reduces this below an exponential scenario.

Over large scales, exponentials can be reasonably modeled by a piecewise function that’s 0 below some threshold and infinity above it (1). That translates roughly into a fixed number of options that can be maintained, modulated by your development practices.

Without knowing what that limit actually is, what’s the best strategy for spending this limited resource? As there’s no such thing as an average person (2), I contend that this budget should be reserved for things that materially affect accessibility.

(1) This is the standard approximation for a diode’s I-V curve, for instance

(2) https://apps.dtic.mil/dtic/tr/fulltext/u2/010203.pdf

> every binary option doubles the number of possible user configurations

This is why you distinguish UI options from functionality options.

If you properly factor functionality out by modularizing UI, you end up with an order of magnitude less complexity.

Ok, so you’ve successfully reduced the problem space from 2^n to 2^(kn) + 2^(n-kn) , where k is the ratio of options in the two categories. That’s better, but still clearly exponential growth.

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.

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

possibly 'a lot of people' meaning other power users though.

How much blog posts about software do you think regular folks read?

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

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

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.

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

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.

Reply on news.ycombinator.com