Webmaster''''s Guide to the Wireless Internet part 36 pptx

Enter a Keyword: The following parameters have been set: Department: $dept Location: $loc Title: $title Keyword: $key UP.Browser Interpretation In this section we will walk through t

<option value="Marketing">Marketing</option>

<option value="HR">HR</option>

<option value="Accounting">Accounting</option>

</select>

</p>

<p>Select your Location:</p>

<p>

<select name="loc">

<option value="Any">Any</option>

<option value="New York">New York</option>

<option value="San Francisco">San Francisco</option>

<option value="Denver">Denver</option>

<option value="Dallas">Dallas</option>

<option value="Washington, DC">Washington, DC</option>

<option value="Phoenix">Phoenix</option>

<option value="Salt Lake City">Salt Lake City</option>

<option value="Chicago">Chicago</option>

<option value="Seattle">Seattle</option>

</select>

</p>

<p>Select your Title:</p>

<p>

<select name="title">

<option value="Any">Any</option>

<option value="Associate">Associate</option>

<option value="Supervisor">Supervisor</option>

<option value="Manager">Manager</option>

<option value="Vice President">Vice President</option>

<option value="President">President</option>

</select>

</p>

Figure 7.25Continued

Continued

<p>Enter a Keyword:<br/>

<input name="key"/></p>

<p>

The following parameters have been set:<br/>

Department: $(dept)<br/>

Location: $(loc)<br/>

Title: $(title)<br/>

Keyword: $(key)<br/>

</p>

</card>

</wml>

UP.Browser Interpretation

In this section we will walk through the above deck (Figure 7.25) using the UP.Browser SDK.We will illustrate how this browser will render multiple

<SELECT> and <INPUT> elements in a single deck In sharp contrast to how

a desktop browser would render these individual form elements, the user is stepped through the different elements on the single card as if they were indi-vidual cards in the deck and linked in a linear fashion.When the user pulls up this deck in the UP.Browser, they will see only the first <SELECT> list, as illus-trated in Figure 7.26

Figure 7.25Continued

Figure 7.26directory2.wml on UP.Browser: Department Criteria

Upon selecting the Department, the user is forwarded to the next

<SELECT> list on the card; in this case it is the Location selector.This is shown

in Figure 7.27

Again, upon selecting an item in this list, the user is forwarded to the next

(and final) list on the card, the Title selector, shown in Figure 7.28.

Once the user has selected the criteria by which they would like to search, they are given the option to enter a keyword, shown in Figure 7.29

Figure 7.27directory2.wml on UP.Browser: Location Criteria

Figure 7.28directory2.wml on UP.Browser: Title Criteria

Figure 7.29directory2.wml on UP.Browser: Keyword Option

Finally, the user is shown the results of their entry, as illustrated in Figure 7.30.

As you can see, the UP.Browser will step the user through individual

<SELECT> lists on a single card as if they were individual cards (keeping keystrokes to a minimum).The reason for this has to do with the evolution of the UP.Browser:When it was first introduced, the UP.Browser was strictly capable of rendering Handheld Device Markup Language, and in many cases (especially in the U.S.), the binary that the phone receives is actually HDML that has been transcoded from WML by the WAP Gateway

This transcoding can pose some strange behavior in your application if you are using 3.1 UP.Browser features on a phone that only supports HDML 3.0

A full discussion of these differences is outside the scope of this chapter, but more details on this can be found on the Openwave Developer Web site at http://developer.openwave.com

Nokia Interpretation

One of the key differences between the UP.Browser and the Nokia browser is that the Nokia browser renders any <SELECT> list as being mapped to a List

option on the Accept key.This feature forces the user to list the options before

they can select one Once they have listed the options, they can select one

Once the user has selected an item and hit OK, they are returned to the card

containing the <SELECT> list.The usability hindrances imposed by this will become evident when we load up directory2.wml in the Nokia SDK

When the user first pulls up this deck, they are presented with several screens

of text with all of the <SELECT> lists and the <INPUT> element rendered on the same page In addition, the user can scroll down to see the final paragraph in our card, which displays the state of the variables on the card Figure 7.31 illus-trates what the user will see when loading up this card (note that this browser

renders the title attribute of the <CARD> element, unlike the UP.Browser).

Figure 7.30directory2.wml on UP.Browser: Viewing Parameters

Once the user selects the List option while the Department selector is active,

they see the following screen (Figure 7.32)

On this screen, the user can use their arrow keys to move up and down the

list Once they have highlighted the desired option, they must hit the Select

button to change the value, as illustrated in Figure 7.33

Once they have selected the option, they must then hit the OK button to

return to the card that contains the <SELECT> list.This process must be

repeated for each <SELECT> element on the card

This feature is similarly implemented with the <INPUT> form element.The

user must select the input, then select Edit to enter their selection Figure 7.34

illustrates what this looks like for the user

First, they must edit the <INPUT> element Once they select Edit, they can

enter text to be stored within the variable.When they are done entering their

text, they must hit the OK button to be returned to the card containing the

<INPUT> element

Figure 7.31directory2.wml on Nokia SDK: Selector List

Figure 7.32directory2.wml on Nokia SDK: Department List Option

Figure 7.33directory2.wml on Nokia SDK: Selecting from List

It is possible to do some rudimentary input validation by using the

format attribute of the <INPUT> element More details on this can be

found in Chapter 4 It is also possible to do some complex input valida-tion by using WMLscript More informavalida-tion on this can be found in Chapter 5.

At the end of this process, the user can scroll down to see the state of the variables that they have entered, as shown in Figure 7.35

As illustrated here, there are large differences in how the UP.Browser and Nokia browsers will render <SELECT> and <INPUT> elements.The cumbersome way the Nokia browser interacts with these elements is certainly cause for careful atten-tion to be paid as to which browsers are being used to access your WAP site

4thPass Kbrowser Interpretation

The Kbrowser, available at www.4thpass.com, renders WML significantly differ-ently than either the UP.Browser or the Nokia browser In order to illustrate these differences, we will compare how this browser renders the first example (with <SELECT> elements on different cards) with how it renders the second example (with the <SELECT> elements on the same card)

Figure 7.34directory2.wml on Nokia SDK: Entering Keyword

Figure 7.35directory2.wml on Nokia SDK: Viewing Parameters

Directory.wml Example

Figure 7.36 illustrates how the 4thpass Kbrowser will render directory.wml One

of the first things that we notice is that the <TEMPLATE> element is rendered

at the top of the user’s screen

Figure 7.37 illustrates how the Kbrowser renders <SELECT> elements.Their behavior is similar to how a desktop WWW browser renders radio buttons.They are treated as a set of mutually exclusive checkboxes, and the user is not able to select more than one element

Figure 7.38 illustrates what the final card of this deck looks like Note the

encoded space that is displayed when we show the Location variable.This can be

eliminated by unescaping the value of the variable by entering:

$(loc:unesc) instead of $(loc)

Figure 7.36directory.wml on Kbrowser: Selector List

Figure 7.37directory.wml on Kbrowser: Department Criteria

The 4thPass Kbrowser is will render keys that have been disabled with the <NOOP/> attribute It is not possible to disable the <PREV/> ele-ment with <NOOP/> for this browser There is a workaround, however, which involves assigning an <ONENTERBACKWARD> event to kick the user one element forward in their history stack.

This example behaves pretty much as expected, assigning values to the vari-ables and allowing the user to see the results of these values.When the

<SELECT> elements are on different cards, this browser behaves functionally equivalent to the other browsers, but what happens when we implement the second example?

Directory2.wml Example

When we load up directory2.wml in the 4thpass Kbrowser, all of the elements are displayed on the same page, as shown in Figure 7.39

However, the state of the page is not updated upon selecting any of the ele-ments on the page, and we cannot refresh the page without resetting the values

of the variables If this application were to be deployed into production, any users browsing the site with the 4thpass Kbrowser would be faced with an unus-able application If you are including this browser in the target browser set for your application, you would be best to branch your code according to the

Figure 7.38directory.wml on Kbrowser: Viewing Parameters

HTTP_USER_AGENT string, and test it thoroughly on a variety of devices and emulators

In this section, we’ve seen that the same WML code may be compiled and rendered on a variety of devices with radically different interfaces resulting from how the browser interprets the code In some cases, it is possible to write WML that will compile for a wide variety of browsers, but that will not be functionally equivalent among them.The examples presented here should be enough to con-vince you that it is important to view your code on different devices and branch

it accordingly

Figure 7.39directory2.wml on Kbrowser: Selector List

The Importance of Testing

It is extremely critical to test your WML site or application on every single emulator or device you can get your hands on If your target audience lies within the United States, it is doubly critical to do so, as the binary that is displayed on any given device will not necessarily be the WML that you have written (due to WAP gateway transcoding) Also, some emulators and devices may behave differently.

In addition to the technical concerns, it is critical to test the human factors of your application using real users in real-world scenarios Try testing your application while on the train, or in a cab, or walking down

Developing & Deploying…

Continued

the street It may be very easy for you to use your site while you are sit-ting comfortably at your desk, but it may be very hard to use in the field.

You will also find that it is much easier to enter input with a desktop key-board and mouse than it is to do with a stylus or keypad.

You may find that an application that works gracefully in an emu-lator and a controlled environment is clunky and hard to use in a real world situation You may also find that regular users will have difficulty interpreting your application because they are unfamiliar with it By showing a prototype of your application to a novice user, you will gain valuable information on how to make the final version more usable, and

by testing on real-world devices you will be subject to the constraints that all users face in the field.