Support:PRD

Firefox Support Requirements Document

End-user navigation process

(see chart and home page mock-up) http://wiki.mozilla.org/images/9/9d/Support-Firefox_Support_Work_Flow.pdf

Overall requirements of solution

One log-in for forums and knowledge base management and preferably chat as well.

• Account levels (admin, senior moderator, moderator, senior editor, editor, volunteer)

• Analytics and metrics
  • Need way to collect metrics from the content management system.
  • See SUMO Weekly Metrics

Knowledge base requirements

The Knowledge base is the back bone of the Firefox support platform. All known issues should be addressed, as best possible, in a user friendly knowledge base article that is easily and quickly accessible to an end-user.

Two main types of content on the knowledge base: How To’s and Troubleshooting

How To’s: Also known as tutorials or best practices, How to’s will initially be populated with content from “Firefox Help.” All How To content will be organized in a directory tree structure and will be built out to include Firefox tips, tricks, tutorials, best practices, etc. displayed various formats for users (text, screenshot demos, flash/YouTube demos, etc).

Troubleshooting: This is the content that is more generally associated with “support” that helps users solve problems they have with Firefox. The troubleshooting section will initially be populated with MozillaZine Knowledge Base content that will be organized in a tagging structure that incorporated most frequently accessed questions data. KB style guides will allow for most user friendly help content and will evolve to include visuals.

Content Creation

Knowledge base content will be community driven. Troubleshooting content will be driven in large part by user requests, while How To content will have some initial prioritization on what the most high-leverage areas for work. Only logged-in Mozilla volunteers will be able to suggest/make changes to documents, while users will be encouraged to comment on all content—although comments will be hidden from public view initially to eliminate spam problems.

New documents:

Volunteer writes documents and assigns priority for editor review

Two separate editorial approval processes: content and style (content can be published initially if correct, even if not style guide needs to be implemented)

Existing documents / edits:

Minor (spelling, grammar, etc): Push live

Major: Same review as new documents

Style Guide: All Firefox support documents should be written for an audience of a slightly below average internet user (doesn’t read blogs—or at least wouldn’t know one if he saw one) and take the tone of a friendly, helpful community volunteer.

• Develop style guide for How To’s and for Troubleshooting docs
  • include requirements for any visuals (screenshots, flash/video, etc)

Feedback system: All articles will have a rating system to determine how useful the article is to users. To allow for these ratings to factor in to a volunteer user’s ratings, end-users should be able to rate it on a 1-5 scale (probably stars). Users are strongly encouraged to add comments on why something was not helpful, or what information would help them answer the question.

Recognition of volunteers: If user writes highly-rated article, we want to recognize their success through an overall Firefox support volunteer points system.

URL Structure

• support.mozilla.com/en-US/kb/Article+Name
• support.mozilla.com/sv/kb/Article+Name
• support.mozilla.com/en-US/chat/
• support.mozilla.com/en-US/forum/

When accessing a locale that doesn't include the requested kb page, it should fall back to en-US (or the fallback language a logged in user has specified). However, the actual URL would still be the foreign locale, and there would be a message on the page saying e.g. "This page is not yet translated to [language]. Feel free to help us out."

Content Migration Strategy

• need to develop some strategies and make some decision here.
• Don't want old links to break
• Redirects? Buttons on pages?
• Exchange specific articles between locals?

Forum requirements:

The Firefox support forum will provide users an opportunity to ask support questions that are not addressed in the knowledge base. This single forum will be moderated and edited by Mozilla community volunteers.

User Posting

Before a user posts, encourage a search of current forum content. In order to ensure that we can communicate with users when their questions are answered, there will be no anonymous posting. Users will be given the option register with a username and email address for contact when the post is answered, otherwise we will supply a username automatically. Also, using a cookie, keep the user logged in to show an alert when the posting is answered--even if there is no email address. Also, if there is no reply within 2 days, users should be contacted and alerted to other support options.

Moderators

Easy for moderators/volunteers Tools for volunteers:

• Queue of new and unanswered posts for volunteers to answer
• Creation and training of best practices for responding to forum posts
• Moderator guide

Easy to move answers from forum to knowledge base

Build layers of responders that have areas of expertise that can assist with more detailed response and engage developers on necessary problems

Feedback will be an important

"This post/user answered my question" signifies post can be closed and rates the volunteer's response.

Feedback ratings become reflective of volunteer's experience and expertise (combination of number of responses and quality of responses).

Chat requirements

Live chat will be an easy to use real time communication channel for users who can’t find answers to their questions in the knowledge base and forums. Through a web interface (no download required), users will chat with community volunteers who will be using IRC.

End-User Interface: Users should be able to access the live chat from the browser, with no download initially. Users should be prompted to ask a question or tell their problem before initiating the live chat (possibly some segmentation from a drop down menu). That question or problem should be queiried in the knowledge base and forum and suggest documents to the user. If those don’t help, users should be able to initiate the live chat, with that question/problem carrying over to the chat. The chat should appear to be a 1 to 1 communication.

Interface should also include a statement” “Don't give out personal info” (credit cards, usernames, passwords, etc)

Support Volunteer Interface/Experience: Integrate with IRC to tap in to existing IRC support community, make collaboration easier for more complex support questions, and enables peer review to ensure high quality responses. Although it will actually be 1-->group, it will appears as one-to-one for the user. Helpers will have simple solution to directly address user, while collaborating with others.

Chat Workflow and Functionality: User asks question and logs into web-based chat ->Bot gives welcome user-> Question goes to special channel on IRC, private, supporters only->Supporters respond using that user's nic--User requesting support gets assigned an alias (should be alpha order and cycling [aardvark, balognia, cat, ... abercrombie, bbital, etc] to make it easier for supporter to respond)->After session is complete, users are asked to rate the experience

• Ability for browser info to appear to the supporter (version, OS, etc)
• Ability to push screenshots to users during chat session
  • Way to get screenshots from users
• Allow users to get back into same chat after browser restart
• Ability to show that chat "Offline" based on idling or lack of helpers
  • Some sort of “busy” or “you are #XX in the queue” to let users know why someone is not helping them right away