(5) Mobile's Share of Web Consumption

(6) Smartphone Sales Q2 2010

(7) Web Requests by Smartphone OS

(8) Browser Wars Revisited

• Two major developments are referred to as Browsers Wars [http://en.wikipedia.org/wiki/Browser_wars]
  • Netscape vs. IE in the late 1990s
  • IE vs. others (Firefox, Safari, Opera, Chrome, …) since 2003
• Economic battles fought with policies and technological weaponry
  • deploy default browsers on major platforms
  • make it hard for users to change their default browser
• Browser wars consume a lot of energy
  • browser developers concentrate on features and not on quality
  • content developers have to negotiate the battlefield

(9) Browser War I

(10) Browser War II

Firefox      Safari      Opera      Netscape      Mozilla      Chrome      Other

(11) Browser War III

• Mobile browsers are platforms for mobile applications
  • competition with native applications requires advanced browser capabilities
  • mobile devices vary widely in their features and configurations
  • defining the standard mobile platform is more challenging than for computers
• Many mobile platforms are designed like old fat clients
  • have a basic browser for simple and low-fidelity tasks
  • require installed native applications for more advanced tasks
• Computers moved away from fat clients a while ago
  • thin clients are more cost-effective (less local maintenance)
  • managing data and applications in the cloud adds flexibility
  • robust browser support allows advanced applications (Web 2.0 [http://en.wikipedia.org/wiki/Web_2.0])

(13) Mobile Browser Evolution

• Mobile Safari was the first desktop-quality mobile browser
  • almost all features of the desktop version of Safari
  • unique properties and problems because of the multi-touch interface
• Touch Web is a new term for explicitly touch-friendly Web pages
  • current focus is on being friendly to small-screen devices
  • iPad and other tablets may create a new category of large-screen touch browsers
• Identifying the target group for an application is not easy
  • native applications always will only work on one platform
  • Web-based applications can work across platforms
  • projections for application lifetime and update frequency are essential

(14) Acid2

   /* picture setup */
   #top { margin: 100em 3em 0; padding: 2em 0 0 .5em; text-align: left; font: 2em/24px sans-serif; color: navy; white-space: pre; } /* "Hello World!" text */
   .picture { position: relative; border: 1em solid transparent; margin: 0 0 100em 3em; } /* containing block for face */
   .picture { background: red; } /* overriden by preferred stylesheet below */

   /* top line of face (scalp): fixed positioning and min/max height/width */
   .picture p { position: fixed; margin: 0; padding: 0; border: 0; top: 9em; left: 11em; width: 140%; max-width: 4em; height: 8px; min-height: 1em; max-height: 2mm; /* min-height overrides max-height, see 10.7 */ background: black; border-bottom: 0.5em yellow solid; }

   /* bits that shouldn't be part of the top line (and shouldn't be visible at all): HTML parsing, "+" combinator, stacking order */
   .picture p.bad { border-bottom: red solid; /* shouldn't matter, because the "p + table + p" rule below should match it too, thus hiding it */ }
   .picture p + p { background: maroon; z-index: 1; } /* shouldn't match anything */
   .picture p + table + p { margin-top: 3em; /* should end up under the absolutely positioned table below, and thus not be visible */ }

   /* second line of face: attribute selectors, float positioning */
   [class~=one].first.one { position: absolute; top: 0; margin: 36px 0 0 60px; padding: 0; border: black 2em; border-style: none solid; /* shrink wraps around float */ }
   [class~=one][class~=first] [class=second\ two][class="second two"] { float: right; width: 48px; height: 12px; background: yellow; margin: 0; padding: 0; } /* only content of abs pos block */

(15) Acid3

• Acid2 [http://en.wikipedia.org/wiki/Acid2] tests only for CSS2 implementation
  • testing CSS selectors to always select the correct elements
  • testing CSS properties to produce the correct layout
• Acid3 adds a number of Web 2.0 technologies
  • JavaScript and DOM2 for basic scripting compatibility
  • SVG, XML, and data URIs for additional functionality
• Six major groups of tests (called buckets)
  1. DOM Traversal, DOM Range, HTTP
  2. DOM2 Core and DOM2 Events
  3. DOM2 Views, DOM2 Style, CSS 3 selectors and Media Queries
  4. Behavior of HTML tables and forms when manipulated by script and DOM2 HTML
  5. Tests from the Acid3 Competition
  6. ECMAScript

(16) Acid3 Result

(17) W3C Mobile Browser Test

• Very specific choice of tested technologies
  • XMLHttpRequest
  • canvas
  • contenteditable
  • geolocation API [Geolocation]
  • input type="date"
  • AppCache (offline launching for Web-based applications)
  • video
  • audio
  • Web Workers (threads for scripting)
  • local storage [Web Storage; Local Storage (1)] (persistent local key/value storage)
  • session storage [Web Storage; Session Storage (1)] (temporary local key/value storage)
  • @font-face
• Testing browsers [http://www.w3.org/2010/01/wctmb2/] is easy but might miss some details
  • video/audio critically depend on the supported codecs

(19) Targeting One Platform

• The Web is becoming increasingly segmented
  • vast majority of accesses are from regular computers (PC/laptop)
  • increasing share of accesses are from smartphones (mobile Web)
  • other platforms such as tablets, e-books, cars, consoles, …
• Use the correct statistics based on your audience
  • platforms vary greatly across countries
  • platform usage can change fairly quickly over time
• Targeting a single platform is high risk and high profit
  • cheaper development than native applications
  • UX not as polished as with native applications
  • same platform limitations as native applications

(20) Least Common Denominator

• The least common denominator is really small
  • state-of-the-art mobile browsers are limited to smartphones
  • most regular phones have very minimal WAP-inspired browsers
  • basic HTML, no CSS, no scripting
• Trade-off between audience and sophistication
  • good as a utilitarian approach if people have to use a service
  • risky as an approach where people have to become engaged

(21) Class-Based Development

• Good theory but hard to implement in practice
  • what are the most useful classes to identify?
  • how to reuse as much content/code across classes as possible?
  • how to make sure that class cost match class coverage?
• Nowadays often implemented in a two-class approach
  • regular site assuming a laptop/desktop computer and environment
  • mobile site either very basic (WAP) or touch-specific (iPhone)
• Publishing/authoring frameworks might become more sophisticated
  • generating different versions of sites (based on target audiences)
  • CSS Media Queries [http://www.w3.org/TR/css3-mediaqueries/] allow better client-side adaptation

@media all and (orientation:portrait) { … }
@media all and (orientation:landscape) { … }

<link rel="stylesheet" media="print and (color)" href="http://…" />
<link rel="stylesheet" media="print and (monochrome)" href="http://…" />

(22) Translation/Adaptation

• Fully automated approaches are research topics
  • usual problem of perfect separation of content and layout
  • many research projects are based on the idea of pure content
  • many real-world projects use a mix of content and layout
• Database-driven solutions typically are good candidates
  • the content almost by definition has no inherent layout
  • designing translation/adaptation has a good starting point