More specifically, today I will shout at web developers who think that delicately inserting an iPhone up their ass is the same as mobile web development.

Before we start, a little thought experiment. Suppose I proposed the following:

1. IE6 is today’s most advanced browser. (Note: this was actually true back in 2000. Please bear with me.)
2. IE6’s market share is about 80%.
3. The other browsers are way worse than IE6, and developing for them is a pain; something we’re not interested in and are a bit afraid of.
4. Therefore we will develop websites exclusively for IE6.

Would you agree with those sentiments, even if we’re back in 2000 and IE6 is really the best browser we have?

Or would you reply that our sites should work as well as they can in all browsers through the use of web standards, progressive enhancement, and all the rest of the best practices we’ve been preaching for the past ten years?

I distinctly remember a time when we web developers cared about such concepts. But those times are long gone.

Nowadays we live in a fantasy world that focuses exclusively on one platform, and does so exclusively for reasons of eye candy.

We laughingly disown every single principle the web standards movement has ever stood for in the past ten years in order to swoon and drool over Apple’s iCandy and happily accept the reality distortion field that emanates from it.

The iPhone has become an obsession. If we don’t pay attention, we’ll have a mobile web that only works on the iPhone. And then we’ll have the real mobile web that wasn’t made by us and doesn’t give a shit about web standards and best practices.

Worse, it seems web developers are happy with this state of affairs. It seems web developers are congratulating themselves on excluding 85% of the smartphone users. They certainly never bother to check their sites in S60 WebKit, the largest smartphone browser in the world.

Fucking dimwits.

We’re doing exactly the same as ten years ago. We now say “iPhone” instead of “IE6,” but otherwise nothing’s changed.

No, wait, there’s one more change: the iPhone has far less mobile market share now than IE6 had desktop share back then.

Stats

Let’s illustrate that last remark with some smartphone sales stats:

1. Nokia: 39%
2. RIM: 20% (BlackBerry)
3. Apple: 15% (this 15% is obviously far more important than the previous 59%)
4. HTC: 5%
5. Other: 21% (Samsung is expected to make a major jump this year)

And here are the smartphone OS stats, also from Tomi Ahonen (whose blog I highly recommend, by the way):

1. Symbian: 45% (all of Nokia plus a bit of SonyEricsson and Samsung)
2. BlackBerry: 20%
3. iPhone: 15% (this 15% is obviously far more important than the previous 65%)
4. Windows Mobile: 6% (HTC, Samsung, SonyEricsson)
5. Android: 4% (HTC, Samsung, SonyEricsson, Motorola, Google)
6. Other: 10% (Various Linux builds, Palm, as well as really obscure stuff. Will be reinforced by Samsung Bada during this year.)

Despite the platform having only 15% sales market share we all want our mobile websites to look exactly like an iPhone app and we only want to use iPhone features.

We want to happily live forever in our fantasy world that’s filled to overflowing with fucking iPhones, and where Nokias or BlackBerries aren’t welcome. Our rationalisation machine is running overtime to maintain this illusion and filter away reality.

We’re a bunch of lousy amateurs, that’s what we are.

No “mobile web development” specialist ever mentions Nokia ever. After all, Nokia only sells more smartphones than BlackBerry and Apple combined, so there’s no reason to mention it.

Mentioning Nokia is the mark of the rude boor. The man of discernment mentions the iPhone. And mentions it and mentions it and mentions it. And then mentions the iPad, to show he is open to non-iPhone devices. The bigger the better.

Oh, and don’t bring up Android. Yes, it’s an excellent system, and yes, it could have a bright future ahead of it, but right now it doesn’t amount to anything in the global market. It certainly won’t serve as a “Hey, I do multiple platforms” alibi.

15% + 4% = 19%

Turn off the fucking reality distortion field.

Arguments

“But ... but ... ” I hear you sputter. Sputter on. You’re wrong.

UX

But the iPhone has the best user experience of any phone!

True. So what?

Whole flocks of web developers swear that their Mac is far more user-friendly than any Windows machine that will ever be invented. Still, do they develop websites only for Macs?

Safari

But Safari iPhone is the best mobile browser!

True. So what?

Firefox is the best desktop browser. (Or Opera, or Safari, or whatever.) Do you develop sites exclusively for Firefox?

CSS enhancements

But Safari supports amazing CSS-driven graphic capabilities!

True. So what?

Use these capabilities, by all means. Just don’t depend on them. Don’t stare at them obsessively for hours on end and then decide you’ve made your site “mobile compatible.”

There’s this thing called progressive enhancement. It’s a neat trick that allows you to use the iPhone’s capabilities without damaging the experience of users of other phones.

Traffic market share

But Safari iPhone has about 50% of mobile internet traffic market share! You can’t ignore that, can you?

Watch me ignore it.

First, so what? No, let me rephrase that: So fucking what? Since when does web development mean leaving 50% of your mobile users out in the cold? Since when is “I only support browsers with a large market share” a valid argument? (Answer: since we have an iPhone up our ass.)

Next, I’m not so sure if it’s true. Mobile browser detection is really hard. None of the reports I’ve read so far show how they detect browsers. Lots of mobile browsers have iPhone in their UA strings to work around browser detects that obsessed web developers have set up. Do all traffic market share reporters work around that problem? Most probably do, but we can’t be sure.

Besides, what will happen when the operators abandon the economically untenable flat rate for iPhone data traffic? Will iPhone users maintain their current traffic market share when they have to pay as they go?

US doesn’t matter

Next, many market share reports apply only to the US market, and it’s exactly these reports that are discussed most by the influential American tech bloggers.

The real mobile battle, however, will take place in Europe and Asia. The US is a sideshow. Unfortunately it’s extraordinarily hard to convince people, both Americans and non-Americans, of that fact. So let’s try again:

Contrary to every single other technical advance of the last 50 years, mobile did not start in the US, and the US has always been somewhat behind Asia and Europe. For instance, SMS only really took off with the Obama campaign, while the rest of the world became addicted to it years ago.

While North America has 17% of the world’s internet users, it has only 7% of the world’s mobile users. Europe (22%) and Asia (45%) have the same figure for both.

The US market doesn’t have any predictive value for the rest of the world, either, because Nokia is absent. It’s just a small niche market.

That means that, contrary to every other branch of tech, American mobile opinions just aren’t very important to the rest of the world. For the American market, yes, of course they matter. For all other markets, don’t listen to them.

The problem is that too much of the rest of the world takes its cues from the well-read US tech bloggers that have made obsessing over Apple and Google while being blissfully unaware of the rest of the mobile ecosystem into a fine art.

In the medium run the problem will solve itself. Either the US bloggers will catch up with mobile reality, or they will cease to be read. I’m guessing the former. They’re not stupid.

Our fault

But with all that said I still have no reliable traffic market share figures. So let’s accept that 50% of all mobile web traffic comes from the iPhone. Or 30%. Or 70%. Whatever. Far more than its sales market share, in any case.

Point is, that’s our fault.

I can vividly imagine an S60 WebKit user getting tired of shitty websites whose developers were too busy playing with their iPhones to bother with the largest worldwide smartphone browser.

We web developers are doing an amazingly lousy job right now. We have to start serious mobile testing instead of just playing around with our iPhone for a few minutes before declaring our site fit for mobile.

Supporting all browsers is the whole fucking point of being a good web developer, and I’m going to force you to do it even if I have to personally swear at each of you individually.

Remove iPhone from ass

I’m sick of the travesty that calls itself “mobile web development” but mostly amounts to Apple-obsessed idiots with iPhones so far up their asses that their brains are starving for oxygen.

Do you ever see any mainstream mobile web development article that talks about S60 WebKit or the (lousy) BlackBerry browser? Due to our iPhone obsession we are deliberately not paying any attention to a user group that’s four times as large as the iPhone.

We have come full-circle back to developing for only one browser. Worse, we are congratulating ourselves on that bit of cleverness. Christ, do we really have to go through the whole standards movement once again?

True, the default browsers on Nokia and (especially) BlackBerry phones are less advanced than Safari iPhone, but so what? Dealing with them is the job we signed up to do. Besides, Nokia and BlackBerry are fully aware of the situation, and I expect significant improvements during this year. And if not, there’s always Opera.

As to traffic, Nokias and BlackBerries may consume less that their fair share, but as I said earlier that’s our fault. We can’t use the mess we created as an excuse to create an even larger mess. Besides, which web developer ignores 85% of his potential users? (The answer, obviously, is: one with an iPhone up his ass.)

Work to do

Web developers should take a look at their sites on a Nokia and a BlackBerry and fix whatever’s wrong. It isn’t that hard to get your hands on a testing device. Just ask around or use PerfectoMobile. (I do not trust emulators, so I don’t recommend their use.)

Install Opera Mini on the device, and also install Opera Mobile if you have a Nokia. Check in both. The native browsers are more important, though.

Oh, and remember: Fixing a site for a browser does not mean making sure the complete feature set works in that browser. Use progressive enhancement. Lots and lots of it. Especially on BlackBerry. That’ll keep you sane.

