15 ms·

Too Many Knobs

161 points by ashitlerferad 10y ago

ktRolster 10y ago
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."
- collyw 10y ago
  Sensible defaults.
- djrobstep 10y ago
  I'd rather have simple software that does what I want.
  - sz4kerto 10y ago
    Then either other people don't have the software what they want (because there are so many different needs when it comes to any domain) or the complexity is transferred to finding/evaluating the huge selection of software.
  - etatoby 10y ago
    LOL that's called having your cake and eating it too, AKA impossible.
  - felipeerias 10y ago
    Exactly. Our tools should not add a layer of unnecessary complexity on top of already complex domains. If anything, they should take complexity away so we can focus on what is most relevant for the goals that we want to achieve. A lot of configuration options come into existence not because they are actually useful, but because the team had a disagreement that they couldn't settle, or because writing code that just figured out the right thing to do would be too complex. Options should be a way of empowering the user, not simply offloading work to them. It's very important to realise that our goals are not just related to the concrete problem at hand, but include things like "get out of the way and don't make me feel stupid".
    - TeMPOraL 10y ago
      But then a lot of options exist because the domain itself is complex and can't be captured in a one-size-fits-all solution. The only way to make something both very simple and very useful for a domain is to cunningly cut out parts of the domain. The end result is a pretty, simple and opinionated tool that doesn't really solve anything for anyone, but sure looks good on screenshots.
      - thaeli 10y ago
        This. Most "disagreements a team can't settle" are rooted in fundamentally different use cases of a complex domain.
- adrianN 10y ago
  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.
  - pron 10y ago
    Why? And what if that one tool came with five common configurations for the five usages?
    - adrianN 10y ago
      Because simple tools are easy to understand and easy to replace when you find something better. Once you invested a lot of time into configuring your GenericTool(tm) to do what you want you're locked into its ecosystem forever. Also, simple tools that do one thing only tend to do it better than tools that do lots of things.
      - pron 10y ago
        What if that one tool came with five configurations for your five usages, that you wouldn't have to touch? You can still replace one usage with another tool, if you like. I think that the idea of many simple tools is good in theory, but seeing that most important codebases last for ten or twenty years, use of many tools increases the likelihood that you've introduced a dependency on a product that may be discontinued/unmaintained. "Easy to replace" is fine if you're very familiar with the code and all the assumptions it makes about the product's behavior, but if a tool that some module of your system that no one has touched in more than five years all of a sudden disappears[1], replacing it may be almost as big an undertaking with replacing the one big tool, but the chances of that happening are greater (because you have more such tools, and small tools are more likely to be discontinued than big ones). [1]: Say, by no longer supporting your new hardware/OS.
        adrianN 10y ago
        Replacing just part of a big tool because there is a better alternative doesn't fly with management ("we already paid for big tool and it does what you want, why should we replace a part of it? It will just increase the complexity!"). I see small tools disappearing occasionally as a good thing. You should always be prepared to change parts of your system and a larger organization should have people that continuously work on improving the tooling. Assuming that your tooling will work indefinitely leads to ossified systems that can't be upgraded at all. Imho, tools should be treated just like code. You wouldn't write one big function that takes half a dozen parameters to change its behavior. You refactor it into multiple functions that are easier to understand and improve when requirements change.
- rasz_pl 10y ago
  I remember learning a saying years ago on slashdot. Difference between Windows and Linux: easy things are difficult in Linux, difficult things are possible. Easy things are trivial in Windows, complicated things are impossible. This was in XP era. Today the likes of Ubuntu/Gnome try their best to dumb down Linux.
- jamesroseman 10y ago
  The real takeaway here should be that engineers tend to make UX that feel good to them as engineers, and most of their clients will typically not be engineers. > I'd rather have confusing software that does what I want, than simple software that doesn't do what I want. Of course you would, or I would, or anyone who browses HackerNews would -- but it's not necessarily the best UX.
  - xixi77 10y ago
    If this is a business software, once the sale is done, users are going to pick it up because they pretty much have to. But the sale can easily fail in the first place if the product does not have a feature that particular customer wants, and the competing offering does.
jdmichal 10y ago
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 10y ago
  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 10y ago
    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.
  - rasz_pl 10y ago
    Plus there are power users and sheep. Sheep will follow power users, power users will expect extra features. No configurability means no power users means no sheep.
- afro88 10y ago
  Right - just because I rarely change a parameter doesn't mean it's not important. In fact, some of the most important parameters are set once and then forgotten about.
  - 10y ago
chillaxtian 10y ago
> 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 10y ago
  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.
  - red_admiral 10y ago
    Or a configuration file with proper documentation.
  - Hondor 10y ago
    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.
- jasonlotito 10y ago
  > opinionated, fixed configuration is a nicer experience Even when those opinions are wrong?
simula67 10y ago
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 10y ago
  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 10y ago
    Not really. The video players on Linux have tons of options that I could set, but I hardly ever do.
    - greggman 10y ago
      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 10y ago
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 10y ago
  >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 10y ago
    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 10y ago
      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.
deleted 10y ago
[deleted]
etatoby 10y ago
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.
- Klathmon 10y ago
  The problem with something like that is maintaining and testing all the possible settings. I can't possibly fathom how firefox tests all of their settings. There's just no way. And that leads to edge cases and buggy software.
  - jjnoakes 10y ago
    It isn't as big a problem as you might expect. A very low percentage of users even change the advanced settings, so any issues which might exist have a very low impact. If a user does hit a problem with some combination of settings, it is more likely they will report it with some useful reproduction information, since they are likely more of a power user than the average user. Finally, anyone changing advanced settings is more likely to understand that they may break something and are less likely to be upset, when compared to something fundamental breaking for all users.
    - jdmichal 10y ago
      In fact, Firefox even warns you upon navigating to about:config that you could very well break something.
      - Klathmon 10y ago
        And chrome warns you too, but it doesn't stop the flood of help posts in the forums, on reddit, and other places when something is broken because of a setting that someone forgot they had enabled. Just recently one of the updates for chrome broke the ability to interact with extensions if the user had enabled the flag "Material design in the browser's top chrome". There were tons of angry posts everywhere about how unusable chrome was because of that change, and how they should test their software better... As for only "advanced users" knowing what happens in there, just do a web search for "chrome://flags" and look at any one of the hundreds of blog posts, news articles, and tutorials showing you how to go in and turn on these few flags that "make chrome better".
TeMPOraL 10y ago
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 10y ago
  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 10y ago
    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.
andybak 10y ago
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.
- red_admiral 10y ago
  And further, the UI for sorting/filtering does NOT get in the user's way. Sure, a config screen with 100 check boxes on a page is bad UI, but a table that you can sort by any column looks almost exactly like one you can't sort, just that in the former case the column headers are clickable (or little arrows appear when you hover over the heading).
- dgoldstein0 10y ago
  One reason for this is that if the list is lazy loaded (e.g. paginated) in any way, it can be more difficult to make sorting & filtering work on more dimensions - mainly it requires the list to be indexed in extra ways. Not impossible, but some applications weren't designed to support it from the beginning.
  - Retric 10y ago
    If it's common to sort by X, you should add an index. But, if it's rare to sort by X then doing it the hard way is at worst (O) x log x which is a generally a non issue out to a few billion records. Remember, give me the next 100 of X less than Y is an O(N) operation.
    - gregmac 10y ago
      > But, if it's rare to sort by X then doing it the hard way is at worst (O) x log x which is a generally a non issue out to a few billion records. Not really true. Users aren't understanding if "sometimes the list page takes over 10 seconds to load". They don't understand (or care) that they are doing a non-indexed query or that the alternative is they don't get to do it at all. Removing a feature is often not acceptable, and so often the only resolution to a problem like this is to add an index. Of course, indexes increase the write times to your database. Indexes on every field increase the write times by a lot. Except sometimes you can't simply add an index, because you're displaying a calculated value and only calculate it for the page you're displaying. In order to sort by that value, you have to calculate for the entire system, so now you're into O(n^2) or worse complexity. You can also denormalize or pre-cache calculated values in some way (even going as far as adding something like ElasticSearch on top), but that introduces another dimension of problems (expensive updates, more potential for bugs and/or stale data). Do this for several fields, and you're now talking about quite a significant development effort, both up-front and for on-going maintenance, to support sorting that wasn't ever an actual requested feature and that only a small minority of users actually use. I know this because I have inherited exactly this problem before. Even as thousands turn to millions (let alone billions), anything worse than O(n log n) becomes painfully obvious rather quickly, and it tends to happen to the entire system at once. Suddenly you have to fix a whole bunch of "this feature is unusable slow, you broke my business" problems at the same time, while getting further and further behind your actual planned schedule. > Remember, give me the next 100 of X less than Y is an O(N) operation. ..IIF you spent the time to implement caching (and deal with the additional cache invalidation complexity problems). Many apps do paging on the database, or only do expensive joins after paging. Heck, many apps are even stupider and query the entire dataset from the DB, do paging in code, then throw it all away afterwards (so every time the client asks for the next page, it transfers the entire result set from the DBMS).
Dowwie 10y ago
This blog is providing a valuable service, aggregating and commenting on research. Are there others like this?
nxzero 10y ago
Unlike an interface on the net with to many choices, in a none emergency situation, I love having too many knobs.
jdub 10y ago
Havoc Pennington in 2002: http://ometer.com/preferences.html http://ometer.com/preferences.html
xchaotic 10y ago
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
- mathattack 10y ago
  Getting the 80/20 rule right on defaults is extremely important. I see this especially in well-written mobile sites, where the GUI complexity cost of configuration is higher.
- stephengillie 10y ago
  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 10y ago
    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 10y ago
      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.
OliverJones 10y ago
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.
marcosdumay 10y ago
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.
6stringmerc 10y ago
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
deleted 10y ago
[deleted]
Bartweiss 10y ago
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 10y ago
  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 10y ago
    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...
ohazi 10y ago
This is the kind of thinking that destroyed GNOME 3.
- jeremysmyth 10y ago
  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 10y ago
    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.
kps 10y ago
“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/2015/09/102737965-05-01-acc.pdf http://archive.computerhistory.org/resources/access/text/201...
ademarre 10y ago
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.
dwarman 10y ago
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.
Too 10y ago
It's funny that they call it "over-designed" when in fact over configuration is usually the result of the opposite: lack of design.

161 points by ashitlerferad 10y ago

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

collyw 10y ago
Sensible defaults.
djrobstep 10y ago
I'd rather have simple software that does what I want.
- sz4kerto 10y ago
  Then either other people don't have the software what they want (because there are so many different needs when it comes to any domain) or the complexity is transferred to finding/evaluating the huge selection of software.
- etatoby 10y ago
  LOL that's called having your cake and eating it too, AKA impossible.
- felipeerias 10y ago
  Exactly. Our tools should not add a layer of unnecessary complexity on top of already complex domains. If anything, they should take complexity away so we can focus on what is most relevant for the goals that we want to achieve. A lot of configuration options come into existence not because they are actually useful, but because the team had a disagreement that they couldn't settle, or because writing code that just figured out the right thing to do would be too complex. Options should be a way of empowering the user, not simply offloading work to them. It's very important to realise that our goals are not just related to the concrete problem at hand, but include things like "get out of the way and don't make me feel stupid".
  - TeMPOraL 10y ago
    But then a lot of options exist because the domain itself is complex and can't be captured in a one-size-fits-all solution. The only way to make something both very simple and very useful for a domain is to cunningly cut out parts of the domain. The end result is a pretty, simple and opinionated tool that doesn't really solve anything for anyone, but sure looks good on screenshots.
    - thaeli 10y ago
      This. Most "disagreements a team can't settle" are rooted in fundamentally different use cases of a complex domain.
