Project Proposal

Proposal

Personas & Task Analysis

Management Methodology
Personas & Goals
Task Analysis
Participation
Appendices

Scenarios, Comparative Analysis & Initial Design

Scenarios
Persona Revisions
Comparative Analysis
Flow Diagram
Initial Design
Participation

Low-Fi Prototype

Introduction
Prototype Description
Prototype Photos
Method
Test Measures
Results
Discussion
Appendices
Participation

First Interactive Prototype

Prototype Differences
Storyboards/Sketches
Prototype Overview
Screenshots
Running the Prototype
Participation
Presentation Slides

Project Heuristic Evaluation

d.r.e.a.m. Evaluation
d.r.e.a.m.'s Evaluation

Second Interactive Prototype

Prototype Changes
Screenshots
Running the Prototype

Pilot Usability Study

Introduction
Method
Test Measures
Results
Discussion
Experiment Design
Appendices

Third Prototype & Final Writeup

Third Prototype
Problem Statement
Solution Overview
Personas & Scenarios
Final Design
Design Evolution
Final Presentation

Paper Prototype Description

Our prototype was driven by two main considerations. First, we wanted the input to maintain as much consistency as possible with the output (although we are willing to redesign the output to bring the two into line with each other). We feel that the input interface should basically look like the syllabus output but with links for editing content. We had the idea for this kind of framework early on, and the feasibility of such an approach was reinforced by our comparative analysis of H2O. Secondly, we have a very rigorous model for syllabus data that we've developed and tested over the last nine months. As such, we know exactly what data we need from the user, and we need to figure out how to extract this information in the most comfortable manner.

We decided to construct our prototype around the basic functions of creating a new syllabus - entering general course information, adding some topics, classes, and readings, and moving those around. We decided to ignore, for the time being, issues such as registering with SylViA, managing permissions, and specialized inputs for exams and assignments. We created 10 basic screens - login, My SylViA home page, editing required course information, display of course information, editing of additional course information, display of schedule/syllabus, editing of topics, editing of classes, editing of readings, and editing of resources. There were various versions of all these pages so the user could progressively add and edit more information. There were also a couple of specialized screens that clarified user input (as alternatives to error messages). When a user clicked the add syllabus button, we showed a screen that asked whether they wanted to create a whole new syllabus or reuse one from prior semesters. Also, as part of our scenario, we asked users to move one class into a space when there was another class already entered. When they do this, we show a screen displaying options for the move - they can cancel, swap classes, bump the target class down, combine classes, or overwrite the target class.

All screens were enclosed in a My SylViA header with some basic navigation links on the left-hand side, links which allow for returning to the My SylViA home page, going to the SylViA output viewer, and logging out. Once the user was editing a particular syllabus, we added navigation for the different editing screens (course information, schedule, and assignments, though assignments was not built in the prototype) and administrative screens (manage permissions and preview).

A general challenge was creating a nice interface for areas where users could optionally input multiple sets of data, such as filling out multiple author names for a reading or multiple office hours for a professor. We decided on a general approach of creating a shaded area behind each group of fields with a button at the bottom right corner of the field to "add another author", "add another office hours", etc. When the user clicked these "add another" buttons, the page would reload with all information saved and a new field group displayed, and we actually built this out in paper for the office hours and included it in a scenario.

We had many drop down menus, which we constructed from index cards taped to a transparency handle that allowed the "computer" to move them into and out of the interface more gracefully. Also, in response to our last user, who had a tendency to stray from the script and start clicking random buttons, we had to create an emergency "404" page (see photos for example).