Finally, I’ll be monitoring new mobile web publications, and I’m thinking of instating an “iPhone Up Ass Award” for the mobile web development article that ignores reality most effectively. You have been warned.

If you write an article about mobile web development, I expect you to devote a significant chunk of it to one or two specific Nokia or BlackBerry phones. Show you can look further than just the latest fad and see the mobile web in its entirety.

To those who still want to blather about seamless UX and swoonworthy CSS and all the rest of the bullshit: why don’t you fuck the fuck off and go wank your stupid iThingy elsewhere? If you’re not interested in universal access you’re not a real web developer and you don’t belong on the mobile web.

As for the rest of us, we’ve got work to do.

That’s a fair question. It deserves a fair answer.

Right now, iPhone and Android support the touchstart, touchmove, and touchend events. Let’s say my advice is accepted and future browsers also support the touchenter, touchleave, and touchhold events.

The point here is that this series of events isn’t that different from the mouse events. Respectively, mousedown, mousemove, mouseup, mouseover, and mouseout fulfill the same role as the first five touch events. The touchhold event does not have a direct mouse equivalent, but it basically fulfills the same function as a right-click detection script.

So if mousedown is really the same as touchstart, why bother with new events? Can’t we just write a mousedown script that is triggered when the user depresses his mouse button OR touches the screen?

The issues

As far as I can see there are three fundamental issues involved:

1. Touch interaction is different from mouse interaction. Not hugely different, but different enough to warrant separate events.
2. It MUST be possible to write ONE single JavaScript file that works optimally in any circumstances, on the desktop, in a mobile browser, or in a widget manager, with the user using the touchscreen, the mouse, or the keyboard, as he sees fit. That implies the web developer MUST be able to distinguish between mouse-driven and touch-driven interaction.
3. The mouse events have already been implemented as legacy events in all touchscreen browsers. They all fire after the user releases the screen.

Let’s study these issues a bit further.

Issue 1: difference

Although at first sight it seems as it touchstart is equal to mousedown, touchmove to mousemove, and touchend to mouseup, this is not really the case.

Take a look at my second scrolling layer script. It was written for touchscreen phones, and works perfectly if the browser supports the touch events. Currently only iPhone and Android do.

I added the mousedown event to touchdown, mousemove to touchmove, and mouseup to touchup. Try it in a normal desktop browser. You’ll find that, although the script works, the interaction just doesn’t make sense. The mouse events aren’t quite the same as the touch events, even though they’re pretty similar.

For more fun, try using it with a touchpad.

If you really want to have fun, try the script on a Nokia S60v3 device, which has a pseudo-cursor and implements the mouse events exactly like desktop browsers. The script works ... in a way.

Question to UX experts: how should the scrolling layer work when the user has a mouse?

In other words, we need a different interaction model for desktop browsers. That requires us to first make a distinction between mouse-driven and touch-driven browsers. But how?

Issue 2: one file

There’s one extra requirement: I absolutely want to be able to deliver one single JavaScript file that contains all the scripts necessary for all interactions. And obviously I do not want to use a browser detect at all in order to determine whether a certain browser needs the mouse or the touch version.

So how do we distinguish between the two? Simple: see if a touchstart event fires. If it does, the browser is certain to be a touchscreen device and we should disable the mouse events.

It would work something like this:

var testEl = [the element you want to do something with];
testEl.onmousedown = function () {
	// initialize mouse interface
}
testEl.ontouchstart = function () {
	testEl.onmousedown = null;
	// initialize touch interface
}

This works fine. The touchstart event fires before the mousedown event, and therefore we can wipe the mousedown event handler before it’s ever executed.

A really proper script would have a third interaction model for using the keyboard. I haven’t written that yet because it’s somewhat more tricky than the touch/mouse one. I will have to deal with S60v3, where the “arrow” keys guide a pseudo mouse cursor across the screen and both the mouse and the key events fire. Besides, the user may alternate between the keyboard and either a mouse or a touchscreen.

Still, we can use a similar trick here: we know that the user is using a mouse if the mousemove event is detected. More specifically, if two mousemove events are detected within a short period of time. After all, all mobile touchscreen browsers will fire one (and only one) mousemove event when the user releases the screen, and that does not constitute evidence for a mouse-based interface.

Of course we can only distinguish them if keyboard use fires different events than mouse use. As we know it does: the keydown, keypress, and keyup events have long been supported by all browsers. Imagine a browser in which depressing a key would fire a mousedown event!

This sort of distinguishing between different interaction models is only possible if the three models use different events. If the touch actions would also use the mouse events, it would be impossible to distinguish between the two.

Issue 3: prior art

Finally, let’s repeat it once more, all touchscreen browsers (with the sole exception of the two Vodafone Widget Managers) already fire all mouse events in one long cascade when the user releases the screen.

We shouldn’t require all browsers to change this behaviour. First of all it doesn’t make sense, and secondly they won’t all do it, leaving us stuck with an impossible situation where some browsers support the mouse events as if they’re a desktop browser, and others as if they’re a touch browser. That’s a recipe for disaster.

Separate touch events

So I strongly believe that all mobile touchscreen browsers MUST (in the sense of RFC 2119) support separate touchstart, touchmove, and touchend events and relegate the mouse events to legacy status.

Web developers will benefit from this since they can easily distinguish between the various interaction modes and create scripts that are suited to every one of them.

Apparently, the touchstart event object persists in browser memory even when the event has long ended. More importantly, it continues to be updated with information about the current touch action.

This is interesting. It’s also profoundly different from the desktop, where a similar trick with the mousedown, mousemove, and mouseup events definitely does not work.

Both iPhone and Android display this behaviour. Therefore future implementations of the touch events should, too.

An error

While tinkering with my scrolling layer test page I found out that I’d made an error in the first version. Oddly, this first version worked absolutely fine on both iPhone and Android; that’s why I didn’t notice the error at first.

I just plain forgot to give the e argument to the touchend function. The script got its touchend information from the touchstart event object:

var testEl = [the scrolling layer];

testEl.ontouchstart = function (e) {
	// do stuff
	var origin = getCoors(e);
	testEl.ontouchmove = moveDrag;
	testEl.ontouchend = function () { <-- forgot the e
		var end = getCoors(e);    <-- e is touchstart object
		// do stuff
		testEl.ontouchmove = testEl.ontouchend = null;
	}

	function moveDrag(e) {
		var currentPos = getCoors(e);
		// move layer
	}

	function getCoors(e) {
		var coors;
		if (e.touches && e.touches.length) { 	// iPhone
			coors = e.touches[0].clientX;
		} else { 				// all others
			coors = e.clientX;
		}
		return coors;
	}
}

I found the error because I wanted to make the script desktop-compatible in order to prove that from an interaction point of view it makes no sense to just swap the mouse events in place for the touch events.

I added mousedown, mousemove, and mouseup event handlers, saw an abrupt stop in Firefox instead of the smooth stop, and discovered the missing e. Incidentally, this proves that the mouse events do not have persistent event objects (something we’ve known for 10 years, but still).

Using one touch object

My curiosity played up. Apparently, handling the touchend event with information obtained from the touchstart event object works fine. Could I rewrite the script so that it only uses the touchstart event object, and entirely ignores the touchmove and touchend objects?

The answer turns out to be Yes. The following script works fine on iPhone and Android:

var testEl = [the scrolling layer];

testEl.ontouchstart = function (e) {
	// do stuff
	var origin = getCoors();
	testEl.ontouchmove = moveDrag;
	testEl.ontouchend = function () {
		var end = getCoors();
		// do stuff
		testEl.ontouchmove = testEl.ontouchend = null;
		setTimeout(checkOneLastTime,1000);
	}

	function moveDrag() {
		var currentPos = getCoors();
		// move layer
	}

	function getCoors() {

		// e refers to the touchstart event object
		// even if the getCoors function is called
		// ontouchmove or ontouchend. Works fine

		var coors;
		if (e.touches) { 			// iPhone
			coors = e.touches[0].clientX;
		} else { 				// all others
			coors = e.clientX;
		}
		return coors;
	}

	function checkOneLastTime() {
		alert(getCoors())	// works! event object still there
	}
}

In other words, the original touchstart event object persists even when the touchstart event itself has long ended. Even better, it continues to be updated with new information, such as the current touch coordinates.

I also read out the touchstart event coordinates one second after the touchend event fired, i.e. when the entire touch action had totally and irretrievably gone. The event object was still there, although its coordinates weren’t updated any more and it ignored new touch actions.

I also tested whether the same is possible with the touchmove event. The answer is Yes: a similar trick that uses a touchmove event object to retrieve information about the touchend event works.

One could think that there is in fact only one single event object that all touchstart, touchmove, and touchend events use. This turns out not to be the case (though it’s an interesting idea).

When I added the missing e to the first version of the script it stopped working on the iPhone. The script now used the touchend event object, which did not contain the touches list because there were no longer any touch actions going on. I had to move to the changedTouches list to get the coordinates I need.

