Design Philosophies

Just as when you build an application that is going to present HTML to a client, when you build an application to deliver WML, always keep in mind who your target audience is. Think about how you would like your application to be experienced as well as how the average end user is going to interact with it.

Working with Limited Bandwidth

The wireless industry is already talking about the 3G data technologies such as GPRS and EDGE. These technologies will speed up the latency and throughput of today's wireless networks, but they are yet to be deployed. Even when this new technology appears, it will take some time for deep market penetration. Combine that with the lifecycle of wireless handsets, you can see that today's technology will live for some time to come. Think about DSL or ISDN. Both technologies have been on the market for years, but only now is the average Internet customer starting to use DSL. There will be a similar, albeit shorter, lag before these new technologies permeate the mass market. That being said, how can an application use the technology available today, and what are the limitations and concerns to be aware of?

The UP.Browser from Phone.com accepts a maximum of 1492 to 2000 bytes of data in each packet (including addressing information) and the Nokia 7110 accepts 1397 bytes of data. The Ericsson R320 accepts slightly more in each packet, but aside from the limits of the data your application can deliver at once, when you start delivering more than 500 bytes at a time, latency of the wireless networks starts becoming apparent. Unlike on the Web browser on your desktop machine—where if a page takes a long time to load you can switch to another application, read your email, or look at data in another window—when a user requests a deck on her phone, her attention is focused directly on the screen of the phone. The result is that perceived and actual latency can vary. To keep things moving smoothly it is advisable to keep compiled deck size below 500 bytes.

When WML content is delivered to the handset, it arrives in a compiled bytecode format. This will result in some compression, as the markup tags are tokenized, but if your deck contains a large amount of text, the "compiled" size might actually be larger than the raw data size. Some developer kits ship with a command-line WML compiler; however, it is unnecessary to precompile your WML because it is the responsibility of a WAP gateway to compile the WML for you. To find out exactly how large your compiled code will be, look in the Phone Information window in the Phone.com UP.SDK when you load your deck. In the Nokia SDK, load your deck into the editing window and the compiled size will display in the lower-right corner

Figure 14.1 shows the compiled and uncompiled bytecode size for a WML deck in the UP.Browser from Phone.com.

Figure 14.2 shows the compiled and uncompiled bytecode size for a WML deck in the Nokia WAP SDK version 1.3.

Working with Limited Screen Size

One reality of delivering content to WAP devices is the small size of the screens. Applications that are built for small-screen devices will still look good on larger screen devices, but the reverse is not necessarily true. Consider the following guidelines when building your WAP site:

• Up to four lines of text or selection items can be visible. Some phones will have as few as two lines and some will have as many as eight lines.

• Devices might provide an indicator that there is more text above or below the current screen.

• Do not rely on text formatting to indicate meaning. Some devices do not render text as bold, italic, strong, and so on, so don't expect it to render in a manner that indicates meaning in your data.

• On devices that display images the displayable region can be as small as 96×40 pixels. Images will not scroll horizontally and if they are larger than the display they might be cropped on one or both sides. Images will scroll vertically, but they can scroll a pixel or a line at a time.

• Soft-key labels might render directly above the keys for which they are defined. If they do render, their length might be limited to five characters.

• Approximately 12 characters can be displayed on one line. This number can vary since most phones support variable-width fonts.

These facts mean that you must present meaningful information very near the top of a card, or users might not discover it. If you expect a user to enter data on a card, place the input element within the first three lines of text.

The following code shows the good placement of the input element:

<card id="buy" title="order cd">
  <do type="accept" label="next">
   <go href="#add1"/>
  </do>
  <do type="prev">
    <go href="cnclcrd"/>
  </do>
  <p>
  Name<br/> First &amp; Last
  <input name="name" title="Full Name"/>
  </p>
 </card>

This code shows an example of bad placement of the input element:

<card id="buy" title="order cd">
  <do type="accept" label="next">
   <go href="#add1"/>
  </do>
  <do type="prev">
    <go href="cnclcrd"/>
  </do>
  <p>
Please enter your full name. Be certain to include
your first and last name
  <input name="name" title="Full Name"/>
  </p>
 </card>

Figure 14.3 shows how the good code will display on the Ericsson device (and on any other device for that matter).

Figure 14.4 shows how the bad code will display on the Ericsson device (and on any other device with a four-line display for that matter).

To provide more lines of data, or more options on a single card, with the UP.Browser you can use the mode="nowrap" attribute for the <p> element. This will result in Times Square–type scrolling on the device where the first 12 or so characters (depending on the device) will display; when a line is selected, the remaining text scrolls onto the screen from the right. An example of when you should do this would be in presenting a list of stories to choose from, as in the following code:

<p mode="nowrap">
      Financial News<br/>
        <a href="#n1">Stock Market Up</a>
        <a href="#n2">Fed Raises Interest Rates</a>
        <a href="#n3">Labor Strike Looming</a>
      </select>
    </p>
  </card>

This attribute has no effect on Nokia or Ericsson phones, but also does not cause any errors.

Because the purpose for displaying text is to provide information, the text should be wrapped except when a line of the text is either a short header or might have little relevance to the user. For example, when displaying news for a specific company, use the <p mode="nowrap"> mode to display the company name as in this example:

  <card id="n1" title="Story">
    <do type="accept" label="Skip">
      <go href="#n2"/>
    </do>
    <do type="options" label="Done">
      <exit/>
    </do>
    <p mode="nowrap">
    Intel News
      </p>
<p>Today Intel announced record profits again as it gets ready to
rollout the next generation of microprocessors that will approach
the 1000 MHz level, once again confirming Moore's law is alive and well
    </p>
  </card>

When you employ the <anchor> or <a> tag, do not expect the link to render inline. Each browser behaves slightly differently, but to date, all WAP-enabled phones will not render more than one link on a line. Also, be aware that each device can indicate a link in a different manner. The Nokia browser underlines links, whereas the UP.Browser from Phone.com renders links surrounded by [] or <> characters. The reason for this is that Phone.com does not control the underlying abilities of the devices to which the UP.Browser is ported. Not all devices have the ability to underline.

Working with Different Devices

The reality of the WAP world today is that there are several WAP vendors in the marketplace, which is a good thing. The downside of this for developers is that due to the flexibility in the WAP specifications, each vendor can render WML in a slightly different manner. As a result, code that displays perfectly on one device might be completely unusable on another. Although it is possible to write an application that works on all WAP-enabled devices, if your application takes a few simple steps to identify the actual device that is accessing your application, you can deliver content that is much more usable. For minimal effort, you can provide a vastly improved user experience, which will increase the likelihood of return visits to your site, and increase usage not only for your application but for any carriers who you are working with. This is a good situation for all parties involved.

The design principle for your application should ideally include abstraction between the data that you are delivering and the presentation of how you deliver it. To achieve this instead of building a site that is based on static WML, you should dynamically generate WML to present your content appropriately.

Consider, for example, presenting a title for a card to offer the user some context to the data she is viewing.

<card id="news1" title="INTEL NEWS">

On some devices the title attribute of the card is rendered in a field above the main display area; in other devices, the title attribute is not rendered at all. As a result, a title attribute should always be defined, but additional information needs to be displayed if the title does not render. The problem is ensuring that this information is not redundant. The following code snippet shows an example of providing a title attribute and informational text that complement each other and guarantee that the user will have some context when viewing the card.

<card id="news1" title="INTEL NEWS">
  <p mode="nowrap">
   INTC Latest
  </p>

If you identify the device that is communicating with your application, you can then remove this extra descriptive text and display more data.

The correct way to handle these differences in your application would be to build a simple API within your code for providing a title that looks at the USER_AGENT and then sets the title attribute or a first line of informational text. Listing 14.1 shows a simple API for handling the title.

Listing 14.1 Processing a Title or Informational Text

#!/usr/local/bin/perl5
##########################################
#
# This sample application makes use of the USER_AGENT
# HTTP Header to discover exactly who is calling it
# It then delivers the WML header lines and a Card title
# in a manner most fitting for two different cases
#
#########################################

$ua = &idUserAgent;               # call the sub routine to identify device
&addHeader;                       # print out the prologue for an WML Deck
&addTitle("Intel News", "news1"); # deliver  the <card> statement with an
                                  # appropriate title
&addPrev;                         # add the <prev> code to this card

# dump out the content of the deck that is the same across all devices
# and then you're done.

print 'Today Intel announced record profits again as it gets ready to
rollout the next generation of microprocessors that will approach the
1000 MHz level, once again confirming Moore's law is alive and well
    </p>
  </card>
 </wml>';

##################
#
# addHeader sub routine outputs the content type
# as well as the XML prologue and the DTD for the deck
#
#################

sub addHeader {
        print "Content-type: text/vnd.wap.wml 

";
    print '<?xml version="1.0"?>
               <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
                 "http://www.wapforum.org/DTD/wml_1.1.xml">
          <wml>
        ';


##############################
#
# addPrev sub routine adds the code to
# ensure that the user can navigate in the
# backwards
							
							
							
							
							
							
							
							
							
							
							
							 direction from your card
#
#############################

sub addPrev{
print '<do type="prev">
         <prev/>
        </do>';
}

##############################
#
# addTitle sub routine makes use of the USER_AGENT
# to decide in what format to deliver a title for the
# card in. It need not only the card Title, but the card id
# as well. The card id is the unique identifier for the
# card so it can be accessed. The title is the descriptive
# text. In the Nokia and Ericsson browsers it is rendered
# above the main display region on the device. On the
# UP.Browser from Phone.com the title attribute is not
# rendered at all, so it should be displayed in the body
# of the card
#
##########################

sub addTitle{
    my($cTitle,$cId) = @_;
    if ($ua =~ "N"|"E"){  # Nokia or Ericsson device
    print '<card id="'. $cId.'" title="'.$cTitle.'">
                <p>';
    }
    else{                 # Phone.com or other device
    print '<card id="'.$cId.'" title="'.$cTitle.'">
                <p mode="nowrap">
                 '.$cTitle.'</p>
                <p mode="wrap">';
    }
}

###########################
#
# idUserAgent sub routine looks at the incoming HTTP Headers
# as set in the $ENV variable by. Specifically it looks at the
# USER_AGENT header which will uniquely identify a specific device
# The code below identified a Nokia browser, an Ericsson browser,
# an UP.Browser from Phone.com or any other. This code can be extended
# to handle other devices or a finer level of granularity. Visit
# Nokia, Ericsson, or Phone.com for more specifics on how the USER_AGENT
# is employed.
#
#########################
sub idUserAgent{
my $ua = $ENV{ "HTTP_USER_AGENT"} ;
if ($ua =~ "Nokia"){  # 7110 delivers Nokia7110/1.0
    $ua = "N"
    }
elsif($ua =~ "Ericsson"){  # R320 delivers EricssonR320/R1A
    $ua = "E";
    }
elsif($ua =~ "UP.Browser"){  # Phone
							
							
							
							
							
							
							
							
							
							
							
							.com UP.Browser delivers a variety
                            # of USER AGENTS which always include UP.Browser
    $ua = "P";
    }
else{               # Default case 'Generic'
    $ua = "G";
}
return $ua;
}
}

Figure 14.5 shows how this code will render on the UP.Browser and how to use a title element that will be visible.

Figure 14.6 shows how this code will render on the Nokia 7110, and how to use a title element that will be visible.