Interview on HTML5 Game Development

Here’s an interview on HTML5 gaming and the Chrome Web Store which took place at Casual Connect, Kiev, last October. Excerpt:

HTML5 speaks to what games are very well – and the opportunities Canvass presents means good things for gamers. That combined with the new avenues to purchase new apps and content through PCs and mobile, when you combine that delivery with the development environment for the industry there is a real opportunity.

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.

“Classy HTML”: A Speculative Design Pattern about Classes and Composition

This is a pattern about Classy HTML.

Classy

ooo posh

No, not THAT “Classy”. This “Classy”:

HTML

No, not THAT “HTML”. This HTML:

The Classy HTML Pattern

Pretty simple: Store important app state as classes in your root (“html”) element.

For example, consider a countdown app. Its significant (from a UI perspective) state can be summed up as being one of three things: “fresh” (app just started), “counting”, “done”. Your app is, in effect, a state machine transitioning between those states according to a set of rules. (Acknowledging that reality and subsequently managing those state transitions with JavaScript can also be an interesting problem ripe for a parsimonious design, but let’s just take that for granted here.)

You would set your HTML class as “fresh” to begin with, and then programmatically switch it over to “counting” or “done” as the app plays out.

Your CSS reflects it:

  1. /* We choose the default case to reflect the most common case, ie "counting" or "done" */
  2. html.fresh .welcomeMessage { display: none; }
  3.  
  4. html.fresh { background: white; }
  5. html.fresh .counter { opacity: 0.3; }
  6.  
  7. html.done { background: red; }

The important thing here is the selector idiom, which can be summed up as “html.state descendentSelector“. We’re styling our classes all the way down, based on the overall application state.

I haven’t done too much of this kind of design, but I can see myself doing more of it as apps get more complex and everything becomes single-state. I’ve been contemplating refactoring the Hacker News Reader along these lines, since (thanks mostly to Paul), it now has sliding panels, and so can effectively be in three states: stories, story (one story above the list of stories), comments (comments above one story above the list of stories).

I guess all this is obvious to CSS design pros, i.e. it’s a natural consequence of the CSS model, but I’ve not thought about doing it much and I mainly got the idea from this FOUC trick, which uses this pattern, but in a very restricted and specific way. The main insight really is that single-page apps usually have a small number of key states which can affect the entire UI.

As with any good pattern, it raises further questions:

  • Should you use “class” or an HTML5 custom “data-something” attributes. I think it’s in the spirit of HTML/CSS to use “class” to represent a state, so that’s fine. And CSS attribute-based support won’t work on older browsers, so that’s another tick for “class”. BUT custom attributes have the distinct advantage that you can be more precise about what kind of state you’re referring to. So while it could just be “data-state”, it could also be “data-phase” or (a boolean) “data-active”. Which takes us to the next question …
  • Should you use more than one type of state? I think for complex apps, yes. And you can then use custom data attributes to manage the type of class. Or you could just use them as a list of free-floating class names on the HTML tag.
  • Should you use multiple selectors, e.g. [data-phase="counting"][data-authenticated="false"] to be more precise? In general, I think no. It would lead to ridiculous combinatorial complexity, so it’s better to treat each state variable – if you must have more than one of them – as being orthogonal. That said, there are probably special cases where it makes sense and fortunately modern CSS makes it easy to pull off.
  • What’s the base case? Should it be the initial state or the “typical” state?
  • Looking at the bigger picture, when do you switch pages versus switch states inside the app?