Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Monkey article

0 views
Skip to first unread message

Majken Connor

unread,
Sep 9, 2008, 1:14:29 AM9/9/08
to Planning how we can best support our users
(contribs forum won't let me see more than the first page of results, want
to bump djst's thread but can't see it)

http://support.mozilla.com/en-US/kb/Using+the+same+bookmarks+and+settings+on+multiple+computersis
a monkey article IMO. I'm fine with leaving the article and explaining
Firefox doesn't do it yet, but addons exist, and maybe link to labs, but it
crosses our line of how to do things that Firefox does and it definitely
shouldn't link to specific extensions or unofficial builds.

Majken Connor

unread,
Sep 9, 2008, 1:25:17 AM9/9/08
to Planning how we can best support our users

discussing this with Myles on IRC, I think *my* ideal solution is to have a
general "Firefox is missing a feature that I want" article that gives a
basic description of options, like amo or how to request the feature. We can
have articles that explain the feature isn't currently available in Firefox
and link to this generic article. This allows us to avoid recommending
specific addons and 3rd party software but lets us have something useful up
for frequently asked features that are beyond our current scope.

David Tenser

unread,
Sep 9, 2008, 4:23:07 AM9/9/08
to

I agree that this is bordering monkeying around with the browser. In
addition, Google Browser Sync seems to have been removed from their
site. I was going to say that Google Browser Sync actually sounds like a
reasonable suggestion for people looking for this functionality that
wouldn't be monkeying around. But since it's not even there anymore, I
see no reason to keep the broken article like this.

Aren't there other services that can share your bookmarks online? I'd
guess most people are interested in that part of this -- having their
bookmarks accessible from any computer. That sounds like a reasonable
thing to cover in an article if there is a straightforward extension for
it, as long as we make it clear that it's an extension that is not
supported.

myles7897

unread,
Sep 9, 2008, 9:35:21 AM9/9/08
to
On Sep 9, 1:23 am, David Tenser <djst.mozi...@gmail.com> wrote:
> Majken Connor wrote:
> > On Tue, Sep 9, 2008 at 1:14 AM, Majken Connor <maj...@gmail.com> wrote:
>
> >> (contribs forum won't let me see more than the first page of results, want
> >> to bump djst's thread but can't see it)
>
> >>http://support.mozilla.com/en-US/kb/Using+the+same+bookmarks+and+sett...a monkey article IMO. I'm fine with leaving the article and explaining

> >> Firefox doesn't do it yet, but addons exist, and maybe link to labs, but it
> >> crosses our line of how to do things that Firefox does and it definitely
> >> shouldn't link to specific extensions or unofficial builds.
>
> > discussing this with Myles on IRC, I think *my* ideal solution is to have a
> > general "Firefox is missing a feature that I want" article that gives a
> > basic description of options, like amo or how to request the feature. We can
> > have articles that explain the feature isn't currently available in Firefox
> > and link to this generic article. This allows us to avoid recommending
> > specific addons and 3rd party software but lets us have something useful up
> > for frequently asked features that are beyond our current scope.
>
> I agree that this is bordering monkeying around with the browser. In
> addition, Google Browser Sync seems to have been removed from their
> site. I was going to say that Google Browser Sync actually sounds like a
> reasonable suggestion for people looking for this functionality that
> wouldn't be monkeying around. But since it's not even there anymore, I
> see no reason to keep the broken article like this.
>
> Aren't there other services that can share your bookmarks online? I'd
> guess most people are interested in that part of this -- having their
> bookmarks accessible from any computer. That sounds like a reasonable
> thing to cover in an article if there is a straightforward extension for
> it, as long as we make it clear that it's an extension that is not
> supported.

> Aren't there other services that can share your bookmarks online?

There is Mozilla Labs' Weave, http://labs.mozilla.com/projects/weave/
and and add-on called Foxmarks Bookmark Synchronizer,
https://addons.mozilla.org/en-US/firefox/addon/2410

Majken Connor

unread,
Sep 9, 2008, 2:31:05 PM9/9/08
to Planning how we can best support our users
On Tue, Sep 9, 2008 at 4:23 AM, David Tenser <djst.m...@gmail.com> wrote:

> Majken Connor wrote:
> > On Tue, Sep 9, 2008 at 1:14 AM, Majken Connor <maj...@gmail.com> wrote:
> >
> >> (contribs forum won't let me see more than the first page of results,
> want
> >> to bump djst's thread but can't see it)
> >>
> >>
> >>

> http://support.mozilla.com/en-US/kb/Using+the+same+bookmarks+and+settings+on+multiple+computersisa monkey article IMO. I'm fine with leaving the article and explaining

> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>

myles was updating the article, which is how we got on the subject. I
understand what you're saying but that's not what we agreed on when we were
discussing this in the first place. There are several extensions that sync
your bookmarks. We can't list them all and listing only some would seem like
an endorsement - otherwise why did we list it over others?

If we're going to suggest addons we need a clear policy on which we suggest.
Perhaps we give the most popular amo addon as an example. I'd rather stick
to what I understood as the current policy which is we don't, unless under
exceptional circumstances, like Hide Unvisited. The general article can link
to a list of the most popular addons to get people started looking for what
they want.

David Tenser

unread,
Sep 9, 2008, 4:11:45 PM9/9/08
to

Yeah so the question here is whether or not this is a frequent enough
request to warrant exceptions. What's the stat from forum/chat?

However, if this is "just" a frequent request (i.e. not an extremely
frequent request that warrants exceptions), just pointing out that there
are extensions that can do this is a good thing. We don't list any
extensions, but we provide an answer to the user's question and give
them a pointer on where they can look.


Majken Connor

unread,
Sep 9, 2008, 4:29:17 PM9/9/08
to Planning how we can best support our users
On Tue, Sep 9, 2008 at 4:11 PM, David Tenser <djst.m...@gmail.com> wrote:

> Majken Connor wrote:
> > On Tue, Sep 9, 2008 at 4:23 AM, David Tenser <djst.m...@gmail.com>
> wrote:
> >
> >> Majken Connor wrote:
> >>> On Tue, Sep 9, 2008 at 1:14 AM, Majken Connor <maj...@gmail.com>
> wrote:
> >>>
> >>>> (contribs forum won't let me see more than the first page of results,
> >> want
> >>>> to bump djst's thread but can't see it)
> >>>>
> >>>>
> >>>>
> >>

> http://support.mozilla.com/en-US/kb/Using+the+same+bookmarks+and+settings+on+multiple+computersisamonkey article IMO. I'm fine with leaving the article and explaining


Page hits should probably be a good enough stat to go from. It's not an
uncommon question but I don't think we necessarily get asked it once a week
either.


>
>
> However, if this is "just" a frequent request (i.e. not an extremely
> frequent request that warrants exceptions),


To start a side discussion, I don't think frequency is a good factor alone
in deciding when exceptions are made. We made an exception for hide
unvisited, for example, because the current behaviour is a regression and a
bad user experience, als Hide Unvisited was written by the developer who did
a good chunk of work on the awesome bar.

A missing feature can be a bad user experience as well, but it's not in the
same park as an existing feature regressing or being incomplete. If it's a
very frequently requested feature then first step should be communicating
with the developers. We might endorse a specific extension if the plan is to
add that feature to Firefox by building it in, as in this case, the
extension is already being endorsed clearly by being integrated.

