For instance, the problems gathered so far are:

• While tikiwiki markup is simple and easy to learn, you still would have to learn it. When a new contributor wants to edit an article and opens the editor, he/she is often confronted with a lot of markup code, which can deter he/she from attempting to edit the article.
• In order to remove a tag from an article, you need to open the editor, and make an edit to the article.
• There are a lot of small variations of tag names (e.g. bookmarks vs. bookmarks) meaning two or more articles that should have the same tag, end up not having the same tag. This is mostly because people don’t know which tags already exist, when adding a tag to an article.
• The additional categories sometimes get misused, or not used at all.
• Use of the Dynamic content feature or the fantastic SHOWFOR plugin that we use to show/hide content depending on the Firefox version and OS requires manually typing the markup, which is not only laborious but increases the chance of markup errors.
• Not many people are citing references when adding content to articles, or even explaining their changes.
• The images for quickly applying markup are not very intuitive.
• Uploading of screenshots is separated from the article content, and hard to find.
• Whenever the SHOWFOR plugin is used, we have to add {SHOWFOR(spans=on)/} to the top of the article.
• When using the SHOWFOR plugin, you have to save an edit to see if it works.
• The size of the content area often not wide enough or tall enough, causing a lot of content lines to be wrapped, and a lot of scrolling to reference content elsewhere in the article.
• The category selector to choose where the article will exist, can easily be misused. In fact, if you’re editing an article that is already in the Knowledge Base, all edits have to be made to the staging copy first, which should only exist in the staging area category.
• The “Alert translators” checkbox is often overused, causing translations to be marked as out of date.

Some of the proposed ideas for solving these issues are:

• The editor should be “What You See Is What You Get” (WYSIWYG). This way, contributors do not have to know the markup, in order to improve content.
• Adding and removing tags should be separate from the article editor; and in the separate UI, contributors should be able to find out which tags have already been created, either through auto complete, or using checkboxes to add tags.
• The additional categories checkboxes should only be visible when creating a new article, and only made available afterwards for admins/locale leaders.
• Dynamic content blocks should be part of the editor toolbar as a quickpaste function.
• We should have buttons on the editor toolbar for applying SHOWFOR.
• {SHOWFOR(spans=on)/} should be automatically applied to every article that uses the feature.
• Create or find images for the editor toolbar that are easily interpretable.
• The image upload feature should be part of the editor toolbar, just like Wordpress.
• The width of the content area should be 100% of available space; and default height should fill up a large portion of the average screen space, only leaving room for the toolbar.
• Get rid of the category selector on staging copies.
• Relabel the “Alert translators” checkbox to more accurately communicate the affects, and add a warning to it.
• (In discussion) We could either add a ‘Reference’ field for contributors to cite references, or add something to the “Edit Summary” label about citing a reference.

There’s still time to add more ideas and feedback, and we want to make sure everyone has a chance to contribute to the discussion. If you would like to add anything, please post in the discussion thread. Thanks.

One great thing about support as a community is that the line between user and helper is blurred. Many of the current support volunteers got started by asking a question themselves, staying around to help other people using information learned solving their own problems. While most users don’t have time to commit regularly, many users have spent extra time to troubleshoot an issue, to let us know what finally fixed a problem, or to post advice about solved issues in the forum. Likewise, many people in the Mozilla community without a lot of time to commit have helped by assisting newer helpers when a new issue arises. The support community allows new helpers to learn about Mozilla and support in general, while actively helping users solve problems.

While SUMO doesn’t define rigid roles for contributors, we need people helping users and those assisting helpers to be available at once for quality help in Live Chat. To regularly achieve this, we are starting a new scheduling system where community members can sign up to fill a ‘role’ in a given time slot.

• Advisor: Senior helpers and other community members who can assist other helpers, but not accept user questions directly.
• Helper: The majority of volunteers sign up as helpers, answering questions from users and participating in discussions in #sumo.
• Anchor: These users commit to an entire block of time, ensuring that users aren’t left without a helper.
• Room monitor: Experienced helpers who watch chats in progress and document new findings to ensure quality service. They should ensure that correct advice is given and that helpers are discussing issues in #sumo.

A senior helper, for example, might want to anchor two hours and advise five hours in a given week. If you know specific times that you can help, please sign up so that other helpers know when to come.

If you think Live Chat might be right for you, read our documentation on getting started. To start accepting Live Chat questions, you will need to get the open source Spark client. However, you can get started assisting other helpers on irc, joining chat sessions using any XMPP (Jabber) client. If you think another area of SUMO would suit you best, check out our other ways to contribute. Alternatively, simply join #sumo on irc.mozilla.org (or via mibbit) to ask us directly!

Sumo

• Weekly metrics
  • Bug 455190 made the poll stats unreliable; should be fixed starting from last week’s push. cilias to verify and report to nkoth if there are still problems.
• Last week’s weekly support issues
  • People stuck on looping update messages. Probably a prefs.js locked problem. lucy to look up more info.
• Logo feedback gathered in newsgroup thread. If you haven’t provided feedback yourself, please do it asap!
• “Are the links on the front page detracting people from using search?” discussion on mozilla.support.planning [1]
• Search box in the top nav performs a mozilla.com site specific search, not a SUMO search [2]. djst to look up how many people search there on SUMO, if possible. If not, we’ll probably just remove the search box.

Knowledge Base

• Bugzilla: 2 new article bugs [3][4], 1 bug verified fixed [5]
• Firefox 3.1 changes [6]

Live Chat

• Top live chat issues, several need investigation or more information
• 4 new chat accounts, 1 account approval: auswddn
• We are now following up chats in the forum after the user understands what to do. That way we can reduce the average chat session length, become more effective, while still providing high class support for our users. All chat helpers should search the forum for their name after helping, to catch followups.

SFD

• E-mail sent to localizers, early feedback
  • Fix bugs that prevent widespread adoption of SUMO first before asking localizers to help en masse.
  • Goal should be to get more people (isn’t it always?) and increase communication between locales/en-US
  • Would like info on how to get started translating and keeping translations up to date
• Decide a day for the event next week

After looking at support.mozilla.com traffic data (since the release of Firefox 3 and all-time), and weighting articles that we feature on the front page, I’ve compiled this list of top 15 articles that should be translated:

1. Installing Firefox
2. Installing Firefox on Windows
3. Installing Firefox on Linux
4. Installing Firefox on Mac
5. Customizing Firefox with add-ons
6. Profiles
7. Hiding bookmarks in the Smart Location Bar
8. Backing up your information
9. Firefox is already running but is not responding
10. Clearing Location bar history
11. Firefox will not start
12. Bookmarks and toolbar buttons not working after upgrading
13. ActiveX
14. Search suggestions
15. How to set the home page

Some localizations of the start page get as much a 50,000 views a month; and localization of the Knowledge Base can be scattered. Those are the most wanted articles for localization, and translating them will have the greatest impact on users finding content in their own language. For instructions on how to translate articles, read our tutorial on translating articles.

If you have any questions, comment here or in the Contributors forum.

If a problem isn’t yet covered in the Knowledge Base, or if the instructions in the article are too hard to understand, Live Chat is a powerful way for users to get touch with Firefox experts and get hands-on assistance in solving their problems.

Live Chat can also be a very fun way for contributors to provide support. Contributors helping out with Live Chat don’t just help users, they talk to each other in the backchannel as well, providing assistance to other helpers whenever needed. This means that although you’re usually the only one interacting with the user you’re helping, you’re never alone.

An important aspect — and one of the most interesting in my opinion — about Live Chat is that it is instrumental in detecting new and emerging support issues that are not yet covered in the Knowledge Base. The people helping out with Live Chat, along with helpers of the Support Forum, are those closest of all to what is going on — they really are the ones with their finger on the pulse, if you will.

However, without enough contributors, Live Chat has the risk of giving the user a negative experience, principally because of long waiting times or limited hours of operation. Without contributors, Live Chat can never be successful. We think the two keys to attracting contributors are:

1. to make contributing as straightforward as possible;
2. to minimize the load on the contributors by using their time as efficiently as possible - we do this with the support funnel. More specifically, we want to make sure that people search the Knowledge Base (and Support Forum) before turning to Live Chat, so helpers aren’t overwhelmed by the number of users requesting assistance.

I’ve already covered the support funnel in previous blog posts, so this time I’ll focus on how we can make contributing to Live Chat as simple and fun as possible. As always, we already have some ideas, but we really need your feedback as well.

Fully integrated help client

In order to help out with Live Chat today, you need to install an open source Java-based chat client called Spark. This means that unlike the Knowledge Base or the Support Forum, people need to learn how to install, configure, and use a separate application in order to get started with helping people with Live Chat. While the current solution certainly works, it is far from ideal for a number of reasons:

• It’s an unnecessary technical barrier and yet another application installed on peoples’ computers.
• It’s poorly integrated with the rest of SUMO, meaning, among other things, that people helping out with Live Chat may not be aware of the support funnel and the most commonly reported problems and solutions already documented in the Knowledge Base.
• The software isn’t custom-made for our needs, meaning for example that it’s not straightforward for helpers to find the backchannel where other helpers hang out.
• We rely on good documentation to ensure that helpers understand where they should look for assistance and relevant information.
• We have a separate log in for Live Chat than the rest of SUMO.

Replacing Spark with something integrated into the SUMO website itself would give us a solution that is pre-configured for our particular needs, do away with the need for separate software, and seamlessly integrate information about weekly common issues and other things relevant for our helpers. The barrier of entry would be reduced significantly.

Simple scheduling solution

Today we have specific times of the day when we’re sure to be open — our “hours of operation” for Live Chat. This is helpful for contributors as they know when they can expect other people to be online. After all, just like many other things in life, Live Chat shouldn’t be a solitary activity.

The ideal solution would be if people could just log in and help out whenever they wanted to, but that would require lots and lots of helpers. We’re not quite there yet, and in the meantime we need a way to make the existing helpers gather around certain scheduled hours naturally. However, the hours of operation might not fit everyone, so we need something that will allow people to commit to specific time slots that are convenient for them, while still seeing which slots other people have offered to take or would like to take — think of it as a shared calendar.

This would give helpers the ability to plan ahead of time when they want to help out, based on what time slots other helpers have already committed to. We think this will encourage collaboration and make Live Chat even more fun. Furthermore, the official hours of operation could then be based on the confirmed schedule time slots, rather than predefined hours we’re using today. And from a user’s point of view, the relevant info is when Live Chat will open next, not a predictable weekly schedule.

Other improvements

Of course, integrating the help client and adding a capability to assist volunteers in being able to plan their contribution of time are just a couple of things we can do to make things simpler. Here are some other things we have in mind:

• Support for other languages than English — Both users and helpers often speak more than one language. Ideally, users would simply select which languages they understand from the list of currently available languages. That list of available languages would itself be based on which helpers are currently logged on.
• Add a lower limit of the number of helpers that needs to be logged on before Live Chat opens, to ensure a good support experience. This way, we can control the helper/user ratio and thus avoid helpers burnout. In other words, if there are lots of users in need of help, we’d need more helpers before we opened Live Chat, to ensure that the waiting times are not unreasonable.
• Automatically save chat logs, along with user happiness rating and whether or not the problem was solved. This would allow us to make better use of the Live Chat stats about common Firefox problems. It would also allow us to tell which helpers are doing a great job, and which ones need a little more training.

Have you tested Live Chat already? If so, what did you like about it, and what would you want to change? We’d love to hear your thoughts, and whether or not you think our ideas are in line with what you’re seeing, or if you have other ideas we haven’t covered here.  And if you haven’t tried it yet, consider this a written invitation.

Sumo

• Weekly metrics
  • First week of collecting metrics from Omniture instead of Urchin, which explains some differences in the numbers
  • All team members set up with access to Omniture; need to schedule meeting with the one and only (Mr Ken Kovash) to get a good introduction
• Last week’s weekly support issues
  • Got poll count data from the Knowledge Base thanks to Laura. Need to integrate it with the rest of the data. Also, we probably want to look at No votes as well, assuming the majority of the people that vote No do so because they tried the instructions but they didn’t work. Moreover, the data is skewed because of the site traffic (e.g. in-product help articles get higher vote counts).

Knowledge Base

• Bugzilla: 2 new article requests [1][2], 1 article bug verified fixed [3]
• Disable Smart Location Bar article is renamed
• Which in-product articles need to change for Firefox 3.1? cilias to get back with info around this.

Support Forum

• More threads, less answers. We currently have around 55% of threads replied to, but no way of determining whether or not the replies were actually an attempt to solve the problem. For this, we need new performance metrics, which is part of SUMO 0.8. Specifically, we need to be able to tell “me too” replies apart from replies that actually try to help the original poster.

Live Chat

• Traffic down again, answer rate >60% — steadily improving as traffic calms down
• Common issues: in weekly issues thread
• New hours, Helping with Live Chat updated
• About 5 new accounts last week, 0 account approvals
• Need more people to connect after-hours to chat-support.mozilla.com (with any Jabber client)
  • Any instructions on how to connect with Jabber client?–cilias 16:48, 29 September 2008 (UTC)
• Anyone who can help us out in Live Chat this week, please sign up on the live chat coverage page to help us plan it better. Thanks!

The Firefox 3.0.2 release is a very good example of this importance; shortly after the 3.0.2 update started to roll out in Europe, Carsten Book from the QA team noticed early signs of users having problems with the Password Manager from various places such as support forums on Heise, and Hendrix. It was then quickly confirmed to be a frequent issue in the Support Forum of SUMO as well.

In a matter of hours, this went from early signs from our different user channels to a solid plan to release an update of Firefox (due out today or tomorrow) to fix it, as well as a new Knowledge Base support article about the issue. SUMO was just one player in this great and efficient teamwork, but it highlights well our ability to “extend our tentacles” during releases to ensure that we keep doing what we do so well: listening to our users — in this case as an early warning system, if you will.

For contributors, the Support Forum is an exciting place to be, since you can take part of this early warning system, while at the same time making other people happy by helping them with their problems. It’s a good place to start helping since you can simply browse through the posted questions and see if there is anything you know the answer to. There are no obligations to respond if you don’t know the answer.

Reaching out to the people in need

One of our current challenges with the Support Forum is that while we have an incredibly helpful community answering a large number of questions, we don’t have a good way of ensuring that the user asking the question actually comes back to read the answer. This means that we don’t really know if the user’s problem was actually solved or not, only that we at least tried to help.

Question asked in the Support Forum.

We’d like to change this by making it easier for users to find their way back to the forum thread they posted. When a user asks a question in the Support Forum, we should offer the ability to get an e-mail notification when someone responds to the question. This way, people don’t have to worry about how our support site works or what page to bookmark — we will reach out to the user instead of the user finding its way back to us.

Making the forum easier to use for our community

Of course, in order to reach out to our users we need to make sure there are people who want to help others in our forum. We already have a group of really amazing people in the forum who help a lot of the users who turn to the forum with their Firefox support questions. However, we definitely need more contributors to cope with the load.

One important thing to focus on in order to make it more pleasant to hang out in the forum is to make the site easier to use for our contributors. We have a few ideas:

• Give contributors credit for solving problems — Allow the user posting the original question to tell us whether or not an answer from a contributor solved the problem, giving contributors credit for their help. Readers of the earlier parts of this blog series might remember the discussion about a contributor karma system in part 3.
• Highlight the solution to a problem — Some forum threads quickly grow long, making finding the actual solution to the posted problem hard to find. Other people who stumble across the thread in search for a similar (or same) problem typically want to get straight to the solution, which could be buried on page 4 of a very long thread. We should make that solution easily discoverable at the start of the thread, by allowing the original poster of the thread to mark a particular response in it as the solution to the problem. This will benefit not just our users, but our contributors as well.
• RSS feed for incoming support questions — Instead of having to log in to SUMO in order to read the latest incoming support questions, a convenient alternative would be to just subscribe to an RSS feed (also known as Live Bookmark in Firefox). This way, people could set their mail client (e.g. Thunderbird) to notify whenever a new question is posted.
• Smart forum thread filters — When browsing the forum today, all questions are listed, including the ones that are already answered. Many contributors are more interested in looking at threads that haven’t been answered yet. Others might want to see only the threads they’ve responded in. We should allow for an easy way to filter the forum view based on what’s relevant for our visitors.
• Localization — This is a big one. We currently only have an English support forum and we’re starting to get more questions posted in other languages as the visibility of SUMO increases. For the locales that have enough contributors a need for it, we should definitely create a support forum in that language.

What other ideas can you think of that would make the forum more pleasant to use for you? We would love to hear from you about your experiences with the SUMO Support Forum so we could use your feedback to improve the site for everyone.

Sumo

• Localizer feedback
• Weekly metrics
  • Less traffic this week, and less community involvement
• Weekly support issues
  • For Hendrix, we have an experimental database built now that sorts each post into a category so it’ll be easy to pull up the raw data now and collect information with a simple SQL query. Cww will be putting in all the info from the support forums as well pending bug 455790. Once this is done, we’ll have a form where we can look up everyone who has a certain issue.
  • By far the most common issue right now is people being confused about the Awesome Bar not appearing to erase their history
    • Evidence that many people report this in the Forum as well. Many people are asking how to downgrade to Firefox 2.0.0.x
    • We have a downgrading to Firefox 2 article, but we need to add a paragraph explaining why downgrading is a bad idea, and how people can disable the Awesome Bar functionality anyway if they really need to

Knowledge Base

• Bugzilla: no activity (all around pretty quiet week)
  • remember to add user-doc-needed to bugs that require changes in documentation or new documentation
• Add-ons policy
  • Policies page is updated, but could improvement. [1]
  • New content block: label=amo
  • Add-on links have been removed from most articles with some exceptions. Dynamic content still needs to be applied. cilias will work on implementing this for related articles this week.
• List of top articles for translation: [2]
• Looking for suggestions on how to get more approvers to review other people’s edits [3]
  • djst thinks we need to make the review queue more obvious to contributors — need a good contributor start page and make sure we direct people who log in to that page
• We should remove instructions on how to completely disable all history in the Awesome Bar. Very few people actually want that, and we also have evidence of people thinking they broke Firefox when applying that “fix”

Support Forum

• Traffic slightly down, by ~ 15-20%

Live Chat

• Traffic down; chat requests down almost 30%
• 2 new accounts created, 0 account approvals
• New common issues: crashes (crash-stats still down, bug 455999), yahoo toolbar causes window jumping, Firefox 3 “crashes entire computer”, default browser corrupted/wrong browser launches on Windows

I’ve started a discussion in the Support Contributors forum soliciting feedback and general brainstorming criteria for a new article editor. I’ve included some of the criteria based on the survey feedback, such as making the editor WYSIWYG, and tools to make features like SHOWFOR and Dynamic Content easier to use.

Have you been editing or writing new articles in the Knowledge Base? What did you think about the process and was there anything you’d like to change? We’d love to hear your feedback. Please post your ideas in the discussion thread. Thanks!

The Knowledge Base is meant to be the primary method of getting support, since it already contains the answers to the most common Firefox issues. Because of this, the articles in the Knowledge Base need to be:

1. easy to find,
2. easy to understand, and
3. easy for contributors to edit.

Let’s cover them one by one — easy as 1-2-3!

1 - Better search

Searching is central to the support funnel –- we want people to search for their problems first. Because of this intended flow through the funnel, it’s critical that the search function is working well and serving the right results.

There are some problems with our current search engine. Most importantly, we don’t have fine-grained control over its behavior, and we can’t control the frequency of its reindexing (the process of making sure all articles are searchable). This means that it might take weeks after a new article is created until it appears in the search results, which is really not ideal.

• The search engine should index the Knowledge Base article on a daily basis to ensure up-to-date search results.
• When a new article is published, the search engine should automatically re-index to include it. Being able to quickly ensure new information is accessible to our users is critical if e.g. a new issue is discovered after a new release.
• Search rating should primarily be based on the frequency of the reported problem, the article tags it contains, and its description. It should also support manual tweaking to ensure new and critical issues are getting a top search result listing even before they’re naturally picked up by popularity.

We could also do a better job of integrating the provided solutions to problems from the Support Forum with the search results. For example, when a user searches the Knowledge Base, we could offer a simple way to extend the search to include answered threads in the forum as well.

Another area of improvement is with locale specific searches. Today we include matches in English articles too, but there’s no clear distinction between the content available in the local language and the English (still untranslated) content.

All in all, this should make articles easier for users to find.

2 - Screencasts

Some users resort to the Support Forum or Live Chat simply because they don’t understand the contents of a Knowledge Base article and need some hand-holding to solve their problem. Screencasts (essentially videos) is a powerful visual medium that helps translate and communicate technical concepts to a wider audience. Even for users who are perfectly capable of following written instructions, watching a screencast can speed up the problem solving process significantly.

Frequent readers know that we already have a bunch of screencasts ready to be used in the Knowledge Base — we just need to get the infrastructure up so we can actually provide them to our readers. Specifically, we need:

• an easy way to upload and embed screencasts into Knowledge Base articles, and
• an elegant way of presenting them in the articles themselves, for example a simple “Show me how” link, expanding into a full screen video view upon clicking; no annoying pop-up windows; all embedded into the page à la Web 2.0.

Once we have this up and running, articles should be easier for users to understand.

3 - Streamlined article editing

Since the Knowledge Base is our most powerful tool to provide efficient support for our users, it’s equally important that this tool is as simple for contributors to use as possible. We have some ideas:

• What You See Is What You Get (WYSIWYG) editing — editing a Knowledge Base article should be as simple as writing a blog post. This is easier said than done, but it’s definitely worth investigating the possibilities, as it would dramatically simplify things for casual Knowledge Base contributors that just want to correct a typo without having to learn a whole new wiki syntax language.
• No-nonsense editing process — remove buttons and options that are just confusing. Right now there are a lot of them, and they’re laid out in a somewhat confusing way.
• Other ideas? This is where you come in. Chris Ilias started a thread to discuss this item more thoroughly, and we’d love to hear your feedback!

With these improvements, Knowledge Base articles should be easier for our contributors to edit, allowing more people to participate.

And that ends part six. As simple as Do Re Mi.