How to design to avoid configuration
Configuration sucks. How can we avoid it, while still making software that supports a wide range of behaviors? What is the essence of "configuration", and how can we identify it? How can we identify what is "bad config", and design our software to avoid it?
This is a
fishbowl: a panel conversation held on the Handmade Network Discord where a select few participants discuss a topic in depth. We host them on a regular basis, so if you want to catch the next one,
join the Discord!
Topic: How to design to avoid configuration
So Demetri's original message was:
I am anti-configuration, and in fact consider configuration a bug not a feature. The designer should just make it good to begin with.
So some of the questions we're interested in are:
- What is "configuration"; how do we identify it?
- Why do we have it, what are the upsides and downsides?
- How do we design software in a way that avoids it as much as possible?
- If we do have configuration, why, and how can we make it not suck?
@demetrispanos has some initial thoughts, so at this point I'll let him open while I give everyone else the fishbowl role.
ok thanks ben, I will paste a short text here summarizing where I'm coming from
I tried a few other options and pasting an image from my editor seems the least-bad among bad options given the formatting on different devices
just to be clear, I'm not arguing that one never needs configuration
but I've found this spectrum useful in thinking about what input I'm demanding from a user
and I consider configuration a cost, because no one comes to your app because they want to configure stuff
it may be a worthwhile cost if adding the configuration allows the user to access a valuable set of features that otherwise wouldn't be possible, or appropriate
but ultimately it is a cost, and needs to justify its presence ... it has no value on its own
I like the terminology you're using here, I think it will be helpful throughout this conversation
One thing that I definitely think I agree on is the 'separate channel' point. Configuration files are generally not great, nobody wants to use them. What reasons would someone have as a developer to have that, instead of providing the option inside the program itself?
At the very least, one could argue that you should be able to change anything you can change inside a config file from inside the actual software while it's running (similar to how options typically work)
(edited)
Voran
One thing that I definitely think I agree on is the 'separate channel' point. Configuration files are generally not great, nobody wants to use them. What reasons would someone have as a developer to have that, instead of providing the option inside the program itself?
a common motivation for this is "headless" software like web servers
though you could imagine a web server that accepts config input over an http request
Voran
At the very least, one could argue that you should be able to change anything you can change inside a config file from inside the actual software while it's running (similar to how options typically work)
(edited)
To this point you can easily imagine (within some standardized config format) having an external configuration program
Something that provides a better config experience, and can serve multiple programs
1
But I think more importantly here, having something like config text files or over-configurability in general usually indicates a design failure
going back to "config as cost", we can combine that with the "designer should just make it good" part and ask ... why is the designer shoving this cost on me?
.bmp
But I think more importantly here, having something like config text files or over-configurability in general usually indicates a design failure
Yes, I think that regardless of your UI for configuration, there are still a lot of downsides. However, maybe better config UX can push it toward "options" in Demetri's terminology?
Many times it's a straight-up avoidance of design
Because there is no designer
Who are often both a) design-phobic and b) config-happy
.bmp
Many times it's a straight-up avoidance of design
yes absolutely true, that systems with elaborate configuration often are trying not to take any stand on what should be good practice or preferred
As opposed to the average end-user who, excepting some circumstances for power users with heavily-used software, just want the thing to work well out of the box with default configuration and only want to edit trivial things like color scheme, if anything at all
Now with perfect configurability this wouldn't be that bad since other users could distribute good configs, but more configurability doesn't just mean less-designed defaults, it generally means a less-designed and less coherent system overall
I should mention one area where "config files" are a generally desired solution, which is when you want to do reproducible automated deployments/builds
Configurability is genericity
demetrispanos
I should mention one area where "config files" are a generally desired solution, which is when you want to do reproducible automated deployments/builds
In this case I would almost not call them config files - at that point it's just an API technically
demetrispanos
I should mention one area where "config files" are a generally desired solution, which is when you want to do reproducible automated deployments/builds
Even in these situations though, you can still avoid many configuration values in the first place
.bmp
In this case I would almost not call them config files - at that point it's just an API technically
yeah I agree that at this point it is moving toward "essential input"
for example, if you want to ship an app and pin some particular library dependency, that is now essential
actually yeah that's a good point
within your terminology, that is the primary channel of input
(edited)
right, so whether it's "configuration" is context-dependent
I think that's an interesting and important distinction, because I would certainly tend to class webserver parameters as "config files"
I think that there can't be the expectation that the end-user ever has to interact with a configuration at all, for the program to work well. In which case, you have to really have something of value that's gained from the different configuration. What are the power users actually getting out of the configuration? If it's "the program works better for this use case", you should probably find a better way to make it work better for that use case out of the box
bvisness
I think that's an interesting and important distinction, because I would certainly tend to class webserver parameters as "config files"
yeah and yet we feel very differently about an nginx.conf vs a vimrc
4
Voran
I think that there can't be the expectation that the end-user ever has to interact with a configuration at all, for the program to work well. In which case, you have to really have something of value that's gained from the different configuration. What are the power users actually getting out of the configuration? If it's "the program works better for this use case", you should probably find a better way to make it work better for that use case out of the box
Yeah there is a philosophical underpinning to this
Because design means constraints
And constraints mean "not equally good for everyone"
Which means even if the design is great you'll have some fraction of 4/5 star users complaining about certain aspects of the design
The proper response very well may be "too bad"
But many companies (or individuals, or whatever) have a very hard time not giving undue significance to the squeaky wheel
What are the power users actually getting out of the configuration
I was tempted to add a category to my taxonomy, and hesitated because it was a bit of a joke, but maybe it's worth mentioning ... there's a category of configuration I'd call "nerdsniping bait"
things that actually make almost no difference and yet waste an hour of many people's time getting it juuuuust right
and the collective cost across all of society is on the scale months or years of lost productivity if the application is popular
That style of configuration I hope we can all agree is a bad thing, a failure of design. Although, I'd be curious to know if you have a concrete example in mind.
bvisness
That style of configuration I hope we can all agree is a bad thing, a failure of design. Although, I'd be curious to know if you have a concrete example in mind.
unfortunately one person's nerdsnipe is another person's important ergonomics
speaking personally, I find editor color schemes to be a huge waste of life
pick one and use it, then go do something useful
but I know people who have easily spent 10+ hours pondering and evaluating color schemes
(edited)
bvisness
rob pike intensifies
Well no Pike is even worse to where he considers color schemes literally net negative haha
Which is basically an unsupportable position
true, but for the sake of focus let's keep pikebashing to #fishbowl-audience
anyway I don't want to derail too much on the nerdsnipe aspect, I think it's worth considering but it's not really the heart of the problem
I guess to bring it back to the core of 'provide something good out of the box', I've personally felt that the appearance of your program should either be handcrafted, or inherit its appearance from other programs for the sake of consistency. People need to approach the visual aspect as a design decision, and make something that is nice for the majority of users instead of trying to make it perfect for everyone.
Yeah, and to Demetri's point I think aesthetic stuff is easily the worst cost-to-benefit ratio of anything you could let users configure
So it provides a very obvious initial example of something the author should just design. And actually I think even your "power" users might appreciate having the decision made for them too, in the end.
Well, from a mechanical perspective sure
But from a quality of life perspective spending 40 hours a week engaging with awful aesthetics is not great
Like how in the Go world, "go fmt is no one's favorite, but go fmt is everyone's favorite"
When you have no power to change trivial things, you readily accept them
1
(That said of course just providing good aesthetics out of the box with minimal tweaking required/allowed is ideal)
Yeah aesthetics do matter, but configurable aesthetics are clearly a waste of time. Enough people are broadly designed aligned on aesthetics anyway that you can just make a good decision pretty easily.
(edited)
(Perhaps with lightweight options for the edges of that space.)
Well no most programmers have bottom of the barrel aesthetic sensibilities
And part of why the most programmery software is the worst aesthetically
I'm talking about what aesthetics people like, not what people will think to create
configurable aesthetics are clearly a waste of time
I agree, but to use demitri's terminology, I do think thatoptional aesthetics have a lot of value to them
Oh well you said "broadly designed" at first and threw me off
yes I apologize for a stupid typo
If Discord were to have a team of artists come up with 5 new themes, there's a pretty good chance they could come up with something I'd like. Maybe one with rainbow highlights, maybe one that uses pastels. But if they gave me the ability to spend that time to do it myself, I would take a lot more time than the artists to make something way worse.
2
And the effort would be duplicated by anyone who wants the same thing as me, leading to a much higher cost
(edited)
So the option is definitely a valuable thing to have, but you can't make it into work for your users.
(edited)
Yep, for sure, and I think a critical part of Demetri's opening ideas is that we need to consider the cost it puts on our users.
So what about stuff that is a little more critical than aesthetics?
We can probably continue to consider configurable editors if we want to think of some concrete examples.
different countries have different keyboard layouts, and not necessarily all the keys that are well placed on an US keyboard is decent on a scandinavian keyboard
Ok, so things like keymappings are maybe a more directly beneficial piece of config. But there again there is strong value in good design up front (otherwise all your mappings are two-keystroke things like shift-F6, ctrl-U)
and there's uncommon cases of color blindness, no point in using a text editor if the user can't see the text
Ok, so those are benefits, but if we're considering costs, how much cost does it put on users? And what can affect that cost?
As with everything in programming, the benefits are obvious in isolation.
I believe that it should be possible to detect the user's keyboard layout, right? If your keybindings are more positional, if you see a need to support more keyboard layouts, you should be able to have things 'just work' instead of having the user get things working themselves
Color blindness is also something that you can design for; using patterns and high contrast instead of relying on color to differentiate things
Yes, so in both of these examples a lot of the user cost could be mitigated by good up-front design.
So design is still an important factor even when the system is configurable. And if you're already being forced to design things, at some point you have to question whether the fringe benefits offset the cost of allowing config.
Because there's another aspect of config Demetri brought up in his intro, which is fragmentation
Things that are configurable will vary between users, and will be more work for the software author to support, but will also result in less sharing of understanding between users.
At the extremes, the way you work may be totally different, aesthetically and functionally, from another user of the "same" software.
Aesthetic configuration doesn't really cause meaningful fragmentation, but functional configuration certainly can.
That's a very good point. If you're learning to use a piece of software through someone who has done an amount of configuration, you'll have to do the same configuration to follow along in a lot of cases
You see this in the extreme in Vim and friends, where the people who teach Vim forget the extent to which they have modified the system, added conveniences, changed subtle parameters years ago.
You see it in shells too, where people have vast networks of aliases.
And the result is really that the system the power users use is fundamentally different from the original system.
One question to ask might be "Is the system the power users use better?", because they might actually be making something far easier to do than it was before. For instance, while not exactly a configuration per say, I have a startup script that I've been working on recently, which has reduced the time it takes for me to open up everything that I typically have open from an hour or two to about 30 seconds.
Actually re: just detecting things instead of user configuration, one of the most common frustrations I run into as a software user is programs that don't use global configuration or interoperability when they trivially could
For example not detecting the system setting for light/dark theme
1
I can set my system settings on that to change based on the time of day
But 80% of programs won't follow suit
I don't want to configure that on a per-program basis, and it also makes my total configuration more fragile and less automatable
Voran
One question to ask might be "Is the system the power users use better?", because they might actually be making something far easier to do than it was before. For instance, while not exactly a configuration per say, I have a startup script that I've been working on recently, which has reduced the time it takes for me to open up everything that I typically have open from an hour or two to about 30 seconds.
So is the system designed by the power users better in general, or better for specific cases that wouldn't apply to a large subset of the user base? Does it depend on the situation?
If the power user extensions result in a generally better system for everyone, then I feel like that stuff should be part of the base program and not even a part of the configuration. But if it's specific, then maybe there's not as much you can do and the configuration is actually providing real benefit to a subset of users.
bvisness
If the power user extensions result in a generally better system for everyone, then I feel like that stuff should be part of the base program and not even a part of the configuration. But if it's specific, then maybe there's not as much you can do and the configuration is actually providing real benefit to a subset of users.
a good example of this is vi motions, which I think are seen as power-user features from the outside but once you train with them a bit they prove their value even to beginners ... I would consider motions to be something you expect almost all vi/vim installations to use, and only very very rarely should they be configured differently or disabled
going off on another tangent, take tmux for example, the default tmux hotkey-combination to access it is by default ctrl+b, which causes you to move your whole damn arm to hit it, and it's used alot so it's really not well thought out default setting
bvisness
If the power user extensions result in a generally better system for everyone, then I feel like that stuff should be part of the base program and not even a part of the configuration. But if it's specific, then maybe there's not as much you can do and the configuration is actually providing real benefit to a subset of users.
I suppose "better" isn't the right word here. It's not that it's better so much as that it provides a way to do things that would be difficult or time-consuming to do otherwise. Nobody will ever want my exact startup script, so a premade solution wouldn't help... except, wait, it actually would. If the operating system gave me a way to just list a bunch of programs I want to start up, with the options I need to open the right things automatically, then it would be far better than the batch file I use right now. What I'm saying is, look and see if what they're doing provides a benefit, and see if you can either create a simple, unified way to let your users do that sort of thing while shifting it closer to an option than a configuration.
Right, and so even in a system where you benefit from configurability, the design of the base system still matters and can probably even reduce the amount of work you have to do in the configuration layer.
So I want to revisit a point @.bmp said earlier:
more configurability doesn't just mean less-designed defaults, it generally means a less-designed and less coherent system overall
Configuration is at a minimum a bunch of knobs to turn, but I want to explore how the idea of configuration (and the idea that it is good) affects the design of systems overall.
What knobs do we even have?
bvisness
So I want to revisit a point @.bmp said earlier:
yeah the cliche situation for this in app ui designs is "should the focus jump to the next element after you click on the target? or should it stay where it is? ==> dunno, make it a config option"
bvisness
What knobs do we even have?
This is a question I was wondering too, because it seems like most configurations could just be implemented as options.
So my concern is that when you design software assuming that users will be able to configure it, you will actually fail to solve the problems that your software should actually solve.
I think that to a very large extent, the purpose of creating software is to make decisions about how things should be done, so that others can benefit from your thinking about the problem.
And if you write software assuming "users will be able to configure this", will you ever be able to make your software do anything meaningful?
Right configuration is often deferral
On the part of the would-be designers
I mean, really, it's always deferral
The question is, when is deferral a good idea
If you're making the user essentially design their own software out of configurable building blocks you've fucked up
bvisness
So my concern is that when you design software assuming that users will be able to configure it, you will actually fail to solve the problems that your software should actually solve.
yes and this compounds nonlinearly, maybe exponentially
it's one thing to say "user, please choose these 3 things, each from a small set of options"
it's another to have 50 options of unclear interaction
But, sometimes it's useful to give some users that power, especially if they can distribute that extra software to others, right? So how do you navigate those decisions?
I don't think it's impossible to design good "building block" software, but my concern is about assuming building blocks too early.
In the overall space of software design it's very rare that you want to defer that power
(In the interest of creating good software at least)
I mean another aspect we haven't discussed much is default configurations
So in the event that you do have moderately configurable software and it's not a disaster
You should still be shipping the best default configuration you possibly can
Such that the greatest number of users configure the fewest number of options
3
(The default is good enough that most users use most of the default settings forever)
Well and importantly, your default config needs to convey some idea of how the software is intended to be used.
Which to me implies that you actually designed a system in a way that is useful, and maybe later found what could be an option.
This is kind of where the nerdsniping aspect comes in because a lot of programmers have a bad model of their audience, I wouldn't be that surprised to hear some arguments back about how configuration is actually enjoyable
And that's something only a programmer would think
(edited)
I think that generally, you want to figure out what your users want to do, that they can't at the moment, but which you can't explicitly support for all users. E.G. I want to start up a bunch of programs when opening up, and enough other people want to start up programs too. The thing you can't decide is which programs to start up(that has to be a configuration if you want to provide this feature), but you CAN provide an interface to start things up.
.bmp
Such that the greatest number of users configure the fewest number of options
a related, but I think slightly different, situation is what Rails calls "convention over configuration", i.e. there isn't even a "default" they just eliminate the choice entirely by saying "your html must be stored in a folder called html"
(I don't know if that specific choice is in rails, but it's the kind of choice they're talking about)
from the rails' designer perspective, nothing is gained and something is lost by allowing you to put your html in a folder called my_awesome_stuff
oh man, that is a whole angle that could maybe be a fishbowl on its own
but definitely related here
Well that's just removing configurability
wanting to do that is pathological
I'm talking about the case where you do have configurability as a base assumption
Obviously overall the less configurability that you have or need is better
well my point is that most frameworks do have that configurability, and rails actively removed it
it was an act to remove it, it wasn't default
(again I emphasize I don't know if that specific thing is in rails, I'm just giving a hypothetical)
actually, as a result of this conversation, I'm now thinking my issues with Rails are for issues that aren't really related to "convention over configuration"
and more just to a design I don't like
I think as a software designer any time you are tempted to add configurability you should give it a trial by fire
The burden of proof is on the necessity for configurability
my paraphrase/summary: "You've come to me to give you a framework to make web applications. I'm telling you, there is no good reason not to put these files in a folder called html. So I'm just not even giving you the option."
(edited)
.bmp
The burden of proof is on the necessity for configurability
This is why I think that you should be seeing what existing users are trying to do that they can't, rather than designing things up front to try and support what they might want to do
1
Well and better yet just provide the ability to do that thing out of the box
.bmp
Well and better yet just provide the ability to do that thing out of the box
In the context of something that might require configuration, it might not be the best idea to always provide it out of the box, actually. Something like the theoretical startup interface for choosing which programs to start requires configuration (each user wants to start different programs, probably), and it could work out of the box, but if I'm the only user who ever uses it then it was probably a waste of time for them to design it.
Ideally you'd want to have some kind of assurance during development that testers tend to actually want to do that thing
demetrispanos
my paraphrase/summary: "You've come to me to give you a framework to make web applications. I'm telling you, there is no good reason not to put these files in a folder called html. So I'm just not even giving you the option."
(edited)
There is a tyranny of choice aspect related to the nerdsniping
Where the more options there are, the more some people will agonize over what the "right" options to use might be
Or worse configuration might even be "expected"
Where nobody uses the out-of-the-box settings
(And of course in the unfortunately common degenerate case the software doesn't even work without configuration)
A quick example would be Windows installers
You must provide an installation path
Because there are actual tradeoffs to where you store the program, owing to Windows not having a model for what installation looks like
Whereas you could remove 100% of installer-config for almost all programs
Toward an app-store like installation process - click install, progress bar, done
And, it's worth noting, for a lot of people I know with average/below average technical literacy installers are a huge point of confusion and frustration
1
a subject for another day, but installation is generally a terrible concept and should be avoided as much as possible
it overlaps with configuration a bit
Ironically it's the power user who understands that you should usually just click next a bunch of times and only pause to disable diagnostics, tracking, mailing lists, etc
For the average user they feel like they might be screwing up something important
Why would they be presented with the option if it didn't matter?
Installation location does matter a whole lot more when you have more than one disk drive, and have to manage space. I personally have to choose a new install location for most new programs, because the default is on my SSD, which doesn't have a lot more storage space (and I'd like that storage space to be reserved for a few things that I want to run fast)
However nobody presents that in a clean way like it could be. The end user could just see a list of drives/partitions/whatever and how much space they have, then choose one and be done, if the operating system was designed that way
Voran
Installation location does matter a whole lot more when you have more than one disk drive, and have to manage space. I personally have to choose a new install location for most new programs, because the default is on my SSD, which doesn't have a lot more storage space (and I'd like that storage space to be reserved for a few things that I want to run fast)
this wouldnt matter if most program installations are tiny like remedybg, single exe
Skytrias (Michael)
this wouldnt matter if most program installations are tiny like remedybg, single exe
I don't expect most of my games to be that tiny, to be honest. Games are big, especially ones with lots of art assets.
Better yet default install would go to a globally configured drive
If you want different you'd right-click and select a different install drive
Double click would still install without config
better yet you don't install it :P
it's just a file you have
(this is the macos .app model)
I mean, not really, though
I mean, for some value of "install" but there is an expected application directory, etc
If you just mean the lack of registry configuration then yes burn it with fire
let me clarify that .app is not related to the app store
.app is a bundle format for all of the files that are required to run an application
to the user it appears as a single file, just like an image or a word doc etc.
you can drag it anywhere in your filesystem etc.
it overlaps with the configuration discussion because it eliminates the concept of installation choices
same as any other artifact
Right and you can put it somewhere else if you want
think of visual studio installation
wasnt there a finder for cl
cuz they messed up locations so badly
across different versions
Jon Blow wrote like a 1000loc C++ program for finding the installation directories
(edited)
I think I agree with demitri, if you just download a file and it's just a file you can execute and run, that is way better for the user than an installation.
Voran
I think I agree with demitri, if you just download a file and it's just a file you can execute and run, that is way better for the user than an installation.
further examples of eliminating configuration through smarter design, yeah
jonathan blow's c++ code for finding msvc. GitHub Gist: instantly share code, notes, and snippets.
Voran
I think I agree with demitri, if you just download a file and it's just a file you can execute and run, that is way better for the user than an installation.
Well part of the thing here is that it is still actually a directory with multiple files but it's presented to the user as the least-complex possible thing
Because almost no user cares about anything that's inside the folder
.bmp
Because almost no user cares about anything that's inside the folder
Right, you can go into it and access, say, saved games, which is very useful. But the fact that it's bundled together with the executable means everything just works wherever you put it, and you don't need any up front configuration
.bmp
Because almost no user cares about anything that's inside the folder
indeed the default desktop operations don't even let you treat it like a folder
so the topic we seem to keep coming around to is that design is really critical: it helps you avoid configuration entirely, ensure that what configuration you have is useful, and ensure that your default configuration is a good user experience
(edited)
so one concrete piece of advice I'd like to propose, then, is to design your software without configuration first, and to then introduce configuration (or options) at a later date
(edited)
sound reasonable? caveats?
Any technical cost to adding configuration later pales in comparison to the costs of adding design later
bvisness
so one concrete piece of advice I'd like to propose, then, is to design your software without configuration first, and to then introduce configuration (or options) at a later date
(edited)
thats interesting, i already have optional features for my program, should i not have them and force them, only implement them once users rage / want them?
(edited)
Yeah. Introduce configuration as it's needed, rather than to give people more options up front
(edited)
Do keep in mind that there's a distinction between configurations and options (see demitri's post at the beginning)
Skytrias (Michael)
thats interesting, i already have optional features for my program, should i not have them and force them, only implement them once users rage / want them?
(edited)
I think it's highly likely that those choices might be irrelevant to your users, and that by failing to make that decision yourself you have locked yourself out of interesting further designs
a lot of useful features will need to be based on assumptions about how other parts of the system work
bvisness
so one concrete piece of advice I'd like to propose, then, is to design your software without configuration first, and to then introduce configuration (or options) at a later date
(edited)
I think this is a good aspirational goal, I wonder if there are practical limitations. For example, if I make a web server I guess I can default to port 80, no TLS cert, etc., and then maybe the next level is I have server_config folder in which I look for a cert file etc.
though web servers could plausibly accept all that stuff as command-line arguments
as they are important operational inputs
Web servers continue to be a confounding case for this terminology
Input method aside, as you said earlier, they are important inputs somehow. But, there's a spectrum of essential to optional, and a lot of webserver stuff is more and more optional.
Like you definitely need to bind to an address and a port, and you can choose whatever input method will best serve your users
Ok, but choosing what address and port something will live on is a decision a user will have to make.
(edited)
Well the web is built on ridiculous layers of complexity and with configuration-first as a baselines assumption
It's basically the worst imaginable degenerate case of everything we're talking about here
So it's not like you're operating from a clean slate
You have to interface with a bunch of configurability imposed on you by the environment
bvisness
Like you definitely need to bind to an address and a port, and you can choose whatever input method will best serve your users
yeah, and that stuff can be pushed toward "options" part of the spectrum with just a little bit of design
demetrispanos
yeah, and that stuff can be pushed toward "options" part of the spectrum with just a little bit of design
Right, there are any number of ways you could do this (config file, GUI, web dashboard served on a random private port, command-line flags, environment variables, etc. etc.)
Or any number of future options. But per your terminology it's hardly even "config".
I mean, with this terminology, I feel like "optional config" is redundant. If it's not optional, it's not config.
Maybe it's still a crappy input channel but we can exclude it from this level of design discussion.
One category of configuration that I particularly despise is first-launch configuration
1
Where to even start using an application you're first forced to make a bunch of decisions related to the config
Where, for one, you don't even know what the tradeoffs are yet because you haven't used it
one thing i wanted to ask, should you force users to use configuration via ui, or should configuration via text always be possible?
Skytrias (Michael)
one thing i wanted to ask, should you force users to use configuration via ui, or should configuration via text always be possible?
anywhere you want reproducibility/automation I think a text artifact is a desirable option
.bmp
Where, for one, you don't even know what the tradeoffs are yet because you haven't used it
I agree, you should never be unable to run the program without configuration at all. Ideally, the few choices that you have to make (language, location on file system) should be inherited from/chosen by something like the operating system, which should have the only necessary things to configure already figured out.
Voran
I agree, you should never be unable to run the program without configuration at all. Ideally, the few choices that you have to make (language, location on file system) should be inherited from/chosen by something like the operating system, which should have the only necessary things to configure already figured out.
I'm not sure how feasible this is, but in most cases the configuration can be limited to a very limited set of things, that you already made the decision about on the overarching system
(edited)
It's totally reasonable I think to be required to provide data on launch as long as there is context for it, and regardless of whether you consider it "config" I think it's less interesting for the purposes of this discussion
If a program needs user data to run, it needs to get it at some point, and maybe the best time to ask for it is on first launch, or maybe it isn't. But I think a lot of the type of configuration we're talking about here is optional data provided beyond the minimum required.
yeah, so one principle is "is it possible to set a default that works most of the time, and is not harmful in the cases where it's wrong?"
I'm curious about what kinds of user data would be needed to run, because it seems like to me, most things that you'd need (keyboard layout, language) can or should be able to be detected rather than asked for.
Voran
I'm curious about what kinds of user data would be needed to run, because it seems like to me, most things that you'd need (keyboard layout, language) can or should be able to be detected rather than asked for.
Depends on the app, e.g. a rideshare app may need location permissions, user profile data for drivers, and payment info
maybe some of that can be deferred, maybe not
2
demetrispanos
yeah, so one principle is "is it possible to set a default that works most of the time, and is not harmful in the cases where it's wrong?"
I like this question, and I think it can be fairly applied to practically any "config decision" a programmer might make.
And I would guess that by thinking through that decision, you will discover some important stuff about your software and the problem you're solving.
similarly, "Hypothetically, if it were impossible to collect this information, what would I do?" (this gives a path to eliminating the input entirely)
(edited)
so for example "Hypothetically, my user refuses to tell me what folder will contain the html files. OK fine user, then I will insist that all html must come from the folder /html"
(edited)
and then you discover that this was a better design than asking the user to begin with
To revisit some previous points, aesthetic editor decisions clearly can have a good default, keymappings could have useful defaults, even program installation locations could have reasonable defaults depending on the underlying system. But perhaps for something like a webserver, some form of address is both difficult (or impossible) to choose a value for, and harmful if it's wrong.
oh I really like that as well, keep 'em coming
and you can then ask the initial question of "is it harmful in any way to choose this on behalf of the user?"
To extend that example, you may then at some point find that for some users it is a legitimate pain point to have everything in the /html folder, and at that point perhaps you could introduce an option. But it still isn't harmful to choose /html on the user's behalf, initially.
going on your webserver example, maybe it's useful to specifically call out inputs where you expect the potential for adversarial action (e.g. web server addresses/ports)
so if you knew no one was trying to exploit you, you could just go ahead and take port 80 (or some similar network resource)
but maybe you have to account for the fact that adversaries might be looking for default-configured software
yeah, and actually, I think that because it's potentially harmful you have a good reason to ask the user, and a good opportunity then to help the user make an informed decision
right so let me throw in an additional tool similar to defaults but not quite defaults, which is runtime/first-time interrogation
the thing @.bmp hates
(edited)
./run_server
... can't find previous run-log, assuming first-run
... will use port 80, ok? [y/n]
y
... will use localhost, ok? [y/n]
y
(edited)
no I mean something different from what brendan means
something interpolating anyway
Right, where it's just like "we're going to do xyz, is that cool?"
so you're 1) calling out the defaults, 2) asking for explicit permission
and if the user says no you then give a helpful message ... will use port 80, ok? [y/n]
n
... ok, please set SERVER_PORT in server.conf
... aborting
(edited)
yeah, and this still allows a design intent to be communicated
this doesn't excuse you from design in any way
something it would need afterwards would be you can configure this afterwards in file.xy
(edited)
I would still much prefer just not asking
And if you want something else, you do something else
sure, but we're talking about the situations where you have to ask
.bmp
And if you want something else, you do something else
this has to be traded against security risks
If it can't be changed after first-time setup, just have two first-time setup paths
One prompt, for example that says "Just use all default settings y/n"
And if you select no, it has further prompts
If you select yes, you're done
that's possibly fine but the user might not know that "all default settings" includes things with security impacts
(edited)
if i store an ip in a config file, i should probably try to encrypt / hide it?
(edited)
demetrispanos
that's possibly fine but the user might not know that "all default settings" includes things with security impacts
(edited)
Then they shouldn't be setting up something with security implications
.bmp
Then they shouldn't be setting up something with security implications
ok but they might not know that :P
Whether they should or shouldn't, people probably will. This is the web
certainly when I started out I didn't know that people were scanning ips for default-configured servers to exploit
I mean in your example someone who doesn't know there are security implications to setting up a web server isn't going to know which port to use for security reasons
But this is an opportunity to communicate this to them, instead of just saying "well, screw it, you don't know better"
1
Right so just say "note: first-time settings have security implications, please only use default configuration if you are certain you are comfortable with that" or whatever
yeah, this raises a separate topic about configuration which is that it is often plagued by documentation/communication problems
Anyway again we're talking about poweruser stuff
Which is not the general design case
I can't count the times I discovered some config option from reading someone else's code, that wasn't documented in the official docs
"oh there's a DONT_LAUNCH_NUKES option, very cool I wish I had known that last week"
Yes, and that's an issue that I think needs to be addressed no matter what you choose to make configuration or not
it's actually a good case too for something more toward "options"
(edited)
Yeah it's a problem even in consumer-tier software where options are just not explained
You have a label on a radio box and the label is highly ambiguous or whatever
And you're like "what the fuck does this mean"
And there's no way to find out
Again another problem with programmer-as-designer
Or even potentially designer-as-designer
The person who is setting up the configuration interface has knowledge bias
They're already very familiar with the settings, the tradeoffs, etc
If they're not a good communicator, don't have a good model of their audience, don't have a good model of how their own knowledge interacts with the interface, they won't communicate the options properly
Eventually I think it does all come back to thinking about your users and trying to reduce costs for them
and I think we've clearly established from this conversation that the benefits of configuration are overestimated and the costs hardly estimated at all
and by asking some critical questions about your design, you can design significantly better software for your users
.bmp
And you're like "what the fuck does this mean"
how would you avoid this though, i know some programs display videos what the change would do
Even just a one-sentence blurb would often do the trick
yea i have that already, still sometimes feels abstract
re: reducing costs — paraphrasing something jon blow has said several times, if you have 1000 users and you waste 5 minutes of time for each of them that's 5000 minutes or two full work weeks
(edited)
Part of the problem can also be the programmer/designer not having a very solid concept of what the option does themselves
They understand what it does intuitively but it's just outside their ability to solidify the concept into clear and concise terminology
.bmp
Part of the problem can also be the programmer/designer not having a very solid concept of what the option does themselves
yes, which is a good reason to design it without config first
Often because the things that software does are abstract or difficult to find words for
(Hence the shitstorm of overlapping/bad terminology in the software world)
Another thing that can be useful here is demonstrating the change
So like, having a little animation that shows before/after
If the setting is visually communicable
Not all settings have to be visual, I don't think.
Hence the word "if"
(edited)
I've seen this done particularly in smartphone apps and it usually works out pretty well
would be doable for some options sure
but yea i think options are bad for programmers too, another source for bugs to occur, especially if you dont use a specific option and it might bug out unknowingly
I'd like to make the point again that options themselves aren't bad. The issues that Demitri mentioned that make them more of configurations than options make them harder to work with though, such as if they're not changed often or the changes are hard to detect in the output
Since we're now about 2.5 hours in, and I'm thinking it's nearly time to wrap this up, I wanted to just quickly highlight some of the stuff we covered in this conversation:
- We established some vocabulary for talking about configuration
- We highlighted the benefits and costs of config, for several different aspects of config
- We found that design is critically important even for configurable systems, and found that having configuration as a goal can hamper your design
- We found some concrete advice and questions you can ask to help drive yourself toward smarter design and less config
Are there any final topics to cover, or lingering questions any of you have?
This conversation can always continue outside this fishbowl as well. I'm sure we'll all be dealing with these design questions all the time going forward.
that all sounds good to me, I'll just wrap up my portion by reiterating viewing configuration as a cost that should pay itself back ... or to put it in a more positive light, as an attempt at an investment
so when you do it, you should have an idea of what it is you are buying for your users and for yourself
maybe also when you store options in a file, it should be a readable format
that seems like an awfully granular and specific takeaway
I think another thing we established through this convo is also that configuration can take many forms
and those forms can continue to impact the cost your users are asked to bear
I think a pervasive problem in this discussion has been returning to things like config files and text editors etc
Things that nobody but programmers cares about
If you have a config file (that you expect users to interact with) for consumer software you have failed
(edited)
2
over configuration can also be a pain - every website forcing you to fill out cookie permissions
i really hate using the web nowadays
I really, really, really do not want anyone to come away from this discussion thinking this somehow only applies to programmer tools. This applies to everything.
Programmer tools are familiar to us all, and frequently terrible examples of design. But they are the tip of the iceberg here.
Even if your users are programmers and like configuration, you would do them all a favor by directing their attention to what matters.
It applies especially to everything
Programmers are the only audience in which some members are okay with or even like configuration
Because what is programming except configuring hardware and libraries to do what you want
So if your model of what a user wants is based on programmer things, you're sorely falling short of the mark and vastly underestimating how much the ordinary user despises, and is frustrated/intimidated by any and all configuration beyond "turn notifications on/off" "light theme/dark theme" etc
Making actual design decisions instead of saying "I don't know, make it a config option" can be very valuable. You'll understand what the tradeoffs are once you have an actual use case for the other config option, and you can decide if the benefits are worth the cost you pay.
On that note there was one other point I wanted to get in related to forcing first-time configuration, which is just how smooth and well-designed the experience feels when a new application drops you right in with no config or introduction and makes good default assumptions and good use of system-wide settings
When you open a new app and it's already dark theme because your phone is dark theme for example
The lack of a hard barrier between "I don't have this app" and "I'm a comfortable user of this app" is hard to overstate in terms of getting users to like your software
And that barrier is where a lot of people will close the app and never open it again
(Or just never have it set up the way they want, despite there being settings for it, and always having a low-grade frustration with the experience)
Voran
Making actual design decisions instead of saying "I don't know, make it a config option" can be very valuable. You'll understand what the tradeoffs are once you have an actual use case for the other config option, and you can decide if the benefits are worth the cost you pay.
Yes along these lines it's worth noting that nobody understands the tradeoffs better than the designer (or at least, if that's not the case, you have a problem)
There may come a time when your advanced users have a better model of some parts of the problem space than you do, but it's important to remember that they are not the common use case and therefore their experiences/opinions are not necessarily reflective of average users
i'm gonna call it a day personally, been getting sleepy faster than i thought
yep, I think we have nicely reached the end here
I'd like to thank @demetrispanos for this fishbowl idea
yea was interesting, definitely helped me out a lot
Yes, absolutely. I'm very glad to have done a fishbowl prompted organically by the conversations we were having around here!
(edited)
I'm glad other people share some of my sentiments on this subject!
Thanks all for participating! I found this super enlightening and interesting, and I hope you all did as well.
As always, you can check the pinned messages to read the whole conversation from the beginning. See you at the next fishbowl!
6