Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Wireless Web: Not! T376 / CS471, Winter 01 © 1999-2001 Armando Fox

Similar presentations


Presentation on theme: "The Wireless Web: Not! T376 / CS471, Winter 01 © 1999-2001 Armando Fox"— Presentation transcript:

1 The Wireless Web: Not! T376 / CS471, Winter 01 © Armando Fox

2 © 2001 Stanford Project Administrivia n By today: teams formed, proposals on Web l Advisors will start to review them shortly n Design review meetings: you can schedule yourself for… l Feb 8-9 time slots l Use link in sent to cs241 n What hardware/software will you need to borrow/buy?

3 © 2001 Stanford Outline n Approaches to wireless “thin clients” l “Straight but reduced” ports: MS Pocket IE, C-HTML, etc. l Adaptation by proxy: ProxiNet and Palm VII “Web clipping” l Targeting phones: the WAP Forum and protocols l The thinnest of clients: smart pagers n Wireless and Palms - technology choices n HCI: why technology improvements are largely irrelevant

4 © 2001 Stanford : Three-Way Convergence WWW Technologies Wireless Access Thin Clients Complex content, services, corporate applications High functionality but palm-size portable devices Inexpensive but slow wireless access Wireless Internet Becomes Real

5 © 2001 Stanford Specific Announcements & Products n Palm Pilot: the resurrection of PDA’s l Cut the right corners to solve someone’s problem l Even better when combined with wireless…though its designers didn’t intend that n WAP Forum announcement l Took a long time to pick up steam, but it placed a stake in the ground for wireless data to smart phones n Japanese (primarily) hybrid phones l I-mode: compact HTML, a simple text-centric Web all over again; what can happen when you control the phones and the service l J-mode: the next step

6 © 2001 Stanford The Big Picture n Existing Web content and services are not designed for non-PC devices l Displays too small or text-only l Slow connection speed l Data input methods very limited (phone keypad or pager buttons) l etc. n 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

7 © 2001 Stanford n Get content from origin Internet servers n Separate by datatype n Perform device-specific transformations n Compression is a nice side effect… n We’ll discuss structure of this app in detail later Armando Fox PhD Candidate, UC Berkeley Computer Science Division Advisor: Eric Brewer Armando Fox PhD Candidate, UC Berkeley Computer Science Division Advisor: Eric Brewer 1. Content Adaptation

8 © 2001 Stanford Pay Only For the Bytes You Need n Ultimately, users know best l proxy transforms as best as it can, but gives users a way to “force” proxy to deliver original content l here, a simple client-side UI enhancement is coupled with proxy- side refinement intelligence transformed content from Proxy refined content from Proxy local UI interaction

9 © 2001 Stanford More On Adaptation n How to make adaptation dynamic l Why would you want to do this? l How to structure an adaptation system n Adaptation workloads have nice systems properties l State management l Replication/parallelization l Caching l An excellent workload for clusters

10 © 2001 Stanford Limitations of Adaptation n Presentation is messed up l Some content just doesn’t translate to smaller screens l Some content is purpose designed at the pixel level for desktop browsers n User experience is often terrible: navigation is cumbersome…why? l Limited input l Each roundtrip to server takes a lot longer l 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.

11 © 2001 Stanford 2. Straight Ports n Example: Microsoft Pocket Internet Explorer (WinCE) l Subset of MSIE desktop functionality l No Java, JavaScript, or plug-ins l Slow to render complex pages l Power-intensive! (Battery life does not follow Moore’s Law) n Real limitations come from HTTP/HTML l Images are scaled -- after downloading l Complex pages (many frames, etc.) difficult to render -- browser can only throw up its hands after content arrives l Many roundtrips (separate connections) Suffers from similar limitations as adaptation

12 © 2001 Stanford Performance of Ports vs. Proxies UC Berkeley research prototype of ProxiWeb, vs. Netscape Navigator on laptop w/same bandwidth

13 © 2001 Stanford 3. Reauthoring: Compact HTML n Proposed by Japanese ACCESS Consortium l engages in Internet and middleware standards activities in Japan l Similar to W3C, but focused on practical applications for consumer electronics (Web terminals, kiosks, etc.) n Approach: subset HTML (no frames, tables, JPG, image map, background images, stylesheets) l Reauthoring assumed l Deployed in jMode phones n Note: Japanese “Internet phones” are much more ambitious than current U.S. and European models! Kyocera video cell phone Kyocera video cell phone

14 © 2001 Stanford Reauthoring: WAP n WAP: Wireless Applications Protocol l Not-for-profit “WAP forum” (analogous to W3C) formed in 1994 l Founding members: Unwired Planet (now Phone.com), Motorola, Ericsson, Nokia l Membership now ~100 companies n The WAP protocols l Cover everything from link layer to application layer l Of interest here: WML (formerly HDML)

15 © 2001 Stanford Wireless Markup Language n Formerly HDML, proprietary to Unwired Planet l Became “open standard” after WAP forum started l Target: cell phones with 2-10 line text-only displays, icon graphics n A cross between a markup language and HyperCard l Metaphor: a “deck” of display cards l Display information (including support for images, rarely used) l Encode a series of menus for keypad navigation l Data entry using alphanumeric mode of phone keypad l “Form submission” -like mechanism to retrieve data from Internet

16 © 2001 Stanford WML, cont’d. n The WML browser l Interprets WML decks, displays info, etc. l Maps phone’s user interface (keypad, soft buttons, dials, etc.) to UI controls for menu navigation, data entry, etc. n WML apps served from HTTP server via WAP gateway l Apps live on standard Web servers l Gateway operated by wireless data provider Diagram © 1999 WAP Forum

17 © 2001 Stanford WML Architecture Notes n WAP architecture isolates application delivery l App developers don’t deal with wireless transport directly (since WAP leverages HTTP infrastructure for app distribution) l Becomes a non-differentiator for phones l App developers don’t have to commit to one phone platform n Lots of incompatibilities across devices and browsers l WMLscript scripting language: part of the spec, but not deployed in practice l HDML 1.0 vs 1.1 vs WML l VXML in future? l In practice, everyone uses least-common-denominator n Free emulator available from Unwired Planet

18 © 2001 Stanford WML Is Not HTML n reauthoring required, or applications have to be developed from the ground up n Differences are conceptual, not syntactic l WAP browser/apps are highly stateful (why?) l No metaphor for “clicking on a link”…only menu selection l WAP deck can control history stack n A thought: can we use the proxy approach again? l At least two scenarios for converting WML to HTML l Case 1: we can make strong assumptions about structure, semantics, syntax of content l Case 2: we can’t

19 © 2001 Stanford Merging WAP With the Web: Case 1 n Semantic/structural assumptions l Content was specifically authored for “small” devices l Content sourced from more structured data (e.g. Web front end to a database) l Future: XML and WIDL for describing content (more later) n Syntactic assumptions l Simple runtime scan of content l Look for “troublesome” elements: frames, tables, imagemaps, … l Translate, or drop?

20 © 2001 Stanford Case 1, cont’d. n Example: WirelessKnowledge l Exchange Server is the center of the world l Revolv service makes WAP phone into limited Exchange client n Example: Oracle Panama (last year) l Many Web sites already backed by RDBMS l Instead of wrapping query output in HTML, wrap in HDML l Better: wrap in XML, then use XSL/XSLT for presentation

21 © 2001 Stanford Merging WAP With the Web: Case 2 n No assumptions about content n Can apply some standard tricks for a few things… l Client side imagemaps: extract ALT text and anchors l Images: extract ALT text l Navbars: hope there’s a textual version farther down the page n Making the result syntactically acceptable is “easy” n 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

22 © 2001 Stanford The Age of “Everywhere” n Everything is Everywhere l “Java Everywhere” l “Windows Everywhere” l “WAP Everywhere??” How about “IP everywhere”? n How about it? IP to a cell phone? l How does this argument play in the “proxy camp”? l Yet, many (most?) proxies are TCP/IP based… l So how about “Existing standards everywhere”?

23 © 2001 Stanford Pagers: the Thinnest of Clients n Early years l 1921: first use of paging, Detroit Police Dept. l 1976: POCSAG radio paging code l 1980’s: numeric-display pagers n Current growth: >20% per year in US l In Japan, paging is on the way out! n Far thinner than PDA’s or WAP phones l Tens of KB of memory, embedded OS l < 6400 baud for most systems

24 © 2001 Stanford Paging Protocols n Motorola FLEX: widely-licensed one-way paging protocol l 6400 baud, fallback to 3200 l 4-bit checksum to pager l In principle, 30K char limit l ReFLEX: Two-way extension to FLEX n Motorola FLEXscript SDK l For designing Motorola SmartPager apps l 1-way or 2-way l Model seems similar to Web clipping

25 © 2001 Stanford Combining Paging and 2-Way Data n Paging system excels at short notifications l Ubiquitous coverage l Inexpensive l Range of devices (digits only, alphanumeric, pixel-addressable) n 2-way data link excels at selectively pulling down more content n Idea: combine the two capabilities l Especially in devices that are capable of both l Examples: PCS phones, some PDA’s (with pager cards)

26 © 2001 Stanford Integration of Push and Pull ProxiWeb (browser) used as universal display client Pushed information seamlessly integrated with pulled information PushBack example: © 1999 ProxiNet, Inc.ProxiNet, Inc.

27 © 2001 Stanford Other Wireless Technologies n Web clipping and Palm.net (PQA) l Basically a proxied approach with subset HTML l Focused on user experience n OracleMobile - a completely hosted mobile app environment l You provide your own Web server l You code your presentation layer in MobileXML l Your app is hosted on their server, which makes calls to your server and handles the WAP devices l They have ready made “modules” including weather, ATM locator, etc.

28 © 2001 Stanford Reliability, Latency, Coverage n Which is most appropriate for your service? Cell phone (SMS or WAP) 1-way pager 2-way pager Reliability End-to-end reliable Best-effort, but can build e2e on top Reliable notification End-to-end ack NoNoNo Delivery latency Bimodal Short (<4 min) Depends PersistenceYesDependsDepends Availability/ Coverage GoodExcellentFair

29 © 2001 Stanford Wireless & Palm: Technology Choices n Direct HTML browsing l Intellisync Browse-it now in public beta (www.intellisync.com) l Use existing HTML authoring tools, etc. l Requires wide-area connectivity (Metricom, OmniSky) l Site will be portable to WinCE browsers such as Pocket IE n Palm VII PQA l Only works with Palm VII or OmniSky-enabled Palm III/V l PQA dev kit is free from Palm, mostly use standard tools n Waba (a subset of Java - but not the libraries!) l Code entire standalone apps for the Palm l Network connectivity is something of a pain in the butt

30 © 2001 Stanford HCI Issues: Voice Control n Myth: perfect voice recognition will solve all HCI problems related to phone-based services Reality of voice interfaces: n Inherently sequential n User must remember context and choices n Big problem with recognizing commands vs. data n User is usually distracted because they’re doing something else! (Otherwise they’d use a data service) n Moral: Use voice where it’s the most natural interaction (e.g. to leave a message)

31 © 2001 Stanford HCI Issues: Network Speed n Myth: fast, widely-available 3G networks will solve usability problems for wireless apps. Reality: n How much data can you stream to a cell phone? Is “talking head” videoconferencing that compelling? n Most real limitations are unrelated to network speed l Limited screen size l Limited data-input capability l Technologies have been developed that are pretty effective at working around slow networks! Slow networks hamper some apps, but are not likely to be the main “dealbreaker” for today’s apps.

32 © 2001 Stanford HCI Issues Summary n Technology breakthroughs will not provide “magic bullet” l Convenience of doing task is critical: minimize number of clicks l Compare to Palm Pilot! n How can you exploit task context to do this? l Location of the phone l Stored information about user in their profile l Other sources of context? n 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

33 © 2001 Stanford Conclusions n Consumer wireless is here, ready or not n The user experience must come first l Most current efforts have floundered in not observing this n Lots of turbulence in the area right now l Competing application standards: WAP, C-HTML, HTML, various proxied approaches l Phones becoming “open” platforms (via WAP) l PDA’s being served by proprietary wireless (Palm VII), open standards based wireless (ProxiNet), cradle/dock based offline browsing (MS Channels and Channel Viewer) n No 800-pound gorillas yet…it may pay to stay agnostic


Download ppt "The Wireless Web: Not! T376 / CS471, Winter 01 © 1999-2001 Armando Fox"

Similar presentations


Ads by Google