Live Blog: PPK on the Future of the Mobile Web

This comes from a talk on mobile web given by PPK the last time I was in this part of the world, before a full house at the very large eBay/PayPal “town hall” in San Jose on April 6. I decided to hold off posting it as he mentioned he’s not releasing the slides so he can deliver the same talk a few more times. With two imminent talks on mobile HTML5 today at Google IO, timing is right to hit the Publish button.

This is still a live blog (I’m far too lazy to edit such things even after the event), so usual typo etc caveats apply.

(>Picture from a different event on the same topic…but how could I not include this one?)

Amid a frenzy of mobile HTML5 hacking at the HQ, I spot a tweet from the veritable @dalmaer:

@AndreCharland come to the @PPK meetup tonight! A bunch of folks are going 🙂less than a minute ago via Twitter for Mac Favorite Retweet Reply


I’m in the area and not going to let the opportunity pass. So here I am.

PPK, Quirks man that he is, explains that the mobile web is more exciting than desktop these days. Twenty browsers and counting! But beyond the proliferation of browsers to pore into, mobile matters. Eventually around five times the number of desktop users in PPK’s estimate.

Luke Wroblewski invented the “Mobile First” mantra. The mobile constraint forces you to design lean. Even a big screen is 480*360…that’s what you get to deal with, and any fluff sends them right to your competitor. Consider a news site. All you see is headlines. Funny about that, it’s all you really need.

On Mobile Browsers

PPK lists a plethora of mobile browsers and asks, “Do you have to test on each of these?”. Answer: “In theory, yes. In practice, don’t be silly.” PPK continues to drive his message that there’s “no” mobile WebKit. Witness the comparison of mobile WebKits at http://quirksmode.org/webkit.html.

It’s important to be aware of the Proxy Browsers, namely: Opera Mini (not Opera Mobile), Ovi (upcoming from Opera), Bolt, and UCWeb. With these browsers, a highly compressed image is sent to the client, and this actually has two (potential) benefits: less network cost and less device requirement. However, once you get fancy with client-side scripting, these devices won’t do much at all. It’s just not what they’re made for.

The Stattage

Time for some stats. According to StatCounter, in Q4, 2010:

  • Safari: 23%
  • Opera: 22%
  • BlackBerry: 18% and dropping
  • Nokia: 16%
  • Android: 12% and growing fast
  • NetFront 4% (on basic Sony Ericsson and Samsung)
  • Samsung 1% (on Bada)

MS doesn’t feature here because many manufacturers introduce Opera (or other) instead of relying on the default IE browser. Interestingly, the Bada browser was met approvingly when PPK showed it to folks recently, and does well in performance.

It’s important to be aware of your own stats and circumstances too, e.g. PPK noticed, for his site at least, social media referrals cause disproportionate queries from iPhone and Android. So people dependent on social media should think about those.

PPK says right now, the browsers for most developers to consider, are Safari iPhone, Opera Mini, and Android Webkit. Beyond that, it depends on geography. In the US, BlackBerry is next to consider. Unfortunately, a recent stat said 90% of BlackBerry users are still on 5.0 or older, ie no WebKit and a very quirky browser. In Europe, Nokia WebKit matters more. Beyond that, Dolfin for bada and Opera Mobile are worth considering; fairly low mobile share, but pretty easy if the others worked.

“Mobile gives us the opportunity to practice what we preach when we talk about web standards”

We all talk about progressive enhancement, but who actually uses it? Again, mobile forces your hand! Basic JavaScript, to augment your semantically sweet HTML, is fine. But advanced – Ajax requests and beyond – may not, so think of progressive enhancement as a spectrum. Also, remember Ajax reuests go over the network, so they can slow things right down and require caution.

PPK argues for feature detection where possible, but experienced developers say browser detection is the only way in some cases.

The Future of Apps

HTML5 is not just a technology that runs in the browser, but one that powers apps. This is a conversation PPK just about kicked off a couple of years ago, and recent trends have begun to vindicate this view. Plugs for http://apparat.io and http://build.phonegap.com from PPK right about now.

