Functionality
and Interaction Flow
Unimplemented Design Changes
Tools
Functionality
and Interaction Flow
The functionality of the SIMians Course Comment
Forum has two main aspects:
- adding ratings and comments expressing a student’s
views of a particular course contained in the database.
- viewing the ratings and comments that other
students have added regarding a particular course.
There are two ways in which a student can add
ratings and comments to the SIMians Course Comment Forum: the "Noun-Verb"
method and the "Verb-Noun" method. The "Noun-Verb" method involves finding
the page that displays information about a specific course, and then
choosing to rate that course. The "Verb-Noun" method involves
choosing to rate a course, then selecting the specific course to be
commented on.
There are also two ways in which a user can find
the ratings and comments for a particular course: browsing and searching.
The navigation mechanisms associated with finding
courses and adding ratings, along with the page content displayed to
the user, are described below. The main parts of the interaction flow
are illustrated by a flowchart.
The system provides four browsing pages that list
all of the courses contained in the system, organized in four different
ways:
- by course number,
- by the main subject of the course,
- by the semester in which the course was taught,
- by the last name of the professor(s) who
taught the course.
Links to these pages are provided on the lefthand
toolbar that appears on every page in the system.
The user can also search for a course. A textbox
situated next to a "Submit" button appears on the upper righthand corner
of every web page in the system. In the final interface design, the
user is allowed to search over the course number, the course title,
the name of the professor(s) teaching a course, and the description
of the course that is provided by the system.
The names and numbers of the courses that match
the search term are displayed on a separate search
results page.
Course pages
The mechanisms described
above for browsing and searching bring the user to pages containing
a list of courses, where each item in the list is hyperlinked
to a page containing descriptive information about the course.
The content of the course page depends upon whether
the user is logged in to the system or not. If the user is not
logged in, the page displays only the course name and number, professor(s),
semester, and description of the course, followed by a form allowing
the user to login. If the user is logged
in, this page displays the following additional information:
- average values for ratings that students
have previously assigned to this course,
- a list of courses highly recommended (i.e.,
that received high ratings) by students who recommended this course,
- the total number of ratings/comments that
have been added for this course,
- a complete listing of the individual ratings
and comments that students have added to this particular course,
- two links (one towards the top of the page
and one following the individual comments/ratings) to a page on which
the user can enter the user's own comments and/or ratings for the
course.
Selecting a course
to rate
As noted above,
when viewing a course description, the user is given the option to add
the user's own comment or ratings. This is the "Noun-Verb"
method.
The "Verb-Noun"
method of adding a comment or rating to the course involves selecting
the "Rate a course…" link that appears on the lefthand side toolbar.
If the user has not logged into the system when the user selects this
link, the user is taken to a page prompting the user to login.
If the user is already logged in or when the user has logged in, the
user is taken to a page featuring a pull-down menu that lists all of
the courses in the database. When the user selects the course the user
wishes to rate from the menu, the user is taken to the add a comment
page.
The add a comment page provides a form for the
user to assign ratings and enter a free-text comment regarding the course
that has been chosen. The ratings are comprised of four different criteria:
- the overall quality of the course
- the quality of the professor(s) teaching the
course
- the difficulty of the course
- the average workload for the course.
For the first three criteria, the user is asked to
choose a rating on a scale from 1 to 5. The default value is "No rating".
For the workload rating, the user can use a pull-down menu to choose a
range of hours representing the average amount of time the user devoted
to the class per week during the semester. Below the ratings is a text
box in which the user can provide a free-text comment.
Below the textbox on this page are a series of
four buttons. The "Submit" button will automatically add the user’s
ratings/comment to the appropriate course page and, once selected, will
also take the user to this course page displaying the newly added ratings/comment. There
is also a "Preview" option, described below. The "Cancel"
button erases the ratings/comment the user has provided and takes him
back to the course page for this course. The "Reset" button erases
all of the information the user has added to the form but stays on this
page.
It is not mandatory for the user to fill in all
of the rating criteria and the comment text box. In order to add the
ratings/comments, the user must choose a value for at least one of the
rating criteria or enter a comment in the textbox. If all of the rating/comment
fields are blank, the system will prompt the user to enter some information
or to cancel the interaction.
The "Preview" button enables the user to preview
how the ratings/comment will appear after it has been added to the appropriate
course page. When the user is taken to the preview page, the user is
given the option of submitting, editing, or cancelling the comment.
If the user chooses the "Edit" button, the user is taken back to the
add a comment page where the user can edit the information the user
has provided on the form.
Login options
Several navigation paths are provided to allow
the user to login. The lefthand toolbar displayed on every web page
in the system contains a "Login" link.
In addition, if the user is not logged in, the user is prompted
to login when the user selects the "Rate a course" function.
Similarly, when a non-logged in user views a course description page,
the user is provided with a reminder that ratings and comments can be
viewed by logging in, followed by the login
form.
Miscellaneous
A "Help/FAQ" link
is provided on the lefthand toolbar. In addition, links
to the Course Comment Forum homepage, the SIMS homepage, and the SIMians
homepage appear on the upper left hand corner of every page. Finally,
if the user is logged on to the system, a "Logout"
link appears on the lefthand corner of every page. As the name suggests,
this link will log the user out of the system and take the user back
to the homepage.
Unimplemented
Design Changes
We have made many changes
to our prototype in response to our usability tests. However, we have
not been able to make all of the changes we would like. Before making
the SIMians Course Comment Forum a reality, the following changes should
be made:
- Add edit/delete
comment functionality. User comments on the system suggested the usefulness
of a function that allows users to edit or delete their own comments.
After being edited, the comment should indicate that the entry has
been edited, perhaps by showing the date of modification.
- Implement the
registration function, including user preferences such as whether
their email address should be shown. In the current prototype, registration
is a completely off-line system administration function. We envision
that the actual registration may require off-line verification (for
instance, to confirm that the person requesting an account is a SIMS
student); however, the site could have a form to submit a request
for an account.
- Improve the
search mechanism. We have enhanced the search mechanism to address
the specific issue observed during testing, which is that course numbers
can be entered with several different formats (such as IS250, IS 250,
or SIMS250). This was addressed by adding logic to extract a numeric
value from the search string and check that value against the course
number field in the database. However,
there are still other logical searches that will not return results.
We do not want users to think that their search retrieved no results
because there is no course when in fact their search query was entered
in a slightly different format than the database entry.
- Improve categories.
We have organized the SIMS courses into categories based on the categories
used in the career section of the SIMS website. These categories should
be improved so that users can find the courses they are looking for.
Ideally, this should be consistent across all SIMS-related web sites.
- Complete implementation
of the multi-year features. The current prototype contains only data
for the most recent year when each course was taught, and does not
include the envisioned commands for paging through multiple years,
although the database is structured to support multiple years.
- Expand the database
to include all courses. The current prototype does not include the
seminar courses (290 series).
- Add graphical
display of rating distributions. This would be in addition to the
average rating that is now displayed. It would give users another
piece of information that they might find useful. For example, two
courses with average ratings of 3 could have very different distributions:
one might have two factions - those who loved the course and those
who hated the course - while the other could be rated 3 by everyone.
Tools
We used a number of
different tools during the design process. Each design iteration expanded
our set of tools.
Design
We began the design
process using pencils and paper. This was a good choice for the initial
design phase because we were brainstorming. We were able to capture
several very different layout and navigation ideas, rather than focusing
on only one possible design at this early phase. Since we were focused
on quickly sketching ideas rather than creating polished and detailed
designs, pencils and paper were perfect tools to work with. We could
jot down ideas quickly that might have taken much longer to capture
using a computer program.
We also used Visio
and Jesse James Garrett's visual design language to design the flow
of the site. Although pencils and paper were good for sketching the
page designs, we found the computer more useful for capturing the flow
of the site. It was easier to modify the interactive flow once it was
on the computer than if it were on paper. Jesse James Garrett's visual
design language was especially useful because it gave us a fixed "vocabulary"
to work with.
Paper Prototype
For the paper prototype,
we used paper, pencils, and printed documents. At this point, we had
chosen a basic design that we could put down on paper. Making the paper
prototype only took a few , whereas a computerized prototype would have
taken many days. In addition, the paper prototype was better than a
computer prototype for the initial round of testing because we were
able to make changes on the fly during the testing sessions. Although
we had worked out the interaction flow of the site, there were unanticipated
glitches. With the paper prototype, were able to use "Wizard of Oz"
techniques to make sure that the testing continued uninterrupted.
The only computerization
we used at this stage was printing out a few of the pages mocked up
in MSWord. Printing out fake pages was much easier than prototyping
them in the computer because we did not have to make them functional.
Overall, using paper
for the first prototype worked well. There were a couple times during
the tests when the user did not recognize parts of the site that we
believe they would have if it had been computerized. However, the short
amount of time spent building the prototype and the many changes we
made after testing it far outweighed those problems.
1st Interactive
Prototype
For the first interactive
prototype, we designed HTML pages using Dreamweaver, supplemented with
Perl/CGI scripts created in a text editor. Even at this point, we expected
to use Cold Fusion to build our final design. However, we decided not
to use Cold Fusion at this point in the design process for essentially
the same reasons that we did not automate the first paper prototype:
we believed that it would be too time-consuming, and that we should
keep our focus on the design rather than on learning a new tool.
Although this prototype
was interactive, it was not fully functional. Dreamweaver allowed us
to prototype the page layout, but most of the information contained
on the pages was static. The Perl/CGI scripts modeled the basic
interaction flow of the site, although the essential element of saving
a user's comment was not included. We found Dreamweaver adequate for
the page layout tasks, but not very helpful for coding functional CGI
forms.
2nd Interactive
Prototype
We used Dreamweaver
with the addition of ColdFusion and an Access database to design our
second interactive prototype. Whereas our first interactive prototype
consisted of over 60 different static pages, our second interactive
prototype consisted of about 10 dynamically built pages. ColdFusion
allowed us to pull information from the database to display in "template"
pages. For instance, instead of creating 20 different course description
pages for 20 different courses, we designed a single page that could
show information from all 20 courses, depending on the variables passed
to the database.
ColdFusion fit our
needs perfectly. Dreamweaver, however, did not work well with ColdFusion.
It was difficult to make any changes to the templates without rewriting
the HTML ourselves. In essence, we used Dreamweaver as a text editor
at this point. We hope that with the purchase of Allaire (the maker
of Cold Fusion) by Macromedia (the maker of Dreamweaver), these two
programs will become more cooperative in the future.
After learning ColdFusion
for the purposes of designing this prototype, we decided that we should
have used the language for our first interactive prototype. It is not
that difficult to learn and very useful.
Conclusions
We found the pencil
sketches, the paper prototype, and Cold Fusion the most useful tools. Dreamweaver
was extremely useful for designing page layout, and it is definitely
helpful to have a tool that provides a WYSIWIG view of the HTML code.
However, Dreamweaver's strength seems to be in designing static pages,
and a better tool for designing dynamic pages is needed.
