Authoring Summit - Project Planning

Topics that should be considered at the Authoring Summit

Team Structure - What do we need, how do we get there?
Design and Dev Process - At least in broad strokes
Timelines - What does our schedule look like?
Deliverables - At least high-level
How does Fluid fit in to all of this?
As volunteers, how efficient do we really expect to be?

Work that should be done to prepare for the Authoring Summit

Make sure key stakeholders attend. If names of key participants have not been added to the list in September 2008 Authoring Summit, please contact them and ask them to attend or send your suggestions to mkorcuska@sakaifoundation.org (Former user (Deleted)) or jimeng@umich.edu (Former user (Deleted)).

Assess other efforts to see if some framework already handles things (also wysiwyg editors). Has anyone looked at this yet?

Project Planning Overview

Team

Below is a proposed project team structure for this work. This is just a proposal to get some discussions flowing. I recognize the complexity and time issues related with forming this type of team, but this would be "ideal" if we can manage it.

Feel free to edit the diagram – it's a work in progress.

Process

In a nutshell, the process should start with design leading the way and *development playing a supportive role. Once the project moves into implementation, development should lead the way and design should play a supportive role. The Sakai ED (Michael) and the community stakeholders (including: board members, managers, thought leaders, and community members at large) should provide careful guidance and review as the project moves along – in other words, they should play a supportive role throughout.

Once ready, we cut off what we can and send it over to testing.

*Some asynchronous development can happen during the design phase.

THE DISCOVERY PHASE

1. Research and Analysis

This is not exclusively a designer or user-centered activity. Everyone will need some time to get a handle on "what" we want to build.

Design can help facilitate some brainstorming activities, but will ultimately venture off down a user-centered path. Developers will probably conduct their own research and tinker with test cases and prototypes, etc. (Please add to this if you like)

We should plan enough time so the entire team can come up with questions and seek out the proper answers. This will take more than just a couple days – and will likely have an on-going aspect to it. But it also shouldn't go on forever! I typically time-box these activities and cram in as much as possible within a give time. If more time is needed, we'll cross that bridge once we come to it.

The emphasis from a design perspective is to understand who the users are, what their goals are, what type of tasks they'll need to perform in order to achieve their goals.

Designers will also be concerned with business (or institutional) requirements. For example, what is the motivation for building/deploying this solution? Aside from it being usable, how will we know if the design is successful?

2. Calibrate The Plan

Depending on the outcome of the Research & Analysis step, it's sometimes necessary to regroup, adjust expectations, and tweak the project plan to reflect a realistic outcome.

THE UX DESIGN PHASE

1a. Interaction Design

Once we get a *reasonable handle on the discovery, we can move into sketching out screens. Everyone has a slightly different approach to this. It's also important to note that the line that separates Discovery from Design isn't always perfect. Sometimes activities alternate between the two as designers review the research, sketch stuff out, return to do a little more research, etc.

*The pursuit of perfection is endless. To keep these steps reasonably organized, I suggest we time-box our efforts and cut things off when we run out of time. This might mean making some decisions early on with respect to how we'd prefer to compromise in such an event. For example, would we like breadth or depth in what we cover in the first release?

1b. Interface Design

This step links the step above to the step below – there is a lot of overlap with each of these steps, though they don't necessarily start at the same time. Interface Design is not the pretty colors (that's the Visual Design step), but is the screen-level layout of the UI. The way a UI is laid out has EVERYTHING to do with how easily it is understood. Bad layout also can effect the scalability of the design. For example, what happens if a user joins another site? Oops, it doesn't fit in the horizontal navigation. That's an example of the Interface Design step.

1c. Visual Design

This step is usually a bit misunderstood and therefor under-planned. This step compliments the Interface Design step by polishing the details on the screen. The emphasis is not just on layout, but colors, contrast, balance, scale, proportion, and the like. More over, this step thinks about style systemically. How can elements be styles in a modular way so that a skin change can cascade properly.

2. Usability Testing

Let's plan for this now! We don't need to go crazy, but some quick and light usability testing will surely go a LONG way.

The above steps are not necessarily serial in nature. Typically they start out as a waterfall, but then churn together.

—

Note: Along the entire process, developers and Sakai stakeholders should review and offer feedback on the progress of the designs. It's crucial to pay close attention to details, offer unforgiving criticism, and challenge the designers as much as possible. If we don't have an answer for why we're doing something, then it doesn't belong.

Dependencies:

Being aware of accessibility issues
Being aware of technical constraints

THE UX DEV PHASE

Can someone please fill this in?

THE JAVA DEV PHASE

Can someone please fill this in?

THE QA PHASE

Can someone please fill this in?