PPK Questions the Future of App Marketplaces

Right now, the proverbial developing-national fisherman might pay $25 for a Nokia feature phone. Stuff is changing. This year, we’ll probably get $75 Android phones, says PPK. Too much for the fisherman right now. But give it a few years and the fisherman’s phone is running apps. Is he using a marketplace? Right now, those mostly require credit cards, so what happens? Download from the net? Too expensive.

So this is where PPK talks about transferring apps device-to-device. The apps are transferred by bluetooth or NFC and the data transferred with JSON-over-SMS. PPK says it’s hard right now to transfer via bluetooth on newer phones, where it works fine on future phones. The end of app stores is a consequence of this vision, sharing Eric Meyer’s quote: “Why is everyone so exercised? As with all walled gardens, the web will interpret the App Store as damage and route around it.”

(MM – This opens up a lot of security concerns.)

Why does PPK think the marketplaces won’t work for all the platforms in the long term? * Discoverability – worked in the past, but is harder in a more cluttered environment. * Distribution – the web works just as well or better for distribution * Works for Apple – it’s proven that the average Apple consumer will spend money on Apple. PPK argues Google has more leverage with developers than consumers. He says that’s the opposite for Nokia, Samsung, and RIM – in his theory, they have high leverage with consumers and low leverage with developers. * Cost of Ownership – Marketplaces need payment systems, sysadmins, content checkers, documentation and best practices writers, and they cost money.

PPK notes there’s a problem with Device APIs right now, i.e. users are prone to “Yes” everything. He notes there’s a UI issue with modal dialogs – users will say yes! Specs are BONDI, JIL, DAP, and WAC 2.0.

Startups Share Chrome Web Store Experiences

Part of my role in developer relations is to work with startups who are using Google’s platforms, and for me, that mostly means people doing interesting things with HTML5 and the Chrome Web Store. Here are some early reports from developers of great apps which were present – and in many cases, featured – on the web store. It’s early days, but the reports here suggest there are benefits in terms of discoverability and usage.

1. Todo.ly

Todo.ly indicates how being featured can impact on the stats of a young product:

Thanks to the store, our user base has increased by 780%, achieving the goals we planned for the next 1/1.5 years within the first 3 weeks. Traffic of Todo.ly has increased even more – by almost 1000.

2. SlideRocket

SlideRocket lists their experiences, including installation stats:

#1 Results – The SlideRocket app on the Chrome Web Store received over 50,000 installs in the first 10 days of availability and the volume hasn’t yet dropped off. As much as 60% of SlideRocket’s daily lead flow now comes from the Chrome Web Store.

#10 The revenue share is only 5% – With all of the benefits in points 1-9 we feel like sharing 5% of our revenue with Google is a small price to pay. Compared to the other marketplaces and apps stores which usually charge between 20% and 25%, this is kind of a bargain.

3. LucidChart

LucidChart emphasises that it’s not all about being featured:

First, thanks to the almost 30,000 users who have installed LucidChart to date, we are one of the top paid apps and also one of the highest rated apps in the Web Store.

Google rotates the applications that are featured in the Web Store, so LucidChart has been both featured and not featured in the store. While featured status definitely brings a significant bump in overall exposure and traffic, we have found that the store still brings an important volume of users even when unfeatured. So the Web Store can be an important driver of traffic and user growth for any web app.

They also comment on the nature of users on the store. I think this is an overlooked-point – we often hear X store has X number of users, but the nature of the users and the way they reached the store should also be a factor.

Second and perhaps just as significantly, we’ve found that the Chrome Web Store brings really well qualified traffic to LucidChart. Our user signup rate for visitors via the Chrome Web Store is about 75% higher than traffic from other sources. So the store not only brings significant numbers of new visitors to our site, but it has an even larger impact on the number of new users we’re registering. In fact, it turns out that a visitor to our listing on the Chrome Web Store is almost as good as a visitor directly to our own site.

4. Streamie

This is of personal interest to me, as I know the developer Malte (who now works for Google), and I had a hand in kicking off its Web Store presence. I wanted to scratch my own itch, so I took 15 minutes out to make a Streamie app, which is a lightweight wrapper of the app at streamie.com. Malte has subsequently incorporated the web store presence into the core Streamie code base, which is nice as an open source example of listing on the store, and he’s submitted it to the store. I was pleasantly surprised (given it’s a “beta” app developed in Malte’s spare time) to see Streamie subsequently featured on the front page of the store. He recently wrote about the front-page experience:

I’m personally somewhat surprised with the overall traffic that Streamie is receiving. It is nice that people like it. The Chrome webstore definitely helped pushing the traffic to a new level, though, which, of course, triggered a lot of blog posts and tweets and then more traffic 🙂

Discussion: Great Apps Get Featured

These days, there are many significant platforms for an HTML5-powered app, beyond just running in web browsers, and I think developers who can leverage them will do well. Chrome Web Store is one of those platforms; others include the Android Market, Apple’s iTunes, and so on. But wait, aren’t those “just mobile” platforms? No – aside from the fact that “mobile” means all manner of tablet, phone, and PDA form factors – Android apps also run on TVs, for example, and HTML5 can be the user-interface driver behind that 10-foot experience. And pure speculation, but I’m fully expecting HTML5 (or “open web standards” if you prefer) to power apps running on watches, cars, kitchen appliances, assorted furniture.

It’s going to be perfectly possible to sell a single app on all of those platforms, where the majority – or even all – of the code is reused across the platforms. Beyond app platforms, you can also be featured in other ways, e.g. by using certain (non-app) platforms or APIs. To take a random – and very cool – API, meet Withings, a smart French outfit with wifi scales that upload your stats to a server. Here’s a page where they list apps using their API. Do you think it’s in Withings’ interests to promote these apps?

Now, I do indeed work for a company with app platforms, so take this advice how you will. My main aim here is to highlight the benefits of working with platforms and to be aware that each of these platforms have developer relations people you may be able to work with, under certain conditions. Why would companies who run app platforms provide free to support developers, especially developers who are already committed to building apps for that platform? The reason is it helps ensure developers are building the best possible apps – the platform people see a lot of apps and know what works and what doesn’t. This leads to (a) great apps for users; (b) “role model” apps for other developers. I recommend you bear these goals in mind when you aim to be featured in the store, because they are important considerations when it comes to being featured. A further reason for developer relations is to listen to developers, and feed bugs and requests back to the platform’s engineers.

In terms of the Chrome Web Store, apps that have done well are typically those which are following good UX principles and making the most of the platform at hand. In the case of an HTML5 app on the Chrome Web Store, making the most of the platform could mean apps using application cache, local storage, HTML5 notifications, CSS3 styling, etc. And for packaged apps, suitably leverage extension behaviours, since those are available to packaged apps. Finally, landing page matters, and fortunately for many developers, there is plenty of low-hanging fruit on their landing pages.

HTML5: The Platform Apps Have Been Waiting For

I just finished my FOWA talk, explaining the technologies of HTML5 that are making it possible to develop rich web apps. There are three things I should mention:

  • London in a tube strike is not pretty, until you realise you’re in 28 Days Later, and suddenly it’s ace.
  • I am posting my slides below. They are based on a slide framework that I trend to stitch and mend with each presentation. So they are still very alpha! But getting to be awesome for authoring. Also, I tend to use the biggest-size images available, so download may be slow.
  • Thanks to Carsonified for doing an amazing job making sure everything was taken care of, and the crowd for their energy, and for actually making it in to the venue on this challenging day of travel.

HTML5: The Platform Apps Have Been Waiting For (full-page version)

–>

In terms of questions, we had time for three – one was about which payment solutions are possible on the Web Store (any – it’s open – but the web store provides solutions which should help developers); one was about making native apps (Web Store doesn’t support native apps as such; but tools like PhoneGap let people create native apps targeting iPhone/Android/etc); and one was about whether Application Cache (and, I assume, other features under discussion in the presentation) are HTML5-specific versus Google-specific etc. I mentioned that I want to avoid the HTML5 debate in this talk and I’ll define it here as the spec and everything else going on around it. It’s a good point though to be clear that Application Cache and the other general technologies I discussed are based on open standards.

Twitter Feedback (via List Of Tweets:

  • Amazing Google Chrome experiment site using #html5 goodness http://bit.ly/cRV3WQ #fowa Mon Oct 04 09:07:34 +0000 2010 from Jas
  • Chrome Experiments http://bit.ly/HDM7w <-- #html5 Not your mother's Javascript! #fowa Mon Oct 04 09:10:22 +0000 2010 from Jas
  • Chrome App Store looks kinda cool. #fowa #google Mon Oct 04 09:18:13 +0000 2010 from jacksonj04
  • payments for web apps – according to #google #fowa chrome app store is the solution http://bit.ly/a7rBot Mon Oct 04 09:21:54 +0000 2010 from timanderson
  • Whoa! Proper geek exodus to Michael Mahemoff’s HTML5 talk at #Fowa Mon Oct 04 08:46:54 +0000 2010 from Jas
  • Huge welcome from a packed room at #FOWA for @mahemoff Mon Oct 04 08:48:47 +0000 2010 from sammachin
  • apps are not applications say Michael Mahemoff #google #fowa Mon Oct 04 08:49:05 +0000 2010 from timanderson
  • HTML 5 talk by @mahemoff from Google #fowa #yam Mon Oct 04 08:50:25 +0000 2010 from WebAndTech
  • Good talk so far at #fowa by @mahemoff about concepts of building apps with HTML5. #ux #security Mon Oct 04 08:54:19 +0000 2010 from codepo8
  • RT @codepo8: Good talk so far at #fowa by @mahemoff about concepts of building apps with HTML5. #ux #security Mon Oct 04 08:55:03 +0000 2010 from mheap
  • #fowa @mahemoff pumping on stage – good talk http://twitpic.com/2uk56j Mon Oct 04 08:55:32 +0000 2010 from codepo8
  • RT @codepo8: #fowa @mahemoff pumping on stage – good talk http://twitpic.com/2uk56j Mon Oct 04 08:56:44 +0000 2010 from Paul_Kinlan
  • Christian Heilmann: Good talk so far at #fowa by @mahemoff about concepts of building apps with HTML5. #ux #security: http://bit.ly/aRzGgm Mon Oct 04 08:56:59 +0000 2010 from __UBI__
  • #Fowa #Mahemoff “the proof is in the pudding” what does that mean? Mon Oct 04 08:57:11 +0000 2010 from llaisdy
  • Suffering catastrophic sense of humour failure as it looks like I’ll miss @mahemoff’s session at #fowa. £#^$ you, London transport. Mon Oct 04 08:58:38 +0000 2010 from philhawksworth
  • HTML5: The Platform Apps Have Been Waiting For – Michael Mahemoff – Google. http://twitpic.com/2uk62j Mon Oct 04 09:00:43 +0000 2010 from lewisking
  • Michael Mahemoff (Google) HTML5 web apps: #NewTwitter, Gmail on iPad, and lots of new games and now even video. Even fonts. #FOWA Mon Oct 04 09:00:57 +0000 2010 from Hagoleshet
  • Michael Mahemoff giving his talk on html5 using http://www.html5rocks.com/ at #FOWA Mon Oct 04 09:04:38 +0000 2010 from kaosbeat
  • The Wilderness Downtown explained… Getting great ideas from @mahemoff http://ow.ly/2NV7N #FOWA #yam Mon Oct 04 09:06:49 +0000 2010 from WebAndTech
  • @mahemoff recommends studying local storage API for prototyping so you don’t need to work with servers when doing quick hacks #fowa #easy Mon Oct 04 09:13:45 +0000 2010 from kaosbeat
  • Props to @mahemoff for being the first to skirt around the definition of #html5 at #fowa. Let’s #focus Mon Oct 04 09:18:14 +0000 2010 from codepo8
  • 4 things web apps need according to #google #fowa: local storage, application cache ,locally installable, payments Mon Oct 04 09:13:40 +0000 2010 from timanderson