UnPeuPlus

HTML5 apps

2010-03-09T14:28:55Z

Shared by PhilippeAntoine
HTML5 app: “an iPhone app that works on several other platforms, too, and doesn’t have to go through the app store approval process.”

Of course it’ll also be less advanced in eye candy, but that’s something we should conveniently neglect to mention

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.

What are HTML5 apps?

HTML5 apps

have one single core application;
are written with web standards, primarily HTML, CSS, and JavaScript;
and are deployed on more than one mobile platform.

Thus, normal websites are HTML5 apps. They are written with web standards, have one single core application (the website) and are deployed on more than one mobile platform (all of them, in fact).

Although I’m concentrating on the mobile web here, there’s no reason why a normal website meant primarily for desktop couldn’t also become an HTML5 app, as long as it also works on at least two mobile platforms (most likely iPhone and Android).

In addition to websites, local applications written with web standards, including but not restricted to W3C Widgets, would also qualify as HTML5 apps, as long as they share one core application.

The fact that we’re dealing with one single core application means that it’s fairly easy to update the HTML5 app. The fact that we’re using web technologies to deploy it means that there is no need to go through 27 app stores’ worth of approval processes. We just have to update the core files, redeploy the app, and it works everywhere.

Still, the problem lies in the deployment. In the short-term we probably have to use several systems in order the HTML5 app working on more than one platform. The market situation is chaotic, and we have to adapt — for now. I’ll get back to the technical details in a bit.

A new name

From a technical perspective all this makes solid sense, but there’s no real need for a new name. Still, I believe this scheme will fail without calling the resulting applications “HTML5 apps.”

There’s some justification for the “HTML” and “app” bits. HTML5 apps are all about applications (web-based or locally installed) that are squarely based on web standards, symbolised by HTML.

Of course the “5” makes no sense from a technical perspective. It’s quite possible to write an HTML5 app that does not use any actual HTML5 features.

From a marketing perspective this new name is exactly what we need, though. If we include the “5,” mobile web standards can hitch a ride on HTML5’s increasing popularity as a buzzword.

It’s just a marketing ploy. I hope Hixie doesn’t mind.

The problem

I am convinced that the HTML5 app route is the best one for a fat slice of the non-game iPhone apps currently out there, especially those that are simple and face stiff competition. Increased interoperability will help them more than a relative lack of eye candy will hinder them.

The problem is convincing clients of that.

Friends of mine have a two-year old daughter. Clients remind me of her. Picture her in her high chair. Picture her wanting something.

Portrait of the client as a two-year old, take 1

Client: [points at iPhone] Want iPhone app.
Me: That’ll only work on the iPhone, and about 80% of smartphone users have another phone. Interoperability is critical for a simple social media client facing stiff competition. Eye candy isn’t.
Client: Want! iPhone! App!
Me: [tries to hand non-iPhone device to client] Take this one, for instance. It’s very popular. An iPhone app won’t work on it, but a [website | web app | W3C Widget] would.
Client: [pushes non-iPhone device away] Don’t want that one. Want iPhone app!
Me: [shoves non-iPhone device into client’s hands] You need [website | web app | W3C Widget]!
Client: [throws non-iPhone device to ground] WANT IPHONE APP! [cries] IPHONE!
...
APP!
non-iPhone device: [sad] Bleep.

The solution

Instead of going against the grain and explaining that what they ask for is not actually what’s good for them, why not try to get clients to want a web-based solution? That, basically, is why we need a new buzzword.

Clients are very buzzword-sensitive because they don’t know better. They’re shielded from reality by a business logic layer of consultants who use a continuous stream of buzzwords to explain their high hourly rates.

Thus we’d have to insert a new buzzword into this stream: “HTML5 app.” The HTML5 bit helps a lot because it is a proto-buzzword with quite a bit of potential right now. Witness:

The Morgan Stanley mobile report (48M PDF) states on p. 142: “Products with best HTML5 browsers gain share.” Nobody bothers to define “HTML5 browsers,” but that doesn’t matter. We’re talking buzzwords here. See also pages 162-4.
“Developers [are] defecting from App Store to HTML5” according to ZDNet.
The Google Mobile blog already described the Google Voice application for iPhone and Palm as an “HTML5 application.” If we just get rid of the “lication” bit we’re in business.

Better, clients and even consultants know that HTML has something to do with the web. The new buzzword will point them in the right direction, while terms like “W3C Widgets” might conceivably cause confusion.

So let’s try to make “HTML5 apps” bloom into full buzzwordiness as the worthy successor to “iPhone app.” Who knows, it might even work.

Portrait of the client as a two-year old, take 2

Client: [points at iPhone] Want iPhone app.
Me: That’ll only work on the iPhone, and about 80% of smartphone users have another phone. Interoperability is critical for a simple social media client facing stiff competition. Eye candy isn’t.
Client: Want! iPhone! App!
Me: [gives non-iPhone device to client] Take this one, for instance. It’s very popular. An iPhone app won’t work on it, but an HTML5 app would.
Client: [pays real attention for the first time] ... HTML5 app?
Me: You want an HTML5 app?
Client: [swings legs happily] HTML5 app! Want HTML5 app!
Me: [takes HTML5 app from pocket and installs it on non-iPhone device] Look what we’ve got for you here?
Client: [clasps device ecstatically] HTML5 app![Shows it to me] Look, HTML5 app!
non-iPhone device: [happy] Bleep!

Selling HTML5 apps

So how do we sell the HTML5 app concept? In the short run we won’t be able to avoid a comparison to iPhone apps. (A mid-range goal would be to get rid of this comparison.)

Right now I think we should try to sell it as “an iPhone app that works on several other platforms, too, and doesn’t have to go through the app store approval process.”

Of course it’ll also be less advanced in eye candy, but that’s something we should conveniently neglect to mention if it’s in our client’s interest.

What you can do

Supposing you think all this is a good idea, there are several things you can do.

First of all, take actual business cases from actual clients and see whether they’d be served by an HTML5 app. The reasons for choosing an HTML5 app over a native app need more study.

You could even try to sell the concept to the client right now, but I think we need the buzzword to become better known before you can really have success in that arena.

More importantly, you could start to use the term “HTML5 app” with artful carelessness whenever it’s appropriate (and even when it isn’t), all the while projecting the assumption that obviously everybody knows what you’re talking about. That’s how a buzzword starts its life.

I have no idea if this is actually going to work, but it would be worth a shot. I myself am definitely going to try it.

Technical details

Still, selling HTML5 apps also means solving a few tricky technical problems. They fall apart in browser compatibility problems, for which progressive enhancement is the solution, and deployment problems, for which there is the beginning of a solution that has no name yet.

Progressive enhancement

If an HTML5 app must run on a plethora of browsers you have to test it in those browsers (or at least a good subset of them) and solve CSS and JavaScript issues.

This is going to be a problem, but it’s nothing fundamentally new. Although we’ll have to discover and solve a lot of brand-new compatibility problems, our mindset and tools are fundamentally the correct ones for the job ahead.

By far the most important tool is progressive enhancement. Where on the desktop progressive enhancement means not much more than daringly leaving out the rounded corners in IE6 and 7, the mobile space calls for a significant upgrade of the concept.

“If it doesn’t work, leave it out.” That’s the fundamental rule. For instance, the BlackBerry browser is totally lousy when it comes to JavaScript performance. If the problems get too hard, just switch off the script for BlackBerry and use a plain HTML/CSS version of the HTML5 app.

(RIM, the Blackberry vendor, is fully aware of these problems, by the way, and is working on a wholly new WebKit-based browser. Of course this browser will be different from all other WebKit-based browsers, but I expect it to be good.)

On the other side of the spectrum there’s the advanced CSS transformations and animations that Safari iPhone and Android WebKit support. It’s perfectly fine to use those, as long as you make sure your HTML5 app also works without them.

And don’t believe the silly nonsense that these advanced effects somehow must work in order for your HTML5 app to be a success. They don’t. They’re just eye candy. Use them when possible, but leave them out when necessary. (That’ll happen automatically anyway, because other browsers just won’t react to the transformation and animation CSS. There is no technical problem here, only a mindset problem.)

In order to create HTML5 apps we must use progressive enhancement as it’s really meant, and not as a theoretical construct that makes for a nice conference discussion topic but is shelved as soon as the client whispers “IE6.” On mobile there is no other way to deliver an HTML5 app on time and keep your sanity.

(Oh, and remember, IE doesn’t matter on mobile! Microsoft may make it matter by vastly improving its standards support, but mobile web developers aren’t required spend 30% of their time squashing IE bugs. Windows Mobile has only a 6% market share, and many Windows Mobile devices already use Opera as default browser. The ball is in Microsoft’s court here. Let’s see what the Windows Phone will bring.)

Deployment

Once we’ve solved the browser issues by applying progressive enhancement we need to deploy our HTML5 app to as many platforms as possible.

The simplest deployment mechanism is already in place and is called the World Wide Web. All smartphones, and even a goodly part of the feature phones, contain a browser, so all their users can visit your website.

Still, sometimes a local HTML5 app makes more sense, particularly when the app uses quite large JavaScript files. Avoiding a reload of those files every time the user starts up the app is well worth the effort. Besides, a local app can also function when the user has no connectivity at all.

If we want to offer our HTML5 app as a local application, we need a deployment mechanism that’s considerably more complicated than the WWW. Still, this is not an impossible task.

In fact, Uxebu has done some ground-breaking work by deploying an HTML5 app in pretty much the way described below. It wasn’t always easy, but it works. And now that we start to understand the basics it it will only get easier.

For local HTML5 apps W3C Widget packaging and configuration is the deployment mechanism of choice. It will become the worldwide standard because it’s already there, it makes sense, and it’s close to becoming a formal specification. Besides, many vendors are already hard at work implementing it.

W3C Widgets work on Vodafone S60 and Samsung phones, Opera desktop and mobile on any platform, the Bolt browser (a thin-client solution like Opera Mini), and Windows Mobile 6.5, while BlackBerry also supports them, though right now they need a special Java wrapper as an interface to the BlackBerry OS. There’s no reason to assume that the W3C Widget march will stop here.

Still, W3C Widgets are not enough for now. They don’t work on several platforms, most notably iPhone and Android, and that’s where the Phonegap library enters the picture. As a stop-gap measure it would become a deployment tool to make HTML5 apps available for the iPhone, Android, and BlackBerry platforms. Its creators consider Phonegap to be temporary; eventually all phones will have to support this sort of thing natively. For now we need a library, though.

Apple Dashboard widgets and their close cousins the Nokia Widgets would also count as HTML5 apps. They’re nearly the same as W3C Widgets except that they require an info.plist instead of a config.xml. Adding that file is of course trivial. Besides, Nokia will switch to true W3C Widgets in the not-too-distant future.

