<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 14-09-12 13:06 , Kent James wrote:<br>
</div>
<blockquote cite="mid:50536412.6060402@caspia.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
To push at the simplicity boundary, we must be willing to reduce
the complexity of the user interface. One of the main ways that we
have to do that is through addons. The user interface for features
that are only going to be used by a tiny fraction of our users
should be pushed to addons, and not included in the core code.<br>
</blockquote>
As TB UX Lead, I'm a strong +1 on this position. ;)<br>
<blockquote cite="mid:50536412.6060402@caspia.com" type="cite"> In
the long run I would like to see us do this more explicitly by
adding a category of addon that is maintained along with the core
product, and shipped with the core product. So these addons would
have the same commitment to support as any core feature, but are
included as addons to reduce the overall complexity of the
product. Good candidates for that in the long run would be chat,
calendaring, RSS feeds, bayesian junk processing, advanced
security models, and advanced search and filter functionality.<br>
<br>
In the short run, I would encourage us to be selective about
adding new features that complicate an already overwhelming user
interface. Just because a developer is motivated should not be a
good reason to add new user interface items for rarely needed
features.<br>
</blockquote>
I also agree with this, although if any developer wants to simplify
some of the user interface (like aceman is doing for the filter
stuff), I would heartily welcome that!<br>
<blockquote cite="mid:50536412.6060402@caspia.com" type="cite">
Comments?<br>
</blockquote>
Instead of addons, what about having a section of the preferences
dedicated to less-used-features, which can be turned on and off as
the user chooses?<br>
<br>
The benefits I see to this are that it will be easier to keep the
code in sync with the core code, since any breakage will show up in
our tests, and it shouldn't be any less work to provide the same
level of support.<br>
<br>
The disadvantage is that we may forget that some features are not
always enabled, and so code against them in the core.<br>
<br>
Later,<br>
Blake.<br>
<pre class="moz-signature" cols="72">--
Blake Winton Thunderbird User Experience Lead
<a class="moz-txt-link-abbreviated" href="mailto:bwinton@mozilla.com">bwinton@mozilla.com</a></pre>
</body>
</html>