Role of addons
kent at caspia.com
Fri Sep 14 18:52:06 UTC 2012
On 9/14/2012 11:23 AM, Patrick Cloke wrote:
> On Fri, Sep 14, 2012 at 1:06 PM, Kent James <kent at caspia.com
> <mailto:kent at caspia.com>> wrote:
> 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.
> To be clear here, you're talking about the user interface, but not the
> actual core code? That seems a bit wonky. Maybe it's time to revise
> the UI that touches these features to add "advanced" options?
I think that our sweet spot (to use an overused term) is the advanced,
non-enterprise user. The complex features absolutely need to be there
for our main users, which means that they need to be in the core code.
But we still need some method to push the boundary toward the simpler
users. That means simplifying the user interface. So I don't understand
why that is wonky.
> 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.
> This sounds more complicated to maintain to me. You have to figure
> out what add-ons are installed (or enabled at least) and check various
> combinations of those to ensure everything still works. Plus, when
> writing code, it might be harder to understand all the consumers of a
> certain API.
This has been the major objection to this concept in the past. I'm not
sure though that it is conclusive however.
> 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.
> Is this list actually based on anything? I use most of these on a
> daily basis, as do most people I know of who use Thunderbird. How do
> you decide what stays in and what goes? Can things be
> prompted/demoted? There's political as well as technical questions in
> there, mind you. It would be great to have hard data about what
> features are used and what ones aren't used.
+1 to the hard data, though note this is reaching out to a new segment
of users so you have to interpret the data carefully. The list is only
my personal list of issues I am aware of, not intended on being a
concrete proposal of any kind.
> I also wonder if some options don't necessary need UI and
> "about:config" is a good enough UI for them.
That is good for really rare choices, or cases where a minority
disagrees with a decision (New versus Unread counts in the Mac summary
is a good example of that). But some key players hate them on principle.
> I don't think it makes sense to talk about this in overall terms. I
> think it would be more useful to take a look at each feature
> individually and see whether it can be simplified / removed / etc.
A specific strategy of being more deliberate about pushing advanced
features to addons is an overall issue, and the main point of this
thread. Certainly we should strive whenever possible to keep user
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning