DUSC: Dynamically Updating Service Calendar Final Report

bubblesvoltaireInternet και Εφαρμογές Web

10 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

82 εμφανίσεις

- 1 -


DUSC: Dynamically Updating Service Calendar
Final Report


Michael Dotterer (mdotter1@wam.umd.edu)
Michael Reilly (mjreilly@wam.umd.edu)
November 8, 2005
- 2 -
Abstract

The design and development of the Dynamically Updating Service Calendar (DUSC) is
discussed. This product is intended for use by the Epsilon Mu Chapter of Alpha Phi
Omega National Service Fraternity at the University of Maryland, College Park. Design
decisions were made to be consistent with the eight golden rules of interface design, as
proscribed by Shneiderman and Plaisant. Flash and MySQL were chosen as development
platforms for the user interface and back-end database, respectively, though alternatives
such as Asynchronous Java and XML (Ajax) and PHP are also considered. Informal
surveys of Brothers of the Epsilon Mu Chapter were conducted to determine early
usability considerations, and a full usability test was conducted later. Changes were
made to the DUSC system in response to these suggestions and observations. While the
product is still approaching completion, chapters from Massachusetts have expressed
interest in using the DUSC system themselves once it is finalized.
- 3 -
Credits

Michael Dotterer
• User needs assessment (concrete
task examples; system
requirements)
• Low-fidelity prototype 2 (design;
description; walkthrough)
• Usability test design (pretest and
posttest questionnaires)
• Back-end MySQL database
development
Michael Reilly
• DUSC Product Proposal
• User needs assessment
(introduction)
• Low-fidelity prototype 1 (design;
description; walkthrough)
• Usability test design (users and task
list)
• Conducted formal usability test
• DUSC: Dynamically Updating
Service Calendar Final Report
(except the Low-fidelity prototype
2 description, which was drafted by
Michael Dotterer)

Michael Dotterer and Michael Reilly (equal contributions)
• References
• Informal usability test survey
• Front-end Flash development
- 4 -
Table of Contents

Abstract 2
Credits 3
Introduction 5
Design Process 7
Requirements of the back-end 7
Requirements of the front-end 8
Initial design 10
Design decisions 11
Development Process 16
Prototype 1 16
Prototype 2 21
Incorporating the prototypes into the final design 26
Proposed formal usability testing 26
Informal usability testing 30
Formal usability testing 31
Conclusions 32
Acknowledgements 33
References 34
- 5 -
Introduction

Alpha Phi Omega National Service Fraternity is the largest undergraduate
intercollegiate organization in the United States of America. This organization has been
gathering undergraduate students and its alumni to organize and promote service to the
Fraternity, its campuses, its communities, and the nation for 80 years. It is currently
represented by active chapters at over 350 institutions of higher learning. Most of these
chapters maintain websites that help them serve information about the Fraternity to
interested parties, including those interested in joining – or “rushing” – the Fraternity and
those interested in community service opportunities in the area. While these resources
are valuable, these chapters do not have a standard way of disseminating information
about upcoming events and keeping track of which members participate in these
activities. (Alpha Phi Omega National Service Fraternity, 2002)
The University of Maryland, College Park chapter of Alpha Phi Omega, called the
Epsilon Mu Chapter, expressed interest in the use of a dynamically updating calendar to
serve information about upcoming service events and keep track of which active
members participate in these events. This information would help them to track the
efforts of active members and give information to non-members about upcoming service
events. To this end, the idea to create a Dynamically Updating Service Calendar (DUSC)
was born.
The use of the World Wide Web to serve information from a database has been
explored through various different technologies, ranging from the original native
language of the web – namely, Hypertext Markup Language (HTML) – to cutting edge,
more powerful technologies such as ColdFusion Markup Language (CFML) and PHP:
Hypertext Preprocessor (PHP). Choosing the proper language(s) for a modern
implementation of a web-based application requires a review of modern methods for
creating such an application.
The original method of displaying information on the web involved a simple
document formatted according to the World Wide Web Consortium’s (W3C)
specification of HTML. These documents are purely static and allow for primitive data
entry. The documents are stored on a server and sent to a personal computer, or “client,”
only after the client sends a request to the server for that specific document. The nature
of client-server communication includes built-in delays between a client’s request and the
server’s response. Over time, the addition of interpreters for JavaScript and other
scripting languages to web browser capabilities expanded the capabilities of HTML to
introduce Dynamic HTML (DHTML). DHTML allows for information to change based
on some information shared by the client and server. Time delays still existed, however.
Several technologies and schemes have been developed to decrease or eliminate the time
delays. Of particular interest are Macromedia’s Flash technology and the Asynchronous
JavaScript and XML (Ajax) model – a term coined by Adaptive Path Firm. (Garrett,
2005; Singel, 2005)
Flash technology allows designers to create a compact and complete application
that can be opened in the most popular web browsers as part of a web page. The
application can communicate back to the server, but eliminates delays while waiting for
server response by being downloaded once to the client at the beginning of the session.
The Ajax model results in similar functionality, but instead uses a complete engine that is
- 6 -
downloaded by the client at the beginning of the session. The engine, which uses
JavaScript and Extensible Markup Language (XML) technologies, can generate data for
display in web browsers while simultaneously communicating with the server. Both of
these methods suffer from their own support issues, particularly in web-enabled devices
other than personal computers, but are well-supported in the most popular web browsers
for personal computers. (Garrett, 2005; Singel, 2005)
Also of interest with regards to a web-based system that can behave differently
for different users is the issue of access control. For a dynamically updating calendar,
some, but not all, users must be allowed to add events to the calendar, and perhaps some,
but not all, users should be allowed to register for an event. Different users can be said to
have a different “role.” Different solutions to this problem have appeared on the web,
ranging from simple authentication based on a password to Role-Based Access Control
(RBAC) technologies. RBAC technologies offer large-scale, enterprise level access
control, and are most appropriate for applications that expect a large number of users
with many different access roles, but these technologies often involve the use of extra
packets of information called “Cookies” that are stored on the client machine. Simple
authentication is tied to individual user identities and can be used on low-traffic
authentication systems with the use of passwords, encryption algorithms, and a database
to track each user’s permissions. In any case, the goal is to authenticate a particular user
and ensure that that user is allowed access only to specific resources. (Park and Sandhu,
2001)
As with any user interface, certain design principles should be followed to assist
in the choices of color scheme, object and data organization, clarity of data and error
messages, etc. The following list of general principles was provided by Shneiderman and
Plaisant in Designing the User Interface as the “eight golden rules of interface design:”
1. Strive for consistency
2. Cater to universal usability
3. Offer informative feedback
4. Design dialogs to yield closure
5. Prevent errors
6. Permit easy reversal of actions
7. Support internal locus of control
8. Reduce short-term memory load
Shneiderman and Plaisant purport that these principles should be tuned for each specific
design, but are generally “applicable in most interactive systems” (Shneiderman and
Plaisant, 2005, p.74).
Finally, previous work in the area of calendar interfaces should be examined.
While searches on ACM’s Portal for research in the area of calendar interfaces found no
relevant academic papers, many such interfaces have been developed. Airlines use
different forms for input of dates, and modern web application design has led to the
popular choice of a monthly 2-dimensional calendar that saves space over a list of
calendar dates and allows for quick intuitive use as the 2-dimensional calendars resemble
common wall calendars. Design choices within 2-dimensional calendars include how to
highlight a specific date, choosing a default date to highlight, how to allow users to scroll
forward and backward through months, how many months to show at a time, and what
data should be shown on the calendar itself. Scheduling applications also use calendar-
- 7 -
based interfaces, which are sometimes designed to allow for hourly or even finer-grained
scheduling. Such applications can be found on integrated devices such as cell phones or
Personal Data Assistants (PDAs), web-based applications, or desktop-based applications.
These applications generally display fine-grained intervals as a list like a traditional day-
timer, and monthly intervals in the form of 2-dimensional calendars. Each of these
popular interface types takes advantage of common physical scheduling interfaces to
achieve an intuitive design.
A search of Macromedia’s Flash Exchange library reveals 10 calendar-related
interfaces that have been pre-programmed for use by Flash developers. Eight of these
interfaces can be downloaded for free. One of these interfaces is designed specifically
for use on a desktop, not on the web, and another is designed to show a full calendar year
on one screen. Three of the interfaces, however, are 2-dimensional monthly calendars or
are designed to facilitate the creation of a 2-dimensional monthly calendar with the
ability to tie an action to a mouse click on a particular day of the month. (Macromedia,
2005)


