DUSC: Dynamically Updating Service Calendar

Introduction<= o:p>

Alpha Phi Omega National Se= rvice Fraternity is the largest undergraduate intercollegiate organization in the= United States of America. This organization has been gatheri= ng 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 act= ive chapters at over 350 institutions of higher learning. Most of these chapters maintain we= bsites that help them serve information about the Fraternity to interested parties, including those interested in joining – or “rushing” R= 11; the Fraternity and those interested in community service opportunities in t= he area. While these resources a= re valuable, these chapters do not have a standard way of disseminating information about upcoming events and keeping track of which members partic= ipate 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 dynamical= ly updating calendar to serve information about upcoming service events and ke= ep 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 abo= ut upcoming service events. To t= his end, the idea to create a Dynamically Updating Service Calendar (DUSC) was born.

The use of the World Wide W= eb to serve information from a database has been explored through various differe= nt 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 r= equires a review of modern methods for creating such an application.

The original method of disp= laying 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 f= or that specific document. The n= ature of client-server communication includes built-in delays between a client’s request and the server’s response. Over time, the addition of interpr= eters for JavaScript and other scripting languages to web browser capabilities ex= panded the capabilities of HTML to introduce Dynamic HTML (DHTML). DHTML allows for information to ch= ange based on some information shared by the client and server. Time delays still existed, however= . Several technologies and schemes h= ave 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 ̵= 1; a term coined by Adaptive Path Firm. (Garrett, 2005; Singel, 2005)

Flash technology allows des= igners 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 ba= ck 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 functiona= lity, but instead uses a complete engine that is downloaded by the client at the beginning of the session. The engine, which uses JavaScript and Extensible Markup Language (XML) technolo= gies, 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; Singe= l, 2005)

Also of interest with regar= ds to a web-based system that can behave differently for different users is the iss= ue 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 allo= wed to register for an event. Dif= ferent users can be said to have a different “role.” Different solutions to this proble= m have appeared on the web, ranging from simple authentication based on a password= to Role-Based Access Control (RBAC) technologies. RBAC technologies offer large-scal= e, 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 sy= stems with the use of passwords, encryption algorithms, and a database to track e= ach user’s permissions. In = any case, the goal is to authenticate a particular user and ensure that that us= er 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 sche= me, object and data organization, clarity of data and error messages, etc. The following list of general prin= ciples 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 “applicab= le in most interactive systems” (Shneiderman and Plaisant, 2005, p.74).<= /p>

Finally, previous work in t= he 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 l= ed 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-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 Pers= onal Data Assistants (PDAs), web-based applications, or desktop-based applications. These applicati= ons 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 ty= pes takes advantage of common physical scheduling interfaces to achieve an intuitive design.

A search of Macromedia̵= 7;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 t= hese interfaces is designed specifically for use on a desktop, not on the web, a= nd 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)

&nbs= p;