We should flesh out a policy on when we do include specific extensions and
how we choose which. Though ideally, IMO, exceptions only ever happen with
discussion on top of that.


> just pointing out that there
> are extensions that can do this is a good thing. We don't list any
> extensions, but we provide an answer to the user's question and give
> them a pointer on where they can look.
>
>
>

Back to original discussion sounds good, I'll file a bug on the generic
article.

David Tenser

unread,
Sep 9, 2008, 5:18:25 PM9/9/08
to

How did we come to that conclusion, if it wasn't for the fact that a lot
of people started to request it? If everyone thought the awesome bar was
nothing but awesome, I doubt we would've identified this "regression" in
the first place. Which is not a bad thing, because we're listening to
our users. I could be wrong, of course; I didn't follow the discussions
around this particular feature.

Frequency is not the only factor, though, which perhaps is what you're
saying here. User experience research and likely lots of other things
should be taken into consideration too. And yes, it should be a
discussion. I agree with that.

>
>> just pointing out that there
>> are extensions that can do this is a good thing. We don't list any
>> extensions, but we provide an answer to the user's question and give
>> them a pointer on where they can look.
>>
>>
>>
> Back to original discussion sounds good, I'll file a bug on the generic
> article.

Just to clarify, what I mean here is that if we're seeing a feature
request being reported frequently, and we have extensions that add this
functionality, we would include the generic info in the article for that
feature request, saying e.g. "there is no built-in functionality for
this in firefox, but you can search AMO for extensions that add this
functionality." In this particular case, the article
http://support.mozilla.com/en-US/kb/Using+the+same+bookmarks+and+settings+on+multiple+computers
would contain that generic answer, instead of pointing to two specific
extensions. Basically, we're telling the user that there is a solution
to their problem, but we aren't officially supporting or endorsing it on
SUMO; we're merely pointing out where the user can go to extend his/her
browsing experience by directing them to AMO.

With that said, I didn't suggest we create a generic article for feature
requests and AMO in general, because I'm not sure how that would be
used. Could you explain what you had in mind there? How would people
find that article?

Majken Connor

unread,
Sep 9, 2008, 5:24:01 PM9/9/08
to Planning how we can best support our users
On Tue, Sep 9, 2008 at 5:18 PM, David Tenser <djst.m...@gmail.com> wrote:

> Majken Connor wrote:
> > On Tue, Sep 9, 2008 at 4:11 PM, David Tenser <djst.m...@gmail.com>
> wrote:
> >
> >> Majken Connor wrote:
> >>> On Tue, Sep 9, 2008 at 4:23 AM, David Tenser <djst.m...@gmail.com>
> >> wrote:
> >>>> Majken Connor wrote:
> >>>>> On Tue, Sep 9, 2008 at 1:14 AM, Majken Connor <maj...@gmail.com>
> >> wrote:
> >>>>>> (contribs forum won't let me see more than the first page of
> results,
> >>>> want
> >>>>>> to bump djst's thread but can't see it)
> >>>>>>
> >>>>>>
> >>>>>>
> >>

> http://support.mozilla.com/en-US/kb/Using+the+same+bookmarks+and+settings+on+multiple+computersisamonkeyarticle IMO. I'm fine with leaving the article and explaining

We'd link to it from articles like this. It'd also be a very handy article
for forums and live chat for when people ask for things that aren't popular
enough to have their own articles. That is to say, this would be the "main"
article in terms of "firefox is missing x feature" and for requests we get
enough of we'd make an article that specifically addresses the question.

Chris Ilias

unread,
Sep 9, 2008, 5:27:01 PM9/9/08
to
On 9/9/08 9:35 AM, _myles7897_ spoke thusly:

I asked in #labs, and got the impression they didn't think Weave is
ready for that yet. It's still a 0.* version, and apparently there are
log in issues.

David Tenser

unread,
Sep 9, 2008, 5:34:03 PM9/9/08
to

Chris Ilias

unread,
Sep 9, 2008, 5:50:08 PM9/9/08
to
On 9/9/08 2:31 PM, _Majken Connor_ spoke thusly:

> myles was updating the article, which is how we got on the subject. I
> understand what you're saying but that's not what we agreed on when we were
> discussing this in the first place. There are several extensions that sync
> your bookmarks. We can't list them all and listing only some would seem like
> an endorsement - otherwise why did we list it over others?
>
> If we're going to suggest addons we need a clear policy on which we suggest.
> Perhaps we give the most popular amo addon as an example. I'd rather stick
> to what I understood as the current policy which is we don't, unless under
> exceptional circumstances, like Hide Unvisited. The general article can link
> to a list of the most popular addons to get people started looking for what
> they want.

The only current policy WRT add-ons is to link through AMO. I definitely
don't want to have a "don't link to any add-ons" policy. How about
making it mandatory to cite the add-on author, or something like that
which indicates that the add-on is developed by Mozilla?

Some other things to consider:
- AMO has certain add-ons tagged as recommended.
- In many cases, there's only one add-on that will be linked; so knowing
which one to pick (if there's a need to limit it to one) isn't as much
of an issue as making it clear that it is not developed my Mozilla.

chris hofmann

unread,
Sep 9, 2008, 7:04:14 PM9/9/08
to Planning how we can best support our users

we should check out navigation paths to see what is working and what is not.

people scratching there heads about why their favorite feature seems to
be missing ought to have a clear path to finding out how to fill that gap.

on the home page we have

[Customizing Firefox with add-ons]

but maybe that needs a wording change. those frustrated people don't
want to "customize" they want to "add a feature"

How about some like

[Want to add a feature to Firefox? | link to
http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons]

The we should say in clear language that the add-on site has over a
1000 ways to add that special feature to firefox that you might have
been thinking about.

The link [Customizing Firefox with add-ons] has also dipped below the
fold again...

We should look at ways to tight up the home page.

Could we shorten

"Have a question about Firefox? Search our community-powered
Knowledge Base for the answers you need."

to

Have a question about Firefox? Search for the answers you need.


There is still lots of white space between the search box and lower
sections of the page.

Those changes and others could make the heavily traveled paths more
visiable and get them working better for visitors.

What are the most frequent paths on the page now, and what adjustments
could we make to make get the most important links more visible?

-chofmann

Majken Connor

unread,
Sep 9, 2008, 7:20:18 PM9/9/08
to Planning how we can best support our users
On Tue, Sep 9, 2008 at 5:34 PM, David Tenser <djst.m...@gmail.com> wrote:

> Majken Connor wrote:
> > On Tue, Sep 9, 2008 at 5:18 PM, David Tenser <djst.m...@gmail.com>
> wrote:
> >
> >> Majken Connor wrote:
> >>> On Tue, Sep 9, 2008 at 4:11 PM, David Tenser <djst.m...@gmail.com>
> >> wrote:
> >>>> Majken Connor wrote:
> >>>>> On Tue, Sep 9, 2008 at 4:23 AM, David Tenser <djst.m...@gmail.com
> >
> >>>> wrote:
> >>>>>> Majken Connor wrote:
> >>>>>>> On Tue, Sep 9, 2008 at 1:14 AM, Majken Connor <maj...@gmail.com>
> >>>> wrote:
> >>>>>>>> (contribs forum won't let me see more than the first page of
> >> results,
> >>>>>> want
> >>>>>>>> to bump djst's thread but can't see it)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>

> http://support.mozilla.com/en-US/kb/Using+the+same+bookmarks+and+settings+on+multiple+computersisamonkeyarticleIMO. I'm fine with leaving the article and explaining

There's a difference between users who want to customize Firefox with
add-ons and users who feel Firefox is missing a feature. Also the
customizing firefox article wouldn't have instructions on how to let people
know you think it should be integrated and not just an add-on.

Also the customizing article is geared towards people who have already
decided they want to customize Firefox. The missing feature article would be
geared towards users who were looking for something built in. There may or
may not be the added step of introducing them to add-ons altogether
including why add-ons are a good alternative to having features built in,
which would be cruft in a how to for people who already know firefox is
customizable and already want to give it a shot.

David Tenser

unread,
Sep 10, 2008, 4:35:39 AM9/10/08
to


But that's why we would explain in the feature request article itself
that "feature x does not exist in Firefox... but: [standard description
of extensions + link to customizing article for more info]."

Having a second article covering nearly exactly the same things seems
like a significant and unnecessary overlap. I'd rather clarify the
existing article and/or rename it if it's not sending the right message.

What we want with that article is to

1) promote the extensibility of Firefox, which is one of our really big
strengths
2) provide instructions on how you install and use extensions
3) make it clear that extensions are third-party addons that aren't
officially supported

I think we're doing well on 2) above, but we can certainly make 1)
clearer, and we don't really cover 3) at all today.

David Tenser

unread,
Sep 10, 2008, 4:54:43 AM9/10/08
to
chris hofmann wrote:
>
> we should check out navigation paths to see what is working and what is
> not.
>
> people scratching there heads about why their favorite feature seems to
> be missing ought to have a clear path to finding out how to fill that gap.
>
> on the home page we have
>
> [Customizing Firefox with add-ons]
>
> but maybe that needs a wording change. those frustrated people don't
> want to "customize" they want to "add a feature"
>
> How about some like
>
> [Want to add a feature to Firefox? | link to
> http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons]

Yeah, something like that, or "Extend the functionality in Firefox," or
"Adding features to Firefox" ...

>
> The we should say in clear language that the add-on site has over a
> 1000 ways to add that special feature to firefox that you might have
> been thinking about.

I think this is a good point: there are so many add-ons for Firefox
today, people usually just have to do a quick search on AMO to get their
requested functionality. We should be clearer about the fact that
whatever their feature request is, there's a high change an extension
already exists.

The extensibility is already promoted as one of the big strengths of
Firefox -- SUMO making that clearer for people makes a lot of sense for
a number of reasons.

>
> The link [Customizing Firefox with add-ons] has also dipped below the
> fold again...
>
> We should look at ways to tight up the home page.
>
> Could we shorten
>
> "Have a question about Firefox? Search our community-powered Knowledge
> Base for the answers you need."
>
> to
>
> Have a question about Firefox? Search for the answers you need.

That would still span two rows even for en-US, and most localizations
would also be unaffected.

>
>
> There is still lots of white space between the search box and lower
> sections of the page.

We could do some minor pixel shaving which might get us another text row
above the 600px fold, but I propose reordering the links in the New to
Firefox box. The Installing Firefox article might be less important than
Customizing Firefox, for example.

Ken showed some pretty neat features in Omniture that labeled the
different paths from the start page so you could clearly see what people
clicked the most; let's get some of that metrics up for discussion.

Majken Connor

unread,
Sep 10, 2008, 2:28:38 PM9/10/08
to Planning how we can best support our users


So I think the existing article is sending the right message for what it's
meant to. Your point 3 below is going to be the biggest way that they
differ. The right message for someone who already knows what extensions are
should involve a fairly basic warning that extensions aren't developed by
mozilla and if you have a problem with them you need to go to the author for
support. For someone who didn't know about add-ons and just wants Firefox
to work they way IE did, or Safari did (eg) that warning is going to be
scary and should be phrased in a completely different manner. Also, someone
may not want to use add-ons but may want to just suggest the feature and
wait for it to be integrated.


>
>
> What we want with that article is to
>
> 1) promote the extensibility of Firefox, which is one of our really big
> strengths
> 2) provide instructions on how you install and use extensions
> 3) make it clear that extensions are third-party addons that aren't
> officially supported
>
> I think we're doing well on 2) above, but we can certainly make 1)
> clearer, and we don't really cover 3) at all today.

> _______________________________________________
>

I think in the case of a user who's looking for a specific feature,and not
someone who's interested in exploring Firefox' extensibility 2 from above
should be in a different article. These sections from the current article
shouldn't be in an article introducing someone to the concept of addons and
how to add features to firefox


- Managing extensions<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Managing_extensions>
- Checking for extension
updates<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Checking_for_extension_updates>
- Extension optionspreferences<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Extension_span_style_text_align_left_float_none_clear_none_class_win_options_span_span_style_text_align_left_float_none_clear_none_class_noWin_preferences_span_>
- Switching themes<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Switching_themes>
- Managing themes<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Managing_themes>
- Using themes<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Using_themes>
- Managing Plugins<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Managing_Plugins>


These things however, are very important and should be in an article like
they're in now, but they're going to be overwhelming and overkill to people
that we're trying to convince to give addons a try. That article should just
cover the basics

- what are add-ons?
- where do I get them?
- how do I know they're safe?
- can I just ask the developers to add my feature?

David Tenser

unread,
Sep 10, 2008, 2:38:32 PM9/10/08
to
Majken Connor wrote:
> I think in the case of a user who's looking for a specific feature,and not
> someone who's interested in exploring Firefox' extensibility 2 from above
> should be in a different article. These sections from the current article
> shouldn't be in an article introducing someone to the concept of addons and
> how to add features to firefox
>
>
> - Managing extensions<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Managing_extensions>
> - Checking for extension
> updates<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Checking_for_extension_updates>
> - Extension optionspreferences<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Extension_span_style_text_align_left_float_none_clear_none_class_win_options_span_span_style_text_align_left_float_none_clear_none_class_noWin_preferences_span_>
> - Switching themes<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Switching_themes>
> - Managing themes<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Managing_themes>
> - Using themes<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Using_themes>
> - Managing Plugins<http://support.mozilla.com/en-US/kb/Customizing+Firefox+with+add-ons#Managing_Plugins>
>
>
> These things however, are very important and should be in an article like
> they're in now, but they're going to be overwhelming and overkill to people
> that we're trying to convince to give addons a try. That article should just
> cover the basics
>
> - what are add-ons?
> - where do I get them?
> - how do I know they're safe?
> - can I just ask the developers to add my feature?


I like this separation more. To clarify:

- One article to explain what addons are, etc
- Another article to explain how to install/manage/etc them


That seems more in line with our needs, and we can include the "can i
just ask" section where it makes the most sense. We need to figure out
good titles for both. Ideas?

Majken Connor

unread,
Sep 10, 2008, 2:57:14 PM9/10/08
to Planning how we can best support our users

> _______________________________________________
>

Installing and managing add-ons for the second?
I'd still go with something like Firefox is missing a feature or Adding and
changing Firefox features

Chris Ilias

unread,
Sep 10, 2008, 11:10:45 PM9/10/08
to
On 9/10/08 2:38 PM, _David Tenser_ spoke thusly:

> I like this separation more. To clarify:
>
> - One article to explain what addons are, etc
> - Another article to explain how to install/manage/etc them
>
>
> That seems more in line with our needs, and we can include the "can i
> just ask" section where it makes the most sense. We need to figure out
> good titles for both. Ideas?

How are users going to arrive at this article?

David Tenser

unread,
Sep 11, 2008, 7:26:06 AM9/11/08
to

right, the other article would cover, like you proposed:


>>> - what are add-ons?
>>> - where do I get them?
>>> - how do I know they're safe?
>>> - can I just ask the developers to add my feature?

then the other article would be more specific about how you install,
uninstall, etc, and where in the UI you get this. basically the one we
already have.

so this new article would be more high-level and explain the
fundamentals, and why extensions can help people get new features, etc.
then we'd link to the other article for the specifics on how to actually
install, etc.

David Tenser

unread,
Sep 11, 2008, 7:27:42 AM9/11/08
to

We would link to that article from specific feature requests articles
like the one this thread was about originally, but it would also be used
for helpers in the forum/chat to point out how they can get their added
functionality they might be requesting. It would also be linked to from
the start page instead of the current "Customize firefox with addons,"
which is focusing more in the logistics of actually installing/managing
them.

Chris Ilias

unread,
Sep 11, 2008, 2:44:23 PM9/11/08
to
On 9/11/08 7:27 AM, _David Tenser_ spoke thusly:

> Chris Ilias wrote:
>
>> How are users going to arrive at this article?
>
> We would link to that article from specific feature requests articles
> like the one this thread was about originally,

For articles that enquire about features Firefox does not have, I think
it's better to list helpful add-ons in the article itself. Making users
go through two articles, only to find out they have to search a separate
site is a bad user experience.

Majken Connor

unread,
Sep 11, 2008, 4:32:34 PM9/11/08
to Planning how we can best support our users

> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>

How do we choose which ones though? By linking directly to some add-ons that
provide a function we're giving that add-on and its author an unfair
advantage. Even if we make it clear that we're not responsible for the
add-on it's still going to come across as an endorsement. If that's what
we're going to do we have to have a very careful policy for choosing these
and we'd need to work at least with the AMO team to make sure we're choosing
well written and well maintained examples to make sure we're recommending
the right ones to users (all of which adds up more and more to an
endorsement).

It's the same experience that users who assumed the feature was missing and
went straight to AMO will have. Cataloging which add-ons add which features
is AMO territory. Maybe this is something they can do, taken from our stats
on what people are looking for most, have lists of most wanted features and
extensions that add that feature and authors can apply to have their add-on
added to that list if it suits. AMO can then display the list including
everything a user needs to know to decide which to install, including
current ratings, download counts and reviews.

We could link to the recommended add-ons from the appropriate category as a
starting point, eg the recommended add-ons for the bookmarks category can be
found here https://addons.mozilla.org/en-US/firefox/browse/type:1/cat:22though
I'm not sure what criteria is used to make an addon "recommended"

Chris Ilias

unread,
Sep 11, 2008, 5:58:07 PM9/11/08
to
On 9/11/08 4:32 PM, _Majken Connor_ spoke thusly:

> On Thu, Sep 11, 2008 at 2:44 PM, Chris Ilias <n...@ilias.ca> wrote:
>
>> For articles that enquire about features Firefox does not have, I think
>> it's better to list helpful add-ons in the article itself. Making users
>> go through two articles, only to find out they have to search a separate
>> site is a bad user experience.
>
> How do we choose which ones though? By linking directly to some add-ons that
> provide a function we're giving that add-on and its author an unfair
> advantage. Even if we make it clear that we're not responsible for the
> add-on it's still going to come across as an endorsement. If that's what
> we're going to do we have to have a very careful policy for choosing these
> and we'd need to work at least with the AMO team to make sure we're choosing
> well written and well maintained examples to make sure we're recommending
> the right ones to users (all of which adds up more and more to an
> endorsement).

If an add-on applies, we link. In cases where more than one apply, we
list all that apply.

Majken Connor

unread,
Sep 11, 2008, 6:12:42 PM9/11/08
to Planning how we can best support our users

> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>

Who would be in charge of maintaining these lists against new add-on
submissions and approvals? How do users know which to pick if there are 20
that add the feature? Do we include just links, or do we also include
descriptions of the add-on?

Chris Ilias

unread,
Sep 11, 2008, 7:05:36 PM9/11/08
to
On 9/11/08 6:12 PM, _Majken Connor_ spoke thusly:

> Who would be in charge of maintaining these lists against new add-on
> submissions and approvals?

Community. It's a wiki. :-)

> How do users know which to pick if there are 20
> that add the feature?

If there are 20, we should file a bug to get an AMO category created,
then link to that category. But right now, there aren't any articles
that list anything close to 20.

> Do we include just links, or do we also include
> descriptions of the add-on?

Always include descriptions, even it's just one add-on.

David Tenser

unread,
Sep 12, 2008, 4:55:05 AM9/12/08
to
Chris Ilias wrote:
> On 9/11/08 6:12 PM, _Majken Connor_ spoke thusly:
>> Who would be in charge of maintaining these lists against new add-on
>> submissions and approvals?
>
> Community. It's a wiki. :-)
>

Let's not go there, for now. The risks of linking directly to add-ons
are clear and I think we create unnecessary problems for ourselves by
promoting them on SUMO.

The user doesn't have to go to that other article to find out more about
extensions, as we will be linking to AMO directly from the "feature
request" article too. E.g.:

"There is no such functionality built into Firefox today. However, there
are add-ons available that achieve it. Go to http://addons.mozilla.org/
to search for and install extensions for Firefox.

For more information about add-ons, read ((article about addons, their
purpose, support situation, etc.))."

Chris Ilias

unread,
Sep 12, 2008, 3:14:56 PM9/12/08
to
On 9/12/08 4:55 AM, _David Tenser_ spoke thusly:

> Chris Ilias wrote:
>> On 9/11/08 6:12 PM, _Majken Connor_ spoke thusly:
>>> Who would be in charge of maintaining these lists against new add-on
>>> submissions and approvals?
>>
>> Community. It's a wiki. :-)
>
> Let's not go there, for now. The risks of linking directly to add-ons
> are clear and I think we create unnecessary problems for ourselves by
> promoting them on SUMO.

So far, I disagree. As I understand it, the risks are that the links
will not be maintained; and that's no more of a risk than keeping any
other part of the KB up to date. I fear that this effort to make the KB
require the least maintenance possible is degrading the user experience.

Plus, this is a great opportunity for new contributors to make their
first edit.

Articles that apply (bug 411557 would have helped in creating this list):
http://support.mozilla.com/en-US/kb/ActiveX
http://support.mozilla.com/en-US/kb/Images+or+animations+do+not+show
http://support.mozilla.com/en-US/kb/Using+Firefox+for+Windows+Update
http://support.mozilla.com/en-US/kb/Video+or+audio+does+not+play
http://support.mozilla.com/en-US/kb/Using+the+Flash+plugin+with+Firefox
http://support.mozilla.com/en-US/kb/Managing+file+types
http://support.mozilla.com/en-US/kb/Parental+controls
http://support.mozilla.com/en-US/kb/JavaScript
http://support.mozilla.com/en-US/kb/Form+autocomplete
http://support.mozilla.com/en-US/kb/Warning+Unresponsive+script
http://support.mozilla.com/en-US/kb/Reloading+Live+Bookmarks
http://support.mozilla.com/en-US/kb/Clearing+Location+bar+history
http://support.mozilla.com/en-US/kb/Using+the+same+bookmarks+and+settings+on+multiple+computers
http://support.mozilla.com/en-US/kb/Granting+JavaScript+access+to+the+clipboard
http://support.mozilla.com/en-US/kb/Creating+a+desktop+shortcut+to+a+web+page
http://support.mozilla.com/en-US/kb/Using+Outlook+Web+Access+in+Firefox
http://support.mozilla.com/en-US/kb/Firefox+forgets+where+you+were+on+previously+viewed+pages
http://support.mozilla.com/en-US/kb/How+to+disable+the+Smart+Location+Bar
http://support.mozilla.com/en-US/kb/Bookmark+Tags

I can understand getting rid of sections in articles called "Add-ons"
that seem to just add icing on the cake of an article; but there are
many instances where add-ons are presented as solutions to questions.

Majken Connor

unread,
Sep 12, 2008, 3:36:20 PM9/12/08
to Planning how we can best support our users
On Fri, Sep 12, 2008 at 3:14 PM, Chris Ilias <n...@ilias.ca> wrote:

> On 9/12/08 4:55 AM, _David Tenser_ spoke thusly:
> > Chris Ilias wrote:
> >> On 9/11/08 6:12 PM, _Majken Connor_ spoke thusly:
> >>> Who would be in charge of maintaining these lists against new add-on
> >>> submissions and approvals?
> >>
> >> Community. It's a wiki. :-)
> >
> > Let's not go there, for now. The risks of linking directly to add-ons
> > are clear and I think we create unnecessary problems for ourselves by
> > promoting them on SUMO.
>
> So far, I disagree. As I understand it, the risks are that the links
> will not be maintained; and that's no more of a risk than keeping any
> other part of the KB up to date.


Actually it is moreso. In our current scope, things that one does with
Firefox usually, our community base can easily stay on top of new
information. This is supplemented by monitoring new issues and solutions
from Live Chat and the forums. Even if all of our community kept articles
up to date with information on add-ons that they use themselves, we're still
only going to be covering a fraction of the add-ons available. Someone
*will* have to be in charge of watching new submissions and updates to all
extensions if this were to be kept as current as the rest of the information
in the knowledge base.


> I fear that this effort to make the KB
> require the least maintenance possible is degrading the user experience.


It's not about making the KB require the least maintenance possible. It's
about keeping focused on our mission and keeping that mission achievable.
Lots of other things degrade user experience, first and foremost that
feature not being included in Firefox in the first place. We're not writing
patches or extensions ourselves to solve the problem. Similarly, keeping a
catalog of add-ons isn't in our scope either. This would be very
interesting to see AMO do though (pretty sure I mentioned this before).


>
>
> Plus, this is a great opportunity for new contributors to make their
> first edit.


Community members who know about add-ons are needed on AMO to leave reviews
and become editors. It would create an opportunity for people to make
edits, but I wouldn't say it's a great one.


I agree, some of these should have been caught during the audit for monkey
articles, or should at least have had sections flagged.


>
>
> I can understand getting rid of sections in articles called "Add-ons"
> that seem to just add icing on the cake of an article; but there are
> many instances where add-ons are presented as solutions to questions.

> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>

Lists of add-ons should be maintained by AMO. I definitely agree that it
would be very helpful to users to be able to see lists of add-ons that add
the specific feature they're looking for. AMO is the place for that though,
not SUMO. We have zero infrastructure in place for watching new add-ons,
extension authors would need to submit not only to AMO for approval and
maintain descriptions etc, but they'd need to start watching SUMO for any
articles that their extension applies to to make sure it's included in the
list. On top of that we don't have access to the ratings or reviews or
anything that helps users decide which on the list they want to install, or
if they even want to install it or just live without the feature.

This would be a really interesting partnership though. We could use our
stats to maintain a list of "most requested features" which is important for
dev already, and AMO could have pages that list the addons that add that
feature, which would then include the author's desired description, ratings,
reviews and download counts etc. Authors could then watch the list of
popular features on AMO and nominate their add-ons to be added to those
lists, where editors, who are already familiar with the add-ons could make
the call on whether it adds the functionality or not.

David Tenser

unread,
Sep 12, 2008, 3:51:03 PM9/12/08
to
Chris Ilias wrote:
> On 9/12/08 4:55 AM, _David Tenser_ spoke thusly:
>> Chris Ilias wrote:
>>> On 9/11/08 6:12 PM, _Majken Connor_ spoke thusly:
>>>> Who would be in charge of maintaining these lists against new add-on
>>>> submissions and approvals?
>>>
>>> Community. It's a wiki. :-)
>>
>> Let's not go there, for now. The risks of linking directly to add-ons
>> are clear and I think we create unnecessary problems for ourselves by
>> promoting them on SUMO.
>
> So far, I disagree. As I understand it, the risks are that the links
> will not be maintained; and that's no more of a risk than keeping any
> other part of the KB up to date. I fear that this effort to make the KB
> require the least maintenance possible is degrading the user experience.
>

It's not about requiring the least maintenance possible; it's about
drawing the line of what we support on SUMO and what we don't.

About the user experience: By linking directly to extensions, we create
a direct connection between the support article and the third-party
extension. If we get a user in the forum or live chat with a problem
with any of the extensions we're linking directly to, what is the level
of support we provide? The truth is, we'll instruct them to uninstall
that extension.

If we don't link directly to addons, we can still inform our users that
there is a plethora of them on AMO that will enable them to get new
functionality in Firefox. But rather than giving the impression that we
officially support them, we hand the user off to AMO (where it should be
clear about the support status for every extension).

David Tenser

unread,
Sep 12, 2008, 3:55:53 PM9/12/08
to
Wow, this thread is getting long.. :)

Majken Connor wrote:
> This would be a really interesting partnership though. We could use our
> stats to maintain a list of "most requested features" which is important for
> dev already, and AMO could have pages that list the addons that add that
> feature, which would then include the author's desired description, ratings,
> reviews and download counts etc. Authors could then watch the list of
> popular features on AMO and nominate their add-ons to be added to those
> lists, where editors, who are already familiar with the add-ons could make
> the call on whether it adds the functionality or not.

Yes, this is interesting. As the weekly "top issues" list is getting
more crystallized, this sounds like a wonderful addition that is
perfectly in line with our mission.

Cheng Wang

unread,
Sep 13, 2008, 5:54:47 PM9/13/08
to


Ok, I finally read all of this thread.

Basically I'm trying to figure out a system for categorizing our user inputs (livechat, forum, hendrix, #firefox, e-mails, letters, phone calls). One category I have is solvable by an existing add-on. I don't delve deeper and sub-sort this list (except people complaining about changes to the bookmark system/awesomebar are separate) but that may be a worthwhile exercise. I currently have no way of going back to see what I put into each category either which means I'd have to go back and resort everything.

Anyhow, I'd say that solvable by add-on isn't super common in the support channels. We get maybe a handful of requests a week and few single requests many times.

Based purely on anecdotal results, I'd say that the most common requests are: tab management, changing keyboard/mouse shortcuts or behavior, parental controls and filling in forms automatically.

chris hofmann

unread,
Sep 24, 2008, 10:34:15 PM9/24/08
to Planning how we can best support our users

Maybe just

Have question about Firefox?

or

Search for the answers you need.

but that would be redundant since we say "Search the Knowledge Base" as
part of the text again inside the orange search box. Maybe there is a
way to combine the question and the response inside the orange box and
get rid of the two lines altogether...

having only the top 3 articles out of the top ten list above the fold is
a definite inhibitor to easy navigation on the site.

There really seems to be a lot of redundancy that has grown on the page
over time.

Top nav bar "Support" looks a lot like the upper right hand "Support"
listing.

-chofmann


>> There is still lots of white space between the search box and lower
>> sections of the page.
>>
>
> We could do some minor pixel shaving which might get us another text row
> above the 600px fold, but I propose reordering the links in the New to
> Firefox box. The Installing Firefox article might be less important than
> Customizing Firefox, for example.
>
> Ken showed some pretty neat features in Omniture that labeled the
> different paths from the start page so you could clearly see what people
> clicked the most; let's get some of that metrics up for discussion.

Chris Ilias

unread,
Sep 29, 2008, 9:21:47 PM9/29/08
to
On 9/24/08 10:34 PM, _chris hofmann_ spoke thusly:

> Maybe just
>
> Have question about Firefox?
>
> or
>
> Search for the answers you need.
>
> but that would be redundant since we say "Search the Knowledge Base" as
> part of the text again inside the orange search box. Maybe there is a
> way to combine the question and the response inside the orange box and
> get rid of the two lines altogether...
>
> having only the top 3 articles out of the top ten list above the fold is
> a definite inhibitor to easy navigation on the site.
>
> There really seems to be a lot of redundancy that has grown on the page
> over time.
>
> Top nav bar "Support" looks a lot like the upper right hand "Support"
> listing.


Another interesting note about the front page is from Rob Campbell's
blog post
<http://antennasoft.net/robcee/2008/09/26/cannot-connect-after-upgrading-firefox-a-story/>.
He talks about pointing a user to support.mozilla.com, and the user says
"I don’t see my problem here". I asked Rob if the user had bothered to
use the search box, and he did not know. Are the links on the front page
detracting people from using Search? Would it be better if we just had
one link to "Browse" the KB?

Majken Connor

unread,
Sep 29, 2008, 10:07:06 PM9/29/08
to Planning how we can best support our users

> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>

We should be able to pull stats about what users do on the start page yes?
We should be able to compare percentages of people who leave the site, who
click on an article link and who actually search, yes?

chris hofmann

unread,
Sep 29, 2008, 10:09:20 PM9/29/08
to Planning how we can best support our users

yeah, in the original design of the home page I think we tried to spec out
a top 10 list followed buy a link to "see all the articles" which might
point to
a full listing sorted by popularity, alpha order, or directory like the old
http://kb.mozillazine.org/Category:Firefox

-chofmann

Chris Ilias

unread,
Oct 3, 2008, 12:03:39 AM10/3/08
to
On 9/29/08 10:07 PM, _Majken Connor_ spoke thusly:

> On Mon, Sep 29, 2008 at 9:21 PM, Chris Ilias <n...@ilias.ca> wrote:
>
>> Another interesting note about the front page is from Rob Campbell's
>> blog post
>> <http://antennasoft.net/robcee/2008/09/26/cannot-connect-after-upgrading-firefox-a-story/> .
>> He talks about pointing a user to support.mozilla.com, and the user says
>> "I don't see my problem here". I asked Rob if the user had bothered to
>> use the search box, and he did not know. Are the links on the front page
>> detracting people from using Search? Would it be better if we just had
>> one link to "Browse" the KB?
>
> We should be able to pull stats about what users do on the start page yes?
> We should be able to compare percentages of people who leave the site, who
> click on an article link and who actually search, yes?

These numbers are approximate:

43% exit the page
27% click on article links
24% search
2% go to Ask a question
2% go to the Forum
1% go to Other Firefox Support

Of course, those article clicks could be because we have the right
articles on the start page. :-)

chris hofmann

unread,
Oct 3, 2008, 12:48:29 AM10/3/08
to Planning how we can best support our users
good data.

to answer your question we just need to know if the top 10 articles make
up 80% or 90% of the article clicks, or are visits to the full list of
article clicks more of a long tail? also interesting to know is how
the search terms relate to visited articles. what pct. of search terms
result in click to the top 10 articles?

that kind of data would tell us if we currently need a site that is
optimized toward making easiest access to the top 10 issues, or if we
should try and optimize more toward finding the "needle in the haystack"
of many articles and giving users the tools to help do that. Where is
the right balance between these two strategies? Over time and release
schedules we may need strategies toward optimizing differently towards
different use patterns.

I wonder what would happen if we did a 1 or 2 day experiment to move the

[Browse all Knowledge Base topics]

link from being buried at the bottom of the page to a prominent link
just above or under the search box.

We also really need to figure out how to drive that exit number lower.
Maybe that will turn out to be a number that makes sense, but right now
that looks to high to me and might be saying 43% are finding that site
is not useful or is confusing to them. The important content ending up
"below the fold" seems like a likey candidate for that possible high number.

Let's figure out some experiments that might have impact on that and
also figure out the right balance between surfacing top 10 v. top
100/200 issues.

-chofmann

David Tenser

unread,
Oct 3, 2008, 7:08:42 AM10/3/08
to
chris hofmann skrev:

> I wonder what would happen if we did a 1 or 2 day experiment to move the
>
> [Browse all Knowledge Base topics]
> link from being buried at the bottom of the page to a prominent link
> just above or under the search box.
>

What would you expect would happen that you want to verify by conducting
this test? Making more people aware that there are more articles in the
KB than what is listed in the top 10 list?

The browse link itself isn't particularly useful, so I'm not convinced
moving that up below the search box would produce a positive effect,
other than making the people that don't click think "ok, this list isn't
all there is -- maybe I should search."

> We also really need to figure out how to drive that exit number lower.
> Maybe that will turn out to be a number that makes sense, but right now
> that looks to high to me and might be saying 43% are finding that site
> is not useful or is confusing to them. The important content ending up
> "below the fold" seems like a likey candidate for that possible high
> number.

Yes, we need to figure out how to get that bounce rate down. How can we
do that? I'm going to talk to Ken Kovash and Blake Cutler about it too.
A bounce rate of around 30% is not uncommon, but 43% is not where we
should be.

When looking at the top 40 Next Page links on the start page, it's
pretty clear to me that the KB articles people visit the most are the
ones we link to on that start page. This means that any link we put on
that page, whether it's above or under the fold, people click on it.
Case in point: the #3 most clicked article from the start page is
"Common issues fixed in Firefox 3," which is at the bottom of the top 10
list, well below the fold.

What this data doesn't tell is whether or not those articles are indeed
what the user was looking for when visiting SUMO. What we do know is
that the ones that are there are clicked on the most. This significantly
skews the data we're gathering for the KB. For example, the article most
commonly voted Yes on the poll "Did this article solve a problem you had
with Firefox" is "For Internet Explorer users," an article explaining
that Bookmarks means Favorites! This is of course just because it's
linked to directly from the Help menu of Firefox on Windows. Just for
the record, we already take this into consideration when determining
which are our most common problems in Firefox, but it's definitely worth
mentioning it in this discussion.

Another thing that would be interesting to find out is how the search
ratio and bounce rate would change if we removed the top issues and new
to Firefox lists altogether and replaced it with a simple paragraph
below the search box encouraging them to search for their problem --
effectively forcing people to search. However, we couldn't do that until
we've replaced the search engine with something that actually works well
(which is in the plans for SUMO 0.8 and is a SUMO Q4 development goal).


1. Exited Site 13,265 45.4%
2. tiki-searchresults.php 7,010 24.0%
3. en-US/kb/Installing+Firefox 1,484 5.1%
4. en-US/kb/Using+Firefox 618 2.1%
5. en-US/kb/Common+issues+fixed+in+Firefox+3 609 2.1%
6. en-US/kb/Ask+a+question 502 1.7%
7. en-US/kb/Customizing+Firefox+with+add-ons 495 1.7%
8. en-US/kb/Support+Website+Forums 486 1.7%
9. en-US/kb/Clearing+Location+bar+history 464 1.6%
10. en-US/kb 451 1.5%
11.
en-US/kb/Bookmarks+and+toolbar+buttons+not+working+after+upgrading
427 1.5%
12. en-US/kb/Firefox+is+already+running+but+is+not+responding 413 1.4%
13. en-US/kb/Other+Firefox+support 358 1.2%
14. en-US/kb/Is+my+Firefox+problem+a+result+of+malware 295 1.0%
15. tiki-login_scr.php 222 0.8%
16. tiki-wiki_rankings.php 190 0.7%
17. de/kb/Firefox%20Support-Startseite 131 0.4%
18. en-US/kb/Firefox+will+not+start 123 0.4%
19.
ru/kb/%D0%94%D0%BE%D0%BC%D0%B0%D1%88%D0%BD%D1%8F%D1%8F%20%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%
112 0.4%
20. tiki-view_forum_thread.php 107 0.4%
21. fr/kb/Assistance%20pour%20Firefox%20-%20Accueil 104 0.4%
22. en-US/kb/Cannot+use+or+save+passwords+after+upgrading+Firefox
99 0.3%
23. en-US/kb/Firefox+Help 93 0.3%
24.
en-US/kb/Toolbars+and+page+content+appear+too+large+after+upgrading+to+Firefox+3
82 0.3%
25. en-US/kb/How+to+contribute 77 0.3%
26. en-US/forum 52 0.2%
27. it/kb/Supporto%20a%20Firefox%20-%20Pagina%20iniziale 35 0.1%
28. tiki-error.php 33 0.1%
29. sk/kb/Domovsk%C3%A1%20str%C3%A1nka%20podpory%20Firefoxu 33 0.1%
30. pl/kb/Wsparcie%20dla%20Firefoksa%20-%20Strona%20domowa 28 0.1%
31. de/kb/Firefox+Help 25 0.1%
32. es/kb/Asistencia%20de%20Firefox%20-%20P%C3%A1gina%20principal
25 0.1%
33. pt-BR/kb/Suporte%20do%20Firefox%20-%20P%C3%A1gina%20inicial 25 0.1%
34. en-US/kb/Options+window 24 0.1%
35. en-US/kb/For+Internet+Explorer+Users 23 0.1%
36. de/kb 23 0.1%
37. en-US/kb/Installing+Firefox+on+Linux 22 0.1%
38. en-US/kb/Installing+Firefox+on+Windows 20 0.1%
39. tiki-user_preferences.php 17 0.1%
40. en-US/kb/Editing+configuration+files 17 0.1%

>
> Let's figure out some experiments that might have impact on that and
> also figure out the right balance between surfacing top 10 v. top
> 100/200 issues.


In order to correctly surface the top 10 articles, we probably need to
be looking at what people actually search for (KB article pages where
Previous Page was tiki-searchresults.php).

And maybe that top ten list should only be based on that metrics,
instead of being constantly boosted by the number of people that click
on the links just because they are already on the start page.

chris hofmann

unread,
Oct 3, 2008, 10:58:50 AM10/3/08
to Planning how we can best support our users

David Tenser wrote:
> chris hofmann skrev:
>
>> I wonder what would happen if we did a 1 or 2 day experiment to move the
>>
>> [Browse all Knowledge Base topics]
>> link from being buried at the bottom of the page to a prominent link
>> just above or under the search box.
>>
>>
>
> What would you expect would happen that you want to verify by conducting
> this test? Making more people aware that there are more articles in the
> KB than what is listed in the top 10 list?
>
>

yes. right now the pct. of useful information that might help people to
see the kind of content available on the site or helps them navigate to
an article is very low, and for the most part appears below the fold.
for the pct. of impatient people that quickly scanning the page they
don't see any kinds of lists of problems that they can latch on to.

the theory to be tested is that if we make that full article list easier
to access that that might drive down the exit number. people that don't
search, or don't know how to articulate their problem into search terms,
will have a page to go visually scan for something that sounds like
their problem.

right now it takes a lot of extra work scrolling and scanning past a lot
of redundant information to get to article lists for these kind of
"non-search" users of the site. many might be giving up and accounting
for the high exit rate.


> The browse link itself isn't particularly useful, so I'm not convinced
> moving that up below the search box would produce a positive effect,
> other than making the people that don't click think "ok, this list isn't
> all there is -- maybe I should search."
>
>

This breaks down if I'm not computer savy enough to describe my problem
easily so I can't figure out what search terms to write in. It's the
case like "I see all this stuff happening and I don't know whats going
on with my browser or how to control it. Help me! I'm in a panic!"
If you have every had interaction with someone without much computer
experience you are likely to have heard something just like that.
Next you tried to help them calm down, then you tried to look at what's
going on to figure out a solution and explain to them what is
happening. Its going to be hard for the site to provide that same kind
of vitural interaction as the real interaction describe above, but
giving people lists to scan is one step towards giving them information
they need to associate with the problem they see.

The problem right now is that when these kind of users hit the front
page and scan it, see only a search box they might just be giving up in
frustration and moving on to something else to try... (like trying to
find an e-mail address and sending mail to webmaster ;-)...


>> We also really need to figure out how to drive that exit number lower.
>> Maybe that will turn out to be a number that makes sense, but right now
>> that looks to high to me and might be saying 43% are finding that site
>> is not useful or is confusing to them. The important content ending up
>> "below the fold" seems like a likey candidate for that possible high
>> number.
>>
>
> Yes, we need to figure out how to get that bounce rate down. How can we
> do that? I'm going to talk to Ken Kovash and Blake Cutler about it too.
> A bounce rate of around 30% is not uncommon, but 43% is not where we
> should be.
>
> When looking at the top 40 Next Page links on the start page, it's
> pretty clear to me that the KB articles people visit the most are the
> ones we link to on that start page. This means that any link we put on
> that page, whether it's above or under the fold, people click on it.
> Case in point: the #3 most clicked article from the start page is
> "Common issues fixed in Firefox 3," which is at the bottom of the top 10
> list, well below the fold.
>
> What this data doesn't tell is whether or not those articles are indeed
> what the user was looking for when visiting SUMO.

