QuirksBlog - Mobile
The mobile world.
| Amazon | App stores | Apple | BlackBerry | Connection speed | Facebook | Firefox Mobile | Google | HTML5 apps | Microsoft | Mobile testing | Mobile web dev | Nokia | Opera Mobile/Mini | Payments | Samsung | webOS |
In February 1999, when my very first salary as a web developer arrived, I bought two things I wanted but so far couldn’t afford: a CD player and a watch. The CD player is still around somewhere in my new house, waiting to be connected. The watch, curiously, stopped working pretty soon after I stopped working for employers. Freelancers don’t need timekeeping, apparently. That was in 2002, and I haven’t worn a watch since.
Now there’s the Apple Watch. (Also a whole slew of Android Wear watches, but guess which type gets most attention?) I don’t really see the use case, but that might be my lack of imagination. Anyway, my job is not to discuss use cases, but browsers — or rather, the lack of them.
A month ago Nokia announced its Nokia X product line which runs Android as its operating system. This is an interesting development because nobody expected Nokia to turn to Android — especially not now, when it’s about to be taken over by Microsoft after gambling (and losing) its independent existence on Windows Phone.
I have a theory about the Nokia X that I’d like to share with you. It may be nonsense, but it fits the currently available facts and makes sense, so it could be true.
Three weeks ago I wrote about installable web apps. Last weekend I found an interesting case study. It’s not exactly what I wrote about, but it give valuable insight in what site owners (and possibly consumers) currently want.
Yesterday I replied to a tweet by Marcos about “add to home screen,” and that kicked off a long and rather interesting conversation about installable web apps. This post gives my view.
As Bruce explained in his Fronteers 2013 session, bookmarking something in a mobile browser should mean adding an icon to the device’s home screen instead of making an entry in an otherwise undistinguished bookmark file. As soon as Bruce said this I knew he was right.
This week I ran an eight-question survey of media query use, responsive web design fundamentals, and one viewport question. 1251 web developers reacted. This entry presents the results.
Most important conclusions:
- Nearly 50% of web developers (occasionally) use device-width and expect it to work the same as width. It doesn’t right now, but it will in the future.
- Many web developers are not aware that a cross-browser resolution check needs both the -webkit-device-pixel-ratio and the resolution media query.
- The most popular resolution query is “larger than 1.5;” a very welcome bit of sanity.
- ems in media queries are not used all that often — only 31% use it in more than 50% of their projects.
- 16% use more than five breakpoints in their responsive design.
Last week Luke Wroblewski published an important article in which he said that web developers practising responsive design rely too much on a device’s screen size to determine which device it is.
Just now I noticed a Twitter discussion on packaged web apps and their purpose. The same question was asked during the Mobilism panel, and I still regret not speaking up and explaining. So here it is.
The point of a packaged web app is to allow for its peer-to-peer transfer from device to device.
A user has a nice web app and proudly shows it off to friends. They also want it, so the user opens a Bluetooth connection (or NFC or whatever) and just sends it to his friends’ devices. They tap it, it installs itself, and they can use the app straight away.
A few more Blink-related links. (This article’s title was
stolen borrowed from Thomas van Zuijlen.)
So Google created Blink, the new rendering engine for Chrome and Opera. What exactly is going on, and what will the consequences be?
OK, so Opera is going to move to WebKit. I didn’t see that coming, despite the recent news about a WebKit-based browser on iOS (can’t port Presto there, so of course it’s WebKit).
What does all this mean? Hard to tell. Here are a few thoughts and guesses.
Currently I’m working on a media query test suite, and I’ve run into one of those weird things: the proper syntax of
Note that I’m only interested in the @media syntax. I cannot use the rest because I can’t fit it into my test suite.
Today I finally have the time to continue with the connection speed measurements. For those joining the discussion only now, first read part 1 and part 2. See also the draft spec; especially for the
I’m trying to distill a few principles for measuring the connection speed. I give them in the form of statements; be sure to speak up if you disagree with one of them.
A later article will return to the nasty details of reading out the connection speed. Today we’re only concerned with broad outlines.
Now that we have the iPad Mini, web designers waste no time in wanting to distinguish between it and the iPad 2. Tough luck.
Incidentally, it appears that native developers can distinguish between the two, making the playing field for the grand match between native and web unleveled (disleveled?). If you wish you can blame Apple.
That’s not what I want to write about, though. Instead, it’s about web developers’ expectations and physical units in the W3C spec.
Well, there were some interesting comments on my last post about connection speed in browsers. This post continues the conversation by giving my replies to a few notes, thoughts, and concerns.
In the past week I’ve done the viewport tests on the latest crop of devices, and things are definitely looking better. The visual viewport dimensions are now well-supported, and a consensus on position: fixed is in the making.
I’ve said it before and I’ll say it again: browsers, especially mobile ones, should give information about the speed of the connection they’re on, so that we know whether to send the high-res images or lowsource ones.
Currently no browser gives any sort of information about connection speed — they don’t even have access to it. Still ... well, let’s say that it’s possible that this will change in the future. But we need to figure out exactly how the system should work.
So this post asks a few questions, and the comments are open.
- On average, respondents used 3.5 libraries in the past year, and about 2 in more than 50% of their projects. (Of course the latter figure might mean they use one library in 50% of their projects, and another in the other 50%.)
- 95% used libraries, which means that 5% didn’t. That’s something, though not much.
- 59% could have done without a library in his last project. That’s not too bad, but it still means 41% could not.
- 42% sticks with his current libraries because learning to use a new one takes too much time.
- The most-used library is jQuery with 91%. Duh.
- Second-most used is Modernizr (58%), and then come underscore.js (33%) and backbone.js (30%).
- From 25-40% of the users of a library use it in at least 50% of their projects. For Modernizr, underscore.js, and especially jQuery this percentage is higher. For Zepto, Sencha Touch, and Raphael.js this percentage is considerably lower.
When I spoke at From the Front I was asked what I thought was the worst case of thoughtless copy/pasting I saw going on around the web. My answer: jQuery.
Yesterday Mark Zuckerberg said (paraphrased):
The biggest mistake we made as a company was betting too much on HTML5. While building native apps that were basically just a wrapper for the mobile web standard let it experiment quickly, it made the apps run way too slow. We burnt two years.
Two quick notes:
- This seems to be not about HTML5 as a whole, but specifically about Android. And the Android 2.x default browser is just not very good. I wouldn’t want to create a cutting-edge HTML5 app on Android 2.
- You can’t use the web to emulate native. You should use the web in a webby way. Which I guess means a simpler interface with less flourishes.
So all in all, this remark doesn’t say as much as you’d think; only that Facebook will switch from web to native on Android because the Android browser does not allow web to emulate native.
But will they also create BlackBerry, Windows Phone, Symbian, bada, and S40 apps? I think not.
BTW: here is the full quote. Facebook to forget about HTML5? Nah.
Oh, and one reason Zuckerberg said this is because investors want to hear this. Investors are a bunch of clueless people who only run after buzzwords, and Facebook’s delicate position on the stock market makes it necessary to placate them.
In preparation for tomorrow’s iPhone announcements I’d like to repeat something I said last October: the iPhone 3GS will be produced for many years to come, and its price will drop a little every year.
Update: Well, it seems I was wrong here. The 3GS has been nixed. Pity.
OK, so now we have the rumour that Facebook is going to buy Opera. That would be unexpected. And interesting.
In this entry I’m going to pretend the news is true, even though that’s not certain yet, because it is a good starting point for some serious strategic thinking.
Back in October 2010 I was very glad to receive a mail from the people behind the Samsung Dolfin browser, who turned out to work from Bangalore, India, asking for my cooperation in making it better and even offering to pay me for it. Unfortunately, by now it turns out that they’re a bunch of fucking assholes who don’t do as they promise. This is to serve as a warning to others NEVER to do business with them.
It should be noted that the engineers are perfectly all-right and reasonable and can easily be talked to. It’s the fucking bureaucratic assholes in "HR" that are the enemy who’ve fucked up my life in the last year or so.
Update: This post helped. I received my money, while I was convinced I'd never get it. So that's arranged now, and my dealings with SISO are at an end.
At first sight the new iPad 3 seems to be a vindication of Moore’s Law. Apple wanted to significantly increase the pixel density of the screen, and had to wait until the components were cheap enough to sell the iPad for its usual price. Now, apparently, that wait has ended and the iPad 3 with Retina is here.
Still, not all is well with the iPad 3. Put simply, what Apple forgot here (or deliberately decided to overlook) is that Moore’s Law doesn’t go for data connections; especially not for mobile ones. Increasing a wireless data network’s speed doesn’t really depend on cheaper hardware: it’s a matter of bandwidth, frequencies, and more cell towers.
In addition to the quality of their web environment, there’s another factor that will decide whether or not mobile web players are going to survive: the quality of their developer relations outreach. Here’s a quick and dirty look at the current state of affairs.
And yes, I admit that this overview is based almost solely on my own experiences in finding sponsors and panelists for Mobilism, and I also admit that I’m writing this post because I’m very frustrated right now.
This is getting frustrating.
The official CSS WG blog:
Discussed problem of WebKit monopoly on mobile and the consequent pressure for other engines to implement -webkit- properties.
Webkit monoculture: threat or menace?
Guys, stop it. This is simplistic us vs. them thinking. It’s not helpful.
Now if you would say there’s an iPhone monoculture among web developers, you’d be right. But whose fault is that?
Belatedly, and snowed under by other news, here are my BlackBerry DevCon slides of Wednesday. Once more the Future of the Mobile Web, but I think it was the best Future session I gave so far. And I use new cat and fisherman pics.
More in general, the conference was excellent; much, much better than I thought. There was ample web content sprinkled through a solid core of BlackBerry-centric sessions, but even part of the BB sessions were in fact about web technologies and related topics.
This is one of those weeks where everything happens simultaneously. I think that the vendor prefix discussion is the most important topic, so that’s what will get my attention.
Daniel Glazman, co-chair of the CSS WG, posted a call for action that warned of the dire consequences of web developers using only
-webkit-prefixed CSS declarations: IE, Mozilla and Opera would also implement
I will argue that the proposed solution of making web developers aware of the problem may be technically and ideologically correct, but does not address the true causes of the problem: the developer-hostility of vendor prefixes, and the lack of mobile test devices.
It’s a new year, and we’re supposed to make some predictions. So I’ll try to order my thoughts about the post-Android market, although I should warn you I won’t make a true prediction but will be a bit wishy-washy and vague.
So HP open-sources webOS. That may sound like good news, but I doubt it.
Today’s hot story seems to be the supposedly Google-initiated howtogomo.com website. I heard some complaints, and decided to take a look myself.
Oh. My. God.
Over the past week or so I found I have seriously misjudged the iPhone 4S announcement, and I’d like to set the record straight. After reading a few interesting pieces I realised I’d misunderstood Apple’s patterns and cycles, and I saw how brilliant the 3GS move is.
I decided to write this little summary to firmly plant Apple’s pattern of cycles in my mind. No original thoughts here — I just collate ideas from other sources.
If you’re not into blog posts that state the blindingly obvious, skip this one. It explains why Google’s whole Dart idea will fail miserably as a “structured language for web programming.” Most people will have already figured this out by themselves, but for those few who haven’t, here’s why:
That’s it, really; there’s little else to say. Still, since a blog post is supposed to be longer than two paragraphs, I’ll say a bit more.
Back in May I went on record saying that Apple would announce two iPhone models this year. It didn’t. I also said I’d eat crow in public if I was wrong, so even though I don’t think anyone actually remembers my promise, I owe you this.
... munch ... crunch ... [spit out feather] ... bleeh ... munch ...
Dear Amazon Silk team,
You released a marketing campaign disguised as a technical talk about your new Silk browser for the Kindle.
Web developers are very interested in what you have to offer, and would love to study the solutions you’ve created for browsing in connection-challenged environments, but currently that’s impossible due to lack of information.
That lack is understandable: right now you’re hurrying to get all last-minute fixes applied in time for the release and don’t have time for answering detailed technical questions.
Still, the emphasis you put on Silk’s use of completely new concepts makes web developers very nervous and has them scramble for any information. Browser vendor had completely idiotic ideas before and tried to sell them as the Next Big Thing. We’d like to know for sure that Amazon is not one of those vendors.
Therefore I have a few questions for you, which are detailed below.
I would also very much like to get in touch with a Silk developer relations manager.
Oh, and next time, please don’t pretend all these concepts are totally new and utterly astounding. They’re not. Opera has been doing this for years. Your solution may be technically better, but the onus of proving that is on you.
So Amazon has announced its Kindle Fire tablet, and it will not be an iPad killer. It runs Android, but not the standard Android, but rather a special Amazon port that does not include any standard Google apps. Notably, Amazon will have its own app store.
Update: I've asked a few questions of the Silk team. Now let's hope we get an answer.
The Kindle Fire will also sport its own browser: Silk. Kudos to Amazon for actually giving their browser a name. That helps a lot.
So. Samsung will open-source bada next year so that developers can improve it and other device vendors use it. The Register does not believe the news, while GigaOM correctly points out that Samsung won’t gain anything by open-sourcing bada.
Meanwhile, the HP board dumps CEO Apotheker and instates Whitman, who vows to retain Apotheker’s strategies, even though it was exactly those strategies that got Apotheker fired. The spin-off of the PC unit may be cancelled, even though it constitutes about 90% of the current strategy. The webOS team is rumoured to be downsized, which does not make sense at all if HP wants to do something useful with it.
Samsung will not buy MeeGo but instead focuses on bada. Meanwhile HTC confirms it is considering buying its own OS, but “won’t be rushed” — unlike certain other large Android vendors we could mention.
Time to update last week’s overview. #15 is the first new one.
It is with great pleasure that I saw that I was included in the latest Carnival of the Mobilists with my Twelve steps for saving webOS.
If you don’t know it, Carnival of the Mobilists is a linklist of the best mobile writing of the past month. It appears on a different blog every month, and this time it’s Dennis Bournique of WAP Review who plays host. I discovered the Carnival about a year ago and have been hooked ever since.
The beauty of the format is that very different articles end up on one page; a bit like Linkbait, but with much more variety. There are articles about the mobile city, a new ad network that might replace AdMob, recommendations for encouraging India's mobile services ecosystem,
the reason why Martha’s Vineyard’s inhabitants love Obama’s visits, and more.
One of the rules of the Carnival is that you do not link to any of the individual posts, but only to the Carnival itself. So if you’d like to read one of the articles, go there!
So Samsung won’t buy webOS after all. Instead, it is said to be interested in MeeGo, which Intel may want to sell. And HP will not sell the webOS team, which has been transferred from the PC division, which will be sold, to a strategy division, which will stay. Good, HP can use some strategy. As can Samsung.
That thud you heard? I fell because my head is spinning.
Well, the webOS saga has already entered a new phase. The Next Web reports that Samsung is seriously considering buying webOS (in addition to hiring a former HP VC for marketing their PCs.)
So it’s outright sale, and not licensing. And it’s Samsung. Neither is unexpected; I predicted both a week ago. (And I must admit I’m very happy to finally get something right, even though it wasn’t a particularly complicated prediction.)
I’ve been thinking a lot about the future of webOS, and have decided it does have one, maybe even a glorious one, provided the new owner or licensee reaches out to web developers, as Palm should have done back in 2009.
So here are twelve steps the new owner should take in order to get webOS to thrive.
HP kills off webOS. However, I do not believe this is the end of webOS. On the contrary, I think it’s the start.
The quote from the press release:
HP reported that it plans to announce that it will discontinue operations for webOS devices, specifically the TouchPad and webOS phones. HP will continue to explore options to optimize the value of webOS software going forward.
How do you optimize the value of webOS software without producing webOS devices? By selling it.
HP was already in talks with Samsung, so that’s one definite option. HTC is another. Basically anyone who needs a good mobile OS does.
Anyway, HP did something very clever (or lucky) by announcing this just after the MotoGoogle bombshell. “Dear discontented Android vendors, if you’re doubting your eternal and undying allegiance to Google, we have a shiny OS for sale for you. No strings attached. Place your bids.”
HP had no fucking clue what to do with a progressive mobile OS. It’s likely that webOS’s future owners will perform better. They can hardly do worse.
Opinions abound on the Motorola acquisition. A quick rundown is in order.
So Google buys Motorola. What does this mean?
Personally I feel this heralds the high-water mark of Android’s OS market share. That’s not the same as its developer mindshare, or customer satisfaction, but I don’t think the other Android vendors are going to be thrilled, and that we’re going to see that in Q1’s sales stats. Android will drop slightly, and one or more new OSs will take its place.
Samsung now has two major operating systems for the smartphone market: Android and its own bada. (We can ignore Windows for now.) Very cleverly, it is stealing the spotlights with its Android devices, while steadily building bada in the background, creating a developer ecosystem and upgrading the OS until it can somewhat compete with iOS and Android.
The reason for this dual strategy is that Samsung does not want to be beholden to Google for its OS. A strong bada will allow Samsung to discontinue Android in the future, and stake everything on its own OS where it owns the entire stack, from hardware to app store. It’s not certain that Samsung will in fact do this, but it wants to keep its options open.
Just today I received a shiny new Palm Pre 2. Now Palm WebKit is notoriously underrepresented in my mobile research because up until now I didn’t have a device (except for a short and unhappy period in early 2010). Besides, webOS is the only OS that can give iOS a run for its money UX-wise. Reason enough to study it carefully.
Before being allowed to actually use the phone, though, I had to go through a user sign-up process that’s so amazingly hostile that I decided to record my adventures in the faint hope that someone at Palm will read it and make changes.
A few more thoughts on Nokisoft.
OK, so the deal is done. Nokia partners with Microsoft and trades in MeeGo for Windows Phone 7, I failed my test as a mobile analyst, and 2011 will make 2010 look like child’s play when it comes to disruption. Here’s a quick reaction to those aspects I find most interesting. No claim to completeness here.
For web developers this is bad news. Windows Phone 7 has the worst default browser of all modern smartphone OSs: IE7 (though, in fairness, Microsoft is working on an IE9 port). MeeGo was supposed to have a Gecko-based default browser, just as its precursor Maemo did.
This Friday Nokia will hold a strategy and financial briefing in London, with major announcements about operating systems being expected. This will impact the mobile browser market, so it’s important to web developers. A bit of background is in order.
Two factual errors, one serious critique and a bunch of new facts and figures about operator billing.
It’s said that Twitter and Facebook play an important role in the current Egyptian revolution, and that closing down the Internet was the best step the beleagured government could take. I don’t believe it.
App stores, pioneered by Apple, aim to provide ease of payments and discoverability to developers and consumers. However,
- do they offer unique advantages that no other payment or discoverability system can match?
- is Apple’s success transferable to other app stores?
Belgium is investigating whether Apple’s recent changes to its subscription policies for newspaper apps are an abuse of its dominant market position. Apple no longer allows newspapers to provide free digital versions to their print subscribers. This could possibly lead to a new antitrust affair.
This story seems to play only in Belgium and the Netherlands for now; readers from other countries may not know it. That’s why I wrote this special report.
Yesterday Horace Dediu tweeted:
A browser is an infinitely flexible interface, but is it the best interface for everything? Apps allow experiments in new interaction models
The browser is not the most advanced interface there is. It’s too easy to build the wrong features into something as flexible as a browser, and once a badly-designed feature gains traction it’s impossible to get rid of it. (See HTML5 drag and drop.)
One of the major changes 2011 is going to bring is the start of operator billing on the web. It will provide a user-friendly way of making mobile (and web) payments without those silly credit cards that are preventing the majority of the world to participate.
Operator billing is nothing new. Premium SMS (see for instance Verizon’s FAQ) , where the user pays something extra to receive news items or ringtones, or vote in a TV show, has existed for ages. The price is automatically charged to your operator account.
The most advanced country on earth when it comes to mobile payments is Kenya. About 50% of the population handles about 20% of GDP by mobile phones these days. The social consequences are profound, and operator Safaricom became the biggest bank in East Africa in the process.
Update: I finally found a good description of the system.
Banks and credit card companies of the world, be very afraid. The operators will come to take your business away.
App stores, so it is assumed, will allow developers to forge a direct link to consumers, which causes consumers to directly pay developers for their hard work. Thus they’re secretly seen as a shortcut for the hard work of a start-up, that (ideally) also forges such links.
This monetisation argument is the fetish of the current age.
Unfortunately it is utter and complete rubbish. The fundamental problem, as I calculated months ago, is that there’s just not enough money in the app store economy to support a meaningful number of independent developers.
Via John Gruber I stumbled on The Unbearable Inevitability of Being Android, 1995. The article ignores key facts of the mobile market because they don’t fit the point the author wants to make.
People have the right to participate in re-enactments of historical platform wars, but they should not confuse them with reality.
Three news items that have nothing to do with each other, except they caught my eye yesterday and today, and might be of interest to others, too.
Just now A List Apart published my Smartphone Browser Landscape article. Despite having written for ALA for more than ten years, this is only my fifth or so article. But it’s a nice one.
I started on this article back in July by writing down absolutely everything that web developers had to know about the smartphone market. It was about twice as long as it is now. ALA rejected this draft — and with good reason. It took me from July to October to figure out which bits web developers didn’t have to know right away, and that was a useful process.
Anyway, enjoy the article. No comments here; you’ll have to go to ALA for that.
For those who follow the mobile market:
There’s a ruckus in the Microsoft world following Mary-Jo Foley’s contention that Microsoft is going to abandon Silverlight in favour of HTML5. If that were true it would be great news for web developers. It is in fact not true, but still great news for web developers.
Ewan MacLeod is spot on:
It’s important to recognise that whilst most of the Western media reckons Nokia is completely screwed, this is also not the case.
The company continues to ship a million handsets a day (or thereabouts) and each one of those devices contributes a tiny bit of profit along with a heck of a lot of cash throughput that keeps bankers smiling very, very widely.
Believe it or not, folk actually queued for the N8. Just not in San Francisco or London. So it might as well not have happened as far as the West is concerned.
Sadly the reality is that ... well ... perception is reality. It’s 0% reality and 100% perception in the case of Nokia from the point of view of the West.
Recently Mike Rowehl, a mobile developer with relatively little knowledge of the web world, confessed to being baffled by the attitude of web developers interested in mobile.
This is the last part of my reply. In parts one and two we talked about what web developers are doing wrong; now we’re going to talk about the errors of the mobile world.
Recently Mike Rowehl, a mobile developer with relatively little knowledge of the web world, confessed to being baffled by the attitude of web developers interested in mobile.
This is part two of my reply, and we’re going to talk about progressive enhancement now. (See also part one)
Like me, Mike was impressed by Bryan Rieger’s excellent presentation in which progressive enhancement plays a crucial role. However, it’s important to realise that Bryan’s presentation is the start of the dicsussion, and not the end. Lots of work remains to be done.
Recently Mike Rowehl, a mobile developer with relatively little knowledge of the web world, confessed to being baffled by the attitude of web developers interested in mobile.
He feels there’s a disconnect between what web developers do, what they’re supposed to be doing, and the tools mobile vendors make available to them.
Mike is completely right. There is a whole series of disconnects right now in mobile web development, and most of them are the web developers’ fault. Unfortunately the web world is hard to understand for an interested outsider.
John Gruber picked up my Nokia post, and makes an interesting comment.
After quoting my “Why on earth wouldn’t Nokia be able to maintain two operating systems?” he says:
I shouldn’t have written “mobile devices”; I should have written “smartphones.”
To me, that doesn’t make any difference. I count both MeeGo and Symbian as smartphone operating systems, so if John had written “smartphones” I would have made exactly the same comment.
That doesn’t mean John’s wrong, though. He just defines smartphones differently than I do. As I see it, he defines a “smartphone” as what I call a “high-end smartphone” (iOS, Android, MeeGo, webOS, likely Windows Phone 7 and BlackBerry OS6, too).
Last week Nokia CEO Olli-Pekka Kallasvuo (OPK for short) was replaced by the first non-Finn to lead the company, Stephen Elop, head of Microsoft’s business division (mainly Office). This is big news that might change Nokia’s perception as well as its strategy.
OPK’s tenure as Nokia chief was not lucky. Barely in office he was confronted with the launch of the iPhone, and this issue overshadowed the rest of his career. For the full story of OPK, see, as always, Tomi Ahonen.
After four years of doing little except producing one of the worst touchscreen phones in history, the N97, Nokia was perceived as a loser, and pressure on OPK to resign was growing. Last Friday things came to a head when Elop’s anointment as his successor was announced.
(This article has been translated into Spanish.)
Yesterday I was visited by a browser tester’s worst nightmare: when testing BlackBerry WebKit I found I made a mistake in my touch event research. I have to re-do all these tests in all browsers because my current results don’t take one variable into account.
That variable is preventing the event default. While writing my test page I left out the
return false at the end of the test event handler, simply because I didn’t think of including it. The test results seemed fine, so I didn’t notice the mistake for months and months. (Meanwhile I added a setting for preventing the default.)
Over the weekend I created a mobile market overview in the form of a sortable table. I hope it gives you some insights; it certainly did for me.
For a complete overview knowledge of the current market share stats is necessary; fortunately Tomi Ahonen provides the latest. My table doesn’t yet contains these stats; I still have to figure out exactly how to display them (not to mention making time to implement a new feature).
Anyway, take a look and let me know what you think. And if you have some extra facts, please provide them.
I have updated the mobile browser page. It now contains 18 browsers, and in addition I added some lists about which browser runs on which OS, and which device vendor uses which OS. However, I need your help in making the list exhaustive.
I have now firmly decided to test and describe only those browsers that run on one or more of the ten smartphone OSs (Android, bada, BlackBerry, iOS, LiMo, MeeGo, Phone 7, Symbian, webOS, Windows Mobile). There are just too many other OSs, but they’re either feature phone only, or they’ve fallen out of the race.
My question to you is to review the list and rack your brain for more data.
- Do you know if a browser runs on one of the smartphone OSs but is not yet mentioned in my lists?
- Do you know if a device vendor sells one of the smartphone OSs but is not yet mentioned in my lists?
If you do, please leave a comment with a useful link (to the browser vendor’s homepage, or to a news item that mentions device vendor A selling smartphone OS B).
jQuery announced the jQuery mobile project, which aims at bringing jQuery to mobile browsers. All mobile browsers; not just Safari iPhone and Android WebKit.
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
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.
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
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.
and the media queries
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
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
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.
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).
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.
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
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:
- Smartphones are on the rise; 48% versus 35% last month.
- Feature phones are falling quickly; 58% to 35%.
- Still, the absolute number of feature phones rose by 31%, which means that the market as a whole is growing rapidly.
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.
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
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
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:
- IE6 is today’s most advanced browser. (Note: this was actually
true back in 2000. Please bear with me.)
- IE6’s market share is about 80%.
- 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.
- 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.
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.
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
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.
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.
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.
(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.)
I'll be giving a mobile workshop in Rotterdam next Monday. The workshop will be in Dutch, so the rest of this entry is in Dutch, too.
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.
width may be unreliable on the Android — in certain situations.
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.
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.
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.