Development and UX from Michael Mahemoff. Maker of Player FM. Previously: Google, BT, O'Reilly author.

Menu

Tag Archives: Apps

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:

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.

Share this:

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.

2. SlideRocket

#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

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.

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.

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.

Share this:

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff