312 Chapter 7 • Deck of Cards: Designing Small Viewpoint Content Figure 7.16 shows info.wml, which contains a total of 8 cards, and the rela- tionship between those cards.You will notice that 4 of the cards (n,e,s,w) are linked from the dirs card. www.syngress.com Figure 7.15 Phone Information for info.wml Figure 7.16 info.wml Represented Graphically n e s w tel hrs addy dirs #n #e #s #w 159_wg_wi_07 10/23/01 10:36 AM Page 312 Deck of Cards: Designing Small Viewpoint Content • Chapter 7 313 When the user first visits the site, they are shown the first card of index.wml, as shown in Figure 7.17. Upon selecting the Information link, the user is sent to the Info card, as shown in Figure 7.18. Upon selecting the Directions link, the user will be sent to the dirs card named info.wml.This selection will initiate the second request from the server.The dirs card of info.wml is shown in Figure 7.19. This card describes the location of the library, and also allows the user to choose a link that will give them directions to the library from the 4 compass points. Upon selecting to receive directions from the East, the user is shown the e card of info.wml.This is illustrated in Figure 7.20. www.syngress.com Figure 7.17 index.wml Figure 7.18 index.wml#info Figure 7.19 info.wml#dirs 159_wg_wi_07 10/23/01 10:36 AM Page 313 314 Chapter 7 • Deck of Cards: Designing Small Viewpoint Content In this example, we have made use of the hub-and-spoke metaphor to deliver the information with a minimum of individual server connections.The user seeking directions in the first request was sent the entire navigation of the site (four cards) in a single deck. On the second request, the user was sent the entire content of the information section (eight cards) in a single deck. The user only had to connect to the server twice: once to receive the global navigation, and once to receive the content for an entire section.Astute viewers will notice that the content deck has no ”index” or “main” page. It merely con- tains the content, as the navigation deck contains all of the links necessary to nav- igate the subsection.The user will be able to view the entire Info section without another request to the server. Since the library’s location, phone numbers, and directions are unlikely to change, we may want to specify a header that instructs the browser to keep this deck in the browser cache.This will give the user ready access to this information from their history stack in the future.The syntax for header declarations in WML is identical to that of HTML, as it is part of the HTTP specification. Utilizing WML Variables WML has the capability of storing variables on the device, which is a concept unheard of in the stateless world of the WWW.Typically, server-side programmers have had to generate Web sessions or maintain the state of the transaction by printing out variables in hidden form fields to pass their values from transaction to transaction.With the ability to store information on the device, you can gather input from the user in a series of cards instead of gathering information CGI- style by passing variables in hidden fields. Let’s say, for example, that we are building an interface to a company direc- tory.The directory contains the department, title, name, phone number, e-mail, and mailing address of every person in a 45,000 employee company. In order to www.syngress.com Figure 7.20 info.wml#e 159_wg_wi_07 10/23/01 10:36 AM Page 314 Deck of Cards: Designing Small Viewpoint Content • Chapter 7 315 get the information they need, a wireless user may wish to narrow their search by location, department, or title. Instead of gathering information from the user in a series of requests, we can gather the desired information by sending one deck to the user.The function of this deck is to generate the parameters necessary to execute a short list of relevant contacts. In the example shown in Figure 7.21, we will allow the user to set param- eters, then display the selected parameters.We will be using the UP.Browser SDK to view this deck, but rest assured that it works in both the Nokia and 4thpass Kbrowsers. In the next section, we will explore display differences in detail. Figure 7.21 directory.wml <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <template> <do type="options" label="GO!"> <go href="#search"/> </do> </template> <card id="home" title="Directory"> <onevent type="onenterforward"> <refresh> <setvar name="dept" value=""/> <setvar name="loc" value=""/> <setvar name="title" value=""/> </refresh> </onevent> <p>Select your Criteria:</p> <p> <a href="#dept">Department</a><br/> www.syngress.com Continued 159_wg_wi_07 10/23/01 10:36 AM Page 315 316 Chapter 7 • Deck of Cards: Designing Small Viewpoint Content <a href="#loc">Location</a><br/> <a href="#title">Title</a><br/> </p> </card> <card id="dept" title="Department"> <p>Department:</p> <p> <select name="dept"> <option value="Any">Any</option> <option value="Sales">Sales</option> <option value="Shipping">Shipping</option> <option value="Operations">Operations</option> <option value="Marketing">Marketing</option> <option value="HR">HR</option> <option value="Accounting">Accounting</option> </select> </p> </card> <card id="loc" title="Location"> <p>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> www.syngress.com Figure 7.21 Continued Continued 159_wg_wi_07 10/23/01 10:36 AM Page 316 Deck of Cards: Designing Small Viewpoint Content • Chapter 7 317 <option value="Seattle">Seattle</option> </select> </p> </card> <card id="title" title="Title"> <p>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> </card> <card id="search" title="Search"> <p> The following parameters have been set:<br/> Department: $(dept)<br/> Location: $(loc)<br/> Title: $(title)<br/> </p> </card> </wml> You will notice the <TEMPLATE> element at the top of the deck.This ele- ment allows us to render the same code on every card within the requested deck. No matter which criteria the user decides to narrow their request by, they will still have the option of viewing the selected parameters by selecting the Options www.syngress.com Figure 7.21 Continued 159_wg_wi_07 10/23/01 10:36 AM Page 317 318 Chapter 7 • Deck of Cards: Designing Small Viewpoint Content key or moving back to the main page with the Accept key to further narrow their search. NOTE In the example shown in Figure 7.21, we are displaying a link to the card with an id of search to display the user’s parameters. However, this link could very easily point to a CGI script that would execute the search with the selected parameters. Figure 7.22 illustrates what the user will see when they pull up directory.wml in their browser and select Department. www.syngress.com Persistent Variables WML variables are persistent throughout time. The example shown in Figure 7.21 will store the selected variables between browser sessions. It is recommended that these variables be set to an empty value using the <SETVAR> command before sending the user to the search application, to avoid using old parameters. It is possible to clear ALL of the variables stored on the phone by using the newcontext=”true” attribute, but this can cause problems for the user on other sites, as well as any other stored variable-dependent applications they may be using on your site. Debugging… Figure 7.22 directory.wml: Department Criteria 159_wg_wi_07 10/23/01 10:36 AM Page 318 Deck of Cards: Designing Small Viewpoint Content • Chapter 7 319 Once the user has selected the Department in which to search by pressing the accept key, they are returned to the first card in the deck.They can then narrow their search by Location and Title, as illustrated in Figure 7.23. Once the user has selected their criteria, they can select the Options key (labeled GO!) to view their parameters, as shown in Figure 7.24. The advantage to this multi-card approach is that the user can quickly enter the information using the first deck, without having to initiate a server request to set each different variable.We could potentially render all of the select lists on one card, although this would result in a very different user experience depending on the browser being used. For example, the Nokia WAP browser has no problems displaying multiple <SELECT> lists on a single card, so the user can individually select the elements of each <SELECT> list. On the other hand, if the user is using the UP.Browser (version 3.x or 4.x) from Openwave (formerly Phone.com), then the select lists will automatically be rendered on different cards and the user will be run through the select lists in a linear fashion. In the next section, we will discuss the most common display differences among browsers. Depending on the markets in which you are deploying your content, you may want to focus on a specific browser or use server-side scripting to branch your code. www.syngress.com Figure 7.23 directory.wml: Location and Title Criteria Figure 7.24 directory.wml: Viewing Parameters 159_wg_wi_07 10/23/01 10:36 AM Page 319 320 Chapter 7 • Deck of Cards: Designing Small Viewpoint Content Examining Display Differences Between Browsers Whereas the wired Internet browser wars of the mid 1990s were the result of dif- ferent companies trying to dominate the market, you should be prepared for the multiplicity of wireless devices and browsers that are available.WML browsers have been developed for many different devices; including mobile phones, e-mail pagers, and PDAs. When designing for the wireless Internet, you are dealing not only with a browser that may implement features differently, but with different devices that will interact with the features in a different manner. Developing for two browsers on a desktop computer is very different to developing for 10 different browsers on 10 different devices with radically differing input methods. For example, a mobile phone user will have only keys with which to input data. Usually, one key acts as a positive acknowledgement (accept), and one offers more options (options). Many phones will have a back key built into the handset.Alternately, a PDA will often use a stylus as the primary input device, allowing for a somewhat mouse-like interface. Some e-mail pagers (such as the RIM 957 Blackberry) have a miniaturized keyboard and a scrolling wheel for the interface. It is generally accepted, therefore, that user input should be minimized wherever possible. Fortunately,WML is defined as an application interface, so you will not have to code individually for each device. It is up to the browser programmers and device manufacturers to interpret the feature set of WML and map it to the input mechanisms of the device. Unfortunately, this world is not perfect, and there are some large differences in how your code will be interpreted on the different devices and browsers. NOTE Openwave has published a list of UI guidelines for the UP.Browser. It is available online at http://developer.openwave.com/resources/uiguide.html. In addition, they have published guidelines for markets that serve both the Nokia and Openwave browsers. A full list of Openwave UI white papers may be found at http://developer.openwave.com/support/techlib.html. www.syngress.com 159_wg_wi_07 10/23/01 10:36 AM Page 320 Deck of Cards: Designing Small Viewpoint Content • Chapter 7 321 In this section, we will examine a few of the differences among the devices and discuss methods of ensuring a consistently usable application.We will focus on the Openwave UP.Browser, the Nokia browser, and the 4thPass Kbrowser.We will also provide an example of submitting a search form that contains both a <SELECT> and an <INPUT> element in order to illustrate the usability differ- ences among these three browsers. Figure 7.25 contains the same <SELECT> lists as the example in Figure 7.21, but with all of the <SELECT> lists contained in a single card.We are still clearing our variables on entry, but we are not including the <TEMPLATE> element because the user will be directed linearly through each element on the single card in the deck. Figure 7.25 directory2.wml <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card id="home" title="Directory"> <onevent type="onenterforward"> <refresh> <setvar name="dept" value=""/> <setvar name="loc" value=""/> <setvar name="title" value=""/> </refresh> </onevent> <p>Select your Department:</p> <p> <select name="dept"> <option value="Any">Any</option> <option value="Sales">Sales</option> <option value="Shipping">Shipping</option> <option value="Operations">Operations</option> www.syngress.com Continued 159_wg_wi_07 10/23/01 10:36 AM Page 321 . Chapter 7 319 Once the user has selected the Department in which to search by pressing the accept key, they are returned to the first card in the deck.They can then narrow their search by Location. back to the main page with the Accept key to further narrow their search. NOTE In the example shown in Figure 7.21, we are displaying a link to the card with an id of search to display the user’s. deck contains all of the links necessary to nav- igate the subsection .The user will be able to view the entire Info section without another request to the server. Since the library’s location,