Maybe it does... What it might tell us is that:

- 24% know how to describe their problem and search for the right article.
- 27% see a description of the problem in the top 10 list and follow
- 5% move on to other support systems that look like a better option
- 43% either were in the wrong place to begin with, or are bewildered
and don't see anything useful.

If your 30% exit rate number is a good target, that means at least 13%
are bewildered.

We can't do much more to raise the visibility of search on the page, but
we could start adding one or two more articles and make the full list of
articles more prominent to see if we can eat away at the 13% bewildered
number.


> What we do know is
> that the ones that are there are clicked on the most. This significantly
> skews the data we're gathering for the KB.

Maybe it skews the data, or maybe it just serves a pct. of users who hit
that problem, leaving the rest unserved.

Right. Its a combination of search terms *and* clicked-on-articles.
For some search is the way people will navigate the site; for others
with less computer literacy top 10, 20, 30, and full lists are the only
navigation paths that are viable options.

If we raise the visibility of those lists and see what get clicked on
out of that set of pages we will also get some good data on both kinds
of users....

-chofmann


> And maybe that top ten list should only be based on that metrics,
> instead of being constantly boosted by the number of people that click
> on the links just because they are already on the start page.
>

Majken Connor

unread,
Oct 3, 2008, 11:52:59 AM10/3/08
to Planning how we can best support our users
On Fri, Oct 3, 2008 at 10:58 AM, chris hofmann <chof...@meer.net> wrote:

>
>
> David Tenser wrote:
> > chris hofmann skrev:
> >
> >> I wonder what would happen if we did a 1 or 2 day experiment to move the
> >>
> >> [Browse all Knowledge Base topics]
> >> link from being buried at the bottom of the page to a prominent link
> >> just above or under the search box.
> >>
> >>
> >
> > What would you expect would happen that you want to verify by conducting
> > this test? Making more people aware that there are more articles in the
> > KB than what is listed in the top 10 list?
> >
> >

> yes. right now the pct. of useful information that might help people to
> see the kind of content available on the site or helps them navigate to
> an article is very low, and for the most part appears below the fold.
> for the pct. of impatient people that quickly scanning the page they
> don't see any kinds of lists of problems that they can latch on to.
>
> the theory to be tested is that if we make that full article list easier
> to access that that might drive down the exit number. people that don't
> search, or don't know how to articulate their problem into search terms,
> will have a page to go visually scan for something that sounds like
> their problem.
>
> right now it takes a lot of extra work scrolling and scanning past a lot
> of redundant information to get to article lists for these kind of
> "non-search" users of the site. many might be giving up and accounting
> for the high exit rate.

> > The browse link itself isn't particularly useful, so I'm not convinced
> > moving that up below the search box would produce a positive effect,
> > other than making the people that don't click think "ok, this list isn't
> > all there is -- maybe I should search."
> >
> >

> This breaks down if I'm not computer savy enough to describe my problem
> easily so I can't figure out what search terms to write in. It's the
> case like "I see all this stuff happening and I don't know whats going
> on with my browser or how to control it. Help me! I'm in a panic!"
> If you have every had interaction with someone without much computer
> experience you are likely to have heard something just like that.
> Next you tried to help them calm down, then you tried to look at what's
> going on to figure out a solution and explain to them what is
> happening. Its going to be hard for the site to provide that same kind
> of vitural interaction as the real interaction describe above, but
> giving people lists to scan is one step towards giving them information
> they need to associate with the problem they see.
>
> The problem right now is that when these kind of users hit the front
> page and scan it, see only a search box they might just be giving up in
> frustration and moving on to something else to try... (like trying to
> find an e-mail address and sending mail to webmaster ;-)...
>
>

> >> We also really need to figure out how to drive that exit number lower.
> >> Maybe that will turn out to be a number that makes sense, but right now
> >> that looks to high to me and might be saying 43% are finding that site
> >> is not useful or is confusing to them. The important content ending up
> >> "below the fold" seems like a likey candidate for that possible high
> >> number.
> >>
> >
> > Yes, we need to figure out how to get that bounce rate down. How can we
> > do that? I'm going to talk to Ken Kovash and Blake Cutler about it too.
> > A bounce rate of around 30% is not uncommon, but 43% is not where we
> > should be.
> >
> > When looking at the top 40 Next Page links on the start page, it's
> > pretty clear to me that the KB articles people visit the most are the
> > ones we link to on that start page. This means that any link we put on
> > that page, whether it's above or under the fold, people click on it.
> > Case in point: the #3 most clicked article from the start page is
> > "Common issues fixed in Firefox 3," which is at the bottom of the top 10
> > list, well below the fold.
> >
> > What this data doesn't tell is whether or not those articles are indeed
> > what the user was looking for when visiting SUMO.
>

> Maybe it does... What it might tell us is that:
>
> - 24% know how to describe their problem and search for the right article.
> - 27% see a description of the problem in the top 10 list and follow
> - 5% move on to other support systems that look like a better option
> - 43% either were in the wrong place to begin with, or are bewildered
> and don't see anything useful.
>
> If your 30% exit rate number is a good target, that means at least 13%
> are bewildered.
>
> We can't do much more to raise the visibility of search on the page, but
> we could start adding one or two more articles and make the full list of
> articles more prominent to see if we can eat away at the 13% bewildered
> number.
>
>

> > What we do know is
> > that the ones that are there are clicked on the most. This significantly
> > skews the data we're gathering for the KB.

> Maybe it skews the data, or maybe it just serves a pct. of users who hit
> that problem, leaving the rest unserved.

> Right. Its a combination of search terms *and* clicked-on-articles.
> For some search is the way people will navigate the site; for others
> with less computer literacy top 10, 20, 30, and full lists are the only
> navigation paths that are viable options.
>
> If we raise the visibility of those lists and see what get clicked on
> out of that set of pages we will also get some good data on both kinds
> of users....
>
> -chofmann

> > And maybe that top ten list should only be based on that metrics,
> > instead of being constantly boosted by the number of people that click
> > on the links just because they are already on the start page.
> >

> > _______________________________________________
> > support-planning mailing list
> > support-...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/support-planning
> >
> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>

I've been thinking about the tag search for a while, and I think it might
actually fit into the discussion about the problem we're trying to solve
here. We may want to put a list of common "keywords" (tags) back on the
front page, or a link "Not sure where to start? See a list of popular
keywords" to help users get started as well

The tag search has a few advantages:

1. People don't have to remember what things are called before they search,
they can see words that apply to their situation suggested to them and we
know those words will turn up articles

2. The tag search suggests useful other terms to help users narrow down
their results. Again users don't have to know beforehand what other terms
would help them find their answer, they can skim the list for keywords that
also apply to their situation.

I think this helps with the problem of helping people find other articles
besides the top 10 but gives them a more useful way to find it than showing
them just a plain list. Afterall, people will be skimming that list for
words that resemble their problem anyway, but by giving them the article
list they'll only get one useful result at a time.

0 new messages