Hacker News Reader

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.

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.

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.

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.

  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.

Obviously it's not a black and white issue... at some point if you provide enough options, you've probably provided a turing complete DSL. And that's not what I'm advocating. I'm advocating making things configurable "within reason" where I'll freely concede that "within reason" is a subjective measure.

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.

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.

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

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.

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

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

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.

Then I have an infinitely valuable compiler and empty file to sell you.

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.

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.

True, true. And that's why I find articles like the parent useful, because they do serve to remind use that we should strive for simplicity... That is, while I may largely disagree with what seems to be the "logical conclusion" of the article, I don't disagree that things should be, as they say, "as simple as possible, but no simpler." And since I am working on some "complex, enterprise software" - and being aware of how notorious this kind of stuff is for NOT being friendly and easy to use - I feel drawn to try and break that trend by making things that are both powerful and flexible, but without being confusing and difficult. It's a difficult balance to strike, and I don't claim to have all the answers, but at least acknowledging the problem and having that as a goal is a start, I think.

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.

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.

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.

  but OP is saying that more preferences don't necessitate 
  poor UI design

This.

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.