322 Chapter 7 • Deck of Cards: Designing Small Viewpoint Content <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> www.syngress.com Figure 7.25 Continued Continued 159_wg_wi_07 10/23/01 10:36 AM Page 322 Deck of Cards: Designing Small Viewpoint Content • Chapter 7 323 <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. www.syngress.com Figure 7.25 Continued Figure 7.26 directory2.wml on UP.Browser: Department Criteria 159_wg_wi_07 10/23/01 10:36 AM Page 323 324 Chapter 7 • Deck of Cards: Designing Small Viewpoint Content 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. www.syngress.com Figure 7.27 directory2.wml on UP.Browser: Location Criteria Figure 7.28 directory2.wml on UP.Browser: Title Criteria Figure 7.29 directory2.wml on UP.Browser: Keyword Option 159_wg_wi_07 10/23/01 10:36 AM Page 324 Deck of Cards: Designing Small Viewpoint Content • Chapter 7 325 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). www.syngress.com Figure 7.30 directory2.wml on UP.Browser: Viewing Parameters 159_wg_wi_07 10/23/01 10:36 AM Page 325 326 Chapter 7 • Deck of Cards: Designing Small Viewpoint Content 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. www.syngress.com Figure 7.31 directory2.wml on Nokia SDK: Selector List Figure 7.32 directory2.wml on Nokia SDK: Department List Option Figure 7.33 directory2.wml on Nokia SDK: Selecting from List 159_wg_wi_07 10/23/01 10:36 AM Page 326 Deck of Cards: Designing Small Viewpoint Content • Chapter 7 327 NOTE 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 information 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). www.syngress.com Figure 7.34 directory2.wml on Nokia SDK: Entering Keyword Figure 7.35 directory2.wml on Nokia SDK: Viewing Parameters 159_wg_wi_07 10/23/01 10:36 AM Page 327 328 Chapter 7 • Deck of Cards: Designing Small Viewpoint Content 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) www.syngress.com Figure 7.36 directory.wml on Kbrowser: Selector List Figure 7.37 directory.wml on Kbrowser: Department Criteria 159_wg_wi_07 10/23/01 10:36 AM Page 328 Deck of Cards: Designing Small Viewpoint Content • Chapter 7 329 NOTE 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 www.syngress.com Figure 7.38 directory.wml on Kbrowser: Viewing Parameters 159_wg_wi_07 10/23/01 10:36 AM Page 329 330 Chapter 7 • Deck of Cards: Designing Small Viewpoint Content 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. www.syngress.com Figure 7.39 directory2.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 159_wg_wi_07 10/23/01 10:36 AM Page 330 Deck of Cards: Designing Small Viewpoint Content • Chapter 7 331 www.syngress.com 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. 159_wg_wi_07 10/23/01 10:36 AM Page 331 . 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. 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. 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