This proves that all events still cause unique objects to be created: the touchstart one contains a touches list; the touchend one doesn’t.

Concluding, you can easily handle the touchmove and touchend events by using the information contained in the touchstart object. There is no need to access the touchmove and touchend event objects.

I wonder if this has performance implications. It probably won’t; the touchmove and touchend event objects must be constructed anyway, since the browser has no way of knowing we won’t use them. (Unless you use only one single event object for an entire touch action sequence.)

Disclosure: This research was ordered and paid for by Vodafone. Nokia, Microsoft, Palm, and RIM have helped it along by donating devices to me.

When a user touches the screen of a touchscreen phone, sufficient events should fire so that web developers know what’s going on and can decide what actions to take. Unfortunately most mobile browsers, especially Opera and Firefox, are severely deficient here.

The touch action is way overloaded, and most browsers have trouble distinguishing between a click action and a scroll action. Properly making this distinction is the only way of creating a truly captivating mobile touchscreen browsing experience.

The iPhone’s touch event model is excellent and should be copied by all other browsers. In fact, these events are so important that I feel that any browser that does not support them by the end of 2010 is out of the mobile browser arms race. There’s only one problem with the iPhone model, and it’s relatively easy to fix.

I have created a drag-and-drop script that works on iPhone and Android as well as the desktop browsers, a multitouch drag-and-drop script that works only on the iPhone, and a scrolling layer script that forms the basis of faking position: fixed on iPhone and Android, who do not support that declaration natively.

I will hold a presentation on my research at the DIBI conference, Newcastle upon Tyne, 28th April. It will likely include future discoveries and thoughts.

• Browser vendor advisory paper on the touch events.
• Compatibility tables.
• Test page.

Problems with the touch actions

One of the most serious problems of the current touchscreen interfaces is that the touch action is way way overloaded. When the user touches the screen he may want to start a click action, a scroll action, or a resize action. Distinguishing correctly between these three actions is what sets a good touchscreen interface apart from a bad one.

This is especially important with regard to the click action. Far too often, an intended click on an element does not work because the user moves his finger a tiny little bit during the action, and the operating system concludes he wants to perform a scroll action instead. The page does not really scroll because the user does not really move his finger, but the click action is canceled, and this results in a seemingly unresponsive interface.

This problem is especially severe in the Samsung WebKit that runs in the Samsung H1 and M1 Widget Manager, but it occurs on other operating systems, too.

Only iPhone and Palm have really solved this problem; the other browser vendors are in various stages of catching up.

Current state

Events can be divided into three groups:

1. Touch events that describe the exact actions of the user on the screen without reference to the result of these actions. Examples: touchstart, touchmove, touchend.
2. Interface events that describe the result of the touch action. Examples: click, resize, scroll, contextmenu.
3. Legacy events that fire because many sites depend exclusively on them. Examples: mouseover, mousedown, mousemove, mouseup.

The touch events are supported only by iPhone and Android, in that order. Even multitouch Androids do not support more than one series of touch events (i.e. more than one finger) at a time.

All browsers support the legacy events, although some don’t support all of them. Still, this is largely irrelevant.

The real chaos is in the interface event group. Most WebKit-based browsers support most events reasonably well, but all others, including Opera and Firefox, don’t support them at all or make a mess of them. That’s annoying, because it’s these events that actually tell us what the user is trying to achieve.

Touch events

The touch events are touchstart, touchmove, and touchend. As you’d expect the first fires once when the user initially touches the screen, the second continuously while the user is moving his finger, and the third when the user releases the screen.

See Touching and Gesturing on the iPhone for more information on how the touch events work on the iPhone. I do not repeat this background information in any of my articles.

All browsers MUST (in the sense of RFC 2119) support these events at their earliest opportunity. Any browser that does not support them by the end of 2010 is out of the mobile browser race.

The touch events are currently supported only by iPhone and Android. There are a few differences between their models:

1. The iPhone also supports the gesture events, which fire when more than one finger touches the screen. I’m not yet totally sure how useful they will be; I’d like to see (or create) a practical test script first.
2. The iPhone stores information about the touch, notably the coordinates, in a special touches interface, while the Android stores them directly on the event object itself.Google is right, and Apple is wrong. I explain why in my advisory paper.

There is also the touchcancel event that fires when the user’s touch is “canceled.” I haven’t yet studied it; I feel that it’s useful only in a very few edge cases.

The touchmove and touchend events also fire when the touch action moves out of the element where the touchstart event took place.

If a touch action moves into an element, touchstart generally fires. I’m wondering if we should use touchenter instead, which in turn presupposes the existence of a touchleave event.

I’m also wondering whether we need a touchhold event, and whether the touch events should return an area instead of just a coordinate of a single pixel.

Interface events

The interface events fire when the user actually takes an action instead of aimlessly touching the screen. These actions include:

1. Clicking on a link or otherwise activating an element. The click event should fire.
2. Scrolling. The scroll event should fire.
3. Zooming. We need a new zoom event for this situation. Currently a few browsers fire a resize event instead, but that’s not good enough, and it might be that resize should be assigned to another situation entirely. I need to do more research on this.
4. Calling up a context menu. The contextmenu event should fire. More in general we might need a touchhold event that fires when the user touches the screen and holds his finger in place, whether or not a context menu pops up. On the other hand, this event is pretty easy to fake in JavaScript.

Browser compatibility is a bloody mess:

1. The click event fires in all browsers.
2. The scroll event does not fire in Opera, Samsung WebKit, Firefox, MicroB, and NetFront when the user scrolls.
3. The zoom event does not exist yet; I’ve invented it during my research. We need it badly, though.
4. The contextmenu event does not fire when a context menu appears in Opera, Android, MicroB, or NetFront. It fires correctly on Iris and IE. The other browsers do not have a touch-based context menu.

Legacy events

Current websites are created exclusively for desktop, and they use the legacy events extensively. Since mobile browsers want to give their users access to the “fixed” web, they have to support these legacy events.

Still, the touchscreen environment is not the same as the desktop environment. Most notably, a mouse action on the desktop is not equivalent to a touch action on a phone. The user of a touchscreen phone needs to touch the screen for pretty much any action (zoom, scroll, click), something that is not true for a mouse.

This is how the legacy events work currently:

1. If a touchstart and a touchend action occur on (roughly) the same coordinates this constitutes a touchclick action. The legacy events are fired, as is the click event.
2. The legacy events are mouseover, mousemove, mousedown, and mouseup. The event order may differ, but that doesn’t matter. In addition the :hover styles, if any, are applied to the element.
3. Only one mousemove event fires.
4. When a touchclick action occurs on another element, the mouseout event is fired on the original element and the :hover styles are removed.
5. The dblclick event is not supported. (It’s totally useless, anyway.)
6. The Vodafone Widget Managers fire the mousedown event when the user initially touches the screen.
7. S60 Widget Manager (Opera-based) and IE try to fire continuous mousemove events.
8. Thus, the S60 Widget Manager in theory allows a mousedown/mousemove-based drag-and-drop. In practice performance is so painful that I advise you not to bother.
9. iPhone and S60 WebKit cancel the rest of the events if a DOM change occurs onmouseover or onmousemove. I’m sure this is a good idea in the short run, but the mobile space will have to emancipate itself from the “fixed web” and this rule must eventually disappear.
10. BlackBerry and NetFront do not support the mouseover and mousemove events.
11. Palm, Samsung and Firefox do not support the mousemove event.

Drag-and-drop and position: fixed

In addition to the official test page I created the following tests:

1. A drag-and-drop script that works on iPhone and Android in addition to the desktop browsers. The trick here is removing the mouse events when the browser turns out to support the touchstart event.
2. A multitouch drag-and-drop script that works only on the iPhone. Android does not support more than one finger at a time.The iPhone handles the touch event properties wrongly.
3. A scrolling layer script that works on the iPhone and Android. Remy Sharp pointed out that it also contains the solution to getting position: fixed to work on the iPhone and Android. Essentially, if you make this script vertical instead of horizontal it’ll create a scrollable layer between “fixed” panels. There are various tricky bits involved, though, and I’ll have to return to this problem later. Still, we now have the basic solution.

iPhone clickable area

I suspect that on the iPhone the actual clickable area is slightly shifted downwards with regard to the visible HTML element. That is, a click just below the element may also be counted as a click on the element itself. This does not go for the area just above the element.

To try it for yourself, use the multitouch drag-and-drop. Try it in normal vertical orientation first, and try to touch the element as low as possible. Then turn the device 180 degrees and try again. You’ll find that you have to touch the HTML element distinctly higher now.

I’m still trying to figure out how to officially prove that Apple does this; maybe I’ve misinterpreted the test results.

iPhone documentation is lousy

Finally, during my research I noticed time and again how unbelievably lousy Apple’s Safari iPhone documentation site is. I advise developers to use my pages instead — as usual.

Part of the problem is the content; once you get to the correct page you will find a terse summary of the situation that is correct as far as it goes but mostly leaves out stuff that doesn’t fall exactly in the page’s topic, even if it’s closely related.

Worse, the invention of the cross-reference has taken Apple completely by surprise. I wish I could say it’s scrambling to catch up, but it isn’t. No cross-references whatsoever. Anywhere.

Try it yourself. Go to the TouchEvent page. It contains absolutely zero reference to the crucial TouchList interface that exposes useful information about the touch events. There is in fact a workable page about TouchList. Try to find it from the TouchEvent page. You won’t.

Alternatively, try finding the same information from the Safari Reference Library home page. Search works — if you know what to search for. The official navigation is absolutely useless.

Apple’s pseudo-frames or something also drive me crazy. The keyboard focus does not snap to the actual documentation page, which means I initially can’t scroll. (Firefox)

Apple, please fix.

As longtime readers may remember, I was totally burned out at the end of both 2007 and 2008. I’m happy to report that that trend has been broken; although I was glad to have a little holiday at the end of 2009, I returned to work without noticeable problems. So that’s good.

However, I have decided that certain aspects of my professional life are in need of a change; notably my public speaking and my compatibility tables.

Basically I’m going off the conference track for a while in order to spend more time with my mobile phones.

I will honour agreements made beforehand, which means I’ll speak at the following occasions:

1. Transmissions 3, Manchester, 28th of January, together with Chris Mills. The focus of this meeting will be the mobile Web.
2. Technique Retreat, 29th to 31st of January in Morecambe, near Manchester. Here I’ll be a trainer and workshop leader. If you want to do a bit of JavaScript or mobile web development with me around to help you, sign up. There’s still a few tickets left.
3. Dutch: Sessie op de Howest te Kortrijk over het mobiele web, in de week van 29 maart.
4. The DIBI conference in Newcastle upon Tyne, 28th of April. I’ll speak about the mobile Web.
5. It’s possible one item will be added to this list.

After that, though, I will be very reticent in accepting new speaking gigs. The problem is not the speaking itself or hanging around at conferences with interesting people and beers, but the travel.

I have to travel to Düsseldorf at least once per month, and that’s OK because it’s always interesting and I’m also paid for this effort. Besides, I can do it by train.

Conference travel usually involves flying, though, and the latest round of air-travel-related hysterics starts to grate on my nerves. Once more we see an addition of pointless security measures that won’t make us much safer but will annoy the hell out of everybody in addition to cheerfully violating every single aspect of our privacy.

I object to the whole scare stuff; this is exactly what the bad guys want, and right now authorities around the world are being, well, authoritative and authoritarian in order to reinforce the terrorists’ message. Stupid idiots.

I especially object to the requirement to put bananas in my ears for the entire duration of the flight in order to scare away the terrorists.

So I’ve decided not to come to SxSW this year. It will be hard on me once the happy tweets start to come in, but flying to the US is becoming less and less attractive, as is the formal content of SxSW. (The parties will be great, I trust.) I have no further US travel planned this year, and as far as I’m concerned I will not plan any, either.

In addition, conference speaking involves a significant investment of time, and I find myself less and less willing to do that, mostly because it leaves me too little time to do the fundamental mobile research I’m paid to do and want to do. Besides, I have an awful lot of writing to do about the mobile space, and that, too, is something that’s suffering from my being on the road so often.

Finally, I’ve given up JavaScript speaking entirely, and that has reduced my value as a speaker. Traditional web conferences aren’t really interested in the mobile Web as yet. That’ll change, but not this year.

Theoretically this loss of speaking gigs could be offset by invitations for mobile conferences, but it turns out that the mobile world has a strong cultural bias against paying flight and hotel for speakers.

So I’ll have significantly less conferences this year than the past few years. Actually I’m looking forward to that.

Compatibility tables

The second change is my view of my compatibility tables.

A year ago I already noticed that I became less and less interested in measuring the desktop browsers’ compatibility. Everybody just supports all the standards, even IE, and in my last round of desktop testing I did not encounter even one juicy new bug. Great for web development, boring for me.

I’ve been into the mobile Web for eleven months now, and there’s little chance I’ll ever return to the “fixed web” and its fast-decreasing problems. That will have consequences for the tables.

When I started my mobile research last March I automatically opened my desktop test pages on mobile phones and as usual started to create tables with test results. There were far less problems than I expected; even purportedly bad browsers such as BlackBerry, NetFront and Obigo supported quite a bit of CSS and JavaScript.

However, now that I’ve worked on the mobile browsers for a while it’s becoming increasingly apparent that I’ve been testing for the wrong stuff.

What I’m doing in the tables is atomic feature testing. Does browser X support the + selector, or querySelectorAll, or whatever? It turns out that this is the wrong question for mobile.

Mobile browsers have trouble not so much with atomic support, but with supporting the unified whole of web technologies. The BlackBerry browser scores surprisingly well on an atomic level, but once you actually send it a medium-complex JavaScript it gives up and hangs. That’s something you’ll never figure out when you only run tests like mine.

So I’ve started to change my focus. For the past two months I’ve been doing fundamental research into several areas:

1. Window and viewport width, with emphasis on media queries. If you use @media all and (max-width: 400px), exactly which element is measured to see if it’s smaller than 400px? The answer turns out to be so complicated that I have to redo all my tests to make sure I’m right. It seems I found at least three different models.
2. If you touch the screen of a touchscreen, exactly what happens? Which events fire? How does the browser distinguish between a click and a scroll action? (The short answer is: badly.) I’m not yet ready with this research; creating the test page took more time than I thought.
3. HTML5 (according to my own definition). This is going slowly. How do you test the online and offline events on mobile phones? Ideally, I’d have to break the data connection without changing anything on the phone itself, because that’s what will happen in practice. But how?

These examples show that my mobile research will have to move beyond the relatively simple tests I’ve been doing on the desktop for so long.

In turn, that means that I have to change my compatibility tables somehow. I’m not yet sure how I’m going to change them and whether I will give up desktop research entirely.

I will continue to host the old ones even if I decide not to update them any more, so you can still come here to find answers to the more basic compatibility questions. But expect some changes to the tables.

I'm doing my damndest to evangelise HTML5 to front end developers and designers but you guys don't make it easy.
[...]
As if this stuff wasn't confusing enough for authors already. Now they have to put up with stupid spec obfuscation for the sake of some minor semantic victory for someone somewhere.
[...]
The WHATWG couldn't make the spec more author-unfriendly if they tried.

Inevitably, it was pointed out that specs aren’t meant for developers but for browser vendors. That’s true but unhelpful, just as it has been for the past ten years. The ritual dance begins anew.

Personally, I’m not going to take part in the dance this time. I already know what the outcome is going to be, and I’m going to skip the rituals.

Because “HTML5” is so vaguely defined we web developers can decide for ourselves what is part of HTML5 and what isn’t, and that’s something I’m looking forward to. (If spec defenders don’t like that they should have been clearer.)

My favourite examples are geolocation and Web Storage, which will feature prominently in my upcoming HTML5 mobile compatibility tables despite the fact that they’re not in the spec. They’re new, exciting, and absolutely vital on mobile. They’re in my HTML5 spec.

HTML5 is the continuation of Web 2.0 by other means, just as Web 2.0 was the continuation of DHTML. Apparently we need a vague, all-encompassing term for cool new stuff that we want browsers to support and clients to buy so we can play with it.

That’s what HTML5 should be. Because there are new and exciting things going on, people will start to make wish lists. Exactly which items on those lists are described in a document called “HTML5” will slowly cease to matter, as long as they have some browser support.

As soon as a certain feature appears on enough HTML5 lists it will become canonical. Conversely, the stuff that nobody’s really interested in will no longer be HTML5, even if it’s in a spec with that name.

I consider this a Good Thing. Wisdom of the crowds and all that. (Again, if spec defenders don’t like it, they should have been more accomodating to authors.)

So what’s in your HTML5 spec? Top three, anyone?

Yet.

Pretty soon, however, B. is going to spend a few months in the outlying parts of Indonesia, and during that time he has to be able to access his business bank account. He was wondering if a modern mobile phone would fit this use case, and, if so, which one.

When he told me all that I whipped out my iPhone. “Something like this, you mean?” He was suitably impressed, and when I told him I regularly have six to twelve phones lying around on my desk he practically begged for an opportunity to come by and try them all in order decide what kind of phone he wants.

That was of course fine by me. User testing is never to be despised, and since B. is not technical and has no experience with touchscreens to speak of, he is the perfect test subject.

Last week we held our session, and this entry is the report.

Tested phones: Nokia N97, Samsung M1, HTC Touch Pro (Windows Mobile), SonyEricsson W960i, Nokia E71, BlackBerry 9500, HTC Pioneer (Android), LG M900, Nokia N900, iPhone.

Set-up

B. is not technically inclined, to put it mildly. His knowledge of the Web is best summarised by this short discussion that ensued when I gave him the HTC Windows Mobile phone:

Me

[gives Windows Mobile phone with home screen activated]

B.

Ah, Internet Explorer. [Clicks on it while ignoring the Opera logo right next to it]

Me

You know what that is?

B.

Sure, it’s Microsoft’s search thingy, right?

Me

Errr ... right ... [pours stiff drink]

On the other hand, B. has an excellent idea of what he needs. He needs access to his bank account and he has to be able to take common actions.

B. knows his workflow: go to Google, search for the entry page to his banking site, go there, log in, and do stuff. I warned him he’d better skip the first step in Indonesia. The network is bound to be slow, and skipping one page load is definitely a good idea. I also revealed the existence of bookmarks.

B.’s target is Mijn ING, which is definitely not the most advanced Dutch banking site. Most of the problems we encountered were in the later, password-protected pages, so you can’t view them in your browser unless you also bank with ING. (I do, so I might take a shot at researching a few problems.)

We tested ten phones, and in all cases I made sure the phone had a connection and was on the home screen. After that I handed it over.

The original plan was not to offer B. any further help, but pretty soon it turned out I had to teach him how to zoom. Not only was he completely unacquainted with any kind of zooming, but the eight phones that have zooming capability use five different mechanisms (double-tap, pinch, Android, BlackBerry, and Maemo), and leaving B. to discover them by himself would have taken far too much time.

I also explained other interface elements I thought might help him. I’m not sure if this is good methodology, but it cut down testing time considerably.

The phones

As to the actual phones we tested, that was mostly a matter of coincidence. I’d taken a lot of touchscreens with me from Düsseldorf because I’m doing some complicated touch research for Vodafone. In addition, all four phones I received as a gift from interested parties are touchscreens, too.

I’d have loved to include the Palm Pre in this test, but at the time of writing I have not yet figured out how to skip the sign-up screen on my locked British one.

I also left out the Samsung F700 because I exclusively use it to torture UX experts. That brought the total number of phones down to ten.

Nine out of these ten were touchscreens (with the Nokia E71 as the exception). In retrospect it would have been better if we’d had one or two more non-touchscreens to test.

I decided on the testing order in advance. On the one hand I wanted to bunch up the phones I thought good toward the end of the session, because I wanted to see if they’re really that much better than all the others in the opinion of an outsider without any experience.

On the other hand I didn’t want to start with the very worst phones because that would only depress B. So I started with the most medium phone I could think of, the N97.

As a practical matter, I had to alternate wifi-capable phones with SIM-only phones in order to have time to insert the SIM card and start up the next SIM-only phone while B. was working with a wifi-capable phone. The BlackBerry, especially, needs a lot of startup time.

Finally, I decided to use the default browser on every phone. I do not believe that many non-technical users will download another browser when their phone contains one that appears to be working. Besides, I’d have to explain the “other browsers” concept to B., and I decided that that would take too much time.

The testing

I handed B. the phones in the order they’re treated below and recorded his impressions.

Nokia N97

OS

Symbian S60v5

Browser

S60 WebKit

Keyboard

hardware

Wifi

yes

Zooming

double-tap

Test result

mostly succeeded

Disclosure

phone on loan from Vodafone

Starting up an S60 WebKit when you want to use a wifi connection is a total disaster, so I did that for B., but otherwise I left him to his own devices.

Since this was the very first phone in the test, neither B. nor I had any expectations. I was mainly curious to see how he worked with the phone. In general this first encounter went rather well, especially once B. discovered the four-way navigation pad on the left.

In fact, B. took only a few minutes to figure out the single most serious problem with touchscreen interfaces. He ran into trouble when he wanted to click on something but the browser scrolled instead, or vice versa. He thought it was just him being dumb, but I could disabuse him of that notion.

The touch event is way overloaded. Touching the screen may start a click, a scroll, or a zoom action, and the less able a browser is to distinguish between these actions, the lousier the interface appears to be. Handling these distinctions well is what separates the iPhone from all other phones.

Because the links on the banking site are pretty bunched up B. had to use his nail to click on links. The discovery of the stylus two phones later helped measurably here. I forgot to explain zooming to him in this case, but the S60 WebKit zoom is lousy, anyway.

It turns out that the S60 WebKit sometimes crashes on one particular banking page. I was not able to quickly figure out whether it was a problem with the browser or a problem with the site.

Samsung M1

OS

Linux

Browser

Opera Mobile

Keyboard

software

Wifi

no

Zooming

double-tap

Test result

succeeded

Disclosure

phone on loan from Vodafone

I handed B. this phone in natural state, and not with the home screen activated. He figured out the slider by himself, but then he saw the Vodafone 360 screen (see screenshot), and his first reaction was “what a confusing interface.” Vodafone 360 can indeed be daunting if you hardly know what a social network is. B. is clearly not part of the M1’s target audience.

On this phone B. encountered his first software keyboard, and he gave it cautiously positive rating: it didn’t work as badly as he’d feared. Still, later on he revised this opinion. Especially in portrait mode the keyboard and the individual keys were too narrow.

This phone uses Opera, and this particular Opera has been extended with several interface features: Opera Fingertouch, as well as a zoomer that works by sliding a block from top (zoom out) to bottom (zoom in). This block becomes visible on double-tap.

B. used Fingertouch intuitively and without commenting on it. Not using it is not an option: if Opera doesn’t understand which link you want to click, it fires up Fingertouch. So B. had to use it, and that turned out not to be a problem.

As to the zoom, it didn’t really work for B. That is not entirely Opera’s fault; one of the M1’s problems is that the touchscreen may sometimes be a bit unresponsive when you double-tap or drag the zoom block.

All in all this phone was not a success.

HTC Touch Pro

OS

Windows Mobile 6.5

Browser

IE

Keyboard

hardware

Wifi

yes

Zooming

double-tap or menu

Test result

succeeded

Disclosure

phone is a gift from Microsoft

It was when I handed him this phone that B. and I had the short conversation I quoted at the start of this article. He started up IE and surfed to his banking account without many problems. I had to point out where IE hides its menu, but then he started using IE’s sliding zoom, which is similar to Opera’s, except that this phone’s way more responsive.

B. absolutely loved the stylus that comes with this phone, and went back to the M1 and N97 to test whether it also worked there. He kept trying it with all other phones, too, and decided to get one no matter what kind of phone he would eventually buy.

He was also glad he could once again work with a hardware keyboard. So glad, in fact, that he started using the arrow keys on the hardware keyboard in order to scroll the page, just as you would on a desktop computer.

My notes say that these keys don’t work, but when I retested it they worked as expected. However, there’s a perceptible pause in IE before the scrolling starts. Maybe that’s what threw us off track.

My particular Touch Diamond has one extremely annoying bug: when you press the “1” on the hardware keyboard, the phone goes back to the home screen. This is especially funny when your banking user name contains a “1.” Fortunately I knew we could use the software keyboard to type the offending character; it’s unlikely B. would have figured that out by himself.

As far as I’m concerned the idiot who thought up this “feature” should be taken behind a shed and shot. I asked B. not to consider it when judging the phone.

SonyEricsson W960i

OS

Symbian UIQ

Browser

Opera Mobile

Keyboard

numerical

Wifi

no

Zooming

none

Test result

more or less succeeded

Disclosure

phone on loan from Vodafone

This phone is by far the oldest we tested, and it’s easy to see that age does make a difference in the mobile space. Not that it doesn’t work, but everything is a bit cranky, and both the OS and the browser (Opera 8.65) are older ones.

This is also the single tested phone with a numerical keyboard. That was no problem; B. has been using them exclusively for years and is way faster with them than I am. He commented favourably on the small menu top-right that shows all characters that reside under a certain key.

On this phone I showed him Opera’s mobile view, in which the entire site is displayed in a narrow column that fits the screen. B. clearly liked it. Unfortunately the site didn’t: the actual data never showed up in the mobile view.

Still B. did not like this phone. Too clunky and kludgy. The only thing I regret is that I plain forgot to point out the scroll wheel on the side.

Nokia E71

OS

Symbian S60v3

Browser

S60 WebKit

Keyboard

hardware

Wifi

yes

Zooming

none

Test result

failed due to site bug

Disclosure

phone on loan from Vodafone

Now we come to the single phone B. already knew because his girlfriend owns it. As a result B. is less likely to buy it, although he readily admitted this had nothing to do with its technical specs.

Again I opened the browser for him due to Symbian’s serious mishandling of the connection between wifi and browser.

Now B. had to type in the URL to start. He touched the screen repeatedly, and I had to remind him that this is the single non-touchscreen phone in the entire test. He asked me how to enter a URL, and I had to take over the phone and use it in order to remember that you just have to start typing and the browser relegates your keypresses to the location bar.

B. absolutely loved the four-way navigation and S60’s pseudo-cursor. It made the interface much clearer to him, and he couldn’t possibly go wrong when selecting a link to click.

When we came to the actual target page, though, it turned out not to work. After the normal header the page said “fastinnerhtml” and then nothing.

Now in itself this is a true statement — I proved as much back when nobody had ever heard of performance testing. Still, it’s an odd message to show on your site. I haven’t yet decided whether the site’s programmer is a total idiot or has a wonderful sense of humor.

