Is it a good idea to have an KB article describing about:config?
myles7897
Bug 428582?
If so, what should the article entail?
and it is metioned, briefly, here:
http://support.mozilla.com/en-US/kb/Editing+configuration+files#about_config
Majken Connor
> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>
I think it's a good idea. In some articles we tell users to use it. Other
support venues tell users about it as well. We should have a document if
only to iterate the damage you can do if you change anything without
understanding what it does. I'd rather handle it like an education doc that
explains what about:config is, how it's a listing of all the prefs and more,
but not list any of the prefs. (though I like having a listing of the prefs
*somewhere* it's incredibly useful)
Jason Barnabe (np)
Describing every preference would make for a very long article and
would take a long time to do. We could have one that just says what it
is, how to get to it, some warnings, but that seems to overlap with
Editing configuration files anyway.
Chris Ilias
We already have the Editing config files article for an overview of how
to use about:config.
I'm in favour of having an article listing as many prefs as possible,
because there's significant user demand for it. Whenever someone gets
help by being instructied to do something in about:config, the usual
response is "Wow, that's cool. Where can I find out what all the other
lines are for? Is there a master list?"
Mike Connor
I don't think we should officially support editing about:config, at
all. If there are behaviours that we should and will support, we
should just suck it up and add UI for them. I don't know of any prefs
that aren't exposed to the UI that don't have potential drawbacks as
well. By documenting them in an official source, it makes it harder
to remove those options going forward, which is a constraint I don't
want to create. In cases where we have actual bugs (not "make it work
like X instead") that you can work around using manual tweaks, we
should fix those bugs wherever possible.
-- Mike
Majken Connor
>
> On 14-Apr-08, at 1:20 AM, Chris Ilias wrote:
> I don't think we should officially support editing about:config, at
> all. If there are behaviours that we should and will support, we
> should just suck it up and add UI for them. I don't know of any prefs
> that aren't exposed to the UI that don't have potential drawbacks as
> well. By documenting them in an official source, it makes it harder
> to remove those options going forward, which is a constraint I don't
> want to create. In cases where we have actual bugs (not "make it work
> like X instead") that you can work around using manual tweaks, we
> should fix those bugs wherever possible.
>
> -- Mike
> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>
People ask a lot of "can I make x do y?" questions where we could tell them
to download a bloated extension, or we could tell them to flip a pref. This
happens in plenty of cases where a default value is changed and the pref is
removed from the UI (or was never there, as in the case of access keys on
websites). There are also cases, like the tab preferences where two
checkboxes were combined into one, were we have to walk a user through
setting their about:config option back to default.
I use the about:config chart on MZ *all the time* for supporting users. I
don't think we should support it in the case of people asking where they can
see the list to find out what else they can do. But we should support it in
the case of finding out what changed to be able to set it back. People get
tips from elsewhere and can't remember what they changed, (or where they got
the tip) or an extension flips something and doesn't properly revert it when
uninstalled.
I don't see how it's harder to take out about:config entries if they're
documented somewhere. If enough users use the option then I don't see why
you'd remove it. If enough don't then it'll be removed and a fraction of
people will complain that x no longer works in the new version.
Melchert Fruitema
for editing the configuration variables and its entry point is part of
the graphic user interface: the button labeled "Config Editor".
Besides there is an extension called Preferential, available from
Mozdev, that although halfheartedly, explains a bit about the variable
and sometimes its settings.
--
Kind regards,
Melchert
(MacOS 10.3.9 / Firefox 2.0, Thunderbird 2.0)
Melchert Fruitema
This is academic, see my parallel reply to Mike.
David Tenser
Why would you want to remove prefs from about:config if they're
used/popular? To me, the reason why some prefs are in the UI and others
in about:config is a separation between stuff that's useful to "most
people" vs stuff that's only useful for "some people," not a separation
between what we support vs what we don't.
SUMO should provide documentation for "some people" as well as for "most
people" in my opinion, as long as it's meaningful to our users. "Make it
work like X instead" is an important part of what people search for, and
if we're not providing the info, others will, so you'll end up with the
same struggle if you want to remove the pref.
We should make it clear that this is an advanced feature (and really the
UI does a pretty good job of making that point too), but we shouldn't
dumb down SUMO into being something for basic documentation only,
especially considering that our troubleshooting articles often use
about:config to solve problems.
Mike Connor
means that we make no guarantees they will be supported in the future, or
that we will fix them if they break. We do not QA these behaviours, and we
will not in the future. Supporting these requires us to carry around extra
code that we don't want.
There are other prefs that exist because we use them to configure Gecko to
our needs (i.e. Network.* prefs). Those should generally not be considered
safe to play with (i.e. Pipelining and max-connections both can lead to
instability or angry sysadmins).
Most people don't use prefs at all. Those who do have a large chunk of
them. If it isn't worth UI, its not worth the code complexity, in the
general case.
Lucy mentioned "bloated" extensions, but having a bunch of "what does it
hurt?" prefs moves the bloat into the core instead. That's not a good
situation either.
- Mike
David Tenser
> Hidden prefs that control behaviour are explicitly not supported, which
> means that we make no guarantees they will be supported in the future, or
> that we will fix them if they break. We do not QA these behaviours, and we
> will not in the future. Supporting these requires us to carry around extra
> code that we don't want.
>
> There are other prefs that exist because we use them to configure Gecko to
> our needs (i.e. Network.* prefs). Those should generally not be considered
> safe to play with (i.e. Pipelining and max-connections both can lead to
> instability or angry sysadmins).
Again, we would make it clear that the prefs are generally not safe to
fiddle with, but I still don't see why we should omit information that
is available elsewhere because of that fact.
>
> Most people don't use prefs at all. Those who do have a large chunk of
> them. If it isn't worth UI, its not worth the code complexity, in the
> general case.
>
> Lucy mentioned "bloated" extensions, but having a bunch of "what does it
> hurt?" prefs moves the bloat into the core instead. That's not a good
> situation either.
This is about explaining prefs that we already have in the core. We're
not moving more bloat into Firefox by explaining what the prefs are for.
By the way, any extensions exposing UI for hidden prefs are also
unofficial and unsupported, but we're still providing them on AMO. How
is that different to the end user?
Chris Ilias
Okay, so do we have a decision on this? I don't want to let this hang.
Personally, I'm still in favour of an article list the prefs, so long as
we put some warnings at the top, similar to the "This might void your
warranty!" page.
David Tenser
I wanted to wait for a response from mconnor to my last post since he's
in charge of Firefox development. I still think the information
regarding what the prefs to makes sense to include on SUMO, much like
we're hosting extensions on AMO that make use of said prefs.
Michael Connor
I think insofar as we will have issues where there's an about:config
workaround, we should have an article about how to use it. My issue
is that we should not be documenting prefs that aren't in the UI,
because those are often unsupported and untested codepaths. We
haven't gone through and purged them, but by documenting them and what
they do, you create an expectation from the user that these codepaths
are still supported. A prime example is the inline autoocomplete
pref, which works rather poorly in Fx3, because we are no longer
matching only the beginning of the string. It was a hidden pref for a
long time, but we never enabled it (due to a11y and usefulness issues)
and now it doesn't work well or at all (haven't looked recently). But
if we have docs telling users that the functionality is available,
there will be an expectation that we will preserve that functionality
in future.
Anything that is not exposed in the UI is fair game to be removed or
broken without notice, and without us putting time into fixing it.
I'm not going to engage in a discussion here about whether people
agree with that position, because its well out of scope for this
group, and more importantly, I don't think there's validity in the
idea that we should support the long tail with hidden prefs. In any
case, that's the current policy on the engineering side, and I do not
intend to change that, because that's a surefire way of continuing to
enable cruft to grow and prosper. Based on that, exposing unsupported
options to users is the wrong thing for the official support site is
missing the point entirely.
FWIW, I don't think the AMO comparison is correct. Official
documentation and a software hosting site have entirely different
implications to users, and the UI is also clear in the install case
that you're installing something and making a trust decision. At an
absolute minimum, the about:config how-to should have a large and
prominent warning, like anything that talks about editing the registry
is on Microsoft's support site, as an example.
-- Mike
Majken Connor
admin/contributor section. That way users can't find it, but we can. There
isn't really a good case to exposing the list to users as the best bet for
them is usually going to be to reset all the prefs from safe mode and set
things back from the UI. If they set a specific pref on purpose, and only
want to change that pref back they should be able to recognize which one it
was, or at least where they got the info to change it. If they were just
flipping random prefs and broke something, then they should really flip
everything back to default and start over.
For our purposes though it's good to know what prefs can cause what
symptoms, and if we still have the chart available we can still look it up
and ask the user if x pref has been changed, or make notes on it ourselves.
chris hofmann
Users will find information about a variety of prefs, and as we have
found will modify them in pretty high volume. We need to have good
documentation to stay ahead of the curve of how the information gets out
and is used...
check out this google search for "extensions.checkcompatibility"
you'll find numerous press articles that tell users about "how great the
new firefox beta is, and by the way, you can get around any extension
compatability problem by flipping this pref...." The reporters in
every case fail to provide the extra warning about instability problems
that can be created at startup, and throughout the operation of the
browser.
The mozillazine article (main source of information on this and other
prefs) only talks about instability at start up. The information is
buried at the bottom of the article, not at the top in big bold text and
it doesn't talk about the possibility of problems durning your whole
browser session, or a pretty long list of extensions and plugins that we
know are causing significant problems. All of these aspects should be
in a support article that we are producing...
So users, based on advice from technology reporters, are flipping this
pref and then we wind up with a very high volume of topcrashes related
to extension incompatibility. Its clear from their comments in the
crash reports that they don't understand the connection of flipping the
pref and the instability they are creating, and we aren't getting the
message out on this issue.
Provide good doc's on prefs and make the warnings strong and highly
visable .
-chofmann
Kevin Brosnan
suggested in media as tweaks to fix perceived problems and
performance. This list should stay quite short compared to
about:config. Of course this introduces the problem of how to decide
if the pref is notable enough.
My short list would include extensions.checkcompatibility,
network.http.pipelining, network.http.pipelining.maxrequests,
nglayout.initialpaint.delay, browser.cache.disk.capacity and
config.trim_on_minimize.
Kevin
mozillasup...@spamgourmet.com
Date: Thu, 1 May 2008 16:12:00 -0400
From: Michael Connor <mco...@mozilla.com>
Subject: Re: Is it a good idea to have an KB article describing
about:config?
To: support-...@lists.mozilla.org
Message-ID: <9D569284-EAA9-464A...@mozilla.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
I'm with mconnor that we shouldn't really have pages on specific
about:config options just because and definitely not hidden prefs.
But extending that discussion: what about userChrome and userContent?
Essentially, all userChrome changes are "hidden prefs" and people
could quite easily be copying and pasting in those files with no
regard for what they're doing. Maybe the way to go is to break the
Editing configuration page into two: 1) Customizing Firefox where we
discuss the UI ways to do things. 2) Changing configuration
(Advanced). Where we put a GIANT warning at the top saying that after
you make changes your browser could go to heck and back really really
fast (won't open, screwy pages, exploding pants) and that after you
make these changes, you may find it much harder to get support or that
future versions of Firefox may just randomly stop working. Also
provide details as to how to undo these changes (particularly deleting
userC*, user.js and prefs.js files)... Also adding that section to
basic troubleshooting.
--Cww.
PS, regarding the choose-a-forum debate. My feeling is this: The
newsgroup is only for discussion important or administrative enough to
go only to people who are subscribed to multiple newsgroups. That's
the MoCo employees and assorted other important people. For the
everyday contributor and the everyday contributor discussion, the
forums are better. I know I'm implying a hierarchy here and we're all
about no hierarchy but on the flip side, I'm really pushing to expand
the community and as such allow a good degree of off-topic discussion
and general mix-and-mingle and we need somewhere to do that. (I'm
actually all for a #contrib-chat as well...). If something that is
discussed in the forums needs the attention of the newsgroup, we can
always link or even transfer the discussion here entirely. If it's
something that doesn't even affect the everyday contributor or is a
policy thing that should be discussed in a small group first, start
here. Yes, this involves a judgment call and smash my head in with a
brick if I'm wrong but I think everyone here is capable of it.
(Myself excluded, of course.)
David Tenser
>
> Users will find information about a variety of prefs, and as we have
> found will modify them in pretty high volume. We need to have good
> documentation to stay ahead of the curve of how the information gets out
> and is used...
>
> check out this google search for "extensions.checkcompatibility"
>
> http://www.google.com/search?q=extensions.checkcompatibility&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
>
>
> you'll find numerous press articles that tell users about "how great the
> new firefox beta is, and by the way, you can get around any extension
> compatability problem by flipping this pref...." The reporters in
> every case fail to provide the extra warning about instability problems
> that can be created at startup, and throughout the operation of the
> browser.
> The mozillazine article (main source of information on this and other
> prefs) only talks about instability at start up. The information is
> buried at the bottom of the article, not at the top in big bold text and
> it doesn't talk about the possibility of problems durning your whole
> browser session, or a pretty long list of extensions and plugins that we
> know are causing significant problems. All of these aspects should be
> in a support article that we are producing...
>
>
> Provide good doc's on prefs and make the warnings strong and highly
> visable .
This is a very good point that I wanted to raise earlier: if we don't
provide the info in our knowledge base, others will. By hosting the info
on our "official" Firefox support channel, we are in control of it,
which is a way better situation than having people finding the info in
other places (which also has the side-effect of undermining SUMO's
chances of becoming the #1 Firefox support channel).
Taking a few steps back, we should ask ourselves: Do we want SUMO to
become the place for "official Firefox support," or do we rather want it
to become the official, best place for "Firefox user-to-user support"? I
say we should strive for the latter, meaning we should embrace the full
community effort behind the project and not exclude articles about
tweaking Firefox in ways we don't deem "official." In other words, we
should reevaluate the meaning of "official" in the context of
user-to-user support.
SUMO becoming the official, #1 Firefox support channel means:
1. Contributors turn to us to write content
2. We control the information and can make sure it's as accurate as
possible and provide appropriate warnings and links to related info
3. Users turn to us for the most reliable support information
4. Firefox support becomes "our property," meaning we can get accurate
metrics about article popularity, quality, etc.
5. Goto 1.
The above can only become a reality by giving the community more
control. That's why I think it would be a mistake to run the knowledge
base content through an "official support" filter, because the only
result would be that people would go to other support channels to find
the information instead, and we wouldn't become #1.
As already suggested, though, we should develop a framework where we tag
articles depending on their intended audience, for example: "Warning:
These instructions are not supported by Mozilla and may not work with
future versions of Firefox." See
https://bugzilla.mozilla.org/show_bug.cgi?id=410411 for an example of
how such tagging could easily be achieved in a consistent way. That way
we can make it clear that not all content is for everyone, while not
limiting SUMO to become a restricted support channel.
Michael Connor
On 5-May-08, at 7:40 AM, David Tenser wrote:
>>
>> Provide good doc's on prefs and make the warnings strong and highly
>> visable .
>
> This is a very good point that I wanted to raise earlier: if we don't
> provide the info in our knowledge base, others will. By hosting the
> info
> on our "official" Firefox support channel, we are in control of it,
> which is a way better situation than having people finding the info in
> other places (which also has the side-effect of undermining SUMO's
> chances of becoming the #1 Firefox support channel).
What's the point of control? Ensuring appropriate disclaimers seems
to be your only stated editorial goal, and that doesn't necessary
equate net benefit. Especially if it exposes more users to tweaking
stuff that shouldn't be tweaked. Users are known to ignore warnings,
and its unlikely that its a good use of our time to spend a lot of
time writing fully-disclosing info on tweaking stuff we don't want to
be tweaked by people.
> Taking a few steps back, we should ask ourselves: Do we want SUMO to
> become the place for "official Firefox support," or do we rather
> want it
> to become the official, best place for "Firefox user-to-user
> support"? I
> say we should strive for the latter, meaning we should embrace the
> full
> community effort behind the project and not exclude articles about
> tweaking Firefox in ways we don't deem "official." In other words, we
> should reevaluate the meaning of "official" in the context of
> user-to-user support.
Best does not mean "widest net" or "greatest quantity" of
information. When I contemplate the sheer volume of effort required
to write and translate articles (time to create article multiplied by
number of languages is a fairly decent baseline), I don't think I can
make a justification that we should document anything more than the
essential stuff we believe users _should_ know. A knowledge base is a
major undertaking if we're maintaining editorial control, and
increasing our coverage along the long tail has a relatively
prohibitive cost over time. I can think of a lot of better ways for
translators to spend their time, myself. I also suspect that the
tighter our focus, the easier it will be to maintain a full set of
high quality translations.
> SUMO becoming the official, #1 Firefox support channel means:
>
> 1. Contributors turn to us to write content
> 2. We control the information and can make sure it's as accurate as
> possible and provide appropriate warnings and links to related info
> 3. Users turn to us for the most reliable support information
> 4. Firefox support becomes "our property," meaning we can get accurate
> metrics about article popularity, quality, etc.
> 5. Goto 1.
>
> The above can only become a reality by giving the community more
> control. That's why I think it would be a mistake to run the knowledge
> base content through an "official support" filter, because the only
> result would be that people would go to other support channels to find
> the information instead, and we wouldn't become #1.
I don't think you're arguing this point well. You're asserting that
a) the community needs to have more control to participate and b) that
control means that we need to change the scope.
For a)
* What is critical is that the community believes in and backs the
mission of the project. Control isn't the requirement here, alignment
is.
* I believe that a large long tail of rarely used articles/data will
act as an impediment to getting effective l10n coverage. I could be
wrong, but l10n is resource constrained, and increasing the scope of
the project requires more resources. I don't think there's any
evidence that a larger scope of work will lead to an even larger corps
of volunteers.
For b)
* I think its a fallacy that the community, by definition, wants a
larger scope. With the exception of MozillaZine's KB, most of the
"ooh, let's tweak this setting and go fast" posts are on web forums,
blogs, or in the press. That isn't really our community. I haven't
seen a massive uproar to broaden the scope of what we document and
support, or people asserting that they won't participate if they can't
write about tweaking obscure prefs.
> As already suggested, though, we should develop a framework where we
> tag
> articles depending on their intended audience, for example: "Warning:
> These instructions are not supported by Mozilla and may not work with
> future versions of Firefox." See
> https://bugzilla.mozilla.org/show_bug.cgi?id=410411 for an example of
> how such tagging could easily be achieved in a consistent way. That
> way
> we can make it clear that not all content is for everyone, while not
> limiting SUMO to become a restricted support channel.
This is the low bar solution, but I don't think this particular case
is a net win, based on the total cost of having an article for this.
-- Mike
Chris Ilias
If I understand what you mean by "unsupported", it is that there is no
concern on the development side, if the pref no longer works at any
point in time. From a user's POV, I don't see the difference between
that and intentionally removing a feature, like the throbber link.
To the user, it's the same experience: feature is no longer there
(intentional or not).
For user support, our goal is to provide the best support possible. Our
obligation is to provide correct information. Things change with every
release; and we need to make sure the KB is up to date with every new
release. My only reservation is if we have the manpower to keep it all
update to date.
As manager of the Knowledge Base, my decision is that we should have the
article. (Unless David vetoes me decision.)
Chris Ilias
> Maybe a better comprise is to document prefs that are commonly
> suggested in media as tweaks to fix perceived problems and
> performance. This list should stay quite short compared to
> about:config. Of course this introduces the problem of how to decide
> if the pref is notable enough.
>
> My short list would include extensions.checkcompatibility,
> network.http.pipelining, network.http.pipelining.maxrequests,
> nglayout.initialpaint.delay, browser.cache.disk.capacity and
> config.trim_on_minimize.
A typical user path to this article is:
Question about Firefox --> Answer is to change a setting in about:config
--> User says "Wow, that's cool. Where can I find out what all the other
preferences are for?"
Listing a short number of prefs doesn't address the need for the article.
Michael Connor
The difference is that we actually put care and consideration into
removing intentional features and behaviours. This is indirectly
forcing us to consider anything documented as equal. That isn't an
acceptable direction for SUMO to take, IMO. I don't want to link to
SUMO from the app if it is creating unintended and unwanted user
expectations. The tail doesn't get to wag the dog.
> For user support, our goal is to provide the best support possible.
> Our
> obligation is to provide correct information. Things change with every
> release; and we need to make sure the KB is up to date with every new
> release. My only reservation is if we have the manpower to keep it all
> update to date.
The article itself isn't the issue. You're talking about documenting
things as features/options that we don't want exposed/supported as
features/options. It is not the place of the KB authors to dictate to
us what features are supported or not. Explaining how to use
about:config is vastly different from implicitly encouraging users to
rely on it as a source of new features. I have no problem with an
article detailing how to use it sanely, since there will be cases
where its needed to fix bugs (or in some cases, to explain the risks
of changing commonly cited prefs like pipelining etc). Supporting the
"oh cool, what do the rest of these things do?" user heads down a path
I do not want to encourage via any official avenues. I think its the
wrong thing to do, and I'm not going to accept it.
> As manager of the Knowledge Base, my decision is that we should have
> the
> article. (Unless David vetoes me decision.)
Trying to pull rank on me? That's probably not the horse you wanted
to bet on...
-- Mike
Jason Barnabe (np)
> Best does not mean "widest net" or "greatest quantity" of
> information. When I contemplate the sheer volume of effort required
> to write and translate articles (time to create article multiplied by
> number of languages is a fairly decent baseline), I don't think I can
> make a justification that we should document anything more than the
> essential stuff we believe users _should_ know. A knowledge base is a
> major undertaking if we're maintaining editorial control, and
> increasing our coverage along the long tail has a relatively
> prohibitive cost over time. I can think of a lot of better ways for
> translators to spend their time, myself. I also suspect that the
> tighter our focus, the easier it will be to maintain a full set of
> high quality translations.
These "long tail" articles are all coming from requests in the forum
or in live chat. I requested the Find Toolbar article because I
believed it would be a net benefit because it would make us not have
to answer it in forum and live chat the next time a user wants to
know.
If the cost of translating the article outweighs the benefit, then it
shouldn't be translated. I'm not aware of any requirement that every
article must be translated into every language we support.
Michael Connor
On 5-May-08, at 12:05 PM, Jason Barnabe (np) wrote:
> If the cost of translating the article outweighs the benefit, then it
> shouldn't be translated. I'm not aware of any requirement that every
> article must be translated into every language we support.
Its not a hard requirement, but its an essential goal. Translation
gets trickier if its not a 1:1 mapping, and I don't accept any
rationale that general articles are useful for en-US but not for other
locales. If its not useful enough for the other locales, why are we
spending time on it for en-US?
-- Mike
Chris Ilias
Not at all; but after almost a month of discussion, we tend to be going
in circles, and someone has to make the final decision. This is a KB
issue; so I'm trying to accept responsibility.
What is the "unwanted user expectation"?
Firefox Support is in no way trying to force developers to consider
unsupported features as equal. We're just trying to serve a high user
demand that is already there.
Jason Barnabe (np)
It's useful in any language. The difference is that en-US has the
resources to write it and has enough traffic in user-to-user support
to make it a net benefit. The same may not be true for every language.
David Tenser
It's not about an article being useful or not, it's about the cost vs
benefit. 1:1 l10n will never be a realistic goal, unless we completely
stopped all article editing now and only focused on l10n from here on.
As long as the majority of our users and community are using an English
copy of Firefox, the en-US content on SUMO will have the upper edge.
That doesn't mean an article can't be useful even if it's just available
in one language.
Anyway, this seems besides the main point you're making, which I'll
respond to in the other branch.
David Tenser
>
> On 5-May-08, at 11:23 AM, Chris Ilias wrote:
>
>> If I understand what you mean by "unsupported", it is that there is no
>> concern on the development side, if the pref no longer works at any
>> point in time. From a user's POV, I don't see the difference between
>> that and intentionally removing a feature, like the throbber link.
>> To the user, it's the same experience: feature is no longer there
>> (intentional or not).
>
> The difference is that we actually put care and consideration into
> removing intentional features and behaviours. This is indirectly
> forcing us to consider anything documented as equal.
This is where the general disagreement is, I think. Many people in this
thread don't put an equal sign between "documented, unsupported pref"
and "supported feature."
Your assumption that this would lead to unwanted user expectations seems
more theoretical than anything else, because in practice we can make it
very clear whether or not a pref is a supported feature.
> That isn't an
> acceptable direction for SUMO to take, IMO. I don't want to link to
> SUMO from the app if it is creating unintended and unwanted user
> expectations. The tail doesn't get to wag the dog.
>
>> For user support, our goal is to provide the best support possible. Our
>> obligation is to provide correct information. Things change with every
>> release; and we need to make sure the KB is up to date with every new
>> release. My only reservation is if we have the manpower to keep it all
>> update to date.
>
> The article itself isn't the issue. You're talking about documenting
> things as features/options that we don't want exposed/supported as
> features/options. It is not the place of the KB authors to dictate to
> us what features are supported or not.
I think everyone agrees with you there. But by writing about something,
we don't automatically support or encourage the use of it. We're just
improving the situation for a user who would otherwise read potentially
incorrect info elsewhere.
> Explaining how to use
> about:config is vastly different from implicitly encouraging users to
> rely on it as a source of new features.
Certainly. We should be very careful to not encourage people to use
features we don't support.
> I have no problem with an
> article detailing how to use it sanely, since there will be cases where
> its needed to fix bugs (or in some cases, to explain the risks of
> changing commonly cited prefs like pipelining etc).
Fwiw, an about:config usage guide and an about:config pref reference
would be two separate article anyway, so the answer to the OP's question
in the topic is "yes."
> Supporting the "oh
> cool, what do the rest of these things do?" user heads down a path I do
> not want to encourage via any official avenues. I think its the wrong
> thing to do, and I'm not going to accept it.
Based on your assumptions, your standpoint is understandable. I don't
think your assumptions are without doubt, though.
>
>> As manager of the Knowledge Base, my decision is that we should have the
>> article. (Unless David vetoes me decision.)
It's not your decision to make, Chris. I understand your intentions to
speed up this long-winded discussion, but leave the decision making part
to me ok? :)
David Tenser
>
> On 5-May-08, at 7:40 AM, David Tenser wrote:
>
>>>
>>> Provide good doc's on prefs and make the warnings strong and highly
>>> visable .
>>
>> This is a very good point that I wanted to raise earlier: if we don't
>> provide the info in our knowledge base, others will. By hosting the info
>> on our "official" Firefox support channel, we are in control of it,
>> which is a way better situation than having people finding the info in
>> other places (which also has the side-effect of undermining SUMO's
>> chances of becoming the #1 Firefox support channel).
>
> What's the point of control?
* making sure we provide the most accurate and up-to-date information on
the subject
* making sure we provide appropriate warnings and disclaimers.
* getting valid data on the popularity of the article
* ensuring that people find the information on sumo and not on other
sites, which helps maintaining our position as the primary location for
Firefox support for both users and contributors.
The last bullet should not be underestimated.
> Ensuring appropriate disclaimers seems to
> be your only stated editorial goal, and that doesn't necessary equate
> net benefit.
That and the ability to make sure the information is 100% correct,
rather than relying on third parties to provide sometimes questionable
information.
> Especially if it exposes more users to tweaking stuff that
> shouldn't be tweaked. Users are known to ignore warnings, and its
> unlikely that its a good use of our time to spend a lot of time writing
> fully-disclosing info on tweaking stuff we don't want to be tweaked by
> people.
Of course, users are known to look elsewhere if the information can't be
found on our servers too, so we have to weigh the disadvantage of users
reading the info on our site against the potentially greater
disadvantage of reading the info from an unreliable third party.
>> Taking a few steps back, we should ask ourselves: Do we want SUMO to
>> become the place for "official Firefox support," or do we rather want it
>> to become the official, best place for "Firefox user-to-user support"? I
>> say we should strive for the latter, meaning we should embrace the full
>> community effort behind the project and not exclude articles about
>> tweaking Firefox in ways we don't deem "official." In other words, we
>> should reevaluate the meaning of "official" in the context of
>> user-to-user support.
>
> Best does not mean "widest net" or "greatest quantity" of information.
> When I contemplate the sheer volume of effort required to write and
> translate articles (time to create article multiplied by number of
> languages is a fairly decent baseline), I don't think I can make a
> justification that we should document anything more than the essential
> stuff we believe users _should_ know. A knowledge base is a major
> undertaking if we're maintaining editorial control, and increasing our
> coverage along the long tail has a relatively prohibitive cost over
> time. I can think of a lot of better ways for translators to spend
> their time, myself. I also suspect that the tighter our focus, the
> easier it will be to maintain a full set of high quality translations.
>
This is a separate point that I won't focus on here (but the short
version is that even with the current, relatively tight troubleshooting
focus, we'll likely never reach l10n completeness on 200+ articles.)
>> SUMO becoming the official, #1 Firefox support channel means:
>>
>> 1. Contributors turn to us to write content
>> 2. We control the information and can make sure it's as accurate as
>> possible and provide appropriate warnings and links to related info
>> 3. Users turn to us for the most reliable support information
>> 4. Firefox support becomes "our property," meaning we can get accurate
>> metrics about article popularity, quality, etc.
>> 5. Goto 1.
>>
>> The above can only become a reality by giving the community more
>> control. That's why I think it would be a mistake to run the knowledge
>> base content through an "official support" filter, because the only
>> result would be that people would go to other support channels to find
>> the information instead, and we wouldn't become #1.
>
> I don't think you're arguing this point well. You're asserting that a)
> the community needs to have more control to participate and b) that
> control means that we need to change the scope.
a) Not really, but they need to feel their contributions are rejected
for good reasons and that they can write about stuff that matters to
people. We still have the control with policies, the review system, the
metrics, etc.
b) Yes, we need to change the scope. Or, rather, we need to define the
scope more clearly.
>
> For a)
>
> * What is critical is that the community believes in and backs the
> mission of the project. Control isn't the requirement here, alignment is.
I agree with that.
> * I believe that a large long tail of rarely used articles/data will act
> as an impediment to getting effective l10n coverage. I could be wrong,
> but l10n is resource constrained, and increasing the scope of the
> project requires more resources. I don't think there's any evidence
> that a larger scope of work will lead to an even larger corps of
> volunteers.
This is besides the point, but see above for my comment on l10n.
>
> For b)
>
> * I think its a fallacy that the community, by definition, wants a
> larger scope. With the exception of MozillaZine's KB, most of the "ooh,
> let's tweak this setting and go fast" posts are on web forums, blogs, or
> in the press. That isn't really our community. I haven't seen a
> massive uproar to broaden the scope of what we document and support, or
> people asserting that they won't participate if they can't write about
> tweaking obscure prefs.
The bottom line is that I think a user-to-user support site should be
more than just "solving a problem." It should be about teaching how to
use Firefox, how to increase your efficiency, how to better utilize the
full power of Firefox. This is an important aspect of building a vibrant
community around the project and establishing SUMO as the primary
resource for both end-users and contributors. And yes, this has to do
with the scope.
That said, this is more about setting a sensible bar on the kind of
tweaking we "allow," or how high the demand needs to be before we add
it. The key here would be user demand / popularity of the tweak.
There will always be a high number of about:config prefs that _are_
tested and supported, and those are typical tweaks that I think we
should include without hesitation, as long as it provides a benefit to
the user. Typically this would be stuff like OS-dependent prefs (middle
click on location bar, Backspace key behavior, etc) but also
accessibility stuff like accessibility.typeaheadfind.linksonly.
Basically things with known code paths.
Then there will be stuff that we'd rather people didn't touch. In these
cases, the user demand / popularity bar would have to be much higher. We
should deal with them on a case by case basis and I'd be happy to get
input from you and your team when such cases arise. I agree with you
that we shouldn't create unnecessary problems by including _anything_ in
the knowledge base, because that will likely not improve the situation
for our users anyway. But if there's something that's heavily written
about elsewhere on e.g. tech blogs, etc, and it turns out our users are
asking for this regularly, I think we owe it to our users to include the
most correct version of that info on SUMO. There, we would also have the
opportunity to make it clear the information is *not* supported by
Mozilla, as well as explaining the potential risks of testing it.
>
>> As already suggested, though, we should develop a framework where we tag
>> articles depending on their intended audience, for example: "Warning:
>> These instructions are not supported by Mozilla and may not work with
>> future versions of Firefox." See
>> https://bugzilla.mozilla.org/show_bug.cgi?id=410411 for an example of
>> how such tagging could easily be achieved in a consistent way. That way
>> we can make it clear that not all content is for everyone, while not
>> limiting SUMO to become a restricted support channel.
>
> This is the low bar solution, but I don't think this particular case is
> a net win, based on the total cost of having an article for this.
>
I assume you mean an article listing all about:config prefs. The real
cost of such an article is theoretical because you're basing it on the
assumption that people would use it as a way to tweak Firefox _without
realizing the risks_. I think we could make that risk clear by adding
both a disclaimer at the top, and a simple "Not fully tested or
supported" in the description of every pref we don't want to support. As
I said previously, the estimated net win also needs to incorporate the
fact that people would otherwise find this information elsewhere, with
potentially incorrect info and without any warnings whatsoever.
That said, I think we should hold of a discussion about an about:config
reference until we've settled on the general issue with the scope.
For now, we need an article describing _how to use_ about:config because
we're referring to in in all sorts of articles, including product help.
Let's focus on that first.
Michael Connor
On 6-May-08, at 7:45 AM, David Tenser wrote:
> Michael Connor wrote:
>>
>> On 5-May-08, at 11:23 AM, Chris Ilias wrote:
>>
>>> If I understand what you mean by "unsupported", it is that there
>>> is no
>>> concern on the development side, if the pref no longer works at any
>>> point in time. From a user's POV, I don't see the difference between
>>> that and intentionally removing a feature, like the throbber link.
>>> To the user, it's the same experience: feature is no longer there
>>> (intentional or not).
>>
>> The difference is that we actually put care and consideration into
>> removing intentional features and behaviours. This is indirectly
>> forcing us to consider anything documented as equal.
>
> This is where the general disagreement is, I think. Many people in
> this
> thread don't put an equal sign between "documented, unsupported pref"
> and "supported feature."
>
> Your assumption that this would lead to unwanted user expectations
> seems
> more theoretical than anything else, because in practice we can make
> it
> very clear whether or not a pref is a supported feature.
The sheer presence of these prefs has led to user expectations in the
past. Look at the outcry/backlash over removing
browser.urlbar.richResults, and that was only in a couple of betas. I
don't think its theoretical to assume that exposing more users to
these prefs will increase the number of users who have an expectation
that they will continue to work.
>>> For user support, our goal is to provide the best support
>>> possible. Our
>>> obligation is to provide correct information. Things change with
>>> every
>>> release; and we need to make sure the KB is up to date with every
>>> new
>>> release. My only reservation is if we have the manpower to keep it
>>> all
>>> update to date.
>>
>> The article itself isn't the issue. You're talking about documenting
>> things as features/options that we don't want exposed/supported as
>> features/options. It is not the place of the KB authors to dictate
>> to
>> us what features are supported or not.
>
> I think everyone agrees with you there. But by writing about
> something,
> we don't automatically support or encourage the use of it. We're just
> improving the situation for a user who would otherwise read
> potentially
> incorrect info elsewhere.
Sorry, bad logic. You're assuming that the set of users who will find
and use these prefs will remain static, its just the quality of the
information. Including this info in the official support site,
especially the one we link to from the app, will absolutely result in
an increase in the number of people exposed to the information.
Information that, unless they're _looking_ for it, is almost certainly
not what we want them to find.
>> Explaining how to use
>> about:config is vastly different from implicitly encouraging users to
>> rely on it as a source of new features.
>
> Certainly. We should be very careful to not encourage people to use
> features we don't support.
By documenting it, and telling about the benefits, you are going to do
so. Even if you explain the potential consequences, you end up
creating a false positive effect "well, I changed those other four
things, nothing bad happened then."
>> Supporting the "oh
>> cool, what do the rest of these things do?" user heads down a path
>> I do
>> not want to encourage via any official avenues. I think its the
>> wrong
>> thing to do, and I'm not going to accept it.
>
> Based on your assumptions, your standpoint is understandable. I don't
> think your assumptions are without doubt, though.
I know. I think your doubts are based on bad assumptions. :)
-- Mike
Michael Connor
en-US isn't the majority. It hasn't been for about a year. Its the
largest userbase still by a long shot, but we also want to change
that. I would love to see China take over top spot, f.e.
IMO, there is a ton of useful content on the web for en-US. We need
to make l10n a priority if we want to tap into growing markets, so I'd
rather ramp down on en-US and focus on enhancing our l10n support, if
there has to be a choice.
-- Mike
David Tenser
>
> On 6-May-08, at 7:43 AM, David Tenser wrote:
>
>> Michael Connor wrote:
>>>
>>> On 5-May-08, at 12:05 PM, Jason Barnabe (np) wrote:
>>>
>>>> If the cost of translating the article outweighs the benefit, then it
>>>> shouldn't be translated. I'm not aware of any requirement that every
>>>> article must be translated into every language we support.
>>>
>>> Its not a hard requirement, but its an essential goal. Translation gets
>>> trickier if its not a 1:1 mapping, and I don't accept any rationale that
>>> general articles are useful for en-US but not for other locales. If its
>>> not useful enough for the other locales, why are we spending time on it
>>> for en-US?
>>
>> It's not about an article being useful or not, it's about the cost vs
>> benefit. 1:1 l10n will never be a realistic goal, unless we completely
>> stopped all article editing now and only focused on l10n from here on.
>>
>> As long as the majority of our users and community are using an English
>> copy of Firefox, the en-US content on SUMO will have the upper edge.
>> That doesn't mean an article can't be useful even if it's just available
>> in one language.
>
> en-US isn't the majority. It hasn't been for about a year. Its the
> largest userbase still by a long shot, but we also want to change that.
> I would love to see China take over top spot, f.e.
>
Didn't say en-US, but English in general. Last time I asked Ken Kovash,
the figure was "over 50%" English Firefox downloads. That is a majority
by definition. :)
> IMO, there is a ton of useful content on the web for en-US. We need to
> make l10n a priority if we want to tap into growing markets, so I'd
> rather ramp down on en-US and focus on enhancing our l10n support, if
> there has to be a choice.
>
Not saying l10n is not a priority, but 1:1 l10n mapping will never be a
reasonable goal. Anyway, this was in reply to you saying
Chris Ilias
Ok. I'm glad that part is clear. :-)
Chris Ilias
> The sheer presence of these prefs has led to user expectations in the
> past. Look at the outcry/backlash over removing
> browser.urlbar.richResults, and that was only in a couple of betas. I
> don't think its theoretical to assume that exposing more users to these
> prefs will increase the number of users who have an expectation that
> they will continue to work.
Users expected the throbber link to still work as well. If I understand
you correctly, you're saying that including documentation about
unsupported prefs just *increases the probability* of users running into
settings that no longer work.
> Sorry, bad logic. You're assuming that the set of users who will find
> and use these prefs will remain static, its just the quality of the
> information. Including this info in the official support site,
> especially the one we link to from the app, will absolutely result in an
> increase in the number of people exposed to the information.
> Information that, unless they're _looking_ for it, is almost certainly
> not what we want them to find.
I think we are in agreeance here. My argument is that people /are/
looking for it. So how do we make sure the people looking for it find
it; and the people not looking for it don't find it?
Chris Ilias
> For now, we need an article describing _how to use_ about:config because
> we're referring to in in all sorts of articles, including product help.
> Let's focus on that first.
We've already got one:
<http://support.mozilla.com/kb/Editing+configuration+files>
But it isn't really needed, because in all cases where we instruct users
to use about:config, every step is laid out.
Justin Wood (Callek)
> Not saying l10n is not a priority, but 1:1 l10n mapping will never be a
> reasonable goal. Anyway, this was in reply to you saying
>
>> I don't accept any rationale that general articles are useful for
>> en-US but not for other locales.
I'll just mention that I feel that a reverse mapping *should* remain
possible. If China for example gets more users (even if just sumo
contributors) *they* should remain allowed to create china-only content
that en-* so-far does not have, (though, imo there *should* be some sort
of indication that en-US needs the content in such cases).
The idea here, is that where there are resources to benefit our
knowledge base, we should use it. And not limit ourselves to "Does xyz
locale have the resources to keep up." We should strive for the best
ratio we can, and the best content we can in all languages, but if the
cost to benefit ratio on specific articles gets better, we should allow
said articles to exist.
Perhaps there is a virus scanner only released in Chinese that causes
problems, great, China should have an article on it. (and en-US *may*
choose to have an article on it, though en-US's cost-benifit will be far
far worse than china's in terms of "should this article exist").
Such that there could be Virus scanners only released in english that
the cost-benefit for the translated articles will make them be far lower
of a priority for non english.
--
~Justin Wood (Callek)
Majken Connor
touch a little on everything I think, but first of all, let me start with an
article that lists about:config prefs.
A *chart* of the prefs doesn't help users at all, except to expose them to
prefs they had no idea existed, as mconnor is saying. It helps us. It
gives us one place to organize all the info, one place to point users from
other articles etc. We've got two use cases we're looking at:
1) users who will find the article because they're looking for a specific
pref or function
There's no reason to expose these users to a complete list.
2) users who want to find the list so they can go through and flip lots of
things without already having an idea of a specific function they were
looking for
These users should find the article about about:config that tells them
simply "don't." We don't want to give these users a chart simply because
they think they want it. What they want to know is "what other cool stuff
can firefox do?" They don't find that out by reading a chart of unsupported
prefs. We want to send these people to our tutorials and to add-ons, or
maybe even developer level documentation since these prefs are for devs (I
think that would set a high enough barrier, but still solve the problem of
pointing the determined user to reliable docs).
I'll reiterate where I think this chart *is* useful, though, and where I
think we should put it. This chart is useful for the case where someone has
gone flipping prefs, or installed something that did, and we get them via
forums or live chat with an odd symptom. In *this* case, we'll probably
want to know what pref was flipped so we can document the cause. If we make
it a contributor document, we can still make use of the information without
exposing users to it.
We have to remember that users are going to want to do things that they
shouldn't. Our job isn't to tell them how to do it anyway and especially
not just because someone else will. Our job is to know what users want
better than they do, and to help them figure out what they really want how
to do it the *right* way.
Majken Connor
> become the place for "official Firefox support," or do we rather want it
> to become the official, best place for "Firefox user-to-user support"? I
> say we should strive for the latter, meaning we should embrace the full
> community effort behind the project and not exclude articles about
> tweaking Firefox in ways we don't deem "official." In other words, we
> should reevaluate the meaning of "official" in the context of
> user-to-user support.
user-to-user support can't be "official." What we have right now is user-*
to-mozilla*-to-user support. We did this on purpose for some very important
reasons.
Mozilla and Firefox are now more than cool open source projects. They're a
brand. Users have specific expectations of quality and trust. This is a
similar to the debate about the update path for suite users. Seamonkey
isn't "official." Mozilla doesn't have the same oversight over it, there is
no guarantee that every Seamonkey release will be of a good enough quality
to live up to the trust relationship the user has with Mozilla. As far as I
understood SUMO was created to give users a support environment that also
lives up to the relationship of trust developed between Mozilla and the
user. In my opinion, we absolutely should not re-evaluate the meaning of
"official" nor do I believe we could without affecting the trust
relationship for Mozilla as a *whole,* not just support.
>
>
> SUMO becoming the official, #1 Firefox support channel means:
>
> 1. Contributors turn to us to write content
> 2. We control the information and can make sure it's as accurate as
> possible and provide appropriate warnings and links to related info
> 3. Users turn to us for the most reliable support information
> 4. Firefox support becomes "our property," meaning we can get accurate
> metrics about article popularity, quality, etc.
> 5. Goto 1.
I think this is wrong once you take it out of the context of it must be
user-to-user support.
1. Someone, somewhere (paid or unpaid) writes content
2. Mozilla reviews and endorses the content
3. Users turn to us because they trust our brand
(optional 4. Link to us from the app)
That's all that's needed for Firefox to become the #1 support channel. I
don't believe we even have to do a great job of maintaining the content to
still get more hits than a vibrant functioning community. So long as the
content is accurate, users will come to us first, then look elsewhere if we
didn't answer the question. Obviously though, we care about the users and
would like another step
5. Someone somewhere (paid or unpaid) maintains and updates the content, go
back to step 2.
>
>
> The above can only become a reality by giving the community more
> control. That's why I think it would be a mistake to run the knowledge
> base content through an "official support" filter, because the only
> result would be that people would go to other support channels to find
> the information instead, and we wouldn't become #1.
Actually, I believe the result would be users would go to the forum where
there is a much clearer expectation that this is user-to-user with oversight
from mozilla.
>
>
> As already suggested, though, we should develop a framework where we tag
> articles depending on their intended audience, for example: "Warning:
> These instructions are not supported by Mozilla and may not work with
> future versions of Firefox." See
> https://bugzilla.mozilla.org/show_bug.cgi?id=410411 for an example of
> how such tagging could easily be achieved in a consistent way. That way
> we can make it clear that not all content is for everyone, while not
> limiting SUMO to become a restricted support channel.
>
Each component of SUMO is unique in every way - how it benefits the users,
how users interact with it and what users expect out of it. As soon as we
stop making it a priority to avoid having to answer questions in the forums
repetitively there's no reason not to let the KB have a more official scope.
We've talked a lot about in an ideal situation the forums and live chat get
no traffic because anything a user wants to know is already in the KB, but I
think we need to clarify that ideal. What we want to be covered in the KB is
what's within our scope. What's good for the users, what do users *need* to
know. That can still be fairly open ended, but I think the good standard is
what to users need to know to continue successfully using Firefox. We'll
still have a lot of grey area, but this leaves us more room to leave less
important (or official) things out of the KB unless it's a question that's
asked fairly frequently.
Majken Connor
wrote:
>
>
>
> Not saying l10n is not a priority, but 1:1 l10n mapping will never be a
> reasonable goal.
This is a very broad statement. I'll admit I haven't been following l10n
discussions much as they're usually out of my scope, but did I miss
something about this?
chris hofmann
Majken Connor wrote:
> On Tue, May 6, 2008 at 10:15 AM, David Tenser <djst.m...@gmail.com>
> wrote:
>
>
>>
>> Not saying l10n is not a priority, but 1:1 l10n mapping will never be a
>> reasonable goal.
>>
>
>
> This is a very broad statement. I'll admit I haven't been following l10n
> discussions much as they're usually out of my scope, but did I miss
> something about this?
>
better to say that full 1:1 mapping for simulatenous release of sumo
content will be difficult to achieve for a number of reasons.
we haven't yet gotten to the point that all localizations have produced
fully localizated help in all the localizations we ship. gettting
closer, and having the content on-line will make it achievable *after*
releases ship now, but still not there yet...
we are overwhelming small localization teams with increasing translation
work. we now have firefox product, web parts, amo, tens to hundreds
of extensions that might be interesting for general use or specific to
locales, and sumo. plus devmo and other developer resources where
localization is going on. In addition some locale teams are still
putting effort into sites that have been around for awhile and haven't
made the transition to sumo as the primary/offical source for support
information.
community building and increased participation in many locales needs to
happen before we can realistically start knocking down some of these
barriers and shooting for near 1:1 simulataneous release of content on sumo.
-chofmann
Majken Connor
>
>
> Majken Connor wrote:
> > On Tue, May 6, 2008 at 10:15 AM, David Tenser <djst.m...@gmail.com>
> > wrote:
> >
> >
> >>
> >> Not saying l10n is not a priority, but 1:1 l10n mapping will never be a
> >> reasonable goal.
> >>
> >
> >
> > This is a very broad statement. I'll admit I haven't been following
> l10n
> > discussions much as they're usually out of my scope, but did I miss
> > something about this?
> >
>
> better to say that full 1:1 mapping for simulatenous release of sumo
> content will be difficult to achieve for a number of reasons.
>
> we haven't yet gotten to the point that all localizations have produced
> fully localizated help in all the localizations we ship. gettting
> closer, and having the content on-line will make it achievable *after*
> releases ship now, but still not there yet...
>
> we are overwhelming small localization teams with increasing translation
> work. we now have firefox product, web parts, amo, tens to hundreds
> of extensions that might be interesting for general use or specific to
> locales, and sumo. plus devmo and other developer resources where
> localization is going on. In addition some locale teams are still
> putting effort into sites that have been around for awhile and haven't
> made the transition to sumo as the primary/offical source for support
> information.
>
> community building and increased participation in many locales needs to
> happen before we can realistically start knocking down some of these
> barriers and shooting for near 1:1 simulataneous release of content on
> sumo.
>
> -chofmann
>
So it's something that's going to take time, basically, and requires
specific measures to be taken. Simultaneous is also an interesting word. I
think there are definitely acceptable time delays that would let us still
say we've achieved 1:1. Of course, that's still within a certain set of
constraints. Obviously if we're relying on it being entirely community led,
sure. 1:1 itself though could easily be achieved if we paid someone to
translate the content though. So the question really is what barriers do we
need to break through and what are we willing to do to break through them.
Axel Hecht
By all experience, paid content is bad content. Let's not go there. It's
a lesson that's taught inside the Mozilla ecosystem and outside.
That said:
I think that we should try to get at least the in-product parts of SUMO
localized for product launch. The key advantage of having help on the
net is not to not have it, but to unbind the translation of help from
code freezes, and to be able to quickly adapt to new challenges in the
wild for user support.
For the general KB content, it really depends on the tools available to
find localizable content for a particular locale.
1:1 is an optimistic goal there, but there are more opportunistic ones,
that are more rewarding to community contributors. Even more so if there
are metrics that expose that.
Axel
Cheng Wang
Is that really what we want? I'm still with Mike Connor that people who
are looking for it should have to ask someone knowledgeable.
I'm going to suggest a compromise (although it's not much of one). List
all settings but NOT what they do, unless it's frequently changed/abused.
The use case I'm thinking of is the following: O-hay resetting
print.printer_ThisPrinterBroke settings fixed that. I wonder if I
should reset all the other non-defaults... or even what they mean. So
we have a table listing: Name of preference, and then one of three things:
1) It corresponds to something in the UI, whereupon we give directions
to the UI control.
2) Something that has a minor effect when changed (like middle click
loads bookmarks in current tab or something) so we give a description of
what the possible states mean.
3) A warning: *changing this setting can break Firefox, if it's listed
as user set, reset by right clicking and selecting reset unless
explicity instructed otherwise by someone experienced.*
That way users know what's "safe" to play with and and what isn't and
what they should reset if they have problems.
Chris Ilias
> Whew! This is covering a lot more territory than last I looked. I'd like to
> touch a little on everything I think, but first of all, let me start with an
> article that lists about:config prefs.
>
> A *chart* of the prefs doesn't help users at all, except to expose them to
> prefs they had no idea existed, as mconnor is saying. It helps us. It
> gives us one place to organize all the info, one place to point users from
> other articles etc.
I can't think of any reason to point to it from another article.
> We've got two use cases we're looking at:
>
> 1) users who will find the article because they're looking for a specific
> pref or function
>
> There's no reason to expose these users to a complete list.
>
> 2) users who want to find the list so they can go through and flip lots of
> things without already having an idea of a specific function they were
> looking for
I think that's a little unfair. :-) The user's intent is to find out
what each pref does. If a user just wanted to flip lots of prefs without
any idea of what they did, they wouldn't go looking for a chart in the
first place.
David Tenser
What I mean in the context of this thread is that we shouldn't base our
scope on the likeliness of getting an article localized into 50+
locales. That doesn't define the value of the article. Instead, we
should base our scope on our intended target audience and what we think
is helpful to the user, which I believe is the essence of this thread,
and is what I'd like to focus on here.
Fwiw, l10n is a huge priority for SUMO -- almost all we do touch on it;
from planning, designing and implementing, to feedback gathering and
community building.
David Tenser
> We've talked a lot about in an ideal situation the forums and live chat get
> no traffic because anything a user wants to know is already in the KB, but I
> think we need to clarify that ideal. What we want to be covered in the KB is
> what's within our scope. What's good for the users, what do users *need* to
> know. That can still be fairly open ended, but I think the good standard is
> what to users need to know to continue successfully using Firefox. We'll
> still have a lot of grey area, but this leaves us more room to leave less
> important (or official) things out of the KB unless it's a question that's
> asked fairly frequently.
OK, I'll start from here, as this is closest to what I think is the
right approach moving forward.
Let's figure out the target audience for SUMO. Who are we trying to
help? The short answer is that we're trying to help normal users, people
who use their browser to surf the web -- people like my mom (bad
example; she gets my personal help!). "End users" is a broad term and
"typical users" is misused, so maybe "end-end-users" paints a clearer
picture.
As I said before, there are valid uses of certain prefs in about:config.
Typical examples of helpful content is on prefs that are tested and
supported, e.g. OS-dependent prefs like browser.backspace_action or
middlemouse.paste -- but more generally, prefs that we can reliably
support and that is helpful to our users, like
accessibility.typeaheadfind.linksonly. However, we need to draw the line
where it stops being helpful to users and where it actually risks
becoming a disservice.
The key here is whether or not the content is helpful for our target
audience. We're not here to provide all tricks possible. That kind of
content is probably more suitable on DevMo.
That said, there is always going to be a gray area, and we should use
our best judgments to figure out where to draw the right line. An
important aspect to consider is when we have evidence there's a high
volume of interest (which we can easily gauge using e.g. the forum), or
misuse (a typical example would be extension.compatibilityCheck, where
we really need to explain why using it is generally a bad idea, instead
of having people find this info in places where the whole store isn't told).
Drawing the line is the hard part, but what this boils down to is that
we should remember who we're trying to help.
After reflecting on this, it becomes clear that a reference article for
about:config prefs really isn't something that's helpful to our target
audience. It would be a much better fit on DevMo, which is more targeted
towards people hacking on their browser.
chris hofmann
djst and I kicked this around and it makes a lot of sense. It could
also be simpilfied into what we might call *the "monkey test".*
Does the article *help fix a problem*?, or does it just *help someone
"monkey around*"? with their browser...
If we set the criteria for SUMO as a site that helps fix problems, and
devmo and wikimo as the places to go to learn how and get information
about how to monkey around with and develop on the platform a lot of the
decisions and the goals for the site become more clear, and the users
will be served better. SUMO stays a lot more simple and directed at
end users trying to fix problems.
It would be great if someone took an inventory of the current articles
to figure out if this dividing line is helpful. the about:config
article as written would easily be classied as removed or moved to devmo
under this criteria, but are there other harder cases to deal with?
I know that we had or were considering more "tips and tricks" kinds of
articles and they might be harder to deal with under this evaluation
criteria.
-chofmann
David Tenser
Can't believe how I failed to name the monkey test. :)
> Does the article *help fix a problem*?, or does it just *help someone
> "monkey around*"? with their browser...
>
> If we set the criteria for SUMO as a site that helps fix problems, and
> devmo and wikimo as the places to go to learn how and get information
> about how to monkey around with and develop on the platform a lot of the
> decisions and the goals for the site become more clear, and the users
> will be served better. SUMO stays a lot more simple and directed at
> end users trying to fix problems.
>
> It would be great if someone took an inventory of the current articles
> to figure out if this dividing line is helpful. the about:config
> article as written would easily be classied as removed or moved to devmo
> under this criteria, but are there other harder cases to deal with?
This should indeed be the next step here.
>
> I know that we had or were considering more "tips and tricks" kinds of
> articles and they might be harder to deal with under this evaluation
> criteria.
We must not forget the basic information on how to use Firefox:
how-to:s, tutorials, tips and tricks.
Not "monkey" tips and tricks that are better suited elsewhere. Most
people would find an article that shows you how to hold down Ctrl and
scroll to zoom in/out would be helpful (problem: "how can I make the
text larger?"). However, not many people would find an article about
using userChrome.css to put the Sidebar on the right side useful, and it
has clearly bordered hacking the browser.
So in this context, fixing a problem can mean teaching how to remove a
bookmark, or how to make the Backspace key work as Back as it did in
Windows.
Justin Wood (Callek)
I am concerned with implications in "3", where if its listed as user set
it could possibly be an extension that changed it to. And extension
authors may rely on the non-UI-exposed setting for their extension to
work, (set via a firstrun pref) or some such.
The extension may also have UI associated with the pref, and makes sure
to expose it in correct (and possibly even "extension-supported" ways.
Advising users to change that back can be problematic (easier just to
uninstall extensions/safe-mode/etc. and/or if there is a specific reason
to reset it.
--
~Justin Wood (Callek)
Justin Wood (Callek)
To clarify my agreement: Basic information should be on *all* user
exposed features. I mean Zooming, keyboard shortcuts, RSS/Feeds, etc.
Possibly even some tips and tricks outlining some popular extensions.
> Not "monkey" tips and tricks that are better suited elsewhere. Most
> people would find an article that shows you how to hold down Ctrl and
> scroll to zoom in/out would be helpful (problem: "how can I make the
> text larger?").
Agreed!
> However, not many people would find an article about
> using userChrome.css to put the Sidebar on the right side useful, and it
> has clearly bordered hacking the browser.
In my opinion, a simple "Is it possible to change where the Sidebar
appears?" article might be good. "Yes but it involves some developer
knowledge, (of CSS mostly) if you think you feel comfortable doing this,
you can see the "userChrome.css" article on the [[Mozilla Developer
Center]]" basically keep it very simple for users, and provide proper
gateways to the developer docs for those people who might feel
comfortable doing it. (but might not otherwise know of our developer
documentation)
> So in this context, fixing a problem can mean teaching how to remove a
> bookmark, or how to make the Backspace key work as Back as it did in
> Windows.
--
~Justin Wood (Callek)
Majken Connor
wrote:
>
>
>
> In my opinion, a simple "Is it possible to change where the Sidebar
> appears?" article might be good. "Yes but it involves some developer
> knowledge, (of CSS mostly) if you think you feel comfortable doing this,
> you can see the "userChrome.css" article on the [[Mozilla Developer
> Center]]" basically keep it very simple for users, and provide proper
> gateways to the developer docs for those people who might feel
> comfortable doing it. (but might not otherwise know of our developer
> documentation)
>
>
I'm not sure I'd go there. I think those are suitable questions for the
forums and live chat. If we're answering them a lot, then we want to talk to
the dev team about the demand and go from there. Maybe we want to have a
basic article about how to do things that aren't already covered in the UI,
and point to add-ons etc.
David Tenser
> On Thu, May 8, 2008 at 8:58 PM, Justin Wood (Callek) <Cal...@gmail.com>
> wrote:
>
>>
>>
>> In my opinion, a simple "Is it possible to change where the Sidebar
>> appears?" article might be good. "Yes but it involves some developer
>> knowledge, (of CSS mostly) if you think you feel comfortable doing this,
>> you can see the "userChrome.css" article on the [[Mozilla Developer
>> Center]]" basically keep it very simple for users, and provide proper
>> gateways to the developer docs for those people who might feel
>> comfortable doing it. (but might not otherwise know of our developer
>> documentation)
This would make sense if there is enough user demand for suck a question.
For the knowledge base, our general policy should be to be proactive
when dealing with support/troubleshooting issues, and reactive when
dealing with tips & tricks in the gray area.
>>
>>
> I'm not sure I'd go there. I think those are suitable questions for the
> forums and live chat. If we're answering them a lot, then we want to talk to
> the dev team about the demand and go from there. Maybe we want to have a
> basic article about how to do things that aren't already covered in the UI,
> and point to add-ons etc.
That's what I mean with using our best judgment and deal with things on
a case by case basis depending on popularity. If there's evidence
there's is a significant demand, we should deal with it then.
David Tenser
> chris hofmann wrote:
>> to figure out if this dividing line is helpful. the about:config
>> article as written would easily be classied as removed or moved to
>> devmo under this criteria, but are there other harder cases to deal with?
>
> This should indeed be the next step here.
>
Here is the full inventory I started. It's in a somewhat raw form, but
hopefully this will make the line between "monkey" articles and problem
solving articles clearer:
http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=90712&forumId=3
(The formatting is a little broken in the contributor's forum since the
new theme launch; we're working on it.)
Stephanie Daugherty
> Is it a good idea to have an KB article describing about:config as per
> Bug 428582?
>
> If so, what should the article entail?
>
> and it is metioned, briefly, here:http://support.mozilla.com/en-US/kb/Editing+configuration+files#about...
I think it's good to have the article, since it's something referred
to quite a bit. I'm not sure however, if this article should be
something that a user can easily browse to or search for. I don't know
if the capability exists to set a "user level" on an article (ie "end
user" "expert" "developer" "contributor") but this is the sort of
thing that highlights a need for that capability.
about:config is something that can be roughly equated to the registry
editor in Windows. It's there because it needs to be there, not to
encourage people to use it. Ultimately, they are going to get the
information if they want to monkey around in there, it would be better
if they get the correct information, and complete documentation. I do
think however, that we can separate out the documentation of what
every setting in there does... and have a "see also" that points to
devmo for that.
I will say that an article with a disclaimer is better than pretending
it doesn't exist IMHO, because with a disclaimer at least the only
"official" source will be one that says in effect "This will break
things, if you break them, you get to keep both pieces"