QuirksBlog

Mobile market overview

Over the weekend I created a mobile market overview in the form of a sortable table. I hope it gives you some insights; it certainly did for me.

For a complete overview knowledge of the current market share stats is necessary; fortunately Tomi Ahonen provides the latest. My table doesn’t yet contains these stats; I still have to figure out exactly how to display them (not to mention making time to implement a new feature).

Anyway, take a look and let me know what you think. And if you have some extra facts, please provide them.

Mobile browser page updated; help needed

I have updated the mobile browser page. It now contains 18 browsers, and in addition I added some lists about which browser runs on which OS, and which device vendor uses which OS. However, I need your help in making the list exhaustive.

I have now firmly decided to test and describe only those browsers that run on one or more of the ten smartphone OSs (Android, bada, BlackBerry, iOS, LiMo, MeeGo, Phone 7, Symbian, webOS, Windows Mobile). There are just too many other OSs, but they’re either feature phone only, or they’ve fallen out of the race.

My question to you is to review the list and rack your brain for more data.

Do you know if a browser runs on one of the smartphone OSs but is not yet mentioned in my lists?
Do you know if a device vendor sells one of the smartphone OSs but is not yet mentioned in my lists?

If you do, please leave a comment with a useful link (to the browser vendor’s homepage, or to a news item that mentions device vendor A selling smartphone OS B).

Thanks.

First serious stab at mobile browser grading

jQuery announced the jQuery mobile project, which aims at bringing jQuery to mobile browsers. All mobile browsers; not just Safari iPhone and Android WebKit.

]]> Still, bringing the library to all mobile browsers is a rather tall order, since there are so bloody many of them. Therefore John Resig has spent a lot of time with mobile phones (I know all about that, so I admire his persistency) and has produced a first serious stab at mobile browser grading.

jQuery’s approach differs slightly from Yahoo!’s, in that it has A-, B-, C- and F-grade browsers.

A High Quality. A high quality browser with notable market share. A must-target for a mobile web developer.
B Medium Quality. Either a lower quality browser with high market share or a high quality browser with low market share. Depending upon your capabilities you should work to support these browsers, as well.
C Low Quality. Typically an extremely low quality browser with high market share. Generally not capable of running modern JavaScript or DOM code.
F Failing. A barely-functioning browser. Even though it has some market share you should avoid developing for it completely.

Safari iPhone 3+, Android WebKit, Dolfin, Opera Mobile 10+, Symbian v5 (which I call Symbian WebKit 2), BlackBerry 6.0 (the WebKit-based one), Palm WebKit, Firefox, and the MeeGo MicroB browser (Gecko-based) are the A-graded ones, and I agree.

I hope other libraries will follow suit. In fact, Dojo and YUI are already doing so, although I’m not sure exactly where they are right now. (Pointers very welcome.) Ext.js has completely moved to mobile and has been renamed Sencha. My personal beef with Sencha is that they only support iPhone and Android; their examples do not work on Dolfin (Samsung bada), while that browser also supports the touch events. But that’ll change

Of course I fully support all these moves. My support will likely take the form of continuing to report on the mobile browsers and their odd quirks; that’s what I have been doing for the first generation of libraries, and that’s what they still need most.

Fronteers 2010: Jake Archibald and Stoyan Stefanov

The Fronteers 2010 conference has announced two new speakers: Jake Archibald of the BBC’s Glow library, and Stoyan Stefanov of Yahoo!

Thus the speakers’ list is continuing to grow, and the conference is becoming more and more worth your € 375. What are you waiting for? Order your ticket now!

Combining media queries and JavaScript

On Tuesday Jason Grigsby challenged the conventional view that media queries are all we need to make a website mobile-friendly. Although he’s right when he points out some serious problems, I do not think that media queries are the “fool’s gold,” as Jason says. The message seems to be more that media queries alone are not enough to make your sites mobile-friendly. An additional component is required.

]]> To recap briefly, this is a media query:

.sidebar {
	float: right;
	width: 250px;
}

@media all and (max-device-width: 600px) {
	.complicatedFunctionality {
		display: none;
	}
	.sidebar {
		float: none;
		width: auto;
	}
}

The media query asks whether the width of the device is 600px at maximum. If it is, the special styles are executed. This usually comes down to hiding advanced functionalities that do not make sense on mobile or take too much bandwidth, while it can also be used to change the site’s grid from horizontally oriented to vertically oriented; for instance by placing a sidebar not right of the main content, but below it.

Technically, the .complicatedFunctionality and .sidebar declarations are added to the style sheet only when the query returns true, i.e. the device is less than 600px wide.

Now this works. Better still, media queries are the ideal way of adapting your design to different screen resolutions. Still, they are not the be-all-end-all of making your website mobile-friendly.

Jason identifies two main problem areas:

It’s all very well to hide, say, an advanced mapping application on mobile, but if you use only media queries the browser will still download the scripts associated with the application.
Even though images might be hidden from mobile browsers, or low-source ones should be used, the browser still downloads the full-source variants.

In other words, media queries do not stop the browser from downloading assets that will not be used on a mobile phone. And with bandwidth at a premium, this is a serious problem.

He concludes:

CSS media queries are a tool, but they are not a silver bullet.

I mostly, but not entire agree. Media queries are silver bullets when it comes to pure CSS. Restricting the width of your site, moving sidebars and main navigations elsewhere, media queries can do all that and more.

The trick, however, is that a pure CSS approach is not enough. In addition we need a JavaScript that also reads out the media queries and uses the data to decide whether to download the complicated mapping script, whether to download the low-source or the full-source images, or possibly none.

As far as I know there is no direct access to media queries from JavaScript. You can’t read out whether the example media query above has fired or not.

JavaScript pairing

Fortunately, there is a pretty safe way of using JavaScript in conjunction with media queries. It turns out that all browsers I tested so far have paired the width and device-width media queries with the values of document.documentElement. clientWidth and screen.width, respectively.

This is a general rule. All mobile browsers that support media queries exhibit these pairings. It’s hard to believe, but I haven’t found any exceptions yet — and rest assured that I searched for them, because I could not believe that it would be this simple. And I will continue to keep an eye on this and report problems as soon as I find them.

One caveat, though: although the pairing exists in all browsers, some browsers report incorrect values for document.documentElement. clientWidth and screen.width. However, these browsers will also fire media queries based on these incorrect values, so the net result remains that both media query and script are executed, although at the wrong time. See the viewport compatiblity table for the gory details.

Therefore, if we want a JavaScript component that fires when the example media query above is triggered, we simply do:

if (screen.width < 600) {
	// don’t download complicated script
	// use low-source images instead of full-source ones
}

I think it’s best to reverse the script logic:

if (screen.width >= 600) {
	// download complicated script
	// swap in full-source images for low-source ones
}

If you want to use width instead, do this:

@media all and (max-width: 900px) {
	// styles
}

if (document.documentElement.clientWidth < 900) {
	// scripts
}

Thus it is quite possible to pair a JavaScript routine with your media queries, and use it to decide which assets you should and should not download.

When these scripts are added to media queries, we’re a whole lot closer to making one website that reacts to a mobile (or rather, a narrow-screen) environment both in its CSS and in its asset management.

“HTML5” — let’s move on, shall we?

Months ago I concluded that “HTML5” means whatever you want it to mean. This week, Jeffrey Zeldman and Jeff Croft took up the discussion, with Tantek Çelik and Bruce Lawson commenting.

]]> Tantek Çelik said:

However, [the test site HTML5test.com] has one very big problem.

It tests things that it claims or implies are HTML5 (or conflates them as such) that are not actually part of HTML5.

Bruce Lawson said:

And what really makes my old-timers’ blood boil is people calling CSS3 or patented Apple CSS-extensions HTML5. The work of the Web Standards Project was incredibly successful in making people aware the structure and style are different. There’s an even greater separation in HTML5.

Jeff Croft said:

Sometimes we just need a word to rally behind. And put in job descriptions. And claim we “support” (another word that is mostly meaningless). It’s a language thing and a human psychology thing.

Needless to say, I agree with Jeff Croft here. There are several points that merit our attention:

It’s already too late. “HTML5” has taken on meaning as a marketing term and is being used as such — not least by the browser vendors. Any opposition is pointless.
Bruce’s argument would carry more force if the HTML5 spec hadn’t habitually blurred the line by inserting behaviour into what’s supposed to be a structure spec. Besides, any web developer is able to see that the
element, a -webkit-transform and Web Workers belong in different layers.
The HTML5 spec is changing constantly, and time and again features are yanked out of it. No doubt that makes sense from a spec-producing point of view, but the problems of spec writers should not dictate what web developers do. We just want to use cool new stuff and sell it to our clients.

I’m sorry, but I just can’t be bothered to once again rise to righteous fury about minor semantic points. Explaining the separation of structure, presentation, and behaviour was very important in its day (hell, I was the first to discuss separation of structure and behaviour back in 2004), but the concept was accepted by the web development community long ago, and I don’t see the use “HTML5” as a broad term contributing to its decline.

And I don’t care whether something is in a document called “HTML5” or not. What matters is what the browsers support, provided they communicate with W3C in the process. (And everybody is very serious about that nowadays. Whatever else happens, we won’t slip back into a Browser War. That danger has gone forever.)

But it seems one more round of pointless semantic purity discussions is called for, and many will rise to the occasion. Not me, though.

Let’s move on, shall we?

Front-Trends in Warsaw, 21/22 October

On 21 and 22 October the first Front Trends conference will take place in Warsaw. I will be speaking there; I’ll talk about JSON over SMS and other exciting marriages of web and mobile.

Tickets are inexpensive, not to say bloody cheap. € 198 to see a lot of good speakers (Douglas Crockford, Tantek Çelik, Dmitry Baranovskiy of Rafael.js, plenty of others) is not expensive.

So if you’re in the neighbourhood, why not join us in Warsaw? As of this writing there are still tickets available.

Four mobile links

Here are four interesting mobile articles that caught my eye in the past 24 hours:

]]>

Your mobile app is spying on you. About the danger in free apps.

The study also found that a large proportion of apps contain third-party code with the capability to interact with sensitive data in a way that may not be apparent to users or the developers of the apps themselves. The third-party code is generally used for advertising or analytics. The project found that 47 percent of free Android apps included this third-party code, while 23 percent of free iPhone apps use it. Third-party code represents a security risk because it is difficult to update (and patch a vulnerability) on a global basis. Apple changed its terms of service for the iPhone recently because of its concerns about what third-party analytics and other companies were doing with private data.

Nokia’s JavaScript Peformance Best Practices. Contains a lot that was taken from Steve Souders’s research and common knowledge, but also a few things I’ve never heard before. I’d really have to do an evaluation of some of the practices. Also contains a few ugly-but-necessary tricks for Symbian WebKit (S60).

Also from Nokia: Introducing Ovi Browser Beta for Series 40. Nokia, too, has produced a mini-browser that relies on a server for the actual rendering and sends out the fully-rendered page, just as Opera Mini does. Now I need to lay my hands on an S40 device so that I can test it.
Update: WAP Review tested it; and confirmed you really need an S40 device.

From Bruce Lawson at Opera, finally, comes Mobile-friendly: The mobile web optimization guide with useful tips and tricks for making your website mobile-friendly.

[...] mobile users are in a hurry; they're on the go and want to perform one specific task and then finish. A common example cited is that of a restaurant site. The mobile user wants to find the location, the menu and the opening hours so, the argument goes, the mobile site should contain this and nothing else.

This is a good argument, but it's only half true. If it were 100% true, what would be on the "full" website? Presumably, a movie of the decor, some atmospheric music, animated representations of the house special dishes, and a downloadable menu in some fancy font. The fallacy here is that users of desktop computers are not task-focussed and have time to waste on an immersive branding experience.

Opera’s problems on mobile

In the mobile browser space all the advanced browsers are based on WebKit. That’s fine — WebKit is an excellent rendering engine — but if all browsers were based on WebKit I would start to worry about a monoculture. At least some browsers should be based on other rendering engines, as far as I’m concerned.

The only serious mobile candidate for “other rendering engine” is Opera. But I’m starting to wonder whether it can keep up with the WebKit browsers. With the recent release of Samsung Dolfin Opera Mobile has firmly dropped from third-best to fourth-best mobile browser on my list.

The problem is not that Opera isn’t innovating. It is. But I’m starting to wonder about the direction that innovation is taking.

]]> Witness the recent release of Opera Mobile 10.1 beta for Symbian (on my 40th birthday; thanks, guys). I went through the press release, which highlights the following changes:

Geolocation is now supported (although it doesn’t give the coordinates in my test page). That’s cool; it’s definitely something that’s extremely important on mobile.
Vega graphics library and Carakan JavaScript engine. That’s fun to have, but I’m not sure if it’s the most important step Opera could have taken right now. I’ll get back to this.
Various improvements to the user interface.

And that’s it, according to the press release. (border-radius is supported, maybe some other stuff too, and there will be some bug fixes here and there, but I haven’t yet studied it sufficiently to give you a full list.)

Relative importance

Nowadays all desktop browsers are innovating like mad in their JavaScript engines. For about a year and a half or so, significant improvements in JavaScript speed have been the Holy Grail of browser making, and every new release of every browser now routinely claims to be the fastest browser available.

(So routine has this claim become that I do not believe any of them any more. Besides, as far as I can tell they’re all testing JavaScript Core speed, while the biggest bottleneck is the speed with which DOM changes are made.)

Now on desktop this is a very important development. On mobile it’s also important, but I feel there are several other topics that are even more important than JavaScript speed, and that Opera is ignoring these topics.

Point is, a super-fast JavaScript engine is relatively worthless if you can’t properly set up a JavaScript-heavy interface. And the very first requirement for a JavaScript-heavy interface is that you always know exactly what the user is doing, so that you can react to his actions naturally and great UX is born.

It’s in the latter part of that equation that Opera Mobile has serious problems. I feel that, while innovating in JavaScript engines, Opera is forgetting basic mobile functionality without which a fast JavaScript engine is pointless.

Touch and viewport

There’s a reason I started my foray into mobile browsing by studying the touch events and the viewport dimensions. These two functionalities are absolutely vital to building compelling mobile interfaces.

The touch events allow us to follow exactly what the user is doing to the touchscreen. Without these events you can only detect whether the user clicks somewhere. That is enough for some interfaces, but others will definitely want to react to more subtle actions from the user.

The viewport dimensions are important for knowing how much of your site the user is currently seeing on his screen. An example will clarify why this is important.

I’m currently working on a little side project that involves writing the perfect JavaScript touch-scroll interface. This presupposes the touch events: without them it’s absolutely impossible to create a compelling UX.

However, I want several scrollable areas on the same page, and with that comes the problem of deciding when to allow a user to scroll. If the user has zoomed in and sees a little bit of one scrollable area on the edge of his screen, it makes sense not to scroll that area when he touches it, because it might confuse him. Instead, we should wait until the scrollable area covers most of the screen before allowing a scroll action. My prototype with this behaviour works pretty intuitively.

However, in order to know whether the scrollable area is on the screen I must be able to read out the dimensions of the visual viewport. I need to know which part of the page the user is currently viewing, compare it to the scrollable area, check their coordinates, and decide whether the user is allowed to scroll. That’s something that few browsers support right now.

Android and Samsung support the touch events, but not the visual viewport dimensions. Symbian, BlackBerry and IE support the visual viewport dimensions, but not the touch events. All other browsers, including Opera Mobile, support neither. So this script only works on the iPhone, which is the single browser to support both.

So this interface, which I feel is an example of a mobile-specific UX, will not work on Opera Mobile, regardless of the speed of its JavaScript engine. That’s what I mean when I say that I’m wondering about Opera’s direction of innovation.

Opera Mobile simply must support the touch events and the viewport dimensions.

Zooming

But Opera Mobile has an even larger problem, and that is zooming. Basically it has the worst zooming functionality of any mobile browser I tested. It seems Opera ignored the emerging standard for touch-based zooming, and instead created its own system. That’s fine, as long as the system works. But it doesn’t.

So what exactly is wrong with Opera’s zooming? Basically everything.

Two levels

Opera has only two zooming levels: in and out. Initially you see the entire page, just as on all other mobile browsers. When you zoom in, however, you go to one single pre-defined zooming level, and once you’ve arrived there your only option is to zoom out again.

This behaviour is not unique to Opera Mobile. Many other second-tier mobile browsers, such as Symbian WebKit on touchscreen Nokias, or IE, have only two zoom levels.

But there are two other characteristics that make the Opera zooming experience uniquely lousy.

Pre-emptive narrowing of text

Opera kind of pre-emptively narrows your text into columns that fit snugly in the screen when you zoom in. Although that’s excellent behaviour to display when the user actually zooms in (as Android does), doing this beforehand makes no sense and has the ability to destroy your page’s graphic design.