On the iPhone (and probably on other platforms, too) a native app can contain a Safari instance. Thus you can create a native app that still downloads its data from the Web, and combine some of the advantages of a native app with most of the advantages of an HTML5 app.

Then we need to study Palm’s webOS, the appcache technique that works on iPhone, maybe the NetFront widget manager, as well as any way of getting HTML5 apps to work on Moblin and LiMo devices.

Yes, it’s going to be complicated. It’s going to take time and effort. It’s also going to take automation.

I expect that in the not-too-distant future a clever web developer will create a site that gives people a way of uploading a core HTML5 app and automatically convert it to a W3C Widget, Phonegap-based native iPhone, Android, and BlackBerry apps, a Dashboard widget, a Palm webOS native app, plus any other platform-specific solution that is necessary.

Conclusion

Concluding, deployment is by far the most tricky problem that early HTML5 apps will run in to, and even there we have the beginnings of a solution. Other than that there aren’t that many arguments against HTML5 apps. As far as I’m concerned the new buzzword will force all relevant parties in the mobile space to firmly opt for web standards, and that’s what we all want, don’t we?

Links for 2010-03-07 [del.icio.us]

2010-03-08T00:00:00-08:00

IE7.js gets an update

2010-03-07T18:48:26Z

IE7.js is finally updated!

Here are the changes:

MSIE5.0 is no longer supported
Layout fixes are no longer applied in quirks mode (except for MSIE5.5)
IE9.js provides improvements to MSIE8
support for opacity is moved to IE9.js
New selectors (IE9.js):
- :first-of-type
- :last-of-type
- :only-of-type
- :nth-of-type()
- :nth-last-of-type()
:contains() has been removed (no other browser supports it)
Changes to the PNG solution
Lots of bugs fixed
New faster and more accurate selector engine (the same as in the upcoming release of base2)
I think I’ve fixed the unclickable links problem too

There is a demo page here:

http://ie7-js.googlecode.com/svn/test/index.html

And you can download it from here:

http://code.google.com/p/ie7-js/downloads/list

Links for 2010-03-06 [del.icio.us]

2010-03-07T00:00:00-08:00

Links for 2010-03-05 [del.icio.us]

2010-03-06T00:00:00-08:00

Links for 2010-03-04 [del.icio.us]

2010-03-05T00:00:00-08:00

Links for 2010-03-03 [del.icio.us]

2010-03-04T00:00:00-08:00

Links for 2010-03-02 [del.icio.us]

2010-03-03T00:00:00-08:00

flogr - Project Hosting on Google Code
Lighty2Go
nginx
How to create offline webapps on the iPhone | The CSS Ninja - All things CSS, Javascript & xhtml
Putting a Webserver on your iPhone
iPhone Patch: Patch Safari
how to use file:// safari patch?
Safari patch in Cydia as "file:// Schema in Safari" a
iPhone Lover » Blog Archive How to view local PDF, DOC, XLS, TXT and others with Safari in iPhone -

KawaCampParis1, c'est reparti

2010-03-02T21:18:00Z

Le KawaCampParis1 avait été reporté la date est maintenant officielle ce sera le 23/03. Ca se passe toujours au Quigley's Point aux Halles (paris 1er). Les inscriptions et les infos sont toujours sur le wiki barcamp.org : KawaCampParis1

Links for 2010-03-01 [del.icio.us]

2010-03-02T00:00:00-08:00

Noktor introduces HyperPrime 50mm f/0.95 lens

2010-03-01T12:24:00Z

After a brief online campaign, US-based company Noktor has announced its first product: the HyperPrime 50mm f/0.95 lens for Micro Four Thirds cameras. This ultra-fast manual focus lens with manual aperture control bears an uncanny resemblance to the Senko 50mm f/0.95 C-mount CCTV lens and shares almost all of its vital specifications. The company, that appears to be registered to a residential property in Canton, Georgia will start shipping the lens from April 15, 2010 at a retail price of $750.

Web Compatibility Test strikes back

2010-02-23T16:00:37Z

We did it again!

Back in 2008, the Mobile Web Test Suites Working Group released its first Web Compatibility Test for Mobile Browsers that packed 12 (and later, 16) important Web technologies into a single page that would tell you at a glance how well your browser supported them.

Fast forward to 2010, the level of support on this first Web compatibility test has tremendously improved, although the browsers that show a fully green grid are still few.

But in the meantime, the technologies have also evolved, and while many of them are still not final by any means, it seemed that getting an overview of which of these technologies are available today on what browsers would make a good follow-up to our first test.

That's the goal of our second Web compatibility test for mobile browsers that tests a number of Web technologies through their JavaScript interfaces, and collects detailed results on which browsers pass which tests.

This is the first release of the test, so it likely isn't quite perfect, and as always, the choice of the tested technologies is somewhat arbitrary; we are very much looking for feedback, either in the comments here, on our Working Group blog, or to our public mailing list.

greut: RT @typekit: Just launched: Buy fonts at FontShop, host them on Typekit - at no additional cost! http://j.mp/bSGhPH

2010-02-24T15:16:32Z

greut: RT @typekit: Just launched: Buy fonts at FontShop, host them on Typekit - at no additional cost! http://j.mp/bSGhPH

wtfjs

2010-02-12T21:40:44Z

Bookmark this on Delicious - Saved by tourist604 to javascript wtf programming js code fun language hacks coding humor - More about this bookmark

On MicroSD Problems « bunnie's blog

2010-02-16T12:55:57Z

Bookmark this on Delicious - Saved by galfridus to hardware technology business engineering microsd electronics memory kingston flash hacking - More about this bookmark

BitTorrent visualization in processing.js

2010-02-17T09:13:02Z

Bookmark this on Delicious - Saved by dbyler to bittorrent visualization processing graphics javascript torrent simulation js tutorial visual - More about this bookmark

How Google Went Into "Code Red" And Saved Google Buzz

2010-02-16T20:58:45Z

Bookmark this on Delicious - Saved by Roger_W to google buzz privacy googlebuzz socialmedia business customerservice marketing blog bussiness - More about this bookmark

Browser news from the Mobile World Congress

2010-02-18T19:07:25Z

Shared by PhilippeAntoine
"Ignore any post you read about the new BlackBerry browser somehow making the creation iPhone-only sites more acceptable. That’s just uninformed nonsense"

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.

MWC is huge, and by that I don’t mean SxSW-style huge. You could drop all of SxSW smack-bang in the middle of MWC, and nobody would notice (apart from the people in the drop area). With only 50,000 delegates this was a decidedly bad year, as one Vodafone MWC veteran pointed out to me.

All major and a lot of minor mobile players were there, with the exception of Apple and (curiously) Nokia. Apple’s absence was expected; it follows its own unique trajectory and basically ignores the rest of the industry when it comes to announcements. (Apple might have a point here; it gets more attention for its announcements when they’re done entirely outside the MWC timeframe.)

Nokia’s absence created a huge buzz; it was the main MWC sponsor for many years before it suddenly withdrew this year. Unfortunately I’m not yet well enough versed in mobile political sciences to be able to explain this. (And don’t leave a “simple” explanation in the comments! This stuff isn’t simple!)

Phone-wise I was deep, deep inside BlackBerry land, as you’d expect with business executives and marketing people. There were few iPhones, I saw almost no Androids, though Samsung had a surprisingly solid presence.

Anyway, the main general question right now is when browsers will become a hot topic on MWC. This year they weren’t; the 30-minute panel for about 100 attendees I participated in was about the most browser-focused event of the entire conference. Still, I believe that browser quality is an emerging theme in mobile, so I expect a future MWC (next year? year after? 2013?) to be more browser-aware.

This will be something to watch; if even business executives start to seriously consider browsers, web technologies will have basically annexed the mobile space. That would be a cool extension to our current reach, right?

For those following the smartphone market Tomi Ahonen’s smartphone war frontline update is required reading. He currently expects Apple to be in serious trouble because Christmas sales were bad. It will be interesting to follow that storyline as it unfolds.

Announcements

Everybody and their dog considers MWC the prime venue to make exciting announcements. As a result you hear all announcements at once, and few make more than a fleeting impression.

Besides, MWC is not a technical conference. It’s a business and marketing conference where business and marketing people try to impress other business and marketing people by firing off a stream of tech-based buzzwords.

Neither the broadcasting nor the receiving party have the slightest clue what they’re talking about, and it’s this curious mechanism that gives all MWC-related press releases the unique vagueness that make them so hard to interpret by techies.

Nonetheless I’ve carefully gathered most (all? nah, probably not) announcements that are important to web developers. Here’s the list, in the approximate order in which they made a splash in web dev land.

Microsoft

Microsoft announced its new Windows Phone line which runs Windows Mobile 7, and a new version of IE that I currently expect to be based on IE8. I saw from my Twitter feed that this announcement was well-received. Unfortunately the Microsoft stand turned out to have no actual Windows Phones in it, so I couldn’t test anything and will reserve judgement until I’ve actually used one.

More in general, this is Microsoft’s last chance to matter on mobile, and they know it. Windows Mobile 6.1 is just spectacularly bad. Windows Mobile 6.5 is a lot better, but still no real competitor to iPhone, Android, or Symbian. Will Windows Mobile 7 help here? Only time will tell.

Obviously I’ll post a full test report as soon as I can get my hands on a device.

Opera

Opera was canny enough to send out its exciting announcement slightly ahead of the crowd. It will shortly submit Opera Mini to the Apple App Store. Although at first I doubted the technical wisdom of this move (Safari iPhone is far ahead of Opera Mini, which, after all, does not offer any client-side interactivity), I’m now starting to revise my opinion.

Personally, I’d welcome Opera Mini because my Safari iPhone has taken up the nasty habit of crashing on my webmail site. The more I reload it (and have to re-login), the higher this crash chance is.

More in general, Opera Mini uses far less bandwidth than Safari iPhone because it sends a highly compressed version of the site to the phone. Right now that might matter on lousy connections (such as the ones in Barcelona, where 50,000 mobile professionals clogged the networks considerably). In the future, though, it will start to matter even more because eventually the operators will put an end to the economically untenable flat-rate iPhone data plan. When that happens Opera Mini will become an interesting alternative because it saves you money.

Still, the main point of this release is political. By publicly announcing their intent, Opera has put Apple in the position of either allowing the first competing browser on the iPhone or being slammed for not allowing it. (Currently all alternative iPhone browsers use the Safari rendering engine; Opera Mini would be the first to use a different one.)

It’ll be interesting to see how this one plays out.

WAC and network APIs

Then, no less than 24 global operators announced the Wholesale Applications Community which aims at spreading applications to an installed base of not 100 million iPhone users, but 3 billion users of other phones.

