GUI changes

[Kimball Robinson]

On Wednesday 14 March 2007 13:35, Jai Dhyani wrote:
> I think this might be the sort of thing that leads to painfully long
> configuration dialogs, so cluttered with options for 1% of the audience
> that 80% of users can't find the option they want, even if it is
> implemented. With regard to this change, it also makes designing the
> interface that much harder, since the developers have to account for that
> many more possible displays. I imagine even little things, like the pop-up
> notifications, might have to be reworked.
>
> Then again, I could be completely wrong. I'm just worried about seeing
> another great app fall victim to feature bloat.

Feature bloat (I know you didn't use it, but you all but said it) is a 
perjorative blanket term to complain about a general problem that might or 
might not exist in the future.  That's not to say the term isn't sometimes 
justified (maybe it is here), but the above comments don't explain why this 
particular feature would introduce efficiency or usability problems--so it 
strikes me as merely uneducated worrymongering, to be blunt.

Please address the reason /why/ said feature might introduce usability or 
efficiency problems for the user or the CPU (rather than citing vague 
statistics and vague application of them which may not even be relevant).  

Honestly, the capability to move and drag toolbars isn't a new idea, and it 
has proven useful to other applications.  Personally, I don't this feature 
represents a major paradigm shift or a huge amount of new code that won't be 
useful to anyone.

If you're worried about the option cluttering the UI, then look to some other 
examples of configuration management: firefox has multiple configuration 
levels: menus, configuration dialog, sub-configuration dialogs, about:config, 
userprefs.js files, and an extension framework.   Perhaps the real question 
is, where does this configuration option belong, to avoid putting it in the 
face of inexperienced users?

To continue my rant (you may not wish to continue reading this post) Generally 
the term bloat refers to problems with organization, accessibility, and/or 
code efficiency;  each of these can pertain to: the underlying functionality, 
the interface (presentation), or the configuration.

One thing to keep in mind is that "lightweight" and "bloated" are always 
relative terms.  IMHO, kmail is feature rich, not feature bloated. ;)

Rather than refuse to accept new features because they might, if designed and 
implemented badly, slow the user or the machine down, we should address why 
it might, and how to mitigate the cost of implementing the feature.  In other 
words, if you're going to object, at least make a halfhearted effort at doing 
some thoughtful value analysis.

-- 
-Kimball Robinson
(bluekb on irc.freenode.net)