Design Process

The Dynamically Updating Service Calendar (DUSC) requires two major
components: a back-end implementation to handle all of the data that is presented by the
calendar and a front-end interface for end users. In order to facilitate a flexible design,
the DUSC Team chose to separate the two components as much as possible. Thus, most
design decisions were split into the back-end domain and the front-end domain. Before
choosing which technologies to use for each of these components, the desired
requirements of the back-end and front-end were determined.


Requirements of the back-end

The DUSC back-end must support some sort of database for a listing of events
occurring throughout one academic semester. Support for more than one academic
semester in the past could be useful for the purpose of keeping records, but is not
necessary. The database could either be a collection of delimited text files to be parsed
by the back-end application or could be more deeply supported by a Structured Query
Language (SQL) database application which would allow for easier searches within the
database. Either way, this back-end application should be able to communicate with the
front-end.
Finally, the back-end must be somehow protected from any user logging in and
making changes to it. Only certain users should be allowed access to the database back-
end after a front-end authentication.


- 8 -
Requirements of the front-end

The DUSC front-end consists of the actual user interface of DUSC, which should
include features as specified by Epsilon Mu Chapter while conforming as much as
possible to the eight golden rules of interface design. First, however, it should be noted
that the front-end must be able to communicate with the back-end in order to send,
receive, and display calendar information from the database.
The front-end must be presentable on the World Wide Web as a web-site. Four
different audiences should be targeted by the website, specifically: 1) active members of
the Fraternity who will need to be able to logon to the calendar and be given the right to
register for events and track their contributions to date, 2) privileged officers of the
Fraternity who will be given the ability to add events to the calendar in addition to the
rights of all active members, 3) non-members who are interested in joining Alpha Phi
Omega, and 4) any other parties who would like information on upcoming service events
– which includes members of the community and alumni of Alpha Phi Omega. In order
to meet the requirements of each of these user groups, the front-end must include a home
page with general information about Alpha Phi Omega, a page with information about
how to rush Alpha Phi Omega, a page with further information about Alpha Phi Omega,
a page links to relevant community service organizations and opportunities, and of course
a link to the calendar itself. All of the data for the non-calendar pages will be supplied by
the Epsilon Mu Chapter, and is merely an extension of the DUSC product, but a potential
feature of the DUSC product is an interface for privileged users to dynamically update
the data on these pages so future updates will not require any knowledge of the language
used to code the interface.
With regards to the eight golden rules of interface design, the DUSC team must
“strive for consistency.” In order to keep the interface consistent, the website should use
a standard color scheme that is shown on all of the pages of the website. Also, the DUSC
product should feature a standard title bar and image at the top of each screen and a
standard menu system to facilitate navigation from any page to any page. The user login
prompt should appear in the same place on any page while a user is not authenticated. If
a user is authenticated, then links to privileged pages will replace the user login prompt,
but follow the same scheme set by the standard menu system. All of the buttons on forms
should be in the same format so that their functionality is clear, and the names of buttons
should concisely explain what they will do when clicked. The display should be logically
grouped in a visually appealing way so that users can easily and efficiently find what they
need to find.
In order to cater to universal usability, the expected users of the DUSC product
were considered. The most common expected users are active members and privileged
officers of the Fraternity. These users will have personal computers with graphically
enabled web browsers available to them by the University of Maryland. There is no
known demand for additional accessibility requirements or for the use of handheld or
integrated devices to view the DUSC product. Thus, the universal usability demanded by
DUSC is relatively low-level.
Informative feedback must be given for each user action. To facilitate this, error
dialogs, screens, or messages should be displayed whenever a user has attempted to
access a privileged page that he/she does not have access to and each page will have a
- 9 -
title that closely matches its name on the menu from which it was selected. When users
login, a page or message should appear to communicate that they are now logged in, and
some sort of indication should be given that the user is still logged in until the privileged
session is ended by logging out or closing the browser. Also, during intermediate steps
involving data entry, the user should be informed of exactly what data he/she has
changed or updated so that he/she can verify that the correct data was entered. If it has
not been entered correctly, a button will be available that allows the user to cancel the
transaction and another to allow the user to undo the change.
Dialogs should be designed to yield closure. In the DUSC product, the following
sequences of actions should be designed to give this closure: logging in, creating an event
on the calendar, and logging out; logging in and registering for an event, then logging
out; logging in and checking the user’s status with regards to hours of community service
completed, then logging out. In each case, the final logout will give complete closure,
but intermediate steps that involve some sort of exchange of data between the user and
the server should have its own closure. This closure will be achieved by keeping the
submission of data to the server to one page, and an informative heading when the server
responds informing the user that the action and/or data he/she requested was completed
and/or delivered.
Preventing errors will mostly involve checking any input given by the user for the
appropriate format. If one or more of these checks results in the detection of an
incorrectly formatted input datum, the user should be presented again with the form used
for data input and a message clearly expressing which data fields need to be corrected
and how data should be formatted for them. In order to prevent these errors from
occurring, the user should either be presented with the expected input format as part of
the input form itself, or should be able to click to a dialog explaining what is expected of
them. Wherever possible, input choices should be limited to only those choices that are
acceptable. As described above, also, the user will have an opportunity to verify data
before it is committed to the system, go back and make changes to it, or cancel the
transaction altogether.
Easy reversal of actions has already partially been discussed: users will have an
opportunity to confirm, change, or cancel data changes before they are committed to the
database. The only other non-trivial reversal of actions is cancelling an appointment to a
service event, which should be allowed in the same way that signing up for a project is
done: by clicking a button on the page that explains the project.
Support for an internal locus of control is mostly attained by the simple nature of
the interface: the user makes a request and the interface responds clearly. One design
addition that will help experienced users to quickly use the interface will be to carefully
control the “tab order” of input fields. The tab order is the order in which input fields are
given focus when the “Tab” key is pressed to switch between them. The tab order should
logically follow the left-to-right, top-to-bottom order of the fields as they appear on the
screen, thus making it an intuitive sequence. Other than pressing the “Enter” or “Return”
key to submit a form, no other keyboard shortcuts will be available, since the DUSC
product will be viewed in a web browser and the web browser will intercept keyboard
shortcuts and interpret them on its own.
- 10 -
Short-term memory load will also be minimized by keeping the interface simple
and by presenting users with an easy way to determine what types of input is expected
from them, as discussed above.