This is typically something operator executives love; it’s an “answer” to the App Store (which, in my opinion, doesn’t need an answer because it’s slowly going to be transformed into a niche market mostly for games and other applications that need to be native, and not web-based. But I digress.)

Obviously, the announcement gave no technical details whatsoever. This is a business and marketing thing, after all.

Still, to anyone who spends more than half a second thought on it it should be clear that there’s only one single technology that gives the operators a fighting chance of attaining their objective: web technologies.

Unfortunately, the fact that web standards are the obvious answer does not mean that they will actually play a role in the WAC initiative. Ignoring the obvious is something that executives are very good at.

Still, Vodafone is part of the consortium, and Vodafone is investing heavily in web standards (even to the extent of paying me to do fundamental research). So I guess we can hope. As far as I know the Vodafone widget-based system is currently the only one that works on more than one platform.

Related to this is the news that operators are working on “network APIs.” I’m not yet totally sure what they are (technical info, as usual, is completely absent), but it seems likely that they’ll include APIs for mobile payments.

The point here is that operator-based payments are the most user-friendly ones possible because, contrary to every single current app store, you do not need to log in. Your identity is ascertained through your SIM card, and the payment is added to your operator bill. Mobile payments cannot be made any simpler than that. (Besides, the operators obviously love this middle-man position.)

BlackBerry WebKit

Then BlackBerry announced that a new WebKit-based browser is coming up. This is no surprise to anyone following the mobile industry. About six months back BlackBerry acquired Torch Mobile, the creator of the Iris browser. Since the Iris browser scored rather well in my tests, it was obvious that BlackBerry wanted a high-quality replacement for their proprietary browser whose Best-Before date was reached somewhere in 2008.

As far as I know there were no actual devices with the new browser in Barcelona (but by the time this news reached me I had become very tired, and I didn’t try very hard to find them).

Still, the 100/100 Acid 3 score gives us a clue as to what’s going on. I found only four WebKit-based browsers with this score: Safari desktop and iPhone, Chrome, and Iris. (Android 2 not yet tested; wouldn’t be surprised if it scored 100/100, too.)

I assume that the Torch Mobile team has been working on an actual port of the Iris browser to the BlackBerry OS instead of creating a wholly new one. This would bode well for the mobile web.

But remember: THERE IS NO WEBKIT ON MOBILE! This is no iPhone WebKit magically transmuted into a BlackBerry application, it’s a completely separate WebKit implementation. A good one, most likely, but that doesn’t mean it’s the same as the iPhone.

Ignore any post you read about the new BlackBerry browser somehow making the creation iPhone-only sites more acceptable. That’s just uninformed nonsense. However, using BlackBerry WebKit as an additional argument for serious use of progressive enhancement, as Andy proposes, is an excellent strategic idea that’s worth a try.

Obviously I’ll post a full test report as soon as I can get my hands on a device.

Adobe

The Adobe stand was all about Flash, and sported the tagline “One Web, any device.” Although I agree with the basic sentiment, I’m not sure if Flash is going to deliver on that promise. I’d like a list of mobile platforms on which it is supported, but obviously the Adobe site doesn’t give any clue of that. (Nobody ever does that ever; everybody’s very vague about platforms and just assures anyone who’s willing to listen that their mobile solution works practically everywhere. But I digress.)

This list of mobile Flash videos is the closest I came, and it mentions Android and Palm, but no other platforms. Not exactly a huge user base.

The odd thing is that Adobe’s announcement was not about Flash but about AIR. This, apparently, will be the technology to deliver content across all platforms — well, to Android and BlackBerry, at least.

We’ll see. The pro of AIR (or Flash) would be that it is the single RIA environment (except for plain old HTML, CSS, and JavaScript) that works on more than one platform. The con is that it doesn’t work on that many platforms.

Adobe AIR uses WebKit, by the way. I never tested it, but it’s safe to assume that it’s different from all other WebKits.

Samsung bada

One of my personal top stories was the unveiling of Samsung bada (Korean for ocean; not capitalised), the new smartphone OS that runs a spiffing new WebKit implementation that’s different from all other WebKit implementations.

I give kudos to Samsung for actually allowing anyone to play with their new Wave phone in their stand. I took the opportunity to invent guerilla browser testing; I fired up the browser and did some very quick tests while standing in the Samsung stand. I returned twice when I’d thought of more tests to do. I crashed two phones in the process.

The WebKit-based browser seems to be called Dolfin; in line with the ocean metaphor that Samsung has chosen. It is not to be confused with the Dolphin browser for Android — I think.

The bad news is that Dolfin is not yet very good. The good news is that Samsung clearly stressed that the software wasn’t yet final; changes would be made. I hope they change a lot on the browser side of things.

I was able to prove that Dolfin is closely related to the widget manager WebKit on the H1/M1 Vodafone devices; something I’d more or less expected. There’s one bug in my still-unpublished width research that occurs only on the Samsung bada and widget manager WebKits, and nowhere else. (There is no “WebKit on Mobile!” They’re all different!)

As a whole bada seems a reasonably good platform. The point here is that it’s not meant as a high-end smartphone platform that competes with iPhone, Android, or Maemo, but instead a mid-range one that will compete with Symbian. Some quality has been sacrificed on the altar of affordability.

Bolt and widgets

The Bolt browser, which is the main competitor to Opera Mini, now supports W3C Widgets in version 1.7. Bolt is WebKit-based, by the way, but it’s different from all other WebKits.

