Section F. The example scripts


F. The example scripts

In order to gain a real understanding of the preparation phase, let's discuss the purpose and user interaction of my example scripts, and distill high-level decisions from them.

Below you'll find descriptions of the preparations I made for each of the example scripts. I start by defining the purpose, user actions, and the feedback on those actions. Then we'll take a quick look at script knowledge (what data does the script require in order to function) and maintenance considerations.

Note on Accessibility

The preparation phase is also the proper time to consider accessibility issues. Since we already treated these in 2E, I'm not going to repeat the discussion here, but accessibility issues played an important role in the decisions I made.


Textarea Maxlength

  • Purpose: Give a warning when the length of the user input exceeds a certain limit.

  • User actions: The user enters text in the text area.

  • Feedback: When the user exceeds the limit, a warning is generated: the current length of the text gets a special style.

  • Script knowledge: The script must know whether a certain textarea has a maximum length, and the value of this maximum length.

  • Maintenance: The Webmaster should be able to add maximum lengths to other textareas, or to change the limit of a textarea.

HTML structure

Here, as in a few other scripts, the script knowledge and maintenance requirements can be combined. Every textarea that has a maximum length should get a custom attribute maxlength. The presence of this hook alerts the script to the fact that it should check this textarea, and its value is the upper limit of user input. In addition, this attribute is easy to change even for newbie Webmasters.

Example:

<textarea maxlength="300"></textarea> 


Script structure

When the page is initialized, the script goes through all textareas and sees whether they have a maximum length. If they do, it sets an event handler.

When the event takes place, the script checks whether the user's text exceeds the limit. If it does, the script changes the style of the element that shows the current length of the text.

In order to do this, the textarea must somehow be related to this element: After it finds out which textarea is currently being edited, the script should be able to find the element that shows the current length. We already discussed the technical nuts and bolts in 4C.

Usable Forms

  • Purpose: Hide as many form fields as possible until the user indicates she needs them.

  • User actions: The user checks certain radio buttons or checkboxes, or selects a certain option.

  • Feedback: The form fields appear at their proper place in the document.

  • Script knowledge: The script must know if checking or selecting a certain value shows new form fields, and which form fields should be shown.

  • Maintenance: The Webmaster should be able to define new actions: "If the user clicks on this checkbox, show that form field."

HTML structure

As with the previous script, the script knowledge and maintenance requirements call for clear definitions in the HTML itself.

Eventually the form would be modified by the bank's internal Web developers, and their JavaScript knowledge was insufficient to add complicated script structures every time new form fields were added. I created a simple, intuitive system to define which form fields should be shown in which circumstances.

I decided to give a rel attribute with the same value to each element that triggers a certain form change, and to each tag that contains form fields that should appear. Example:

<tr> <td>[label]</td> <td><input type="checkbox" name="country_other"  rel="othercountry"> Other than The Netherlands</td> </tr> <tr rel="othercountry"> <td>[label]</td> <td><input name="other_country"  /></td> </tr> 


This allows Webmasters to easily add or change relations, and allows the script to find related elements. Besides, the existence of the rel attribute serves as a hook.

Script structure

When the script is initialized, it removes all container elements that have a rel attribute. If the user clicks on form elements with a rel attribute, it returns the containers with the same rel value to their original position in the document, or removes them again. We'll study Usable Forms's associative arrays in 8K.

Form Validation

  • Purpose: Validate form fields according to certain definitions.

  • User actions: The user tries to submit the form.

  • Feedback: Form fields with an erroneous value are highlighted. If there aren't any, the form is submitted.

  • Script knowledge: The script must know what to check the individual form fields for, and must have a custom function for every sort of check.

  • Maintenance: The Webmaster should be able to add existing definitions to new form fields, and to create new definitions and functions.

HTML structure

Form Validation needs an HTML attribute that serves as a hook, contains validation information, and can be updated by a newbie Webmaster:

<input name="phone" validation="required numeric" /> 


As we discussed in 4B, I could also have used class as a hook for this specific script.

Script structure

Since I wanted Webmasters with JavaScript knowledge to be able to add new validation definitions, the script structure should make it easy to add new bits of script.

