We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byAaliyah Hursey
Modified about 1 year ago
The Wireless Web: Not! T376 / CS471, Winter 01 © Armando Fox
© 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?
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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.
© 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 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
© 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)
© 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
© 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
© 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
© 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
© 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?
© 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
© 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
© 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”?
© 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
© 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
© 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)
© 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.
© 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.
© 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
© 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
© 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)
© 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.
© 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
© 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
MOBILE AND WIRELESS APPLICATION DEVELOPMENT PRESENTED BY: SARAH HAMEED SOPHIA HASAN UMAIR YOUSUF NAZIA HASSAN.
Wireless Markup Language - Vedantis. Copyright © [Vedantis Inc.]. All rights reserved Wireless Markup Language o Introduction Internet today has made.
Agility Craig Thompson, Steve Ford, Tom Bannon, Paul Pazandak, David Wells Object Services and Consulting, Inc. (OBJS) Main Idea - agents for the masses.
What is an Operating System? A program that acts as an intermediary between a user of a computer and the computer hardware. Operating system goals: Execute.
Mobile App Development & Localisation Eric Chubb Alchemy Software Development 14 th June 2012.
General web design Thomas Krichel assessment You return a two-page typed assessment on a library and information science department web site.
1 Computer Networks: A Systems Approach, 5e Larry L. Peterson and Bruce S. Davie Chapter 9 Applications Copyright © 2010, Elsevier Inc. All rights Reserved.
Web site design incubation Thomas Krichel LIU & НГУ
Geospatial Interoperability and the Open Geospatial Consortium Mike Jackson Centre for Geospatial Science University of Nottingham.
Chapter 51 Information Technology For Management 5 th Edition Turban, Leidner, McLean, Wetherbe Lecture Slides by A. Lekacos, Stony Brook University John.
LIS650 prologue: web design Thomas Krichel
CS211/Fall /29 CS211: Protocol and Systems Design for Wireless and Mobile Networks Instructor: Songwu Lu Office: 4531D BH Lectures:
DEV381.NET and J2EE: Strategies for Interoperability When you just know you're gonna need it.
Wireless Communications UniForum Chicago October 26,2004 Bill Latura.
LIS650 web site architecture & design lecture 0 Thomas Krichel
Web site design: thinking for the non-thinker Thomas Krichel
Department of Tourism, Leisure, Hotel and Sport Management - Jason Harding (PHD) Lecture One Information Systems For Service Industries NATHAN CAMPUS.
LIS650lecture 0 Introductory lecture Thomas Krichel
Public Information Version 3.1: 1/1/2012 Introducing Instant Business Intelligence To IT BI Project Managers What you need, when you need it
Information Systems Using Information (Higher and Intermediate 2)
ERP and E-Business- An Overview Based on the book Enterprise Resource Planning Solutions and Management by Flona Fui-Hoon Nah, Idea Group Publishing 2001.
1 IT Essentials I v. 3 Module 1 Information Technology Basics.
LIS650 lecture 3 Web site design Thomas Krichel
ADAMA UNIVERSITY SCHOOL OF ENGENEERING & INFORMATION TECHNOLOGIES Sem. II,2010/11 INSTRUCTOR TARIKU W OPERATING SYSTEM (IT3016)
UNIT I FUNDAMENTAL OF E-COMMERCE 1.1INTRODUCTION TO E-COMMERCE 1.2 DRIVING FORCES OF E-COMMERCE 1.3 BENEFITS AND LIMITATIONS OF E-COMMERCE 1.4 DATA MINING.
E-MARKETING (INTERNET MARKETING). E-MARKETING Marketing: A comprehensive process that involves every aspect of a business from designing its products,
Version 4.1 CCNA Discovery 2– Chapter 7. Contents 7.1: ISP Services : TCP / IP Protocols 7.2: 7.3: DNS 7.3: 7.4: Application Layer Protocols 7.4.
© 2016 SlidePlayer.com Inc. All rights reserved.