Re: swallowed apps



textshell <textshell neutronstar dyndns org> writes:
> In this list often people say options are "on crack", and then remove them, 
> but what is the *problem* with options.

We should have a FAQ about this or something.

There are a number of costs to any option:

 - adds to the number of items in a dialog or menu. 
   Each dialog or menu can only have a certain number of items
   before it becomes unusable (you can't find what you want).
   Therefore each item needs to be worthwhile.
   (each item incrementally makes things harder to use.)

 - increases difficulty of testing and increases bug 
   reports. I've gotten any number of bugs that only 
   happen when a silly option XYZ is enabled.
   Options flat-out increase the number of codepaths.

 - damages application interactions, because apps can't make any
   assumptions how things work. For example, in the panel-focus case,
   to make things work really nicely the panel and the WM have to
   coordinate how they work together. If you have tons of WM options
   for how focus works, then this becomes very difficult. So I think
   sloppy vs. click to focus for example is probably worth the effort
   to deal with, but obscure focus implementation details that many
   WMs let you configure now are probably not worth it.

 - increases the size of the documentation in unwieldy ways:
   "If you have selected XYZ then foo will happen, else bar"

Moreover, from a more abstract point of view: the number of possible
options useful to someone is infinite. The number of options you can
fit into the code/UI is clearly finite. Therefore eliminating options
that someone finds useful is logically required.

Given this fundamental reality, the only useful question to ask is:
how will you choose which options to include?

Metaphysics about "options bad" or "options good" are always silly,
given that. Having zero options is nonsense, having all options is
nonsense, choosing some options makes sense. How will you choose the
options?

The only productive conversation is to answer that question.

Havoc




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]