Here’s my compatibility master page as it should display on mobile (Dolfin on Samsung Wave). Note that the text in the table stretches all the way from left to right, as it should:

And here is the same page on Opera Mobile 10.10 (Nokia N97). Here the text in the table is narrowed to the width Opera is going to take later on, when you zoom in:

In this particular case I don’t mind much, but this feature has the ability to completely destroy a well-designed page. As far as I know you can’t do anything against this effect and will have to accept the damage it does to your page.

Single tap

But by far the worst feature of Opera’s zoom is the user interaction. On touchscreens an industry standard is emerging for zooming. You either pinch-zoom or you double-tap. Some browsers don’t support pinch-zoom, but the double-tap works pretty well, too.

However, Opera in its wisdom uses not a double-tap but a single-tap interface. Tap once when zoomed out and you will zoom in on roughly the area you tapped on.

This is terrible. In order to understand why, take a look at my Touch test page. It’s fully zoomed-out:

This is how I designed the page: I want it to be usable even fully zoomed-out. Thus I can load the page, hit Record, and record an event sequence of my choice.

But what happens in Opera Mobile when I hit Record with a single tap in order to start recording? It. Bloody. Zooms. In! That makes my test page much harder to use.

To be fair, Opera Mobile 10.10 does not zoom at all in pages that have a , as my test page has. That solves this particular issue, but I feel it’s still a stop-gap solution. All other browsers do allow the user to zoom in on a -enhanced page. (Some even allow you to zoom out.)

Opera’s problems

Concluding, Opera Mobile has a serious zoom problem that must be addressed in addition to the touch event and viewport dimension problem.

I feel that addressing these issues is more important than yet another faster JavaScript engine or yet another UX upgrade. Besides, as long as zoom remains lousy the UX can be upgraded only so much. Zooming is a fundamental part of the mobile UX; without it many other innovations just don’t make sense.

So in order to remain relevant on the highest tier of mobile browsing, Opera will have to concentrate on three things:

Fix zooming: double-tap interaction, many more zoom levels, no pre-emptive narrowing of text columns.
Support the touch events.
Allow us to read out the viewport dimensions.

I more-or-less expect the busy engineers in Oslo to be working on these problems, and I assume that the next major Opera Mobile upgrade will bring significant improvements here.

If it doesn’t, I’m afraid Opera is out of the race for the top spot. That is not necessarily bad: it could always forget about the top tier and instead concentrate on the low-end smartphone market. Right now Opera Mobile is available only for Symbian and Windows Mobile, and on those operating systems it’s the best available browser.

Without a serious upgrade of mobile-specific functionality ruling this second tier is the best Opera can hope for. The top tier will be WebKit-only.

Mobile payments made easy

This is just in: Google seems to be taking steps to allow operator billing. If that’s true it’s huge news.

Note from the outset that the article doesn’t say in so many words that operator billing is coming, although it certainly gives that impression, and plenty of publications translate it as such.

The basic idea of operator billing is very simple: if you want to buy an app, or access to online content, the price is automatically added to your operator bill (or, I assume, deducted from your pre-paid account).

]]> Now I’m not a mobile billing specialist by any means, but I still want to give you an idea of what we’re talking about. If I make any technical mistakes, please correct them in the comments.

The billing process

Just yesterday I made my first Android Market purchase, and although the process was relatively smooth, I still had to fill in all my credit card stuff, make mistakes, being told off, etc. Besides, when I tried to do the same a few months ago, the Android Market rejected my credit card. Why? Probably because the Dutch market wasn’t active yet — but I thought of that only much later. At the moment I was pretty pissed.

Now with operator billing I wouldn’t have all this hassle. I’d just click on whatever I want to buy, give a one-time confirmation “Yes, I do want to spend € 2.39 on this” and be done. When my next operator bill comes around, the € 2.39 will be added to it.

In addition, operators can verify your identity through your SIM card, without you having to do anything. No more hassle with credit card numbers. (In fact, the only parties that have a lot to lose from operator billing are the credit card companies. Expect resistance from them; they’ll probably say it’s unsafe or something.)

Thus operator billing is by far the most user-friendly way of making mobile purchases. That’s what makes it so important. Besides, it also opens up the mobile marketplace to those that do not have a credit card.

