Webmaster''''s Guide to the Wireless Internet part 35 pdf

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.wm

Trang 1

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

Figure 7.15Phone Information for info.wml

Figure 7.16info.wml Represented Graphically

n e s w

tel hrs addy dirs

#n

#e

#s

#w

Trang 2

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

Figure 7.17index.wml

Figure 7.18index.wml#info

Figure 7.19info.wml#dirs

Trang 3

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 concon-tains 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

Figure 7.20info.wml#e

Trang 4

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.21directory.wml

<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

"http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>

</do>

</template>

</refresh>

</onevent>

<p>Select your Criteria:</p>

<p>

<a href="#dept">Department</a><br/>

Continued

Trang 5

<a href="#loc">Location</a><br/>

<a href="#title">Title</a><br/>

</p>

</card>

<p>Department:</p>

<p>

<option value="Sales">Sales</option>

<option value="Shipping">Shipping</option>

<option value="Operations">Operations</option>

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

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

</select>

</p>

</card>

<p>Location:</p>

<p>

<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="Chicago">Chicago</option>

Figure 7.21Continued

Continued

Trang 6

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

</select>

</p>

</card>

<p>Title:</p>

<p>

<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>

<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 Figure 7.21Continued

Trang 7

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

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.22directory.wml: Department Criteria

Trang 8

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

Figure 7.23directory.wml: Location and Title Criteria

Figure 7.24directory.wml: Viewing Parameters

Trang 9

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.

Trang 10

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.25directory2.wml

<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"

"http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>

</refresh>

</onevent>

<p>Select your Department:</p>

<p>

<option value="Sales">Sales</option>

<option value="Shipping">Shipping</option>

<option value="Operations">Operations</option>

Continued

Định dạng
Số trang	10
Dung lượng	205,15 KB