This news is interesting because it requires Bolt to use a different architecture than the standard widgets W3C is defining and Vodafone and Opera are implementing. Such a widget is an application stored on the device that uses a full browser that offers full JavaScript capabilities to run in.

Like Opera Mini, Bolt does not support client-side interaction, but instead requires a full page refresh every time a script changes something to the DOM. Besides, the widgets cannot be stored on the device because there’s no full browser there, just a thin client that gets its instructions from the server. Therefore the widgets will be stored server-side. The downside of this is that you need something like a Bolt account to access your widgets. (Details aren’t clear to me.)

Android

Google’s announcement was that 60,000 Android phones are sold per day. Let’s be clear: this encompasses all Android phones, whether they’re branded by Google itself, HTC, Samsung, Motorola, SonyEricsson, or minor players. Still, it’s an impressive number that might upgrade Android to third-largest smartphone operating system in 2010, after Symbian and BlackBerry, but before the iPhone.

Still, all’s not well in the Android world. The problem is the Nexus One. Google’s release of its own branded phone (created by HTC) has widely been interpreted as a stab in the back of Motorola, who’s gambled its existence as a smartphone vendor (or even as a device vendor in general) on the Droid-centred Android strategy. The Google phone is obviously a serious competitor to the Droid in the eyes of the affluent tech-savvy US smartphone purchaser. (Motorola is irrelevant outside the US.)

To partly make up for that HTC unveiled the Desire, an HTC-branded and -skinned phone that runs on exactly the same hardware as the Nexus One. HTC’s brand awareness doesn’t come close to Google’s, but still it has a decent market share in Asia and Europe, and of the generic vendors without their own OS I definitely rank HTC first when it comes to interface design and general performance. They even made Windows Mobile 6.1 work — more or less.

Right now I don’t know how much all this matters. Some people will buy an Android phone specifically; others buy a SonyEricsson, HTC, or Motorola phone without knowing anything about the OS. Motorola will likely fall out of the race in 2010, and it could full well blame Google, but it’s certain that Google won’t care. Meanwhile it’s unclear whether Google cares about the HTC Desire.

In any case, of the sub-markets the Android one will remain by far the most complicated because there are so many players involved. Every single Android player, however, has at least one alternative platform in case of emergency. Except for Google.

Android will be one of the major unfolding stories of the year.

Nokia and MeeGo

As to Nokia, despite being absent from MWC it had one announcement for each of its smartphone platforms. Symbian^3, the successor to S60, is coming this year. No more details are known, but I expect its WebKit to be significantly upgraded. (It still will be different from all other WebKits, though.)

More interesting is the Maemo news, because industry pundits generally expect Maemo to become Nokia’s high-end smartphone platform, while Symbian will serve the low end and the business market.

Point is, Maemo’s gone. It has been merged with Intel’s Moblin platform to produce MeeGo (silly name in my opinion, but nobody asked me). I have no clue what this means in terms of browsers (technical details, obviously, are absent). And no, I have no idea what Intel was doing in the mobile OS world, either. Maybe this merger was the point. (Whose chipsets will the new MeeGo devices use?)

For now I assume that the Gecko-based MicroB browser will remain the default one of the new system, and that Mozilla will create a Firefox port for it. That’s just guesswork, though.

The most interesting tidbit is that the new MeeGo platform is not restricted to Nokia; LG just announced it will release a MeeGo phone. It was already working with Moblin, anyway, so moving to the new platform wouldn’t be such a huge step.

I hope the photo in the article does not depict LG’s new phone, though. The photo shows the Obigo browser, and if there’s one browser you should definitely avoid if you want to give your users a forward-looking browsing experience it’s Obigo.

That concludes my coverage of the MWC news. If you have more mobile browser news, please leave a link in the comments.

xpoxpo: http://bit.ly/c4tOTR Enlarge la Cantine ! Congrats. #lacantine

2010-02-16T14:43:45Z

xpoxpo: http://bit.ly/c4tOTR Enlarge la Cantine ! Congrats. #lacantine

A new Buzz start-up experience based on your feedback

2010-02-13T23:53:00Z

Posted by Todd Jackson, Product Manager, Gmail and Google Buzz

We've heard your feedback loud and clear, and since we launched Google Buzz four days ago, we've been working around the clock to address the concerns you've raised. Today, we wanted to let you know about a number of changes we'll be making over the next few days based on all the feedback we've received.

First, auto-following. With Google Buzz, we wanted to make the getting started experience as quick and easy as possible, so that you wouldn't have to manually peck out your social network from scratch. However, many people just wanted to check out Buzz and see if it would be useful to them, and were not happy that they were already set up to follow people. This created a great deal of concern and led people to think that Buzz had automatically displayed the people they were following to the world before they created a profile.

On Thursday, after hearing that people thought the checkbox for choosing not to display this information publicly was too hard to find, we made this option more prominent. But that was clearly not enough. So starting this week, instead of an auto-follow model in which Buzz automatically sets you up to follow the people you email and chat with most, we're moving to an auto-suggest model. You won't be set up to follow anyone until you have reviewed the suggestions and clicked "Follow selected people and start using Buzz."

For the tens of millions of you who have already started using Buzz, over the next couple weeks we'll be showing you a similar version of this new start-up experience to give you a second chance to review and confirm the people you're following. If you want to review this list now, just go to the Buzz tab, click "Following XX people" and unfollow anyone you wish. If you don't want to share the lists of people who are following you and people you are following publicly on your profile, you can opt out at any time from the edit profile page.

Second, Buzz will no longer connect your public Picasa Web Albums and Google Reader shared items automatically. Just to be clear: Buzz only automatically connected content that was already public, so if you had previously shared photos in an "Unlisted" album or set your Google Reader shared items as "Protected," no one except the people you'd explicitly allowed to see your stuff has been able to see it. But due to your feedback Buzz will no longer connect these sites automatically.

Third, we're adding a Buzz tab to Gmail Settings. From there, you'll be able to hide Buzz from Gmail or disable it completely. In addition, there will be a link to these settings from the initial start-up page so you can easily decide from the get go that you don't want to use Buzz at all.

It's been an exciting and challenging week for the Buzz team. We've been getting feedback via the Gmail help forums and emails from friends and family, and we've also been able to do something new: read the buzz about Buzz itself. We quickly realized that we didn't get everything quite right. We're very sorry for the concern we've caused and have been working hard ever since to improve things based on your feedback. We'll continue to do so.

Update (2/18): These changes are now live with the exception of the similar version of the start-up experience for those of you who are already using Buzz.

RT @remis: So happy that vark acquisition by google is finally public. Congrats to the team. After...

2010-02-12T08:50:23Z

RT @remis: So happy that vark acquisition by google is finally public. Congrats to the team. After Affinity, that’s 2 exits in a row for me.

Playground: Environmental tagging of pictures

2010-01-10T13:40:15Z

small idea. Pictures or video are supports to remember, reconstruct our experiences of life and a way to transfert them without spatio-temoral constraints. In regards of the current green trend, can I also add environemtal information to such support of memory to capture also environmental dimensions of my experience? Can I take augmented pictures capturing also [...]

VIDEO: Derek Sivers' 3-minute TED talk.

2010-02-11T15:45:00Z

Derek Sivers’ 3-minute TED talk.

Introducing Project Rosetta Stone

2010-02-11T20:24:13Z

Shared by PhilippeAntoine
Pivot Music Ids...

Here at The Echo Nest we want to make the world easier for music app developers. We want to solve as many of the problems that developers face when writing music apps so that the developers can focus on building cool stuff instead of worrying about the basic plumbing . One of the problems faced by music application developers is the issue of ID translation. You may have a collection of music that is in once ID space (Musicbrainz for instance) but you want to use a music service (such as the Echo Nest’s Artist Similarity API) that uses a completely different ID space. Before you can use the service you have to translate your Musicbrainz IDs into Echo Nest IDs, make the similarity call and then, since the artist similarity call returns Echo Nest IDs, you have to then map the IDs back into the Musicbrainz space. The mapping from one id space to another takes time (perhaps even requiring another API method call to ’search_artists’) and is a potential source of error — mapping artist names can be tricky – for example there are artists like Duran Duran Duran, Various Artists (the electronic musician), DJ Donna Summer, and Nirvana (the 60’s UK band) that will trip up even sophisticated name resolvers.

We hope to eliminate some of the trouble with mapping IDs with Project Rosetta Stone. Project Rosetta Stone is an update to the Echo Nest APIs to support non-Echo-Nest identifiers. The goal for Project Rosetta Stone is to allow a developer to use any music id from any music API with the Echo Nest web services. For instance, if you have a Musicbrainz ID for weezer, you can call any of the Echo Nest artist methods with the Musicbrainz ID and get results. Additionally, methods that return IDs can be told to return them in different ID spaces. So, for example, you can call artist.get_similar and specify that you want the similar artist results to include Musicbrainz artist IDs.

