Here are four interesting mobile articles that caught my eye in the past 24 hours:
.
Includes:
Here are four interesting mobile articles that caught my eye in the past 24 hours:
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.
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).
Back in early June I got a Samsung Wave that runs the brand-new bada OS and did some brief tests of the native Dolfin browser. In the past few days I’ve done some more extensive testing, and the verdict is in: good browser, well on the way to becoming excellent.
(Oh, and Dolfin ought not to be confused with Dolphin, which is a skin for Android WebKit.)
It’s Samsung’s philosophy that it will not compete in a market unless it belongs to the top three of that market. In the case of the mobile browsing market Samsung has succeeded: from nothing, Dolfin has become the third-best mobile browser in the world. Only iPhone and Android are better.
If you’re keeping track of the mobile browser landscape you should add Dolfin to your A-list. It’s easily good enough, and Samsung has big plans with the bada operating system. Somewhere in 2011 the installed base of Dolfin will pass that of Safari iPhone, and bada might even become a competitor to Android. (Samsung sure hopes so.)
I have updated my mobile pages with Dolfin data. (By the way, I also tested Android 2.2 while I was at it: few changes. There’s not a single difference with 2.1 in my great WebKit table.)
Apple continues to startle me, and I do not mean by its iPhone 4. (I haven’t yet seen it, so I can’t say anything useful about it.) No, what I mean is the ongoing Antennagate problems, and even there I do not mean the actual problem, but Apple’s way of dealing with it. And even there I do not mean Antennagate as an isolated PR incident, but as yet another chapter in how Apple spends 2010 to piss off the world at large.
Vision Mobile just released its Mobile Developer Economics report in which it presents the result of a poll of 401 mobile developers across the eight main platforms: Android, iPhone, BlackBerry, Symbian, Windows Mobile, Flash, Java ME, and the mobile web.
If you’re interested in the mobile developer world, download and read the report. It’s free, though a valid email address is required. Below I treat some interesting aspects of the research, including the quote from me Vision Mobile decided to publish.
About a month ago I release part one of my series “A tale of two viewports,” where I discuss the widths and heights of the viewport, the <html> element, and related issues on desktop browsers. Today I release part two, which deals with the mobile browsers. And of course there’s the inevitable compatibility table.
On Thursday I got a Samsung bada test phone (the Wave) that runs the latest installment of Samsung WebKit, and of course I subjected it to various tests. The verdict is clear: excellent browser. As far as I’m concerned it ousts Opera Mobile from my personal top three.
Back in November I started complicated research into measuring the widths and heights of various interesting elements in mobile browsers. This research kept me occupied for months and months; and frankly I became a bit afraid of it because the subject is so complicated.
Besides, when I re-did some tests in March I pretty quickly figured out I’d made some nasty mistakes in my original tests. Back to the drawing board.
However, after a review round by some browser vendors and some rewriting it’s done now.
Today I present
A tale of two viewports — part one.
I explain CSS vs. device pixels, the viewport, several interesting JavaScript properties,
and the media queries width and device-width.
This piece is about the desktop browsers, because the mobile story is much easier to follow if you know exactly what happens on desktop. Later on I’ll publish part two, which is exclusively about mobile.
The acquisition battle has come and gone, and it’s HP that’s become Palm’s new owner. In general this news has been greeted with glad cries, despite (or maybe because) it was so unexpected. In general everybody assumes that the marriage of Palm software and HP hardware will be a good one, and that HP will also release a webOS-based tablet device.
However, there’s an interesting dissenting opinion on VisionMobile (a blog I highly recommend, by the way). Guest author Michael Valukenko sees few synergies between Palm and HP, and pinpoints three problems besetting the new hPalm combination:
Yesterday John Gruber wrote about the upped pixel density in the upcoming iPhone (960x640 instead of 480x320), and why Apple did this. He also wondered what the consequences for web developers would be.
Now I happen to be deeply engaged in cross-browser research of widths and heights on mobile phones, and can state with reasonable certainty that in 99% of the cases these changes will not impact web developers at all.
14 April 2010
Permalink | Apple, Microsoft, Nokia, Palm | 1 comments (closed)
Some updates on a few developing stories in the mobile space.
This is just in: HTC is said to be considering taking over Palm. That would be an interesting development, since HTC is one of the few parties we can trust not messing up webOS but actually using it as it’s supposed to work.
Palm has an absolutely first-rate product in webOS, especially its user interface. As far as I’m concerned the Palm Pre is the only phone that’s (almost?) on a par with the iPhone when it comes to UI, although the system is completely different (and has supported multitasking from the start, not partially and as an “exciting” novelty).
Right now Jason Grigsby’s excellent summary of the orientation media query is making the round of blogs and tweets, and that’s well deserved. Media queries will become extremely important in the near future, when we have to build websites that work on any device resolution from 300px to 1280px or more.
Still, there’s one tiny nitpick I’d like to make, so that you fully understand when to use orientation and when to use device-width.
I have made a list of the fifteen mobile browsers I currently test. This will give you some insight in the current mobile browser market, which is volatile, complicated, and sometimes shrouded in mystery.
One of the commonest questions I get is “Which mobile browsers should I test?” The hidden question here is which devices you should own. It’s time to attempt an answer.
Cameron Moll is worried about a future in which we’ll all write Objective-C for the iPhone OS instead of writing web standards for the mobile web.
At one point in time, J2ME (now Java ME) and WAP were the starting points for a discussion on mobile strategy and the web. Then, for a brief period of time, you talked about HTML/CSS. Now, for a growing majority of mobile strategies that don’t require a global presence on widely varying devices, the discussion begins with iPhone.
Emphasis mine. Strategy and presence are the clue, and they’re the reasons I think the situation will not be quite as bad as Cameron fears.
2 April 2010
Permalink | BlackBerry | 9 comments (closed)
An interesting study caught my eye. When taken at face value, it proves that in order to really make money with apps you have to switch to the BlackBerry platform.
30 March 2010
Permalink | Apple, Google, Market share | 10 comments (closed)
AdMob, the mobile advertiser that was bought by Google some months ago, has released its latest market share figures for the mobile browsers.
Their main findings have already been discussed extensively:
The AdMob report, however, is not about browser market share but about ad impressions. And that may matter a lot. Unfortunately we don’t know how much it matters.
In response to my HTML5 apps argument a few people came back to how the payment thingy is missing from my idea, and how it will (apparently) be worthless because of that. I’ve been thinking about that a lot in the past few days, and I’m increasingly of the opinion that the payment argument is nonsense.
Sure, everybody who does iPhone apps, or who’s glancing cursorily at the mobile market without trying to gain in-depth knowledge, currently believes that the App Store concept is going to be a huge success because of the opportunity for developers to earn some money. But they’re just wrong.
I did some back-of-napkin calculations and found that, macro-economically speaking, iPhone app development costs money right now. And yes, an individual developer can strike it rich, but that’s getting rarer and rarer. I do not want to build a new app ecosystem based on arguments from developers who just want to take a gamble in the App Store roulette. Gamblers’ arguments are not real arguments.
Right now nobody’s interested in a mobile solution that does not contain the words “iPhone” and “app” and that is not submitted to a closed environment where it competes with approximately 2,437 similar mobile solutions.
Compared to the current crop of mobile clients and developers, lemmings marching off a cliff follow a solid, sensible strategy. Startling them out of this obsession requires nothing short of a new buzzword.
Therefore I’d like to re-brand standards-based mobile websites and applications, definitely including W3C Widgets, as “HTML5 apps.” People outside our little technical circle are already aware of the existence of HTML5, and I don’t think it needs much of an effort to elevate it to full buzzwordiness.
Technically, HTML5 apps would encompass all websites as well as all the myriads of (usually locally installed) web-standards-based application systems on mobile. The guiding principle would be to write and maintain one single core application that uses web standards, as well as a mechanism that deploys that core application across a wide range of platforms.
18 February 2010
Permalink | BlackBerry, Google, HTML5 apps, Mobile, Nokia, Opera Mobile/Mini, Samsung | 8 comments (closed)
Yesterday evening I returned from my fourth foreign trip this year. This time I went to the Mobile World Congress, the annual Barcelona-based get-together of the mobile industry, and I can tell you, it’s something else.
This post gives an overview of announcements by mobile players that might be of interest to web developers. There’s an incredible lot of it, too, because every single major mobile player except Apple feels that MWC is the ultimate forum for major announcements.
If you know of more news, or have links to additional information, please leave a comment.
I was there because Vodafone had invited me to sit on a
panel in a technical “embedded
conference” about W3C Widgets and related technologies.
The concept can use some fine-tuning; I’m hoping to do some of that in the future.
I was there mainly to stress that the mobile browser situation is not as simple as it looks. THERE
IS NO WEBKIT ON MOBILE!
While I was at it I also invented guerilla browser testing.
Since my attempts at capturing web developers’ hearts and minds by publishing fundamental research have failed miserably but my thirst for attention continues unabated, today I will once more shout at iPhone developers. That’s proven to work.
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:
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.
One reaction I received about my touch research was: Do we really need the touch events? Can’t we just fire the mouse events when a touch action occurs? After all, touch and mouse events aren’t that different.
That’s a fair question. It deserves a fair answer.
It turns out to be possible to handle the touchmove and touchend events with data obtained from the touchstart event object. It is not necessary to access the touchmove and touchend event objects, as long as you continue to have access to the touchstart one.
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.
Update: I’ve been given to understand that this behaviour will disappear from WebKit. So don’t build your scripts with this behaviour; they’ll misfire sooner or later.
Over the past few weeks I have done some fundamental research into the touch action and its consequences, and it’s time to present my conclusions in the form of the inevitable compatibility table. I have also written an advisory paper that details what browser vendors must do in order to get by in the mobile touchscreen space. Finally, I discuss a few aspects of my research in this article.
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.
B. is an old friend of mine who owns an old Nokia. And when I say old, I mean really old. It was released somewhere in 2000 or so (the Nokia, not the friendship). It’s not a smartphone, to put it mildly, and B. does not use the mobile Web.
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.
I have several more things to say in the Web apps vs. native apps debate, and I’ve decided that a few smaller posts treating just one subject would be the best form. Today we kick off with the Cocoa Touch framework.
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.
Well, that was an interesting ride. Besides passionate agreements, my previous post also elicited passionate disagreements.
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.
23 November 2009
Permalink | Apple, HTML5 apps | 110 comments (closed)
In his “Apple’s mistake” essay Paul Graham makes an unwarranted assumption; an assumption everybody who’s currently involved in the Great App Store Debate seems to be making.
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.
13 October 2009
Permalink | Apple, Chrome, Google, Safari, Samsung | 12 comments (closed)
When I reviewed the reactions to my There is no WebKit on Mobile post, it became pretty clear that few had expected its conclusion that there is no single WebKit on Mobile. Overall, it seemed that most people were pretty surprised, and hurried to revise their ideas of the mobile browser market. That was the point of the article, so I was happy.
The most-often heard criticism was that I was unclear about the browser version numbers. That’s true, and I have updated the table to include them. I also split out the tests into Acid, CSS2, CSS3, HTML5, and JavaScript, and calculated separate scores for each browser. The results are interesting for some browsers. Konqueror sucks at JS but is very good in CSS, while Android is exactly the opposite. Interesting data.
(I’m still tinkering with the interface, by the way, and I didn’t have the time to finish my current revision. So the coloured bars are temporarily gone, but they’ll return in the future.)
7 October 2009
Permalink | Apple, Chrome, Google, Mobile, Safari, Samsung | 32 comments (closed)
Last week I spent a lot of time on WebKit in order to produce a comprehensive comparison of all WebKits. My purpose was to prove there is no “WebKit on Mobile,” and to gain some more insight in the complicated relations between the various WebKits.
Therefore I now present the Great WebKit Comparison Table. In it I compare 19 different WebKits on 27 tests.
Having tested mobile phones for the last seven months or so, I have become pretty well inured to odd, or even disastrous, results. Still, after encountering the following bug on the Android, even I started to doubt my sanity.
I don’t usually spend a blog post on a single browser bug, but this time I break that rule because this is doubtlessly the weirdest bug I found so far, and possibly also the most serious one.
CSS width may be unreliable on the Android — in certain situations.
14 September 2009
Permalink | Mobile testing | 18 comments (closed)
After seven months of mobile testing (as well as a wealth of inventive invective aimed at mobile devices) I think it’s time to share some of my experiences with others who are inclined to violent self-punishment.
Welcome to my world! Bring your whip, bring a first-aid kit, and let’s have some fun punishing ourselves.
Today we’ll discuss the process of testing mobile browsers. We will not talk about the test results or their interpretation, we’ll leave that gorefest for another time.
As everybody who’s even slightly interested in mobile knows, the creation of the Apple App Store has caused a perfect flurry of activity among everybody else having to do with the mobile web.
Currently I’m making a list of all existing app stores. I’ve found a few, but I’m reasonably certain that I missed a few, too. So I’d like to ask you if you know of an app store I’ve forgotten. I’m especially looking for information on T-Mobile and HTC.
Last week I’ve done the DOM Core tests in new browsers: IE8 final (in both IE8 and IE7 mode), Firefox 3.5b4, Safari 4.0, Chrome 1 and 2, and Opera 10a. I found no surprises.
After that I decided to continue with mobile browsers, of which I have 15 lying around on my desk. Unfortunately I could not test IE Mobile (old) because it supports only inline event handlers, Skyfire because it does not allow you to remove alerts, and the Opera runtime in the Vodafone widget manager for terrifyingly complicated reasons I still have to describe properly.
Still I managed to test the other twelve and found a few surprises.
As I said before, I’m currently working for Vodafone on mobile browser compatibility and W3C Widgets. I’ve discussed some mobile browser problems, and you can look over my shoulder while I’m at work dissecting their odd behaviours. If you want the latest scoops on my mobile adventures, you can follow me on Twitter.
The time has come to talk about the W3C Widgets part of my job. Exactly what is a widget, how do you create one, why would you want to, and which systems support them?
Personally I firmly believe that widgets are the future of the mobile web. They are easy to create, they’re based on open standards, they save the end user quite a bit of network traffic, and many people around the world already know how to create them.
In contrast to other recent publications about widgets, I’ll tell you the whole story — or rather, a condensed version thereof.
16 March 2009
Permalink | Mobile testing | 14 comments (closed)
Since my previous post about mobile browser testing I’ve had four days in Düsseldorf to play with mobile phones, and I’ve once again unearthed quite a few problems that mobile browser testers will encounter. So this post is mostly about how the situation is even more complicated than we thought.
You can look over my shoulder while I’m testing, as far as I’m concerned, as long as you remember that every bit of data is provisional and may change radically without warning.
If you’re interested in real-time raw test results, follow me on Twitter. I regularly post my findings there, and it’s already delivered me some excellent feedback.
In this entry we’ll look at first-line and second-line browsers, mobile support for basic CSS, Opera’s two modes, the failure of @media handheld, Vodafone “content adaptation,” the Nokia keyCode problem, and we’ll close off with a few fun browser facts.
The crucial question of the moment is: who asserts supreme control over the way a website looks on a mobile phone? Currently I’m arguing the author should, but Opera and Vodafone assert vendor control, with Opera also giving the user a modicum of control.
6 March 2009
Permalink | Mobile testing | 23 comments (closed)
About a month ago the software department of Vodafone Internet Services, based in Düsseldorf, Germany, asked for my help in creating mobile widgets according to the W3C Widgets specification. In particular, they’d noticed there are differences between browsers even on mobile phones (imagine my surprise), and decided they needed advice from a specialist (that would be me).
Better still, it quickly turned out that they were willing to pay me for doing serious mobile browser compatibility tests and publishing them on this site. The payment thingy is quite unusual, I can tell you (though not entirely unique).
This is easily the best job offer I’ve gotten in my entire freelance career, so I hurried to accept it. Meanwhile I’ve done mobile tests for five days; enough to offer some guidance for setting up a doctrine for mobile browser testing.
As far as I’m concerned you can look over my shoulder while I’m working, but please PLEASE remember that everything I say may change radically without notice after I’ve tested the same browsers on other devices.
Right now I’ve only done a few tests of functionality that’s basic to the mobile experience, and even these basic tests will likely have to be expanded. Besides, right now getting a general feeling for mobile testing and its manifold problems is more important than running lots and lots of tests.
Yesterday I walked into the local phone store because the “Temporarily Unavailable” sign had been removed from their “Get your iPhone here” poster. To my utter surprise they had six (6!) entire iPhones for sale, and no, there was no waiting list. I walked back home with a shiny new gadget, impatient to start testing it.
Meanwhile I’ve done some tests; now it’s time for a report.
Before we continue, let’s get the bad CSS news out of the way: Safari on the iPhone does not support position: fixed. Certain Other Browsers were ridiculed for this lack; Safari won’t be.
I’ve updated the CSS Table, the Core Table and the Events Table. In this entry I’m going to talk about JavaScript events on the iPhone. They’re — interesting.
This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer. You can also visit his Elsewhere on the 'Net linklog, his political blog, or you can follow him on Twitter.
Categories:
Monthlies: