Developing Pages for Mobile Web 3 2-15-09

Verizon Wireless
Web Development Guide for Mobile Web 3.0
1
DEVELOPING PAGES FOR MOBILE WEB 3.0
Introduction
Mobile Web 3.0 gives Verizon Wireless’ (VZW’s) 70+ million subscribers access to the internet,
including the ability to directly read web pages on their handheld devices. It supports a wide range of
web design standards and protocols, including JavaScript, CSS, and Flash Lite, as well as web-based
audio, animation, and video.
Mobile Web 3.0 comes installed on a wide variety of handsets, from consumer-level cell phones
to feature-rich personal digital assistants. In accordance with resource availability on the various
handsets, Mobile Web 3.0 comes in three tiers of functionality: basic, full, and enhanced.
This development guide is intended for developers who want to create appealing, functional
web page designs for Mobile Web 3.0 with a relatively small amount of work. It will tell you about
Mobile Web 3.0’s new and existing features and how to take advantage of them to optimize existing
designs, or to create your own optimized pages.
This guide will also give you strategies for tailoring your designs to the broad range of mobile
handheld devices which will be running Mobile Web 3.0. You may choose to deliver different designs for
different sets of screen widths, as well as to differing tiers of functionality. You may also wish to keep
track of your web site. This document will tell you how to access user profile information and other
relevant device data.
This guide will also instruct you how to build in commands for dialing, messaging and other
handset features, and has recommendations for making your designs optimal for the mobile platform.
This development guide is broken into the following sections:
Part 1: Introducing Mobile Web 3.0
Chapter 1: What is Mobile Web 3.0?
An overview of Mobile Web 3.0’s features in the context of mobile web development
Chapter 2: Planning for Mobile Development
The unique constraints and advantages of the mobile web medium and common practices for it

Verizon Wireless
2
Part 2: Adapting Existing Pages with CSS
Chapter 3: Adapting an Existing Site for the Mobile Platform
How to use CSS Style Sheets to adapt your existing pages to Mobile Web 3.0
Part 3: Creating Fully Mobile-Optimized Pages and Sites
Chapter 4: Managing User Profile Information
Details on user profile information provided by the VZW server and Mobile Web 3.0
Chapter 5: Creating Effective Mobile Pages
How to create fully mobile-optimized pages that take into account navigation and data-entry
constraints
Chapter 6: Implementing Dialing, Messaging and Other Handset Functionality
How to set up your pages so Mobile Web 3.0 users can contact you directly with their handset
Chapter 7: Optimizing Your Mobile Site for Performance
Strategies for improving page load on Mobile Web 3.0 devices
You may also be interested in these separate documents:
Mobile Web 2.0 Technical Specifications
Mobile Web 3.0 Technical Specifications
Working with Multimedia in Mobile Web 3.0
Using Linkaways
Using Location-Based Services
Verizon Wireless Optimized View for Mobile Web

Verizon Wireless
3
Chapter 1
What is Mobile Web 3.0?
Verizon Wireless’s 70-million (and growing) subscriber base now accesses the internet via
Mobile Web 3.0. Previously, delivering web content to mobile subscribers often required you to work
around many design limitations, such as lack of multimedia or Javascript support. Mobile Web 3.0
supports most web standards and protocols, including Flash, so sites can function, and typically, look
much more like their desktop counterparts. For a concise and thorough list of supported languages,
protocols, and multimedia formats, see the document “Mobile Web 3 Technical Specifications.”
Mobile Internet: It’s Getting Better All the Time
The mobile internet space used to be a spare counterpoint to the rich world of HTML-based web
design. In the past, many mobile handheld devices relied on WAP (Wireless Application Protocol) 2.0 for
internet access. This protocol had a unique architecture that separated web content into smaller
interconnected pieces that could be easily transmitted and received, but it made for a different web
browsing user experience than people were used to on their desktop. Developers had to create
alternative mobile pages with WAP-specific tools, and users were sometimes unable to access HTML-
based pages they were interested in.
But as mobile handheld devices have become more powerful, so has the range of what they can
support. VZW subscribers can currently access HTML pages, and with Mobile Web 3.0 they enjoy mobile
internet access close to what they’d expect on a PC. Web standards are thoroughly. You can use your
regular Javascript and CSS style sheets. And you can expect support for web standard graphics, audio
files, and video formats, including Flash- and SVG-based content.
Security and User Tracking
Mobile Web 3.0 gives you meaningful security with its support for SSL (Secure Socket Layers) 3.0
and TLS 1.0 (Transport Layer Security), including authentication and encryption. Cookies and bookmarks
can be stored on the user’s mobile handheld device, making it easier for both sides to recognize each
other and get to the right information. You’ll be able to get relevant user profile information, including a
key to help you with site traffic statistics.
Streaming in Mobile Multimedia
With the full and enhanced tiers of Mobile Web 3.0, VZW subscribers can play inline and
embedded music and video. Mobile Web 3.0 supports RTSP (the Real Time Streaming Protocol), and
web multimedia standards such as MP3 audio and MPEG-4 video. A lightweight version of Adobe Flash,

Verizon Wireless
4
Flash Lite 3.0, is built into Mobile Web 3.0, so small Shockwave animations and FLV (Flash Video) can
play, depending on the resource availability in the handset.
Easy Adaptation and Maintainability
You can expect your HTML-based web pages to run under Mobile Web 3.0, complete with
scripts, styling, and animations. Higher-end handsets will even support Flash-based designs to a certain
size. You don’t have to rewrite your site completely for the mobile platform. You can adapt your existing
page quickly, knowing that most protocols and standards are supported. If you have a straightforward
page design already, you may need little more than using CSS and simple scripts to have your pages
reformat themselves to different screen sizes.
New Features for Innovative Web Development
Mobile Web 3.0 gives you the potential to go beyond the desktop, and create designs that take
advantage of the communication power and mobility of handheld devices. You have access to
commands that let users contact you from your web site. VZW subscribers can access downloadable
content via “Linkaways” (a clever way your site can integrate with a VZW server and applications to
deliver music, video, games and more). With user permission, you can lock into the subscriber’s bearings
to deliver information specific to their location using Location Based Services (LBS).
User-Side Adaptation
Even if you don’t redesign your pages, or your design is too complex for some devices, Mobile
Web 3.0 users will be able to make it work for them. Mobile Web 3.0 includes user options for content
optimization, a VZW service which adapts web pages so they fit a device screen and run as fully as
possible. Users can also set Mobile Web 3.0 to set all web pages to fit to their screen’s width, or to show
only the text on a page. This guarantees your page will be available to all users, though you may want to
set up designs that won’t be affected by these choices.
Conclusion
As handheld mobile devices are becoming capable of delivering high-quality web pages with
streaming video and Flash, Mobile Web 3.0 is there to let you take deliver your pages to the mobile
work. Millions of VZW subscribers are looking for compelling pages to browse when they’re away from
their desk, but still on the web. You’ll find it won’t take extensive effort to tap into this market: you
simply have to understand the mobile platform and know which changes you need to make.

Verizon Wireless
5
Chapter 2
Planning for Mobile Development
The mobile handheld platform presents some unique issues, especially for web page designers
used to creating pages for the desktop platform. You may not have to rewrite your HTML pages to
conform to mobile platform protocols, but it goes without saying that handheld mobile devices are a
dramatically different medium.
Most obviously, you have to design for screens with are considerably smaller than a desktop
screen, and come in a wide variety of sizes, form factors, and resolutions. Navigating through your pages
and entering data is much more difficult for mobile users: they have small keyboards and some simpler
devices lack a mouse-like pointer. Network latency and page loading is an issue, even at optimal
network speeds. Not all devices will be able to support all of Mobile Web 3.0’s functions. And since your
content is being delivered directly onto handsets, you can take advantage of dialing and messaging
functions which you wouldn’t typically find on a PC.
As you think about revising your pages to be appealing under Mobile Web 3.0, you’ll discover
the process is not as difficult as it may seem. In fact, it may even give you ideas on how to streamline
and add functionality to your standard web designs. This chapter will review major factors in Mobile
Web 3.0 design, and give brief recommendations on how to handle these factors, and where to find
further information.
Once you’ve assessed the differences between the mobile and PC mediums, you will have to
decide whether to adapt your existing pages to style themselves for display on Mobile Web 3.0 devices,
or if you want to create separate pages and sites specifically for mobile users. We’ll go over the pros and
cons of each option so you can combine it with what you know about mobile development and your
own site to make your design decisions.
Overview
This chapter will discuss general design considerations for the Mobile Web 3.0, including
 The Viewport and User-Selected Views
 The variety of screen sizes
 Navigation and Data Entry
 Network performance
 Varied handset capabilities and Mobile Web 3.0 tiers of functionality
 Unique capabilities of handheld devices, as related to web development
 Pros and cons of adapting an existing site for Mobile Web 3.0

Verizon Wireless
6
 Pros and cons of creating new pages specifically for Mobile Web 3.0
The Viewport and User-Selected Views
The physical size of a mobile handheld device’s screen is not the same size as the windows of its
browser. It will be large and wide, like a desktop browser window. However, it is also at a higher
resolution. The result is, that without modification, web pages will usually sprawl outside of the physical
mobile handheld window.
For instance, a mobile handheld device may have a physical window size of 176 by 220 pixels.
Though the standard viewport size may vary by browser vendor, a typical viewport size is 800 by 600
pixels. The rendered web window is smaller than it would be on a PC desktop, thanks to the high
resolution of the mobile device, but it’s still larger than the window itself.
Mobile browser viewport in relationship to mobile device window
For instance, here you can see the virtual page that the browser renders behind the physical
window of a handheld device. As you develop for the mobile platform, you need to keep in mind the
differences between the viewport—the default window size of the Mobile Web 3.0 browser—and the
physical display size on a mobile handheld device.
Additionally, Mobile Web 3.0 may have options to override the viewport and control how pages
lay out on their handheld device. Not all Mobile Web 3.0 will have access to these options, though
Mobile Web 3.0 supports them all. The layout options built in to Mobile Web 3.0 including
Desktop layout mode. As shown above, this standard mode lays out your page in the browser
viewport. It is the default layout for Mobile Web 3.0
Page Overview Mode. This mode zooms out of your page so users can get an overview of it.
With a marquee, they select the section they want to read, and selectively zoom in on it.

Verizon Wireless
7
Page Overview Mode. Note the square marquee to select content to view more
closely.
Fit to Screen Mode. This mode fits the page to the mobile handheld device window width.
Text Wrap to Screen Width. This mode fits text to fit within the handheld device’s windows
width, but allows images and other elements to keep their regular dimensions.
Text Only View. This mode shows only the text on a page.
Display Size Considerations
You’ll find Mobile Web 3.0 handset devices come in a wide range of sizes and form factors, all
considerably smaller than desktops, and at varying levels of resolution. Additionally, newer devices can
switch between landscape and portrait orientations. For your designs to work consistently and to be
accessible on mobile devices, you’ll want pages to fit the physical window, not necessarily the viewport.
As a result, you need to make sure your web designs are flexible and designed for smaller windows.
1. Modularize Your Design
Unless you have a very simple one-column design, you should think of your page design as a
collection of sections instead of as a single block. Divide your page elements into separate parts
which you can set up to rearrange themselves for different configurations, including on-the-fly
orientation changes.
2. Implement Top-Down Navigation
On the mobile platform, visitors will not be able to take in your site, so set up anchors for each
section, and a menu bar which lets users quickly move to that section of your page or site.
3. Group screen size configurations into three or four ranges
When it comes to screen size, you mostly only need to worry about width, since users on any
platform are used to scrolling down a page. The low end of Mobile Web 3.0 device widths is a
width of about 176 pixels, and the high end is an 800 pixel width. One suggested set of ranges is:
Small 176 to 220 pixels

Verizon Wireless
8
Medium 240 to 320 pixels
Large 360 to 480 pixels
Mini-desktop 600 to 800 pixels
Both
Chapter 3, “Adapting an Existing Site for the Mobile Platform,” and Chapter 5, “Creating
Effective Mobile Pages” will give you specific tips for creating separate pages or style sheets for different
screen size ranges.
Keyboard & Mousing Constraints
Mobile Web 3.0 runs on both touchscreen and keypad handsets. In either case, any data entry
has to be done with non-standard small keyboards, some little more than numeric keypads doing double
duty. Furthermore, some simpler handsets may even lack a mouse equivalent, so users have to tab
between links or over to scroll bars in order to see your page. A few simple design considerations can
improve your page accessibility.
1. Limit the number of links on any page and use accesskey
Some mobile web users may need to jump from link to link to navigate your page. To make your
pages more accessible to all users, implement the accesskey attribute (available both in HTML
and CSS) so users can select a link and click a link with their keypad.
2. Streamline data entry with autocomplete and preformatting input
Mobile Web 3.0 has a built-in autocomplete function, which will offer users a choice of
previously-used text entries. You can further streamline and improve their data entry by
applying –wap-input-format attribute to your data entry fields. The –wap-input-format will set
fields to only accept input as numeric or alphabetic; it may also be used to specify the number of
characters to be entered in any field.
3. Provide alternatives to text-based data entry
Mobile handset devices are primarily designed for calling and sending short texts. Consider
putting in commands for calling or texting their information to you. Or, if possible, instead of
requiring data entry, let users choose likely answers from a drop-down menu or a set of
checkboxes.
In Chapter 5, “Creating Effective Mobile Pages,” you will find you recommendations on
designing your pages for improved accessibility and navigation on mobile handheld devices.
Network Latency and Page Load Times
You can expect a throughput of about 400kpbs via the VZW network, but even in the best
circumstances, your pages may have some latency issues, depending on the handheld device’s amount
of available resources, the size of your page, and traffic issues. You can make design changes on your
page and your server to improve this issue.

Verizon Wireless
9
1. Keep It Small and Simple
Smaller, shorter pages will always look and work better on small screens. If you have images or
video, don’t scale them in HTML: resize them to their target size before you place them in your
page. If you have many elements on your page, it may work better as a series of separate pages
rather than as one large one.
2. Cache your pages wisely
Set up your CSS styles and JavaScript as external files: they’ll cache into device memory and be
available more readily than they might if they were inline or embedded. You can also set
elements to expire in the future, so the server won’t request updated versions when they’re not
needed.
3. Reduce or eliminate page updates
You may have your pages set up to refresh themselves after a set period of time. While this
keeps your information timely, it can also impact your page’s accessibility in lower bandwidth
situations. Eliminate your refresh rate, or set a longer time between updates.
4. Aggregate Your Content
Instead of having your page elements deliver themselves separately, you can bundle them
together in a single package. This may make the initial load of your page longer, but it may run
more smoothly when it doesn’t have to call back to the server.
This document discusses simple page design in Chapter 3, “Adapting an Existing Site for the
Mobile Platform,” and Chapter 5, “Creating Effective Mobile Pages.” Chapter 7, “Optimizing Your
Mobile Site for Performance” goes into further depth on this issue.
Capability Differences
There’s a wide range of features and functionality among the handsets which will have Mobile
Web 3.0 installed. They may range from entry-level cell phones which won’t have the resources and
functionality to play audio or video, to powerful PDAs (personal digital assistants) which are no less than
miniaturized mobile computers.
VZW has set up three tiers of functionality: basic, full, and enhanced. Each of these tiers
describe the minimum level of functionality you can expect on a device with that tier of Mobile Web 3.0.
Mostly, the tiers vary in their levels of multimedia support. Handsets with the basic tier of functionality
are not required to be able to play audio, video or animation besides GIF animations. Handsets with the
full level of functionality have to be able to play audio and short videos and animations. Handsets with
the enhanced tier of functionality are capable of playing longer and more complex audio and video files
including Shockwave animations and Flash Video files. The limitations are not absolute: for instance, a
device with Mobile Web 3.0 at the basic tier may still be able to play some web audio formats, even if it
cannot support video.
There are several strategies you may choose to follow, such as
Design for the Basic Tier

Verizon Wireless
10
If your pages don’t include audio or video, you can target your designs to the minimum
requirements of the basic tier. Your HTML, scripts and CSS will be supported, and you can take
advantage of unique handset functionality. You’ll find details on what Mobile Web 3.0 supports
at each tier in the document, “Mobile Web 3.0 Technical Notes.”
Create Separate Styles or Pages Targeting Handset Capabilities
You can set up pages specifically geared to different handset capabilities. This way you can reach
the broadest audience, but also build rich pages which may only work on high-end sets today,
but continue to be relevant as handsets become generally more capable. You may need to set
up scripts to read HTTP request headers for handset information in order to deliver device-
specific pages. You’ll find information on reading HTTP request headers in Chapter 4, “Reading
User Agent Profiles.”
Design Multimedia-Rich Sites
If you have a multimedia-dependent site, such as one with Flash-based pages, Mobile Web 3.0
handheld devices can support them at the enhanced tier. As you would with your desktop
designs, you can give users a link to a simpler page. You can also expect Mobile Web 3.0 to
adapt your pages to the device, even if features are unavailable, with the content optimization
feature.
The Communication Advantage
In terms of communication functionality, the mobile web platform is typically less passive than
the desktop medium. If you set up your web page correctly, handset users can call you by simply
“clicking” on a link, an option which may be easier for them that searching your site. Though it may not
be as easy for them, they can also send you short messages (to your device or email program) with their
built-in text-messaging service. Take advantage of this!
1. Make your contact information prominent
It may be easier for users to call you for information than to browse through your site. Make
your contact information readily accessible and prominent, especially for mobile users. Be sure
to include a uniform resource identifier (URI) in your phone number so Mobile Web 3.0 users
can call or text you directly from your page.
2. Make all you contact information activatable
Mobile Web 3.0 supports several URI schemes that let your pages integrate with handset
functionality. Include them any time you have a phone number or email address on your page.
The Development Dilemma: Adapt or Diverge?
Though it runs on a different medium, the Mobile Web 3.0 browser is much like a typical
desktop browser. You can expect your HTML pages to run natively, complete with standard scripts and
styling. On more powerful handsets, you can deliver web-based music, video, and animations. If you
make no changes to your existing pages, you can still expect them to be more accessible and appealing

Verizon Wireless
11
to VZW users, thanks to VZW content optimization, and options users have to modify your page, such as
fitting it to the screen, zooming in on it, or setting it to display only its text content.
Why Change At All?
So if Mobile Web 3.0 can largely do what a desktop browser can do, why do you want to alter
your pages at all? Well, the devices that will be running Mobile Web 3.0 are still small, in form factor,
memory, processing power, and speed, especially compared to desktops. Mobile users will appreciate
designs that anticipate their first impression on small screens, and forms that take into account that
data entry isn’t as fast and simple as on a PC. Furthermore, while VZW subscribers can now watch a
music video in their browser, it’s still a bit much to expect them to be able to log in and play your
graphics-heavy multi-user online game in a satisfactory way.
On the other hand, the mobile handheld platform is primed for interaction in a way that desktop
PCs are not. When customers can contact you with a tap on a button, there’s more likely to do so, and a
smart designer can take advantage of this.
Pros and Cons of Adapting with Style Sheets
There are quite a few advantages to having a default site that can dynamically adapt itself
according to the medium reading it, especially if your pages don’t include a lot of multimedia content:
 You only need to maintain and update a single set of pages
 The look of your site will be consistent across different platforms
There are a few disadvantages, especially if you have large pages:
 Hidden elements on your page will still load, compromising page performance
 Increased cross-platform traffic may stress your server
 Your pages are less focused on unique Mobile Web 3.0 advantages
You will find more information on setting up alternative style sheets for Mobile Web 3.0 devices
in Chapter 3, “Adapting an Existing Site for the Mobile Platform.”
Pros and Cons of Separate Mobile-Optimized Pages
Even though it’s harder to maintain several pages simultaneously, you may decide to set up
separate pages for handheld users. The primary advantages of doing so are:
 Your pages will be smaller to begin with
 You can focus on unique Mobile Web 3.0 features
 You can balance your server load among platforms and levels of device functionality
There are a few disadvantages, especially if you are short on staff or time, such as:
 Content and styling may not be consistent across platforms

Verizon Wireless
12
 One platform may be deprecated in how frequently it is updated
You’ll find more information on the custom development process and reading user agent profile
information in Chapter 4, “Creating Fully Mobile-Optimized Pages and Sites.”
Mix and Match
For the best results, you may consider a combination of the two options in order to deliver the
best design to each device without creating an unmanageable workload. For instance, you may have a
mobile site that opens with your actively-linked contact information, and bookmarks to the key portions
of your site; but which uses CSS style sheets to make the same page size differently according to screen
width. Or you may set up a bare-bones version of your page for Mobile Web 3.0 phones at the basic tier
of functionality, but use style sheets to fit your multimedia content to other Mobile Web 3.0 devices.

Verizon Wireless
13
Chapter 3
Adapting an Existing Site for the Mobile
Platform
Since Mobile Web 3.0 supports most web standards, you can adapt your page so that it works equally
well on desktops and mobile handheld devices by using CSS (Cascading Style Sheets) to set up a more
flexible page design that can suit itself to a variety of screen sizes and device capabilities. This makes it
easy to reach mobile users with minimal effort, since you only need to maintain and update a single site.
And when you set up your pages so that styles and scripts load externally, you’ll speed up their
deliverability on all platforms.
Overview
This chapter focuses on using CSS to adapt existing desktop pages to Mobile Web 3.0. Topics to
be covered include
 An introduction to CSS: The key to simple site adaptation
 Preparing your site for adaptation
 Designing your mobile style sheet for design flexibility
 Using multiple external style sheets for different devices
Introducing CSS: The Key to Simple Site Adaptation
CSS is used to define the design aspects of a page. For instance, you can create CSS styles to
describe what different types of text should look like on your page, including font choices, color and size.
It lets you set up a more flexible design, which is particularly useful on the mobile platform, by letting
you group your page into sections like boxes. Within those boxes, you can use relative positioning and
sizing to make them conform to the window they’re in. You can hide parts of your page depending on
what kind of medium it’s on. And its ability to reside in a separate file from your content page makes it
easy to keep your site styles consistent across platforms, more maintainable, and faster to load.
Separating Style from Structure
Most of the information you’re delivering to desktop browsers is the same information you
want to deliver to Mobile Web 3.0 users. You don’t need to change the actual content, which is why CSS
is so effective at letting you deliver the same content to different views. What you should do is to
separate the content into different groups, and prioritize the content for different platforms. For

Verizon Wireless
14
instance, if only one section of your page is visible to first-time visitors, what would it be? What would
you want mobile users to see first: your contact information or a compelling introductory animation?
Though Mobile Web 3.0 pages are just like desktop pages, it may help to think of them in the
historic concept of mobile internet access. Back in the day, mobile web pages were straight text in short
pages, and even today, if they get nothing else from you, that’s what they’ll see. Think of your present-
day site in the same context, except that those little text pages can play with each other as well as
multimedia on the same screen, and top the whole thing with styling, and you understand how CSS’
separation of text from style helps you build multi-platform pages from the most basic to the most
complex.
IDs and Classes
Your default design will be the attributes you’ve set for your base attributes. A base selector
takes an (X)HTML tag and redefines some or all of its properties to style the whole element. For
instance, if all your paragraph text will be white, you set the p tag to white:
P {
Color:#FFFFFF
}
But if you only had base selectors, your page would either be very simple, or you’d be using
HTML tags constantly to make changes inline. Luckily, you can add to your base selector styles with ID
and class selectors. You can set them up in your style sheet and apply them to your (X)HTML elements
throughout your page for greater styling control.
There’s understandable confusion between ID and class, since browsers aren’t consistent in
enforcing their definitions. Both may be used to create styles for an (X)HTML attribute, but you should
only use an ID once per element per page.
In some cases, a browser will only parse the first use of an ID, leaving other elements to base
and default styling Also, If you use Javascript to access elements referred to by the same ID, it will only
apply to the first instance of the ID: so it’s best to have just one.
The next key part of your CSS styles will be ID selectors, which are supposed to be for unique
identifiers to styles on your page. For instance, you may want all your headlines to be in bold Times-
Roman font. You could set an ID with this style like this
#headline {font-size: medium
font-family:times new roman, times, serif}
You may especially want to use the ID selector to name divisions (<div>) especially if you are designed
for mobile devices which do not support CSS3. Javascript can locate sections of your page with the

Verizon Wireless
15
.getElementbyID command, which will be useful for creating scripts to have your pages style themselves
to screen widths.
Classes are the most flexible of CSS styles, and can be used repeatedly within a page. Use classes
to control elements that belong to a group, for temporary items, and to add attributes to an ID.
Inline, Page and External CSS
Your default design
In particular, the fact that, as its name says, CSS cascades, is what makes CSS work so well to
deliver the same content to different platforms in unique medium-specific ways. Put more simply: you
have a default style which applies to all styles; if you want it to change, you only have to change part of
the default style, not redefine a whole new style.
The default styles for elements of your design are called IDs. For any variations on these ID
styles, you have classes, which are exactly like the ID, except where they’re different.
For instance, you may have a simple page where the main body section is black text on a gray
column:
#main {
background-color:#999999;
font-family:"trebuchet ms" , arial, sans-serif;
width:540px;
padding:1px;
}
But you want to make this column narrower with a white background for better readability on
small handheld devices. You can set up a style for this which will override the background color and
padding, but everything else remains the same:

Verizon Wireless
16
.mobilebackground {
background-color:#FFFFFF;
width:device-width
padding:0px
}
You can use CSS to turn the background white when a mobile device is reading the page, i.e.
@media=small-screen class=.mobilebackground
Note that the font and content has remained the same.
You may also read HTTP request headers and Javascript for defining style changes, especially if
you are delivering pages to a Mobile Web 3.0 device that does not fully support CSS3.
The media attribute
The media attribute in CSS deserves special note. Among its functions is the ability to recognize
whether the platform on which your page is being viewed is mobile or desktop. You can then specify
styling to the platform. Or you can use the display attribute to hide the section, which can be useful if
you want to simplify your design for mobile screens and have only a few elements that won’t work.
For instance, if you have a restaurant web site, you may have a multiple column layout with a
brag box that has a video of your chef, and quotes from satisfied customers. Since this will make your

Verizon Wireless
17
site too busy to work on small screens, you may hide it. Instead, you may want to display a section with
an active link to dial your restaurant’s phone number.
You can hide the brag box from mobile users by inserting this into your page or into the
section’s styling:
<media=”mobile, handheld” display=none>
You can set up the section with your phone number so that it will not show up to desktop users
(but will for mobile platform users) like this:
<media=”screen, print” display=none>
Some browsers (including some implementations of Mobile Web 3.0) support CSS3 in which
case the media attribute for mobile platform devices reads as:
@media=small-screen
Unfortunately, browsers which use CSS3 may deprecate the CSS2 media attribute, so if you are
designing for multiple browsers, you may need to use both CSS2 and CSS3 descriptions.
CSS Reference
This guide assumes you have a basic understanding of CSS, and will focus only on the use of CSS
as related to mobile and multi-platform page design. If you are not familiar with CSS already, check out a
guide like CSS Basics or CSS from the Ground Up. To understand the flexibility of designs possible with
CSS, check out CSS Zen Garden.
Preparing Your Site for Adaptation

Verizon Wireless
18
The previous chapter has given you design recommendations on making your pages more
flexible so that they can work on both desktop and mobile platforms. However, there are several
advantages to creating and setting up pages specifically for mobile handheld devices, even if you also
have pages for desktop users. Doing so makes it easier to target handheld device capabilities specifically:
for instance, you could have a mobile site with separate pages for Flash-capable devices, as well as for
non-Flash devices. You don’t have to hide elements of a page for showing a cleaner design, so your
pages may load more quickly. And you can keep track of your traffic more specifically by having separate
pages for different mediums and devices.
The following sections will cover more advanced topics in designing pages for Mobile Web 3.0,
such as reading and using device profile information and creating pages designed specifically for mobile
web usage, complete with navigation and data entry concerns. We’ll also include information on
inserting commands to let users contact your directly from your web page, and more advanced methods
to make sure your pages load quickly on mobile devices.
Chapter 4
Managing User Profile Information
There are several aspects to setting up a site specifically for Mobile Web 3.0 devices. On the
server end, you’ll be running scripts in order to gather user profile information so that you can deliver
the proper pages to their device. You have to create simple, but effective designs that cater to different
ranges of screen widths and device capabilities. And as part of any mobile design, you have to take into
account navigation and data entry differences between the mobile and desktop platforms.
This chapter will cover:
 Managing User Profiles and Data
 Information in the HTTP Request Header, including
 The User Agent Profile
 The User Agent Profile Specification (UAProf)
 The User Identification Key
 The Brew Product ID Number
 Cookies
Reading User Profiles and Data
When the VZW server requests a page from you, it will send you an HTTP request header. This
header includes several lines of information which will give you information about the user’s handheld

Verizon Wireless
19
device and an anonymous ID for the user. You can use this information to target your pages to the
handset size and capability, as well as keeping track of page hits and user statistics.
Reading the HTTP Request Header
How you access your information depends on your server configuration: typically you will do so
with a server-side scripts like ASP, Perl, PHP, or Java Servlet. In general, you need to insert the name of
the HTTP header from which you want information. Here are example scripts in PHP (typically used on
Apache servers) and ASP (typically used on IIS servers).
PHP puts the HTTP header information into its $_Server array. If you are using PHP, your code
from retrieving relevant HTTP Request Header information might look like this:
$user_agent = $_server["http_user_agent"];
$x_wap_profile = $_server["http_x_wap_profile"];
$userip = $_server["http_userip"];
$xid = $_server["xid"];
$accept = $_Server["http_accept"];
$accept_charset = $_server["http_accept_charset"];
$accept_encoding = $_server["http_accept_encoding"];
$accept_language = $_server["http_accept_language"];
$x_pid = $_SERVER["http_x_pid"];
In ASP, you can use the ServerVariables collection of the Request object to retrieve the value of
HTTP headers. If you use Jscript, the code for reading Mobile Web 3.0 headers will look like this:
var user_agent = Request.ServerVariables("http_user_agent");
var x_wap_profile = Request.ServerVariables("http_x_wap_profile");
var userip = Request.ServerVariables("http_userip");
var xid = Request.ServerVariables("http_xid");
var accept = Request.ServerVariables("http_accept");
var accept_charset = Request.ServerVariables("http_accept_charset");
var accept_encoding = Request.ServerVariables("http_accept-encoding");
var accept_language = Request.ServerVariables("http_accept_language");
var x_PID = Request.ServerVariables("http_x_pid");
The HTTP Request Header
When a VZW subscriber wants to access your web site, you server will receive an HTTP Request
header with several fields of information. The following table shows the headers which may be useful
for you in identifying devices, device capabilities, and user IDs. We give your further information about
each of these headers afterwards.
Header ID Example

Verizon Wireless
20
User-Agent Opera Mini/4.2 (compatible; BREW 3.1.5; en) 176x220 LG VX7000
X-Wap Profile http://uaprof.vtext.com/lg/vx9600/vx9600.xml
Userip 97.183.1.131
Xid AB12345678ABCDEF1A12A123456A12345@VzW
Accept: Text/html.application/xhtml+sml,*/*
Accept-Charset Utf-8, utf-16, us-ascii, iso-8859-1
Accept-Encoding Gzip, deflate
Accept-Language En; q-10, en, *, q=0.5
x-PID 2374
The User-Agent Profile
Header ID Example
User-Agent Opera Mini/4.2 (compatible; BREW 3.15; en) 176x220 LG VX7000
The User Agent Profile includes a sequence of handset and browser information. With Mobile
Web 3.0, the information comes in 5 sections, like this:
Section Example Notes
1 Opera Mini/4.2 (compatible; BREW 3.1.5; en) Browser information:
Browser name/browser version number
(compatible; application operating system;
language)
2 176 x 220 Screen size (width x height) in pixels
3 LG Handset manufacturer
4 VX7000 Handset model
VZW may add a fifth section of information, though it does not currently do so. These sections are not
uniquely delimited from one another. You can set up a script to search the User-Agent header for
relevant information, such as screen size.
The User Agent Profile Specification (UAProf)
Header ID Example
X-Wap Profile http://uaprof.vtext.com/lg/vx9600/vx9600.xml
The User Agent Profile (UAProf) specification is a standard way of getting information about the
user’s handset, including its manufacturer, model, screen size, and capabilities. Handset manufacturers
and telecommunications companies, including Verizon, voluntarily provide this information and make it
publically available for mobile web developers.

Verizon Wireless
21
This information comes in the form of an xml file available on the web. If you are unfamiliar with
UAProf, see the Open Mobile Alliance’s specification at
http://www.openmobilealliance.org/tech/affiliates/wap/wap-248-uaprof-20011020-a.pdf
User IP
Header ID Example
Userip 97.183.1.131
This is the user IP as provided by the Mobile Web 3.0 server. Unfortunately, this address cannot
be used to identify repeat visits, since Mobile Web 3.0 have dynamic IP address assigned whenever they
access the web. Instead, use the XID header to keep track of repeat visits.
XID
Header ID Example
XID AB12345678ABCDEF1A12A123456A12345@VzW
This is an anonymized identification number for each Mobile Web 3.0 device. It consists of a
string of 33 letters and numbers followed by “@VzW”. It is not an email address.
Accept
Header ID Example
Accept Text/html.application/xhtml+sml,*/*
This header shows the content types the device will accept. It can be useful for assessing
whether a device supports audio or video, and which level of quality of this content type it can support.
Accept-Charset
Header ID Example
Accept-Charset Utf-8, utf-16, us-ascii, iso-8859-1
This header shows the character sets the device will accept, and may be useful if you have pages
in several different languages. Note that the range of supported fonts may still be limited.
Accept-Encoding
Header ID Example
Accept-Encoding Gzip, deflate
This header shows which compression encodings the handset supports. Most handsets will
support gzip and deflate, encodings which may come in useful if you want to compress your pages for
faster throughput.
BREW Product ID
Header ID Example
x-PID 2374
This is a number assigned by Qualcomm to each firmware version of a handset. While it is
typically used to help assign appropriate BREW (Binary Runtime Environment for Wireless) applications
for different phones, you may also find it useful in identifying the mobile device accessing your site. It is
typically a four-digit number.

Verizon Wireless
22
Cookies
Mobile Web 3.0 supports HTTP cookies, so you can use them for purposes such as
authentication or shopping cart contents.

Verizon Wireless
23
Chapter 5
Creating Effective Mobile Pages
When you’re designing pages specifically for Mobile Web 3.0, you have several factors to
consider in putting together your design. You’ll want to be able to fit your design to the small (and
variable) screen form factor. You’ll want to take into consideration the features and resources of mobile
handset devices, which can vary widely among models. And you’ll have to remember that navigation
and data entry may be constrained due to the interface restrictions of mobile devices.
 Creating Effective Mobile Layouts
 Navigation Considerations
 Data Entry Considerations
 Optimizing your Pages for Widths and Orientations
 Device Tier Support
Start with a Simple Layout
Keeping it simple is always a good idea, but it’s particularly important on the mobile platform.
First of all, pages need to focus on accessibility rather than intricate layouts. A desktop page that
attracts with intriguing images and informational pull-outs can look unpleasantly cluttered on a mobile
handset.
Before you even start work on your mobile site, you should figure out how to organize your
pages into a logical structure, because being able to navigate your page or site is as important to mobile
users as the page’s look itself.
If you choose to use backgrounds, use them sparingly, and keep in mind that large images, such
as photographic backgrounds, will have less impact on a small screen, but will increase the weight of the
page.
You can always add to your design, and you should take advantage of navigation links to make
Mobile Web 3.0 users aware of the content on the rest of your page, and make it easier to them to get
to it.
Navigation
Easy navigation and well-named links are key to successful mobile web page design. Your mobile
pages are smaller than they’d be on a desktop; moreover, it’s harder for users to move around.

Verizon Wireless
24
Keypad Interface
Many Mobile Web 3.0 users will be navigating your pages with their telephonic keypads. These keypads
generally have a button with right, left, up and down arrows to help in navigation. There may be a
scrolling or mousing function built into these navigation buttons, but not always. If there is no mouse,
the users have to navigate your page by hopping through links or toggling over to a scroll bar. For data
entry, a keypad user may have to press a key multiple times to enter a single character.
Touchscreen interface
Some mobile handheld devices have touchscreens, which can be more intuitive to use than a keypad.
But just as with keypad and button navigation, scrolling around a page can be tedious. When it comes to
data entry, many touchscreen devices will produce an onscreen keyboard, which may obscure your page
and which can also be difficult to use quickly and effectively, compared to a regular full-size keyboard.
If you have a page with more than two important sections, you can make your page more
accessible by setting up a navigation menu that lists sections of your page. Likewise, if you’ve set up
your site as one with many short pages, you may want to create a navigation menu to other pages of
your site. Group your sections and give them clear heading names. You’ll want only a few headings,
because your menus should be short and concise on the mobile platform. If you find yourself with too
many headings, it may be a hint that you should set up separate linked pages instead of one long one; or
to group your site pages into categories.
Accesskey
The accesskey attribute, which you can insert into either (X)HTML and CSS code, can make your
pages easier to use for mobile internet users with a keypad interface.
Once you set up a page with the accesskey property in your code, users can jump directly to an
element of your web page using the numbers on their keypad. For example, Verizon’s Mobile Web 2.0
main site uses accesskey to make it easier for subscribers to get to different sections of their portal:
Accesskey as used in VZW’s Mobile Web 2.0 portal.

Verizon Wireless
25
Mobile Web 3.0 supports accesskey attributes directly. If you add accesskey to an item, Mobile
Web 3.0 users can select it simply by clicking the key with the corresponding number or letter.
You can use accesskey in your navigation bar, or for fields in your form so that keypad users
don’t have to hop across links to get to one they want. Accesskey attributes may be the digits on the
keypad, or one of the letters on the keypad. Because of typical keypad design, you’re limited to 10
numbers or 8 letters, and if you use letters you can only use one of the 3 letters on each button. For
instance if you have an Address field that can be selected with the A key, you cannot have a Company
field as well, because a, b, and c are on the same keypad button, and Mobile Web 3.0 will only take the
user to the first instance of the key.
To set up accesskey, simply apply it as an attribute. For instance, you may have a menu for your
page like this:
<div id="menu">
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">News</a></li>
<li><a href="#">Blog</a></li>
<li><a href="#">Gallery</a></li>
<li><a href="#">Contact</a></li>
</ul>
</div>
You can apply accesskey attributes to it with it in HTML like this:
<div id="menu">
<ul>
<li><a href="#home" accesskey=1>Home<em> (1)</em></a>
<li><a href="#news" accesskey=2>News<em> (2)</em></a></li>
<li><a href="#blog" accesskey=3>Blog<em> (3)</em></a></li>
<li><a href="#gallery" accesskey=4>Gallery <em>(4)</em></a></li>
<li><a href="#contact" accesskey=5>Contact <em> (5)</em></a></li>
</ul>
In this example, we’ve also added the accesskey number to the text to make users aware of the
option.

Verizon Wireless
26
Data Entry Forms
Data entry forms have always been somewhat of a thorny issue in mobile internet design, but
you can set some worries aside with Mobile Web 3.0. Your HTML/CSS forms will work as designed:
Mobile Web 3.0 supports all input types, from text fields to radio buttons. Furthermore, you can count
on some built-in features to improve accessibility, such as the “autocomplete” feature which
automatically fills in forms with previously used words. Mobile Web 3.0 also supports –wap-input-
format, a WCSS (Wireless CSS) attribute which conforms data entry appropriately for the form. For
instance, if you have a field for a phone number, you can set up the field so that only numbers will go
into it, and limit it to 10 characters. You can also set up name fields to automatically alphabetize the first
letter of the name, followed by all lowercase letters, of unlimited length.
One of the main constraints to keep in mind is that your forms appear smaller, and in smaller
windows. Mobile users have data-entry constraints: without a full-size keyboard, Mobile Web 3.0 users
have to tap in their information. And network latency may require waits for loading lengthy forms and
submitting data.
As with overall mobile internet design, the best option is to keep your forms short and simple:
 Keep the number of fields in your form to a minimum.
The difficulty of loading and filling in too many fields may have mobile users opting out
altogether. You can easily send follow-up inquiries via SMS/text.
 Keep fields short
Short fields will work in any screen size, with any user setting; too-long fields may sprawl
over the edge of the window, and can be disorienting. Users can still enter data that’s longer
than the field size: their entry will simply scroll inside the field.
The Form of your Forms: Tables, Paragraphs, or Definitions
Tables are a tried and true method for forms. If you have complicated forms, such as forms with
levels of hierarchy, there’s almost no alternative to this method. However, for mobile internet
development, they often lack the flexibility needed to work best on a variety of screen widths. Unless
you create multiple forms for different screen widths, your form won’t be able to give users the best
possible amount of data entry room.

Verizon Wireless
27
Table-based form layout on a wide mobile screen
You may opt for a more free-form paragraph and break form layout, and while this gives you
more flexibility, especially on narrow screens, labels and fields will be misaligned unless you apply
hidden (and extraneous) spacing elements.
Non-table based form layout on mobile screen
One option you might consider is the little-known definition list. In this case, you set up your
form as a <fieldset> and use definition term <dt> for the “column” in which you have lables, and
definition definition <dd> for the “column” in which you have fields. You’ll also want to set up styles for
your <dt> and <dd> “columns” with a margin of 0. You should also set a fixed width (i.e. 150px), float left

Verizon Wireless
28
and clear both for your <dt> “column.” This will line up your labels and fields consistently on wider
screens, or have them arrange themselves vertically on narrower screens.
For example:
<form action="" method="post" id="sendquestion">
<fieldset>
<legend>Definition List Layout Form Example</legend>
<dl><!-Definition List-!>
<dt><!-Definition Term-use for labels-!>
<label for="subject">Subject</label>
</dt>
<dd><!-Definition Definition-use for fields-!>
<select name="subject" id="subject">
<option value="">Select</option>
<option value="Option 1">Option 1</option>
<option value="Option 2">Option 2</option>
</select>
</dd>
<dt>
<label for "name">Name</label>
</dt>
<dd>
<input type="text" style="-wap-input-format:A*a" name="name" id=="name" />
</dd>
<dt>
<label for="email">Email</label>
</dt>
<dd>
<input type-"text" style="-wap-input-format:*a" name="email" id="email" />
</dd>
<dt>
<label for="phone">Phone number</label>
</dt>
<dd>
<input type-"text" style="-wap-input-format:NNNNNNNNNN" name="phone" id="phone" />
</dd>
<dt>
<label for"message">Message</label>
</dt>
<dd>
<textarea name="message"" id="message" rows="11" cols="30"></textarea>
</dd>
</dl>
</fieldset>

Verizon Wireless
29
<input type="submit" value="Send" />
With these CSS styles for the <dt> and <dd> columns:
fieldset dt {
float:left;
clear:both;
width:150px;
padding:5px;
margin:0px;
}
fieldset dd {
margin:0px;
padding:5px;
}
This simple sample code looks like this on narrow Mobile Web 3.0 screens:
Definition list form on narrow Mobile Web 3.0 screen
And like this on wider Mobile Web 3.0 screens:

Verizon Wireless
30
Definition List Form on wide Mobile Web 3.0 screen
Using the –Wap-Input-Format Command
Besides supported web standards, Mobile Web 3.0 also supports several WAP (Wireless
Application Protocol) standards which you can implement in your code to improve mobile user
accessibility. One of these is the -wap-input-format attribute from WCSS (Wireless CSS). This lets you
specify whether the type of characters (and optionally the number of characters) that should be entered
in a text field. As a result, if you have a number field, such as a telephone number field, Mobile Web 3.0
will only accept numbers as input; or if it is an alphabetic field, such as a name field, it will only recognize
key strokes as letters, and will automatically capitalize the name.
For instance, you may have a name field in your form like this:
<input type="text" name="first name" id=="name" />
Notice that in this case, the field has been set up with an ID. You can now set up a style for this
ID. In this case, the only attribute in the style is the –wap-input-format with an input mask which sets
the first letter that is entered as a capitalized alphabetic letter, followed my an unlimited number of
lowercase alphabetic letters:
#name {
-wap-input-format: "A*a"
}
With the –wap-input-format attribute you can limit the number of letters or numbers to be
entered to eliminate mistakes (such as extra digits) as well.
To use the –wap-input-format, you need to be familiar with its mask characters. They are