Initial design

Before the DUSC team made any decisions about which languages to use in the
development of the front and back ends, the team worked together to develop a transition
diagram showing the how the main screens would link together. The team then each
developed a series of screens showing how each team member visualized the DUSC
system. These low-fidelity prototypes will be discussed in the next sub-section, but here
the transition diagram and its design implications are discussed.


Figure 1. DUSC General Transition Diagram in the form of a flow chart

Examining the transition diagram (Figure 1), it can be seen that the homepage
node is connected to the most nodes. The homepage is directly connected to all of the
static pages – pages with general data such as the service links and rush information
pages. It is also connected to the calendar and the login function. The calendar further
leads to event detail pages for events present on the calendar, and a signup function so
that authenticated users can register for an event.
The login function will lead to a “Personal Home” page for the user which will
indicate that the user is logged in. If there is an error in the login, or if the user has
attempted to access a page without the appropriate privileges, an error message will
- 11 -
appear. From the personal home, an active member can view their attendance history and
a privileged officer can manage users and calendar events.
After exploring the design implications of this general transition diagram, the
DUSC team made several design decisions. First, placing the login function as part of
the standard menu on each page allows for easy authentication. Also, all pages can be
tied directly to the static pages through the standard menu system. Once users are logged
in, they are taken to their personal home, but can still access all of the other pages from
the standard menu without having to log out. They will also be given the option to
signup for an event from the “Event Detail” pages from buttons that are not visible to
unauthenticated users. Finally, an authenticated user will be given access to their
personal “View Attendance” page via a new button on the standard menu (or placed
directly on their personal home page), and if the user is a privileged officer they will also
be given access to “Manage Users” and “Create an Event” pages via new buttons on the
standard menu, depending on what type of privileges they have.


Design decisions

After deciding on the initial flow of the DUSC product, the DUSC team was
ready to make several important design decisions ranging from color scheme to
languages used to develop the front and back ends. Decisions made at this point also
included how to treat static vs. dynamic pages. Each of these design decisions are
addressed below:
• Color scheme: The choice of a color scheme was not difficult since this product is
geared towards Alpha Phi Omega whose colors are blue and gold. To improve
contrast and appeal, the DUSC team chose a blue background with yellow text.
The body of each page, however, was chosen to be white with black text to ease
readability.
• Title bar: The title bar was chosen to constantly display the name of the
organization and some brief descriptive information about it. Specifically, the
title bar reads: “Alpha Phi Omega National Service Fraternity, Epsilon Mu
Chapter, University of Maryland, College Park.” An accompanying image was
designed to incorporate the Alpha Phi Omega crest and the University of
Maryland mascot, and placed on the upper left corner of the title bar. This title
bar is visible on every page of the interface so the user always knows what
website he/she is viewing, and to promote consistency.
• Menu bar: The menu bar was chosen to work hand-in-hand with the title bar. The
menu bar was placed on the left-hand side of each page with links to the pages
outlined above. Each link button on the menu bar was designed to highlight itself
when the mouse is over it by changing text color from gold to yellow. This
simple feedback alerts the user that the highlighted button is active and will lead
to a new screen when clicked.


- 12 -

Figure 2. DUSC standard title bar, menu bar, and color scheme. The “Calendar” button has been
highlighted by the mouse, which was hovering over it when this screen shot was taken.

