DUSC: Dynamically Updating Service Calendar

Design Proces= s

&nbs= p; 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 o= f the back-end

&nbs= p; 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, bu= t is not necessary. The database c= ould 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 ba= ck-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 allow= ed access to the database back-end after a front-end authentication.

Requirements o= f the front-end

The DUSC front-end consists= of the actual user interface of DUSC, which should include features as specified b= y Epsilon Mu Chapter while conforming as much as possible to the eight golden rules of interface design. First, howe= ver, 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 t= he database.

The front-end must be prese= ntable 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 tra= ck their contributions to date, 2) privileged officers of the Fraternity who w= ill be given the ability to add events to the calendar in addition to the right= s 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 serv= ice 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 Al= pha 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-calend= ar pages will be supplied by the Epsilon Mu Chapter, and is merely an extensio= n of the DUSC product, but a potential feature of the DUSC product is an interfa= ce 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 g= olden 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 th= at is shown on all of the pages of the website. Also, the DUSC product should feat= ure 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 appea= r in the same place on any page while a user is not authenticated. If a user is authenticated, then l= inks to privileged pages will replace the user login prompt, but follow the same scheme set by the standard menu system.&nb= sp; All of the buttons on forms should be in the same format so that the= ir functionality is clear, and the names of buttons should concisely explain w= hat they will do when clicked. The display should be logically grouped in a visually appealing way so that use= rs can easily and efficiently find what they need to find.

In order to cater to univer= sal 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 com= puters with graphically enabled web browsers available to them by the University of Maryland. There is no known demand for addit= ional 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 b= e given for each user action. To faci= litate this, error dialogs, screens, or messages should be displayed whenever a us= er has attempted to access a privileged page that he/she does not have access = to and each page will have a title that closely matches its name on the menu f= rom which it was selected. When u= sers login, a page or message should appear to communicate that they are now log= ged in, and some sort of indication should be given that the user is still logg= ed in until the privileged session is ended by logging out or closing the brow= ser. Also, during intermediate steps involving data entry, the user should be informed of exactly what data he/s= he has changed or updated so that he/she can verify that the correct data was entered. If it has not been e= ntered 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: log= ging 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, t= hen 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 i= ts own closure. This closure wil= l 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 ac= tion and/or data he/she requested was completed and/or delivered.

Preventing errors will most= ly involve checking any input given by the user for the appropriate format. If one or more of these checks res= ults 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 wi= th the expected input format as part of the input form itself, or should be ab= le to click to a dialog explaining what is expected of them. Wherever possible, input choices s= hould 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 reversa= l 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 loc= us 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.&n= bsp; 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 fol= low 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.

Short-term memory load will= also be minimized by keeping the interface simple and by presenting users with an e= asy way to determine what types of input is expected from them, as discussed ab= ove.

Initial design=

Before the DUSC team made a= ny 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 te= am member visualized the DUSC system. These low-fidelity prototypes will be discussed in the next sub-sect= ion, but here the transition diagram and its design implications are discussed.<= /p>

Figure 1.= DUSC General Transition Diagr= am in the form of a flow chart

Examining the transition di= agram (Figure 1), it can be seen that the homepage node is connected to the most nodes. The homepage is direct= ly 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 calend= ar and the login function. The calen= dar 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 lea= d 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 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, plac= ing the login function as part of the standard menu on each page allows for easy authentication. Also, all pag= es 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.&n= bsp; 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. Finall= y, 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 offi= cer they will also be given access to “Manage Users” and “Cre= ate an Event” pages via new buttons on the standard menu, depending on wh= at type of privileges they have.

Design decisio= ns

After deciding on the initi= al flow of the DUSC product, the DUSC team was ready to make several important desi= gn 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 produ= ct is geared towards Alpha Phi Omega whose colors are blue and gold. To improve contrast and appeal, th= e 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.

