Role of addons
unicorn.consulting at gmail.com
Sat Sep 15 03:33:57 UTC 2012
On 15/09/2012 4:22 AM, Kent James wrote:
> 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.
About config options are almost always buried in the comments of the
bug. They are not documented, until now support have had a policy of
not documenting them in how to articles unless they must. There are
literally thousands of settings in About:config, If we are to start the
process of deliberately placing advanced settings in about:config for
the user to edit then it is time to ante up and document the ones that
are already there.
On a like note, I find it almost impossible to determine what is
actually stored in a file in the user profile. Recently the penchant
for CCleaner to delete the session.json file as a standard part of it's
cleaning arose. What settings are actually stored there? as opposed to
No idea, no documentation and even searching mxr does not provide
answers. I really wonder, if anyone knows. So instead of knowing which
settings would mysteriously not stay set when the file is deleted we ask
questions of users and generally fiddle around and suggest the modify
CCleaner if they have it.
>> 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
> interfaces simple.
I don't think it is advanced features that is the problem, it is UI
design. When I am editing my account setup, there is no button to click
to open passwords or outgoing servers for that account. It is this sort
of creaky decades old design that is the issue.
Over in support land users are asking
* how to change a password (Microsoft have passwords, most users are
x Microsoft software). We hide this stuff so well that some are not
even aware they have a password until it stops working.
* They want to know how to "export" their mail to move to their new
device. This is an area that needs action. We have a full bodied data
intensive application sitting on a machine that is these days often
replaced in 12 to 24 months, that is if it does not simply let out the
magic smoke in 6 months. We have no migration path. Or backup
strategy. I know. backup is a machine thing. Not any more. Everyone
copies their important stuff to USB.
* Where have their menu and toolbars gone (How can I send a mail my
send button and it's whole bar is missing?)
* My account does not work and it has a padlock on it! It would be
funny, except for some providers our penchant for NOT using the account
settings recommended by the providers does mean that padlock is indeed
the reason their mail is not working.
*And they still don't get Tabs (Yesterdays description was a line of
email addresses across the top of the page)
None of those things are advanced features, but they are UI issues. If
the users just don't get it that our design is at fault.
> tb-planning mailing list
> tb-planning at mozilla.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." Benjamin Franklin
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3766 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning