|
|
It is 9:00 a.m. on the Monday morning the Center Park Web site has gone live. As part of your initial project proposal, you are now in a critical meeting with the school administrators to review the functioning of the site to ensure that it meets all required functionality and to make a list of possible future updates.
Imagine, then, that the following sections are "meeting notes" from this discussion, as you—as the site developer—discuss your final product with the school administrators. Also, note that the final section contains a complete listing of each source file for the entire site (this type of source code listing might be something you would provide to the client, especially those who may have the expertise to modify functionality of the site on their own).
The first thing to review in the completed site is the site home page. Figures 21.1 and 21.2 show the page and highlight the rotating banner functionality that has been built into the site.
The home page meets many of the functionality requirements set forth in the initial project request:
The rotating banner graphics (in this case, highlighting the general "Support Your Bobcats" message as shown in Figure 21.1, and the advertisement for the "June Bug Festival" as shown in Figure 21.2) help to answer the "screen real estate" issue, in that by displaying each ad for a few seconds, they allow multiple advertisements to share the same space, with each getting equal "air time." Note there is no limit to the number of graphics you can rotate; moreover, you can include hyperlinks within each one so that if a particular group/event being advertised has its own Web site, a link could be provided to it within the rotating ad.
As shown in Figure 21.3, the navigation buttons utilize DHTML effects by changing color when the mouse is moved over them. Note as well that the functionality presented by these links is also presented in the right frame. Why do this? In case the user somehow was to get out of the site frame set (and thus lose the navigation buttons presented in the left frame), he or she could still access all the major functionality of the site.
Figure 21.3: When you move your mouse pointer over each navigation button, it changes color to indicate that it is active and ready to be selected.
While this is arguably a simple design (for illustrative purposes only; in the "real world" you might be asked to put a more aesthetic touch to your design), it works well from a functional perspective—all major site functionality is readily available and easy to find and understand, via the names given the button links.
Because of the omnipresent security concerns with Web sites, more and more organizations of all sizes are seeking to secure specific content. Sometimes, organizations will form "intranets"— versus an extranet or Internet site—in order to make information available only to employees or other authorized persons.
The Center Park Web site is no different. In this case, the secure Log In button, when clicked, presents users with a user name and password sign-in, as illustrated in Figure 21.4.
JavaScript doesn't have a lot of built-in security functionality, and this "secure" login is indicative of that. Still, the page does have some basic attributes that you could—in a real-world situation— develop in a more robust manner:
The password field could be changed to a regular form password field, where the characters that are entered are marked out and represented only by asterisks (this is still only very basic security, but it would prevent, for example, someone from gaining your password while looking over your shoulder as you keyed it in).
If this were a production site, each user would have a specific user name and password; however, even in this basic example, you can see the inherent security that is possible by locking out unauthorized access via a user name and password.
Once users log in to the site (via the user name and password shown in Figure 21.4), they are presented with their customized calendar of tasks and events, as shown in Figure 21.5.
The calendar function, even in this most basic form, is a virtual cornucopia of JavaScript functionality. The following subsection describes how this coding meets many of the defined requirements of the Web site.
The Center Park administrators wanted their site to present users of all types (teachers, students, and parents) an easy and convenient way to keep in organized touch with the Center Park School.
That said, the Task Calendar fits the bill for many of these function requirements:
As shown in Figure 21.5, the calendar is specific to each user login (“Welcome John!!).
The calendar defaults to the current month and day (the current day is highlighted with a box around it).
"Navigation" buttons are presented at the bottom of the calendar, so users can move forward or backward one month in order to view that month's respective calendar.
The ability to add a task to the calendar is presented via the "Add task" link at the bottom of the calendar.
Adding a task to the calendar is an important functional component. When the user clicks on the "Add task" link illustrated in Figure 21.5, he or she is presented with the Schedule Task form, as shown in Figure 21.6 below.
To add a task, the user would follow these steps:
First, the user would click on the "Add task" button as shown in Figure 21.5. This presents the Schedule Task screen, as shown in Figure 21.6.
At this point, the first thing to do is select the date of the task. As shown in Figure 21.6, the user would click on the button underneath the "Date of task" text, which in turn brings up the Date Chooser pop-up calendar, as shown in Figure 21.7.
Figure 21.7: The Date Chooser pop-up allows a user to select a specific date for their task. Note that the date and month can be changed so that the task can be assigned to any date, not just during the current month.
Once a date is selected in the Date Chooser pop-up calendar, it is automatically inserted back into the initial form, as shown in Figure 21.8. Also, the description of the task is also entered. Note that in this case, the following HTML is entered:
Figure 21.8: Once a date is chosen in the Date Chooser, it is placed into the Date of task field.
<a href="http://www.centerparkschool.edu/tests/test1.html">Click here to take the
first exam.</a>
so that when the task is placed on Donald's calendar for 5/30/2003, it will actually be a hyperlink to the an exam.
Once the date and task description are entered, the user clicks the Submit button and the task is entered on his calendar.
While the Center Park administrators have their reservations about going to a purely online testing environment, they are interested in working with this functionality in the new site.
If you look back to Figure 21.5, you can see that on May 5th, there is a task entitled "Take CS Test." If you click on this link, you will be presented with a glimpse of the online testing component, as shown in Figure 21.9.
 |
