Assignment 5: First Interactive Prototype

Page Contents:

I.Revised Interface Design

Revised Scenarios

We revised our scenarios after our low-fi prototype testing. They are listed below:

Differences as a Result of the Lo-fi Interface Testing:

For a detailed discussion of the problems we found in our interface testing, please review the discussion from Assignment 4.

For the purposes of this first prototype, the interface changed in the following ways:

• We decided to implement a tabbed navigational structure in order to let users quickly switch between functions. This new structure is always visible from every screen.
• We changed our buy interface to allow users to contact multiple sellers simultaneously and thus facilitate bargaining. The concept of bargaining between multiple sellers did not emerge in our user assessment, either in our questionnaires or our interviews. We first encountered this idea when our paper-prototype subjects said that they would email several people to bargain for the best price. We implemented this need in our new interface by allowing the buyer to easily select more than one seller to contact, and the email message is sent simultaneously to all parties.(Screen D, Buy Book View)
• We have changed the name of the main functions to better reflect that the site is not an e-commerce site. We have reviewed and revised the explanatory text throughout the site. For example, we evaluated the subheadings in the "seller grid" to better explain its categories.
• We have used color to highlight functions that are particularly important. We have also used color schemes to denote which of the main functions a user is currently performing.
• We improved our titles.
• We added a logout and improved our login by letting users immediately login if they so desire.

Pages That We Planned But Didn't Implement

We did not implement the pages that the system administrator would use to add, modify, or delete book records in BESS. However, since these tasks are not part of our scenarios, we are confident that we can implement system admin pages at a later time.

We also did not implement the majority of the login and account pages. In order for these functions to be used in their normal way, they require cookie generation and database interactivity that we did not have time to complete. The login and account pages are the following:

Screen R: Logout
Screen T: Login confirm
Screen U: Change password
Screen V: Password confirm

Prototype Overview

Overview of the UI actually implemented

Using HTML, Dreamweaver, Cold Fusion, and Access, we built an interactive web prototype that allows testers to run through each of our three scenarios. Most of the pages are dynamic, allowing users to find books in different ways, see real book information as it is generated from the database, and navigate throughout the site. Some functionality, such as login and cookie generation, was not included in this prototype due to time and technical constraints. Our current list of screens follows:

A. Home - Initial page
B. Class View - Displays book list for a chosen class
C. Sell Book View - Displays form for user to sell a certain book
D. Buy Book View - Displays details of a certain book for sale
E. Sell Main - First screen in sell process (find book to sell)
F. Buy Main - First screen in buy process (lets user search for books in different ways)
G. Buy Form - User fills out form to buy a certain book
H. (Not used)
I. Buy Confirm - Confirms that user/system contacted seller about a book
J. Sell Confirm - Confirms that user posted a book onto BESS
K. Search Results - Shows a list of books that meet search criteria
L. Login - Asks for user login and password, or lets user link to new account form (O)
M. Edit/Delete Main - Lets user edit or delete the book listings they've posted on BESS
N. Edit Form - Lets user adjust existing posting
O. New Account Form - Lets user enter personal information to set up a BESS selling account
P. Confirm New Account - Confirms account set-up and tells user how to use account
Q. Help Desk - Text on how to use BESS, FAQs, etc.
S. Account Maintenance - Lets user change account preferences (not working yet)

What was left out and why

We decided to include the most SIMS courses of a masters student's first year: IS 202, 204, 206, 208, 213, and 214. We chose these courses because they are used in our three scenarios, the course content is familiar with all SIMS students, and they require a wide range of textbooks. Although our database has a table of all courses offered at SIMS, the required textbooks are not known for many of them, or the course may not have any required textbooks. In the future, we will implement our interface to display all courses offered at SIMS.

We left out all of the Administrative functions, Oliver Wang's pages. We made this decision because we wanted to concentrate on designing the interface that most users would see. Oliver is only one user-- albeit a central one-- but we wanted to keep the complexity of Yvonne and Sarah's goals foremost in our minds.

We did not implement the create account or login functions, although we have implemented the screens. For now, we will assume that the user is automatically logged in when he or she arrives at BESS.

Wizard of Oz techniques

The search results page is hard coded with the book titles that are used in our scenarios. The edit postings page is also hard coded. When the user decides to "edit" or "delete" a book posting, nothing really happens, but a hard coded screen tells the user that the modifications have taken effect. During the buy process, the table showing the books posted for sale is also hard-coded.

Tools we used

We used Dreamweaver to design our web pages, Microsoft Access for our database of books, authors, and courses, and Cold Fusion to link the web pages to the database.

Dreamweaver was useful in designing wireframes for our initial design. The graphical nature of the tool helped us concentrate on the placement of content instead of the nitty gritty coding aspects. On the other hand, Dreamweaver can be frustrating to experienced HTML writers. Oftentimes, a particular tag is not apparent on the tools palette, and we would have to edit the HTML code by hand to get what we want.

We decided to use Dreamweaver templates to create a consistent look throughout the site. Templates allow the designer to make a shell from which other pages are derived. One change in the template should propogate automatically to the derived pages. While this sounds wonderful in theory, we hit a lot of problems using templates. First, Dreamweaver forces all templates to be located in a folder called Templates in the file structure. However, when pages are created from templates, Dreamweaver defaults to relative links from within the Templates folder, even when the derived page is not saved in the Templates folder. For example, "sell_main.htm" is located in the root, but all image links begin with "Templates/.." This bug forced us to hand edit each page to remove erroneous links to the Templates folder.

There is also uncertainty as to whether Dreamweaver templates, upon automatically updating the web pages, overwrite Cold Fusion code. We got around this problem by creating backup copies of each htm file and copy-pasting, updating the templates, copy-pasting the Cold Fusion code back into the htm file, and then saving the file as cfm.

Microsoft Access served our database needs satisfactorily. We created several tables: books, authors, courses, required_books, users, and postings. We created the appropriate relationships between these tables.

Cold Fusion has been relatively easy to learn and very applicable for our needs. Some of us have experience with Perl scripts, and in comparision, Cold Fusion is delightfully intuitive to use. The problems we had with Cold Fusion were mostly file permissions, since the Cold Fusion directory is not within our 213 project space. Cfm files can only be edited by the owner of the folder. We solved this problem by having Susanne, the one with the Cold Fusion folder, login for all of us group members. For the next prototype, we plan to have Kevin set up a cold fusion folder for our group.

Screen Shots

Screens A-E

Screens F-J

Screens K-V

Prototype Instructions

To use our prototype, go to the BESS website. Use Netscape Navigator, not Internet Explorer. Go through the task scenarios. Note that the prototype has the following limitations:

Click on the tabs to move among tasks. Have fun!

Work Division

Jump back to these sections:

Revised Interface Design
Prototype Overview
Screen Shots
Prototype Instructions
Work Division