How to design to avoid configuration

It is that time again!

11:00

Topic: How to design to avoid configuration

#fishbowl-audience conversation begins here: https://discord.com/channels/239737791225790464/708458209131757598/820371782115655750 So, this topic was prompted by a message from @demetrispanos a while ago about configuration in software design. I'll let him introduce the topic in a bit (and give everyone their fishbowl role), but I just wanted to introduce the subject quickly so everyone is on the same page. (edited)

11:01

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.

11:02

And this got me thinking about configuration in software in general. The full pitch for this topic can be found here: https://github.com/AsafGartner/hmn_fishbowl/discussions/22

11:03

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?

11:03

@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

11:05

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

11:05

just to be clear, I'm not arguing that one never needs configuration

11:06

but I've found this spectrum useful in thinking about what input I'm demanding from a user

11:06

and I consider configuration a cost, because no one comes to your app because they want to configure stuff

11:06

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

11:07

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?

11:10

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

11:10

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

11:12

Something that provides a better config experience, and can serve multiple programs

1

11:12

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

11:14

Because there is no designer

11:14

Only programmer(s)

11:14

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

11:17

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

11:20

A "fear" of design

11:20

Because design means constraints

11:21

And constraints mean "not equally good for everyone"

11:22

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

11:22

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"

11:22

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

11:25

speaking personally, I find editor color schemes to be a huge waste of life

11:25

pick one and use it, then go do something useful

rob pike intensifies

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

11:27

Which is basically an unsupportable position

true, but for the sake of focus let's keep pikebashing to #fishbowl-audience

11:27

leave my dumb joke be

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

11:32

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

11:33

and it clears your mind

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

11:34

(Perhaps with lightweight options for the edges of that space.)

Well no most programmers have bottom of the barrel aesthetic sensibilities

11:35

It's a real problem

11:35

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

11:36

I meant aligned

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

11:38

And the effort would be duplicated by anyone who wants the same thing as me, leading to a much higher cost (edited)

11:39

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.

11:40

So what about stuff that is a little more critical than aesthetics?

11:40

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?

11:44

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

11:44

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.

11:45

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.

11:46

Because there's another aspect of config Demetri brought up in his intro, which is fragmentation

11:46

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.

11:47

At the extremes, the way you work may be totally different, aesthetically and functionally, from another user of the "same" software.

11:48

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.

11:50

You see it in shells too, where people have vast networks of aliases.

11:50

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

11:54

For example not detecting the system setting for light/dark theme

1

11:54

I can set my system settings on that to change based on the time of day

11:55

But 80% of programs won't follow suit

11:55

(Or more)

11:56

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?

11:57

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.

Exactly

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

12:02

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.

12:02

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"

Yeah, that sucks

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.

12:06

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.

12:06

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

12:07

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?

12:09

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

12:09

(In the interest of creating good software at least)

12:10

I mean another aspect we haven't discussed much is default configurations

12:10

So in the event that you do have moderately configurable software and it's not a disaster

12:11

You should still be shipping the best default configuration you possibly can

12:11

Such that the greatest number of users configure the fewest number of options

3

12:11

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

12:12

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"

12:13

(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

12:14

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

12:14

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

12:15

it was an act to remove it, it wasn't default

12:15

(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

DHH has a relevant essay on this, "Rails is Omakase" https://dhh.dk/2012/rails-is-omakase.html

12:17

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

12:17

Not as an option

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

12:23

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

12:19

Where the more options there are, the more some people will agonize over what the "right" options to use might be

12:19

Or worse configuration might even be "expected"

12:19

Where nobody uses the out-of-the-box settings

12:20

(And of course in the unfortunately common degenerate case the software doesn't even work without configuration)

12:20

A quick example would be Windows installers

12:21

You must provide an installation path

12:21

Because there are actual tradeoffs to where you store the program, owing to Windows not having a model for what installation looks like

12:22

Whereas you could remove 100% of installer-config for almost all programs

12:22

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

12:25

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)

12:27

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

12:29

If you want different you'd right-click and select a different install drive

12:29

Double click would still install without config

better yet you don't install it :P

12:29

it's just a file you have

12:30

(this is the macos .app model)

I mean, not really, though

12:30

App store

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.

Right

12:31

This is all good

it overlaps with the configuration discussion because it eliminates the concept of installation choices

12:31

you just have it

12:31

same as any other artifact

Right and you can put it somewhere else if you want

12:32

Or not

think of visual studio installation

I'd prefer not to

wasnt there a finder for cl

12:32

cuz they messed up locations so badly

12:32

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.

oh god

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

@Skytrias (Michael) https://gist.github.com/andrewrk/ffb272748448174e6cdb4958dae9f3d8

jonathan blow's c++ code for finding msvc

jonathan blow's c++ code for finding msvc. GitHub Gist: instantly share code, notes, and snippets.

12:33

My bad it's like 500

12:33

Still

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

12:35

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)

Yes

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

12:37

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

12:38

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

12:40

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

12:41

Or any number of future options. But per your terminology it's hardly even "config".

12:42

I mean, with this terminology, I feel like "optional config" is redundant. If it's not optional, it's not config.

12:42

Maybe it's still a crappy input channel but we can exclude it from this level of design discussion.

Very much disagree

12:43

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

12:44

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

that makes sense

also for sharing options

.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

12:50

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

12:53

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.

12:54

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)

12:58

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.

12:57

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

yeah

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)

13:01

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)

13:01

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)

13:04

no I mean something different from what brendan means

13:04

something interpolating anyway

Right, where it's just like "we're going to do xyz, is that cool?"

ah, I see

so you're 1) calling out the defaults, 2) asking for explicit permission

13:05

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

13:05

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

13:06

One prompt, for example that says "Just use all default settings y/n"

13:06

And if you select no, it has further prompts

13:07

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

13:13

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

13:14

"oh there's a DONT_LAUNCH_NUKES option, very cool I wish I had known that last week"

Talk about bad defaults

Yes, and that's an issue that I think needs to be addressed no matter what you choose to make configuration or not

13:15

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

13:16

You have a label on a radio box and the label is highly ambiguous or whatever

13:16

And you're like "what the fuck does this mean"

13:16

And there's no way to find out

13:16

Again another problem with programmer-as-designer

13:17

Or even potentially designer-as-designer

13:17

The person who is setting up the configuration interface has knowledge bias

13:17

They're already very familiar with the settings, the tradeoffs, etc

13:18

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

13:19

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

13:19

Or a better-worded label

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

13:20

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

13:21

(Hence the shitstorm of overlapping/bad terminology in the software world)

13:22

Another thing that can be useful here is demonstrating the change

13:22

So like, having a little animation that shows before/after

13:22

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

13:30

Are there any final topics to cover, or lingering questions any of you have?

13:30

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

13:32

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

true haha

I think another thing we established through this convo is also that configuration can take many forms

13:33

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

13:34

Things that nobody but programmers cares about

13:34

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

13:35

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

13:36

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

13:39

When you open a new app and it's already dark theme because your phone is dark theme for example

13:39

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

13:39

And that barrier is where a lot of people will close the app and never open it again

13:40

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

13:42

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.

13:49

As always, you can check the pinned messages to read the whole conversation from the beginning. See you at the next fishbowl!

6