Dealing with the many different music ID formats One of the issues we have to deal with when trying to support many ID spaces is that the IDs come in many shapes and sizes. Some IDs like Echo Nest and Musicbrainz are self-identifying URLs, (self-identifying means that you can tell what the ID space is and the type of the item being identified (whether it is an artist track, release, playlist etc.)) and some IDs (like Spotify) use self-identifying URNs. However, many ID spaces are non-self identifying – for instance a Napster Artist ID is just a simple integer. Note also that many of the ID spaces have multiple renderings of IDs. Echo Nest has short form IDs (AR7BGWD1187FB59CCB and TR123412876434), Spotify has URL-form IDs (http://open.spotify.com/artist/6S58b0fr8TkWrEHOH4tRVu) and Musicbrainz IDs are often represented with just the UUID fragment (bd0303a-f026-416f-a2d2-1d6ad65ffd68) – and note that the use of Spotify and Napster in these examples are just to demonstrate the wide range of ID format.

We want to make the all of the ID types be self-identifying. IDs that are already self-identifying can be used without change. However, non-self-identifying ID types need to be transformed into a URN-style syntax of the form: vendor:type:vendor-specific-id. So for example, and a Napster track ID would be of the form: ‘napster:track:12345678′

What do we support now? In this first release of Rosetta Stone we are supporting URN-style Musicbrainz ids (probably one of the most requested enhancements to the Echo Nest APIs has been to include support for Musicbrainz). This means that any Echo Nest API method that accepts or returns an Echo Nest ID can also take a Musicbrainz ID. For example to get recent audio found on the web for Weezer, you could make the call with the URN form of the musicbrainz ID for weezer:

http://developer.echonest.com/api/get_audio
         ?api_key=5ZAOMB3BUR8QUN4PE
         &id=musicbrainz:artist:6fe07aa5-fec0-4eca-a456-f29bff451b04
         &rows=2&version=3 - (try it)

For a call such as artist.get_similar, if we are using Musicbrainz IDs for input, it is likely that you’ll want your results in the form of Musicbrainz ids. To do this, just add the bucket=id:musicbrainz parameter to indicate that you want Musicbrainz IDs included in the results:

http://developer.echonest.com/api/get_similar
               ?api_key=5ZAOMB3BUR8QUN4PE
               &id=musicbrainz:artist:6fe07aa5-fec0-4eca-a456-f29bff451b04
               &rows=10&version=3
               &bucket=id:musicbrainz  (try it)

<similar>
    <artist>
          <name>Death Cab for Cutie</name>
          <id>music://id.echonest.com/~/AR/ARSPUJF1187B9A14B8</id>
          <id type="musicbrainz">musicbrainz:artist:0039c7ae-e1a7-4a7d-9b49-0cbc716821a6</id>
          <rank>1</rank>
    </artist>

<!– more omitted –>

</similar>

Limiting results to a particular ID space – sometimes you are working within a particular ID space and you only want to include items that are in that space. To support this, Rosetta Stone adds an idlimit parameter to some of the calls. If this is set to ‘Y’ then results are constrained to be within the given ID space. This means that if you want to guarantee that only Musicbrainz artists are returned from the get_top_hottt_artists call you can do so like this:

http://developer.echonest.com/api/get_top_hottt_artists
       ?api_key=5ZAOMB3BUR8QUN4PE
       &rows=20
       &version=3
       &bucket=id:musicbrainz
       &idlimit=Y

What’s Next? In this initial release of Rosetta Stone we’ve built the infrastructure for fast ID mapping. We are currently supporting mapping between Echo Nest Artist IDs and Musicbrainz IDs. We will be adding support for mapping at the track level soon – and keep an eye out for the addition of commercial ID spaces that will allow easy mapping being Echo Nest IDs and those associated with commercial music service providers.

In the near future we’ll be rolling out support to the various clients (pyechonest and the Java client API) to support Rosetta Stone.

As always, we love any feedback and suggestions to make writing music apps easier. So email me (paul@echonest.com) or leave a comment here.

Sans proportions, première partie

2010-02-08T16:44:15Z

A SUIVRE !

Désolé de vous faire ce coup là, une fois n’est pas coutume mais vous savez quoi ? Hé bien ça prend du temps tout ce bazar à mettre en place!
Alors je saucissonne.
Au prochain épisode donc, la préparation de la pâte à crêpes.
Et nous terminerons en fin de semaine par la cuisson.

Sinon, quelle déception de constater que tout le monde connaissait la recette (soi-disant secrète) de mon pépé… Quel héritage pourri !

A bientôt !

The iPhone obsession

2010-02-08T12:13:20Z

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:

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.

Warning! iCandy will damage your brain!

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:

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

Let’s break these sales stats down by continent. Asia excluding Japan first:

Nokia: 75%
Apple: 8%
HTC: 6%
RIM: 4%
Samsung: 3%
Motorola: 2%

Western Europe:

Nokia: 48%
Apple: 20%
RIM: 15%
HTC: 10%
Samsung: 5%
SonyEricsson: 1%

Finally North America:

RIM: 51%
Apple: 29%
HTC: 6%
Palm: 5% (probably includes PalmOS devices)
Nokia: 4%
Samsung: 2%
Sharp: 1%

Apple is second in every market, but the least difference with the market leader is 22% in North America.

Source: Morgan Stanley Mobile Internet Report (48Meg PDF) p. 160

North Americans are parochial in their choice of a smartphone. One more reason why the North American market has zero predictive value for the rest of the world.

Oddly, Europeans buy relatively more Asian smartphones, while Asians buy relatively more European smartphones.

The Japanese market is so very different from all the others that I left it out. Besides, a full 20% of Japanese smartphone sales fall in an unspecified “others” category. Apple is fourth with 10% of sales.

The Japanese are even more parochial than the Americans when it comes to selecting a smartphone, but that’s partly caused by the unique shape the mobile space has in that country. None of the Western manufacturers has truly created an inroad in the most advanced mobile market in the world.

Incidentally, the Japanese market does have predictive value for the rest of the world, but it’s sometimes so advanced that it’s hard to understand.

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

Symbian: 45% (all of Nokia plus a bit of SonyEricsson and Samsung)
BlackBerry: 20%
iPhone: 15% (this 15% is obviously far more important than the previous 65%)
Windows Mobile: 6% (HTC, Samsung, SonyEricsson)
Android: 4% (HTC, Samsung, SonyEricsson, Motorola, Google)
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.

Source: Morgan Stanley Mobile Internet Report (48Meg PDF) p. 75

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.

BUSTED: Sarah Palin Caught Scribbling Speech Notes On Her Hand

2010-02-07T20:21:00Z

You can stop making fun of Barack Obama for his dependence on a teleprompter. Sarah Palin -- the biggest hero of the right -- was caught by AP photographers with cliff notes on her hand.

See on her left hand there?

Maybe not. That's okay. HuffPo zoomed in and cropped it closer:

We can read the top word, energy, pretty clearly.

We also see the word "tax" in there.

We're not sure what the other ones are. Any thoughts?

And if you're still not convinced. Mediaite has the video of her looking down at her hand during a Q&A. Watch around the :50 mark, and you'll see it's pretty clear.

Join the conversation about this story »

See Also: