Assignment #5: First Interactive Prototype

April 1, 2004

Revised Interface Design

Scenarios

Our scenarios are the same as the ones used in Assignment 4.

Differences as a Result of Lo-Fi Testing

We made several key changes to our interface as a result of the testing of our lo-fi prototype:

  1. Completely changed the navigation

    In our lo-fi prototype, our top level navigation consisted of: "Event Manager," "Calendar," "Search Campus Events," "Subscriptions," "My Profile," and "Event Archive." The users we tested found it difficult to locate certain functions, such as "Format Calendar" and "Search Campus Events." Additionally, some of them tried to find "Format Calendar" within "Account Settings." Here is a screen shot showing our old top-level navigation:


    As a result, we decided to change to a multi-level navigation system. This allowed us to group all actions related to events under the top-level "Events" section of the website. The sub-menus under events now include: "Add Event," "Search," "Subscribe," and "Export." We added two other top-level navigation elements along with "Events": "Calendar" and "Format Calendar." We believe that moving "Format Calendar" to a top-level link instead of a link on the "Calendar" page will help users find this section more easily. We also moved "Account Settings" to the right in a physically separated section from the main navigation along with two new links: "Help" and "Logout." We modeled this new navigation on the navigation on the Amazon website. Here is a screenshot showing our new navigation:



  2. Used tabs to separate long pages

    In our lo-fi prototype we had very lengthy "Pending & Posted Events" and "Format Calendar" pages. Here are screen shots of these pages:


    During our testing, we found that users were overwhelmed by the many options in "Format Calendar" and realized that users would most likely never need to see both "Pending" and "Posted" Events at the same time. We decided to create tabs to separate the sections of these pages to make them shorter and make it easier for users to find the part of the page they are looking for. This change gave us the added benefit of creating more space on a page, allowing us to group a semantically related item, "Archived" Events, with the "Pending" and "Posted" Events. We are still deciding whether it would make sense to make a similar change to the "Add Event" form. Here are screen shots of the new pages:



  3. Added a "Quick Search"

    In our lo-fi prototype we gave users a box from which they could choose from several different search criteria to find an event. Users described this interface as "too clicky" and said that they just wanted an easy way to type in a search term without having to select what type of search they wanted to do. Here is a screenshot of the different choices users had in the old interface:


    We redesigned the search interface to default to a keyword search, giving users the option to change it to a specific search field in a drop-down or select advanced search if they wanted to see all of the options available to them at once. Here is a screenshot of the revised interface:



  4. Reduced number of confirmation screens

    As mentioned in the previous section, several of our users described our interface as "too clicky," and one of the reasons cited for this was the abundance of confirmation screens. We decided that we will only use confirmation screens for actions taken on events that have been multiple-selected, and events that are added to the repository through the "Add Event" form. When a single event is changed or moved from "Pending" to "Posted" for a particular calendar, we will simply put a message at the top of the "Event Manager" screen stating that a change has been made. Here is a screen shot of an example:



  5. No longer allow shared events to be deleted

    During our user testing of the low-fi prototype, we realized that it was difficult for users to determine the implications of "deleting" an event from the "Pending" vs. "Posted" events sections. They wondered whether that meant that the event completely left the repository, and whether that would cause problems if it was a shared event on another user's calendar. We decided that it would not be fair to other users of the repository if we allowed event owners to delete events that had been shared with other calendars. Thus, we will allow event deletions from a user's "Pending" events, as that is simply a deletion from their person work queue. However a user will only be able to cancel events that have been designated as "Public" (meaning it can be shared with other calendars) and "Posted." We are determining how best to inform calendars who have posted a shared "Public" event on their calendar of cancellations; it will probably involve using e-mail.

[Top]

Prototype Overview

You may view an interactive, though not fully-functional, version of our prototype here. This is a different version of the prototype than the one used in the scenarios, and is also not linked to a database. You may also link from the name of each section below to the screen it represents within this interactive prototype.

Our prototype is divided into the following main sections:

  1. Event Manager

    This default page of this section is divided into three tabs: "Pending" Events, "Posted" Events, and "Archived" Events (which has not yet been implemented). "Pending" Events are basically events in a work queue which are waiting for approval to be posted onto the user's calendar. These events may have been submitted via the on-line public "Add Event" form, the "Add Event" form within this application, subscriptions set up by the user, or recommendations from other calendar owners. "Posted" Events are simply events that are live on the user's calendar, and "Archived" Events are events that were at one time live events, but have passed and are no longer posted on the user's calendar.

  2. Event Manager subsections

    • Add Event: This section allows users to add an event to the repository or save it as a draft, and may consist of the following sections: Title & Type, Date & Time, Location, Description, Public Event Contact, Event Participants, Event Sponsors, Intended Audiences, Admission Information, and Supplemental Information. However, users may customize the fields they see in the Account Manager. This screen currently displays two Location fields, but in the final implementation it will only have one, depending on which radio button, "On Campus" or "Off Campus," is selected.
    • Search: This section allows users to enter search criteria in order to find public events in the repository.
    • Subscribe: This page allows users to review their current subscriptions, as well as add new ones. Subscriptions are searches that put events into a user's "Pending" events queue, or are posted directly to their calendar depending on the options selected.
    • Export: This section allows a user to export a selection of events to a spreadsheet or comma-delimited file. It has not yet been implemented.

  3. Calendar

    This section allows a user to view their calendar. In future versions of the system, we hope it will also be used to allow users to edit and delete posted events. It has not yet been implemented

  4. Format Calendar

    This section allows the user to customize the display of their calendar. Each section has an interactive calendar display that previews the changes users make. It consists of the following sections:

    • Layout: This section allows users to determine whether any navigational links they add to the calendar are displayed horizontally or vertically.
    • General Styles: This section allows users to select the background color and link style of their calendar, as well as determine how far in advance to display their calendar's events.
    • Header: This section allows a user to create a header, by either filling out some provided options, uploading a graphic banner, or entering html code.
    • Navigation: This section allows the user to add their own navigational links to the calendar, either by entering links into the spaces provided or entering html code.
    • Event Description: This section allows users to change the colors and styles of the headings of their event descriptions, as well as create an abbreviated event description and choose which fields to display.
    • Footer: This section allows the user to create a footer, either by entering links into the spaces provided or entering html code.
    • Advanced: This section is not yet implemented, but will allow users to upload a Cascading Style Sheet to style their calendar.

  5. Account Info

    This section will allow users to set up security and additional users on the account, as well as set other configuration settings that have yet to be determined. This may include the method by which calendar owners choose to be notified of changes to events on their calendar. It is not yet implemented.

Tools Used

We created this prototype entirely out of html and css, using editors such as Dreamweaver. We plan to add a database and implement our next prototype using php. We felt it was important to begin creating the code that will be used in the final version of our prototype, and because we used html, we will easily be able to add php code to the pages that we have created. Additionally, in the lo-fi prototype when users had difficulty finding buttons or features, we were not sure if it was due to our formatting or the limitations of the medium. We wanted this prototype to resemble the final design as much as possible so that we could readily determine whether or not users would be able to locate all the parts of the application.

[Top]

Interface & Scenario Instructions & Storyboards of the Scenarios

Because our interface currently consists of only of html pages and is not yet connected to a database, you must closely follow each task when running through the scenarios. Only the functionality described in our task scenarios, and not the functionality suggested by the UI, is available. Start each scenario from the [Start Here] link, and navigate through the interface while completing each task. You may also use the link at the end of each scenario to link to the first screen of the next one. If you get lost, you may also click on any task within the scenario description below to see the corresponding interface screen. Thus, this section also serves as storyboards of the scenarios.

Scenario #1: Post, Edit, & Delete Events

You are the calendar administrator for the Mechanical Engineering department. You have been using the calendar system for a few months, and subscribe to events from many different calendars. You have chosen to manually approve all events that you subscribe to before posting them to your calendar. Today you are logging in to review new events that came in over the weekend.

[Start Here]
  1. Log in
  2. Review your pending events
  3. Post all EECS events to your calendar (3 events). You are familiar with EECS events and don't feel it necessary to review each one in detail.
  4. You are not sure whether you want to include the Bio Engineering "Guidant Information Meeting" and so decide to review it more closely.
  5. You decide that you don't want to post it on your calendar and want to remove it from your pending events list.
  6. You received an email asking you to change the time for the "ME Grad Visiting Day" on 3/14/04 to 2-4pm. This event has already been posted to your calendar. Find it and make the time change.

Scenario #2: Add Event & Administer Calendar

You are the calendar administrator for the Mechanical Engineering department and need to add a new event to your calendar and change the background color of your calendar.

[Start Here]
  1. Login
  2. Add the following event:
    Date: 3/25/04
    Time: 1-2pm
    Title: How Smart Helmets Save Lives
    Event Type: Lecture
    Location: Etcheverry Hall
  3. Post it to your calendar immediately
  4. Find and review the event you just posted
  5. Change the background color of your calendar to blue

Scenario #3: Find Campus Event & Set Up Subscription

You are the calendar administrator for the Biology department and have been using the system for a few weeks, but so far only for your department's own events. Today you want to start adding some other campus events to your calendar.

[Start Here]
  1. Login
  2. Find the following campus event: Environmental Science, 3/8/04, 4:00pm: "The Conquest of Bread: 150 years of CA Agribusiness"
  3. Post it to your calendar
  4. Set up a subscription to receive all seminars sponsored by the Civil & Environmental Engineering and Environmental Science departments that contain the word "environment" in the description. You want to manually approve all events before they post. You want to receive events that occur 2 weeks ahead or less. Name this subscription CivEngEnvSciSeminars.
[Top]