• Static pages: Due to time constraints (which will be discussed further in the next
section), it became infeasible to create dynamically updatable “static pages.” In
other words, the “Home,” “Rush,” “About ΑΦΩ,” and “Service Links” pages
were not given an interface for updating by privileged users. The text, links, and
images on these pages have to be updated by directly modifying the source. Each
static page would be given a heading below the title bar stating the name of the
page. This was deemed an acceptable omission since the primary goal of the
DUSC product is to create a dynamic calendar system, not a “wiki” or other
dynamically updatable reference.
• Calendar pages: To make efficient use of space and an intuitive visual design, the
2-dimensional monthly calendar discussed above was chosen. As such, each
calendar page shows a single month. The calendar pages are actually a single
dynamic page with the month that it is supposed to show as an input variable.
The choice of what date to show initially when a calendar application is opened is
based on the intended use of the calendar. In this case, the calendar is intended to
be used to view upcoming events, with the next upcoming event being the
chronologically first important event. Thus, the current month was chosen to be
displayed when the calendar is initially visited.
To allow the user to move forward or backward in time, “Next” and “Previous”
buttons were added to show the calendar for the previous and next months,
respectively. Also added was a form allowing the user to select a month from a
drop-down menu and input a year to go directly to that month. This is the first
input encountered in any design decisions. The choice of a month does not
require input validation since the month is chosen from a drop-down menu. The
year, however, requires some validation to make certain that the user has inputted
a valid year. The text entered in the year input box is limited to digits, so only
positive years can be entered. The user is allowed to view a calendar for any such
year, so the title of the calendar shows the month and year, giving the user an
indication of what they entered. The calendar automatically accounts for all leap
years by giving February 29 days whenever appropriate.
Finally, the calendar must display events. Each day of the month has a square on
the calendar, much like a traditional wall calendar. Each of these “day squares”
shows the events planned on that day. Each event is indicated by the time at
which it begins and the type of event it is: “SERV,” “FELO,” or “MTG,” for
- 13 -
“Service project,” “Fellowship event,” and “Meeting,” respectively. These
abbreviations are used because there is not enough room in the “day squares” to
fit the full names of all events. A legend always appears with the calendar to
indicate what these abbreviations mean. The actual name of the event will appear
when the user places the mouse over the event on the calendar. If too many
events exist on one day to fit in the “day square,” then this is indicated by “--
more --" after the last event – it should be noted that this is unlikely to occur since
more than two events on one day is rare for this organization. The number box in
the upper left of any “day square” that has one or more events in it is clickable,
allowing the user to go to a page with full names for each of that day’s events.
These titles can each be clicked on, taking the user to an “Event Details” page for
that event. The user can also reach the “Event Details” page by clicking directly
on it’s listing on the calendar. Finally, the “day squares,” while loading data from
the server, display a blue “Loading” message, which disappears once the data has
been retrieved from the server. If there is an error retrieving the data, the “day
square” shows a red error message indicating to the user that that particular square
failed to load data and that they should try reloading the page. Each monthly
calendar page has the month and year as a heading, clearly indicating which
month the user is viewing.


Figure 3. DUSC Calendar Page. Note the “Loading” label in the boxes that are still loading, and
the event scheduled for November 9
th
.
- 14 -
• Event detail pages: Like the calendar pages, these pages are actually just one
dynamic page showing all of the events for a specific day. This page is accessed
by clicking on one of the events on the calendar, or an event on a “Daily Details”
page. The full details for that event are displayed. If the user is logged in and the
event has not yet occurred, they also have an associated button to “Sign Up!” for
the event or a highlighted message indicating “You are signed up for this event,”
and a button in the same format as the “Sign Up!” button allowing the user to
“Cancel.” Finally, each “Event Details” page has a link back to the calendar for
the month in which the event took place.
• Daily detail pages: This dynamic page shows a list of the full times and names of
events on a particular day, and is accessed by clicking on the day number of one
of the “day squares.”
• Login process: The login process was simplified by allowing the user to login
from any page on the site by typing a valid “Username” and “Password” in the
login prompts at the bottom of the menu bar. Once the user is logged in, the login
prompts will be replaced by buttons for their “Personal Home” and to “Log Out.”
If the user is also a privileged officer, buttons to “Manage Users” and “Add an
Event” will also appear as appropriate. This makes it clear that the user is logged
in. If the username and password combination supplied do not authenticate, then
the user is informed of such with a highlighted error message stating that the
username/password combination did not authenticate. The user is not told which
of the two does not authenticate since this would decrease the security of the site.
In this case, the buttons for authenticated users are not added to the menu bar.
While the scale of this product is too small to necessitate a full RBAC system, a
modified role-based authentication was chosen using the principles of simple
authentication, since at least three different roles are to be supported by DUSC:
unauthenticated user, authenticated member, and authenticated privileged officer.
• Signup for an event: When an authenticated user signs up for an event (which can
only be done by clicking the appropriate button on the “Event Details” page), the
user is shown a highlighted message stating “You have registered for <event
name> at <time> on <date>. To cancel this registration, click here:” followed by
a button to “Cancel.” Another button appears allowing the user to “Return to
Event Details Page.” This allows for an easy reversal of the registration action.
• Attendance “page:” The attendance “page” will actually appear as part of each
user’s “Personal Home” and is a summary of attendance for the particular logged
in person. This page merely lists the events attended by the person along with the
number of hours served at each of those events, and the type of service to which
the event corresponds.
• Manage users page: The “Manage Users” page is available to privileged officers.
This page presents the privileged user with a list of users registered and the
following data: the user’s name, the user’s login id or “username,” phone number,
America Online Instant Messenger screen name, email address, a drop down
indicating their status (privileged officer or regular), a “View Attendance History”
button, and an “Update” button. Upon clicking the “View Attendance History”
button, the user is taken to the previous user’s attendance history page. Upon
committing a change, the user is prompted to “Accept,” or “Cancel” the changes.
- 15 -
No invalid input is allowed since the input is chosen from a drop down menu, or
is allowed to be any text. Also on this page, the user has an option to add a new
user with the same data as outlined above. When the data is changed, the user is
again given the choice to “Accept” or “Cancel” the changes.
• Create an event: The “Create an Event” page accepts the most complex input in
the DUSC system. The data required by this form include: project name, project
date, meeting time, meeting place, area of service, and brief description. The
project name, meeting place, and brief description will be text inputted by the user
and can contain any characters, but must not be empty and are checked for this
error. The project date must be a valid date in the future and can be entered by
selecting dates from drop down menus for month, day, and year or from a 2-
dimensional calendar with selectable dates. This is checked to verify that the
selected date is in fact in the future (years before this year are not available, but
the months and days in this year before today’s date are still available). The
meeting time can be entered by selecting from drop down menus for the hour and
minutes and clicking a radio button indicating either “AM” or “PM.” Finally, the
area of service is selected by clicking one or more checkboxes with the options
“Fraternity,” “Campus,” “Community,” or “Nation.” All fields are checked
against being empty when the “Submit” button is clicked. If any fields are empty,
they area highlighted by an error message saying “This field cannot be left empty.
Please [enter|select] data for it and click Submit again.” Once there are no empty
fields and “Submit” is clicked, the user is shown a summary page of the
information they have entered and is allowed to “Accept,” “Edit,” or “Cancel.”
Clicking “Accept” gives the user a message that the event has been added. “Edit”
returns the user to the form with the data they initially entered in the form.
“Cancel” returns the user to a blank “Create an Event” page with a message
“Event was not added” at the top. There is also a “Cancel” button on the “Create
an Event” page which will return the user to their “Personal Home” page.
• Error handling: Error handling, as discussed in each specific case, is consistent
throughout the product. Through the choice of the front-end development
language (discussed below) the DUSC team was able to eliminate the possibility
of someone attempting to access a page what they are not allowed to access, so
the only type of error to handle is invalid input. Any input field that has a
possibility of invalid input is handled by giving the user a highlighted message
indicating the error and allowing them to immediately change the input. These
messages are highlighted in order to alert the user, but are designed to not be
threatening. All such messages are complete, concise, and informative,
sometimes in black font, sometimes in red font, and always inform the user what
needs to be done to correct the error.
• Built-in help: Through quick directions within each form, no help or tutorial is
necessary to help the users through the process. Every input block explains itself,
and the error messages also explain what needs to be changed.
• Back-end development language: The choice of a back-end development language
depended on the expertise of the DUSC team members, the resources available to
the Epsilon Mu Chapter’s server, and the time constraints imposed upon the
development period. The DUSC team members have some experience in PHP,
- 16 -
MySQL, and ColdFusion Markup Language. However, the experience in PHP
was too limited and would take too long to learn compared to the timetable of the
project. Also, the Epsilon Mu Chapter does not have access to a ColdFusion
server, which would be required for the use of ColdFusion Markup Language.
This left MySQL as the best choice for a back-end database development
language. The MySQL back-end and front-end could be easily linked through
Perl scripts, thus completing communication between the two.
• Front-end development language: With the backend chosen to be MySQL with
associated Perl scripts, the two main choices for the front end were an Ajax
implementation using JavaScript, Dynamic HTML, and Cascading Style Sheets to
facilitate consistency or a Flash implementation. Both options allow for a smooth
work experience and easy communication with the back-end. While the use of an
Ajax approach would work well and extend the usability of the product to some
devices that are not Flash enabled, the requirements of the Epsilon Mu Chapter do
not necessitate such an extension. Furthermore, the use of Flash enables the
DUSC team to not have to worry about users accessing pages they do not have
permissions for, and allow for error messages to appear instantly. Flash can also
help prevent hacker attacks, as communication with the server uses only the
relatively secure “POST” method, which is not easily infiltrated. Finally, Flash
more readily allows for the consistency required for the DUSC team through the
use of layers.


