Kill the settings, build opinionated software(flyosity.com)
flyosity.com
Kill the settings, build opinionated software
http://flyosity.com/iphone/kill-the-settings-build-opinionated-software.php
51 comments
This is the problem -- the argument about 'settings' has become about whether there should be a preference pane, whether there should be an "advanced preferences" pane, etc.
Settings aren't the problem. Preference panes are the problem. If you back the ability to customize something (aka toggle a setting) into the thing that needs customizing, then preference panes disappear, and the interface becomes inherently customizable.
Consider the window. Imagine if the x/y/w/h of every window was hidden in a preference pane! No one would use windows, because thats a terrible interface. The solution is to bake the customizability into the interface -- allow users to drag windows around, or resize them by dragging the edges (or corners if you're on a mac, etc.).
The next time you think about adding something to a preference pane, either find a way to bake it into the UI or forget it.
Settings aren't the problem. Preference panes are the problem. If you back the ability to customize something (aka toggle a setting) into the thing that needs customizing, then preference panes disappear, and the interface becomes inherently customizable.
Consider the window. Imagine if the x/y/w/h of every window was hidden in a preference pane! No one would use windows, because thats a terrible interface. The solution is to bake the customizability into the interface -- allow users to drag windows around, or resize them by dragging the edges (or corners if you're on a mac, etc.).
The next time you think about adding something to a preference pane, either find a way to bake it into the UI or forget it.
So for your mail client you bake all those little mailbox settings into the UI somehow, even though it's mostly a "set and forget" kind of thing?
Yeah, you do.
I want to enable secure outgoing email. Which is better:
"Click the Accounts menu, then Mailboxes, click the mail account you want, click the Outgoing tab, scroll to SMTP Advanced Settings, and Enable TLS/SSL"
or
"Click the i icon next to the mailbox name, or right-click and select Settings. Scroll down to Outgoing Mail, and check the SSL/TLS option."
The first option is vestigial, from an age where pull-down menus and dialogs were marked improvements over text-based config files nobody but us understood. The second option directly links the item with the controlling settings for that item, but will hopefully also one day be vestigial when we figure out something better.
I want to enable secure outgoing email. Which is better:
"Click the Accounts menu, then Mailboxes, click the mail account you want, click the Outgoing tab, scroll to SMTP Advanced Settings, and Enable TLS/SSL"
or
"Click the i icon next to the mailbox name, or right-click and select Settings. Scroll down to Outgoing Mail, and check the SSL/TLS option."
The first option is vestigial, from an age where pull-down menus and dialogs were marked improvements over text-based config files nobody but us understood. The second option directly links the item with the controlling settings for that item, but will hopefully also one day be vestigial when we figure out something better.
Ok, fair point. The thing that changes what the little picture does should be closer to the picture. I can agree with that.
Every piece of code or bit of functionality you write has a cost of ownership to your business.
Every preference requires more testing to make sure that other things don't break as a result of a user changing an obscure setting.
If you don't mind having to write test cases for thousands of permutations of possible settings, go ahead and let your customer change everything. A simple product, however, is far easier to maintain.
Every preference requires more testing to make sure that other things don't break as a result of a user changing an obscure setting.
If you don't mind having to write test cases for thousands of permutations of possible settings, go ahead and let your customer change everything. A simple product, however, is far easier to maintain.
To take a concrete example, we don't exactly enjoy maintaining justin.tv in many different languages. As a matter of fact the whole translations system adds a lot of complexity to the codebase. But we'd be bloody idiots to have the website exist only in English. Many other settings are similarly important.
If you don't mind having to write test cases for thousands
of permutations of possible settings, go ahead and let
your customer change everything. A simple product,
however, is far easier to maintain.
And you're right about the cost, so you have to weigh that cost against the potential lost sales from not providing a given option. And you never know for 100% sure, especially since people who don't buy your product don't typically call you up and say "Hey, I didn't buy your stuff and here's why." "Silent evidence" as it were. So it's still a bit of a judgment call. I just come down on the side of being a bit more accepting of options and configurable items, than what I think the parent article is advocating.
Obviously, the simpler the product is, the easier it is to maintain. But as the product gets simpler and simpler, it becomes valuable to an ever-smaller pool of users, all of whom have differing needs. Obviously it's not as simple as "just build it simple." There's a delicate equilibrium that must be maintained.
While they're often linked, it's important to remember the distinction between "Simple Codebase" and "Simple to Use". The latter is much more important in most cases than the first, and sometimes it can take very complex code to make something as simple as possible for the user.
The simpler something to use, the bigger the pool. The fewer the applicable use cases, the smaller the pool.
The simpler something to use, the bigger the pool. The fewer the applicable use cases, the smaller the pool.
You do mind but if the customer insists you have no choice.
My customers use metres, feet and statute feet, they work in degrees, deg/min/sec and grads. They work in X,Y,Z or N,E,Z (don't get me started on South Africa)
Then you have day/month/year and month/day/year, then you have Canadians that work in both.
It's easy for a web 2.0 site with no actual customers.
My customers use metres, feet and statute feet, they work in degrees, deg/min/sec and grads. They work in X,Y,Z or N,E,Z (don't get me started on South Africa)
Then you have day/month/year and month/day/year, then you have Canadians that work in both.
It's easy for a web 2.0 site with no actual customers.
What is N,Y,Z and how does it relate to SA?
A Google search for "n e z coordinates" revealed that N stands for north or northings, E stands for east or eastings. Basically, it looks like they just swap X and Y.
I'm South African and I've never seen that used. Perhaps it is by people in a particular industry?
South Africa has a novel coordinate system, at least for people who expect North to be at the top and east on the X axis.
Yes just a simple swap, except every dialog, grid control, status bar and tooltip has to keep track of which way round they are.
I didn't mean to say it would be easy to support in any given software package :)
Users work in an infinite number of different ways, and they way they worked before they use your app is probably forced by whatever crap they are currently using.
No matter what you do, you end up forcing a lot of people to learn to work the way the app wants them to. The best you can hope for is to build an app where, once it's explained, most users first go "Oh, ok, that makes sense." and then actually remember it later. If you're really good, the users will even say, "Wow! That's much better than the app I used before."
No matter what you do, you end up forcing a lot of people to learn to work the way the app wants them to. The best you can hope for is to build an app where, once it's explained, most users first go "Oh, ok, that makes sense." and then actually remember it later. If you're really good, the users will even say, "Wow! That's much better than the app I used before."
This assumes a one-to-one relationship between pieces of software and workflows, which is absolutely incorrect. Just because you design a piece of software to be used in a certain workflow does not mean that that workflow will work for everyone; software which allows users to configure it to fit their individualized problems and processes is infinitely more valuable than software that tells the user "it's my way or the highway."
Then I have an infinitely valuable compiler and empty file to sell you.
Arguably, if you work a different way than the majority of users of a product, you'd be better served by a different product.
Usually, a product which doesn't exist.
Ok, sure, you have to draw a line somewhere. Point conceded. But the position taken by the parent article seems to be pretty close to "don't make a damn thing configurable" and that is a position I think is flat wrong - for many classes of software.
Then again, my interest is more in complex, multi-user, enterprise systems, where you are likely to have more varying forces at work (integration with other systems, needs of different classes of users, etc.) than something like, say, a TODO app for ones iPhone.
Then again, my interest is more in complex, multi-user, enterprise systems, where you are likely to have more varying forces at work (integration with other systems, needs of different classes of users, etc.) than something like, say, a TODO app for ones iPhone.
I have yet to see a highly complex piece of enterprise software that people actually liked to use. Honestly, I think the current state of enterprise throw everything and the kitchen sink at the problem software just demonstrates the downsides of a complex and highly configurable system. If you don’t know what people will be using it for then you can’t build a streamlined system.
I have yet to see a highly complex piece of enterprise
software that people actually liked to use. Honestly, I
think the current state of enterprise throw everything
and the kitchen sink at the problem software just
demonstrates the downsides of a complex and highly
configurable system. If you don’t know what people will
be using it for then you can’t build a streamlined system.
As they say, "All generalizations are false". Anyone can come up with anecdotes supporting either side of this argument, and as usual they are all right. Some options are the results of indecisive developers, who would be doing the user a favor if they did away with some options, but others add value.
You touch on one of the unstated assumptions here: some applications have more homogeneous user pools than others. The more diverse a user pool an application needs to support, the more flexible it needs to be to satisfy those users. Some users need feature X; others never use feature X and find it distracting, and would like to use the screen space for something else. Are they wrong? Maybe, probably not, but it depends on the specifics of the case and not on platitudes about having vision.
You touch on one of the unstated assumptions here: some applications have more homogeneous user pools than others. The more diverse a user pool an application needs to support, the more flexible it needs to be to satisfy those users. Some users need feature X; others never use feature X and find it distracting, and would like to use the screen space for something else. Are they wrong? Maybe, probably not, but it depends on the specifics of the case and not on platitudes about having vision.
Such a valid and too often overlooked point. Simplicity and ease of use are great, but you've got to have sufficient complexity to get the early adopters (power users, all) excited and talking about your app. This is especially true in the freelance or smallscale development world, and for most developers looking to "break in" to a market. The trick is in concealing functional complexity behind (sometimes literally) a simple UI. For example, the tried-and-true route of burying complexity along the Z axis, so that power users plunge "into" the app to deal with settings (via dialogs or panels or other UI canvas), whereas the normal users swim in the shallower waters towards the top (or the "main screen"). And etc.
> Poor UI design (3 different places to set prefs?) is orthogonal to the issue of whether or not something should be configurable.
That's not how you use the word. Even if it were, I would still dispute your argument, because configuration clearly must happen through a user interface of some sort.
That's not how you use the word. Even if it were, I would still dispute your argument, because configuration clearly must happen through a user interface of some sort.
This is a perfectly valid use of the word. In a purely technical sense, orthogonal means "intersecting or lying at right angles". But it can also mean "mutually independent, non-redundant, non-overlapping, or irrelevant" in the context of everyday conversation.
And you're missing the point. Obviously configuration must happen through a UI, but OP is saying that more preferences don't necessitate poor UI design, and I absolutely agree.
And you're missing the point. Obviously configuration must happen through a UI, but OP is saying that more preferences don't necessitate poor UI design, and I absolutely agree.
but OP is saying that more preferences don't necessitate
poor UI design
And also that you could have the "right" number of preferences (if such a thing exists) and still have a crappy UI.
IOW, UI quality and number of preferences vary independently.
Someone please communicate this to the Gnome designers.
I am well aware of the meaning of the word, but it's nonsense if you use it to describe a practice on one side, and a condition on the other.
Further, "doesn't necessarily imply" is quite another thing from "is completely unrelated to." To say that available user options and user interface design are perpendicular to one another is silly.
Further, "doesn't necessarily imply" is quite another thing from "is completely unrelated to." To say that available user options and user interface design are perpendicular to one another is silly.
Here's a little anecdote: Years and years ago, in a moment of free time, I added a bunch of silly settings to my software (EasyBCD, now with 7-10MM+ users). It had almost no users then, and I just added these options to "fill up" the empty preferences dialog. A year or two later, I removed a couple, and the complaints could be heard around the world.
The features, you ask? They really are ridiculous: Save the window size on exit. Set the default size of the UI text. Set the default font of the UI text. Open in "advanced mode" by default. Open to a particular page.
None of these features really saves a user more than a click. Some of them are purely aesthetic. But their popularity - which I greatly underestimated - was incredible. Till now, people file bugs when their favorite "silly preference" ends up resulting in odd behavior. And they always catch on immediately when I change something there.
Sure, it's hard work (read: boring, time-consuming, donkey work) to maintain these options. But I think they're part of the reason EasyBCD has succeeded.
(Note: EasyBCD is a software most people install once and never use again. It's definitely not something you would use on a daily basis. But people LOVE power and control, even if it's just an illusion.)
The features, you ask? They really are ridiculous: Save the window size on exit. Set the default size of the UI text. Set the default font of the UI text. Open in "advanced mode" by default. Open to a particular page.
None of these features really saves a user more than a click. Some of them are purely aesthetic. But their popularity - which I greatly underestimated - was incredible. Till now, people file bugs when their favorite "silly preference" ends up resulting in odd behavior. And they always catch on immediately when I change something there.
Sure, it's hard work (read: boring, time-consuming, donkey work) to maintain these options. But I think they're part of the reason EasyBCD has succeeded.
(Note: EasyBCD is a software most people install once and never use again. It's definitely not something you would use on a daily basis. But people LOVE power and control, even if it's just an illusion.)
Egads, you're right. That is the sort of software you wouldn't use every day.
Personally, I find it surprising that customers would complain about you removing "trivial" options. Do you think you would lose customers (did they threaten to not use your product)? Would paying for your product change their opinion?
Personally, I find it surprising that customers would complain about you removing "trivial" options. Do you think you would lose customers (did they threaten to not use your product)? Would paying for your product change their opinion?
No, I don't think I'd actually lose anyone. It's hands-down the best tool for the job, and the only competition is from a product that I originally wrote as a freeware in cooperation with another site, was kicked off the project, and was subsequently turned into payware and has stagnated over the years. I could easily sell this product for 5 or 10 a pop and still have a decent userbase, but choose not to for not moral so much as karmic reasons.
But the thing about these features is.. they generate consumer goodwill. I don't know how else to explain it, but implementing stuff like this somehow makes geeks and grandmas alike more willing to endorse it. From the feedback that I've gotten, they feel it "speaks to them" and doesn't get in the way.
But what I've learned, regardless of the reason, keep your users happy and they'll recommend your product. They'll stick with you, and they'll remember you.
Case in point: just yesterday, I added the final feature for the 2.0 milestone which is a blue border around the button used to select the current page when it has focus. Trivial feature. Except instantly a user realizes that if they set an option to start EasyBCD up with a particular page, the blue border will remain along the default button. And they bug it, and when I say "it's really not worth fussing over" they insist: http://neosmart.net/forums/showthread.php?t=6506
That doesn't of course mean that I let the plethora of strongly-opinionated users take over the development of the software. I generally refuse most features. But the subtle enhancements they recommend, that's what I follow. Because it's just a bit more work for me, but it's makes the software go viral without even my trying.
One last thing: I'm absolutely against locking down features. I give users enough rope to hang themselves, but enough guiderails and warning messages that they don't do so blithely. And that opens the door to experimentation, to videos on YouTube where people use the software to do things I didn't think were possible and certainly never intended. And it keeps your users content with you, your software, and any future products you'll ever ship in the future.
tl;dr Features make EasyBCD's users happy. It's minor stuff, they would never abandon ship if it weren't there, but it makes them happy and it makes EasyBCD come to mind whenever someone needs a product that fits the bill.
But the thing about these features is.. they generate consumer goodwill. I don't know how else to explain it, but implementing stuff like this somehow makes geeks and grandmas alike more willing to endorse it. From the feedback that I've gotten, they feel it "speaks to them" and doesn't get in the way.
But what I've learned, regardless of the reason, keep your users happy and they'll recommend your product. They'll stick with you, and they'll remember you.
Case in point: just yesterday, I added the final feature for the 2.0 milestone which is a blue border around the button used to select the current page when it has focus. Trivial feature. Except instantly a user realizes that if they set an option to start EasyBCD up with a particular page, the blue border will remain along the default button. And they bug it, and when I say "it's really not worth fussing over" they insist: http://neosmart.net/forums/showthread.php?t=6506
That doesn't of course mean that I let the plethora of strongly-opinionated users take over the development of the software. I generally refuse most features. But the subtle enhancements they recommend, that's what I follow. Because it's just a bit more work for me, but it's makes the software go viral without even my trying.
One last thing: I'm absolutely against locking down features. I give users enough rope to hang themselves, but enough guiderails and warning messages that they don't do so blithely. And that opens the door to experimentation, to videos on YouTube where people use the software to do things I didn't think were possible and certainly never intended. And it keeps your users content with you, your software, and any future products you'll ever ship in the future.
tl;dr Features make EasyBCD's users happy. It's minor stuff, they would never abandon ship if it weren't there, but it makes them happy and it makes EasyBCD come to mind whenever someone needs a product that fits the bill.
This article is little more than a generic rehash of popular memes. Let's break it down:
- 37Signals is great, they do simple! - anecdote - Apple is great, they do simple!
I hope whatever software this guy does has less opinion and more substance.
- 37Signals is great, they do simple! - anecdote - Apple is great, they do simple!
I hope whatever software this guy does has less opinion and more substance.
Indeed, check out his dig at multitasking on Android and praise of iOS multitasking, even though Apple's implementation seems to be essentially identical.
It's not identical, Android lets you do a lot more in the background than iOS 4.0 does. That's the crux of my part about battery life... because it lets apps do anything in the background it will drain your battery. Apple didn't want to give developers that ability because they were concerned about regular users' iPhone batteries draining.
I don't think it's black and white; you can have an opinionated, simplified front end, and a back end that is wide open. The back-end makes some things easier, such as testing, and helping admins deploy to 100+ users.
A flexible back-end can even be used to create an opinionated front-end. Consider a "factory defaults" file; preset any behavior, whether or not it has a checkbox. Try every combination, and convince yourself that one is better. Even with these decisions made up front, the interface is there to let other people disagree with you.
Mac OS X has a nice balance, because the built-in "defaults" command line program can tweak any setting that would also be available in the application's code. Just because a program is a GUI, doesn't mean that it should rely exclusively on GUI elements for configuration.
A flexible back-end can even be used to create an opinionated front-end. Consider a "factory defaults" file; preset any behavior, whether or not it has a checkbox. Try every combination, and convince yourself that one is better. Even with these decisions made up front, the interface is there to let other people disagree with you.
Mac OS X has a nice balance, because the built-in "defaults" command line program can tweak any setting that would also be available in the application's code. Just because a program is a GUI, doesn't mean that it should rely exclusively on GUI elements for configuration.
At the farthest reaches of powerful software, you will always end up with a programming language and libraries.
At the other extreme, you have one thing that does exactly one task and as such can have a nearly "invisible" interface.
My suspicion is that it's actually kind of rare to need the areas in between - that apps like spreadsheets and photo editing are unusual, and if you _suspect_ that you have an app that could be developed in such a broad, deep, configurable way, your best bet is to start building in a library form and construct prototype one-shots - possibly even making them your MVP - attacking various different problems to see if you're right, before you try to make a unified monster UI for the perceived need.
At the other extreme, you have one thing that does exactly one task and as such can have a nearly "invisible" interface.
My suspicion is that it's actually kind of rare to need the areas in between - that apps like spreadsheets and photo editing are unusual, and if you _suspect_ that you have an app that could be developed in such a broad, deep, configurable way, your best bet is to start building in a library form and construct prototype one-shots - possibly even making them your MVP - attacking various different problems to see if you're right, before you try to make a unified monster UI for the perceived need.
What if my opinion is that software should have more settings? I am very opinionated about that.
Indeed, all software is opinionated. You can't write anything remotely non-trivial without making decisions about what to do, where things go, what to add, what to leave out.
The key, though, is to do it willfully and deliberately. Realize that the end result will come with a point of view, and craft it on purpose.
The key, though, is to do it willfully and deliberately. Realize that the end result will come with a point of view, and craft it on purpose.
Probably explains why Basecamp didn't click for us.
To put that in a less confrontational way: instead of designing features, and then providing options to maximize your audience, first pick an audience, then make software that will work perfectly for them without the need for options. Result: a smaller, more dedicated audience, versus an audience of "everyone" and a product that is as well-suited to an individual task as Microsoft Office.
I always cringe when I hear "don't listen to your customers." That is absolutely the wrong behavior. If you don't listen to the people who are going to buy your product, you won't build a product that solves a real problem.
I listen to my stakeholders (potential users, potential buyers, current users, etc), but I don't necessarily do what they say. Most people try to give you a solution to their problem, you need to dig through their "solution" to find their actual "problem", then design the best solution (and like all design, it is best not when nothing else can be added to it, but rather when nothing else can be taken away).
Oh, and I completely agree that software should be opinionated. People are paying you to solve their problem, don't get lazy and push responsibility back on them!
I listen to my stakeholders (potential users, potential buyers, current users, etc), but I don't necessarily do what they say. Most people try to give you a solution to their problem, you need to dig through their "solution" to find their actual "problem", then design the best solution (and like all design, it is best not when nothing else can be added to it, but rather when nothing else can be taken away).
Oh, and I completely agree that software should be opinionated. People are paying you to solve their problem, don't get lazy and push responsibility back on them!
"don't listen to your customers" means doing exactly the way you describe it in the second paragraph. It does not mean "don't pay attention to what your customers are doing".
Except I've had conversations where people don't do that. I've also seen blogs that say "build what you want, if it's great it will sell." That is BS.
It is very similar to the "Fail Fast" mantra. Yes, if you apply it correctly, you will build a better startup. If you apply it naively, you will do just that: fail quickly.
"Don't listen to your customers" seems to resonate with engineers in a weird way. I think it is a combination of ego and anti-social behavior.
It is very similar to the "Fail Fast" mantra. Yes, if you apply it correctly, you will build a better startup. If you apply it naively, you will do just that: fail quickly.
"Don't listen to your customers" seems to resonate with engineers in a weird way. I think it is a combination of ego and anti-social behavior.
Minor annoyance, but what's the bullshit sideshot against Android multitasking? Are we to believe now that only Apple get's multitasking right? "Apple invented multitasking"? It works fine on my N1. I think Steve didn't even say what makes multitasking on the iPhone so special.
That's how Apple marketing works, and frankly, it makes me dislike them despite of the neat design of their products. If their products are so great, why do they even need to work that kind of marketing?
That's how Apple marketing works, and frankly, it makes me dislike them despite of the neat design of their products. If their products are so great, why do they even need to work that kind of marketing?
Apple doesn't listen to users and they're the most successful technology company in the world. They have a fearless leader who's not afraid to piss people off... Just like Zuckerberg.... Except we all complain about him. I suppose he needed the cult like following before you start to piss people off. That is the key.
Well, I, in turn, think that's bullshit. IMO, the best software conforms to the way the user works, rather than trying to force the user to work in a way that's unnatural to them.
The arguments against a confusing preferences pane and the arguments for sensible defaults in no way contradict the notion of making software than is flexible enough for power users. Poor UI design (3 different places to set prefs?) is orthogonal to the issue of whether or not something should be configurable.
Power Users don't matter? Maybe for certain classes of consumer applications that don't face a steep barrier to adoption in the first place. But for some apps, it's the power users who are the early adopters, who first begin using and evangelizing for the software and without whom it would never catch on in the first place. Do you really want to piss those folks off?
Make the damn "advanced preferences" pane more or less hidden (ala, about:config) but document the shit out of it and make sure it's at least there for the people who do care.