Download 02Wireless - Computer Science Division

The Wireless Web: Not!
T376 / CS471, Winter 01
© 1999-2001 Armando Fox
[email protected]
Project Administrivia

By today: teams formed, proposals on Web



Advisors will start to review them shortly
Design review meetings: you can schedule yourself for…

Feb 8-9 time slots

Use link in email sent to cs241
What hardware/software will you need to borrow/buy?
© 2001
Stanford
Outline

Approaches to wireless “thin clients”

“Straight but reduced” ports: MS Pocket IE, C-HTML, etc.

Adaptation by proxy: ProxiNet and Palm VII “Web clipping”

Targeting phones: the WAP Forum and protocols

The thinnest of clients: smart pagers

Wireless and Palms - technology choices

HCI: why technology improvements are largely irrelevant
© 2001
Stanford
1996-1998: Three-Way Convergence
WWW
Technologies
Complex content, services,
corporate applications
Thin Clients
High functionality
but palm-size
portable devices
Wireless
Access
Inexpensive but slow
wireless access
Wireless Internet
Becomes Real
© 2001
Stanford
Specific Announcements & Products


Palm Pilot: the resurrection of PDA’s

Cut the right corners to solve someone’s problem

Even better when combined with wireless…though its designers
didn’t intend that
WAP Forum announcement


Took a long time to pick up steam, but it placed a stake in the
ground for wireless data to smart phones
Japanese (primarily) hybrid phones

I-mode: compact HTML, a simple text-centric Web all over again;
what can happen when you control the phones and the service

J-mode: the next step
© 2001
Stanford
The Big Picture


Existing Web content and services are not designed for
non-PC devices

Displays too small or text-only

Slow connection speed

Data input methods very limited (phone keypad or pager
buttons)

etc.
But the Web is where the action is…so we can:
1.
Adapt existing content on the fly and automatically
2.
Make browsers run on non-PC devices
3.
Manually reauthor to new standards (there are so many!)
4.
Make an end run around the problem and move closer to the
source
© 2001
Stanford
1. Content Adaptation

Get content from origin
Internet servers
Armando Fox

Separate by datatype
PhD Candidate, UC
Berkeley Computer
Science Division

Perform device-specific
transformations
Advisor: Eric Brewer

Compression is a nice
side effect…

We’ll discuss structure of
this app in detail later
© 2001
Stanford
Pay Only For the Bytes You Need

Ultimately, users know best

proxy transforms as best as it can, but gives users a way to
“force” proxy to deliver original content

here, a simple client-side UI enhancement is coupled with proxyside refinement intelligence
transformed content
from Proxy
local UI
interaction
refined content
from Proxy
© 2001
Stanford
More On Adaptation


How to make adaptation dynamic

Why would you want to do this?

How to structure an adaptation system
Adaptation workloads have nice systems properties

State management

Replication/parallelization

Caching

An excellent workload for clusters
© 2001
Stanford
Limitations of Adaptation


Presentation is messed up

Some content just doesn’t translate to smaller screens

Some content is purpose designed at the pixel level for desktop
browsers
User experience is often terrible: navigation is
cumbersome…why?

Limited input

Each roundtrip to server takes a lot longer

Feedback often provided using graphics that don’t reproduce well
Adaptation of existing Web content is a useful technology,
but by itself won’t result in an acceptable user experience.
© 2001
Stanford
2. Straight Ports


Example: Microsoft Pocket Internet Explorer (WinCE)

Subset of MSIE desktop functionality

No Java, JavaScript, or plug-ins

Slow to render complex pages

Power-intensive! (Battery life does not follow Moore’s Law)
Real limitations come from HTTP/HTML

Images are scaled -- after downloading

Complex pages (many frames, etc.) difficult to render -- browser
can only throw up its hands after content arrives

Many roundtrips (separate connections)
Suffers from similar limitations as adaptation
© 2001
Stanford
Performance of Ports vs. Proxies
UC Berkeley research prototype of ProxiWeb,
vs. Netscape Navigator on laptop w/same bandwidth
© 2001
Stanford
3. Reauthoring: Compact HTML



Proposed by Japanese ACCESS Consortium

engages in Internet and middleware standards activities in Japan

Similar to W3C, but focused on practical applications for consumer
electronics (Web terminals, kiosks, etc.)
Approach: subset HTML (no frames, tables, JPG, image
map, background images, stylesheets)

Reauthoring assumed

Deployed in jMode phones
Note: Japanese “Internet phones”
are much more ambitious than
current U.S. and European
models!
Kyocera video cell phone
© 2001
Stanford
Reauthoring: WAP


WAP: Wireless Applications Protocol

Not-for-profit “WAP forum” (analogous to W3C) formed in 1994

Founding members: Unwired Planet (now Phone.com), Motorola,
Ericsson, Nokia

Membership now ~100 companies
The WAP protocols

Cover everything from link layer to application layer

Of interest here: WML (formerly HDML)
© 2001
Stanford
Wireless Markup Language


Formerly HDML, proprietary to Unwired Planet

Became “open standard” after WAP forum started

Target: cell phones with 2-10 line text-only displays, icon graphics
A cross between a markup language and HyperCard

Metaphor: a “deck” of display cards

Display information (including support for images, rarely used)

Encode a series of menus for keypad navigation

Data entry using alphanumeric mode of phone keypad

“Form submission” -like mechanism to retrieve data from Internet
© 2001
Stanford
WML, cont’d.


The WML browser

Interprets WML decks, displays info, etc.

Maps phone’s user interface (keypad, soft buttons, dials, etc.) to
UI controls for menu navigation, data entry, etc.
WML apps served from HTTP server via WAP gateway

Apps live on
standard Web
servers

Gateway
operated by
wireless data
provider
Diagram © 1999 WAP Forum
© 2001
Stanford
WML Architecture Notes



WAP architecture isolates application delivery

App developers don’t deal with wireless transport directly (since
WAP leverages HTTP infrastructure for app distribution)

Becomes a non-differentiator for phones

App developers don’t have to commit to one phone platform
Lots of incompatibilities across devices and browsers

WMLscript scripting language: part of the spec, but not deployed
in practice

HDML 1.0 vs 1.1 vs WML

VXML in future?

In practice, everyone uses least-common-denominator
Free emulator available from Unwired Planet
© 2001
Stanford
WML Is Not HTML

reauthoring required, or applications have to be
developed from the ground up

Differences are conceptual, not syntactic


WAP browser/apps are highly stateful (why?)

No metaphor for “clicking on a link”…only menu selection

WAP deck can control history stack
A thought: can we use the proxy approach again?

At least two scenarios for converting WML to HTML

Case 1: we can make strong assumptions about structure,
semantics, syntax of content

Case 2: we can’t
© 2001
Stanford
Merging WAP With the Web: Case 1


Semantic/structural assumptions

Content was specifically authored for “small” devices

Content sourced from more structured data (e.g. Web front end
to a database)

Future: XML and WIDL for describing content (more later)
Syntactic assumptions

Simple runtime scan of content

Look for “troublesome” elements: frames, tables, imagemaps, …

Translate, or drop?
© 2001
Stanford
Case 1, cont’d.


Example: WirelessKnowledge

Exchange Server is the center of the world

Revolv service makes WAP phone into limited Exchange client
Example: Oracle Panama (last year)

Many Web sites already backed by RDBMS

Instead of wrapping query output in HTML, wrap in HDML

Better: wrap in XML, then use XSL/XSLT for presentation
© 2001
Stanford
Merging WAP With the Web: Case 2

No assumptions about content

Can apply some standard tricks for a few things…

Client side imagemaps: extract ALT text and anchors

Images: extract ALT text

Navbars: hope there’s a textual version farther down the page

Making the result syntactically acceptable is “easy”

Making it usable is a different story
If you use WAP, plan for it from the moment you start
designing your data schema and user interactions
© 2001
Stanford
The Age of “Everywhere”


Everything is Everywhere

“Java Everywhere”

“Windows Everywhere”

“WAP Everywhere??” How about “IP everywhere”?
How about it? IP to a cell phone?

How does this argument play in the “proxy camp”?

Yet, many (most?) proxies are TCP/IP based…

So how about “Existing standards everywhere”?
© 2001
Stanford
Pagers: the Thinnest of Clients


Early years

1921: first use of paging, Detroit Police Dept.

1976: POCSAG radio paging code

1980’s: numeric-display pagers
Current growth: >20% per year in US


In Japan, paging is on the way out!
Far thinner than PDA’s or WAP phones

Tens of KB of memory, embedded OS

< 6400 baud for most systems
© 2001
Stanford
Paging Protocols


Motorola FLEX: widely-licensed one-way paging protocol

6400 baud, fallback to 3200

4-bit checksum to pager

In principle, 30K char limit

ReFLEX: Two-way extension to FLEX
Motorola FLEXscript SDK

For designing Motorola SmartPager apps

1-way or 2-way

Model seems similar to Web clipping
© 2001
Stanford
Combining Paging and 2-Way Data

Paging system excels at short notifications

Ubiquitous coverage

Inexpensive

Range of devices (digits only, alphanumeric, pixel-addressable)

2-way data link excels at selectively pulling down more
content

Idea: combine the two capabilities

Especially in devices that are capable of both

Examples: PCS phones, some PDA’s (with pager cards)
© 2001
Stanford
Integration of Push and Pull
PushBack example: © 1999 ProxiNet,
Inc.
ProxiWeb (browser) used as universal
display client
Pushed information seamlessly integrated
with pulled information
© 2001
Stanford
Other Wireless Technologies


Web clipping and Palm.net (PQA)

Basically a proxied approach with subset HTML

Focused on user experience
OracleMobile - a completely hosted mobile app
environment

You provide your own Web server

You code your presentation layer in MobileXML

Your app is hosted on their server, which makes calls to your
server and handles the WAP devices

They have ready made “modules” including weather, ATM locator,
etc.
© 2001
Stanford
Reliability, Latency, Coverage

Which is most appropriate for your service?
Cell phone
(SMS or WAP)
1-way pager
Reliability
End-to-end
reliable
Best-effort, but can Reliable notification
build e2e on top
End-to-end
ack
No
No
No
Delivery
latency
Bimodal
Short (<4 min)
Depends
Persistence
Yes
Depends
Depends
Excellent
Fair
Availability/ Good
Coverage
2-way pager
© 2001
Stanford
Wireless & Palm: Technology Choices



Direct HTML browsing

Intellisync Browse-it now in public beta (www.intellisync.com)

Use existing HTML authoring tools, etc.

Requires wide-area connectivity (Metricom, OmniSky)

Site will be portable to WinCE browsers such as Pocket IE
Palm VII PQA

Only works with Palm VII or OmniSky-enabled Palm III/V

PQA dev kit is free from Palm, mostly use standard tools
Waba (a subset of Java - but not the libraries!)

Code entire standalone apps for the Palm

Network connectivity is something of a pain in the butt
© 2001
Stanford
HCI Issues: Voice Control

Myth: perfect voice recognition will solve all HCI problems
related to phone-based services
Reality of voice interfaces:

Inherently sequential

User must remember context and choices

Big problem with recognizing commands vs. data

User is usually distracted because they’re doing
something else! (Otherwise they’d use a data service)

Moral: Use voice where it’s the most natural interaction
(e.g. to leave a message)
© 2001
Stanford
HCI Issues: Network Speed

Myth: fast, widely-available 3G networks will solve
usability problems for wireless apps.
Reality:

How much data can you stream to a cell phone? Is
“talking head” videoconferencing that compelling?

Most real limitations are unrelated to network speed

Limited screen size

Limited data-input capability

Technologies have been developed that are pretty effective at
working around slow networks!
Slow networks hamper some apps, but are not likely to be
© 2001
the main “dealbreaker” for today’s apps.
Stanford
HCI Issues Summary



Technology breakthroughs will not provide “magic bullet”

Convenience of doing task is critical: minimize number of clicks

Compare to Palm Pilot!
How can you exploit task context to do this?

Location of the phone

Stored information about user in their profile

Other sources of context?
Remember: things that are easy on a desktop Web
browser become awkward on a smaller device.
Wireless experience must be carefully designed--not
retrofitted from the Web experience
© 2001
Stanford
Conclusions

Consumer wireless is here, ready or not

The user experience must come first



Most current efforts have floundered in not observing this
Lots of turbulence in the area right now

Competing application standards: WAP, C-HTML, HTML, various
proxied approaches

Phones becoming “open” platforms (via WAP)

PDA’s being served by proprietary wireless (Palm VII), open
standards based wireless (ProxiNet), cradle/dock based offline
browsing (MS Channels and Channel Viewer)
No 800-pound gorillas yet…it may pay to stay agnostic
© 2001
Stanford