Jump to: navigation, search

Difference between revisions of "User Interface Best Practices Working Group Charter Related Activities"

 
(UI POLISH REVIEW)
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
POST-MORTEMS
+
Here are the details of the various UI related activities that will be carried on by the working group and the participating project groups.
  
+
===POST-MORTEMS===
  
 
PURPOSE: Assess the state of the project with respect to usability; prioritize corrective measures and work them into the release plan
 
PURPOSE: Assess the state of the project with respect to usability; prioritize corrective measures and work them into the release plan
Line 11: Line 11:
 
SUGGESTED APPROACH:  
 
SUGGESTED APPROACH:  
  
- Project team gathers usability issues from sources which may include, but are not limited to, the following: newsgroup questions, UI walkthroughs, Bugzilla reports, usability tests on the previous release, and so on.
+
* Project team gathers usability issues from sources which may include, but are not limited to, the following: newsgroup questions, UI walkthroughs, Bugzilla reports, usability tests on the previous release, and so on.
  
- Project team members summarize issues into a list and assign severities to each item (e.g., 1 - prevents completion of task, 2 - significant delay in task completion, 3 - minor delay in task completion)
+
* Project team members summarize issues into a list and assign severities to each item (e.g., 1 - prevents completion of task, 2 - significant delay in task completion, 3 - minor delay in task completion)
  
- File requirements for feature level work, file bug reports for smaller items
+
* File requirements for feature level work, file bug reports for smaller items
  
OUTPUT: A prioritized list usability issues to be addressed is posted on project wiki with links to related requirements/bug reports.  This should be a requirement for participation in the simultaneous release.
+
OUTPUT: A prioritized list of usability issues to be addressed is posted on the project wiki with links to related requirements/bug reports.  It is suggested that the list have three categories: committed, proposed, and deferred.  This list should be a requirement for participation in the simultaneous release.
  
+
===PROJECT SHOW AND TELLS===
 
+
+
 
+
+
 
+
PROJECT SHOW AND TELLS
+
 
+
+
  
 
PURPOSE: Share information about what is under way in the various projects; identification and dissemination of good UI solutions, identification and dissuasion from not-so-good UI practices
 
PURPOSE: Share information about what is under way in the various projects; identification and dissemination of good UI solutions, identification and dissuasion from not-so-good UI practices
Line 39: Line 31:
 
OUTPUT:  
 
OUTPUT:  
  
- UIBP group culls potential examples - whether positive or negative - for addressing in the UI guidelines. These are kept in a sandbox type area of the wiki.   
+
* UIBP group culls potential examples - whether positive or negative - for addressing in the UI guidelines. These are kept in a sandbox type area of the wiki.   
  
- Any suggestions for UI improvements from the UIBP group are communicated directly to the project UI contacts
+
* Any suggestions for UI improvements from the UIBP group are communicated directly to the project UI contacts
  
+
===UI POLISH REVIEW===
 
+
+
 
+
+
 
+
UI POLISH REVIEW
+
 
+
+
  
 
PURPOSE: Identify candidates for final hour usability/UI cleanup.  These items will tend to be cosmetic since few if any destabilizing changes can be introduced at this point.
 
PURPOSE: Identify candidates for final hour usability/UI cleanup.  These items will tend to be cosmetic since few if any destabilizing changes can be introduced at this point.
Line 61: Line 45:
 
SUGGESTED APPROACH:  
 
SUGGESTED APPROACH:  
  
            - Members of the review group refresh their recollection of the UI guidelines checklist (each member can cover several sections)
+
* Members of the review group refresh their recollection of the UI guidelines checklist (each member can cover several sections)
  
            - The group jointly walks through the product, following the major usage scenarios, and identifying areas for improvement, both within the project as well as in related projects
+
* The group jointly walks through the product, following the major usage scenarios, and identifying areas for improvement, both within the project as well as in related projects
  
            -  Polish suggestions for related projects are sent to the relevant project UI contacts for their consideration.
+
* Polish suggestions for related projects are sent to the relevant project UI contacts for their consideration.
  
            - A list of potential fixes is prioritized for the specific project and the set that will actually get fixed is decided upon
+
* A list of potential fixes is prioritized for the specific project and the set that will actually get fixed is decided upon
  
            - Bug reports are filed accordingly
+
* Bug reports are filed accordingly
  
 
OUTPUT:  A final fix list is posted on the project wiki with links to associated bug reports.  This should be a requirement as part of the release exit criteria.
 
OUTPUT:  A final fix list is posted on the project wiki with links to associated bug reports.  This should be a requirement as part of the release exit criteria.
 +
 +
[[Category:User Interface Best Practices Working Group]]
 +
[[Category:User Interface]]

Latest revision as of 20:54, 12 January 2007

Here are the details of the various UI related activities that will be carried on by the working group and the participating project groups.

POST-MORTEMS

PURPOSE: Assess the state of the project with respect to usability; prioritize corrective measures and work them into the release plan

TIMING: At the start of a new development cycle, during planning phase

WHO DOES THIS: UI contacts and interested others from a given member project

SUGGESTED APPROACH:

  • Project team gathers usability issues from sources which may include, but are not limited to, the following: newsgroup questions, UI walkthroughs, Bugzilla reports, usability tests on the previous release, and so on.
  • Project team members summarize issues into a list and assign severities to each item (e.g., 1 - prevents completion of task, 2 - significant delay in task completion, 3 - minor delay in task completion)
  • File requirements for feature level work, file bug reports for smaller items

OUTPUT: A prioritized list of usability issues to be addressed is posted on the project wiki with links to related requirements/bug reports. It is suggested that the list have three categories: committed, proposed, and deferred. This list should be a requirement for participation in the simultaneous release.

PROJECT SHOW AND TELLS

PURPOSE: Share information about what is under way in the various projects; identification and dissemination of good UI solutions, identification and dissuasion from not-so-good UI practices

TIMING: Over the course of the development cycle

WHO DOES THIS: UIBP group schedules these meetings with UI contacts from the various project teams;

SUGGESTED APPROACH: A given project team demos their software. Emphasis may be given to UI solutions that the team thinks are good candidates for more general adoption. They may also want to focus discussion on UI areas they think are problematic. The presentation must accommodate a distributed audience (e.g., use WebEx or comparable technology). Although the meeting will focus on a given project, each meeting should be publicized to UI contacts from all projects so others can optionally attend.

OUTPUT:

  • UIBP group culls potential examples - whether positive or negative - for addressing in the UI guidelines. These are kept in a sandbox type area of the wiki.
  • Any suggestions for UI improvements from the UIBP group are communicated directly to the project UI contacts

UI POLISH REVIEW

PURPOSE: Identify candidates for final hour usability/UI cleanup. These items will tend to be cosmetic since few if any destabilizing changes can be introduced at this point.

TIMING: Late in the development cycle - post code complete but fairly early in the bug fixing phase

WHO DOES THIS: Minimally, the UI team members from each project; it's also a good idea to invite one or two additional individuals who aren't as close to the project - they can offer a novel viewpoint

SUGGESTED APPROACH:

  • Members of the review group refresh their recollection of the UI guidelines checklist (each member can cover several sections)
  • The group jointly walks through the product, following the major usage scenarios, and identifying areas for improvement, both within the project as well as in related projects
  • Polish suggestions for related projects are sent to the relevant project UI contacts for their consideration.
  • A list of potential fixes is prioritized for the specific project and the set that will actually get fixed is decided upon
  • Bug reports are filed accordingly

OUTPUT: A final fix list is posted on the project wiki with links to associated bug reports. This should be a requirement as part of the release exit criteria.