Development Process

The DUSC product was developed concurrently with the design process. For
example, preliminary design decisions were made first, such as the transition diagram.
Next, low-level visual prototypes were developed which in turn influenced future design
decisions, which facilitated the development of the final DUSC product. Therefore, this
section will be dedicated to the low-level visual prototypes and how they were influential
in the design process described above. Also, the issue of usability testing for the DUSC
product will be addressed.
Each member of the DUSC team developed his own low-level prototype. Both
are discussed in detail below.


Prototype 1

This prototype used a deep-tree organization for the DUSC product. In other
words, in some cases a user would need to pass through more than one page to get to
where they want to be. While it may work better for some websites to have a shallow,
broad tree organization with many or all links on the home page, the team was curious to
assess the reactions of users to a shallow organization. Since the website is not very
large, it was expected that it would not take much work to change an implementation
from deep to shallow.
- 17 -
This prototype was designed to use as much native HTML as possible for client
browsers to interpret so that all kinds of browsers present the site in a similar manner
(including mobile devices with browsers).
Five sample screens for Prototype 1 were created: a sample home page, a sample
event calendar for the month of October, a sample error page, a sample service project
creation page, and a sample service project report page.
The sample home page introduced the proposed standard template for the Epsilon
Mu website: links and login fields on the left and an event reminder for the next
scheduled event in the Service Calendar on the right (please note that other types of
events could also be included in the Service Calendar). It was designed to present a short
welcome message with any pertinent information in the body of the page.



Figure 4. DUSC Prototype 1 Home Page

The layout of the home page was identical to that of the proposed event details
pages (dynamically created), the rush info pages (statically created), about Alpha Phi
Omega page (statically created), and the service links page (statically created). The
layout was intended to convey information while not precluding the user from utilizing
the navigation bars to move around the website.
The navigation bar included links to the home page (statically created), the
calendar page (dynamically created), the rush info page, the about Alpha Phi Omega
- 18 -
page, and the service links page. Along with the login prompt (which is replaced by a
logout link when the user is in fact logged in), unprivileged users would be able to get to
all of the information the wish to see from here. Privileged users would see a personal
home page once they were logged in from which they could navigate to all of the
privileged features that they require, including service project and fellowship creation
pages and service project report pages.
The event calendar was presented for one month at a time. This design allowed
users to move ahead or back one month at a time by clicking on the appropriate arrows,
which was assumed to be reasonable considering that most projects and events are not
planned more than a few weeks in advance.


Figure 5. DUSC Prototype 1 Calendar Page

Each scheduled event would appear on the calendar with event name and meeting
time. These texts would be clickable, and clicking on the links would take the user to the
corresponding dynamically created page with full details for the event. For all events,
users would find the event name, event date, meeting time and place, address of the
event, and event description. Service projects would also include the area of service that
was being performed (fraternity, campus, community, or national), the number of hours
that the project would take place, and a list of Alpha Phi Omega members who are
registered for the project (for authenticated users only).
- 19 -
The error page created was the page that would be shown for anyone who
attempted to access a resource that required elevated privileges. A similar error page
(with different error message) would be shown to those who attempted to access a page
that did not exist.


Figure 6. DUSC Prototype 1 Error Page

Errors due to invalid user input on a form would be noted with an alerting
message at the top of the same page with the offending form identifying the field(s) that
had invalid input. All of the data in the offending form would be kept the same so that
the user did not have to retype any of it.
The service project creation page showed the first few form fields that would be
on the page. The full list of form fields included:
• Project Name: any text
• Project Date: entered manually or can be selected from a pop-up calendar system,
which would be available to users using a modern web browser on a personal
computer or laptop; this text would be validated
• Meeting Time: entered manually, though “AM” or “PM” are chosen by clicking a
radio button, making the selection mutually exclusive (you can only choose one);
this text would be validated
• Meeting Place: any text
- 20 -
• Brief Description: any text
• Area of Service: checkboxes used to select “Fraternity,” “Campus,”
“Community,” and/or “Nation;” checkboxes allowed for more than one selection
to be chosen at once
• Minimum number of people needed: any positive integer; this text will be
validated
• Project Chair: drop-down menu with the names of all of the brothers that are
eligible to be project chairs; the default value is “None”


Figure 7. DUSC Prototype 1 Service Project Creation Page

Other events can be created with a similar creation page. The fields “Area of
Service,” “Minimum number of people needed,” and “Project Chair” would not have
been included. Errors were handled as discussed for form errors above.
The service project report page was a fairly straightforward page where the user
entered hours into each of the fields for members who were present at the project in
question. The values were to be validated as positive integers, and errors handled as
discussed for form errors above.

- 21 -

Figure 8. DUSC Prototype 1 Service Project Report Page


Prototype 2

The second DUSC prototype was designed to use a much broader tree than the
first. It was designed to make getting to different pages require less clicks, and hopefully
less time. However, this may come at the risk of confusion and/or too much of a sense of
business.
This design took full advantage of the capabilities of the Ajax model to provide a
rich user interface. It was common throughout the prototype to see places where the user
would click, or otherwise interact, with one part of the display, which would lead them to
more information on a single page. However, this was usually not what was actually
going on. In most of these cases, DUSC actually requires communication with the server
to fetch the additional data. This was to be done completely in the background to make
the interface as smooth as possible.
The four screens presented for the second prototype were a sample main page, a
sample calendar for the month of October, a sample event detail for an arbitrary event,
and a sample interface for editing the members recognized by the website.
The sample main page consisted of two parts: the header and the body. The
header of the page served largely as navigational and was repeated across all full pages in
the site. The body was the unique content of the page.
- 22 -


Figure 9. DUSC Prototype 2 Home Page

The header consisted of the logo of the site and a navigational hot bar. The hot
bar featured links to some of the most used pages on the site, but did not allow the user
access to the entire site. The hot bar was designed to give navigational ease to the users
but preserve as much screen space for content as possible.
The body of the main page consisted of a series of links grouped into one of three
categories. The idea was that all of the large pages would have a link from this main
page, filed under at least one relevant category. More or less links could be added as
needed. Additionally, on this main page there was a large iconic link to the calendar.
This was to attract additional attention to the calendar as it is likely to be the feature used
most on the site. Other iconic links could be added as needed.
The sample calendar page presented the dynamic calendar layout. There were
only a sparse number of events displayed, however in the real application there would be
many more. There were two components to the calendar: a monthly calendar and a daily
schedule. They were presented side by side to allow the user to use both simultaneously
without switching back and forth.

- 23 -

Figure 10. DUSC Prototype 2 Calendar Page

Navigation of the calendar was accomplished by a few simple operations.
Changing the month viewed could be accomplished in two different ways. The first
method was to click the arrows on either side of the month label, which would move the
user forward or backward by one month, respectively. The second method was to select
the month and type the year that the user was interested in and click the “Go” button. To
change the date of the daily schedule, the user would click on the number of the day
he/she was interested in. If the user knew exactly which event they were interested in,
they could click directly on the event, which would open a separate popup window with
the event detail interface, which is described below. Additionally, the user could click on
the event in the daily schedule. This would also open up a separate popup window with
the event detail.
On the monthly calendar, only the time and type of event were listed. This was
because the space in each day square was limited. Even on a high resolution machine
there would only be a small space to display the information. The reason that the type
was listed was because it could consistently be abbreviated into an understandable
abbreviation. This could not be guaranteed of actual event names. A color coding
scheme could also be developed to further differentiate between the different types of
events.
On the daily schedule, more event detail was displayed. Here, not only the time and type
were displayed, but also the name of the event. Here, additional information could also
be displayed since it would be simple to add scrolling and allow for more textual area.
- 24 -
While the scrolling may have been necessary even for this version, the reason a
simplified version is used is because the event name should be enough information for
users to decide whether or not they are interested enough to investigate further.
The sample event detail was fairly straightforward. It was simply a display of
information about the event. It provided full event details and allowed the user to sign up
for the project by clicking a button at the bottom. The major difference about this
window is that it was a popup window. It was smaller and did not have the hot bar from
the full page template. This allowed the details to be viewed without interrupting the
view of the calendar.


Figure 11. DUSC Prototype 2 Event Detail Popup

The edit member interface was designed to allow users to easily update contact
information and status of all members recognized by the system. Similar to the calendar
interface, the screen was once again divided into two parts. One gave more general
information while the other presented more specific details.

- 25 -

Figure 12. DUSC Prototype 2 Edit Members Page

The drop down boxes above both portions was to filter the members being
viewed. There were several categories of members and for the most part the user would
probably only want to view one type at a time. However, there was a filter option for
“All” which would show all members entered into the system.
The main content box was a list of the members. If there were more members
than could be displayed in a single window, a scroll bar would appear to the right. When
scrolled, the column headers would remain in place. There were three actions the users
could choose from in this part of the interface. The first is to delete a user by clicking the
small red ‘x’ to the left of each name. Deletion would have been contingent on the
acceptance of the action by clicking “Yes” in a confirmation dialog box. The user could
cancel the deletion by clicking “No” in the confirmation dialog box. The second action
the user could have taken was to change the status of any of the members. This action
would instantly change the status, but the user would not be filtered out of the current
screen until the filtering is done again by either reloading the page, or changing the
selection in the “Limit to:” drop down menu. Finally, the user could have clicked on any
part of a row to bring up that member in the member editing box on the left of the screen.
The member editing box was a simple HTML form. It provided all of the values
associated with the user’s identity in editable text boxes along with apply and reset
buttons. Clicking the reset button would return the values in the editing box to their
stored values. The changes would not take affect until the apply button had been pressed.
- 26 -
Once the apply button was pressed, the changes would take effect immediately without
waiting for the page to reload. The member list would also be updated automatically.


Incorporating the prototypes into the final design

