articles about specific add-ons
Majken Connor
bringing up something already discussed somewhere, please feel free to link
me.
That being said, should we be covering specific add-ons? I don't think we
can justify it unless we do support for all of them, and we (Mozilla) don't
want to support add-ons. I'm not talking about supporting issues that can be
caused by specific add-ons, I mean articles like the Adblock Plus article -
http://support.mozilla.com/kb/Adblock+Plus which is basically promoting this
particular extension, and there's no mention of the legitimate issues
(blocking all flash) that can come up when using the extension.
If we want to have an article about certain things that can be accomplished
only via add-ons, that would be ok IMO, but it would need to tell the user
to go to addons.mozilla.org and search for that thing or point to the
recommended add-ons list.
I believe we should only mention specific add-ons in the case where they're
the cause of specific issues.
What does everyone else think?
Jason Barnabe (np)
> That being said, should we be covering specific add-ons? I don't think we
> can justify it unless we do support for all of them, and we (Mozilla) don't
> want to support add-ons.
We're going to have to, just like we're going to have to support
Windows, firewalls, plugins, and anything that the user could think is
Firefox's problem.
I think these articles should contain
-A general overview of what it does
-How to install it (probably just a link to another article)
-How to uninstall it (ditto)
-How to use it
-Links to articles about issues it could have
Majken Connor
wrote:
No, we don't support firewalls. We only give instructions on making sure
they're properly configured for Firefox, we don't list all the features of
the firewall or how to use it. Same for Windows. We don't have any
articles that cover Windows features, or other operating systems. We cover
these things when they're causing a symptom or problem with Firefox.
Chris Ilias
> I don't recall having discussed covering these in the past, so if I'm
> bringing up something already discussed somewhere, please feel free to link
> me.
>
> That being said, should we be covering specific add-ons? I don't think we
> can justify it unless we do support for all of them, and we (Mozilla) don't
> want to support add-ons.
It was discussed, but the entire discussion consisted of:
"we can have support articles for plug-ins, but what about add-ons? Is
that an AMO thing?"
"I don't see why we wouldn't provide support articles for add-ons."
<http://groups.google.com/group/mozilla.support.planning/browse_frm/thread/56bb9180a71e4a6>
I think we'd like to have articles for the more popular add-ons. I like
it, because an add-on author can maintain an article for his/her add-on,
and possibly be encouraged to contribute to other sumo articles.
Majken Connor
My concern is that this is outside of our mandate and might create an
expectation that we support add-ons, which we don't want.
We support plugins because they are supported by firefox, and because
they're necessary for viewing web content. We also don't support the plugin
as a whole, only how to install and troubleshooting issues.
Most add-on authors don't read their discussion pages on amo. While it
would certainly be *nice* if that were a way to get add-on authors to
contribute to sumo, I think that's just not likely. They already contribute
by making add-ons. We shouldn't target people who are already making a
significant contribution to Mozilla in other areas, only if they choose to
or we need that specific person to answer a question.
Jason Barnabe (np)
> My concern is that this is outside of our mandate and might create an
> expectation that we support add-ons, which we don't want.
I don't buy the concept that we don't support extensions, firewalls,
or operating systems but do support plug-ins. To me, we support all of
the things I listed, at least as far as they affect Firefox. We
support Quicktime's settings as they relate to Firefox, but we don't
support them as they relate to Internet Explorer. We support turning
on East Asian support in Windows because it affects Firefox, but not
the myriad of unrelated settings in Windows. The entirety of the
functionality of most extensions affect Firefox, therefore we should
support them.
It's simply pragmatic to have these articles. No matter where we draw
the line, people are going to ask whatever they think is related to
Firefox, so we're going to have to answer one way or another. I'd
rather have this content in the KB than have people answering it in
the forum or in chat.
Majken Connor
wrote:
> On Nov 11, 12:05 am, "Majken Connor" <maj...@gmail.com> wrote:
> > My concern is that this is outside of our mandate and might create an
> > expectation that we support add-ons, which we don't want.
>
> I don't buy the concept that we don't support extensions, firewalls,
> or operating systems but do support plug-ins. To me, we support all of
> the things I listed, at least as far as they affect Firefox. We
> support Quicktime's settings as they relate to Firefox, but we don't
> support them as they relate to Internet Explorer. We support turning
> on East Asian support in Windows because it affects Firefox, but not
> the myriad of unrelated settings in Windows. The entirety of the
> functionality of most extensions affect Firefox, therefore we should
> support them.
>
Yes, we don't support plugins either, we only support them as needed for the
*normal functioning of Firefox.* We don't support quicktime settings, we
support getting background sounds to work. Quicktime settings come into
play because thats what you *have to* change to get background sounds to
work. We support changing from Quicktime to Flash because that is an
*issue* that comes up in the normal operation of the product we *do*
support. If the add-on is causing issues like the skype one did, where it
was breaking the *normal functions of Firefox* then that's what we should
cover. We cover fonts because Firefox only looks for them in the default
fonts folder where safari or IE will find them anywhere on the OS.
>
> It's simply pragmatic to have these articles. No matter where we draw
> the line, people are going to ask whatever they think is related to
> Firefox, so we're going to have to answer one way or another. I'd
> rather have this content in the KB than have people answering it in
> the forum or in chat.
>
And the answer should be to go to that extension's support page, or to
uninstall the extension if support doesn't exist if it's simply a question
of an add-on not working properly. If addons.mozilla.org doesn't have
enough info about what an add-on does on the add-on's page then that's
something that should be fixed on amo.
If we *are* going to take on responsibility for add-ons of any sort, we need
to at least consult with the add-ons team.
Majken Connor
>
>
> On Nov 11, 2007 2:30 AM, Jason Barnabe (np) <jason_...@fastmail.fm>
> wrote:
>
> > On Nov 11, 12:05 am, "Majken Connor" <maj...@gmail.com> wrote:
> > > My concern is that this is outside of our mandate and might create an
> > > expectation that we support add-ons, which we don't want.
> >
> > I don't buy the concept that we don't support extensions, firewalls,
> > or operating systems but do support plug-ins. To me, we support all of
> > the things I listed, at least as far as they affect Firefox. We
> > support Quicktime's settings as they relate to Firefox, but we don't
> > support them as they relate to Internet Explorer. We support turning
> > on East Asian support in Windows because it affects Firefox, but not
> > the myriad of unrelated settings in Windows. The entirety of the
> > functionality of most extensions affect Firefox, therefore we should
> > support them.
> >
>
> Yes, we don't support plugins either, we only support them as needed for
> the *normal functioning of Firefox.* We don't support quicktime settings, we
> support getting background sounds to work. Quicktime settings come into
> play because thats what you *have to* change to get background sounds to
> work. We support changing from Quicktime to Flash because that is an
> *issue* that comes up in the normal operation of the product we *do*
> support. If the add-on is causing issues like the skype one did, where it
> was breaking the *normal functions of Firefox* then that's what we should
> cover. We cover fonts because Firefox only looks for them in the default
> fonts folder where safari or IE will find them anywhere on the OS.
>
>
> >
> > It's simply pragmatic to have these articles. No matter where we draw
> > the line, people are going to ask whatever they think is related to
> > Firefox, so we're going to have to answer one way or another. I'd
> > rather have this content in the KB than have people answering it in
> > the forum or in chat.
> >
>
> And the answer should be to go to that extension's support page, or to
> uninstall the extension if support doesn't exist if it's simply a question
> of an add-on not working properly. If addons.mozilla.org doesn't have
> enough info about what an add-on does on the add-on's page then that's
> something that should be fixed on amo.
>
> If we *are* going to take on responsibility for add-ons of any sort, we
> need to at least consult with the add-ons team.
>
>
Since I'm the one with the concerns, I emailed the amo-admins list to see if
I my impressions of how this has been handled in the past were off-base or
not. I linked to the group, but if I get a direct response I'll be sure to
post it here.
David Tenser
> Majken Connor wrote:
>> That being said, should we be covering specific add-ons? I don't think we
>> can justify it unless we do support for all of them, and we (Mozilla) don't
>> want to support add-ons.
Like Jason says here, we need to support many things outside the core
Firefox product if we want to provide the solution to our user's most
common Firefox problems.
When it comes to add-ons, we actually encourage our users to install
them: http://www.mozilla.com/en-US/firefox/2.0.0.8/whatsnew/add-ons/
This is something that I'd like to see the extension developers help us
with. If you're an author of an extension with a common issue/problem,
it would be awesome if they could write the KB article themselves.
David McRitchie
I think you changed it from how to use an extension to
"a common issue/problem" which would be more legitimate as a KB
article as would be "problem solving" which might involve more
than one extension or applications to get to a goal.
As for the extension itself most problem solving that should
be done on addons, but I see a number of problems where
it appears that extension authors
gave up and just deal with things through their own site, the ambitious
ones keep the distribution at addons but that is about it.
The "What's New" treated as recommendations, and the "We Recommend"
certainly have me wonder most of the time what's going on.
--
HTH,
David McRitchie
My Excel Pages: http://www.mvps.org/dmcritchie/excel/excel.htm
Firefox Custom: http://www.mvps.org/dmcritchie/firefox/firefox.htm
Search Page: http://www.mvps.org/dmcritchie/excel/search.htm
Majken Connor
> _______________________________________________
> <https://lists.mozilla.org/listinfo/support-planning>
>
I haven't received a response from Basil, but if we are going to cover
add-ons, I still think it needs to be carefully coordinated between the
teams, or at the least we're going to have a lot of duplication of effort.
If we cover more than issues, as Jason proposes, then it's going to be a lot
of work to make sure those articles stay current, especially when
localization is factored in. Someone will have to keep up with the
extension, and update the article as an update to the extension introduces
new functions, or breaks existing ones. Will we have people assigned to
these articles, or will we have some other mechanism for tracking when
extensions are updated so that we can update the article?
How are we going to decide which add-ons can have an article and which
can't? Are we going to have articles for add-ons that aren't hosted on amo?
Are we only covering extensions, or will we cover themes and dictionaries,
too?
If we have complete information about how to use an add-on where amo
doesn't, that's probably going to mean at least some users will clue in to
that and start browsing sumo to choose add-ons rather than amo. Will we
include a link to the amo page, or the add-on's homepage so the user can
install the add-on almost directly from sumo, or will they have to search
for it next?
Extension authors already write the extension, as well as the description
and notes that go on amo. Ignoring that fact that *most* won't want to
write a wiki article as well, if the info we're asking them to write for
sumo is the info that users want, then it should be what's written on the
amo page, regardless of whether we duplicate it or not.
Like Jason says here, we need to support many things outside the core
> Firefox product if we want to provide the solution to our user's most
> common Firefox problems.
We're not talking about dealing with common problems though. Yes, we should
definitely deal with the problems and solutions to common issues even if
they're related to add-ons. That's a pretty easy line to draw, and is
pretty straightforward in how we would answer most of the questions above.
How do we decide what add-ons to mention? Ones that cause known issues. If
we want to go beyond that, we need to have a plan as well.
Mike Connor
> Jason Barnabe (np) wrote:
>> Majken Connor wrote:
>>> That being said, should we be covering specific add-ons? I don't
>>> think we
>>> can justify it unless we do support for all of them, and we (Mozilla)
>>> don't
>>> want to support add-ons.
>
> Like Jason says here, we need to support many things outside the core
> Firefox product if we want to provide the solution to our user's most
> common Firefox problems.
Yes, but that to me means "Q. I'm getting this error on startup. A.
Update FooBar to version1.1" not "here's FooBar, this is what it does,
this is how you install/use it, here's the problems, here's some other
random information, etc." Providing answers to specific problems is
absolutely the right thing to do.
Here's an example of what I think we actually do want:
http://support.microsoft.com/kb/328613
This is a problem with the app, caused by a third party product. The
support is confined to "here's how to unbreak our application." Exactly
what we want to do for addon issues, IMO.
> When it comes to add-ons, we actually encourage our users to install
> them: http://www.mozilla.com/en-US/firefox/2.0.0.8/whatsnew/add-ons/
And we have an explicit disclaimer on AMO:
"Mozilla is providing links to these applications as a courtesy, and
makes no representations regarding the applications or any information
related there to. Any questions, complaints or claims regarding the
applications must be directed to the appropriate software vendor."
If we're going to change our policy on how we support addons, we need to
be explicit about what we're taking on and what that means in terms of
officialness. And if we're going to do it, IMO we need to identify the
top extensions and document all of them, not have some scattershot
approach. Either its worth doing all the way, or its not. I think its
not, FWIW.
> This is something that I'd like to see the extension developers help us
> with. If you're an author of an extension with a common issue/problem,
> it would be awesome if they could write the KB article themselves.
I think if we're expanding to "support some/all addons" as part of sumo,
we should understand the scope. This feels like potentially blowing the
scope of sumo wide open, and with a widely translated site like sumo
aspires to be, I think you need to be really aggressive about
controlling scope creep, since every article you add is going to get
translated about 30-40 times at some point.
-- Mike
Mike Connor
Majken Connor wrote:
> I haven't received a response from Basil, but if we are going to cover
> add-ons, I still think it needs to be carefully coordinated between the
> teams, or at the least we're going to have a lot of duplication of effort.
Is there some AMO initiative to do something like this? Not sure what
you mean by duplication of effort.
> How are we going to decide which add-ons can have an article and which
> can't? Are we going to have articles for add-ons that aren't hosted on amo?
> Are we only covering extensions, or will we cover themes and dictionaries,
> too?
this is tough, since even "hosted at AMO" casts a very wide net. What
if we did get articles for 200 of our favourite extensions? Do we have
the resources to handle a couple of hundred extra articles, especially
as we add locales? Seems like we're opening ourselves up to double our
content.
> If we have complete information about how to use an add-on where amo
> doesn't, that's probably going to mean at least some users will clue in to
> that and start browsing sumo to choose add-ons rather than amo. Will we
> include a link to the amo page, or the add-on's homepage so the user can
> install the add-on almost directly from sumo, or will they have to search
> for it next?
Integration would be good, if it comes to it, maybe even have a plugin
to get info about current version via the AMO API. But that's if we
decide this type of info is worth adding (and worth doing right).
> Extension authors already write the extension, as well as the description
> and notes that go on amo. Ignoring that fact that *most* won't want to
> write a wiki article as well, if the info we're asking them to write for
> sumo is the info that users want, then it should be what's written on the
> amo page, regardless of whether we duplicate it or not.
We can possibly pull this directly from AMO, but it feels like
redundancy and duplication at this point.
-- Mike
Majken Connor
> Oy, I should have read this before I replied to David... gah.
>
> Majken Connor wrote:
>
> > I haven't received a response from Basil, but if we are going to cover
> > add-ons, I still think it needs to be carefully coordinated between the
> > teams, or at the least we're going to have a lot of duplication of
> effort.
>
> Is there some AMO initiative to do something like this? Not sure what
> you mean by duplication of effort.
As I explain further down, we're going to be duplicating info that's already
on AMO, and further on we could be duplicating what's meant to be in the
review and discussions pages on the add-on's AMO page (as you noted when you
got to that point)
David Tenser
> On Nov 14, 2007 5:08 PM, David Tenser <djst.m...@gmail.com> wrote:
>
>> Jason Barnabe (np) wrote:
>>> Majken Connor wrote:
>>>> That being said, should we be covering specific add-ons? I don't think
>> we
>>>> can justify it unless we do support for all of them, and we (Mozilla)
>> don't
>>>> want to support add-ons.
>> Like Jason says here, we need to support many things outside the core
>> Firefox product if we want to provide the solution to our user's most
>> common Firefox problems.
>>
>> When it comes to add-ons, we actually encourage our users to install
>> them: http://www.mozilla.com/en-US/firefox/2.0.0.8/whatsnew/add-ons/
>>
>> This is something that I'd like to see the extension developers help us
>> with. If you're an author of an extension with a common issue/problem,
>> it would be awesome if they could write the KB article themselves.
>> _______________________________________________
>> <https://lists.mozilla.org/listinfo/support-planning>
>>
>
> I haven't received a response from Basil, but if we are going to cover
> add-ons, I still think it needs to be carefully coordinated between the
> teams, or at the least we're going to have a lot of duplication of effort.
>
The big problem with extensions is that many users don't even know
they're running them, or that an extension might be the cause of a
problem they're experiencing.
I talked to Basil about this today and what we can do about the
situation. My point of view is that we need to be able to support our
users when they have a Firefox problem. The fact that the problem might
be caused by an extension is irrelevant to the user (because he/she
might not even understand what an extension is). mozilla.com isn't
exactly helping solving that problem either, because we happily
encourage people to install extensions without making it clear that
we're not offering support for them.
The AMO website (the upcoming one) will even remove Support from the top
mozilla.com banner in attempt to reduce the number of people looking for
extension support going to mozilla.com/support. So, where are they going
to go now? Basil admitted he hadn't thought too much about it, but the
general idea is that the extension author provide support for it.
Basil's point of view is that it's going to be impossible for us to
maintain support articles even just for the extensions we promote,
because that number of extensions is going to increase. I can definitely
see that becoming a problem too.
What we came up with, which allows us to stay with our mission (not yet
formalized, but basically "provide the solution to people's problems w/
Firefox"), was to provide articles for the most common issues people
have with extensions, or at least a way for us to direct them to a
general "problem with extension" article that says something like: "It
appears you're having a problem with an extension" and then the
procedure to diagnose and verify it (disable extensions, etc).
So basically, we would make common extension problem symptoms
searchable, but they would normally direct to this generic "Problem with
extension?" article that would describe in step by step instructions how
to determine what extensions are installed, disable extensions,
uninstall them, etc.
I also suggested that the AMO website should be clearer about extensions
being an independent, community developed component that might or might
not work properly. Now we're touching a greater problem, which is how to
communicate about extensions (what are we doing to make people aware of
the distinction between Firefox the product and xyz the extension?).
Again, many users don't know about this distinction and might end up on
our support website.
Jason Barnabe (np)
> If we cover more than issues, as Jason proposes, then it's going to be a lot
> of work to make sure those articles stay current, especially when
> localization is factored in. Someone will have to keep up with the
> extension, and update the article as an update to the extension introduces
> new functions, or breaks existing ones. Will we have people assigned to
> these articles, or will we have some other mechanism for tracking when
> extensions are updated so that we can update the article?
While it may apply more so to extension articles, I think this concern
applies to all articles.
> Are we only covering extensions, or will we cover themes and dictionaries,
> too?
If there's enough you can say about them to warrant an article, sure.
> If we have complete information about how to use an add-on where amo
> doesn't, that's probably going to mean at least some users will clue in to
> that and start browsing sumo to choose add-ons rather than amo.
We're going to have a small fraction of AMO's extensions, so I don't
expect people to start using sumo to find extensions.
> Will we
> include a link to the amo page, or the add-on's homepage so the user can
> install the add-on almost directly from sumo, or will they have to search
> for it next?
Link to the article's entry on sumo, but don't provide an install link
on sumo.
> Extension authors already write the extension, as well as the description
> and notes that go on amo. Ignoring that fact that *most* won't want to
> write a wiki article as well, if the info we're asking them to write for
> sumo is the info that users want, then it should be what's written on the
> amo page, regardless of whether we duplicate it or not.
AMO currently doesn't give extension authors a space to put help
documentation. The spaces provided are for release notes and general
descriptions of what an extension does. From my experience, most of
the help documentation is on the extension author's homepage.
This means the content already exists. Would extension authors want to
duplicate it to sumo, or host it only on sumo, or link to it on
sumo... I don't know. But it's not like they'd have to start from
scratch to put it on sumo.
If AMO starts to let extension authors put help info in, then we've
got duplicated on two Mozilla sites. We'd have to revisit whatever we
decide should that happen.
> How do we decide what add-ons to mention? Ones that cause known issues. If
> we want to go beyond that, we need to have a plan as well.
With unlimited resources, we'd have articles for everything. With
limited resources, we should prioritize based on what users are
looking for.
David Tenser
>
> I think if we're expanding to "support some/all addons" as part of sumo,
> we should understand the scope. This feels like potentially blowing the
> scope of sumo wide open, and with a widely translated site like sumo
> aspires to be, I think you need to be really aggressive about
> controlling scope creep, since every article you add is going to get
> translated about 30-40 times at some point.
>
> -- Mike
I agree with you here. This is unfortunately a tricky question because
from our point of view, it's very easy to separate Firefox from an
extension, but from the user's point of view, the separation is often
nonexistent. The bottom line is that we will inevitably get a lot of
support questions about problems that are really not related to Firefox
itself, but an extension. That's why I think the general approach to
provide step by step instructions on how to diagnose, disable, and
uninstall extensions is a good solution if we can get common search
queries end up on that page.
For the most common problems, however, I still think we should have an
article for that specific extension, even if it would mostly just be a
skeleton article that explains that this is a result of running that
particular extension, and then link to the generic extension
troubleshooting article. I think the need for per-extension articles can
be kept to a minimum, and statistics on navigation paths and search
queries will certainly help figuring out the right level for us.
As long as we're able to solve the user's problem, be it by just
pointing out the possibly faulty extension, and/or just provide
instructions on how to diagnose extension issues, we're doing a good job
of fulfilling our goal.
David Tenser
> AMO currently doesn't give extension authors a space to put help
> documentation. The spaces provided are for release notes and general
> descriptions of what an extension does. From my experience, most of
> the help documentation is on the extension author's homepage.
I proposed to Basil that the extension submission form would have a
support URL field and that the extension listing would prominently link
to it. If no support URL is provided, a notification should be displayed
making it clear that the author of this extension does not provide support.
> With unlimited resources, we'd have articles for everything. With
> limited resources, we should prioritize based on what users are
> looking for.
Exactly. We should make sure we provide the solution to the problems our
visitors are having. If a top 10 search query ends up being related to a
specific extension, we should provide an article that at least says
"you're having a problem with FooBar and here's how to uninstall it."
We don't have to support the extension, but we want to help our users
fixing their problem. That's prio #1.
Majken Connor
> > limited resources, we should prioritize based on what users are
> > looking for.
>
> Exactly. We should make sure we provide the solution to the problems our
> visitors are having. If a top 10 search query ends up being related to a
> specific extension, we should provide an article that at least says
> "you're having a problem with FooBar and here's how to uninstall it."
>
> We don't have to support the extension, but we want to help our users
> fixing their problem. That's prio #1.
> <https://lists.mozilla.org/listinfo/support-planning>
>
Right, and as you said in your previous email, users aren't necessarily
going to distinguish the problem in firefox being caused by an extension, or
necessarily realize they have an extension installed (hopefully this is rare
enough, they've just forgotten). We're best serving them by having issue
specific articles, not extension specific articles.
Chris Ilias
For those who did not attend last week's meeting, this issue was
discussed; and we basically agreed that we would only provide articles
for problems caused by add-ons.
David Tenser
And here's the link to the meeting minutes:
http://wiki.mozilla.org/Support/Weekly_Meetings/Minutes_2007-11-15
Look under "Knowledge Base".