July 24, 2013

Settings Things Straight

Settings iconI listen to a lot of podcasts. Having a round-trip commute of 106 miles, with around 24 miles of that through construction, it takes me a little while to get to work and back home every day. Even with that long duration, my podcast addiction is so great that I end up playing everything on 2x, just to make sure I get through them all in a timely manner. Even then, I end up listening to the overflow on the days I go out for a run. The first step is admitting I have a problem, but I'm not the only one in need of public admittance of wrongdoing.

This evening's trek was, in part, filled with the sounds of Gina Trapani & Kevin Purdy, the hosts of In Beta on the 5by5 network. Specifically, it was the middle part of episode 58, where Gina discusses an email she received about the latest release of her Android app, Todo.txt. The email's author, an individual by the name of John, was complaining about the removal of a setting in the most recent app update. There is a lot wrong with this email, so much so that its going to take a few steps to break it down. Lets start here:

It's not just this setting I miss, it bothers me in general when options are removed.
It bothers John. In all fairness, for every John that complains, there are probably another 9 who didn't. Something changed in a way that you feel is incorrect so you spoke up. John did this in the right way as well; he didn't just lambast someone on the internet, he wrote an email hoping to encourage a reversion back to the previous behavior. He stated his case (we'll get to that in a minute) and did so respectfully.

What I want to point out here is that this is a personal opinion where John can only represent himself. He dislikes something, and that is a fair point, but disliking something is not the same as saying something is wrong. The complaint here is that John feels passionate about that setting, and there are probably others who liked it as well, yet the removal of the setting, and Gina's reasoning for doing so, is based on the facts of how most people use the app. Does the reality of usage match John's preferences? Clearly not. John's preferences are not the issue here as Gina doesn't develop an app for the sole purpose of doing what John likes. She created an app to meet the needs of her users. Those users are not best served by the presence of that setting, especially when her new method for dealing with that functionality is a more elegant and user friendly solution for almost every customer, except of course, John.

The programmer can't always know the many ways a user can use an app so the more options that are available for controlling the experience the better. (I say this as a programmer of many -- many! -- years myself.)
John, you are right, that for every app with a sufficiently large user base, it is impossible to know how every user will use that app. The flaw in this logic is that you have to know how every single user uses the app to do the right thing. Its called statistics and if you've got a reasonably large enough sample size, you can be quite confident of how your users are, in general, using your app, without needing to know the usage pattern of every user. In fact, knowing how every single user uses your app is actually counterproductive because you have to not only develop a way to collect and analyze that data, you then just spent a significant amount of time that you could have instead put into shipping a better app.

The second sentence is even better, mostly because it relies on yet another logical fallacy, that of the appeal to authority. I'm going to assume John is an excellent developer. Lets even assume he is a great consumer application developer, one with years of Android experience. Even with all that experience, it means nothing in this situation. John probably knows his apps and his users very well, but he has intimate knowledge of exactly one user of Todo.txt, namely himself.

One of the cardinal rules of software development is "the end user is not like me." John, being a great developer means nothing when it comes to being a great user. I've known many users who know more about how to use an application than the developers I knew who wrote the application. Being an expert in one thing does not make you an expert in anything else.

While I understand the idea of Simplicity... ultimately I find that Simplified OSs or apps (iOS for example) are constricting because of the options that have been taken out of my control.
Ah, so now we have the real reason John doesn't like it. No, its not his stated reason, the straw-man of 'simplicity' he brings up, but the very last word is so telling… control. John just lost some of it and it hurts. If we're going to argue about something, lets not toss mud on the competition but instead be honest about what our motives really are in complaining.

Even if John was not trying to hide his real complaint, if he had been very forthcoming about having a sense of control, in reality that's all he ever had was a mere sense of control. He could control one single thing… did he use Todo.txt or not. Its binary. Yes or No. He doesn't commit code to the project (its open source). He wasn't asked his opinion on future release decisions. He wasn't even a beta tester who could provide feedback. All he did was pay $2 for a copy, which likely he had been using for quite some time and which still works perfectly well in the new version.

It seems to me that in general programs and OSs are being simplified down to the lowest common denominator of user which doesn't allow for discovering new ways of using systems not envisioned by the originators.
Last point… 'lowest common denominator' is geek-speak for 'they are not as smart as I think I am'. Its also a lie. Yes, John's IQ is probably double-digits larger than the average person, but his ego about his abilities is far larger. This really burns me up when I see this attitude from people in technology. His argument is this… if everyone was as smart as me, we wouldn't need to make software friendly because everyone would then want to dig into the guts of it, spending their weekends tinkering around to understand how everything works.

Crap. Complete crap.

I've been that guy, so I should know. Far too many people in technology feel this way, signaling a disdain for our users, whose purchasing of our software pays our bills. It can be a subtle thing and in John's case, I'm not sure he's even aware of it. Yet it is a deadly thing because it pollutes our thinking when we set out to make great tools. We don't create software in an echo chamber for only our own pleasure (well, most of us don't, anyway). We create software because of what it enables people to do.

If removing a setting enables more people to use an app, that is a win, not a loss. No one was hurt, except for maybe John's feelings, by removing that preference. This isn't a case of ends justifying the means as we're not talking about something life and death here but showing a simple toggle in a settings screen. In the end, if this is really that big of a deal, fork the app and put the setting back in. If you really believe you're right, put the app in the store and see if you sell more copies than the original. John, this is the only way you will get back that false sense of control.