Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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