[ui-best-practices-working-group] Revised charter related activities

["Troy Beecroft" <troyb@xxxxxxx>]

Hi All,

 

Here's a revision based on comments from the last meeting.  Additional
feedback welcome.  Also, here's a couple of notes that apply, from the
discussion.

 

-Troy

 

It will be easier for other project teams to effectively conduct these
activities if one or two key projects lead the way.  This will not only
set a good example for peer projects, but provide concrete examples of
format and content of the outputs.

 

Additionally, we'll need to establish at least one UI contact on each
member project.  This person will interact with the UI Best Practices
group on related activities and serve as the lead on required
activities.  In projects where it makes sense, such as when the UI work
is distributed among various individuals, more than one UI contact will
be determined, and responsibilities shared among them. A directory of
the UI contacts should be maintained on the UI Best Practices wiki.

 

 

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 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.

 

 

 

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.

 

>>Register now for BEA World 2006 --- See http://www.bea.com/beaworld<<
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.