Role of addons

Mark Banner mbanner at mozilla.com
Tue Sep 18 13:23:14 UTC 2012


On 14/09/2012 18:06, Kent James 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.
>
> 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.
Generally, I'm not yet convinced moving items to add-ons that are 
shipped with the core product, will actually benefit us - the 
maintenance of those add-ons would be approximately the same, or even 
slightly more. From the user interface perspective, we'd have the same 
UI with the add-on enabled and we'd need to do some kind of dance for 
having the add-on enabled for existing users, and some sort of UI to 
enable it for new users if they wish to (including explaining the feature).

If we want to look at simplifying what we have, then I think the best 
way to start that is by looking at what we already have and try to drive 
forward consistencies or tab specific options etc.
> 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.
Agreed.

Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120918/d6fc1e89/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120918/d6fc1e89/attachment.p7s>


More information about the tb-planning mailing list