adrianN 10y ago
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.
- pron 10y ago
  Why? And what if that one tool came with five common configurations for the five usages?
  - adrianN 10y ago
    Because simple tools are easy to understand and easy to replace when you find something better. Once you invested a lot of time into configuring your GenericTool(tm) to do what you want you're locked into its ecosystem forever. Also, simple tools that do one thing only tend to do it better than tools that do lots of things.
    - pron 10y ago
      What if that one tool came with five configurations for your five usages, that you wouldn't have to touch? You can still replace one usage with another tool, if you like. I think that the idea of many simple tools is good in theory, but seeing that most important codebases last for ten or twenty years, use of many tools increases the likelihood that you've introduced a dependency on a product that may be discontinued/unmaintained. "Easy to replace" is fine if you're very familiar with the code and all the assumptions it makes about the product's behavior, but if a tool that some module of your system that no one has touched in more than five years all of a sudden disappears[1], replacing it may be almost as big an undertaking with replacing the one big tool, but the chances of that happening are greater (because you have more such tools, and small tools are more likely to be discontinued than big ones). [1]: Say, by no longer supporting your new hardware/OS.
      - adrianN 10y ago
        Replacing just part of a big tool because there is a better alternative doesn't fly with management ("we already paid for big tool and it does what you want, why should we replace a part of it? It will just increase the complexity!"). I see small tools disappearing occasionally as a good thing. You should always be prepared to change parts of your system and a larger organization should have people that continuously work on improving the tooling. Assuming that your tooling will work indefinitely leads to ossified systems that can't be upgraded at all. Imho, tools should be treated just like code. You wouldn't write one big function that takes half a dozen parameters to change its behavior. You refactor it into multiple functions that are easier to understand and improve when requirements change.
rasz_pl 10y ago
I remember learning a saying years ago on slashdot. Difference between Windows and Linux: easy things are difficult in Linux, difficult things are possible. Easy things are trivial in Windows, complicated things are impossible. This was in XP era. Today the likes of Ubuntu/Gnome try their best to dumb down Linux.
jamesroseman 10y ago
The real takeaway here should be that engineers tend to make UX that feel good to them as engineers, and most of their clients will typically not be engineers. > I'd rather have confusing software that does what I want, than simple software that doesn't do what I want. Of course you would, or I would, or anyone who browses HackerNews would -- but it's not necessarily the best UX.
- xixi77 10y ago
  If this is a business software, once the sale is done, users are going to pick it up because they pretty much have to. But the sale can easily fail in the first place if the product does not have a feature that particular customer wants, and the competing offering does.

jdmichal 10y ago

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 10y ago
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 10y ago
  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.
- rasz_pl 10y ago
  Plus there are power users and sheep. Sheep will follow power users, power users will expect extra features. No configurability means no power users means no sheep.
afro88 10y ago
Right - just because I rarely change a parameter doesn't mean it's not important. In fact, some of the most important parameters are set once and then forgotten about.
- 10y ago

chillaxtian 10y ago

> 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 10y ago
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.
- red_admiral 10y ago
  Or a configuration file with proper documentation.
- Hondor 10y ago
  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.
jasonlotito 10y ago
> opinionated, fixed configuration is a nicer experience Even when those opinions are wrong?

simula67 10y ago

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 10y ago
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 10y ago
  Not really. The video players on Linux have tons of options that I could set, but I hardly ever do.
  - greggman 10y ago
    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 10y ago

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 10y ago
>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 10y ago
  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 10y ago
    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.

deleted 10y ago

[deleted]

etatoby 10y ago

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.

Klathmon 10y ago
The problem with something like that is maintaining and testing all the possible settings. I can't possibly fathom how firefox tests all of their settings. There's just no way. And that leads to edge cases and buggy software.
- jjnoakes 10y ago
  It isn't as big a problem as you might expect. A very low percentage of users even change the advanced settings, so any issues which might exist have a very low impact. If a user does hit a problem with some combination of settings, it is more likely they will report it with some useful reproduction information, since they are likely more of a power user than the average user. Finally, anyone changing advanced settings is more likely to understand that they may break something and are less likely to be upset, when compared to something fundamental breaking for all users.
  - jdmichal 10y ago
    In fact, Firefox even warns you upon navigating to about:config that you could very well break something.
    - Klathmon 10y ago
      And chrome warns you too, but it doesn't stop the flood of help posts in the forums, on reddit, and other places when something is broken because of a setting that someone forgot they had enabled. Just recently one of the updates for chrome broke the ability to interact with extensions if the user had enabled the flag "Material design in the browser's top chrome". There were tons of angry posts everywhere about how unusable chrome was because of that change, and how they should test their software better... As for only "advanced users" knowing what happens in there, just do a web search for "chrome://flags" and look at any one of the hundreds of blog posts, news articles, and tutorials showing you how to go in and turn on these few flags that "make chrome better".

TeMPOraL 10y ago

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 10y ago
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 10y ago
  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.

andybak 10y ago

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.

red_admiral 10y ago
And further, the UI for sorting/filtering does NOT get in the user's way. Sure, a config screen with 100 check boxes on a page is bad UI, but a table that you can sort by any column looks almost exactly like one you can't sort, just that in the former case the column headers are clickable (or little arrows appear when you hover over the heading).
dgoldstein0 10y ago
One reason for this is that if the list is lazy loaded (e.g. paginated) in any way, it can be more difficult to make sorting & filtering work on more dimensions - mainly it requires the list to be indexed in extra ways. Not impossible, but some applications weren't designed to support it from the beginning.
- Retric 10y ago
  If it's common to sort by X, you should add an index. But, if it's rare to sort by X then doing it the hard way is at worst (O) x log x which is a generally a non issue out to a few billion records. Remember, give me the next 100 of X less than Y is an O(N) operation.
  - gregmac 10y ago
    > But, if it's rare to sort by X then doing it the hard way is at worst (O) x log x which is a generally a non issue out to a few billion records. Not really true. Users aren't understanding if "sometimes the list page takes over 10 seconds to load". They don't understand (or care) that they are doing a non-indexed query or that the alternative is they don't get to do it at all. Removing a feature is often not acceptable, and so often the only resolution to a problem like this is to add an index. Of course, indexes increase the write times to your database. Indexes on every field increase the write times by a lot. Except sometimes you can't simply add an index, because you're displaying a calculated value and only calculate it for the page you're displaying. In order to sort by that value, you have to calculate for the entire system, so now you're into O(n^2) or worse complexity. You can also denormalize or pre-cache calculated values in some way (even going as far as adding something like ElasticSearch on top), but that introduces another dimension of problems (expensive updates, more potential for bugs and/or stale data). Do this for several fields, and you're now talking about quite a significant development effort, both up-front and for on-going maintenance, to support sorting that wasn't ever an actual requested feature and that only a small minority of users actually use. I know this because I have inherited exactly this problem before. Even as thousands turn to millions (let alone billions), anything worse than O(n log n) becomes painfully obvious rather quickly, and it tends to happen to the entire system at once. Suddenly you have to fix a whole bunch of "this feature is unusable slow, you broke my business" problems at the same time, while getting further and further behind your actual planned schedule. > Remember, give me the next 100 of X less than Y is an O(N) operation. ..IIF you spent the time to implement caching (and deal with the additional cache invalidation complexity problems). Many apps do paging on the database, or only do expensive joins after paging. Heck, many apps are even stupider and query the entire dataset from the DB, do paging in code, then throw it all away afterwards (so every time the client asks for the next page, it transfers the entire result set from the DBMS).

Dowwie 10y ago

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

nxzero 10y ago

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

jdub 10y ago

Havoc Pennington in 2002: http://ometer.com/preferences.html http://ometer.com/preferences.html

xchaotic 10y ago

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

mathattack 10y ago
Getting the 80/20 rule right on defaults is extremely important. I see this especially in well-written mobile sites, where the GUI complexity cost of configuration is higher.
stephengillie 10y ago
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 10y ago
  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 10y ago
    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.

OliverJones 10y ago

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.

marcosdumay 10y ago

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.

6stringmerc 10y ago

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

deleted 10y ago

[deleted]

Bartweiss 10y ago

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 10y ago
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 10y ago
  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...

ohazi 10y ago

This is the kind of thinking that destroyed GNOME 3.

jeremysmyth 10y ago
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 10y ago
  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.

kps 10y ago

“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/2015/09/102737965-05-01-acc.pdf http://archive.computerhistory.org/resources/access/text/201...

ademarre 10y ago

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.

dwarman 10y ago

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.

Too 10y ago

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