Notes from today's Firefox Support meeting
Samuel Sidler
those of you that couldn't attend, this should be a good recap of the
things we discussed. Additionally, below is a link to the full audio
of today's meeting. If there's anything I missed or should have
explained further, feel free to reply back here.
http://samuelsidler.com/media/firefox-support-meeting-2007-05-08.mp3
For those of you who couldn't make it, we'd love to hear comments and
ideas from you regarding this meeting. Be sure and let us know if
there's anything else we can do to facilitate this better.
Thanks again to all who came and all the great feedback you gave.
-Sam
--
>From the meeting today, we believe these are commonly held beliefs
about the knowledge base:
* Engaging the existing support community, and building a larger
number of contributors is key to helping build support options as
Firefox market share grows. We need to recruit more contributors, and
provide better tools to help get work done easier and faster, and
continue to improve the quality of the support site. Mozilla Corp.
needs to invest in the the tools and people needed to build a better
support community and better support options for Firefox.
* Content of the knowledge base pages at mozillaZine and other sites
needs to be inventoried, reviewed, reorganized and upgraded as
Firefox attracts new users
** Understand which pages are most viewed, most useful, most in need
of work and start to organize community efforts to make these
improvements.
** Start to add multi-media and other enhanced forms of content to
improve the usability of the content
* Searchability and Navigation of the knowledge base needs constant
improvement
** Adding tagging for searches, surfacing common search terms,
applying tags to pages
** Leverage current mozillaZine index pages
** Sort by code module/Bugzilla component owner
* A new l10n compatible structure needs to be created to allow
international contributors to effectively find and translate support
information.
* Rating, Feedback and reporting systems need to be created to provide
better data and communication about how the site is used and guide
future work to both improve the site content and the product.
** support system user feedback to the support community,
** support community feedback to the development community
The creation of an "official Firefox knowledge base site" hosted at
mozilla.com is highly desirable to remove user confusion about the
source of the support information, and provide a site where we can get
a fresh start work on the goals listed above.
All of these are, of course, up to discussion, but are based on the
meeting today.
--
General overview of current Firefox support efforts:
* MozillaZine
* Forums
* Knowledge Base
* Newsgroups / Mailing lists
* Bugzilla (unfortunately)
* Want to condense this into one location so users know where to
go. Scattered is bad.
Current state of knowledge base
* Positive things:
* Has about 900 articles
* Dedicated contributors
* Good resource; has information that people need and is easy
to point people there
* Negative things:
* Some content is too complicated for users
* It's not clear the kb is geared toward end users
* Need to define who the kb is for
* Should the support system house data for all types of
users?
* Comparison to MSFT. Their kb fields information for all
types users.
* English-only. Needs to be multilingual
* Currently our support options for non en-US users are
scattered even more
* Various small forums / mailing lists in all different
areas of the world
* We should do something similar to devmo where articles
are translated
* Bring in the small non-English support groups
Content control - who should be able to edit?
* Is the Wikipedia style good?
* Security isn't as much of an issue as it appears, but it
requires constant community policing
* Works well for them, but might not work well for us
* Might be easy to moderate overall issues because we can know
what dangerous things are
* Putting up content immediately (without moderation) could
cause a short period where bad information is displayed
* Can our people develop the "passion" they do with topics in
Wikipedia? (Doubtful)
* A bot (on IRC or so) or something could identify changes
immediately and could show potentially articles that look scary
* Such a bot already kind of exists (for Wikipedia)
* Also firebot can do most of these things required
* We need good monitoring tools.
* Sandboxing of articles beforehand
* Rating articles ("this was helpful", star rating, thumbs up/
down)
* Commenting would be good but shouldn't be required and
should be hidden by default (see MySQL documentation)
* Is the current kb style working?
* Some think it's easy to get an account, some find it hard
* The style "works well when it works"
New Ideas
* A "click to IM" or "click to forum post" if the article is
confusing to allow direct contact with someone
* VNC access to a user (with permission, of course)
* There are some security concerns that would need to be
addressed
* Maybe instead of that, work on showing visuals (screencasts;
screenshots; tutorials)
* Maybe only give access to "trusted volunteers" or employees
* An extension that takes screen captures and uploads them to
a source (so they don't need to do the uploading themselves) for
giving support
* Instructional videos
* Tying in bugzilla/hendrix into the kb
* Keep hendrix separate if possible; make it for feedback not
support
* Prominently direct users who go to hendrix to support
offering
* Better sorting/metrics of hendrix already being worked on
* Boilerplates for responding to support requests / bugzilla bugs
* Have a picture of the browser window and let the user select
where they're seeing the issue
* Good for those who don't know terms (address bar, search
bar)
* Good experiment to try
Action items / Next steps
* Get better analytics of what are the most important topics/
articles
* chofmann working to get this from mZine
* Also see http://kb.mozillazine.org/Special:Popularpages
* Make inventory of all Firefox articles on kb and the state of
them
* Might require access to kb
* Lucy will start going through some of the articles but it's
a job for several people
* Also get metrics from grepping the IRC logs of #firefox to
see what's most used. Ask one of the bots (gavin or reed)
* Organizing the information
* How do we want to organize them? Tagging them, etc
* Get inventory of current hierarchies
* See which ones are useful and which are too complex
* Categories on the kb: http://kb.mozillazine.org/Special:Categories
* Style guide
* Guidelines for content
* Writing in the same voice/style
* Written for novice
* Create a checklist to evaluate articles with
* Makes auditing content easier
* Catches blatant problems right off the bat
* Should wait on style guide for the inventory to be completed
* Go from most likely / least invasive on up to other topics
* Module owner for this project
* Need someone to lead, take on decision making, working with
individual contributors, arbitrating disputes, etc
* No current, clear leader of kb
* Potential for np and/or Lucy
* Something to think about for the future
* Venders/infrastructures for this system
* MediaWiki
* Drupal
* Jive Software (mostly open source, used all over the place)
More things...
* Naming this
* Have been using "User Support", "Customer Support", "End-
User Support"
* Have heard recommendations for "Firefox Help" or "Firefox
Support"
* Sticking with Firefox Support thus forward
* How do other projects/products fit into this?
* This project is Firefox-specific however we want to build it
in a way that other products could use the platform
* Need better communication with other outlets (forums,
newsgroups, IRC, etc)
* Don't want others to think this is a "power grab"
* Have tried posting to multiple places, but need to have a
good conversation with others who might not already be participating.
* Anything that any contributor can do to get the word out is
encouraged
* Maybe get np to help present it to other members of
mozillaZine
Chris Hofmann
Samuel Sidler wrote:
snip
> ** Start to add multi-media and other enhanced forms of content to
> improve the usability of the content
>
>
>
On the content rating and video requirements I was reading a bit about
about these Media Wiki extensions
http://www.mediawiki.org/wiki/Extension:Review_script
http://www.mediawiki.org/wiki/Extension:YouTube_Video
I wonder if anyone has played with these?
> * Rating, Feedback and reporting systems need to be created to provide
> better data and communication about how the site is used and guide
> future work to both improve the site content and the product.
> ** support system user feedback to the support community,
> ** support community feedback to the development community
>
>
>
the content rating and ability to add narative comments to feedback for
kb pages also needs to be rolled up in to over all status. we really
need a list of the top 20 articles that users say need the most work as
one way to focus contributions to have the greatest impact.
> * Negative things:
> * Some content is too complicated for users
> * It's not clear the kb is geared toward end users
> * Need to define who the kb is for
> * Should the support system house data for all types of
> users?
> *
one way to solve this content leveling would be to initiate a project to
have community members to create videos related to every important kb
article that could clearify and simplify the written content, then link
in the video's on the kb pages as additional sources of information.
there is quite a bit of youtube content already available to be review
and possible harvested. here are some examples of stuff that already
available, and hints at the kind of things that could be done if we set
up a frame work for adding video on a wide scale for all kb articles.
http://youtube.com/watch?v=66Dg0TUhU-c
http://youtube.com/watch?v=mHyPJBkGX-8
http://youtube.com/watch?v=7byO3LvkSe8
http://youtube.com/watch?v=iEBBmQg26Ek
snip
> * Venders/infrastructures for this system
> * MediaWiki
> * Drupal
> * Jive Software (mostly open source, used all over the place)
>
>
we definitely want to solicit ideas about other possible providers that
might help to best meet the requirements.
chris h.
Jason Barnabe (np)
On May 8, 5:38 pm, Samuel Sidler <samuel.sid...@gmail.com> wrote:
> The creation of an "official Firefox knowledge base site" hosted at
> mozilla.com is highly desirable to remove user confusion about the
> source of the support information, and provide a site where we can get
> a fresh start work on the goals listed above.
This may just been bad wording, but do we really want a "fresh start"
rather than a gradual improvement over the current state?
> * Is the Wikipedia style good?
> * Security isn't as much of an issue as it appears, but it
> requires constant community policing
> * Works well for them, but might not work well for us
(Is "them" Wikipedia in this sentence?) The KB has years of history of
Wikipedia style editing. All you have to do is look at how well it's
worked to see how well it will work.
> * Can our people develop the "passion" they do with topics in
> Wikipedia? (Doubtful)
Our people definitely have the passion to provide support. I don't
think you could have thousands of posts of the forum or spend hours in
IRC without passion. I think this passion for the most part isn't
being directed toward the KB due to technical and social issues.
Technical in that a lot of things would be much more helpful if only
the MediaWiki software were modified, social in that disputes turn
people off and that there isn't as much reward for writing
documentation as there is for directly helping someone. I think we
could change all of these issues fairly easily.
> * A bot (on IRC or so) or something could identify changes
> immediately and could show potentially articles that look scary
What's "scary"? I don't find blanking or vandalism all that scary, but
I do find writing destructive instructions scary.
> * Rating articles ("this was helpful", star rating, thumbs up/
> down)
> * Commenting would be good but shouldn't be required and
> should be hidden by default (see MySQL documentation)
I really don't think commenting would be on the article itself, rather
it would be much like Discussion pages in it being another "view" of
the article. Commenting is very important IMO, because while ratings
are helpful, we would need actual reasons why people are giving an
article bad ratings.
> * Some think it's easy to get an account, some find it hard
It gives the impression that we vet potential editors when all we're
doing is trying to prevent spam bots. Getting an account should be an
automated process.
> * A "click to IM" or "click to forum post" if the article is
> confusing to allow direct contact with someone
Good idea, but I wouldn't necessarily say it's there because the
article is confusing, but simply that it wasn't helpful to the user.
> * VNC access to a user (with permission, of course)
> * There are some security concerns that would need to be
> addressed
Massive security concerns. Someone could go through the helpful
Mozilla VNC process once and then come back and say "Hey, I have
another problem, e-mail me at us...@example.com", and then someone
malicious could forge an e-mail from Mozilla to them and get access.
> * Make inventory of all Firefox articles on kb and the state of
> them
> * Might require access to kb
> * Lucy will start going through some of the articles but it's
> a job for several people
I'll help, but I'd need direction on what information I should be
pulling out of them.
> * Create a checklist to evaluate articles with
> * Makes auditing content easier
> * Catches blatant problems right off the bat
Very good idea. Kind of like the "featured article review" on
Wikipedia.
> * Don't want others to think this is a "power grab"
> * Have tried posting to multiple places, but need to have a
> good conversation with others who might not already be participating.
> * Anything that any contributor can do to get the word out is
> encouraged
> * Maybe get np to help present it to other members of
> mozillaZine
I think that the fact that it's so abstract at the moment makes people
not give feedback. Once it's more fully defined, I believe there'd be
more interest and support. "Mozilla is taking over the KB" sounds bad,
but "Mozilla is taking over the KB to provide us features like X, Y,
and Z" sounds good.
maj...@gmail.com
wrote:
> My reply got eaten, had to rewrite it...
> > * Make inventory of all Firefox articles on kb and the state of
> > them
> > * Might require access to kb
> > * Lucy will start going through some of the articles but it's
> > a job for several people
>
> I'll help, but I'd need direction on what information I should be
> pulling out of them.
>
Mine, too. I've made 2 threads in this group (I think they're up this
time, had to repost). Please email me if you want to help coordinate,
and we can make some plans on what to do.
-Majken "Lucy" Connor
goy.ben...@gmail.com
I am whatching this group as well. I missed the meeting but am
interrested. This seems to be a real attempt to involve more consumer
types. I hope it works out as we do need some thing like this if for
nothing else than to teach some of us new commers how FOSS development
works.
Samuel Sidler
> On the content rating and video requirements I was reading a bit about
> about these Media Wiki extensions
>
> http://www.mediawiki.org/wiki/Extension:Review_script
> http://www.mediawiki.org/wiki/Extension:YouTube_Video
>
> I wonder if anyone has played with these?
I haven't at all. I've seen the YouTube one in use before but I can't
remember where. One of the problems I have with YouTube is the quality
of the video there. I think we should be showing higher quality video
(crisp looking) on our support site and I don't think YouTube fills
that. Are there other video hosts that exist out there that have a
good quality on their videos? I'm sure we could hack any add-on to use
any other video site.
> the content rating and ability to add narative comments to feedback for
> kb pages also needs to be rolled up in to over all status. we really
> need a list of the top 20 articles that users say need the most work as
> one way to focus contributions to have the greatest impact.
This is part of what Majken is working on, though she might not know
it. ;) If we can identify all our articles and which ones need help
and, separately, identify what the top articles are, we'll be able to
see where we can get the most bang-for-buck.
> one way to solve this content leveling would be to initiate a project to
> have community members to create videos related to every important kb
> article that could clearify and simplify the written content, then link
> in the video's on the kb pages as additional sources of information.
>
> there is quite a bit of youtube content already available to be review
> and possible harvested. here are some examples of stuff that already
> available, and hints at the kind of things that could be done if we set
> up a frame work for adding video on a wide scale for all kb articles.
>
> http://youtube.com/watch?v=66Dg0TUhU-c
> http://youtube.com/watch?v=mHyPJBkGX-8
> http://youtube.com/watch?v=7byO3LvkSe8
> http://youtube.com/watch?v=iEBBmQg26Ek
There is a lot of YouTube content, but I have concerns about YouTube
(which I mention above). I think it'd be more beneficial to solicit
the creators of those videos for content and see if they'll sign off
with creating it under a Creative Commons license (or something) and
donating it to the project. Then we can retain high quality of video
and also work on a consistent style for all our video tutorials.
I'd also say we should utilize screenshots first since that's
something almost anyone can contribute and add video demonstrations
where appropriate.
> we definitely want to solicit ideas about other possible providers that
> might help to best meet the requirements.
I agree. Very much so. There doesn't seem to be a wealth of solutions
out there for things of this scale.
-Sam
Jason Barnabe (np)
listened to it yet.
On May 8, 5:38 pm, Samuel Sidler <samuel.sid...@gmail.com> wrote:
> The creation of an "official Firefox knowledge base site" hosted at
> mozilla.com is highly desirable to remove user confusion about the
> source of the support information, and provide a site where we can get
> a fresh start work on the goals listed above.
I don't know whether this was actually meant, but I don't feel a
"fresh start" is necessary. Gradual improvement over the existing
situation would be better.
* It would ensure one constant source of information rather than
"migrating to" and "migrating from" sources.
* The history of the documentation is an asset, not a liability.
Current contributors would be more likely to continue to contribute in
a new system if they saw it as a continuation of their previous
contributions.
* While some chaff would get cut, so would some wheat.
> Content control - who should be able to edit?
> * Is the Wikipedia style good?
> * Security isn't as much of an issue as it appears, but it
> requires constant community policing
> * Works well for them, but might not work well for us
I don't see why having Mozilla run the KB would change how well the
Wikipedia style works.
> * Can our people develop the "passion" they do with topics in
> Wikipedia? (Doubtful)
People who have tens of thousands of posts on the forum or spend hours
a day on IRC helping certainly have a passion for providing support.
That passion is often stifled by what they see as determental changes
to stuff they wrote. I believe guidelines for articles and a better
way to resolve disputes would help keep the passion alive.
> * A bot (on IRC or so) or something could identify changes
> immediately and could show potentially articles that look scary
What does "scary" mean? I can see how the bot would notice spam or
vandalism, but not things that I find scary like directing users to do
something damaging.
> * We need good monitoring tools.
> * Sandboxing of articles beforehand
> * Rating articles ("this was helpful", star rating, thumbs up/
> down)
> * Commenting would be good but shouldn't be required and
> should be hidden by default (see MySQL documentation)
I don't think comments should appear on the articles themselves.
Rather, they should exist as a separate "view" of the page much like
"Article" and "Discussion". I think comments are very important in
addition to ratings. A "This was not helpful" rating doesn't mean much
if we don't know why.
> * Some think it's easy to get an account, some find it hard
It's easy, but it's a ridiculous process. E-mailing me or tanstaafl
isn't because we want to vet potential users, it's because we don't
have the technical solution to stop spam bots.
> * A "click to IM" or "click to forum post" if the article is
> confusing to allow direct contact with someone
Not necessarily confusing, just not helpful to the user.
> * VNC access to a user (with permission, of course)
> * There are some security concerns that would need to be
> addressed
I don't think the security concerns could be overcome with something
like this, what with phishing-like attacks.
> * An extension that takes screen captures and uploads them to
> a source (so they don't need to do the uploading themselves) for
> giving support
I think many of the problems users experience would preclude this from
working.
> * Make inventory of all Firefox articles on kb and the state of
> them
> * Might require access to kb
> * Lucy will start going through some of the articles but it's
> a job for several people
I'd help, but I need to know what information to gather on "the state
of them".
> * Create a checklist to evaluate articles with
> * Makes auditing content easier
> * Catches blatant problems right off the bat
Very good idea.
> * Don't want others to think this is a "power grab"
> * Have tried posting to multiple places, but need to have a
> good conversation with others who might not already be participating.
> * Anything that any contributor can do to get the word out is
> encouraged
> * Maybe get np to help present it to other members of
> mozillaZine
I think you'd get a much better response once it becomes more
concrete. "Let's move the KB to Mozilla.org" won't have the same level
of support as "Let's move the KB to Mozilla.org, where we'll
immediately provide features X, Y, and Z to help you".
maj...@gmail.com
rolling in here, I definitely want to involve as many MZ people on
this as possible (for practical reasons as well as social). I was
going to have them done for today, but it looks like I'll get them up
tonight. Please email me if you want to help coordinate this.
-Majken
Chris Ilias
> * Content of the knowledge base pages at mozillaZine and other sites
> needs to be inventoried, reviewed, reorganized and upgraded as
> Firefox attracts new users
> ** Understand which pages are most viewed, most useful, most in need
> of work and start to organize community efforts to make these
> improvements.
Watch out for pages that encompass many different problems, like
reducing memory usage, or crashing.
> * Searchability and Navigation of the knowledge base needs constant
> improvement
Search should be the primary navigation tool. Let's face it, what is
easier: trying to find your way through online documentation, or posting
your question in a discussion forum? Finding a KB article has to be
quicker/easier than posting a question (which should also be easy :-) ).
> * A new l10n compatible structure needs to be created to allow
> international contributors to effectively find and translate support
> information.
This, to me, is a deal breaker. Looking at a recent blog post by John
Lilly [1], "we no longer have an English/US majority of users." A
multi-lingual system is a prerequisite.
[1]<http://john.jubjubs.net/2007/05/18/growth-around-the-world/>
> The creation of an "official Firefox knowledge base site" hosted at
> mozilla.com is highly desirable to remove user confusion about the
> source of the support information, and provide a site where we can get
> a fresh start work on the goals listed above.
<raising hands> Hallelujah!
> General overview of current Firefox support efforts:
> * MozillaZine
> * Forums
> * Knowledge Base
> * Newsgroups / Mailing lists
> * Bugzilla (unfortunately)
> * Want to condense this into one location so users know where to
> go. Scattered is bad.
I tend to be of the opinion that one of each is good. Some people prefer
newsgroups, some prefer IRC, some prefer web-forums; and our job is to
accommodate users, not herd them, like cattle. I'm not saying scattered
is good. We just need to be careful not to deny them what they want.
There should be a support gateway, where we can "herd" users, and from
there, choose the support venue they want.
The bi-directional mirror between mailing lists, newsgroups, and Google
Groups is cool, but there are formatting and control issues.
> Content control - who should be able to edit?
> * Is the Wikipedia style good?
As long as the pages aren't too complex to create (ie. everything should
be possible via WYSIWYG editing). I'm an HTMLer, and to me, learning
wiki code is like learning another language.
It might even be worth accepting text contributions, than having someone
else wikify it, in accordance with a KB style guide.
> * Putting up content immediately (without moderation) could
> cause a short period where bad information is displayed
If content requires review before publication, there better be at least
one moderator available at any time (24/7). Doesn't it suck to create
content, and find no-one is there to review it, because everyone is
sleeping?
> * Commenting would be good but shouldn't be required and
> should be hidden by default (see MySQL documentation)
Commenting on support articles will always result in a support
discussion, that actually belongs in a support forum. ("I'm having
trouble implementing these instructions. Can someone help he?")
> * Have a picture of the browser window and let the user select
> where they're seeing the issue
I don't like that idea. A picture of the browser only covers UI issues.
What about mem usage, crashing, website problems, etc.
> * Venders/infrastructures for this system
> * MediaWiki
> * Drupal
> * Jive Software (mostly open source, used all over the place)
I'm surprised this item hasn't garnered more discussion. Choosing which
CMS to use, is a huge decision. Pretty much everything else discussed in
this meeting depends on what CMS is being used. We need to put a lot of
time and effort into choosing the right CMS, because once we decide,
there's almost no going back. I think of it as the support equivalent of
Mozilla.org choosing which version control system to use for Mozilla2.
We need to weigh the pros and cons of each CMS, and have them battle it
out Mortal Combat style. :-)
Inversely, this decision depends on everything else. Our vision of what
we want our end result to be, needs to be as vivid as possible; so that
when we come across any arbitrary characteristic of a CMS, we can easily
determine whether or not that characteristic is a pro or a con.
As the saying goes, there's no substitute for experience. Would it be
possible to have test installations for us to get to know each CMS, for
the purpose of helping us decide on one. Maybe call it "Support Beta."
> More things...
> * Naming this
> * Have been using "User Support", "Customer Support", "End-
> User Support"
> * Have heard recommendations for "Firefox Help" or "Firefox
> Support"
> * Sticking with Firefox Support thus forward
> * How do other projects/products fit into this?
> * This project is Firefox-specific however we want to build it
> in a way that other products could use the platform
Whatever the name, if this KB is Firefox-only, there should be the word
"firefox" somewhere in the URI. If you use something as generic as
help.mozilla.org, that's infringing on other Mozilla products.
--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird
mozilla.test.multimedia moderator
(Please do not email me tech support questions)