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.
>
>