Therefore I decided to treat the values of the validation attributes as keys to an associative array (we'll discuss those in 5K). If the script finds the value "required", it looks up the function it should execute to handle this bit of validation, and then it does the same with the value "numeric":

[Form Validation, lines 9, 12, 15-32 (condensed), and 47-49 (condensed)]

validationFunctions["required"] = isRequired; validationFunctions["numeric"] = isnumeric; function isRequired(obj) {     // check } function isnumeric(obj) {     // check } 


If the Webmaster wants to add a validation function, he can write the function, and add its name to the validationFunctions associative array and to the validation attribute of the relevant form fields:

<input name="phone" validation="required numeric mustBeMobile" /> validationFunctions["mustBeMobile"] = checkMobile; function checkMobile() {     // check if phone number is a mobile number } 


If a form field is discovered to contain an error, the script automatically creates an error message next to it. I used the same naming system as with the validation functions:

[Form Validation, lines 2-3]

validationErrorMessage['required'] = 'This field is required'; validationErrorMessage['numeric'] = 'This field requires a number'; 


In addition, I decided that any validation function could return one of three values:

  1. true; validation succeeded

  2. false; validation not succeeded, show default error message

  3. A string; validation not succeeded, show the string as error message.

This allows Webmasters to define special error messages for special cases.

Dropdown Menu

  • Purpose: Show parts of a hierarchical navigation so that the user is not overwhelmed by all possibilities and options.

  • User actions: The user selects a main navigation item.

  • Feedback: The sub-items of the chosen main item become visible. Any other opened submenu becomes invisible.

  • Script knowledge: The script must know which menu to show or hide.

  • Maintenance: The Webmaster should be able to define new main items and sub-items.

HTML structure

The script must understand which sub-navigation to show when the user selects a main navigation item. Obviously, the best way of doing that is to use nested lists. If the user selects an item that contains a list, that list should become visible. In addition, the root <ul> should get a class name that indicates "I'm a dropdown menu" and simultaneously serves as a JavaScript hook.

<ul > <li><a href="#">News</a>   <ul>     <li><a href="#">Press Releases</a>            <ul>                    <li><a href="#">Release 1</a></li>                    <li><a href="#">Release 2</a></li>                    <li><a href="#">Release 3</a></li>            </ul>     </li> etc. 


Script structure

In principle, the script structure is simple. If the user selects an item, make that item's nested list (if any) visible; if the user unselects the item, or selects another item, the nested list should become invisible again.

I didn't want to perform all kinds of complicated calculations in JavaScript, so I decided that the script would change only the className of the nested list. The CSS definitions for this new class name would take care of the actual visibility/invisibility.

We'll get back to Dropdown Menus in Chapter 7, especially in 7H.

Edit Style Sheet

  • Purpose: Allow a Webmaster to edit parts of a style sheet.

  • User actions: The Webmaster indicates the desired style changes in a form.

  • Feedback: The style changes are implemented immediately.

  • Script knowledge: The script must know which styles to change when the user does something.

  • Maintenance: The system manager should be able to define new styles that the Webmasters may change.

  • Special: This script is meant for Webmasters, and is therefore part of the administrative module of the site. Normal users won't use it.

HTML structure

This script works with a form that contains fields that allow the Webmaster to change the styles. Since the script runs on an administration page, we have greater control than usual over its exact content. Therefore the script does not use a hook, but instead is hard-coded to use the second form in the page.

In order to keep everything simple, I decided to store the names and values of the CSS properties in the form fields:

<select name="textAlign" >     <option value="">not specified</option>     <option value="left">Left</option>     <option value="center">Center</option>     <option value="right">Right</option> </select> 


This select box is meant for setting the alignment of the text. Therefore, its name is textAlign (the JavaScript version of CSS text-align), and the values of the options are the CSS values: left, right, or center.

The script thus only has to read out the name and value of the form field the user changed in order to know which style it should change to which value. We'll discuss this further in 5K and 9D.

Script structure

The script first has to access the individual rules of the correct style sheet (colors.css in the example). Then it waits for the user to pick a rule, and to change a style of that rule.

As we saw, the style change itself is easy: Just take the name/value pair of the form field the user has changed, and use it as a CSS property/value pair.

Sandwich Picker

  • Purpose: Allow the user to search for and order sandwiches.

  • User actions: The user searches for sandwiches. The user can indicate she wants either to order or trash a sandwich.

  • Feedback: The sandwiches the user searches for are moved to the search table. The ordered sandwiches are moved to the order table. The trashed sandwiches are returned to the start table at the bottom of the page.

  • Script knowledge: The script must know where the sandwiches are located, and has to be able to search through the names of all sandwiches.

  • Maintenance: The Webmaster should be able to add and remove sandwiches, and to set their prices. In this case the Webmaster was my client, and although he knew some basic HTML I didn't want to make things too difficult for him.

HTML structure

Each sandwich can be moved through the document. Since the list with all sandwiches and their descriptions is clearly a case of tabular data, it made most sense to give each sandwich its own <tr> and move these <tr>s through the document.

In addition, I put the price information in the table headers. Any sandwich below a certain header has that price. The element with initially contains all sandwich <tr>s, and therefore this id serves as the script's hook.

Script structure

The script's main job is to find out which <tr>s should be moved to which position, and then to do it. This is trickier than it seems; we'll discuss this problem fully in 8I.

The script should have easy access to the sandwich name and price, since they are needed for the search action and the total price calculation. Therefore I added these two bits of data as properties of the object that represents the <tr> (see 5J).

XMLHTTP Speed Meter

  • Purpose: Show the estimated download speed as an animation.

  • User actions: The user enters her postal code and house number.

  • Feedback: An animation starts up and shows the estimated download speed.

  • Script knowledge: The script must catch the download speed (or error message) that the server returns.

HTML structure

In all scripts we've discussed so far, I decided to store a significant amount of data in the HTML. This is not necessary with XMLHTTP Speed Meter; here, the data is pulled from the server by an XMLHttpRequest.

Therefore the only important point in the HTML structure was the animation. I decided to always show a grey background image, and to overlay it with an element that had a green background image. The animation would consist of changing the width of this element.

The script uses a few ids as hooks, and I assign a submit event to the only form in the page.

Script structure

This script has two distinct modules:

  • The XMLHttpRequest module fetches data from the server.

  • The animation module receives this data and shows it as an animation.

I developed each independently; their only point of connection is that the XMLHTTP module passes the data (the download speed) to the animation module.

We'll discuss the animation module in 9G and the XMLHttpRequest module in Chapter 10.

Site Survey

  • Purpose: Find out which pages of a site the user has visited, and redirect the user to a survey when she quits the site.

  • User actions: The user browses a site in the normal way.

  • Feedback: None visible. The popup remembers the pages the user has visited, but that information remains invisible.

  • Script knowledge: The script must keep track of the pages the user visits, and be alerted when the user leaves the site.

  • Maintenance: The client enters a few bits of data, notably the survey period and the project number. Nonetheless, there's no maintenance in the traditional sense.

  • Special: Ideally, the users never notice that the script is there, until they see the survey being opened.

HTML structure

This script should be able to work on any page in any site. Therefore, I didn't prepare an HTML structure, except for defining an optional element with . If this element is present in the page the script is added to, the script creates a little help text that announces the popup that's going to open.

The popup contains a bit of text and a form. The script adds as many hidden fields to this form as necessary.

This script uses no hooks, since I can't predict how the pages it will work on will be structured. Besides, the script hardly changes anything in the document tree, so it doesn't really need hooks.

Script structure

The main challenge was keeping the communication between the popup and the main window open. The script reads out the necessary data (mainly the page URLs) and stores quite a bit of information in cookies for safekeeping.

We'll discuss these features in detail in 6B.

Detail decisions

These explanations focus on the high-level decisions I made while I was working out the scripts. These decisions allowed me to start writing the script, although during the writing I discovered many special cases and little extras that also needed to be addressed. For instance:

  • Sandwich Picker needs a special function that converts a four-<td> <tr> to a three-<td> one or vice versa. The order table's fourth column is taken by the order form, so any <tr> I move to this table should have only three <td>s, and any <tr> I move to one of the other tables should have four.

  • Edit Style Sheet needed a few functions to remember what the user was doing: if the page is reloaded the user should be able to continue working on the same rule, with his previous changes still visible.

  • Usable Forms should scan all form fields after the page has been loadedsome may already be checked, and then the script should show the relevant <tr>s.

These are typical functionalities you add later on. Although they're important for the overall user experience of the scripts, you shouldn't worry about them much while making core decisions. Making sure that the basic functionality works is your first priority; once that's done you can start working on the extras. Besides, usually you'll discover the need for such extras only while you're writing the script.



ppk on JavaScript. Modern, Accessible, Unobtrusive JavaScript Explained by Means of Eight Real-World Example Scripts2006
ppk on JavaScript. Modern, Accessible, Unobtrusive JavaScript Explained by Means of Eight Real-World Example Scripts2006
ISBN: N/A
EAN: N/A
Year: 2005
Pages: 116

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net