Support:PRD
Firefox Support Requirements Document
Overall project requirements
(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
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."
Technical requirements
This summarizes our technical requirements for the overall project:
- Bla bla [1]
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.
Forum requirements
The Firefox support forums will provide users an opportunity to ask support questions that are not addressed in the KB. Users will be directed to search the KB before using the forum.
The forums will also be used as a feedback mechanism for KB articles.
The forums will be used by three types of users:
- End users seeking support (they will have already searched the KB and were unable to find a solution)
- Contributors providing support
- Administrators
Getting information out of users
Contributors need complete information from end users, but end users may not want to provide it (additional work) or may not know what to provide. Whenever possible, we should automate the information gathering. Information we could gather automatically:
- OS (from user agent)
- Firefox version (from user agent, or prompt the user if the user agent isn't Firefox)
- What the user has searched for already
- What articles the user has visited already
Other information can't be gathered automatically. We could prompt the user to include this information with separate text fields for each piece of information (like the Bugzilla Helper) or with instructional text. Not all text may apply for all situations. Information we could prompt for:
- URL
- Short description of the problem (thread title)
- Steps to reproduce
- Expected results
- Actual results
- When the problem started happening
- Configuration info such as add-ons installed
- Error text
- Screenshot
End users may reach others' threads when looking for a solution. To ensure they get the best information from this path, encourage end users to create a new thread rather than re-use someone else's thread.
Helping users find their questions later
End users will need to find their questions after posting them. Possible ways they could do so:
- Prominent link to threads they've posted in
- E-mail notification, possibly defaulted to notify
- Feed
The first two require end users to register, which they may not want to do. We should encourage them to register, but not require it. To encourage them, we should make registration very easy (a few fields on the New Question screen) and explain why it's useful to register.
Unregistered users can cause problems for contributors and administrators. Contributors can get confused by multiple anonymous users, and not requiring registration could potentially cause spam problems. To mitigate these problems:
- Force the end user to at least give themselves a name, and remember this name (via cookie?) for future posts.
- Use a captcha or similar
End users will want to not be distracted by other threads and options that may be useful to contributors. We should provide two different views - one for end users that lets them track their questions and post new ones, and one for contributors that's like a normal forum (forum list, advanced views, etc.). Which view to show could be determined by roles or at different URLs.
Helping contributors find information
Contributors want to be able to find certain threads, such as:
- Threads they've posted in.
- Threads via arbitrary criteria (advanced search).
- Threads where the user is still looking for help. Allow end users to mark their question as answered and provide a filter for contributors based on this info. This could be extended to say which post answered the question, which could tie into a contributor rating feedback mechanism.
Helping contributors help users
Contributors will be linking to KB content often when helping users, so we should make it very easy to do.
- Allow contributors to use wiki syntax (double parenthesis) for links.
Helping contributors help each other
Contributors will want to discuss things with each other that aren't support requests. Give them a forum or forums to discuss things with each other.
Technical requirements
This summarizes our technical requirements for the forums:
- Gather information automatically and manually from users when they post a question [2]
- Include text to encourage users to create new threads rather than use existing threads[3]
- Prominent link to a user's previous threads [4]
- Notify users of responses by e-mail by default.[5]
- Make it easier for users to register when creating a new question[6]
- Allow anonymous posting with captcha [7]
- Require anonymous users to name themselves [8]
- Simplified view for users [9]
- "Threads I've posted in" [10]
- Advanced search[11]
- Mark a thread as answered, and filter based on this data.[12]
- Wiki syntax [13] (FIXED)
- Create a contributors' forum (FIXED)
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 the OpenFire application.
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 queried 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 statements e.g.: “Don't give out personal info” (credit cards, usernames, passwords, etc).
Support Volunteer Interface/Experience: (This is not a requirement but rather a request for future enhancement: 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 (not up to date):
- 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
Functionality:
- 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