If the site had actually worked the E71 would have scored very well in B.’s opinion.

BlackBerry 9500

OS

RIM

Browser

BlackBerry

Keyboard

software

Wifi

no

Zooming

click (in) or hardware Back button (out)

Test result

failed due to browser bug

Disclosure

phone is a gift from RIM

Back to touchscreens. The BlackBerry came next, and pretty soon B. ran into severe interface problems when trying to click on options in the browser menu.

Now in theory the BlackBerry interface is pretty good. You have to actually depress the screen in order to activate something, but as soon as your finger touches an option it lights up in blue.

The problem is that your finger will probably move a few pixels between touching the screen and clicking on it, and it happens too often that the correct option will highlight, but you’ll click on the wrong one because of this finger sliding. This is a generic BlackBerry problem that holds back an otherwise well thought-out system.

Then, as I knew he would, B. accidentally pressed the hardware button on the left side of the phone. The screen went white, and after a few seconds a woman’s voice said “Sagen Sie einen Befehl!” (It’s a German BlackBerry.) I taught B. the proper response (“Halts Maul”) and warned him not to press the button again.

Login was succesful, but then the site sent the BlackBerry browser a lot of JavaScript, and that’s something this browser can’t handle. It just gave up after a while, as it’s wont to do, and the site did not work.

Good thing BlackBerry is going to use a WebKit-based browser in the future.

HTC Pioneer

OS

Android 1.5

Browser

Android WebKit

Keyboard

software

Wifi

yes

Zooming

move finger down and use special menu

Test result

succeeded

Disclosure

phone on loan from Vodafone

Then we came to the Android, and I had high hopes of this phone. Until now B. had only used touchscreen phones that I knew were flawed in some way or another. I was curious how he’d react to a good one. He did not disappoint. His first remark was: “Oh, this is a lot better than the previous ones!”

Still, the more B. used it the less enthousiastic he became. He deplored the lack of a hardware keyboard and again complained that it was so hard to select a link to click. When I pointed out the trackball he got the idea immediately but thought it was far too sensitive. He had to try very hard to use it right. I searched for a trackball setting, but there doesn’t seem to be any.

Filling out the login form turned out to be very hard, especially because B. held the phone in landscape orientation. In that case, one form field and the software keyboard combine to fill the entire screen, and it’s not at all clear how to proceed to the next field.

It turned out we had to press the Enter key to exit a text input. Later on I tried a textarea in landscape mode, and pressing the Enter key (correctly) added a line break, but didn’t exit the textarea. It turns out you have to rotate the phone back to portrait mode. Not ideal.

B. was imperfectly satisfied with this Android. It had given him an idea of how a proper touchscreen should work, but had let him down when it came to the details, even though he reached the banking site and could do what he wanted to do.

LG KM900

OS

LG proprietary

Browser

Obigo

Keyboard

software

Wifi

no yes

Zooming

pinch

Test result

failed due to Google Web Toolkit

Disclosure

phone on loan from Vodafone

When testing the LG phone B. was very happy with the slight vibration that accompanies every single keypress, but less so with the total lack of feedback that clicking on a link yields. Did I press the right one? Is something happening? The LG/Obigo interface doesn’t give a clue.

Still, we made progress. Until Google pulled its evil trick.

As usual, B. went to Google first in order to search for the entry link to his site. It turns out that Google in its infinite wisdom sends this Obigo browser through GWT hell, which causes the banking site to be completely unusable.

I considered delving deeper into this problem, but first asked B. if he thought this phone was a serious contender. When he said No we decided to move on to the next one.

Still, the fact that Google messes with web content is unacceptable. And GWT is an pestilence that should be eradicated from the world. Expect to hear more of this.

Late update: Four days after publishing this article I found out that this phone does support wifi.

Nokia N900

OS

Linux

Browser

MicroB (Gecko-based)

Keyboard

hardware

Wifi

yes

Zooming

move finger in circles or use hardware button

Test result

succeeded

Disclosure

phone is a gift from Nokia

Then came the Nokia N900, the first Maemo Linux-based phone, which I have high hopes of. I had to show B. the hardware zoom button at the top of the device, but once he got that the phone worked well.

So well, in fact, that while I put away the LG phone, poured some more drinks, and made a few notes, B. had already found, opened and used his banking site.

This was the first phone that he didn’t need help with at all, even for a minor issue. It just worked. And that’s rare.

B. commented again that it’s so hard on some phones to distinguish click actions from scroll actions from zoom actions, but that the hardware zoom button solved most of that problem.

When B. discovered that the HTC Touch Diamond’s pen also works with the Maemo, he became even more happy.

iPhone

OS

iPhone

Browser

Safari WebKit

Keyboard

software

Wifi

yes

Zooming

pinch

Test result

succeeded

Finally, the iPhone. I’d deliberately saved it for last, and was not disappointed. I only had to tell him the browser is called Safari, and off he was, logging in and working with his banking site. “Oh,” B. said, “so this is how a touchscreen is supposed to work.”

Finding and using the site took as little time as it had on the Maemo, and after B. was done he again tried a click, a scroll, and a zoom action, and commented that this phone did understand what he was trying to do instead of mostly guessing wrong.

He concluded that he understood the iPhone hype fully now; all the praise was well deserved.

The verdict

Finally I asked B. to rank the ten phones from good to bad. This ranking mostly confirmed the picture I had formed of the phone market, except that the iPhone and especially the Android ended up lower on the list than I expected.

1. Nokia N900 (Maemo)
2. iPhone
3. Nokia N97
4. HTC Windows Mobile
5. HTC Android
6. Nokia E71
7. LG KM900
8. BlackBerry 9500
9. Samsung M1
10. SonyEricsson W960i

B.’s most severe problem was the lack of distinction some phones make between a click, zoom, and scroll action, and this fits seamlessly into the larger picture of the market as a whole. Of the pure touchscreen devices, only the iPhone has truly solved this problem. The others are in various stages of catching up with Apple.

B. also had trouble with clicking on the right links because they’re too bunched up in his banking site. The most obvious solution to that problem is zooming, and therefore his top two consisted of the phones that allow for graceful, easy zooming.

More in general, B. is a hardware man. He consistently put the phones with better hardware controls higher on his list, with the iPhone and the E71 as the only exceptions. He has also decided to buy a stylus no matter which phone he’ll eventually get.

In the end, after much deliberation, B. put the Nokia N900 in the top slot above the iPhone.

He was extremely careful to note that he did so only because he felt that the hardware keyboard and zoom button were most conductive to his personal goal of accessing and working with his online banking site. He could imagine that the iPhone would be better suited for other purposes.

This confirms my hunch that Nokia is on the right track with the Maemo platform. The next Maemo phone, I think, will be something to watch.

To my surprise he ranked Windows Mobile above Android. Although he liked Android, it did not entirely deliver on its promises as far as B. was concerned. Windows Mobile promised less, but delivered.

Curiously, the six best phones in his opinion were also the wifi-capable phones, while the four SIM-only phones made up the bottom of the list. Apparently support for wifi is a measure of phone quality.

All in all this was a very useful session, both for B. and for me. Maybe I’ll repeat this later on, with another friend (and probably a slightly different line-up of phones).

Update: A week after this article appeared, B. told me he’d bought a Nokia N72. His reasoning was that no touchscreen save for the iPhone was good enough, and het got the N72 for free (with subscription, obviously). So no touchscreen for B.

Later update: It turns out B. bought an E72, not an N72. I installed Opera Mini on it just to be on the safe side.

John Gruber wants me to mention the Cocoa Touch framework. He feels that its excellence is an important factor in the success of native iPhone apps.

Point is, although Gruber’s probably right, he ought to be wrong.

If you have to choose between, whatever, two kinds of Web servers, picking the one with the better tools (libraries and such) is an excellent idea. They’re both Web servers, after all. The net result to your end users will be the same, but your job will become easier.

It’s different with Web apps vs. native apps.

The net result of a Web app is that anyone with a modern browser can use it, though on some devices the user experience is less-than optimal. The net result of a native app is a superior experience on the iPhone, and nothing for the rest of the world.

What do your users want you to pick, superior user experience or vastly bigger reach? Do you need device APIs, and is there a way to get paid? Those are the questions that matter right now.

Cocoa Touch is excellent. There, I said it — without having the faintest idea what I’m talking about, obviously.

But it’s just a tool. It shouldn’t matter.

My post could be construed as a rant. Hell, parts of it were a rant. (Nobody said this blogging stuff is easy, especially when you’re passionate about something. But if I can’t speak my mind here, what’s the point of having a blog?)

Several people I respect a lot said that I’d made a stupid mistake and was just plain wrong. After some thought I decided they are right.

I was wrong about Web apps being able to replace native apps right now. I was wrong about the iPhone developers’ mindset. They aren’t stupid.

While writing the current article I figured out there’s a whole lot of undigested information in my head that I instinctively used in my previous article but didn’t bother to explain properly. This is especially true for payments and the general state of Web technologies on mobile.

