Solution for allowing defaults to be changed while not angering existing users


#1

Ideally, every default option and behavior would have the exact perfect setting upon release. But that’s not reality. And it’s common to push back on suggestions to change the defaults to what are arguably better values because, “Well, it’ll make current users upset.”

I was thinking about a month ago about a program that’s been pushing back on those suggestions for decades, and how easy it would be to solve the problem.

Upon installation, write the following to wherever user settings are stored:

use-defaults-from: x.y.z

where x.y.z is the version that was installed.

The application/package then uses that version to load the appropriate config set.

Done.

Now, there is no Silver Bullet. For example, documentation likely describes the default behavior, and if a new user is reading the docs from a different version than they have installed, there will be a disconnect. Or, the user could change the use-defaults-from version number to applesauce.

But this seems like a low-impact way to improve the user experience by being able to choose better defaults without angering existing users.

Thoughts? Other solutions?


#2

There is no such thing as “arguably better values”. Everybody has a different idea what they should be. That is why every good app has an easy way to change defaults. Why do you care what the defaults are?


#3

That’s the simplistic explanation for why push back is given, yes. The more accurate and much wordier version is:

  1. The people asking for changes to the defaults almost always represent a minority of users (vocal yes, but also typically minority)
  2. The people who are happy with the defaults will probably never see the conversation to weigh in on it … creating a “silent population” (I didn’t use the term “silent majority” because we don’t know if it is a majority or not)
  3. Changing the defaults will break things that are working for existing users
  4. Simply shifting pain around is never good policy, if we make a change it should make things better overall

We have had multiple situations where one group of users was upset at a default so we changed it. This upset another group of users who then let us know about it. And the vast majority was just confused because things didn’t seem to work consistently from version to version.

Yes, the suggestion would allow us to change defaults without upsetting users. But it would still end up with the Atom team chasing our tails with a bunch of people shouting “no no no do it this way”. It simply isn’t sustainable. I would be much happier with the Atom team adding features or increasing performance than constantly responding to strongly-worded suggestions to change this or that default.

Now, if someone were to come up with a suggestion for how to actually measure the populations preferring different configuration settings, they might actually have a case. But someone’s non-data-derived opinion (or even ten or a hundred of them) shouldn’t carry much weight.


#4

Hi, Lee. Actually, this post was motivated by your comment on https://github.com/atom/whitespace/pull/94#issuecomment-171382441: “Whatever solution we come up with, the behavior shouldn’t change out from under people. If configuration options change meaning or naming … we need to build conversion utilities so that the migration is seamless.”

I wanted to throw this idea out there as a solution for changing default behavior/options without changing it from underneath existing users.

.1. The people asking for changes to the defaults almost always represent a minority of users (vocal yes, but also typically minority)
.2. The people who are happy with the defaults will probably never see the conversation to weigh in on it … creating a “silent population” (I didn’t use the term “silent majority” because we don’t know if it is a majority or not)

I’m approaching this problem as an engineer, not an end user:

We make mistakes in software development. Sometimes the wrong defaults are chosen, and we’d like to change them to better defaults to reduce the support load.

That’s what this idea is about: making life easier for package developers and the Atom devs.

.3. Changing the defaults will break things that are working for existing users
.4. Simply shifting pain around is never good policy, if we make a change it should make things better overall

This idea is to fix #3 and to make #4 easier to accomplish.

Yes, the suggestion would allow us to change defaults without upsetting users. But it would still end up with the Atom team chasing our tails with a bunch of people shouting “no no no do it this way”.

I’m sorry that you have to experience that. As the old chestnut goes, “Software development would be great if it weren’t for the install base.” :wink:

Now, if someone were to come up with a suggestion for how to actually measure the populations preferring different configuration settings, they might actually have a case.

Atom uses Google Analytics for tracking. So the Powers That Be can measure this.

If anyone has thoughts about the workability of this idea or about alternative solutions, I’m interested.


#5

Inherent to the notion is mistakes, is the notion that most user would benefit from the change, being a correction. Thus the idea of silently not upgrading default is probably broken.

I think the problem is not as much, changing default, as silently changing them.
Some kind of welcome screen that explain the change and let the user accept / decline them would probably be useful. Also using some kind of ask-me-later so user could try the new default before accepting or rejecting them.