The code for the Center Park site that is presented in this chapter, while functional, is for illustrative purposes only.
What's the catch, you say? The data entered in the Task Calendar (as well as the online store, which is illustrated a bit later in this chapter) doesn't really go anywhere when the user clicks the various submit buttons. Why is this so? The answer is simple: the data has nowhere to go; specifically, it doesn't have a database to be inserted into.
Integrating a database with your Web site can be a complicated task, depending on the type of functionality you wish to present. However, you will quickly find that you will need this type of functionality if you are to move beyond the most basic functionality. Unfortunately, database integration goes beyond the scope of this book (focusing as it does purely on JavaScript); moreover, there are different programming methods that can be utilized to integrate a database with your site.
That said, then, much of the advanced functionality of the Center Park site is just an illustration of potential functionality that could be achieved if the site were integrated with a database.
|
Figure 21.9 illustrates a simple five-question Computer Science test. The user is presented with answer fields, and at the bottom of the screen (not visible in Figure 21.9) is a Submit button for them to click when they have answered all questions. Note that if they do not enter something in each answer field, they will be presented with a warning prompt (more JavaScript functionality here…) as shown in Figure 21.10.
When each question has been answered and the Submit button has been clicked, the test-taker's score is immediately returned, indicating right/wrong answers, as shown in Figure 21.11.
As mentioned above, while the core functionality is here, you would ideally need some type of backend database to capture the scores as well as store the questions and answers. Right now, the questions and answers are hard-coded into the actual Web page file that presents the online test. While this is good for, again, "illustrative purposes," it probably would not be the best solution either from a security perspective or in order to store the results of each test.
JavaScript can be utilized in conjunction with DHTML in order to produce some neat and functional effects. The site navigation buttons are one example of this; however, an even better example is how the site allows the visitor to set both the foreground and background colors.
When the user clicks on the Custom Navigation button, he or she is presented with the options shown in Figure 21.12.
As shown in Figure 21.12, the user can select the foreground and background colors of the site. Figure 21.13 illustrates how choosing black as the background and white as the foreground changes the appearance of the Center Park site.
While this is again a simple example, it hints at the possibilities in Web page customization features that are possible with JavaScript. Moreover, giving the user this type of control is good customer relationship management and indicates that you—as site designer and/or administrator—are interested in catering to your customers' specific needs and interests.
The final piece of required functionality, as set forth by the Center Park school administrators, was to have some type of basic Web store, so that visitors could shop for school merchandise (and thus, again, potentially alleviate the need for all those bake sales). Figures 21.14 through 21.16 illustrate the base functionality of the Web Store.
As with some of the other functionality of the site, in the real world this type of online store would have several other factors that go beyond the scope of this book. Clearly, one of those factors would be how individuals actually pay for their items: Do they get an invoice via e-mail? Are they asked to enter credit card information?
However, even in its "just for illustrative purposes" form, the code presented here could still be considered an online store. How? Perhaps the store is really just a catalog, where shoppers can browse what is available, get a total, and then e-mail their request to the school store or print out a hard copy order form and mail it in. The point here is that— along with other functionality shown in this chapter—the core functionality is provided, and with some customization (as well as integration of a database), the site could easily fit all requirements set forth by the school administrators, even in a real-world setting.
|
|