Despite my mistakes the whole thing seems to have kick-started a solid, sensible discussion about the differences between native apps and Web apps, and which one is better under which circumstances. I’d like to continue that discussion.

My original idea was: with a few exceptions, native apps could just as well be written as Web apps. That would bring much better interoperability as well as avoiding Apple’s insane App Store approval process.

Now let’s see exactly where I was right and where I was wrong.

It’s all about the money

The strongest argument against my idea is that the App Store offers an easy and convenient way of making money with your apps. I did in fact think about this a lot while writing the original article, but in the end decided not to mention it. That was a mistake.

Mobile payments are a complicated subject that I have my own thoughts about; thoughts I planned to discuss in a later blog entry.

I feel that the mobile operators have the strongest cards when it comes to mobile payments because they are already billing everybody and are already able to identify people through their SIM card. Their system has to be extended in order to accomodate online payments, but that seems doable. In fact, Vodafone is already doing it.

Since Vodafone is my main client now, my plan was to get some more publishable info about how it will work and how it impacts Web development before blogging about it. This crisis has forced my hand, however, so I can’t offer you the level of detail I wanted.

Suffice it to say that a system that might fulfill the same function as the App Store, but works throughout the Web on (presumably) all Vodafone devices (and possibly many more), is probably coming.

This idea was in the front of my mind while I wrote the article, but I did not realise that I had not yet explained it to my readers, nor that a system that’s not yet there has no bearing on a comparison in the present.

In addition, I have some qualms about the whole payment concept. I guess I’m just old-fashioned and long for the days where developers would develop just for the heck of it and worry about money later.

Frankly, I hadn’t factored immediate payments in my mental model of an app developer. And I should have, even though my inner geek is saddened by the thought.

Thus I’m forced to concede this point. Right now, getting paid is a lot easier through the App Store than through any other system.

Getting attention

Then comes the discoverability argument. Apparently, getting attention through the App Store is the superior way of disseminating your app. I’d like some more data on that point.

The question is: How do users find their apps?

1. By searching the App Store,
2. because friends give them tips,
3. or because of old-fashioned marketing?

I have no idea what the answer is. Anyone? I myself started with searching, and have now mostly gone to friends’ referrals, but I have no idea how representative I am.

The discoverability argument only makes sense if the answer is searching. Friends’ referrals and marketing work just as well for Web apps.

So I’m undecided pending further data.

Device APIs

As I said in the original article, device APIs that give access to device functionality like the camera, the file system, the address book, and so on, are coming. There are some security considerations, and the user will have to give permission for most forms of access, but those problems will be solved.

Geolocation is accessible from the browser already. That’s a start, but it’s not enough.

An app that requires access to device APIs will have to be native for now. Only simple location-based systems are possible on the Web side of things.

My problem is that I’ve been living with device APIs as a reality for months now, and have seen a few simple examples. I just plain forgot they’re not actually there yet.

Sorry about that.

Offline Web apps

Let’s debunk one argument. It is perfectly possible to write an offline Web app for Safari iPhone. The browser supports appcache and local storage for storing the application and its data, respectively.

Both Web apps and native apps can work offline. Thus this argument has no value.

Interoperability

Let’s chalk up one inevitable point for Web apps. They beat native apps hands down when it comes to interoperability.

To my way of thinking this is an extremely important point. A large part of my previous post was born out of exasperation that I had to explain interoperability yet again.

Could people please be made to see the value of interoperability instantaneously and naturally? Maybe implant something in their heads or something? It’d save me a lot of energy. Thanks.

Interoperability is trumped by UX in the long run, and also by easy payments and lack of device APIs in the short run.

I still feel that the developers of some iPhone apps, especially those that give quick access to specific online data (tweets or train times, for instance), would have been better off publishing something interoperable. They’re competing against similar apps, and being used by 0.1% of the entire mobile Web has much more potential value than being bought by 1% of the iPhone platform.

UX

Then we come to UX. UX is really the crux of the matter. All other problems can be solved, but UX-wise a native app will likely retain an indefinite advantage over Web apps. Still, the question is whether should give up interoperability for UX’s sake in all cases.

In my original article I already cautioned that graphic- and processor-heavy games were a special case. They cannot be ported to the Web. Whatever else it is, the browser is no immersive game platform.

But I might have overestimated the current state of Safari iPhone as a platform. Two commenters pointed out two immediate problems.

1. Safari iPhone doesn’t support position: fixed, which makes it hard to create anything remotely resembling a static menu bar.
2. When you set a click event handler on anything, it flashes when the user touches it.

No doubt some research will turn up many more such problems.

They are just browser compatibility problems, though, and I never consider browser compatibility problems show-stoppers. (No good Web developer does, but my case may be a bit more extreme than most.)

I’m going to work on the flash problem later. I have to do massive event research on mobile and desktop anyway, and the iPhone’s event model, especially where it concerns the touch action, is high on my priority list.

But if it can’t be solved, would that matter? Shouldn’t we treat it as the equivalent of the dotted outline; a sure-fire way of letting the user know he has in fact clicked on something? Should we deliberately decide to leave the effect alone, because it’s a platform usability and/or accessibility feature?

Questions, questions. These things are not as simple as they look.

Trade-off

As to position: fixed, Andrew Hedges said:

One clever developer came up with a nearly native feeling workaround using JavaScript and hardware accelerated CSS transitions, but “nearly native feeling” is just a little worse than native.

... if your goal is to emulate a native app perfectly. If that goal is so important to you that you’re willing to sacrifice interoperability for UX brilliance, yes, then a native app is the way to go.

But there’s a trade-off involved here. Do you want perfect UX, or do you want decent interoperability? Does it make sense for every single app to choose UX over interoperability? As I said above, I feel there’s a category of apps where the latter might be more important.

After all, a nearly native feeling app, or even an app that feels distinctly non-native, can be a perfect tool for a specific set of actions if it’s easy to use.

Does the pure look-and-feel, the cool extras, matter that much in every situation? Experience on the Web suggests this is not the case. Ugly websites can be very popular. As long as users can do what they want to do in a reasonably convenient way, they’re willing to put up with lack of polish.

Flashback to eleven years ago. The graphic designer tells me to publish the entire body text as a JPG because her choice of fonts is not available on browsers. I, an intern having no say in the matter, do it, but feel dirty.

Are we walking into the same trap with native UX? Are we sacrificing too much interoperability on the altar of eye candy? I would not be surprised if that turns out to be the case for some apps.

Web developer on mobile

Right now is a lousy time to be a Web developer passionate about the mobile space.

I hate you

On the one hand the mobile Web is postponed yet again by the success of a proprietary system. An excellent system, but still proprietary. It sucks up far too much energy that could have gone to an interoperable mobile Web.

Worse, Apple’s success has caused every single mobile player to hurriedly start working on an app store, and the situation is getting ridiculous. There are now two to four new app stores being opened every month. The pace will slacken somewhat in a little while, but the situation has already grown preposterous.

I love you

On the other hand, many of these app stores work with Web technologies. They all support slightly different things, but hey, they resemble each other. And they definitely work with HTML, CSS, and JavaScript.

Web is hip on the mobile space. Most players have declared their love for Web technologies in some way or another.

Vodafone, Opera, and Microsoft go for W3C Widgets, and BlackBerry might add support in the not-too-distant future, as might Nokia. Of course they do not use exactly the same W3C Widgets — yet. But the emergence of a proper standard will help here. The players are eager for it, and chances are it will be implemented fairly decently across all platforms.

Palm goes for native apps written in Web technologies. Nokia has the Web Runtime Dashboard-like system, SonyEricsson recently announced a Phonegap-based Web system.

Even NetFront has a widget manager that works with Web standards, although you cannot scroll widgets, which makes the whole exercise a bit pointless.

If we count Apple’s original interest in Web standards, only Google hasn’t given a peep. Sure, their mobile browser is good, but otherwise they don’t seem to really care about mobile Web technologies beyond viewing sites. But maybe something is brewing there.

I either love or hate you

The real point here, the one that I wanted to think about a bit more, is that right now Web standards are the weapons of choice of the losers in the mobile game.

Apple and Google are the big winners right now, and they don’t use Web standards beyond providing an excellent browser.

All other players, however, the ones that are threatened by Apple’s and Google’s rapid ascent, go for Web standards big time. Is that a good or a bad sign? I just don’t know yet, that’s why I’d have preferred to discuss this point later on.

I hate you

The outreach of these losing companies that bet on Web standards to Web developers is shockingly bad. Everybody wants Web technologies. Nobody cares about Web developers.

Opera is doing its best, but it’s not getting real support from other companies yet.

I suppose my own hiring by Vodafone comes next, but I’m not there as a developer relations manager, although I definitely should write some serious stuff about widget development. So I’m partly to blame personally for the whole mess.

I was especially baffled by the Palm case. Here’s this (formerly) major phone vendor that’s gambling its entire existence as a company on the Web as a platform — as an OS, even — but other than opening a blog and saying there’s this really cool JavaScript library it did not do anything to connect to those people that were its natural allies: the Web developers.

