Second Life Viewer

In the Snowstorm Product Backlog Office Hour Wednesday, I commented that "I think options are bad for users and bad for code quality". If you read that whole transcript, you can probably see that it was interpreted badly. The most extreme variant ... [More] , reported by someone who was watching in-world chat afterward, held that Linden Lab wanted to remove all options from the Viewer. Let me start by saying that is not the case and never would be, nor is it something that I or anyone at Linden Lab has ever seriously contemplated.However, I still stand by my original comment -- options are problematic for lots of reasons.Let's see why:First, every option has to have a way to control it. In many cases, you have to have multiple ways to control it. From a user interface design point of view, that means creating option interfaces. For the SL Viewer, those are a) the preferences dialog, b) the debug settings, c) checkable menu items, and d) options within dialogs that control other features.You'd normally like to put options with the things they affect, but screen space is always at a premium and many options are only changed infrequently. So instead, we group options together in a preferences dialog. But there are enough of them that it becomes necessary to create some means of organizing prefs into a hierarchical structure, such as tabs.But as soon as you do that, you find that you have trouble because not everyone agrees on what the hierarchy should be. What tabs should you have? Where does each option go? When you get too many options for one tab, how should you split them up?There's no one answer and there's rarely a right answer.And then, once you have a place to put them, you have to decide what to call each option and what the default is. And if those decisions were easy there wouldn't be a need for an option!Second, options add complexity to the interface. Every time you add an option, you add a decision for the user to make. In many cases, someone might not even know what the option controls or whether it's important. Too many options might leave someone feeling that the product is too complex to use.Third, options add complexity to the code. Every option requires code to support all of the branches of the decision tree. If there are multiple options affecting the same feature, all of the combinations must be supported, and tested. Option code is often one of the biggest sources of bugs in a product. The number of options in the Second Life Viewer renderer, which interact not only with each other but with device drivers and different computers, make it literally impossible for us to exhaustively test the renderer. We have to do a probability-based sampling test.You could say that it's our problem to deal with that complexity, and you'd be right, but every additional bit of complexity slows down development and testing and makes it harder for us to deliver meaningful functionality.Fourth, options that are 50-50 probably do need to exist. Options that are 90-10 are addressing an advanced (and possibly important) use case. Having them in the preferences interface promotes them to a primacy they probably don't deserve.Finally, adding options has a snowball effect. Having a small number of options is good, but having too many options is definitely bad for the product and for the customers trying to use it. Sure, advanced uses need advanced features, but we don't have to make everyone confront all of the complexity.Add all of this up, and I think it becomes clearer why I said I didn't like options and would prefer to find alternatives.So why have options at all, then? Because different people legitimately have different needs. Advanced users vs novices, or landowners vs shoppers. We get it. But it's also often an indication of a design that needs work.There are alternatives to putting more checkboxes on the preferences screen:a) Allow entire user interfaces to be "plugged in". This requires a major architectural change to the software. Although we've talked about it, it's going to be a while yet before we get there.b) Allow options to be controlled close to the point of use. As I said above, this can clutter the interface but can be effective.c) Make an interface that covers all use cases. This is the hardest of all, requiring real understanding and design, but is usually the right answer.In short, I often consider adding a preference to the prefs panel to be the wrong answer to a real question. It's not that we don't consider different use cases, it's that we're trying to cover them in a better way.So this has been my attempt to explain the thinking behind a statement like "options bad". I hope it's helped -- has it? Tell me in the comments. [Less]