<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 9/14/12 7:20 PM, Blake Winton wrote:<br>
</div>
<blockquote cite="mid:50536771.5020205@mozilla.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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>
</blockquote>
I would love to have a UI map of the usage of Thunderbird, that
would be a great first step into figuring how to reduce complexity.<br>
<br>
Ludo<br>
<pre class="moz-signature" cols="72">--
@lhirlimann on twitter
<a class="moz-txt-link-freetext" href="https://wiki.mozilla.org/Thunderbird:Testing">https://wiki.mozilla.org/Thunderbird:Testing</a></pre>
</body>
</html>