The Web, Mobile
Michael(tm) Smith, Web Opener
Opera Software, Tokyo
“What to make of a diminished thing”
“…The bird would cease and be as other birds
But that he knows in singing not to sing.
The question that he frames in all but words
Is what to make of a diminished thing.”
from “The Oven Bird”, by Robert Frost
Some people like to start off presentations with jokes; I prefer to start the off with poems (well, excerpts from poems).
mikes@opera.com
- smith@sideshowbarker.net
- feel free to contact me
About me: I live and work in Tokyo, for Opera Software, as a
"Web Opener". What that title means would take me some time to
explain, but basically, I work for the Opera web-standards
team.
Just flew in on an all-night flight from JFK to CDG that arrived
at 6am, so I may be a little bit loopy.
The slides in this presentation are heavy on words; sorry in
advance for the lack of interesting images in this presentation;
it’s not a canned presentation, but instead something I put
together specifically for this event.
I have a lot to cover, so given the limited I will go through this
presentation very quickly. (Though 15 minutes is actually a
luxury; I once did a presenation at the MobileMonday Global Summit
awards where I had only 3 minutes…)
Sorry to start of the presentation with stuff about contacting me,
but please bear with me for a minute (I don't want you to walk
away from here without knowing how to follow up with me).
I live in Tokyo but work odd hours and am on the road a lot.
Available 24 hours a day, 7 days a week to anybody, to share my,
um, wisdom about smart browsing software for mobile devices, and
about access to the Web from mobile devices.
Go ahead and quote me if (even quote me out of context if you want
-- it'll give me a good opportunity to reach more people and
clarify what I actually said).
Now a little bit about where to take further discussion after this
presentation…
Further discussion
- This presentation takes place in the context of an ongoing discussion
- It is very likely that you will disagree with some things I say
- If you comment/blog somewhere on this presentation, please e-mail me and let me know
- Don’t expect that I’ll read or respond with comments on your blog (or anybody else’s)
You may or may not want to discuss some things with me after
this presentation.
This is really just another jumping-off point to get further
discussion going.
So let's make sure we find an appropriate place to have the
discussion.
On that note, let's see next slide...
www-mobile@w3.org
- http://lists.w3.org/Archives/Public/www-mobile/
- shared online discussion is important
- www-mobile@w3.org is an appropriate place for discussion about this subject domain
- mailing lists are the time-honored way to have discussions online
Don't isolate discussions only to blogs. At best, blogs are
just the starting point for a discussion that should be followed
up somewhere else if it's worthy of further discussion. At
worse, blogs are just vanity "hey, sign my yearbook" backwaters,
or places for people to do safely do narcisstic ranting without
exposing themselves to the need to engage in real discussion.
web-based forums are suboptimal for many reasons
Contentious discussion and open arguments online are also important.
Which brings us to the next slide...
Disruption and Controversy
- changes and disruptive technologies always generate controversy
- in the short term, disruptive technologies are newsworthy and generate much discussion and interest
- bad side: somebody loses; disruptive technologies are often a threat to existing business models
- long term: users win by having access to new technologies and new solutions to problems
I work on a class of software that could perhaps be described
as disruptive technology. That class of software is what I'll be
talking about today (see the subtitle of this talk)
Some people genuinely feel that in making the kind of software we
make, we are taking the wrong approach and that what we are doing
is out of touch with the needs of businesses that need to deliver
Web content to mobile devices, and out of touch with the needs of
users who want to access Web content from mobile devices.
Others argue that the class of software I work on, as it gains
more market acceptance, perhaps represents a serious threat to the
business models of some existing companies.
Some, in fact, would very much like to see us fail.
I do not have time to present a lot of context information about
this controversy up front; I will present it at the end if I have
time.
So, while we’re on the subject of controversy, and before I go
into details about specific software and technology, I’d like to
introduce a particular assertion…
Assertion: Do not deny access to content
- “Do not deny access to content on account of your presumptions about the user.”
- Not my words, but actually (I think) an amplification of section 3.6 of the W3C “Mobile Web Best Practices” guidelines (courtesy of Jo Rabin)
- Further: “Do not deny people the opportunity to access your content if they try to access some aspect of it from a context that you would not normally consider appropriate to that aspect.”
Content being Web content.
A message to content providers/developers.
From a blog entry that Jo Rabin posted this month.
That statement does not necessarily reflect his own views; instead they represent his description of the views of people who support the so-called “One Web”.
I highly recommend reading the “Mobile Web Best Practices” guidlines.
I will discuss the “One Web” concept more later if I have time.
Implicit in this, I guess, it the notion that your presumptions about users may not always be correct.
One specific way to rephrase that assertion is: If you have content that you are making available to users browsing the Web from desktop PCs, do not deny users of mobile devices access to that same content.
So let’s now state a premise related to that assertion…
Premise: Users want to access “desktop” content from mobile devices
- There are, by orders of magnitude, much more existing “originally intended for desktop access” Web sites than there are “specifically intended for mobile access” sites.
- There are some (many) existing Web sites that were originally intended for viewing from a desktop PC but that users nonetheless sometimes (often) want/need to access from their mobile phones.
Now I want to state a premise and see where it leads to…
Problem: Most desktop sites not adapted for access from mobile devices
- A current reality of the Web is that the vast majority of content providers and developers have not optimized/adapted their content for access from mobile devices, and many (most) never will
- Yet, users still want/need to access that content.
Content providers are the site owners and developers who control the servers from which Web content is served.
There is a gulf here between what content providers should be doing with respect to making their content available to mobile users (according to best-practice guidelines) and what they are actually doing.
Solution: Make smarter browsers
- For the case of providing access to sites which have not been adapted by content providers for access from mobile devices, make the browser do the work of adapting the site’s content in such a way that it is usable and accessible from small-screen mobile devices.
- Can be described as “client-side content adaptation” (as opposed to any “server-side content adaptation” done by the content providers themselves).
Later in the presentation (if I have time), I will discuss what “content adaptation” is, and at what points in the content delivery chain it can take place.
A smart browser basically does the work of making content judgements and formatting adjustments and that a human being would have otherwise been making do adapt the content server-side.
Checklist: What makes a smart browser?
- Can reflow the text content of a Web page (even a multi-column page) into a single column, eliminating the need for horizontal scrolling.
- Can resize images on the fly to fit to the width of the device viewport (again, to eliminate horizontal scrolling).
- But can also provide a “desktop mode” or “PC view” of the page (that is, as it would look when accessed from a desktop PC browser).
- The above are the minimal criteria.
In “desktop mode”, the browser viewport acts as a sort of magnifying glass that is focused on one particular part of a page at a time.
Checklist: What makes an even smarter browser?
- Can “collapse” or “fold” parts of the page that are obtrusive to viewing on small-screen devices and/or allow users to “jump” past those parts of the page. Primarily useful for dealing with multi-line “navigation menu” content.
- Can efficiently handle display of large pages (in excess of 1 megabyte) and/or “chunk” logical pages into smaller physical pages (of 10K or whatever each) to fit within memory limitations of current mobile devices.
- The above are still relatively minimal criteria.
Currently, HTML does not provide a standard way for marking up navigation menus, so the work of identifying navigation-menu is basically an artificial-intelligence task.
Smart browsers:
Opera Mini and Opera Mobile
- Opera makes two smart browsers for mobile devices.
- The browsers are basically doing the same thing with respect to content adaptation, just doing it in different ways (different points in the delivery chain).
This presentation is a primarily a discussion of “smart” mobile browsers as a class of software, but Opera does not pay me to go places and talk about this stuff strictly in the abstract. And though there are some companies out there other that Opera that are making smarter mobile web browsers (some of them are maybe in this room now), I’m not here to do their marketing for them.
So I’ll take some time now to talk about what Opera is doing to serve the need for smarter mobile browsers.
Opera Mini
- Small (currently less than 100K footprint) client
- Currently a Java (MIDP) client
- Relies on a proxy server; proxy is itself an Opera instance running on a remote server that does the “heavy lifting” of formatting raw pages; the proxy server delivers a “cooked” form of the page to the client.
- The Opera Mini client is capable of running on even the humblest of devices, as long as the device has a Java VM running on it (as the vast majority of deployed devices do).
Current production version of Opera Mini is 2.0. Beta version of Opera Mini 3.0 is available and supports SSL/TLS and a number of others things.
Opera Mini: Content folding
- long list of links is "folded" or collapsed (e.g., a
navigation menu), with a plus sign
[+]to indicate where in the page the list of links occurs - select the plus sign to expand the list
Eliminating or moving long lists of links is one of the main design changes that mobile-authoring guidelines suggest content providers/developers should make; Opera Mini can do it programmatically.
Opera Mobile
- A full native application; does not rely on a proxy.
- The same core code as desktop Opera, but “ported” to a variety of mobile-devices operating systems (Brew, Symbian S60 and UIQ, Windows Mobile, etc.)
- Still relatively small footprint (compared to that of other mobile browsers) and manages memory efficiently.
- involves direct (normal) interaction between client and content provider’s remote Web server, so makes full-fledged web applications usable on mobile devices (not just web sites)
The Nintendo DS is less powerful (as a platform for running a browser) than many mobile phones (certainly less powerful than most mobile phones currently being marketed in Japan), yet we still managed to get Opera Mobile running on it well.
Opera Mobile goes farther by providing mobile users not just with access to static web sites, but also with access to interactive web applications.
What’s a Web Application?
- Examples of web apps: games, online shopping sites, calendars, maps, chat apps, clocks, webmail clients…
- At the top end, see also (buzzword alert) Rich Internet Application (RIA): web applications that have the features and functionality of traditional desktop applications.
Perhaps a web application is most often something that users interact with in order to complete a task (as compared with, say, a news page or something that users simply read).
What’s a really smart mobile browser?
- A really smart mobile browser supports web technologies that enable users to access web applications.
- Supports CSS 2.1 and client-side scripting which (in practical terms) means support for Javascript (aka ECMAScript)
- More specifically, supports asynchronous scripting; for example, through XmlHttpRequest (XHR) also known (in vulgar terms) as Ajax
- In addition, technologies such as SVG, the <canvas> element, browser-side XSLT, security protocols such as SSL/TLS, and emerging standards such as CSS 3 and XBL
Note that these technologies is all non-proprietary and standards-based; HTML and CSS are W3C standards, while Javascript/ECMAScript is standardized by Ecma International (European Computer Manufacturers Association). Though Javascript was originally created by Brendan Eich of Netscape/Mozilla but evolved with discussion and consensus of Yahoo!, Apple, Microsoft, Adobe, Opera, and others.
What’s a brilliant mobile browser?
- A truly brilliant mobile browser would have scripting APIs to device capabilities
- For example, an API that enables a remote web application to query the device for the device’s GPS location
- Would enable web apps for location-based services (LBS)
- Problem: There is no agreed-upon standard/spec describing scripting APIs to mobile-device capabilities
Of course there are security issues around this. There are security issues around doing anything powerful and useful on any network-connected device.
Why do this? Do users want this?
- Answer: Yes, users do want access to web-based apps from mobile devices, just as they want access to such web apps from desktop browsers
- The web apps that users want to access from mobile devices may not necessarily be that same web apps they want to access from desktop PCs (eventually, most probably won’t be)
- Example: location-aware web apps have much relevance to mobile use cases, little relevance to desktop PC use cases
- Users are already using these kinds of apps on mobile devices (they’re just Java, Brew, Flash apps, not yet web-based)
We have seen user movement on the destkop away from installed apps and toward web-based (RIA) apps.
Why do this? Do developers want this?
- Answer: Yes. Because those technologies (Javascript/XHR/Ajax, SVG, XSLT, etc.) enable developers to build web apps that can replace Java/MIDP, Flash, and Brew “appli” that need to actually be installed on the devices (apps which are based on closed/proprietary technologies and/or for which there is a high cost to developers to deploy)
Is appli a Japan-specific term? I don’t know what else to call “appli”…
The full toolkit
- The goal is to provide developers with the full toolkit – same as desktop browsers – to web developers, and we leave it up to developers to do their magic with those tools
- Given access to the tools and technologies, smart web developers can always amaze you with what they can do.
We have a lot of powerful web apps to look forward to.
But let’s get back to the discussion about content adaptation…
A Challenge: Guidelines don’t cover this case
- MWBP 3.4, “Assumptions about Adaptation”, says:
“In phase 1 (See 1.4.1 Phasing) it is assumed that content adaptation, if any, is carried out Server Side. Future phases may consider the implications of content adaptation elsewhere...” - Another document attempting to offer best-practice
guidelines about delivering Web content to mobile devices
says:
“Client-side adaptation is aimed at web sites and covering it is out of the scope of this document”
The guidelines don’t offer any guidance as far as client-side apaptation goes…
"One Web" and "Mobile Web"
- "One Web" means making “the same information and services available to users irrespective of the device they are using”
- "Mobile Web", (as a noun and in the limited context of this presentation) means creating separate content (or subsetting existing content) in a way specifically optimized for access from mobile devices
- These descriptions simplify the distinction considerably
The context in which I'll make my comments is an ongoing controversy about a concept called "One Web" and the concept of a separate "Mobile Web".
The W3C puts some of its resources into work on the "One Web" approach. Jo Rabin has jokingly referred to the W3C as the "Church of One Web".
Experienced/working real-world mobile-specific developers and businesses (and perhaps the Open Mobile Alliance) tend to put their resources into the "Mobile Web" approach.
Some advocates of the “One Web” approach avoid using the term “Mobile Web” as a noun and instead just use it as an adjective.
One thing that it’s important to note about "One Web" is that it is not just about extending Web access just to mass-market mobile phones; it’s about extending it to a range of devices: game machines like the Nintendo Wii and portable Nintendo DS, the Sony Mylo, set-top boxes, back-of-seat monitors on airplanes, etc.
MWBP 3.1 add this clarification about the meaning of “Open Web”: “it does not mean that exactly the same information is available in exactly the same representation across all devices.
I don't want to mischaracterize arguments on either side…
Strong opinions, strong words
- Some less-thoughtful "One Web" advocates are fond of mischaracterizing the "Mobile Web" approach by invoking charged/pejorative phrases like "walled-garden approach" to describe it.
- Some "Mobile Web" advocates are fond of mischaracterizing the "One Web" approach as only a "dream for the future" that has very little connection to current business realities, developer needs, or to sound usability principles
- If you find me mischaracterizing your views, let me know
There are people advocates of both approaces who have very strong opinions
We are not being fair to one another when we try to
mischaracterize the two different approaches.
But do the two approaches necessarily conflict with one another?
next slide...
This is not Good vs Evil
- the Web is not a dualistic universe
- we are not well-served by trying to assert a dichotomy/polarity between "One Web" and "Mobile Web" approaches; they are not mutually exclusive
- if you take part in this discussion, at least please don't mischaracterize the arguments of your supposed foes
Advocates of "One Web" intentionally
mischaracterize/misrepresent the arguments of the other side,
while the other side intentionally mischaracterize/misrepresent
the One Web advocates.
But "One Web" and "Mobile Web" can live together in peace (coexist
in harmony)...
KDDI/Au handsets have two browsers
- "PC Site Viewer" (Opera Mobile 8.5) for viewing "One Web" content
- EZWeb browser (so-called "WAP browser") for viewing mobile-specific "Mobile Web" content
- The browsers have different use cases, and I use both every day.
I am not a WAP-hater. One of my all-time favorite sites has a separate mobile-specific site…
Tokyo Art Beat - www.tokyoartbeat.com
- Tokyo Art Beat (TAB) is a bilingual guide to art events in Tokyo, designed by some friends of mine (including W3C's Olivier Thereaux )
- I use the mobile-specific version of the site when I want quick access
- I use the regular "PC site" version of the site when I want access to some features that the mobile site does not yet have
The current mobile-specific version of the site lacks a mechanism to let me save favorite events and other preferences. The "one Web" version of the site provides personalization features, but the TAB developers have not yet done much to "mobilize" it or to make it "mobile considerate", so using the mobile-specific site is currently quicker (mostly). I actually volunteered months ago to help out with adding the personalization features to the mobile-specific site. But now I'm more inclined to look into how the "one Web" site may be tuned (through use of a handheld stylesheet) for quicker and cleaner access from the "PC Site Viewer" (Opera Mobile). Anyway, I like having the choices available…
Let users choose
- Choice rightly belongs in the hands of users
- If users want to access "PC sites" from their mobile devices, then find a way to enable them to do that.
- Ideally, give users a range of choices.
This is where I pick sides.
I don’t like the idea of limiting user’s choices.
My experience tells me that Users do not always want to be corralled into limited mobile-specific sites only; they sometimes (often) want to have access to the full Web. If there are in fact "walled gardens", they don't want to be restricted to them.
But forget about my opinion – what do existing guidelines say about user choice?
Mobile Web Best Practices
- 3.6 Choice of User Experience
- “the content provider may choose to allow the user to select from broad categories such as mobile or desktop presentation, where these are distinguished in the application. If the presentation option has been determined automatically, the content provider may choose to allow the user to override the automatic determination”
The W3C Mobile Web Best Practices guidelines recognize the need to enable users to make their own choices about how the want content presented them.
The language in MWBP 3.6 is diplomatic and the underlying principle can be stated a bit more emphatically…
One Web approach:
Do not deny access to content
- Amplification of MWBP section 3.6 (courtesy of Jo Rabin)
- “Do not deny access to content on account of your presumptions about the user. … Do not deny people the opportunity to access your content if they try to access some aspect of it from a context that you would not normally consider appropriate to that aspect.”
A message to content providers/developers.
It would be hard to come up with a more cogent statement of the principle of user choice with respect to access to the Web from mobile devices thatn this amplification of MWBP by Jo Rabin.
But not everybody agrees with this prinicple…
Mobile Web approach:
Don’t serve a website to a
mobile device
- “Global Authoring Practices
for the Mobile Web” document Represents the personal views of a strong (outspoken) critic of the “One Web” approach, and contains the following best-practice guideline. - [DIFFERENT_MEDIA] Do not serve a website to a mobile device and do not serve a mobile site to a web browser.
The “Global Authoring Practices for the Mobile Web” document posits itself as an alternative to MWBP that is more in touch with business realities and developer realities, and more in touch with usability principles
Do not dismiss the author as a crank; his comments represent the views of a lot of working developers and content providers; they just don’t express their views quite so emphatically.
But the problem with this principle is that it restricts users’ choices.
Might it be possible to find some middle ground?
Middle ground: Gmail example
- Gmail has a mobile-optimized interface, but also gives mobile users the choice/option to get to its “basic HTML” and “standard” interfaces
Allow choices; don’t make presumptions about users.
Questions?
- Questions welcome (smart or dumb…)
Opera’s Chief Standards Officer (Charles McCathieNevile) says there are no dumb questions, but I think there actually are, in fact, dumb questions. As a presenter, I like to get those kinds of questions, because then people mock you instead of me. So please go ahead and ask those kinds of questions, and embarrass yourself. It will take some pressure off me. The dumber the question, the better.
Of course I also welcome smart questions.