
Too Many Knobs - ashitlerferad
http://neverworkintheory.org/2016/06/09/too-many-knobs.html
======
andybak
I've noticed a trend in many web apps to stop doing something that used to be
standard

It's this: you're displaying a list of things that have various properties. It
used to be the case that you're be allowed to sort and filter by any property.
Many web apps nowadays seem to 'curate' my sort and filter options and in many
cases a particular use is crippled because the property I want to sort or
filter by is one that the author deemed a minority use-case.

Now the programming cost of allowing filtering by anything is minimal. The
cognitive load on the user is minimal (once you've got the UI for one property
then adding more doesn't make much difference)

I've found this deeply frustrating on many occasions.

~~~
OldSchoolJohnny
"Now the programming cost of allowing filtering by anything is minimal"

Not only is this not true except in your imaginary app but it's also
disregarding the incredibly bad UI that can come from allowing everything to
be filtered.

A good design has constraints and thoughtful choices. A shitty design has
everything possible thrown on the screen because "allow filtering by anything
is minimal".

~~~
wallacoloo
This is highly application-specific. If you're looking for components to use
in some design, for example, it's useful to have the component value, power
rating, cost, form-factor, etc, all displayed together and
filterable/sortable. If the application doesn't allow for filtering in this
context, then that's something that the user ends up doing mentally. Worse, if
the application doesn't allow all this information to be displayed as a
summary, you end up with 50+ products for which you have to manually click a
link and skim the product brief of each one individually.

For example, here's Newarks's procuct chooser [1]. You can sort and filter by
_any_ field. It remains uncluttered by default-populating only the most
commonly-used fields, but it avoids sacrificing any capabilities via making
these hidden fields easy to access (click the "extended" button right above
the table header).

I'd like to point out that in lists like these, the parent comment is 100%
correct in saying "[the] cost of allowing filtering by anything is minimal".
And while I'm sure an experienced designer could improve the UI, this is a
scenario in which _sacrificing_ capability for beauty is absolutely an
inappropriate thing to do.

[1] [http://www.newark.com/eeprom](http://www.newark.com/eeprom)

------
jdmichal
I think I can isolate the entire issue to this one line, emphasis mine:

> Only a small percentage (6.1%-16.7%) of configuration parameters are set by
> the majority of users; a significant percentage (up to 54.1%) of parameters
> are _rarely_ set by any user.

The necessary question is, how many _installations_ used at least one rarely-
set parameter? Would those installations have happened _without_ that
parameter? How much effort went into developing that parameter, versus the
profits of those installations?

~~~
Negitivefrags
Reminds me of this article:
[http://www.joelonsoftware.com/articles/fog0000000020.html](http://www.joelonsoftware.com/articles/fog0000000020.html)

The pull out quote being:

 _A lot of software developers are seduced by the old "80/20" rule. It seems
to make a lot of sense: 80% of the people use 20% of the features. So you
convince yourself that you only need to implement 20% of the features, and you
can still sell 80% as many copies.

Unfortunately, it's never the same 20%. Everybody uses a different set of
features._

~~~
felipeerias
The same idea applies to those advocating for having "simple" and "expert"
configuration menus: everybody's expertise is different, and changes over time
as we learn and forget things.

------
ktRolster
I'd rather have confusing software that does what I want, than simple software
that doesn't do what I want.

I'd suggest the proper response to this is, "Make the common case easy, make
the uncommon case possible."

~~~
adrianN
I'd rather have five simple tools that do what I want than one tool that can
in principle do what the five tools do if you massage its configuration
enough.

~~~
dctoedt
In my real-world tool kit for household use, I've got a configurable
screwdriver with multiple heads of various sizes and shapes (slot, cross-
point, etc.). I also have a bunch of conventional screwdrivers. I use the
latter far more.

~~~
vcarl
But when you come across a Torx screw, I bet you're really happy you have the
configurable screwdriver.

~~~
dctoedt
Actually I have a Torx screwdriver too -- and the multi-head configurable
screwdriver doesn't.

------
TeMPOraL
_sigh_

That's how you get shiny toys, not useful tools.

The advice here is good if your primary goal is to successfully sell glorified
interactive ads in a market where people buy software by looking how pretty it
is and making their choice in 2 seconds. If that's your goal, then ok, one has
to make a living, but in this case I don't want your software, and I'll
discourage everyone from using it.

Sane defaults + flexibility are a way to go. Software should empower the user,
and part of this empowerment may be suggesting a particular workflow, but it
should not _force_ one to use that workflow and never stray from it. And don't
give me the excuse that "more options == much more complexity == much harder
to add new features". That's only true if you write utter spaghetti code, and
fuck it, programmers get paid so much so that they do this right.

~~~
eterm
Emphasis on sane defaults.

One issue is that "sane" changes over time _, but it 's hard to change
defaults without upsetting people who suddenly find their defaults changed
because of an update.

(Although I'd argue that's best solved by letting them be upset until they
understand why the default changed.)

_ e.g. a Video capture which previously defaulted to 320x240 might later
default to 640x480 and now default to 1440x720.

~~~
thaeli
Or better yet, intelligently handle the change as a suggestion during the
upgrade process. "We see you are still using the legacy default 320x240
setting. We are now recommending 640x480. Do you want to change to this new
recommendation, or keep your existing setting?" Something like that.

------
etatoby
I think Firefox is a great example here.

It has a simple UI to guide the user into finding and setting the most common
options. That UI must be as simple as possible for new users and can be
changed regularly, according to the changing needs of the majority of users.

It also has an advanced, generic but type-safe UI (about:config) for finding
and setting any possible option present in the software.

Configuration files are the traditional way to achieve this second level, but
they don't always help the user in _finding_ the options and are generally not
type-safe.

~~~
optforfon
I think about:config is terrible. It's really hard to find anything in it.
It's very "if you know its there you will use" but has no discoverability.

For instance I was wondering if I could have one tab connect over a VPN while
the rest were over my normal connection. I have no idea if that's an options
somewhere in the millions of toggles

EDIT: You know how applications used to be have an "Advanced" button that'd
give you a nicely organized display off all the "extra" toggles? Whatever
happened to that paradigm?

~~~
delecti
> You know how applications used to be have an "Advanced" button that'd give
> you a nicely organized display off all the "extra" toggles?

I think your example of about:config is also an explanation for why that went
away. It used to be possible to reasonably put all of the more esoteric
settings on a single page (or a small, single-digit, number of pages), but
that's no longer the case for many pieces of software. Also realistically the
overwhelming majority of users probably already weren't going into the
advanced settings, and those that were are probably more capable of handing
about:config.

~~~
Programmatic
At least there were options that were grouped in a sane fashion and
discoverable while I was in a particular screen trying to grope around to find
a setting that I needed to change. about:config is not discoverable in any
way, shape, or form and we've lost the ability to discover capabilities that
you don't look for in particular via a broader search. The ability to find
something in passing that is related to your mission has severely diminished.

------
Bartweiss
And yet _more knobs_ is the difference between Photoshop and Elements, or
Elements and Photo Viewer. I'll be Photoshop is full of features with <1%
usage, and that's how it should be. Those components don't have to be
(shouldn't be) displayed at equal visibility to others, but they shouldn't go
anywhere. The entire value of the program is that if you do want them, they're
there.

Removing low-use features is a dangerous game; much of the best software out
there (Excel, Photoshop, Viz, etc) is defined by an enormous feature set and a
high skill ceiling.

~~~
OldSchoolJohnny
Arrghh...jesus there are a lot of "engineers" in here that can't seem to see
the forest for the trees.

Yes _we_ developers and engineers as a class of human beings love being able
to set things to the nth degree as can be seen by the comments here but that's
not necessarily the right choice for the vast majority of projects.

Most normal human beings want simple tools that do what they say on the box
and don't require much cognitive load at all.

Every setting, every "knob" introduces to the average user a feeling of
frustration, confusion, complication.

To an engineering minded person they might find all those options exciting but
to someone who just needs to GET SHIT DONE those extra options are hellish and
anxiety inducing.

In a few rare cases an application is best designed with more knobs but it's
very definitely the exception and almost always a clear sign of shitty design
made by engineers for people who they imagine are like them and not
professional designers who have actually worked with the general public and
know what they actually want, how they think, what they need.

More knobs is almost always a sign of lazy thoughtless design.

~~~
bpchaps
Not sure why you're getting downvoted. I completely agree.

I use photoshop maybe once every two months and have found that its interface
is _completely inaccessible_ if you don't use it full time.

I understand that it's great to have full control over everything, but there's
a point where it's overkill in Getting Shit Done. Hell, it's gotten to the
point with me where I'd rather use cv2 over photoshop/gimp for most things...

~~~
Programmatic
Meanwhile, I fire up the average application that uses the Gnome HIG spec, and
I find it horrendous to use. They take it a number of steps further and
remove, completely and thoroughly, any ability to customize. I very much like
the Apple mentality circa 2005 with sane, intelligent defaults, a small number
of configuration options in a small number of screens, and an advanced button
for everything else. Apple did a very good job back then of making their
software feature complete and customizeable without making it a shit show in
either the too dumb or too complex direction.

~~~
bpchaps
There's a middle ground. I'm fine with tons of configuration, but at least
make some sane defaults or prompts so that I don't have to read a giant wiki
to do an initial setup. Everybody initially runs through it, so why not spend
the time it took to write the wiki and write prompts for an installer,
instead?

------
chillaxtian
> a significant percentage (up to 48.5%) of configuration issues are about
> users' difficulties in finding or setting the parameters to obtain the
> intended system behavior

this is the important bit to me.

i don't like using software that feels like it could fall over because i
turned the wrong combination of knobs the developer didn't anticipate.

opinionated, fixed configuration is a nicer experience than an app that can do
anything, if you bend it to your will.

~~~
TeMPOraL
The thing is - some of us want software not for "experience", but for its
utility. If I want "experience", I can go to a theme park or play a video
game. I expect my software to help me achieve my goals faster and more
efficiently, or to at least eliminate clutter in my life.

Also, nothing really prevents one from having the settings hidden in the
"advanced" menu. It's not either/or.

~~~
Hondor
Nobody ever says they want fewer options, but that's because it's never such a
pressing issue as not having the one you want.

In a program I develop, I sometimes remove an option and people complain, then
it turns out they were randomly tweaking that option to try to solve some
problems that it was never going to solve in the first place. They just liked
the feeling of being able to control _something_. So those are cases of bad
options that should have been removed because they made it harder for people.
People just can't help but try changing settings when something doesn't work,
and hiding them in an "advanced" menu doesn't deter them. That's where all the
most powerful settings are afertall! It encourages frustrating time wasting.

------
simula67
This is a very important question to ask, but I am a little frustrated reading
the paper. I went into reading the paper expecting answers to these questions
:

1\. How much is the problem of having too many configuration options mitigated
by having sensible defaults ?

"a significant percentage (up to 48.5%) of configuration issues are about
users’ difficulties in finding or setting the parameters to obtain the
intended system behavior; a significant percentage (up to 53.3%) of
configuration errors are introduced due to users’ staying with default values
incorrectly."

The former means the configuration options provided do not match the ones
desired by the user, not whether there was too many or too few. If anything it
encourages software authors to provide more knobs. The latter doesn't have a
strong enough correlation to the number of configuration parameters at all.
For example, say all these errors happened at Google because of high load, and
they were using Apache with default configuration which was built for small
and medium scale websites.

2\. How does having many configuration options affect software update process
?

No idea

3\. What percentage of users are unhappy due to having too many knobs (
decision fatigue, fear of missing out ) ?

17.3%∼48.5% of users calls to the technical support center and questions
posted on forums. I assume this is a conservative estimate.

4\. Does having too little knobs cause software to be forked and cause
fragmentation ?

No idea

5\. Does the result differ when applied to application software ( vs system
software ) ?

Not in scope.

Need more research.

~~~
nullc
As soon as you have multiple dimensions of configuration it might be
impossible to provide better defaults-- that "wrong for 53.3%" could be a good
number reflecting the best possible defaults.

~~~
collyw
Not really. The video players on Linux have tons of options that I could set,
but I hardly ever do.

~~~
greggman
And do those options clutter the ui?

I use vlc. 99% of the time all I need is the standard ff, play, rew and the
que bar. But I'm also one of those uses that uses many of the other buried
features. If they weren't there I'd switch players but they're buried and so
the basic ui is uncluttered

------
rodionos
I can only attest, configuration bloat is especially relevant to complex
enterprise products, for obvious reasons. What we normally do in our products
is to provide a simple interface to view a filtered list of non-default
settings. We also have a way to export this list of custom setting names (not
values), so we can query our customer base once in a while, to check which
settings are not utilized. We've used this trick to internalize or EOL a lot
of "knobs" that haven't been used at all.

~~~
mrweasel
>configuration bloat is especially relevant to complex enterprise products,
for obvious reasons

I've always assumes that enterprise software has complex configuration options
because it's more bespoke than the supplier would have you believe. So rather
than delivering a piece of software tailored to the need of one, or a few
customers, the new behaviour just becomes a setting in a much, much larger
system. The goal being having just one code base.

~~~
joshyeager
Our product is on the small side of "enterprise". We have many configuration
options that are customer-driven, but we're not trying to replace bespoke
software.

For example, we have 5-6 different settings for password policy. Most
customers use the defaults, but the ones in banking and government usually
have very specific security rules that require them to tweak the settings. One
allows 10-char passwords but requires them to expire in 60 days. Another is 12
characters and 90 days. And so on.

~~~
rodionos
We had that too. At some point we added LDAP authentication and it took care
of user credential management. LDAP (AD) is universally present in the
enterprise.

------
xchaotic
tl;dr: "there is too many setting, most people won't even use them". The
solution IMO is not to remove those knobs completely, but to set defaults well
and be able to 'pop under the hood' when you need as you probably know what
you're doing by then. A good use case is an editor - most recent successful
editos such as Sublime, VSCode etc are minimalistic to begin with, but very
configurable behind the scenes. For starting user it's nothing but text
editor, for an advanced user it can be a full blown, build, testing and
deployment enviornment

~~~
stephengillie
When making Office 2007, the MS Office team had the problem that 99% of their
feature requests were for features already existing. Users couldn't find them.

Their solution was a UI change, from menus and toolbars, to the oft-maligned
Ribbon. Advanced settings were kept almost the same as in previous versions,
and the button to access those was an arrow in the section containing common
settings.

~~~
ourmandave
_Users couldn 't find them._

That's my problem with the oft-maligned Ribbon. It changes it's appearance
based on the window width.

So the first time an option might be a large-icon-with-text.

The next time you look for it, it may be a small icon, have no text, or be
completely hidden. That's 4+ visuals for the same option.

</rant>

~~~
digi_owl
Never mind that menus could be navigated by keyboard. You hit alt, then either
the highlighted letters or used the arrows to move around.

Do it frequently enough and you can pretty much do it blind.

------
kps
“Star had many fewer commands than today’s systems, and it didn’t do it by
having fewer functions. It just had fewer commands.” — Dave Smith¹ at The
Final Demonstration of the Xerox ‘Star’ Computer²

Most UX designers are not as good as David Smith; they worship Apple/Jobs'
“function follows form” misunderstanding of the Star GUI, and think you need
to remove functionality in order to remove complexity.

¹
[https://en.wikipedia.org/wiki/David_Canfield_Smith](https://en.wikipedia.org/wiki/David_Canfield_Smith)

² video:
[https://www.youtube.com/watch?v=_OwG_rQ_Hqw](https://www.youtube.com/watch?v=_OwG_rQ_Hqw)
text:
[http://archive.computerhistory.org/resources/access/text/201...](http://archive.computerhistory.org/resources/access/text/2015/09/102737965-05-01-acc.pdf)

------
OliverJones
The VMS product managers at Digital figured this out in about 1985. VMS was
horrendously configurable, with all sorts of system settings to tweak.

As I recall, product management forced the issue by making it so the dev team
didn't have access to their own machines to tweak parameters. It didn't take
long in VAX years for the OS to become more self-configuring. It was a
draconian approach, but helped customer satisfaction.

------
Dowwie
This blog is providing a valuable service, aggregating and commenting on
research. Are there others like this?

------
6stringmerc
On topic, I do think studying interfaces is exceptionally helpful. Just take a
look at all the approaches in music! Faders, knobs, buttons, toggles...the
gamut. Such a fascinating issue...and can be confusing, no lie.

But too manky knobs? How about Too Many Buttons?!

(It's a DJ parody video and actually hilarious):

[https://www.youtube.com/watch?v=grYXuR8ODwY](https://www.youtube.com/watch?v=grYXuR8ODwY)

------
jdub
Havoc Pennington in 2002:
[http://ometer.com/preferences.html](http://ometer.com/preferences.html)

------
ohazi
This is the kind of thinking that destroyed GNOME 3.

~~~
jeremysmyth
I was thinking precisely this.

"User-friendly" depends _entirely_ on the user in question. I find Gnome 2 to
be considerably more "user-friendly" than Gnome 3, because Gnome 3 frustrated
my attempts to do what I expected to be able to do.

For that matter, I consider bash (and coreutils and family) considerably more
user friendly than Gnome, for a given value of "user" (me).

~~~
digi_owl
And thats why i think KDE back in the day, before plasma and all that bling,
had the right idea. The basic behavior emulated Windows 9x pretty closely,
thus anyone passably familiar with Windows could jump right in and use KDE.

This in turn lessened the transition friction, as people try to do something
but do not find it where they expect it from memory.

------
marcosdumay
So, users don't change the settings on your software? Good for you. That means
you have good defaults, and should be one of your goals.

------
nxzero
Unlike an interface on the net with to many choices, in a none emergency
situation, I love having too many knobs.

------
ademarre
There are some good observations here. I believe a large part of the interface
problem is that people try to design interfaces that make tools easy to _use_
, but it's usually better to design interfaces that make tools easy to
_understand_. There's a difference.

------
Too
It's funny that they call it "over-designed" when in fact over configuration
is usually the result of the opposite: lack of design.

------
dwarman
My own saying on this:

"That which _can_ be configured _must_ be configured",

corr: "Defaults Aren't".

Inspired by my early experiences with early Windows 3.

