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

Re-evaluating inproduct help for Firefox 3.1

3 views
Skip to first unread message

Chris Ilias

unread,
Oct 30, 2008, 3:18:35 AM10/30/08
to
_Background_
Between Firefox 2 and Firefox 3, help documentation was moved from the
Firefox source code to the Support web site, and the information in
those docs were updated to reflect changes in Firefox 3. The subject of
the content was not changed, nor was the structure.

_Going deeper_
Something I've been thinking about for quite a while now, is what kind
freedom we have with in-product help and the opportunity in Firefox 3.1.
Instead of simply updating the information in our set of 13 articles, we
can re-evaluate:
* What content should be covered in in-product help?
* Can we better organize the content in product help?

For example, some articles that would really be useful in product help are:
http://support.mozilla.com/kb/Live+Bookmarks
http://support.mozilla.com/kb/Navigation+Toolbar+items
http://support.mozilla.com/kb/Site+Identity+Button
http://support.mozilla.com/kb/Smart+Location+Bar

The Options Window article is probably our biggest and most complicated
article, already beyond our size limit for screenshots, without
screenshots for secondary option windows (e.g. Fonts, Advanced JS,
Languages, Warning messages, etc.). It would be better if we split that
article up by panel.

"Live Bookmarks" in product help raises another question: Are there any
other good places for help-topic links? For instance, when a user sees
the web feed icon in the Location bar, and clicks on it, the drop-down
menu or feed preview page can have an item called "What is this?", and
link that to the Live Bookmarks tutorial.

On a greater level, why isn't the entire Knowledge Base the in-product
help? I assume the issue is localization, and insuring that certain
content is available in the user's native language.

I just want to get everyone's initial thoughts on the idea of
re-evaluating the content, structure, and size of in-product help. Is
this something we want to explore for Firefox 3.1? There are two issues
I can think of:
* Localization
* Inproduct articles cannot link to non-inproduct articles. (Perhaps we
can get around that with CSS trickery.)

Majken Connor

unread,
Oct 30, 2008, 1:14:04 PM10/30/08
to Planning how we can best support our users
On Thu, Oct 30, 2008 at 3:18 AM, Chris Ilias <n...@ilias.ca> wrote:

> _Background_
> Between Firefox 2 and Firefox 3, help documentation was moved from the
> Firefox source code to the Support web site, and the information in those
> docs were updated to reflect changes in Firefox 3. The subject of the
> content was not changed, nor was the structure.
>
> _Going deeper_
> Something I've been thinking about for quite a while now, is what kind
> freedom we have with in-product help and the opportunity in Firefox 3.1.
> Instead of simply updating the information in our set of 13 articles, we can
> re-evaluate:
> * What content should be covered in in-product help?
> * Can we better organize the content in product help?
>
> For example, some articles that would really be useful in product help are:
> http://support.mozilla.com/kb/Live+Bookmarks
> http://support.mozilla.com/kb/Navigation+Toolbar+items
> http://support.mozilla.com/kb/Site+Identity+Button
> http://support.mozilla.com/kb/Smart+Location+Bar
>
> The Options Window article is probably our biggest and most complicated
> article, already beyond our size limit for screenshots, without screenshots
> for secondary option windows (e.g. Fonts, Advanced JS, Languages, Warning
> messages, etc.). It would be better if we split that article up by panel.


I agree. We could do some cool things to make sure the articles all link
back to each other so that a user can go through the different panels
without having to keep going back to the original options window article to
switch between panels.

"Live Bookmarks" in product help raises another question: Are there any
> other good places for help-topic links? For instance, when a user sees the
> web feed icon in the Location bar, and clicks on it, the drop-down menu or
> feed preview page can have an item called "What is this?", and link that to
> the Live Bookmarks tutorial.


In theory everything that can be clicked on could have a Help context menu
option that links to a related article. This might be overkill, but I think
we should at least be able to look at our stats and see which features
people are having to research. Those would be good ones to figure out how to
incorporate into the browser, if possible.


>
>
> On a greater level, why isn't the entire Knowledge Base the in-product
> help? I assume the issue is localization, and insuring that certain content
> is available in the user's native language.


I agree here. I'm a little fuzzy on why this hasn't been the case, but I do
believe that the idea was to present the users with a consistent set of
documents in their locale, however I think we're missing some pieces with
regards to tying these consistent articles in with the supporting articles
that aren't "in-product"

I just want to get everyone's initial thoughts on the idea of re-evaluating
> the content, structure, and size of in-product help. Is this something we
> want to explore for Firefox 3.1? There are two issues I can think of:
> * Localization
> * Inproduct articles cannot link to non-inproduct articles. (Perhaps we can
> get around that with CSS trickery.)


I think if we do this correctly we should be able to link outside of the in
product area. We just need to let people know up front that these are a
different class of article and may not be available in their language.

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

David Tenser

unread,
Oct 30, 2008, 4:36:28 PM10/30/08
to
Majken Connor skrev:

> On Thu, Oct 30, 2008 at 3:18 AM, Chris Ilias <n...@ilias.ca> wrote:
>
>> _Background_
>> Between Firefox 2 and Firefox 3, help documentation was moved from the
>> Firefox source code to the Support web site, and the information in those
>> docs were updated to reflect changes in Firefox 3. The subject of the
>> content was not changed, nor was the structure.
>>
>> _Going deeper_
>> Something I've been thinking about for quite a while now, is what kind
>> freedom we have with in-product help and the opportunity in Firefox 3.1.
>> Instead of simply updating the information in our set of 13 articles, we can
>> re-evaluate:
>> * What content should be covered in in-product help?
>> * Can we better organize the content in product help?

Good discussion, thanks for starting it.

I especially think the smart location bar article should be here. Is
navigation toolbar items really essential though?

I can also think of a number of articles that really aren't very
essential: Glossary and possibly Cookies (while cookies are important
for the web, that was more of a top feature of Firefox 1.0 as far as I
can remember, and there are far more interesting features to talk about
today).

>>
>> The Options Window article is probably our biggest and most complicated
>> article, already beyond our size limit for screenshots, without screenshots
>> for secondary option windows (e.g. Fonts, Advanced JS, Languages, Warning
>> messages, etc.). It would be better if we split that article up by panel.
>
>
> I agree. We could do some cool things to make sure the articles all link
> back to each other so that a user can go through the different panels
> without having to keep going back to the original options window article to
> switch between panels.

Splitting that article up sounds reasonable if it provides a benefit to
the reader. In this case, yes, a reduced loading time seems like one.

Please share the "cool things" to move the discussion forward. ;)

>
> "Live Bookmarks" in product help raises another question: Are there any
>> other good places for help-topic links? For instance, when a user sees the
>> web feed icon in the Location bar, and clicks on it, the drop-down menu or
>> feed preview page can have an item called "What is this?", and link that to
>> the Live Bookmarks tutorial.
>
>
> In theory everything that can be clicked on could have a Help context menu
> option that links to a related article. This might be overkill, but I think
> we should at least be able to look at our stats and see which features
> people are having to research. Those would be good ones to figure out how to
> incorporate into the browser, if possible.

Context menus aren't really used by many people, so I'm not sure if
adding help context menus would really be helpful to people.

What we definitely should be doing, though, is adding _visible_ links to
support where appropriate. Some examples of places that might be
appropriate:

* on a future New Tab page (learn more about tabbed browsing)
* on the Add-ons window (learn more about add-ons)

>
>
>>
>> On a greater level, why isn't the entire Knowledge Base the in-product
>> help? I assume the issue is localization, and insuring that certain content
>> is available in the user's native language.
>
>
> I agree here. I'm a little fuzzy on why this hasn't been the case, but I do
> believe that the idea was to present the users with a consistent set of
> documents in their locale, however I think we're missing some pieces with
> regards to tying these consistent articles in with the supporting articles
> that aren't "in-product"

The main reason for having "in-product" help is to classify a subset of
the KB (really a "Firefox manual") a higher localization prio to ensure
we have at least that content localized before we deem a locale l10n
complete. This is an ongoing discussion with the l10n lead to figure out
how we formally make this a requirement for localization teams, but I
absolutely think we need to bring SUMO into the core l10n requirements,
and obviously the whole KB can't be the requirement.

A possible way to communicate this with l10n teams is to say that we
have three main localization priorities:

prio 1: product help -- essential stuff for using firefox
prio 2: top support articles -- our most common support requests
prio 3: everything else

This could of course be broken down into even greater detail, but I
think it's important that we communicate clearly to localizers what
their primary focus should be so we don't overwhelm them with stuff to do.

Axel Hecht

unread,
Oct 30, 2008, 7:17:47 PM10/30/08
to

I personally happen to disagree.

We have a grand tug of war between everybody's own piece of mozilla and
our localization community, where each group makes up their list of
important stuff and not-so. Just the "really important" piece of each is
totally overwhelming for our community, not to speak about new
localizations starting.

We traditionally made the cut of what's required on the side of "no,
help is not required", and with all the new tasks emerging, I'm not sure
that making it block would be the obvious way to go.

Axel

David Tenser

unread,
Oct 31, 2008, 2:17:18 PM10/31/08
to
Axel Hecht skrev:

I understand that traditionally, the position has been that "no, help is
not required." However, I would argue that we're in a different position
today with Firefox now targeting the types of end-users that sometimes
don't even know what a browser is (and an overwhelming number of them, I
might add!). If we want to take Firefox retention seriously, a set of
support articles should absolutely be included in my opinion. Exactly
which articles is another matter of course, but given the prios above,
I'd say prio 1 should be part of our requirements.

Again, just my personal opinion. This is why we're having the
discussion, to reach consensus. :)

Cheng Wang

unread,
Oct 31, 2008, 4:26:40 PM10/31/08
to

Ok, I understand that the concern is with getting enough localizers for the sheer volume of translation that may be needed. I agree that we simply can't block release because of lack of inproduct documentation in a certain locale. At the same time, it's good to be able to have as much localized documentation as possible and to do that we should be working more closely with the various communities.

This is probably something we need to decide on a per-locale basis. I think we should make it clear to our localization communities that this is a goal for us and it will improve user experience in their locale. I also think we should really advertise the support that we'll be providing to /localizers/, especially new localizers so that the task isn't something we just dump on them and then abandon. The message we should be promoting is that this is a goal for us: to have support documentation in all languages. Therefore, it's not just a task we're handing off, it's something that we'll be helping with every step of the way. We'll help with getting more users, help with training, help with connecting community members with questions to people with answers. What we absolutely do NOT want is for localization teams to feel like we just dumped a ton of pages into their to-do queue and gave them a hard deadline to meet it by or impose unnecessary pressure if it's unlikely th
at they'll reach the goal of having all in-product articles translated.

For locales that think that they can meet the goal, it may be a good idea to block just so everyone is on the same page and we have some pressure to get it done. For locales that may need more help, blocking is probably not the right incentive. We should instead go back and try to figure out what we can do to help those locales (recruit more users, advertise, have contests, help train) and then even if we don't get the localization done by release time, at least we'll have built a stronger community so it CAN get done quickly enough.

chris hofmann

unread,
Oct 31, 2008, 4:51:52 PM10/31/08
to Planning how we can best support our users

> A possible way to communicate this with l10n teams is to say that we
> have three main localization priorities:
>
> prio 1: product help -- essential stuff for using firefox
> prio 2: top support articles -- our most common support requests
> prio 3: everything else
>
> This could of course be broken down into even greater detail, but I
> think it's important that we communicate clearly to localizers what
> their primary focus should be so we don't overwhelm them with stuff to do.

The most positive thing that we can do here is to inform localization
teams about the impact that any one area can have in providing good
support....

I agree that the priority listing above might be the most "astetically"
appealing, but now that we have help on line we should have better data
on if that is the real top priority.

For en-US and other locals where we have SUMO content translated are we
seeing more page views on product help pages or top support articles?

Within product help what is the ranking on pages in that area? Those
are good questions that we should have answers to so we can communicate
which pages might have the most impact if translated. Is it posssible
to dig that data out?

-chofmann

Axel Hecht

unread,
Oct 31, 2008, 5:08:38 PM10/31/08
to

The metrics for this would be kinda orthogonal to the metrics Cheng did
previously, I'd say. I still keep a message in that thread marked as
unread, I wanted to follow up there still.

Axel

Axel Hecht

unread,
Oct 31, 2008, 5:23:51 PM10/31/08
to

I feel the pain of having to miss out on your presentation in Barcelona
right now. I read on planet that you'll upload the slides, I hope
that'll get me up to speed.

I'll refrain to go into too detailed thinking 'til then, because that's
probably just me getting all confused by my own assumptions on
localizing sumo.

Axel

Majken Connor

unread,
Oct 31, 2008, 5:40:07 PM10/31/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
>

I really agree with everything you've said here. There are so many active
communities in other locales that include support, we know there are people
out there. We need to make sure we're supporting them as well as we can in
all of the ways you listed. We also need to give them incentive, though, to
contribute to our project, not just theirs. We need to make it as easy as
possible for our info and data to be shifted back to their sites. I think
this goes back to what you're saying about not dumping projects on them, we
need to make sure the stats for the locales are easy to find and interpret.
I think we also need to make sure it feels like participation. Telling
everyone what we think is important is good for helping people know where to
start, but doesn't give people a chance to share their expertise. Perhaps we
should only set Prio 1 for all locales, and then let locale leaders choose
the set that's Prio 2 (with suggestions from us of course).

Chris Ilias

unread,
Nov 5, 2008, 12:36:33 PM11/5/08
to
On 10/31/08 4:51 PM, _chris hofmann_ spoke thusly:

> I agree that the priority listing above might be the most "astetically"
> appealing, but now that we have help on line we should have better data
> on if that is the real top priority.
> For en-US and other locals where we have SUMO content translated are we
> seeing more page views on product help pages or top support articles?
> Within product help what is the ranking on pages in that area? Those
> are good questions that we should have answers to so we can communicate
> which pages might have the most impact if translated. Is it posssible
> to dig that data out?


An interesting note: In October, around 65% of *all* support.mozilla.com
traffic was in-product start pages.

Top articles by page view in October:
01. Options+window *
02. For+Internet+Explorer+Users *
03. How+to+set+the+home+page
04. Profiles
05. Using+Firefox *
06. Keyboard+shortcuts *
07. Installing+Firefox
08. Clearing+Location+bar+history
09. Customizing+Firefox *
10. Pop-up+blocker *

(*) denotes an in-product article
Also interesting is the drop in percentage between 2 and 3. 1 and are
0.9% and 0.8%. 3 is 0.3%.
'Options window' and 'For IE users' are special because there are links
directly from Firefox to those articles. Whereas other in-product
articles are linked to from other in-product articles.

So, either users are not bothering to navigate to other in-product help
articles after arriving, or they're using the search box.
(Which would help explain why "bookmarks" is such a popular search term,
even though it's so generic.)

Chris Ilias

unread,
Nov 5, 2008, 2:44:43 PM11/5/08
to
On 10/30/08 4:36 PM, _David Tenser_ spoke thusly:

> What we definitely should be doing, though, is adding _visible_ links to
> support where appropriate. Some examples of places that might be
> appropriate:
>
> * on a future New Tab page (learn more about tabbed browsing)
> * on the Add-ons window (learn more about add-ons)

One thing we should find out, given that Firefox 3.1 is frozen for Beta
2, is whether or not it is too late to consider additional help-topic
links. If it isn't too late, what's the deadline.

Axel Hecht

unread,
Nov 5, 2008, 8:18:03 PM11/5/08
to

I guess we're past that deadline. Adding help pointers is requiring a
visual hint, and thus, is probably going to affect things like dialog
sizes, or requires strings to be added.

Any of those break string freeze, and would require bugs that are
blocking+. I'd argue that now is not the time to add to that list.

Axel

David Tenser

unread,
Nov 6, 2008, 9:05:48 AM11/6/08
to
Cheng Wang skrev:


This makes a lot of sense.

For the record, I didn't mean that the lack of product help should block
a release -- what I meant was that the locale would not have a
"final/complete" status, but e.g. something like "beta". We would still
release it, but we would simply take support documentation into account
when determining the completeness of a localization. I don't think
blocking a release is ever the right incentive, regardless of a
community's willingness to do the hard work.

I can understand the concerns of sending out a message to l10n
communities that "your work is not done until you've also done xyz." We
should think of ways to communicate the importance of good support
contents without adding additional requirements to their already
overwhelming amount of work.

Yes, documentation is a goal for us, but the real impact benefits
everyone, including of course our users, but also support contributors
around the world.

Cheng, I think you're spot on about communicating closely with
localizers about this and ensuring that we do what we can to assist.
This is definitely something we should keep working hard on.

Axel Hecht

unread,
Nov 6, 2008, 11:07:49 AM11/6/08
to

I don't think so at all. Requiring for those that can and not requiring
for those that can't is just going to make people say that they can't.

> For the record, I didn't mean that the lack of product help should block
> a release -- what I meant was that the locale would not have a
> "final/complete" status, but e.g. something like "beta". We would still
> release it, but we would simply take support documentation into account
> when determining the completeness of a localization. I don't think
> blocking a release is ever the right incentive, regardless of a
> community's willingness to do the hard work.
>
> I can understand the concerns of sending out a message to l10n
> communities that "your work is not done until you've also done xyz." We
> should think of ways to communicate the importance of good support
> contents without adding additional requirements to their already
> overwhelming amount of work.
>
> Yes, documentation is a goal for us, but the real impact benefits
> everyone, including of course our users, but also support contributors
> around the world.
>
> Cheng, I think you're spot on about communicating closely with
> localizers about this and ensuring that we do what we can to assist.
> This is definitely something we should keep working hard on.

Right now, the l10n plan for SUMO seems to be
https://wiki.mozilla.org/Support/l10n. Well, I guess not.

It is really hard for me to discuss localizing sumo without any real
information to base my thinking on.

Forgive to just dump my uneducated thinking. It doesn't seem like a good
compromise to wait for videos of BCN or slides to see if those are
already covered. From what I see so far, SUMO as a support offering is
not localizable. Chat isn't, the forum isn't. The knowledge base is,
though it's unclear what of that is popular. Let alone popular for a
particular language. I don't understand how SUMO integrates with
community sites and communities spanning more products than just firefox.

I really need to understand how this currently works, and how it's
supposed to work before I can make an educated comment on the value of
localizing SUMO in the picture at large.

Axel

Majken Connor

unread,
Nov 6, 2008, 12:38:47 PM11/6/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
>

Chat and the forums should be very easy to add support in other locales to.
They need other things in place, though, before they can be successful (like
fairly solid kb documentation, and performance improvements in some areas)
and they're a whole different type of work from translating. I think what
you're saying though is that you can't just go through and translate forum
threads and chat transcripts (nor would you want to, I don't think).

I think the end goal isn't that SUMO translation would be covered by the
Firefox locale teams primarily. I believe what we really want is for support
communities for each locale to develop. That's a bit of a catch 22 though in
the sense that we need good support documentation to attract new helpers,
and we need new helpers to translate the documents. We also do have the
question of how we want to handle forum/chat support for locales that
already have thriving communities. How do those communities see themselves
working with us? What do they want to get out of it?

I think what we really need out of the current set of localizers is for them
to be our leaders, they know the terminology and how we do things, but we
really need to help them get to the position of approvers within SUMO rather
than translators themselves. I think to grow different locale communities
within SUMO we'll need to open up either forums or live chat to different
languages. I'd recommend focusing on the forums first, of course, as live
chat needs a really solid team and regular hours to be successful.

I think I've tangented from what you were originally raising though. Of
course this is somewhat of a tangent of the original topic anyway.

In terms of 3.1 I don't think we really can change much of the process, but
I do think we should sit down with dev and do a reevaluation of what
articles count as in product. One of the benefits of being web based was
that we could do this and there are new features that we have articles for
already. We do, though, need to be sensitive to localizers and make sure we
don't completely change up the list from release to release. We also have
leeway in terms of not being bound to the dev string freeze, and we have the
upcoming SFD where we could focus on translating the new in product
articles.

David Tenser

unread,
Nov 6, 2008, 5:38:32 PM11/6/08
to
Axel Hecht skrev:

I said myself (see below) that I don't think that's a good idea either.
What I think makes a lot of sense in what Cheng said above is that we
need to make it clear why this is important for us and our users, and
communicate more closely with l10n communities and generally assist in
any way we can.

The priorities for l10n communities should be clear.

>> I don't
>> think blocking a release is ever the right incentive, regardless of a
>> community's willingness to do the hard work.

Those were my words. :)

>>
>> I can understand the concerns of sending out a message to l10n
>> communities that "your work is not done until you've also done xyz."
>> We should think of ways to communicate the importance of good support
>> contents without adding additional requirements to their already
>> overwhelming amount of work.
>>
>> Yes, documentation is a goal for us, but the real impact benefits
>> everyone, including of course our users, but also support contributors
>> around the world.
>>
>> Cheng, I think you're spot on about communicating closely with
>> localizers about this and ensuring that we do what we can to assist.
>> This is definitely something we should keep working hard on.
>
> Right now, the l10n plan for SUMO seems to be
> https://wiki.mozilla.org/Support/l10n. Well, I guess not.

Where did you find that old, obsolete page? :) It was meant as an
initial planning page for moving stuff from Fx2 in-product help to the KB...

>
> It is really hard for me to discuss localizing sumo without any real
> information to base my thinking on.
>
> Forgive to just dump my uneducated thinking. It doesn't seem like a good
> compromise to wait for videos of BCN or slides to see if those are
> already covered. From what I see so far, SUMO as a support offering is
> not localizable. Chat isn't, the forum isn't. The knowledge base is,
> though it's unclear what of that is popular. Let alone popular for a
> particular language. I don't understand how SUMO integrates with
> community sites and communities spanning more products than just firefox.
>
> I really need to understand how this currently works, and how it's
> supposed to work before I can make an educated comment on the value of
> localizing SUMO in the picture at large.

Man, that SUMO session at MozCamp was custom made for you, and you
missed it. ;) SUMO is a localizable project, but we need to work
together with our local communities. For example, rather than offering a
German forum on SUMO, it's a better idea to link to
http://www.firefox-browser.de/forum/.

Let's get you up to date. I'll contact you privately so we can set up a
meeting to get us on the same page.

Chris Ilias

unread,
Nov 7, 2008, 12:18:43 AM11/7/08
to
On 11/5/08 12:36 PM, _Chris Ilias_ spoke thusly:

> An interesting note: In October, around 65% of *all* support.mozilla.com
> traffic was in-product start pages.
>
> Top articles by page view in October:
> 01. Options+window *
> 02. For+Internet+Explorer+Users *
> 03. How+to+set+the+home+page
> 04. Profiles
> 05. Using+Firefox *
> 06. Keyboard+shortcuts *
> 07. Installing+Firefox
> 08. Clearing+Location+bar+history
> 09. Customizing+Firefox *
> 10. Pop-up+blocker *
>
> (*) denotes an in-product article
> Also interesting is the drop in percentage between 2 and 3. 1 and are
> 0.9% and 0.8%. 3 is 0.3%.
> 'Options window' and 'For IE users' are special because there are links
> directly from Firefox to those articles. Whereas other in-product
> articles are linked to from other in-product articles.
>
> So, either users are not bothering to navigate to other in-product help
> articles after arriving, or they're using the search box.
> (Which would help explain why "bookmarks" is such a popular search term,
> even though it's so generic.)

Exit data on the en-US inproduct start page for October:
78% Exit the site
16% search
The rest are article links and others (e.g. Ask a question, log-in),
starting at 0.6% and going down from there.

Majken Connor

unread,
Nov 7, 2008, 3:25:08 PM11/7/08
to Planning how we can best support our users
On Fri, Nov 7, 2008 at 12:18 AM, Chris Ilias <n...@ilias.ca> wrote:

> On 11/5/08 12:36 PM, _Chris Ilias_ spoke thusly:
>

>> An interesting note: In October, around 65% of *all* support.mozilla.comtraffic was in-product start pages.

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

These will be interesting stats to interpret. FWIW my cats step on F1 all
the time. I haven't used in product help once, so 100% of my visits to the
page were unintentional and so of course I exited from the start page. I
wonder what percentage of exits are the same type of accidental loading of
help. Do we have any leeway in how we look at the numbers? For instance can
we see what percentage of users have visited help more than once but always
exit without going anywhere?

Bug 406646 might be at play for a small percentage as well.

Chris Ilias

unread,
Nov 11, 2008, 10:38:05 PM11/11/08
to
On 11/6/08 5:38 PM, _David Tenser_ spoke thusly:

> Let's get you up to date. I'll contact you privately so we can set up a
> meeting to get us on the same page.

So, have you guys talked about it yet?
I'm a little unclear on what the disagreement is. Is any part of help
documentation a release blocker (for each specific locale)?

Axel Hecht

unread,
Nov 13, 2008, 12:48:44 PM11/13/08
to

We didn't make that a topic of our call, but I think the general
understanding was that introducing requirements is likely wrong approach
to creating a local sumo community. Making sure that links like
http://support.mozilla.com/1/firefox/3.0.3/Darwin/si/prefs-security
actually end up inviting collaborators in a understandable way was more
like it. Other discussions in this group on how to help building
communities and ask for help should help, too. Another item was to make
open items for translation easily discoverable, and to figure out a
system that actually gives some reward to contributors, for example
something like "500 users saw Chris' translations this week" or similar
metrics that help to get some cooptetion going.

Apart from the "everybody wants sumo to have less bugs and better speed".

Axel

Chris Ilias

unread,
Nov 19, 2008, 12:04:03 AM11/19/08
to
On 10/30/08 3:18 AM, _Chris Ilias_ spoke thusly:

> I just want to get everyone's initial thoughts on the idea of
> re-evaluating the content, structure, and size of in-product help. Is
> this something we want to explore for Firefox 3.1? There are two issues
> I can think of:
> * Localization
> * Inproduct articles cannot link to non-inproduct articles. (Perhaps we
> can get around that with CSS trickery.)

Given the stats and discussion, I'd like to bring the discussion back to
inproduct help, and what improvements can be made. Here are what changes
I would like to see made:

* In-product mode should be applicable to all KB articles, and the
search results page. Given that more people are searching inproduct
help, rather than navigating the links; and they're arriving at arriving
at articles not considered part of inproduct help, the look of the web
site is inconsistent.

* Do not designate a set of articles as inproduct help. The entire KB is
already available via search from within inproduct help.

* Take advantage of the traffic on the inproduct start page, to help
address the issues we are hearing about from users. For instance:
- A lot of users are confused about the new Bookmarks system; so we can
showcase the Bookmarks tutorial on the front page, with a heading saying
"Learn about the new Bookmarks system".
- A lot of users are also confused about the Smart Location Bar, so we
can also showcase the SMB tutorial; and even have small screenshots, so
users unfamiliar with the terminology can still identify what the linked
tutorial is about. Something like
<http://www.mozilla.com/en-US/firefox/tips/>.
- When Firefox 3.1 is released, the start page can showcase a tutorial
on how to use new Firefox 3.1 features, like Private Browsing.

Axel Hecht

unread,
Nov 19, 2008, 5:07:47 AM11/19/08
to


Let me ask the other way around, why does the inproduct mode look the
way it does?

I think that a split of the Options window page is really pressing.

How popular are which entry points for in-product help? Having a matrix
for all entry points and all locales sounds like a good start. Something
like

all af ar ....

all 100% 5% 5% ....
main 43% 20% 50% ....
pref/foo ...

where the first column is adding all locales, giving us the popularity
of pages across all locales, and the first row is giving us the
popularity of inproduct help in that locale.

The percentages per page/per locale should be relative to the total hits
of the locale, i.e., the sum of all individual page percentages over a
single locale should give 100.

Yes, this is slightly skewed, but I would figure that this is the
representation that's most likely to show interesting aspects.


Once we know how people come in, we can actually think about
navigational aspects.

I think we should keep the help articles in a particular bucket, just
because I think those need to be written in a different style than for
example a troubleshooting article, or possibly even as a tutorial. It
might make sense to create new help pages from popular tutorials,
though, I guess.

Axel

David Tenser

unread,
Nov 19, 2008, 5:34:45 AM11/19/08
to
Axel Hecht skrev:

If you mean visually, it has a simplified topnav and footer to be
consistent with the rest of the in-product pages, e.g. the firstrun and
whatsnew pages.

If you mean why exactly these 14 articles were chosen as the in-product
help, it's really for historical reasons, as these were the ones we
imported from Firefox 2.

>
> I think that a split of the Options window page is really pressing.

Yes, I agree. I think most people agree this is a good idea, but let's
point out the reasons:

* the article is huge
- incredible work to localize
- heavy on images / load time
* when navigating to a specific pane/anchor, the "article not
translated" notification is missed since it's only showing at the top of
the page. splitting up the article would make sure all panes have a
notification for localizers.

>
> How popular are which entry points for in-product help? Having a matrix
> for all entry points and all locales sounds like a good start. Something
> like
>
> all af ar ....
>
> all 100% 5% 5% ....
> main 43% 20% 50% ....
> pref/foo ...
>
> where the first column is adding all locales, giving us the popularity
> of pages across all locales, and the first row is giving us the
> popularity of inproduct help in that locale.
>

Yes, this would be interesting to get data on. That said, I only really
care about "all" here, not the various locales. I'd be very surprised if
there a significant difference in distribution between various locales.


> The percentages per page/per locale should be relative to the total hits
> of the locale, i.e., the sum of all individual page percentages over a
> single locale should give 100.
>
> Yes, this is slightly skewed, but I would figure that this is the
> representation that's most likely to show interesting aspects.
>
>
> Once we know how people come in, we can actually think about
> navigational aspects.
>
> I think we should keep the help articles in a particular bucket, just
> because I think those need to be written in a different style than for
> example a troubleshooting article, or possibly even as a tutorial. It
> might make sense to create new help pages from popular tutorials,
> though, I guess.


As a priority for localizers helping out with SUMO, here's one more
long-term proposal:

1. UI, using verbatim -- could be done by the regular l10n teams
2. start page(s)
3. product help, but only the absolute necessary ones:
- options panes
- page info window
- keyboard shortcuts
- for internet explorer users
4. remainder of KB, with clear hints about which articles
are most important, backed up with metrics about page
hits and/or popularity


Thoughts?

Axel Hecht

unread,
Nov 19, 2008, 7:01:46 AM11/19/08
to

I noticed that the search box is taking way more screen estate than in
the regular layout. This isn't so obvious on the index pages, but if we
split the options window, that might become an issue.

> If you mean why exactly these 14 articles were chosen as the in-product
> help, it's really for historical reasons, as these were the ones we
> imported from Firefox 2.

Well, I wouldn't put it that way. The reasons are only partly
historical, the real reason for those being in one group is that they
have hooks in the UI that lead to them. Some hidden, in particular, page
info is only available if you know that you can press F1 there, while
the pref dialogs have help buttons.

>> I think that a split of the Options window page is really pressing.
>
> Yes, I agree. I think most people agree this is a good idea, but let's
> point out the reasons:
>
> * the article is huge
> - incredible work to localize
> - heavy on images / load time
> * when navigating to a specific pane/anchor, the "article not
> translated" notification is missed since it's only showing at the top of
> the page. splitting up the article would make sure all panes have a
> notification for localizers.

I saw that the page info page is linked to with anchors, too. But from
the size of the page, I think it's ok to leave that as is. I expect that
page to be really low on our hit rates, too.

Do we have a plan on how to distinguish the user-facing strings from the
rest?

> 2. start page(s)
> 3. product help, but only the absolute necessary ones:
> - options panes
> - page info window
> - keyboard shortcuts
> - for internet explorer users
> 4. remainder of KB, with clear hints about which articles
> are most important, backed up with metrics about page
> hits and/or popularity

I'd slam 3 and 4 together. As indicated above, I don't expect page info
for example to raise above the noise, while some KB-only articles sure will.

Axel

David Tenser

unread,
Nov 19, 2008, 12:38:24 PM11/19/08
to Axel Hecht
Axel Hecht skrev:

Aside from Options window and Page Info window, are there any other
hooks? I thought those were the only two. So yes, those two have valid
reasons to exist, but the other stuff (e.g. Glossary) isn't really
critical for our users.

>> As a priority for localizers helping out with SUMO, here's one more
>> long-term proposal:
>>
>> 1. UI, using verbatim -- could be done by the regular l10n teams
>
> Do we have a plan on how to distinguish the user-facing strings from the
> rest?

Cleaning up language.php is bug 442916, targeted for the 0.8 release on
December 16. The plan is to remove stuff we don't use.

>
>> 2. start page(s)
>> 3. product help, but only the absolute necessary ones:
>> - options panes
>> - page info window
>> - keyboard shortcuts
>> - for internet explorer users
>> 4. remainder of KB, with clear hints about which articles
>> are most important, backed up with metrics about page
>> hits and/or popularity
>
> I'd slam 3 and 4 together. As indicated above, I don't expect page info
> for example to raise above the noise, while some KB-only articles sure
> will.

Yeah, I kind of like that idea too. It's really all about which articles
are actually read. The options window is definitely one of them. The
Page Info window one, not so much.

Chris Ilias

unread,
Nov 19, 2008, 9:47:12 PM11/19/08
to
On 11/19/08 7:01 AM, _Axel Hecht_ spoke thusly:

> David Tenser wrote:
>
>> If you mean visually, it has a simplified topnav and footer to be
>> consistent with the rest of the in-product pages, e.g. the firstrun
>> and whatsnew pages.
>
> I noticed that the search box is taking way more screen estate than in
> the regular layout. This isn't so obvious on the index pages, but if we
> split the options window, that might become an issue.

Thanks for pointing that out. The search box was moved to the sidebar
for KB articles [1]. We forgot to make that change to the inproduct mode
stylesheet. I've filed a bug [2].

[1]<https://bugzilla.mozilla.org/show_bug.cgi?id=442182>
[2]<https://bugzilla.mozilla.org/show_bug.cgi?id=465872>

>> If you mean why exactly these 14 articles were chosen as the
>> in-product help, it's really for historical reasons, as these were the
>> ones we imported from Firefox 2.
>
> Well, I wouldn't put it that way. The reasons are only partly
> historical, the real reason for those being in one group is that they
> have hooks in the UI that lead to them. Some hidden, in particular, page
> info is only available if you know that you can press F1 there, while
> the pref dialogs have help buttons.

With the exception of the start page, only three articles are
destinations for help-topic links.
* Options Window
* For Internet Explorer Users
* Page Info Window

See <https://bugzilla.mozilla.org/show_bug.cgi?id=414353#c16>.

The rest is just basic help documentation in the help viewer. (Unless we
have a broken help-topic link somewhere. =-O :-) )

David Tenser

unread,
Nov 20, 2008, 2:59:04 AM11/20/08
to
Chris Ilias skrev:

> On 11/19/08 7:01 AM, _Axel Hecht_ spoke thusly:
>> David Tenser wrote:
>>
>>> If you mean visually, it has a simplified topnav and footer to be
>>> consistent with the rest of the in-product pages, e.g. the firstrun
>>> and whatsnew pages.
>>
>> I noticed that the search box is taking way more screen estate than in
>> the regular layout. This isn't so obvious on the index pages, but if
>> we split the options window, that might become an issue.
>
> Thanks for pointing that out. The search box was moved to the sidebar
> for KB articles [1]. We forgot to make that change to the inproduct mode
> stylesheet. I've filed a bug [2].
>
> [1]<https://bugzilla.mozilla.org/show_bug.cgi?id=442182>
> [2]<https://bugzilla.mozilla.org/show_bug.cgi?id=465872>