· Titl= e 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 Maryla= nd, College Park.” An accompanying image was designed= to incorporate the Alpha Phi Omega crest and the University of Maryl= and 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, a= nd 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 lef= t-hand side of each page with links to the pages outlined above. Each link button on the menu bar w= as designed to highlight itself when the mouse is over it by changing text col= or from gold to yellow. This sim= ple feedback alerts the user that the highlighted button is active and will lea= d to a new screen when clicked.

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 w= ords, the “Home,” “Rush,” “About AFW,” and “Service Links” pages were not given an interface for updating by privile= ged users. The text, links, = and images on these pages have to be updated by directly modifying the sou= rce. Each static page would be giv= en 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 dyn= amic calendar system, not a “wiki” or other dynamically updatab= le reference.
Calendar pages: To make effic= ient use of space and an intuitive visual design, the 2-dimensional monthly calendar discussed above was chosen.&= nbsp; As such, each calendar page shows a single month. The calendar pages are actual= ly a single dynamic page with the month that it is supposed to show as an i= nput variable. The choice of = what date to show initially when a calendar application is opened is based = on the intended use of the calendar.&nbs= p; In this case, the calendar is intended to be used to view upcom= ing events, with the next upcoming event being the chronologically first important event. Thus, t= he current month was chosen to be displayed when the calendar is initially visited.
To allow the user to move forward or backward in time, “NextR= 21; and “Previous” buttons were added to show the calendar for= the previous and next months, respectively. Also added was a form allowin= g 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 no= t require input validation since the month is chosen from a drop-down menu. The year, however, requires s= ome 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 mon= th and year, giving the user an indication of what they entered. The calendar automatically ac= counts for all leap years by giving February 29 days whenever appropriate.
Finally, the calendar must display events. Each day of the month has a s= quare 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 th= e time at which it begins and the type of event it is: “SERV,” “FELO,” or “MTG,” for “Service project,” “Fellowship event,” and “Meeting,= 221; 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.<= span style=3D'mso-spacerun:yes'> If too many events exist on o= ne day to fit in the “day square,” then this is indicated by R= 20;-- more --" after the last event – it should be noted that thi= s is unlikely to occur since more than two events on one day is rare for th= is 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 retrievi= ng the data, the “day square” shows a red error message indicatin= g 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” lab= el in the boxes that are still loading, and the event scheduled for November 9th.

Event detail pages: Like the calendar pages, these pages are actually just one dynamic page showing= all of the events for a specific day.&nbs= p; 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 eve= nt are displayed. If the user is logged in and the event has not yet occurred, they also have an associ= ated button to “Sign Up!” for the event or a highlighted message indicating “You are signed up for this event,” and a butto= n in the same format as the “Sign Up!” button allowing the user= to “Cancel.” Fi= nally, each “Event Details” page has a link back to the calendar = for the month in which the event took place.
Daily detail pages: This dyna= mic 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 proc= ess 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, t= he login prompts will be replaced by buttons for their “Personal Ho= me” and to “Log Out.” If the user is also a privileged officer, buttons to “Man= age Users” and “Add an Event” will also appear as appropriate. This makes = it clear that the user is logged in.&nbs= p; If the username and password combination supplied do not authenticate, then the user is informed of such with a highlighted err= or message stating that the username/password combination did not authenticate. The user i= s 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 ba= r.
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 ro= les are to be supported by DUSC: unauthenticated user, authenticated membe= r, 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” pag= e), the user is shown a highlighted message stating “You have regist= ered for <event name> at <time> on <date>. To cancel this registration, = click here:” followed by a button to “Cancel.” Another button appears allowi= ng the user to “Return to Event Details Page.” This allows for an easy rever= sal 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.&= nbsp; 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 privil= eged 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 addr= ess, a drop down indicating their status (privileged officer or regular), a “View Attendance History” button, and an “UpdateR= 21; 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. No invalid inpu= t 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 “C= reate 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 e= mpty 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 ye= ar or from a 2-dimensional calendar with selectable dates. This is checked to verify tha= t 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 d= ate are still available). The me= eting 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.” Finall= y, 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|sel= ect] data for it and click Submit again.” Once there are no empty field= s and “Submit” is clicked, the user is shown a summary page of t= he 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 th= e 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.<= /li>
Error handling: Error handlin= g, as discussed in each specific case, is consistent throughout the product. Through the cho= ice of the front-end development language (discussed below) the DUSC team was able to eliminate the possibility of someone attempting to access a pa= ge 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 immediat= ely 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 fo= nt, sometimes in red font, and always inform the user what needs to be don= e 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, 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.&nb= sp; 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 scrip= ts, thus completing communication between the two.
Front-end development language: With the backend chosen to be MySQL with associated Perl scripts, the two m= ain choices for the front end were an Ajax implementation using JavaScript, Dynamic HTML, and Cascading Style She= ets to facilitate consistency or a Flash implementation. Both options allow for a smoo= th work experience and easy communication with the back-end. While the use of an Ajax approac= h 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 h= acker attacks, as communication with the server uses only the relatively sec= ure “POST” method, which is not easily infiltrated. Finally, Flash more readily a= llows for the consistency required for the DUSC team through the use of laye= rs.

&nbs= p;