In fact, I doubted my sanity for a while because I just did not understand what was going on. Did Palm figure it didn’t need us because it already had plenty webOS developers? Or was it being stupid?

I love you

Then Dion Almaer and Ben Galbraith moved to Palm as developer relations managers, and everything fell into place. Palm admitted it had made a mistake and was improving relations with Web developers by hiring people who could do the job.

We are worth wooing, after all. Cool! Still, it makes me dizzy.

I hate you. I love you. I hate you. I love you.

Make up your fucking mind, mobile space!

Are iPhone developers stupid?

So that was the mindset I was in while writing the original article and dissing iPhone developers royally.

Although, as I said earlier, some people I respect a lot disagreed with me, and led me to write this article, another bunch of people I respect a lot agreed with my original post.

We once again have to wage a war for the soul of a platform, and point out time and again that Web standards are the way to go if you’re looking for interoperability, and maybe even if you’re not. We know the whole score by heart now.

I see the possibility of making the same mistakes as on desktop, fighting the same battles, waiting the same amount of time, before the mobile Web really takes of. It saddens me. And it angers me.

That led me to lash out to iPhone developers. From the reactions I got it became clear that some of them did consider Web standards, but decided to go native anyway.

That’s fine by me. As long as you think about it.

But the thinking bit is what I have my doubts about. Chris Heilmann tweeted:

I'm just saying, I've been to the iphone developer camp and 1 of 40 hacks used web standards. It is just not on the radar.

That’s what I’m afraid of: iPhone developers not even considering Web apps.

Are iPhone developers stupid? No. I was wrong about that.

But they might become stupid later on, when the Web has become a totally viable alternative, but they refuse to consider it.

The fundamental problem on the iPhone is not Apple’s App Store approval policies, but the iPhone developers’ arrogant disdain for Web technologies.

It was only last Friday I told a roomful of Web developers that Apple is evil, and a spontaneous applause erupted. Since then, however, I have changed my mind completely. The Web developers and I were wrong.

Apple is not evil. iPhone developers are stupid. Their problems with the App Store approval process are entirely their own fault and they deserve no commiseration.

I hope the App Store approval process sticks around for a loooooooong time.

Update: I was wrong about Web apps being able to replace native apps right now. I was wrong about the iPhone developers’ mindset. They aren’t stupid. Read my follow-up post.

Graham’s argument runs as follows:

1. Developers want to develop stuff they themselves want to use on the platform they’re using.
2. Developers have embraced the iPhone with a passion.
3. Therefore developers want to develop stuff for the iPhone.
4. This is to Apple’s advantage, since it’s developers that can make or break a platform.
5. Apple, however, is pissing off developers royally by its insane App Store policies.
6. Therefore it is losing some good iPhone application developers.
7. Even worse, Apple is becoming an Evil Company that developers won’t want to work for, either as third-party app creators or directly as employees.

The unwarranted assumption here is that if developers want to develop for the iPhone platform they love they must go to the App Store for distribution.

That’s not true. They have another option. In order to solve the App Store problem they just have to stop wilfully ignoring it.

Stupidity

In order to release an iPhone application without having to submit it to Apple’s insane App Store process, developers could just use Web technologies and create Web apps instead of native apps.

The iPhone’s Safari browser is one of the best mobile browsers available, and recent improvements in hardware acceleration have made it an excellent graphics platform that can handle serious 3D-animations written entirely in CSS.

It also supports JavaScript geolocation, which is (I hope) only the first step towards true device APIs that will give JavaScript developers access to phone functionality such as the camera, text messaging, the address book, and more. I’m assuming Apple is working on all that because it’s the next logical step.

Safari’s support of appcache makes it possible to store the Web app’s core files on the iPhone itself, so that it only has to download the data. Thus mobile connection problems can be avoided.

The user can place the Web app’s icon on his desktop, thus creating an app-like way of starting the Web application. When will users do that? When they think your app is cool. Instant meritocracy.

Best of all, if you want to update a Web app, you just put the updates on your Web server. There’s no need to wait for Apple’s broken approval process.

iPhone developers are stupid because they’re wilfully ignoring all this.

More stupidity

I reviewed the apps I have on my iPhone, and most can be released as a Web app right now. The exceptions are complex games that are both graphically and programmatically intensive, and apps that depend on device functions such as the accelerometer or GPS.

As I said, Safari supports geolocation, and maybe Apple is working on other device APIs. That would solve all problems for the second category. Complex games will remain very hard to release as a Web app in the near future.

Still, the graphically simple games such as sudoku and chess, the interactive shopping lists, the dictionaries and bible citation apps, the beer appreciation apps, the firmware Yahoo weather app, and most importantly all social network clients could have been written as a Web app without any loss of quality whatsoever. (Most have fairly little quality to lose in any case.)

In addition to avoiding the App Store and its insane policies, such Web apps would (mostly) work in any modern browser, whether desktop or mobile, and users of other phones or even of old-fashioned desktop computers could have used them, too.

Developers like their stuff to reach as many people as possible, right? That makes sense from both a business and an ego perspective, right?

Then why do iPhone developers jump through burning hoops as nasty as the App Store approval process just to make sure that their stuff can only be used on one single platform instead of many?

That’s stupid.

The Web

Apple’s original plan for iPhone development was to use Web technologies. This plan caught both Mac developers and Web developers by surprise because it was totally unexpected.

The plan failed. Jobs Himself ordered His developers to create Web applications with Web standards, but a deafening silence ensued. Then He hurriedly thought up the App Store. Too hurriedly, as it now turns out.

I remember the ecstatic reaction to the announcement, because it was the very first time a major industry leader mentioned Web standards in a major presentation.

Still, we Web developers didn’t really believe our favourite technology could deliver all that Apple wanted. Maybe we still don’t.

Besides, Apple does not reach out to Web developers at all, and Web developers respond by not bothering with Apple beyond making sure their Web sites work in Safari.

I believe that Apple is working towards its own heavily CSS-centric Web OS, certainly for mobile, possibly also for the desktop, and that this evolution has been slowed down by the energy devoted to the App Store as well as the complete lack of outreach.

(This lack of outreach, by the way, is the main problem with every single mobile player that has opted for Web technologies in the past two years or so. Everybody wants Web technologies. Nobody cares about Web developers. Stupidity is not restricted to iPhone developers.)

Arrogance

The fundamental problem on the iPhone is not Apple’s App Store approval policies, but the iPhone developers’ arrogant disdain for Web technologies.

That’s nothing new. Most X developers (for any non-Web value of X) live in mortal fear of the browser as a development platform.

As a long-time browser researcher I can confirm that their fears are not entirely unfounded, although the situation is not nearly as bad as it’s made out to be, especially not if you only want to target the iPhone.

But the so-called “real” developers aren’t confronting their fear. They’re covering it up with arrogance.

They dismiss Web technologies as toys for children. JavaScript is just this little language that cannot possibly compare to real technologies such as the one they’re using. HTML is too simple. Real programmers don’t do that stuff. As to Web developers, they are just glorified pixel-pushers that should in no circumstance be taken seriously.

After ten years I am fucking tired of the “Web development is not real programming” bullshit that the arrogant bastards in “real programming” are spouting because they’re too frightened to learn something new.

Fuck those condescending, ignorant, self-important, stupid, blind, fearful pricks. Fuck them real hard. Where it hurts.

And fucking them real hard where it hurts is exactly what Apple is doing right now.

That’s why I changed my mind. That’s why I’m cheering Apple on. I hope the App Store approval process sticks around for a loooooooong time.

The myth

The poor, oppressed iPhone developer suffering under Apple’s heavy App Store hand is a myth invented by these developers themselves because they’re too fearful to look beyond their “native” fetish.

The Web is patiently waiting in the wings like a spurned bride, quietly promising to solve all of their problems for them if they’d only look at her.

But instead, iPhone developers are eagerly bending over begging Apple for more because of their myopic obsession with bad APIs, the twin geekgasms of both objecty stuff and C, bloated SDKs, impossible layout mechanisms, and all the rest of the archaic nonsense we’re going to have to rid the mobile Web of in the next few years.

All that stuff is native and therefore “real” and important. Web development isn’t.

Well, you know what, iPhone developer? You’re wrong. Stupid, stupid you.

In order to create an app for the iPhone platform you know and love, an app that Apple’s policies can never touch and that works on other platforms, too, you need an iPhone, a text editor, graphics software, a Web server, and a good Web development reference.

None of these are particularly hard to find. You already found the reference.

Jobs showed His chosen people the straight and narrow path to enlightenment, but they ignored His word. Therefore He unleashed the scourge of the App Store upon them. Good for Him. He should do stuff like that more often.

iPhone developers deserve no commiseration. If we encounter yet another post about Apple’s lack of love for the author’s iPhone app, we should tell the pathetic whiner it’s his own fucking fault. He should have used Web technologies instead.

Update: I was wrong about Web apps being able to replace native apps right now. I was wrong about the iPhone developers’ mindset. They aren’t stupid. Read my follow-up post.