The two low-level prototypes discussed above gave the DUSC team many of the
ideas used in the final design of the DUSC product. The color scheme and title bar from
the second prototype were used while the navigational bar from the first prototype was
used. The differences in depth between the deep and shallow tree structures were so
minimal that there seemed to be no need to add an extensive number of links to the main
page. Also, many of the links proposed by the second prototype were unrelated to the
dynamically updating calendar itself, and were abandoned due to time constraints. The
information on the static pages was determined to be the responsibility of the Epsilon Mu
Chapter, not of the DUSC product itself.
Both prototypes allowed for slightly more useful transitioning between pages with
the use of constant navigational bars, which resulted in adding a few more state changes
to the transition diagram. Both prototypes used the Ajax approach to web design, but
since Flash was chosen as a more appropriate design method, several changes were made
to take advantage of Flash’s strengths, particularly in the area of error handling. Also,
some options in the event creation and member editing forms were eliminated as they
were deemed unnecessary by an informal usability test, which will be discussed below.
Finally, both prototypes specifically allowed for non-service events to be scheduled.
While the calendar in the final design allows for this option as well, the implementation
of the appropriate forms was deemed extra to the scope of the Dynamically Updating
Service Calendar and was left for future development, as discussed in the next section.
The design of the final high fidelity prototype, as discussed in the previous
section, puts more emphasis on the eight golden rules of interface design than did either
of the low-fidelity prototypes.


Proposed formal usability testing

While the DUSC team was entirely prepared to conduct a usability test of ten
sample users for the four user groups described in the introduction, time constraints
forced them to initially forego this formal testing. As a result, informal surveys of the
members of Epsilon Mu Chapter were conducted to determine which features would be
favorable, and modified formal testing was conducted later. Both will be explained
further in the next two subsections, respectively.
The proposed usability tests were to include several tasks associated with one or
more “personas.” These personas were to include 4 active members of Epsilon Mu
Chapter, 2 privileged officers of the Epsilon Mu Chapter, 2 people interested in finding
community service information from the University of Maryland Office of Community
Service Learning, 2 people interested in joining Epsilon Mu Chapter from the chapter’s
most recent pledge class, and 2 alumni from the Epsilon Mu Chapter. The following
general tasks were to be tested:
- 27 -
• Finding information for an interesting event, logging in, then signing up for it
o Active member of Epsilon Mu Chapter
o Privileged officer of Epsilon Mu Chapter
• Logging in then signing up for a specific event
o Active member of Epsilon Mu Chapter
o Privileged officer of Epsilon Mu Chapter
• Logging in and adding an event to the service calendar
o Active member of Epsilon Mu Chapter
o Privileged officer of Epsilon Mu Chapter
• Finding information about upcoming events
o Active member of Epsilon Mu Chapter
o Privileged officer of Epsilon Mu Chapter
o Alumnus of Epsilon Mu Chapter
o Non-member of Epsilon Mu Chapter interested in joining the fraternity
o Member of the community seeking community service resources
• Find contact information and send an email to the Chapter President
o Alumnus of Epsilon Mu Chapter
o Non-member of Epsilon Mu Chapter interested in joining the fraternity
o Member of the community seeking community service resources
• Enter service hour records after an event
o Active member of Epsilon Mu Chapter
o Privileged officer of Epsilon Mu Chapter

Each test subject was actually to be selected from each of the “personas,” and no
one was going to be asked to take on a false persona. Each subject was to be informed
that they were helping the DUSC team to test the DUSC interface and that their input
would be taken into consideration as the team continues to develop the interface.
The following are the step-by-step descriptions of the six tasks:
• Finding information for an interesting event, logging in, then signing up for it
1. Visit www.apo-em.org
2. Navigate to the web site’s calendar
3. Find an upcoming event that looks interesting to you and view it’s details
4. Login to the system and sign up for that event
5. Logout of the system
• Logging in then signing up for a specific event
1. Visit www.apo-em.org
2. Login to the system
3. Sign up for the next University of Maryland Football Game Concessions
event
4. Logout of the system
• Logging in and adding an event to the service calendar
1. Visit www.apo-em.org
2. Login to the system
3. Add the following service project to the service calendar:
a. Project Name: Happy Helpers
b. Date: December 20
th
, 2005
- 28 -
c. Meeting Time: 3:30pm
d. Meeting Place: Hoff Entrance to the Stamp Student Union
e. Description: We will be happily helping people!
f. Area of Service: Community
4. Logout of the system
• Finding information about upcoming events
1. Visit www.apo-em.org
2. Find the details for the next three events on the service calendar
• Find contact information and send an email to the Chapter President
1. Visit www.apo-em.org
2. Find the Chapter President’s email address
3. Send an email to the Chapter President
• Enter service hour records after an event
1. Visit www.apo-em.org
2. Login to the system
3. Report that Terri Hyle, Meghan Wahl, and Jackie Owens worked 8 hours
for the “Happy Helpers” service project you chaired
4. Logout of the system

Each person tested was to be given a pretest survey, asked to complete a series of
tasks on the interface, and then given a posttest survey. They were also to be asked to
sign a consent form indicating that they are aware of the testing that they are participating
in, and can ask questions or withdraw at any time. The pretest and posttest surveys are
featured below.

- 29 -

Figure 13. DUSC Usability Pretest Survey
- 30 -

Figure 14. DUSC Usability Posttest Survey


Informal usability testing

Since the DUSC team did not have a working prototype ready in time to conduct
its formal usability testing, informal surveys of about 12 members of the Epsilon Mu
Chapter were conducted to determine what changes to make to the low-fidelity
prototypes. The final color scheme, layout, and functionality were chosen through these
surveys. The members were surveyed in a round-table discussion of the prototypes and
asked to comment on the color scheme, layout, and functionality. Surprisingly, the
members seemed to come to consensus on their recommendations, so their suggestions
heavily influenced the final design choices, including the decisions to use the
- 31 -
navigational bar from Prototype 1 and the title bar from Prototype 2. Also, the choices to
keep the login prompt on each page while the user is logged out, and to use Flash’s
strengths to have pop-ups instead of full pages for the “Daily Details” and “Event
Details” pages were influenced by these surveys. These pop-ups function as dialogs with
the features of traditional web pages, such as scrollable text and clickable links. Finally,
the navigation arrows to the left and right of the month names on the calendar were
changed to “Previous” and “Next” buttons. People asked about this change were
indifferent to it.


Formal usability testing