A question of identity

However, Google’s rather vague announcement does leave some questions unanswered. No doubt that’s because Google is still figuring out how to answer those questions. But let’s review them anyway:

What do I have to do in order to make a purchase? A one-step system is within reach; I hope it will be implemented.
How will my identity (and thus my bill) be verified?
How will the various parties communicate?

The last question is probably the most important one. If I want to make a purchase through operator billing, there are three parties involved: me, the selling party, and the operator. Somehow, the selling party has to connect to the operator to figure out exactly who I am, and to make a request to put € 2.39 on my bill for my purchase. In addition, the operator has to pay that money (maybe minus a fee) to the selling party.

The JIL 1.2 API gives us some clues as to how this system is going to work. This API, that will eventually be implemented in Vodafone 360 phones as well as, one hopes, many others, has two properties that are meant specifically for operator billing (p. 16):

Widget.Device.AccountInfo.phoneUserUniqueId
Widget.Device.AccountInfo.phoneOperatorName

Thus, when purchase times comes around, the store has some grip on your identity. It will have to send off a communication to the specified operator stating that user with unique ID X wants to make a € 2.39 purchase.

The operator will have to make some effort to verify this information; after all I might be able to hack a phone to send false unique IDs. Thus the operator will probably send me an SMS “Are you sure you want to purchase product X for € 2.39?“ Once I reply to that SMS the purchase is made and downloading can commence.

Still, I hope that the process will become even more user-friendly. The same JIL specification defines a way to send an SMS from a widget. Thus, if I want to purchase something the system could automatically generate an SMS for me and send it off to the operator. Thus the operator will be able to verify my intent by comparing my unique user ID with the SIM card through which the SMS was sent. If they match the purchase is made and downloading can commence.

That’s one step less, and thus more user-friendly. Hell, if it’s implemented correctly I don’t even have to switch to my SMS application. (The operator still has to tell the store “Purchase made, proceed with download.” But a proper system will not bother me with the details.)

Unfortunately the JIL 1.2 spec does not yet contain the methods that will be used for actual payments, nor the exact workflow. Besides, it’s unclear which operators Google is talking to right now. Probably US-based ones, and of those only Verizon is part of the JIL consortium. The others might use other APIs. (Come to think of it, so might Verizon. One never knows.)

Future expansion

Let’s close on a positive note and assume that a system roughly similar to what I describe above will actually be in place in two years or so. Apart from the increased user-friendliness of the purchasing process, what will it bring?

The basic answer is Long Tail. Increased user-friendliness and the scrapping of the requirement to own a credit card may entice more consumers to make a mobile purchase. That would be good.

The real benefit will lie with developers, though. In theory, the system could be set up so that individual developers who offer one or two apps for download on their own site can also use it.

Thus the requirement to offer your wares through one or more app stores might also be scrapped. That could be especially important to cross-platform apps such as W3C Widgets. Whichever phone with whichever operator ends up at the developer’s site, they can all make a purchase, provided they support widgets.

One more nail in the app stores’ coffin would be the opportunity to make in-app purchases; say some articles from a news site or a few new levels for your game. Operator billing is explicitly meant for such purchases, too. And if we can use operator billing in our apps, too, the app store infrastructure is basically not necessary any more.

Picture the following:

I write a news reader app as a W3C Widget. Anyone can download it for free from my website.
If you like my app you can share it with your friends. Just send over the widget via Bluetooth. No more complicated user-unfriendly Send-To-Friend systems necessary.
But how do I make money? By selling access to the actual articles. Every article you want to read costs you, say € 0.02. Alternatively, you can buy a day of unlimited access for, I don’t know, € 0.99.
All the billing is done in-app through the operator. My users never have to do anything beyond saying “Yes, I want to buy this article.”

Where’s the app store in this process? Nowhere. We don’t need it any more. Wouldn’t that be something?

(I should note that although sending widgets via Bluetooth is possible nowadays — I’ve done it — the process is not very user-friendly yet. But this functionality is definitely coming; it’s not a pipe dream.)

Waiting for Google

So I’m impatiently waiting for Google to announce more details. Exactly how will their system work? What does the user have to do? Which operators? Questions, questions.

Anyway, the future of mobile payments has come one step closer.