White Cheddar

• Home Page

Phase 7: 3nd Interactive Prototype

• Final Presentation(ppt)
• Third Interactive Prototype
• Final Report

Phase 6: Pilot Usability Study

• Introduction
• Method and Procedure
• Updated 2nd Interactive Prototype
• Results and Discussion

Phase 5: 2nd Interactive prototype

• Heuristic Evaluation (PDF)
• Response to Heuristic Evaluation
• 2nd Interactive Prototype

Phase 4: 1st Interactive prototype

• Scenarios
• Design Changes
• Storyboard of Scenarios
• Prototype Overview
• Using the Interface
• Work Report

Phase 3: Low-Fidelity Prototypes

• Low-Fidelity Prototypes
• Interview Script (PDF)
• Work Report

Phase 2: Scenarios/Initial Design

• User Scenarios
• Comparative Analysis
• Preliminary Design
• Work Division

Phase 1: Meet Our Users

• How We Came Up with Our Users
• - Meet Modest Mark
• - Meet Linux Larry
• - Meet Assiduous Ann
• Their Tasks
• Common Terms They Use
• Their Thoughts on Their Tasks
• Work Division

Documents and Forms

• Project Proposal
• Informed Consent Form
• Record Release Form

Prototype Overview

We decided to implement the graphical/textual non-linear room scheduling prototype. The primary features of this interface that are what we believe to be improvements on Ad Astra are its tabbed-based navigation, non-linearity of room reservation, and graphical searching and scheduling. Navigation through the reservation process is straightforward and intuitive, using tabs as links from page to page. This provides a means for the user to quickly search for rooms that are appealing for a desired event, or pick rooms based on building and location in that building. Further, in the “specify a time” tab, it allows the user to either textually enter a desired time, or “click and drag” on the room’s schedule to choose a desired time slot.

In this version of the prototype, we decided to leave out a couple of features that existed in past prototypes or ideas. The status bar that we had initially designed into the paper prototype was removed, since that status bar was deemed mostly useless by all of our test users. We are also not including availability for the user to edit their event information in the confirmation/e-mail screen. We wanted to focus the function of this screen onto the e-mail feature, and leave information editing to screens that are more user-friendly, and more importantly, make potential conflicts with times or locations visible.

We are also making a couple of key assumptions for our prototype. First is that the system is linked to the school’s login system, so that contact information about the current user can be transferred into the program via login. We are also assuming that this provides all functionality to work with the back-end users, and that the system will have an up-to-date database of all schedulable rooms available for reservation. Finally, we assume that conflicts that come about post-room reservation can be resolved on the back end, and that an individual can be notified, by email, that his or her reservation needs to be changed (which is something that couldn’t happen before) to accommodate someone higher up in the “chain of command” at Olin.

TOOLS USED

To implement this prototype, we decided to use html. It seemed like the logical choice for an interface that would ideally be web based, and its range of features and flexibility (especially with graphical design) were very attractive at the onset of the interactive prototype. In addition, PHP scripts were used to make the prototype interactive via their ability to store and recall data entered in the web interface.

During the prototyping, html was helpful because it is easy to get a good sense of the static look and feel of the interface. Static links from page to page create a decent interaction flow that, though void of content, provides a helpful visual cues and guidance for implementation. The PHP scripts we created allowed us to take input data, store it, and display it where necessary.

On the other hand, the limited ability for html to deal with interaction and input data or data storage was incredibly frustrating and required us to implement PHP to accommodate html’s deficiencies. However, using PHP in this manner was not ideal, since no member of the group knew the language, and learning how to effectively write PHP scripts in a short amount of time was very difficult.

Design by Michael Wu