Yes, good catch indeed. Thanks!

>
>>> If you mean why exactly these 14 articles were chosen as the
>>> in-product help, it's really for historical reasons, as these were
>>> the ones we imported from Firefox 2.
>>
>> Well, I wouldn't put it that way. The reasons are only partly
>> historical, the real reason for those being in one group is that they
>> have hooks in the UI that lead to them. Some hidden, in particular,
>> page info is only available if you know that you can press F1 there,
>> while the pref dialogs have help buttons.
>
> With the exception of the start page, only three articles are
> destinations for help-topic links.
> * Options Window
> * For Internet Explorer Users
> * Page Info Window
>
> See <https://bugzilla.mozilla.org/show_bug.cgi?id=414353#c16>.
>
> The rest is just basic help documentation in the help viewer. (Unless we
> have a broken help-topic link somewhere. =-O :-) )

This looks correct to me. And with 3.1, we'll get a fourth help link
with https://bugzilla.mozilla.org/show_bug.cgi?id=414715

David Tenser

unread,
Dec 1, 2008, 10:59:15 AM12/1/08
to
So, it's time to recap:

The feedback from localization teams is that the l10n process on SUMO is
overwhelming and that it's unclear where to start and what is actually
"required" to translate. A large part of the traditional set of
in-product articles were established before Firefox 1.0 was released,
and the content that actually is the most relevant for our users may or
may not be in that set.

In order to make the process simpler for localizers, and to ensure that
the content with the highest impact for our users are localized first,
let's figure out a sensible l10n priority so that the localization
process on SUMO doesn't feel overwhelming:

1. UI, using verbatim -- could be done by the regular l10n teams. Wil
Clouser is working on implementing support for SUMO/Verbatim as we
speak. See also https://bugzilla.mozilla.org/show_bug.cgi?id=442916.


2. start page(s) -- currently two pages:

- http://support.mozilla.com/kb/Firefox+Support+Home+Page
- http://support.mozilla.com/kb/Firefox+Help