Verizon Wireless
31
Mask character Attribute
a Any lowercase letter or symbol
A Any uppercase letter or symbol
n Any number or symbol
N Any number
x Any lowercase letter, number or symbol
X Any uppercase letter, number or symbol
m Any lowercase character, which may be overridden with uppercase character
M Any uppercase character, which may be overridden with lowercase character
If you have a set number of characters, you can specify them by placing a mask character in
place of each character, i.e. for a 5-digit zip code, “-wap-input-format:NNNNN.”
If you want the number of characters to be unlimited, place an asterix (*) in front of the
character mask, i.e. *a for an unlimited number of lowercase non-numeric characters. However, you can
only use the asterix once in a –wap-input-format mask.
You can also insert characters like dashes or parentheses by putting them into the mask with a
backslash character in front of them. For instance, you might set up a phone number field like this:
<input type-"text" style="-wap-input-format:(NNN)NNN-NNNN">
In the above case, when the phone number is entered, it will automatically insert the parentheses and
dashes to make the number format itself.
If you don’t set a mask for the –wap-input-format, the default mask is *M, an unlimited number
of uppercase characters, which may be overridden.
Alternatives to Data Entry
Given that data entry is slow and awkward on mobile forms, you may consider giving your
visitors alternatives, such as menus and options instead of data entry fields. Or, since mobile handheld
devices are superior at other forms of communication, you may give users alternatives to straight text
entry, and let them call or text you instead.
The <select> element lets you create a drop-down menu. If you have a field which has several
likely answers, this is a more efficient way for users to answer than entering text. However, you have to
remember that you still have a small screen, so you need to keep the drop-down menu small as well. If
you would have more than 5 selections in your drop down menu, you may decide to group the choices
into categories. Or you make a short drop down menu with a built in scroller so users can scroll through
a list of choices.
If you know several standard answers, you may set up a few checkboxes or radio buttons for
users to choose from instead of having to enter text.
If you have available staff for answering telephone inquiries, such as salespeople, it may be
faster and easier to give Mobile Web 3.0 a phone number as an alternative to entering data. You’ll find

Verizon Wireless
32
information on setting up URIs so users can call you directly from your page in Chapter 6 “Implementing
Dialing, Messaging, and Other Handset Functionality.”
Optimizing for Widths and Orientation
Mobile Web 3.0 will be installed on handheld devices with a wide range of screen sizes, but
supporting this variety is not as complex as it sounds. You largely only have to worry about screen width,
since scrolling down is easier than scrolling in two directions. Next, you can group the screen widths into
a few categories and set up separate style sheets or pages for each category. The low end of Mobile
Web 3.0 device widths is a width of about 176 pixels, and the high end is an 800 pixel width. One
suggested set of ranges is:
Small 176 to 220 pixels
Medium 240 to 320 pixels
Large 360 to 480 pixels
Mini-desktop 600 to 800 pixels
Some devices may have two device widths, if they support orientation changes. For instance, a
LG VX9600 handheld device may have a 176 pixel width in portrait orientation, and a 240 pixel width in
landscape orientation. The page will refresh between orientations, but if you have separate pages and
styles for different ranges, users may see altered versions of the page. (If you have data that has to be
consistent, you may want to set up style sheets instead of alternative pages, see Chapter 3.)
Device Tier Support
Mobile Web 3.0 has their tiers of functionality, depending on the built-in and available resources
on the handheld devices running it. The tiers describe the minimum features you can expect on a device.
Mostly, the tiers differ in their level of multimedia support. For instance, one handheld device may be
described as having Mobile Web 3.0 at the basic tier because it’s not fast enough to support streaming
multimedia. But it may support non-streaming multimedia even though that is not required at that level.
The Enhanced Tier
The enhanced tier, which you’ll mostly find on the most powerful handsets, can support
streaming and non-streaming animations and video, including Shockwave and FLV, as well as music.
The Full Tier
The full tier, which you’ll typically find installed on high-end consumer devices, can also play
audio and video, though there may be limitations on the size of the files that can be supported.
The Basic Tier
The basic tier of Mobile Web 3.0 does not have to support audio or video, and it may have a less
flexible code parser, requiring you to conform to the rules of XML more strictly.

Verizon Wireless
33
Specifics on the minimum requirements for each tier are found in the document “Mobile Web
3.0 Technical Specifications.”
In any case, you can expect web standard functionality, and if you already have a slim site that
does not depend on multimedia, your pages will work at any tier. If you have multimedia-dependent
pages, be aware that not all Mobile Web 3.0 handheld devices may have the full resources to run them.
Developing for All Tiers
Developers with multimedia-dependent or rich sources may want to build alternative, less-rich
sites to reach the widest range of Mobile Web 3.0 uses. You can set up your server to read the HTTP
Request Header to read handheld device information and deliver your pages accordingly. Or you can
provide step-down links. For instance, if your site requires Flash, include a link to a simpler alternative
that doesn’t require it. For instance, if a video file turns out to be too large for one Mobile Web 3.0
device, set up your page so users can listen to just the audio instead. If a device can’t play a web-based
music file, you can use VZW’s Linkaways feature so users can get it and play it in a separate application
instead.

Verizon Wireless
34
Chapter 6:
Implementing Dialing, Messaging, and
Other Handset Functionality
One of the advantages of the mobile internet platform is that your users are primed to contact
you more readily. The same device that is serving up your pages for them to view is also typically their
main tool for calling and sending messages. Whenever possible, you should take advantage of this when
setting up your web site for Mobile Web 3.0, and create active communication links within your mobile
pages.
Mobile Web 3.0 lets you interface with the mobile handset hardware with Wireless Markup
Language (WML) or specific uniforms resource identifiers (URIs) for calling (tel:, wtai://wp/mc;+) and
text messaging (sms:). You may be familiar with URIs used on desktop PCs for calling (callto:) and
emailing (mailto:). These URIs do not typically work on Mobile Web 3.0 devices, unless a device is
specifically capable of the desktop function, as in the email function on the Blackberry series. You may
want to create separate pages or style sheets or pages for mobile and PC users if you want to implement
communication links on both mediums.
 Interfacing with the Handset Dialer using WTAI
 Interfacing with the Handset Dialer using the Tel: URI
 Interfacing with Text Messaging using the sms: URI
Interfacing with the Handset Dialer using WTAI
The most universally supported way of setting up a telephony link in mobile internet browsers is
with the WTAI (Wireless Telephony Application Interface) from the Wireless Markup Language(WML).
WML is supported in all Mobile Web 3.0 tiers. To use it create an anchor link with the wtai command in
it <a href ="wtai://wp/mc;+ followed by your contact number and ending quote like this:
<a href="wtai://wp/mc;+12015551234"> </a>
For example, you may have a contact section on your page like this:

Verizon Wireless
35
The code behind it might look like this:
<h2>Libri Miris Books</h2>
<h4>Animus opibusque parati </h4>
<p>Open 10 am to 7 pm PT <br />
<a href="wtai://wp/mc;+14155554567">Call us</a> at 415-555-4567</p>
Interfacing with the Handset Dialer using the Tel URI
Another way to make your contact information capable of being dialed with a click is to use the
tel: URI. The use it, set up an anchor link with the tel: URI followed by your phone number like this:
<a href=”tel:12015551234”></a>
For example, for the contact section shown above, your code might look like this:
<h2>Libri Miris Books</h2>
<h4>Animus opibusque parati </h4>
<p>Open 10 am to 7 pm PT <br />
<a href="tel:14155554567">Call us</a> at 415-555-4567</p>
Interfacing with Messaging using the SMS URI
Another way you can allow mobile internet users to contact you is via their text messaging
service. This is particularly convenient if you prefer to be contacted via email, since mobile handset
users can send text messages to your email address. To use it for emails, set up an anchor link with the
sms: URI followed by your email address like this:
<a href=”sms:myaddress@mydomain.com”></a>
To avoid confusion for mobile users, describe your link as a text message, even if you will be
receiving it in your email application, i.e.
<a href=”sms:support@company.com”></a>
The return address from Mobile Web 3.0 users will be their phone number at the domain
vtext.com. You can respond to this address from your email program and it will be received as a text
message by the Mobile Web 3.0 users.

Verizon Wireless
36
Typically, text messages are limited in size, so keep messages short. If not, you may find your
message is abruptly truncated, or delivered in several separate messages. If you include a URL in a text
message, a Mobile Web 3.0 user will be able to select it and launch it.

Verizon Wireless
37
Chapter 7
Optimizing Your Mobile Site for
Performance
Even the best networks will suffer from a certain degree of latency. On the Verizon network, you
can expect a throughput of 400kpbs, or better, on average. However, this may vary depending on the
complexity of your pages and network traffic.
There are several factors to take into account when optimizing a site for performance. Mostly it
relates to keeping your pages short and lightweight, and designing your site to reduce the number of
callbacks and requests between servers and devices.
 “Minifying” Your Pages
 Using Cache Wisely
 Callbacks
 Minimizing Total Page Requests
Less is Best
Typically, the very factor of screen size and resource restrictions will inspire designers to keep
their web pages straightforward and simple. But there are a few additional techniques you can use to
make sure your pages are as tight and trim as they could possibly be.
Gzip
Mobile Web 3.0 supports gzip compression. You may consider implementing this on your pages.
It can improve network latency, since your files arrive compressed and are expanded after they load .
To use gzip, you simply have to set up your server to do it. For instance, on an Apache server,
you can edit the .htaccess file to compress HTML files. On an IIS server, you can can go to the the Web
Site’s Properties>Service tab and check the boxes to compress files.
Minify code, scripts and styles
You may also choose to “minify” your code, scripts and styles, especially if you don’t expect that
you’ll need to modify them frequently. In essence, you remove all characters that aren’t absolutely
necessary for function, so that, for instance, a style which was set up like this:
#header h1 {
margin: 0px;

Verizon Wireless
38
padding: 0px 0px 0px 10px;
text-align: left;
color: #3399FF;
font-size: 3em;
text-transform: uppercase;
}
Will now look like this:
#header h1{margin:0;padding:0 0 0 10;text-align: left;color: #3399FF;font-
size: 3em;text-transform: uppercase;}
This can greatly shrink your pages, in some cases, by as much as half. On the other hand, this
greatly reduces readability, so it may not be as easy to change your code if you’re not used to the
minified style.
There are several free tools which can minify your code, scripts and CSS for you, which you can
find at Sourceforge.net and Google Code.
Minimize Image Size and Depth
Instead of placing images and other media files into your web page and then shrinking their
dimensions to fit, you should shrink the images to the size you want them to be before placing them.
Because unfortunately, when they’re resized within the browser, they still have the weight of the larger
image they’re based on. If you size your images (and video) to smaller dimensions beforehand, these
files will be as small as they look, and can load in more quickly.
You may also consider whether you need to have image with full color depth. While some
handheld screens can reproduce rich colors beautifully, many screens are more limited. In fact, some
screens are still black and white. So if your pages are getting heavy, you may want to take 32-bit color
images and try them in lower depths. If the difference in color depth doesn’t make your images look
considerably different on small screens, you may consider trading in color nuances for speed instead.
Replace Images with CSS
Typically some elements of a page, such as a logo, or masthead, will be placed in as a graphic
rather than text. There a several reasons why this is done, and in particular, it makes up for the fact that
fonts and styles are not universal among browsers or mediums. But if a Mobile Web 3.0 user has set her
browser to show text only, your logo or masthead will not appear at all. If you can replace any of these
images with text and CSS styling, you’ll improve accessibility and have a smaller, more loadable page.
For instance, instead of using roll-over images for, say, menu items, you may use text instead,
restyled and with a simpler graphic element behind the text.
Chris Coyier shows several techniques for using CSS to style text so that it looks like images on
his CSS Tricks site: http://css-tricks.com/nine-techniques-for-css-image-replacement/

Verizon Wireless
39
Use Your Cache Wisely
The more of your page that is cached into the mobile device’s memory, the more quickly your
page will load. If you’ve been following our guidelines already, you know that it’s best to store your CSS
styles and Javascripts as external files. This way, these frequently-referenced elements of your design,
are cached, ready to be accessed on the device, not from a remote server.
If you haven’t done so already, you should set up your pages so that your CSS style sheets and
Javascript reside on separate pages on your server. You can load them in for your page using a reference
tag in the header, like:
<link href="styles/basicstyles.css" rel="stylesheet" type="text/css" media="mobile, handheld" />
Limit Auto Refreshing & Redirection
Simple design choices which work for keeping pages up-to-date on the desktop are impractical
in the mobile internet space. For instance, you may have your page set up to refresh itself after a certain
amount of time has elapsed. While this can keep a news-oriented page up to date, it may make the
same page annoyingly slow as scrolling or reading is interrupted with a new page load.
Consider eliminating or reducing the frequency at which your page refreshes on the mobile
handheld platform.
For much of the same reason, avoid redirects. For instance, you may have a number of doman
names, redirected to the same main page. Instead of having Mobile Web 3.0 redirect (and thus reload)
your pages, you can take care of it on the server end by accessing user profile information (see Chapter
4) and delivering the device-appropriate page directly to the user.
Minimize Total Page Requests
Typically loading a page into a browser requires more than a single call and response between
servers. Modern web pages consist of several elements including external files, images, and multimedia
files. Instead of having these elements constantly running back and forth between your server and a
Mobile Web 3.0, you can opt to package them together with MIME/Multipart-Related. In essence,
instead of delivering several discrete files, you attach them to each other in the header, like attachments
to an email message, and they arrive as one unit on the user’s device. For instance, you may have only
18 elements on your page, but these can lead to 40 calls between servers and the device.
Your page will load in slower initially, but run faster subsequently, since all elements are loaded.
You may consider this if you have a page with many external files.
Mobile Web 3.0 supports the MIME/Multipart-Related standard, as defined in the Network
Working Group’s RFC2387. (http://tools.ietf.org/html/rfc2387).

Verizon Wireless
40

Developing Pages for Mobile Web 3 2-15-09

Recommended

Recommended

More Related Content

What's hot

What's hot (8)

Similar to Developing Pages for Mobile Web 3 2-15-09

Similar to Developing Pages for Mobile Web 3 2-15-09 (20)

Developing Pages for Mobile Web 3 2-15-09