The DUSC team ended up having time to perform this usability testing at the last
minute. Since the static pages of the DUSC product had been determined to be out of
scope for the true goal of the DUSC product – that is, to create a dynamically updating
service calendar – only the privileged and non-privileged members of the Fraternity were
asked to be tested. Four members agreed to be tested. By chance, a non-member
volunteered to be tested as well. The consent form was signed by each person tested, and
the pretest and posttest surveys were administered to each person tested. They were also
asked to complete modified versions of the tasks outlined above, modified to match the
working portions of the device.
The tasks that the users were asked to complete included logging in, finding an
event on the calendar, adding or modifying users, and figuring out how to complete an
event. Qualitatively, the users tested each found the parts of the website that they were
asked to find without any problems. Some people used manual entry to move around the
calendar, while others used the “Previous” and “Next” month buttons to navigate through
the calendar, indicating that both are useful, depending on the goals of the user.
The users also gave qualitative feedback on the posttest survey. The feedback
indicated that the users found the interface to be intuitive, easily navigable, and inclusive
of all features that would be useful. One user requested a directory feature for all
authenticated users and a bit more color in the interface. Finally, the decisions to add
event names to the calendar when the mouse rolls over the event and a descriptive error
message for each “day square” when it fails to load properly were both taken from these
qualitative assessments.
The responses to the quantitative posttest questions for features that had been
completely developed indicated that the users found the login process, understandability
of the website, and overall aesthetics to be on a level of 5 or better. The qualitative
responses gave us some hints as to how to improve these scores.
Finally, each person tested uses a computer for 9-20 hours a week, and each used
interactive sites. Two used calendar applications for 0.5 and 3 hours per week,
respectively. Operating systems used by those tested were Linux, MacOSX and
Windows, and the browsers used were Internet Explorer, AOL Explorer, Mozilla, and
Safari.



- 32 -
Conclusions

The current status of the DUSC system is: incomplete. The backend database has
been completely developed, but the front-end currently consists only of the general
scheme, privileged user pages, and the calendar interface. Some functionality remains to
be implemented, such as the attendance hour list, the event sign-up buttons, and event
attendance list. Communication between the front-end and back-end is currently being
established. The initial goals set by the DUSC team were too ambitious and took too
long to implement, and so had to be paired down accordingly. Progress on the task was
fairly significant, and the implemented functions work well. Work on the DUSC system
is expected to continue until the product is complete.
Once the product is complete, there is still room for future improvement. Forms
can be added to allow for non-service events such as meetings and fellowship events to
be added to the calendar. Also, over time the users of the DUSC system may express
interest in additional features that were not exposed during the informal usability testing.
For example, the users may wish to see the attendance for an entire event summarized on
one page, or have today’s events summarized next to the calendar, as shown in the
second prototype. Finally, the DUSC system should be tested on all of the operating
systems and web browsers that those tested in the usability tests use (so far, the device
has been tested in Linux, MacOSX, and Windows, and in Internet Explorer, Mozilla, and
Safari, but we have not tested all combinations of these). While Flash is designed to be
platform independent, there may be some slight differences in the ways the plug-ins work
for different browsers/OSs, and the DUSC team should be certain that the device does in
fact work in each combination of these.
A primary suggestion for future development is the addition of more privileged
roles, including specific permissions for creating users, editing members, creating
projects, etc., and a webmaster role that would have access to forms that allow updating
of the various “static” pages (these forms would allow for text and images to be added to
the content of the website without any necessary training in Flash development). The
backend database was, in fact, designed with this extension in mind, and hopefully it will
become reality.
While the DUSC product is incomplete, the DUSC team is committed to finishing
the product so that a working, standalone Dynamically Updating Service Calendar can be
used by the Epsilon Mu Chapter. Additionally, other chapters of Alpha Phi Omega can
take advantage of this product by simply modifying the text and images to suit their
needs. In fact, several chapters from Massachusetts have already requested that the
DUSC team send the DUSC source code to them upon completion. This development
suggests that perhaps non-Alpha Phi Omega organizations may be interested in using the
DUSC product as a basis for their own dynamically updating calendar.
- 33 -
Acknowledgements

Thank you to:

• Ben Shneiderman for his continued support and understanding;
• The Brothers of Alpha Phi Omega, Epsilon Mu Chapter for their input and
enthusiasm;
• Aaron Hopp, Hana Lee, Ben Parker, and Zalian Za for their valuable comments
and suggestions.
- 34 -
References

Alpha Phi Omega National Service Fraternity. Alpha Phi Omega National Service
Fraternity
. 2002. 28 Nov. 2005 <http://www.apo.org/>

Beier, B., & Vaughan, M. “The Bull's-Eye: A Framework for Web Application User
Interface Design Guidelines.” CHI 2003: New Horizons
5(1) (2003): 489-496.

Boucher, J., & Smith, M. “Web site redesign follies.” Proceedings of the 28th annual
ACM SIGUCCS conference on User services: Building the future
(2000): 14-18.

Chen, H., & Tompa, F. W. “Set-at-a-time Access to XML through DOM.” DocEng '03

(2003): 225-233.

Document Object Model (DOM) Level 3 Core Specification
. Ed. Le Hors, Arnaud, et al.
7 Apr. 2004. W3C. 9 Oct. 2005
<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/>

Garrett, Jesse J. “Ajax: A new approach to web applications.” Adaptive Path
. 18 Feb.
2005. 9 Oct. 2005
<http://www.adaptivepath.com/publications/essays/archives/000385.php>

Golub, E., & Shneiderman, B. “Dynamic query visualizations on World Wide Web
clients: a DHTML solution for maps and scattergrams.” International Journal of
Web Engineering and Technology
1(1) (2003): 63-78.

Macromedia, Inc. Exchange Search
. 2005. 28 Nov. 2005
<http://www.macromedia.com/cfusion/exchange/index.cfm>

Park, J. S., & Sandhu, R. “Role-based access control on the web.” ACM Transactions on
Information and System Security (TISSEC)
4(1) (2001): 37-71.

Schranz, M. W. “Engineering flexible World Wide Web services.” Symposium on
Applied Computing: Proceedings of the 1998 ACM Symposium on Applied
Computing
(1998): 712-718.

Shneiderman, Ben, and Catherine Plaisant. Designing the User Interface
. 4th ed. Boston:
Pearson Education, 2005.

Singel, Ryan. “You say you want a web revolution.” Wired News
5 Aug. 2005. 9 Oct.
2005 <http://www.wired.com/news/technology/0,1282,68403,00.html>