Support:PRD: Difference between revisions

← Older edit

Support:PRD (view source)

Revision as of 01:38, 11 March 2008

5,978 bytes added , 11 March 2008

no edit summary

Np

103

edits

@@ Line 2: / Line 2: @@
-= End-user navigation process  =
+=Project overview=
-(see chart and home page mock-up)
+One log-in for forums and knowledge base management and preferably chat as well.
-http://wiki.mozilla.org/images/9/9d/Support-Firefox_Support_Work_Flow.pdf
+* Account levels (admin, senior moderator, moderator, senior editor, editor, volunteer)
+* Analytics and metrics
+**Need way to collect metrics from the content management system.
+**See [http://wiki.mozilla.org/SUMO_Weekly_Metrics SUMO Weekly Metrics]
+== End-user navigation process  ==
+See chart and home page mock-up [http://wiki.mozilla.org/images/9/9d/Support-Firefox_Support_Work_Flow.pdf]
 http://wiki.mozilla.org/images/thumb/e/e6/Mockup1.2.jpg/745px-Mockup1.2.jpg
-= Overall requirements of solution =
+== 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/
-One log-in for forums and knowledge base management and preferably chat as well.
+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."
-* Account levels (admin, senior moderator, moderator, senior editor, editor, volunteer)
+==Technical requirements==
+This summarizes our technical requirements for the overall project:
-* Analytics and metrics
+*Need an automated way to collect [http://wiki.mozilla.org/SUMO_Weekly_Metrics SUMO Weekly Metrics]. [https://bugzilla.mozilla.org/show_bug.cgi?id=398606]
-**Need way to collect metrics from the content management system.
+*Make sure TikiWiki ignores the number of empty lines before/after headings/lists/paragraphs. This helps us ensuring a consistent article format and layout regardless of the author's conventions and allows us to remove parts of the writing style guidelines. [https://bugzilla.mozilla.org/show_bug.cgi?id=398358]
-**See [http://wiki.mozilla.org/SUMO_Weekly_Metrics SUMO Weekly Metrics]
+*Support for l10n URLs [https://bugzilla.mozilla.org/show_bug.cgi?id=398625]
 = Knowledge base requirements =
@@ Line 24: / Line 39: @@
 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 ==
+== Content Types ==
+The content of the knowledge base are split up in the following two major categories:
-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).
+=== Help ===
+Help translates to "articles about things you can do with just Firefox", like adding a bookmark, using a keyboard shortcut, or similar. Articles under the Help category should be searchable from the Firefox built-in help window, as well as the SUMO web site. See '''Support''' below for what Help is ''not'' about.
+* '''Reference charts:''' Reference charts are points of reference, that list all possible user-oriented options, like keyboard shortcuts, menu reference, command-line options, etc.
+* '''Tutorials:''' Tutorials will take a feature of Firefox, and explain the very basics on how to get started using it. More advanced elements of a feature should not be included in a feature tutorial.
+* '''How To's:''' How To's answer specific questions, regarding the use of Firefox, which could involve a part of a feature, or several features.
-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.
+=== Support ===
+Support translates to "articles about fixing problems in Firefox that require more than just Firefox, or highly technical stuff that should not be exposed to users of the built-in help". For example, how to move a profile folder, or how to configure Norton firewall to not block Firefox.
+* '''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 ==
@@ Line 36: / Line 60: @@
-New documents:
+=== 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)
+Articles are required to be reviewed, before going live. As our community grows, and we have more reviewers, we will have 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:
+New articles will initially existing in a staging area, where it can be reviewed and edited, before being visible to people not logged in. Once approved for visibility to the general public, the reviewer will move the article from the staging area to the public knowledge base.
+=== Existing documents / edits ===
 Minor (spelling, grammar, etc): Push live
@@ Line 48: / Line 74: @@
 Major: Same review as new documents
+All edits need to be made on a staging copy of the article. Once an edit is made, the edit is tagged for review. Contiguous edits by the same contributor will be treated as one edit. Anyone with given permission, can either approve or reject the edit. Once approved, the edit is applied to the KB version of the article. If the editor has reviewer permission, their own edit is automatically approved. Approvals and rejections are done on an edit-by-edit basis; so if there has been more than one edit to a staging copy, each edit has to be approved or rejected.
+=== Style Guide ===
-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.
+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.
+=== Feedback system ===
+All articles will have a poll system to determine if the article is useful to users. 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 by giving them more power to edit articles without review, and automatically approve articles they have reviewed.
+==Technical requirements==
+This summarizes our technical requirements for the knowledge base:
+* Permission to make live edits to live articles should be restricted to those who have already earned our trust. There should never be incorrect information in Firefox Support KB articles.
+** Registered users should still be able to submit edits, either to bugs, or by editing a trunk version of the article, which is going to be tricky to make contributor-friendly. [https://bugzilla.mozilla.org/show_bug.cgi?id=392513]
+* Need way of knowing which staging copies are not same as live copy. [https://bugzilla.mozilla.org/show_bug.cgi?id=401916]
+* Approve and Reject buttons for reviewing article edits. [https://bugzilla.mozilla.org/show_bug.cgi?id=402884]
+** If the editor has reviewer permission, their own edit is automatically approved. [https://bugzilla.mozilla.org/show_bug.cgi?id=403869]
+** Approving edits should add the contributor credit to the live article. [https://bugzilla.mozilla.org/show_bug.cgi?id=401917]
+* If a page doesn't exist for the requested locale, TikiWiki should fallback according to the http accept-language header if not logged in, or according to the user preferences if logged in. [https://bugzilla.mozilla.org/show_bug.cgi?id=398353]
+** If a page doesn't exist for the requested locale, a box should appear at the beginning of the article explaining that the page is not yet translated to the requested language. [https://bugzilla.mozilla.org/show_bug.cgi?id=398354]
+* Need a way of tracking article requests/status without using Bugzilla. [https://bugzilla.mozilla.org/show_bug.cgi?id=398760]
+* Need hidden tags for articles (needs mac review, needs style review, needs updating, etc.). [https://bugzilla.mozilla.org/show_bug.cgi?id=398761]
+* Image optimizing on upload. [https://bugzilla.mozilla.org/show_bug.cgi?id=398762]
+* We need a simple way to create a translation of an existing KB article. [https://bugzilla.mozilla.org/show_bug.cgi?id=398351]
+* Need way of finding the lowest rated articles, without having to check each article poll result individually. [https://bugzilla.mozilla.org/show_bug.cgi?id=398764]
+* Common includes which can be multi-lined, and parsed. [https://bugzilla.mozilla.org/show_bug.cgi?id=398766]
-Recognition of volunteers: If user writes highly-rated article, we want to recognize their success through an overall Firefox support volunteer points system.
+* When a significant change is made on the en-US page, there should be a way to automatically mark all localized versions of the page as "potentially outdated". [https://bugzilla.mozilla.org/show_bug.cgi?id=398355]
+** A "potentially outdated" localized version of an article should have easy access to the diff of the en-US. [https://bugzilla.mozilla.org/show_bug.cgi?id=398356]
+** This "potentially outdated" status should be visible on the page as a box at the beginning of the article, even for users not logged in. [https://bugzilla.mozilla.org/show_bug.cgi?id=398357]
+* By using the same article name/id across l10n, the cross-linking of articles would be maintained without the need to update the links. For example, if the page s.m.c/sv/Article1 pointed to "Article2", the page served would be s.m.c/sv/Article2 (i.e. the Swedish version of Article2). In other words, TikiWiki will remember/save the current locale and parse in-page links accordingly. [https://bugzilla.mozilla.org/show_bug.cgi?id=398352]
-== URL Structure ==
+* support.mozilla.com should be able to detect what operating system the visitor is using, and automatically display a version of the content, that applies to them. In cases where the OS cannot be determined, show Windows content, by default; and always include an OS selector, near the top of each article. [https://bugzilla.mozilla.org/show_bug.cgi?id=388960]
-* support.mozilla.com/en-US/kb/Article+Name
+* Put Tiki breadcrumbs in top gray bar. [https://bugzilla.mozilla.org/show_bug.cgi?id=398087]
-* support.mozilla.com/sv/kb/Article+Name
-* support.mozilla.com/en-US/chat/
+* Move images to image gallery, and make upload image tool upload to the image gallery. [https://bugzilla.mozilla.org/show_bug.cgi?id=398767]
-* support.mozilla.com/en-US/forum/
+* Need a way to link to anchors within another KB article. [https://bugzilla.mozilla.org/show_bug.cgi?id=398768]
-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."
+* Multiple instances of the same header should not produce the same anchor (breaking every TOC link after the first instance). [https://bugzilla.mozilla.org/show_bug.cgi?id=398769]
+* Need a listing of all freetags, to make tagging easier, and more consistent. [https://bugzilla.mozilla.org/show_bug.cgi?id=398770]
+* Search results should include a link to the same search, but for forums. [https://bugzilla.mozilla.org/show_bug.cgi?id=398772]
 = Forum requirements =
@@ Line 136: / Line 204: @@
 * 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.
+* 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.
+** Threads with no replies
+** Threads where the last poster is (not) a contributor
 ==Helping contributors help users==
@@ Line 160: / Line 231: @@
 * Require anonymous users to name themselves [https://bugzilla.mozilla.org/show_bug.cgi?id=396814]
 * Simplified view for users [https://bugzilla.mozilla.org/show_bug.cgi?id=395275]
-* "Threads I've posted in"
+* "Threads I've posted in" [https://bugzilla.mozilla.org/show_bug.cgi?id=398488]
-* Advanced search
+* Advanced search[https://bugzilla.mozilla.org/show_bug.cgi?id=398490]
 * Mark a thread as answered, and filter based on this data.[https://bugzilla.mozilla.org/show_bug.cgi?id=397703]
-* Wiki syntax [https://bugzilla.mozilla.org/show_bug.cgi?id=396578]
+* Wiki syntax [https://bugzilla.mozilla.org/show_bug.cgi?id=396578] (FIXED)
 * Create a contributors' forum (FIXED)
+* Threads with no replies [https://bugzilla.mozilla.org/show_bug.cgi?id=416477]
+* Threads with last contributor response [https://bugzilla.mozilla.org/show_bug.cgi?id=422000]
+* Feed for a thread [https://bugzilla.mozilla.org/show_bug.cgi?id=422001]
 = Chat requirements =
@@ Line 170: / Line 244: @@
 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:'''
+==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:'''
+==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