3. List of KB articles ordered by priority (as determined by traffic,
vote scores, etc. in the same way as the Weekly Common Issues
(http://support.mozilla.com/en-US/kb/Weekly+common+issues). This
naturally includes some of the more important articles currently called
"in-product" including:

- options window


- keyboard shortcuts
- for internet explorer users


We would no longer maintain a set of articles called "in-product"
anymore; instead, the priority would be based on what is actually
important to our users.

Thoughts?

Chris Ilias

unread,
Dec 2, 2008, 10:29:11 PM12/2/08
to
On 12/1/08 10:59 AM, _David Tenser_ spoke thusly:

Just one: For non-English locales, Ask+a+Question gets more page views
than the web site start page. Maybe it would be better to include
Ask+a+Question in #2, or remove Firefox+Support+Home+Page from #2 and
replace it with Ask+a+Question.

David Tenser

unread,
Dec 3, 2008, 5:45:34 AM12/3/08
to
Chris Ilias skrev:


That makes sense; that page is equally important because it flows the
user through the support funnel, so it's essentially part of the UI
(although in this priority list it's indeed under #2).

Chris Ilias

unread,
Dec 3, 2008, 9:39:33 PM12/3/08
to
On 10/30/08 3:18 AM, _Chris Ilias_ spoke thusly:
> The Options Window article is probably our biggest and most complicated
> article, already beyond our size limit for screenshots, without
> screenshots for secondary option windows (e.g. Fonts, Advanced JS,
> Languages, Warning messages, etc.). It would be better if we split that
> article up by panel.

Another article that I would like to change is "Using Firefox".
<http://support.mozilla.com/en-US/kb/Using+Firefox>


It's a legacy article from the old in-product help, which covers many
subjects already covered in other KB articles:

* Making Firefox the default browser is already covered in
<http://support.mozilla.com/en-US/kb/How+To+Make+Firefox+The+Default+Browser>.

* Managing different file types is already covered in
<http://support.mozilla.com/en-US/kb/Managing+file+types>.

* Searching the web is covered in
<http://support.mozilla.com/en-US/kb/Search+bar>.

* Tabbed browsing is covered in
<http://support.mozilla.com/en-US/kb/Tabbed+browsing>.


Other than that, the title does really tell us what the article is
supposed to cover. Much of it seems to cover the very basics. Looking at
the rest of the content:

* Navigating web pages - "Viewing your home page", "Retracing your
steps", and "Stopping and reloading" seem like good info for a "Firefox
Basics" article. If the user has found this article, then it's logical
to assume the user already knows how to "Navigate to another page" or
"Clicking a link" (which are the second and third parts of that
section). If that content were to be included, there should be a
help-topic link pointing to it.

* Using the Sidebar - I don't see the usefulness of the content in that
section.

* Searching within a page - I think this would make a great separate
article. I think it's a common use-case, and a great chance to educate
users about FAYT.

* Copying part of a page - This one, I don't know about. I have no idea
if that's a common use-case.

* Saving all or part of a page - This could make for a good separate
article.

* Printing a page - This seems good for a separate article. There's
certainly enough content.

* Changing cache settings - IMO... monkey content.

Majken Connor

unread,
Dec 4, 2008, 12:22:56 AM12/4/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
>

This sounds like great content for a basic web education type article like
was mentioned in how SUMO can fit in the 2010 goals. I agree that most of
this stuff users already know how to do, and if they don't they're not going
to go looking for it in help.

We have the "New to Firefox" box, it'd be great if we had some articles that
were more like actual articles rather than documents. Like the top 10
extensions articles you'll see on digg. So we'd have an article called
"browsing basics" which would give brief descriptions and then link to these
other articles. Maybe we can do this with a tag even so other articles can
be added, and for ease of linking.

Probably not doing the best job of explaining, let me do a little mock up.

___Browsing Basics___

Here are some topics and articles that can help you get to know Firefox and
the web

_Navigating_

Here are some articles that will help you learn how to get around the web
using Firefox
link 1
link 2
link 3

_Saving and printing_

description of the type of links this section gives
link 1
link 2
link 3

etc.

Localizers could maintain their own versions and add links as the other
articles are translated, leaving out ones that haven't been as these types
of articles would be aggregates of others.

Mike Connor

unread,
Dec 4, 2008, 1:10:57 AM12/4/08
to Planning how we can best support our users

On 1-Dec-08, at 10:59 AM, David Tenser wrote:

> The feedback from localization teams is that the l10n process on SUMO
> is overwhelming and that it's unclear where to start and what is
> actually "required" to translate. A large part of the traditional set
> of in-product articles were established before Firefox 1.0 was
> released, and the content that actually is the most relevant for our
> users may or may not be in that set.

Is this all feedback from localizers, or just the first sentence? It
seems like its feedback, followed by a separate problem statement, so
I'm going to read it as that and go from there.

> In order to make the process simpler for localizers, and to ensure
> that the content with the highest impact for our users are localized
> first, let's figure out a sensible l10n priority so that the
> localization process on SUMO doesn't feel overwhelming:
>
> 1. UI, using verbatim -- could be done by the regular l10n teams. Wil
> Clouser is working on implementing support for SUMO/Verbatim as we
> speak. See also https://bugzilla.mozilla.org/show_bug.cgi?id=442916.
> 2. start page(s)

> 3. List of KB articles ordered by priority (as determined by traffic,
> vote scores, etc. in the same way as the Weekly Common Issues
> (http://support.mozilla.com/en-US/kb/Weekly+common+issues). This
> naturally includes some of the more important articles currently
> called "in-product" including:

So I think this doesn't actually solve the problem of knowing what is
"required" and what is "optional" here. Obviously, localizing the UI and
the start pages isn't enough to be useful. Nor do I think that a
handful of articles (i.e. less than 10) is likely to provide enough
information to have any meaningful impact on our goals. So what should
we require, and what should be optional?

Let's step back to first principles here. We believe that SUMO can and
should play an important role in improving user satisfaction with
Firefox and increasing the likelihood that they will continue to enjoy
and use the product. To get this benefit across locales, we should be
able to identify a standard set of articles (likely built from looking
at the stats you referenced) that represent a complete core translation
of SUMO. This core translation would represent the minimum set of
content that we believe necessary to make a real difference. If we
aren't going to get this baseline level of support, we probably
shouldn't waste localizer cycles on any of it, since we should spend our
scarce resources only when there is a viable return on investment. I do
not think it would be dramatically hard to do some stat crunching and
broader analysis to establish what information needs to be part of this
corpus.

Earlier in the thread there was some opposition to requiring any of this
as part of translating Firefox. If we truly believe that SUMO is having
a meaningful impact, we should not shrink away from asking for this
baseline level of support, IMO. To do this right, of course, we should
have a crisp argument for why it is integral to future growth,
preferably with data backing up our assertions.

-- Mike

Axel Hecht

unread,
Dec 4, 2008, 5:59:48 AM12/4/08
to

I'm looking at this from the long tail of our localizations.

I could picture a very poor return of investment for those. I wouldn't
be surprised to see some locales hitting SUMO in the order of once a
week. It'd be interesting to have some numbers to back that claim up, of
course.

If I try to think about making a cut at which point SUMO is important, I
remember looking at ADU stats a while back, and I never saw a real cut
in those numbers, apart from the first 3 or 4. I don't really see a
migration path from small to non-small either.

You mentioned finding a clear cut in popularity of documents. I'd love
to see that, too. In particular if we can resolve this by locale, I
don't think that small user groups have the same problems as large user
groups, and it might very well depend on region, i.e., how "techie and
early adopter" people on the internet are in that region anyway.

I admit having a hard time seeing usage stats for English support docs
map to, say, Estonian, Hindi, Vietnamese, Occitan. Just to pick on a few
of our locales with small ADU counts.

I'd rather see us coming up with something that makes it easy to find
"the next good page to add to your localization on SUMO", than to go in
and say "we made some stats on US, German and France users, and you're
not doing anything useful until you have these pages done". "The next
good page" does sound like a much higher return of investment to me
(yes, I like that language).

Axel

Mike Connor

unread,
Dec 4, 2008, 6:22:03 AM12/4/08
to Planning how we can best support our users

Why are you focusing on the long tail here? That's the lowest likely
rate of return from serious time investment in SUMO. I'm much more
concerned with getting what we need for the top 8-10 strategic locales
than with getting SUMO in 62 locales.

> If I try to think about making a cut at which point SUMO is important,
> I remember looking at ADU stats a while back, and I never saw a real
> cut in those numbers, apart from the first 3 or 4. I don't really see
> a migration path from small to non-small either.

I think ADU matters for retention, and we should also be thinking
strategically about what locales we want to maximize retention/adoption
first, i.e. China comes to mind. When I looked at this a few months
back, I think I ended up with eight locales as my tier 1 for SUMO.

> You mentioned finding a clear cut in popularity of documents. I'd love
> to see that, too. In particular if we can resolve this by locale, I
> don't think that small user groups have the same problems as large
> user groups, and it might very well depend on region, i.e., how
> "techie and early adopter" people on the internet are in that region
> anyway.

How would we resolve this per-locale, other than guesswork? I think
that assertion is likely going to be false, in any case, as the highest
volume issues cut across consumer verticals. The techie/early adopter
issues are not our main priority with SUMO, so trying to account for
degree of early adopter presence won't really solve things.

> I admit having a hard time seeing usage stats for English support docs
> map to, say, Estonian, Hindi, Vietnamese, Occitan. Just to pick on a
> few of our locales with small ADU counts.

Again, I think you're focused on the wrong things here, and making
assumptions that issues differ across locales in a way that doesn't seem
based on any data, or even anecdotal evidence.

> I'd rather see us coming up with something that makes it easy to find
> "the next good page to add to your localization on SUMO", than to go
> in and say "we made some stats on US, German and France users, and
> you're not doing anything useful until you have these pages done".
> "The next good page" does sound like a much higher return of
> investment to me (yes, I like that language).

I do not think a mostly empty site is useful. I believe that there is a
critical mass of content that needs to be available to cover a
significant enough portion of the issues users commonly experience to
make the site effective. What that set is, and how big it is, is
largely TBD, but I feel confident in predicting that except for
translation bugs, most issues users report will be common across most
locales (i.e. the most common Fx2 bug was the Lost Bookmarks stuff,
which was entirely locale-independent.

-- Mike

Axel Hecht

unread,
Dec 4, 2008, 8:04:59 AM12/4/08
to

... which is based on as much data as my thinking?

I'm happy to take data to base my thinking upon, but I don't see it. I
have asked concrete questions before in either this thread or another
recently.

And yes, if you have a suggestion on how to do a tiers for SUMO, I'd be
happy to get that data as well.

Axel

David Tenser

unread,
Dec 4, 2008, 10:58:42 AM12/4/08
to
Axel Hecht skrev:

> Mike Connor wrote:
>> Axel Hecht wrote:
>>> Mike Connor wrote:
>>>>
>>>> On 1-Dec-08, at 10:59 AM, David Tenser wrote:
>>>>
>>>>> The feedback from localization teams is that the l10n process on
>>>>> SUMO is overwhelming and that it's unclear where to start and what
>>>>> is actually "required" to translate. A large part of the
>>>>> traditional set of in-product articles were established before
>>>>> Firefox 1.0 was released, and the content that actually is the most
>>>>> relevant for our users may or may not be in that set.
>>>>
>>>> Is this all feedback from localizers, or just the first sentence?
>>>> It seems like its feedback, followed by a separate problem
>>>> statement, so I'm going to read it as that and go from there.
>>>>

Right you are.

>>>>> In order to make the process simpler for localizers, and to ensure
>>>>> that the content with the highest impact for our users are
>>>>> localized first, let's figure out a sensible l10n priority so that
>>>>> the localization process on SUMO doesn't feel overwhelming:
>>>>>
>>>>> 1. UI, using verbatim -- could be done by the regular l10n teams.
>>>>> Wil Clouser is working on implementing support for SUMO/Verbatim as
>>>>> we speak. See also
>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=442916.
>>>>> 2. start page(s)
>>>>> 3. List of KB articles ordered by priority (as determined by
>>>>> traffic, vote scores, etc. in the same way as the Weekly Common
>>>>> Issues (http://support.mozilla.com/en-US/kb/Weekly+common+issues).
>>>>> This naturally includes some of the more important articles
>>>>> currently called "in-product" including:
>>>>
>>>> So I think this doesn't actually solve the problem of knowing what
>>>> is "required" and what is "optional" here.

That's right; this is just a proposal for a new priority that better
maps to the current support situation and adds clarity for localizers
about what is most important to us and our users.

When I met with the l10n-drivers during their weekly meeting, we all
agreed that the most important motivator for getting people to localize
SUMO is to be able to provide clear priorities on what actually matters
and why. Localizers need to know where to start, and _how_ to start.
This is something we can certainly do a better job of communicating more
efficiently.

Our belief is that if we can make a clear case of why these priorities
are indeed the right ones -- and introduce localizers to the starting
point with good, engaging communication, and offer to help and make sure
they are getting a smooth start -- we will meet our minimum
"requirement" (e.g. the top 10 or so articles) without having it as a
formal requirement, as in "your work isn't complete until you've
translated these articles."

That said, I agree with you that there are locales here that are more
important for us than others. What we could be doing with these
strategic locales is similar to how we're treating tier-1 locales in
other l10n projects: having an even closer relationship, communicating
crisply about the importance of getting this work done, offering a
helping hand, maybe doing l10n sprints over a weekend to ensure we get
the minimum support documentation covered.


>>
>>> If I try to think about making a cut at which point SUMO is
>>> important, I remember looking at ADU stats a while back, and I never
>>> saw a real cut in those numbers, apart from the first 3 or 4. I don't
>>> really see a migration path from small to non-small either.
>>
>> I think ADU matters for retention, and we should also be thinking
>> strategically about what locales we want to maximize
>> retention/adoption first, i.e. China comes to mind. When I looked at
>> this a few months back, I think I ended up with eight locales as my
>> tier 1 for SUMO.

Here's some data of SUMO visitors from November:

United States 108,561 32.8%
Germany 31,010 9.4%
United Kingdom 16,270 4.9%
France 13,321 4.0%
Brazil 13,005 3.9%
Canada 11,883 3.6%
Poland 9,692 2.9%
Japan 9,215 2.8%
Russian Federation 7,249 2.2%
Italy 7,226 2.2%
Spain 6,114 1.8%
India 5,078 1.5%

I can pick out at least the following languages as being important from
a user base point of view: German, French, Portuguese, Polish, Japanese,
Russian, Italian, Spanish. Note that in terms of retaining Firefox
users, German is much more important than Russian (by a factor of 4.3).

Then there are strategic locales for growth that aren't even in the top
list above, like China and Korea. However, we need to remember that
SUMO's focus is retention, not acquisition. With that in mind, we may
not want to call these locales "SUMO tier-1 locales" yet (unless someone
can claim that the lack of support is hindering the growth of Firefox
marketshare in these locales).


>>
>>> You mentioned finding a clear cut in popularity of documents. I'd
>>> love to see that, too. In particular if we can resolve this by
>>> locale, I don't think that small user groups have the same problems
>>> as large user groups, and it might very well depend on region, i.e.,
>>> how "techie and early adopter" people on the internet are in that
>>> region anyway.
>>
>> How would we resolve this per-locale, other than guesswork? I think
>> that assertion is likely going to be false, in any case, as the
>> highest volume issues cut across consumer verticals. The
>> techie/early adopter issues are not our main priority with SUMO, so
>> trying to account for degree of early adopter presence won't really
>> solve things.
>>
>>> I admit having a hard time seeing usage stats for English support
>>> docs map to, say, Estonian, Hindi, Vietnamese, Occitan. Just to pick
>>> on a few of our locales with small ADU counts.
>>
>> Again, I think you're focused on the wrong things here, and making
>> assumptions that issues differ across locales in a way that doesn't
>> seem based on any data, or even anecdotal evidence.

I'm still struggling somewhat with Omniture to get good per-locale
stats, but I have evidence suggesting that the most common support
issues are the same for all locales: The top search term in English,
German, and Japanese are all "bookmarks" (well, in their respective
languages).

Then I'd argue that since we're talking about the same software product,
I would be very surprised if the common support issues differed
significantly (or even marginally, to be honest) between different
locales. When talking about top support issues, those don't seem locale
specific by nature.

So, I would not say we should treat locales differently because the
support needs are different, but because the userbase is significantly
larger.

>>
>>> I'd rather see us coming up with something that makes it easy to find
>>> "the next good page to add to your localization on SUMO", than to go
>>> in and say "we made some stats on US, German and France users, and
>>> you're not doing anything useful until you have these pages done".
>>> "The next good page" does sound like a much higher return of
>>> investment to me (yes, I like that language).

I agree with this for most locales, although I do think we should be
more engaged with our tier-1 SUMO locales and ensure they reach a level
of translation that fulfills the needs for that locale, say the top 10
articles or so.

Again, it's not really about adding requirements to select localization
teams, but about prioritizing which locales we want to hand-hold and
ensure they reach a level of completeness that matches the significance
of the locale.

A large part of this is to increase visibility of SUMO amongs those
communities and explain clearly why this is very important for their locale.

Mike Connor

unread,
Dec 4, 2008, 2:08:41 PM12/4/08
to Planning how we can best support our users
David Tenser wrote:
>>>>> So I think this doesn't actually solve the problem of knowing
>>>>> what is "required" and what is "optional" here.
>
> That's right; this is just a proposal for a new priority that better
> maps to the current support situation and adds clarity for
> localizers about what is most important to us and our users.

If we've identified a problem, we should be identifying how to solve
that problem, or declaring we're not going to bother fixing that
problem. Creating a proposal that doesn't actually solve problems is
just spinning our wheels.

> When I met with the l10n-drivers during their weekly meeting, we all
> agreed that the most important motivator for getting people to
> localize SUMO is to be able to provide clear priorities on what
> actually matters and why. Localizers need to know where to start,
> and _how_ to start. This is something we can certainly do a better
> job of communicating more efficiently.
>
> Our belief is that if we can make a clear case of why these
> priorities are indeed the right ones -- and introduce localizers to
> the starting point with good, engaging communication, and offer to
> help and make sure they are getting a smooth start -- we will meet
> our minimum "requirement" (e.g. the top 10 or so articles) without
> having it as a formal requirement, as in "your work isn't complete
> until you've translated these articles."

This doesn't actually address my core point, which is that in order to
have a significant impact on users, we need to have content that
covers enough of the top issues. To be clearer, I would aim for a
minimum of 90% of incoming users being able to find their answer.
That seems like a very reasonable target, given what we've seen with
the top articles covering the vast bulk of issues. Maybe that's 10,
maybe that's 25, I don't have all of the stats handy right now, but we
do have the data, so let's aim for the right coverage level.

The point is to set a goal that localizers can work towards. If they
go above and beyond, great, but I cannot see a situation where saying
"we believe that we need this minimum set of articles translated to
provide effective support" would be a negative. Especially if there
is an objective goal (i.e. answering 90% of user issues) driving the
baseline requirement.

> That said, I agree with you that there are locales here that are
> more important for us than others. What we could be doing with these
> strategic locales is similar to how we're treating tier-1 locales in
> other l10n projects: having an even closer relationship,
> communicating crisply about the importance of getting this work
> done, offering a helping hand, maybe doing l10n sprints over a
> weekend to ensure we get the minimum support documentation covered.

Right, exactly. But having a milestone we can use to evaluate "doing
fine" vs. "needs help" is a lot easier with a crisp baseline. Anyone
under the baseline needs our focus and help, anyone above it is doing
ok. Without defining that target, it feels a little more like
spinning plates, since there's no clear target other than "keep going!"

>>>> If I try to think about making a cut at which point SUMO is
>>>> important, I remember looking at ADU stats a while back, and I
>>>> never saw a real cut in those numbers, apart from the first 3 or
>>>> 4. I don't really see a migration path from small to non-small
>>>> either.
>>>
>>> I think ADU matters for retention, and we should also be thinking
>>> strategically about what locales we want to maximize retention/
>>> adoption first, i.e. China comes to mind. When I looked at this a
>>> few months back, I think I ended up with eight locales as my tier
>>> 1 for SUMO.

> I can pick out at least the following languages as being important
> from a user base point of view: German, French, Portuguese, Polish,
> Japanese, Russian, Italian, Spanish. Note that in terms of retaining
> Firefox users, German is much more important than Russian (by a
> factor of 4.3).

That's a deeply flawed conclusion, IMO, and doesn't seem to take
strategic value into account. Building and maintaining a stronger
base of users in Russia may in fact have a larger strategic value, as
our market penetration is less than it is in Germany, and a strong
base is our biggest asset in increasing adoption.

> Then there are strategic locales for growth that aren't even in the
> top list above, like China and Korea. However, we need to remember
> that SUMO's focus is retention, not acquisition. With that in mind,
> we may not want to call these locales "SUMO tier-1 locales" yet
> (unless someone can claim that the lack of support is hindering the
> growth of Firefox marketshare in these locales).

Retention and acquisition are not separate concepts. Retention
measures how many people using the product continue to use the
product. We can market well and get more downloads every day, but
from the moment users first launch Firefox, the retention rate is what
has the greatest influence on sour growth. In fact, from what we've
learned in the past the biggest opportunities with retention are with
new users, not established users, so retention is actually a primary
aspect in all of our growth.

> I'm still struggling somewhat with Omniture to get good per-locale
> stats, but I have evidence suggesting that the most common support
> issues are the same for all locales: The top search term in English,
> German, and Japanese are all "bookmarks" (well, in their respective
> languages).
>
> Then I'd argue that since we're talking about the same software
> product, I would be very surprised if the common support issues
> differed significantly (or even marginally, to be honest) between
> different locales. When talking about top support issues, those
> don't seem locale specific by nature.
>
> So, I would not say we should treat locales differently because the
> support needs are different, but because the userbase is
> significantly larger.

Yay data backing up common sense assertions!

>>>> I'd rather see us coming up with something that makes it easy to
>>>> find "the next good page to add to your localization on SUMO",
>>>> than to go in and say "we made some stats on US, German and
>>>> France users, and you're not doing anything useful until you have
>>>> these pages done". "The next good page" does sound like a much
>>>> higher return of investment to me (yes, I like that language).
>
> I agree with this for most locales, although I do think we should be
> more engaged with our tier-1 SUMO locales and ensure they reach a
> level of translation that fulfills the needs for that locale, say
> the top 10 articles or so.

I strongly feel we need to set goals based on coverage of user needs,
rather than an arbitrary number. I'm pushing on this hard because an
arbitrary number or articles isn't as useful as figuring out how to
cover as much as possible before we hit the long tail. Even if the
top 10 covers 90% of issues now, that trend might not continue, and we
might see a wider range of issues making up that 90%, and we should be
focused on keeping that level of coverage, rather than some arbitrary
number that may or may not give us what we need.

> Again, it's not really about adding requirements to select
> localization teams, but about prioritizing which locales we want to
> hand-hold and ensure they reach a level of completeness that matches
> the significance of the locale.

It is less about requirements than about setting a clear goal for
"good enough" that localizers can understand and target. What you're
proposing is rather open-ended, which is a lot harder to scope and plan.

-- Mike

Majken Connor

unread,
Dec 4, 2008, 2:54:09 PM12/4/08
to Planning how we can best support our users
On Thu, Dec 4, 2008 at 2:08 PM, Mike Connor <mco...@mozilla.com> wrote:

> David Tenser wrote:
>
>> So I think this doesn't actually solve the problem of knowing what is
>>>>>> "required" and what is "optional" here.
>>>>>>
>>>>>
>> That's right; this is just a proposal for a new priority that better maps
>> to the current support situation and adds clarity for localizers about what
>> is most important to us and our users.
>>
>

> If we've identified a problem, we should be identifying how to solve that
> problem, or declaring we're not going to bother fixing that problem.
> Creating a proposal that doesn't actually solve problems is just spinning
> our wheels.
>

> When I met with the l10n-drivers during their weekly meeting, we all
>> agreed that the most important motivator for getting people to localize SUMO
>> is to be able to provide clear priorities on what actually matters and why.
>> Localizers need to know where to start, and _how_ to start. This is
>> something we can certainly do a better job of communicating more
>> efficiently.
>>
>> Our belief is that if we can make a clear case of why these priorities are
>> indeed the right ones -- and introduce localizers to the starting point with
>> good, engaging communication, and offer to help and make sure they are
>> getting a smooth start -- we will meet our minimum "requirement" (e.g. the
>> top 10 or so articles) without having it as a formal requirement, as in
>> "your work isn't complete until you've translated these articles."
>>
>

> This doesn't actually address my core point, which is that in order to have
> a significant impact on users, we need to have content that covers enough of
> the top issues. To be clearer, I would aim for a minimum of 90% of incoming
> users being able to find their answer. That seems like a very reasonable
> target, given what we've seen with the top articles covering the vast bulk
> of issues. Maybe that's 10, maybe that's 25, I don't have all of the stats
> handy right now, but we do have the data, so let's aim for the right
> coverage level.
>
> The point is to set a goal that localizers can work towards. If they go
> above and beyond, great, but I cannot see a situation where saying "we
> believe that we need this minimum set of articles translated to provide
> effective support" would be a negative. Especially if there is an objective
> goal (i.e. answering 90% of user issues) driving the baseline requirement.
>

> That said, I agree with you that there are locales here that are more
>> important for us than others. What we could be doing with these strategic
>> locales is similar to how we're treating tier-1 locales in other l10n
>> projects: having an even closer relationship, communicating crisply about
>> the importance of getting this work done, offering a helping hand, maybe
>> doing l10n sprints over a weekend to ensure we get the minimum support
>> documentation covered.
>>
>

> Right, exactly. But having a milestone we can use to evaluate "doing fine"
> vs. "needs help" is a lot easier with a crisp baseline. Anyone under the
> baseline needs our focus and help, anyone above it is doing ok. Without
> defining that target, it feels a little more like spinning plates, since
> there's no clear target other than "keep going!"
>

> If I try to think about making a cut at which point SUMO is important, I
>>>>> remember looking at ADU stats a while back, and I never saw a real cut in
>>>>> those numbers, apart from the first 3 or 4. I don't really see a migration
>>>>> path from small to non-small either.
>>>>>
>>>>
>>>> I think ADU matters for retention, and we should also be thinking
>>>> strategically about what locales we want to maximize retention/adoption
>>>> first, i.e. China comes to mind. When I looked at this a few months back, I
>>>> think I ended up with eight locales as my tier 1 for SUMO.
>>>>

>>> I can pick out at least the following languages as being important from a
>> user base point of view: German, French, Portuguese, Polish, Japanese,
>> Russian, Italian, Spanish. Note that in terms of retaining Firefox users,
>> German is much more important than Russian (by a factor of 4.3).
>>
>

> That's a deeply flawed conclusion, IMO, and doesn't seem to take strategic
> value into account. Building and maintaining a stronger base of users in
> Russia may in fact have a larger strategic value, as our market penetration
> is less than it is in Germany, and a strong base is our biggest asset in
> increasing adoption.
>

> Then there are strategic locales for growth that aren't even in the top
>> list above, like China and Korea. However, we need to remember that SUMO's
>> focus is retention, not acquisition. With that in mind, we may not want to
>> call these locales "SUMO tier-1 locales" yet (unless someone can claim that
>> the lack of support is hindering the growth of Firefox marketshare in these
>> locales).
>>
>

> Retention and acquisition are not separate concepts. Retention measures
> how many people using the product continue to use the product. We can
> market well and get more downloads every day, but from the moment users
> first launch Firefox, the retention rate is what has the greatest influence
> on sour growth. In fact, from what we've learned in the past the biggest
> opportunities with retention are with new users, not established users, so
> retention is actually a primary aspect in all of our growth.
>

> I'm still struggling somewhat with Omniture to get good per-locale stats,
>> but I have evidence suggesting that the most common support issues are the
>> same for all locales: The top search term in English, German, and Japanese
>> are all "bookmarks" (well, in their respective languages).
>>
>> Then I'd argue that since we're talking about the same software product, I
>> would be very surprised if the common support issues differed significantly
>> (or even marginally, to be honest) between different locales. When talking
>> about top support issues, those don't seem locale specific by nature.
>>
>> So, I would not say we should treat locales differently because the
>> support needs are different, but because the userbase is significantly
>> larger.
>>
>

> Yay data backing up common sense assertions!
>

> I'd rather see us coming up with something that makes it easy to find "the
>>>>> next good page to add to your localization on SUMO", than to go in and say
>>>>> "we made some stats on US, German and France users, and you're not doing
>>>>> anything useful until you have these pages done". "The next good page" does
>>>>> sound like a much higher return of investment to me (yes, I like that
>>>>> language).
>>>>>
>>>>
>> I agree with this for most locales, although I do think we should be more
>> engaged with our tier-1 SUMO locales and ensure they reach a level of
>> translation that fulfills the needs for that locale, say the top 10 articles
>> or so.
>>
>

> I strongly feel we need to set goals based on coverage of user needs,
> rather than an arbitrary number. I'm pushing on this hard because an

> arbitrary number or articles isn't as useful as figuring out how to cover as


> much as possible before we hit the long tail. Even if the top 10 covers 90%
> of issues now, that trend might not continue, and we might see a wider range
> of issues making up that 90%, and we should be focused on keeping that level
> of coverage, rather than some arbitrary number that may or may not give us
> what we need.
>

> Again, it's not really about adding requirements to select localization
>> teams, but about prioritizing which locales we want to hand-hold and ensure
>> they reach a level of completeness that matches the significance of the
>> locale.
>>
>

> It is less about requirements than about setting a clear goal for "good
> enough" that localizers can understand and target. What you're proposing is
> rather open-ended, which is a lot harder to scope and plan.
>
> -- Mike
>

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

If I"ve understood past l10n dicussions correctly, a big issue for getting
SUMO localized with the current teams is that they need to see where SUMO is
the priority in terms of all the other l10n work they're doing for Mozilla.
It's all great to get this work together and identify our top articles, but
if the overall message is that product (of course) and AMO etc localization
is more important than SUMO, then that's what our localizers will choose to
work on.

We don't just need to prioritize what work needs to be done in SUMO, we need
people like mconnor to help prioritize SUMO within all the other l10n work.
I think we can assume that we won't be at the top of the pack, hopefully we
won't be at the bottom either, but not being the highest priority is going
to mean that, for some locales, the existing teams are not going to have
time to take on SUMO as well.

To solve this problem we either need to somehow find more time for our
localizers or we'll have to attract new localizers to the teams to handle
the extra work [side note, when we were talking a while ago about paying
people to help with l10n I think those of us suggesting it were suggesting
we pay existing localizers to be able to localize more, rather than hiring
out some firm]. In some cases i think if we can get the existing localizers
to agree to be locale leaders - that is they'll review translations and
approve or deny them when someone *else* does them - that will be the best
we can do, and might even be enough. We get people from different locales
looking to get started that don't have the expertise to be leaders right
away. If we can at least have leaders waiting for content, these new people
can hit the ground running.

Axel Hecht

unread,
Dec 4, 2008, 3:41:20 PM12/4/08
to

That feeling that SUMO isn't well prioritized is apparently around, and
it might come from a few not-so-outspoken side-thoughts in everyones
head, including mine.

I had a chat with David about that, and clarified on what we actually
mean about "blocking on ..." in particular for tier-1 locales.

The basic setup is this:

- We block a particular release of Firefox on a particular set of locales.
- We block individual locales on a set of tasks to complete.

Now what happens if such a locale doesn't match the tasks? We don't
know, as we have never got into the situation before. Not doing so comes
from a few factors:

- our localizers over-achieve, across the board. Not just tier 1, really
in general
- we have lions and dogs and despots fighting over each line of content
that come to our localizers, in particular during release times. Yours
truly.
- we do an increasing amount of handholding, lifting, and personal
attention in particular for tier 1 locales

The current set of requirements is rather common across locales, though
we go into more depth on things like actually nagging and bragging for
local services for web-services and the getting started page. So there
is some additional work for high-ranking locales compared to locales
targetting a smaller online world.

So in the end, we're having some form of policy for the long tail, which
says "A, B, C needs to be done to get into Beta, D, E, F needs to be
done to get out". And then there is a set of locales, in particular the
set we'd block shipping on, where we more actively reach out to make
sure that they actually make it into a beta in time, and that stuff is
done completely by the time we want to ship.

In order to get there, we do things like announcement posts, mails, irc
meetings, phone calls, and even physical gatherings.

...

So, how do we map that to SUMO? Talking to David, it seems like at least
the KB/translating articles part is by and large an occasional one-off
huge-ish chunk of work. Rumor has it that sprints are a good tool to get
those done, so that is one thing we can do. Recruiting community of
translators in general open source events is one. Supporting real-life
community meet-ups is another. David volunteered to do some of the
physical presence that we should have for those. I see other folks being
obvious candidates, too, hugely dependent on which locales we're talking
about.

We need to find the right tool for the problems at hand for each team,
as we're here talking about a finite set of tier-1 locales. That gives
us a finite amount of problems, and some solutions will work for more
than one locale, others might not. I'm leaving the details out of the
public discussion, that'd look a tad like pointing fingers.

In short, if we can switch the message from "SUMO is important" to "we
see you didn't really succeed here, we think this would improve it",
then that message will be much more well received.

Setting goals and measures of when we think a locale has issues or not
is of course a basis to an outreach like that.

...

And then we need a policy still for the long tail.

...

Sounds better?

Axel

David Tenser

unread,
Dec 5, 2008, 9:45:41 AM12/5/08
to
Mike Connor skrev:

> David Tenser wrote:
>>>>>> So I think this doesn't actually solve the problem of knowing what
>>>>>> is "required" and what is "optional" here.
>>
>> That's right; this is just a proposal for a new priority that better
>> maps to the current support situation and adds clarity for localizers
>> about what is most important to us and our users.
>
> If we've identified a problem, we should be identifying how to solve
> that problem, or declaring we're not going to bother fixing that
> problem. Creating a proposal that doesn't actually solve problems is
> just spinning our wheels.

Well, I was creating a proposal that solved a very specific problem --
the SUMO l10n priority. This proposal:

* attempts to make it clear what content matters the most to our users
is localized first

* attempts to make it clear for localizers what l10n work has the
highest impact

* attempts to make it easy for localizers to know where to start.

I didn't say my post was an attempt to solve the particular problem
you're referring to now (defining what is "required" vs "optional"), or
any other problem for that matter.

That said, I'm glad we're doing that now, as it's a sign that we're
ready to move forward. Step 1 was to identify a sound priority, and step
2 is to figure out where to draw the line of what we call a healthy l10n
situation for a locale.

>
>> When I met with the l10n-drivers during their weekly meeting, we all
>> agreed that the most important motivator for getting people to
>> localize SUMO is to be able to provide clear priorities on what
>> actually matters and why. Localizers need to know where to start, and
>> _how_ to start. This is something we can certainly do a better job of
>> communicating more efficiently.
>>
>> Our belief is that if we can make a clear case of why these priorities
>> are indeed the right ones -- and introduce localizers to the starting
>> point with good, engaging communication, and offer to help and make
>> sure they are getting a smooth start -- we will meet our minimum
>> "requirement" (e.g. the top 10 or so articles) without having it as a
>> formal requirement, as in "your work isn't complete until you've
>> translated these articles."
>
> This doesn't actually address my core point, which is that in order to
> have a significant impact on users, we need to have content that covers
> enough of the top issues. To be clearer, I would aim for a minimum of
> 90% of incoming users being able to find their answer. That seems like
> a very reasonable target, given what we've seen with the top articles
> covering the vast bulk of issues.

Where are you seeing this data? Looking at a subset of our top 190
support articles, in order to get 90% of the traffic on this subset of
articles, we would need to include 101 KB articles. Even a moderate goal
of 50% coverage would require 15 articles.

I'd be interested in figuring out better ways of measuring "able to find
their answer" than just page hits, but it's pretty safe to say we're
looking at a very long tail of support issues on Firefox Support.

> Maybe that's 10, maybe that's 25, I
> don't have all of the stats handy right now, but we do have the data, so
> let's aim for the right coverage level.

I do agree that "xx% of people getting problem solved" is a better line
to draw than "top yy articles," because it adds meaning to the otherwise
more arbitrary line, but I think it will be unrealistic to achieve
unless xx < 50.

>
> The point is to set a goal that localizers can work towards. If they go
> above and beyond, great, but I cannot see a situation where saying "we
> believe that we need this minimum set of articles translated to provide
> effective support" would be a negative. Especially if there is an
> objective goal (i.e. answering 90% of user issues) driving the baseline
> requirement.

Setting a goal is one thing, which I definitely am in favor for as it
gives us a way of saying: "locale A is doing well, but locale B needs
more help."

Setting a _requirement_ is a completely different beast though, and
that's why I keep repeating that our best bet there is to work with
localizers, explain why this is important, and provide clear entry points.

>
>> That said, I agree with you that there are locales here that are more
>> important for us than others. What we could be doing with these
>> strategic locales is similar to how we're treating tier-1 locales in
>> other l10n projects: having an even closer relationship, communicating
>> crisply about the importance of getting this work done, offering a
>> helping hand, maybe doing l10n sprints over a weekend to ensure we get
>> the minimum support documentation covered.
>
> Right, exactly. But having a milestone we can use to evaluate "doing
> fine" vs. "needs help" is a lot easier with a crisp baseline. Anyone
> under the baseline needs our focus and help, anyone above it is doing
> ok. Without defining that target, it feels a little more like spinning
> plates, since there's no clear target other than "keep going!"
>

Yes, so this definitely makes sense. "xx % of users finding their
answer" is a fine target to measure the status of locales. I don't think
"yy number of articles translated" is spinning plates though. Keep in
mind that one important aspect of making sure localizers get properly
introduced to the system (the wiki, review system, UI, etc). Once people
get started, it's easier to ensure the work continues and evolves. This
aspect could be achieved with both types of targets.

>>>>> If I try to think about making a cut at which point SUMO is
>>>>> important, I remember looking at ADU stats a while back, and I
>>>>> never saw a real cut in those numbers, apart from the first 3 or 4.
>>>>> I don't really see a migration path from small to non-small either.
>>>>
>>>> I think ADU matters for retention, and we should also be thinking
>>>> strategically about what locales we want to maximize

>>>> retention/adoption first, i.e. China comes to mind. When I looked

>>>> at this a few months back, I think I ended up with eight locales as
>>>> my tier 1 for SUMO.
>> I can pick out at least the following languages as being important
>> from a user base point of view: German, French, Portuguese, Polish,
>> Japanese, Russian, Italian, Spanish. Note that in terms of retaining
>> Firefox users, German is much more important than Russian (by a factor
>> of 4.3).
>
> That's a deeply flawed conclusion, IMO, and doesn't seem to take
> strategic value into account. Building and maintaining a stronger base
> of users in Russia may in fact have a larger strategic value, as our
> market penetration is less than it is in Germany, and a strong base is
> our biggest asset in increasing adoption.

I specifically said "from a user base point of view." I admit that there
may be strategic reasons why we want to treat certain locales specially,
although I would like to learn more about that before deciding on SUMO
tier-1 locales.

The main point here is to treat tier-1 locales differently, just like we
do with other projects.

>
>> Then there are strategic locales for growth that aren't even in the
>> top list above, like China and Korea. However, we need to remember
>> that SUMO's focus is retention, not acquisition. With that in mind, we
>> may not want to call these locales "SUMO tier-1 locales" yet (unless
>> someone can claim that the lack of support is hindering the growth of
>> Firefox marketshare in these locales).
>
> Retention and acquisition are not separate concepts. Retention measures
> how many people using the product continue to use the product. We can
> market well and get more downloads every day, but from the moment users
> first launch Firefox, the retention rate is what has the greatest
> influence on sour growth.

I'm obviously well aware of the concepts of acquisition and retention.
Retention is a _huge_ subject and involves a lot more than just support.
As you say yourself, retention starts from the moment users first launch
Firefox, and the majority of our users aren't leaving Firefox because of
a lack of support. The reasons why people stop using Firefox are many
more than just a lack of technical support.

I obviously believe support is critical because of our large user base
and large representation of mainstream users, but I'm not convinced that
the lack of support is the reason why we're not making inroads in China
today. We were able to build a large user base in other locales without
decent support initially. So, before we add Chinese to a list of SUMO
tier-1 locales, I'd like to see a solid strategic reason based on solid
evidence of where the problem lies.

As a side note, I don't think we have a very strong community in China
in the first place, and that is a problem that goes beyond just SUMO.


> In fact, from what we've learned in the past
> the biggest opportunities with retention are with new users, not
> established users, so retention is actually a primary aspect in all of
> our growth.
>

Yes. And we have lots of interesting ideas around how to capture the new
users within the marketing team for 2009, but that's off-topic for this
thread. :)


>> Again, it's not really about adding requirements to select
>> localization teams, but about prioritizing which locales we want to
>> hand-hold and ensure they reach a level of completeness that matches
>> the significance of the locale.
>
> It is less about requirements than about setting a clear goal for "good
> enough" that localizers can understand and target. What you're
> proposing is rather open-ended, which is a lot harder to scope and plan.
>

Yes, I agree that a clear milestone for locales where we can say "doing
well" or "needs help" is needed.

David Tenser

unread,
Dec 5, 2008, 9:52:06 AM12/5/08
to
Axel Hecht skrev:

Thanks for sticking to the main point and for presenting it well. It's
about being available for the localizers and not just tell what they
need to work on and why. We (SUMO, l10n-drivers) need to engage with
them and lend them a helping hand if they need one.

The SUMO l10n priority we're establishing makes this process a lot
smoother to communicate, of course.

And by identifying a measure of when we think a locale has reached a
milestone of "doing well," it will be straightforward to identify which
locales need more help based on their progress and relative importance
(e.g. "tier-1").

Majken Connor

unread,
Dec 5, 2008, 12:50:45 PM12/5/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
>

Not sure if it's needed, but now that I think we're on the same page wrt
l10n responsibilities I think it's probably good that someone steer the
conversation back to specifically what we're doing about "in product" help
for 3.1

Does all this above discussion mean that we're going to only cover the pages
that are linked to from the browser and then everything else is based on
need? I think we're still going to have to identify a set of
how-to-use-firefox articles like we have now, and that we don't consider a
locale "complete" until these are met.

I think maybe we need to think of these as two different things, there's the
"user guide" which is like the instruction manual. Then there's "support"
which is what we're talking more about above, which covers solving problems,
how to fix something that's broken. This is more user focused in a way, it
revolves around what the user is trying to do and the problem the user is
trying to solve. The "user guide" is product focused. It tells you what the
product can do and how you're supposed to interact with it.

We can easily have a localizer that cares more about support than the user
guide, this is more likely from localizers we attract from SUMO. We'll also
have localizers that care more about product localization and will want to
make sure they cover the user guide, but don't want to expand into support,
which is a lot more fluid and changing.

On top of the l10n question, we have the even bigger issue of how we present
in-product support at all, in [en]. What articles are required for a "user
guide." Can we cut some out as legacy? Which do we add to reflect new
features? How do we best present those articles to users. Do we continue
segregating them in any way or do we mash everything together.

I think we segregated them for a reason, and that reason still exists. When
we had the SUMO meeting in Toronto last year there was a mockup of what we
thought the in-product start page should look like eventually with the idea
of having two landing pages that were divided more along the lines of "How
to use Firefox" and "How to solve a problem" than along in-product vs
additional articles.

Obviously we need to factor l10n needs into how we go about this, but I
think we probably need to focus again on the development requiremens for
what SUMO hosts that would otherwise be an in product user guide.

Majken Connor

unread,
Dec 5, 2008, 3:42:44 PM12/5/08
to Planning how we can best support our users
On Fri, Dec 5, 2008 at 12:50 PM, Majken Connor <maj...@gmail.com> wrote:

>
>
> On Fri, Dec 5, 2008 at 9:52 AM, David Tenser <djst.m...@gmail.com>wrote:
>

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

Another issue that this definitely affects is our support of older versions.
Having a set of "in-product" articles as a user guide gives us a clear set
that we can archive for legacy support. I don't know what our current plan
or mandate is in terms of support for unsupported versions. Are we expected
to remove references to Firefox 2 once it's no longer officially supported?

In the case of Firefox 2 this wouldn't be a problem. However, when we drop
support for Firefox 3, for example, I think since we moved to web based help
we should maintain archives of what would have been in product support.
While we'll tell people that they need to solve their problems by upgrading,
people that choose to stick with an older product should still have access
to the user guide for that product.

David Tenser

unread,
Dec 8, 2008, 9:17:01 AM12/8/08
to
Majken Connor skrev:

> Not sure if it's needed, but now that I think we're on the same page wrt
> l10n responsibilities I think it's probably good that someone steer the
> conversation back to specifically what we're doing about "in product" help
> for 3.1
>
> Does all this above discussion mean that we're going to only cover the pages
> that are linked to from the browser and then everything else is based on
> need?

Based on what is most relevant to our users, unlike how it's been up
until now, when we've e.g. had rarely visited articles like "Glossary"
being a required priority by localizers when in fact "Lost Bookmarks"
(or similar) was much more useful for our users.

Generally, we want the priority to be based on real needs, not articles
we _think_ are relevant to our users.

> I think we're still going to have to identify a set of
> how-to-use-firefox articles like we have now, and that we don't consider a
> locale "complete" until these are met.
>
> I think maybe we need to think of these as two different things, there's the
> "user guide" which is like the instruction manual. Then there's "support"
> which is what we're talking more about above, which covers solving problems,
> how to fix something that's broken. This is more user focused in a way, it
> revolves around what the user is trying to do and the problem the user is
> trying to solve. The "user guide" is product focused. It tells you what the
> product can do and how you're supposed to interact with it.
>
> We can easily have a localizer that cares more about support than the user
> guide, this is more likely from localizers we attract from SUMO. We'll also
> have localizers that care more about product localization and will want to
> make sure they cover the user guide, but don't want to expand into support,
> which is a lot more fluid and changing.

We shouldn't be looking at the documentation needs with localizer
resources in mind, but with what is actually relevant to our users. With
that said, the prioritized list of Weekly Issues (which is the best
metric we have about what actually matters to our users) is really a mix
of tutorials, troubleshooting articles, and references; so it's
certainly not a polarized "support" vs "user guide" priority we're
suggesting here. With this metric, I don't see the point of separating
priorities into two arbitrary categories, since it's clear both are
represented.

However, I do see the potential of maintaining one article that
introduces people to Firefox and its unique (or just useful) features.
We have that today with the "Using Firefox" article, but it's aged and
somewhat redundant since it overlaps a lot of already existing content
in other articles.

We already have lots of great tutorials on specific Firefox features,
and it seems to make great sense to keep articles on topic, meaning
they're searchable, concise, easy to understand and read, and simpler to
localize.

So, what I'm thinking is more of a glue-it-all-together type of user
guide that _briefly_ mentions the key features and links to the
multitude of great content we already have as separate articles:

* Smart location bar
* How to customize the toolbar
* Customizing Firefox with add-ons
* Tabbed browsing
* Page zoom
* Site identity button
* ...

This user guide could be called the "Firefox User Guide," and we would
obviously have a good opportunity to highlight the features we really
think matters to our users. We could also feature this article on the
start page similar to how we do today with the aged "Using Firefox"
article. This would pretty much force it to become included in the list
of prioritized articles, which would mean we'd have a solid user guide
to accompany the other high priority l10n articles.

If this makes sense to people, I'd love to see a proof-of-concept user
guide drafted that's clearly aimed towards the mainstream Firefox user.
Anyone up for the task? :)

Chris Ilias

unread,
Dec 21, 2008, 12:40:02 PM12/21/08
to
On 10/30/08 3:18 AM, _Chris Ilias_ spoke thusly:
> The Options Window article is probably our biggest and most complicated
> article, already beyond our size limit for screenshots, without
> screenshots for secondary option windows (e.g. Fonts, Advanced JS,
> Languages, Warning messages, etc.). It would be better if we split that
> article up by panel.


This one is going to be tricky, because we cannot break the help-topic
links. In other words, all-sub articles need to be created in all
locales, before we change the htaccess file.

Perhaps we should maintain the anchors on the Options window article,
until we know all locales have their Options window article split up.

We can even copy/paste the sections ourselves, and just ask locale
leaders for article titles. (Or name them based on the headings in the
top Options window articles)

Chris Ilias

unread,
Dec 21, 2008, 1:11:41 PM12/21/08
to
On 10/30/08 3:18 AM, _Chris Ilias_ spoke thusly:
> Something I've been thinking about for quite a while now, is what kind
> freedom we have with in-product help and the opportunity in Firefox 3.1.
> Instead of simply updating the information in our set of 13 articles, we
> can re-evaluate:
> * What content should be covered in in-product help?
> * Can we better organize the content in product help?

In another post, I looked at dismantling the "Using Firefox" article.
Another legacy article that mostly overlaps other KB content is
<http://support.mozilla.com/kb/Customizing+Firefox>.

_Analyzing Customizing Firefox_

* Toolbars:
Most of this is covered in
<http://support.mozilla.com/kb/How+to+customize+the+toolbar>, except the
initial paragraph that covers the difference between the Menu bar,
Navigation Toolbar, and Bookmarks Toolbar. We should move that over to
How+to+customize+the+toolbar.

* Add-ons (extensions, themes and plugins) and Using the Add-ons window:
Most is covered in
<http://support.mozilla.com/kb/Customizing+Firefox+with+add-ons> and
<http://support.mozilla.com/kb/Uninstalling+add-ons>, except "Further
functions such as Visit Home Page and About". I'm not sure we even need
to have that documented; but if we want to bother, it can be added to
Customizing+Firefox+with+add-ons.


And that's the entire article. :-)

Majken Connor

unread,
Dec 21, 2008, 1:57:06 PM12/21/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
>

I agree with your last statement. The content shouldn't need any editing and
the headings should already be correct for the article name. We'd just want
to get the locale leaders to double check that that's true, however I think
it's a safe assumption to make and shouldn't block us from going ahead. That
is to say if it's not the right title for the article name, the heading was
most likely already wrong.

David Tenser

unread,
Dec 22, 2008, 6:54:06 AM12/22/08
to

Do we have a plan for how to tie the different sub-articles together?
Here's one suggestion:

* In the summary/first paragraph for each sub-article, say that this is
section [Foo] of the Options window reference, and link back to the
parent Options window article. Example: "This article explains the [Foo]
section of the Options window in Firefox. See ((Options window)) for the
other sections."
* At the end of each sub-article, add a link back to the parent Options
window article
* In the parent Options window article, keep the summary/first
paragraph, but replace the actual content with a list of links to the
sub-articles
* Name the sub-articles "Options window - [Foo] section"

I suggest the following roll-out plan:

1. Create the sub-articles in en-US while keeping the parent/original
article untouched to see our suggestions in action and make sure we like
the content and layout.
2. Talk to localizers about the concrete plan and show the en-US
articles and explain what we need help with (writing the generic summary
for each section, the link back to the Options window). Obviously we
need as much help we can get, but for the locales that don't have time
or interest, we will have to do it ourselves.
3. Lock the parent Options window articles for editing. We don't want
people to remove content from here until we've updated the in-product
links. Otherwise we'll break current product help.
4. Finish the sub-article creation for each locale and help the locales
that don't/won't do it.
5. Push new .htaccess rules to production so the in-product links point
to the new sub-articles where appropriate.
6. Finally, change the parent Options window articles as agreed on, so
it's just this generic intro + links to sub-articles.

Thoughts? Assuming this plan makes sense, let's start working on #1-3 asap.

David Tenser

unread,
Dec 22, 2008, 7:00:44 AM12/22/08
to
On 08-12-22 12.54, David Tenser wrote:
> 1. Create the sub-articles in en-US while keeping the parent/original
> article untouched to see our suggestions in action and make sure we like
> the content and layout.
> 2. Talk to localizers about the concrete plan

We should also make sure we're clear about why we're making this change:

* It will ensure localizers see the "this article has not yet been
translated" notification at the top of each page that Firefox 3 links
to. Today this is a problem because we're linking to anchors so people
don't realize that they can help out with the translation of the article.
* It will make articles more manageable for contributors since the
current Options window article is huge.
* It will make the articles less bandwidth heavy for users with slow
connections.
* It will allow us to get data about which sections of the Options
window are most visited (which might give us clues which options are the
most confusing).

Axel Hecht

unread,
Dec 22, 2008, 8:43:02 AM12/22/08
to

Sounds good to me. There's a little race condition here when you propose
the working en-US sample to localizers, I could expect that some would
just go ahead and create the sub-articles themselves. So the follow-up
plan should probably keep its knees bent on some localizers being faster
than the automation, and some being happy to take the automation.

Axel

Axel Hecht

unread,
Dec 23, 2008, 8:04:57 AM12/23/08
to
On 23.12.2008 13:45 Uhr, Cheng Wang wrote:
> I'm not completely sure I grok what's going on exactly (we're splitting
> the articles but exactly how we're getting this through localizers
> etc)... anyhow, I just want to say I'm happy that we can get
> tab-specific metrics with regards to the options window. It's one of the
> most visited pages on SUMO and it'd be good to know what tabs people
> have the most trouble with.

I'm pretty sure that we have those metrics, they just might be in a
different system. I'd be really surprised if there weren't some
logs/metrics/something available for the actual redirect hits.

Axel

David Tenser

unread,
Dec 23, 2008, 10:29:43 AM12/23/08
to

The redirect stats might be in the Apache logs; not sure. Of course,
this is not the main reason why we're splitting the article up, it's
just a nice side-effect that we'll be able to tell which options are
most in need of descriptions.

However, I can also imagine that many people look through all panes in
the Options window for something specific in an attempt to solve an
issue, and then give up when they don't see it anywhere and click Help
instead, which would mean that much of the traffic to this documentation
are for people that are looking for some settings they can't find in the
Options window in the first place.

- David

Chris Ilias

unread,
Dec 31, 2008, 12:56:58 PM12/31/08
to
On 10/30/08 3:18 AM, _Chris Ilias_ spoke thusly:
> _Background_
> Between Firefox 2 and Firefox 3, help documentation was moved from the
> Firefox source code to the Support web site, and the information in
> those docs were updated to reflect changes in Firefox 3. The subject of
> the content was not changed, nor was the structure.
>
> _Going deeper_

> Something I've been thinking about for quite a while now, is what kind
> freedom we have with in-product help and the opportunity in Firefox 3.1.
> Instead of simply updating the information in our set of 13 articles, we
> can re-evaluate:
> * What content should be covered in in-product help?
> * Can we better organize the content in product help?

Final reply to myself. :-)
I've started a Support/Firefox3.1 section on wiki.m.o to cover all these
changes.
<https://wiki.mozilla.org/Support/Firefox3.1>

All the tasks are still scattered; when we've applied most of the
changes, I think we should have a "checklist" type of page for localizers.

Axel Hecht

unread,
Jan 2, 2009, 1:10:13 PM1/2/09
to

I don't think we should call all of the KB "in product help". Either
drop the term completely, or keep its meaning as those pages on SUMO
that we directly point to.

I'd be leaning towards keeping the term as it is.

That doesn't mean that in-product says anything about "has to be on the
import list" or not. It does mean something for metrics, though, thus my
suggestion to keep it.

The options dialog is not legacy, I would expect it to be highly
visited, even. I don't see us purging that article. Restructuring and
making it easier to read, yes. No idea what happens to the other pages
you mention there.

Axel

Chris Ilias

unread,
Jan 3, 2009, 4:41:10 PM1/3/09
to
On 1/2/09 1:10 PM, _Axel Hecht_ spoke thusly:

> On 31.12.2008 18:56 Uhr, Chris Ilias wrote:
>> I've started a Support/Firefox3.1 section on wiki.m.o to cover all these
>> changes.
>> <https://wiki.mozilla.org/Support/Firefox3.1>
>>
>> All the tasks are still scattered; when we've applied most of the
>> changes, I think we should have a "checklist" type of page for
>> localizers.
>
> I don't think we should call all of the KB "in product help". Either
> drop the term completely, or keep its meaning as those pages on SUMO
> that we directly point to.
>
> I'd be leaning towards keeping the term as it is.
>
> That doesn't mean that in-product says anything about "has to be on the
> import list" or not. It does mean something for metrics, though, thus my
> suggestion to keep it.

The heading is there as an identifier, to explain how we are treating
the articles /they/ know as in-product help. I think once everyone is
aware that we're scrapping the concept of a subset of articles
designated as "in-product help", we shouldn't need to use the term
anymore. When referring to the articles for item #3 in Davids proposal,
I think that term is up in the air. ("Priority 1 articles", "Top
articles", "First articles to translate", etc.)

> The options dialog is not legacy, I would expect it to be highly
> visited, even. I don't see us purging that article. Restructuring and
> making it easier to read, yes. No idea what happens to the other pages
> you mention there.

I think we have different definitions of the word legacy. I didn't mean
to say that it was out of date or unimportant, just that it was directly
imported from the Firefox 2 XHTML files. i.e. Grandfathered in. Or from
<http://www.answers.com/main/ntquery?s=legacy> "Something handed down
from an ancestor or a predecessor or from the past"

0 new messages