Meeting about Design Doc Types & Templates, 1 Mar 2004

Attending: MimiYin, BrianDouglasSkinner, ChaoLam

Goals:

rationalize the Project Overview Table with the UIDesignArchive^?
identify a list of canonical page types & set up page templates for all the page types
have a better policy for figuring out which pages go on Chandler vs. which go on Jungle (e.g. Workflows), and how pages get "promoted" from Jungle to Chandler

Proposal: Page Types

MimiYin and %ID_BRIAN% are proposing that the design group organize its work into the following seven types of pages:

	"About" Page	Examples	Sections & Content	Wiki-Web	# Pages
Overview Pages (formerly called "Design Docs")	About Design Documents (need to rename this page)	Contacts General Information Management (need to rename and reorganize this page)	Summary Structure Use Cases name narrative "when status" (listed in order of priority) Terminology Overview Feature List name description "when status" Open Issues Notes Page Status	Chandler	maybe a dozen
UI Component Spec Pages	About UI Component Specs	Summary Table View	Summary Motivation Wireframes (with callouts) Open issues Links to relevant workflows "Functionalities" narrative "When status" interaction spec storyboard Page Status	Chandler	about a dozen
Workflow Pages	(needs to be created)	Customizing Content Areas	Summary one or more workflows, each with the following... Name Motivation Narrative Storyboard Open Issues "When status" Page Status	Chandler	dozens
Detailed Use Case Pages	(needs to be created)	Stamping Use Case	Use Case Name Summary Scenario Narrative "When status" Links to relevant workflows Page Status	Chandler	about a dozen
Glossary Entry Pages	none	Parcel^?	Term Definition "See also" links Usage	Glossary	dozens
Scratchpad Pages	(needs to be created)	Brian's XML Format Notes Processing vs. Filing	anything you want	Jungle	about a hundred
Table of Contents Pages	(needs to be created)	Project Overview Table UI Design^?	Summary/Intro/Purpose Links	Chandler	exactly two

%ID_BRIAN% also suggests that we might want to have the Design Group To Do List^? be a page that has a specific page type. It seems like it could be either of two types:
1. a "to do list" page, like these:
2. a "working group home page", like these:

We might also want to have simple naming conventions for different page types. Here are some examples:

page types	example names	naming patterns
Overview Pages (formerly called "Design Docs")	"CalendarOverview"	_____Overview
UI Component Spec Pages	"BookmarkBarSpec"	_____Spec
Workflow Pages	"StampingWorkflow"	_____Workflow
Detailed Use Case Pages	"StampingUseCase"	_____UseCase
Glossary Entry Pages	"Parcel"	_
Scratchpad Pages	(anything you like)	none
Wiki Help Pages	varies	none
Wiki Infrastructure Pages	varies	none
Home Pages	"CommunityHome" "GlossaryHome" "WikiHelpHome"	_____Home
Table of Contents Pages	"GlossaryIndex" "CommunityContents"	_____Index _____Contents
To Do List Pages	"DesignToDoList"	_____ToDoList

Replace the "Workflows" row and its 7 sub-rows with the following row and sub-rows (thereby reversing our 19 Feb 2004 decision ):
- General Information Management
  - Entering
  - Stamping
  - Collecting
  - etc.
Take "Mundane Features", "Interoperability", and all their sub-rows, and move them into their own table. Put that new table below the existing "Engineering Infrastructure" table
Rename the "End-User Features" table to be the "Chandler Landscape" table
In the "Chandler Landscape" table (aka End-User Features table), reorder the sections so that they end up in this order:
- General Information Management
- UI Components
- Functional Areas -- Mail, Calendar, Tasks, Contacts, Notes, IM
Take the two existing columns for "Design Docs" and "UI Design", and replace them with three columns, titled "Feature List", "Workflow", and "UI Component Spec". Each row can have entries in one or more of these rows.

Questions from Chao	Answers from Mimi & BrianDouglasSkinner
Is it okay that we have "open issues" recorded in many of the different doc types, rather than in a single place?	Yes, let's do it that way. It makes it easy to capture open issues whereever they come up.
How do we keep track of and process open issues?	The Project Overview Table will have links to all of the docs that include "open issues" sections. We will work our way through the Project Overview Table, stepping into each doc and resolving open issues as we go.
The proposal above outlines all the doc types we'll use for describing the Canoga design. How does this map to dot release planning and dot release specs?	Let's defer this issue for now.
Who is the target audience for each doc type?	For all of the doc types, the target audience includes both the design group and engineering.
Questions from BrianDouglasSkinner	Answers from Mimi & BrianDouglasSkinner
How do we keep track of what's proposed vs. what's approved?	For each page, we will have a PageStatus form with on of the 3 standard "page status" value. Within a page, for individual features and use cases we will have a "when" column with one of the 8 standard when values.
What goes in the Jungle and what goes on Chandler?	The "Scratchpad" pages go in the Jungle, and everything else goes on Chandler.

BrianDouglasSkinner: update Project Overview Table to reflect decisions listed above
MimiYin: move 'official' UI design docs from Jungle to Chandler
MimiYin: populate the Project Overview Table with links to the 'official' UI design docs
BrianDouglasSkinner: create "page type bars" for the new page types, modeled on the current "This is a design doc" bar
BrianDouglasSkinner: add "page type bars" to all the design group pages on the Chanlder wiki-web
MimiYin: propose standard templates/formats for the new page types: Workflow pages, Detailed Use Case pages, and UI Component Spec pages

Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.