The Boot2Gecko Developer Experience: An Interview with Mozilla’s Jonathan Nightingale

A surprise bonus of last week’s MWC trip was the coincidental launch of Boot2Gecko, Mozilla’s operating system based on Firefox (Gecko being Firefox’s underlying layout engine and B2G being the unofficial brand name for now). They made a joint announcement with Spain’s Telefonica (O2 and GiffGaff’s parent company) with the expectation to release a commercial offering this year (no commitments yet though).

Continuing my “a conference is worth more than 140 characters” resolution, I had a chance to sit down with Mozilla’s Senior Director of Firefox Engineering, Jonathan Nightingale and understand some of the technical issues around the new OS.


Key points from the video, as well as speaking to some of the other Mozillians:

  • The device could be very cheap, $60 for a SIM-free device is a figure I heard. Needless to say, if they can achieve a price point like that, it will be music to carriers’ ears and simultaneously light up the HTML5 developer community. At 10:00, Jonathan mentions that Telefonica sees the opportunity to produce a smartphone that’s “interactive, smooth, high quality, with a good app selection, that is one-tenth the cost of an iPhone”. From what I’ve heard, this is because of two factors: the target hardware is open and patent-free, and the HTML5 runtime is built over a thin Linux core, so various layers are eliminated.
  • It boots fast, about 14 seconds (I thickly say 4 seconds in the video but I was counting from the splash screen…my argument is invalid). Bearing in mind this is a very early concept, the final version will hopefully be even faster, though it’s possible extra services may make it slower too.
  • Everything is HTML5. The launcher, dialler, camera, gallery, et al. And what’s more …
  • … On the dev build, as Jonathan demos, View Source is available everywhere! On all the apps, and that includes those “system” apps above (launcher, dialler, etc).
  • The Mozilla Marketplace is not exclusive to B2G. It will run on other devices where Firefox runs, like Android. (It turns out that Android apps can be permissioned to add multiple URL shortcuts to the Android launcher, so once a user installs the market, they can install apps directly on the launcher.) This is a little like the Chrome Web Store, which is the app distribution mechanism for ChromeOS, but also works on regular Chrome across the different OSs it runs on.
  • Mozilla’s keen to cultivate an ecosystem of multiple marketplaces with different verticals and business models. They offer their own marketplace, but will happily embrace others.
  • No immediate plans for extensions or a NodeJS service layer like WebOS runs, but Moz is very open to feedback via the standard channels.

PPK argued in last week’s Web Ahead we may well see a shift away from Android in the next year as carriers come to terms with Google’s Motorola acquisition. It’s not for certain, but I did hear people echo this view at MWC. Boot2Gecko will be a key part of the current movement among the smaller OSs to embrace HTML5 developers. And if the price point means developers can easily get their hands on these devices, as opposed to the usual suspects who are awarded freebies by marketing departments, it stands a real chance in this market.

HTML5 developers should also check out Christian’s Boot2Gecko write-up for more info, as well as the official Boot2Gecko Wiki.

The Non-Visual Web

Looking Forward

7 years on from Ajax, we have our JavaScript-fu down and the APIs we could ever have dreamt of are baked into the desktop browsers of note. So what’s next for the web? The latest 5×5 podcast with Jason Grigsby is illuminating on future trends (as well as being a must-listen for all its practical advice):

Episode Homepage

Here I want to outline a few specific features which will challenge the boundaries of the web as we know it. And then I’ll explain how the web community can meet those challenges.

Tip of the Iceberg

In 2009, I gave a talk at London Web Standards on eight features of HTML5 you won’t see, features such as offline storage, geolocation, and history API.

That’s the tip of the iceberg of the tip of the iceberg. An example in this podcast is walking down the street and having your phone’s navigation system vibrate once if you should turn left, twice if you turn right. Another example mentioned in the podcast is a JavaScript vehicle API! webinos.vehicle.addEventListener (webinos.vehicle.NavigationEvent.DESTINATION_REACHED, handleDestinations, false); Checking fuel level, engine condition, etc. via a high-level API. And of course, there’s the whole medium of sound…this post was kicked off by a podcast after all!

The web has traditionally been a visual medium. As Jen Simmons observes here, even when it’s not visual, we use the word “Screen Reader” to emphasise its visual foundations. While it’s moved from text to images to fancy graphics and multimedia, those things are still visual elements on the page. Yet all of the above are not about elements on the page. That’s where technology is headed. So is it even sensible to handle these things through the web?

Model-View Separation

On a technical level, what makes the web incredibly powerful is the DOM concept. DOM is sync’d to UI. Update the DOM and it changes the user-interface. Change the UI and the DOM updates. The programmer doesn’t have to facilitate this bidirectional sync; it just happens.

Really, on a technical level, this is an incredibly important and overlooked aspect of HTML5. Too many HTML5 APIs are pure JavaScript functions and ignore the DOM altogether. For the web to thrive, vehicle APIs should not just be webinos.vehicle.addEventListener. The vehicle itself should be part of the DOM. If that sounds too domain-specific, that’s okay, because look at the work of Web Components. These guys are bringing about a world where anyone, or any community, can create a first-class <x-vehicle> element with its own look-and-feel.

Open Standards

Of course, at a higher level, the web is about open standards. That’s really what sets it apart from iOS, Android, and .Net. There’s no single vendor in charge. Something like the Java Virtual Machine comes close, but the web stack stands out as a more balanced control system. If there are to be standards for things like vehicle APIs, the web is attractive as the best stab at a neutral ground with real developer buy-in.

For this reason, the web can successfully move beyond the visual medium without losing what makes it the web in the first place.

Login Best Practices for Mobile Web Apps

Walking home, I thought I’d venture to make a meal order via my phone…and without making a phone call. It shouldn’t be an ordeal to do so in 2011, but frankly a sense of learned helplessness means I haven’t even tried before. I know, #FirstWorldProblems, but let’s learn something from it.

Anyway, I pull up my favourite meal delivery service, Hungry House (highly recommended! At least in London.) I simultaneously launch a Market search for a Hungry House app – right or wrong, we know mobile app experience is almost always smoother. Well, no app, but the web page loads…and a bunch of antipatterns emerge.

Instead of documenting login antipatterns, I’ll make this post more useful by turning them around and proposing best practices for mobile web login. Beware it’s all speculative and subjective.

Zen Login Form

Make a simple, mobile-optimised, login form. Make sure it’s easy to click on each field to focus them (there’s only two of them!). Make sure any links (“forgot password”, “sign up”) are far enough away they won’t accidentally be licked.

This is true of all mobile web forms, not just login one. But if your app only works behind a login form, this would be the first one to optimise.

“Keep Me Logged In” should default to On

It’s a mobile phone, not an internet cafe, so yeah. Admittedly, this is trickier in the case of a tablet, but still it’s only a default, I’m not saying “hide the option altogether”. Also, form factor detection ftw.

Don’t Expire the Login Cookie

Okay, this will be controversial. But if mobile web apps are to be a viable alternative to mobile-native apps, they should provide the same login experience. Right now, a majorly overlooked distinction is login expiry. I find myself having to login to Twitter all the time, when trying to tweet from some other web app. But with the Twitter mobile app, I’m always logged in. Basically, mobile-native apps never expire the session. Most of them probably don’t even bother with a session/token, they probably just store the user’s credentials in plain text on the device (just some speculation on my part, based on the “see no evil” principle, given that this data is fairly invisible, being stuck in the app’s data storage.) At least a cookie, if found by someone else, doesn’t compromise the entire account, and can easily be expired.

Keep it Light

Needless to say, don’t load so much that the browser crashes. Repeated browser launches makes users hungry.

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.

Actually, the mobile web really does suck

I access the web via mobile on a daily basis, but that doesn’t mean the mobile web is fine and dandy. Publishing 2.0 says the mobile web sucks, Russell Beattie disputes it. His arguments don’t make sense – the mobile web is getting better, but still sucks.

1) 3G is slow? Get a better 3G phone and then learn how to use it. My preferred mobile (an LG CU500) gets DSL speeds down, and my preferred browser (Opera mini) is as easy to use as a desktop browser, and just as fast.

Yes, 3G is slow. I researched my phone extensively and came up with a popular choice, the Orange SPV M700, aka HTC Trinity, aka, HTC P3600. Pretty good for text-only sites, though you notice the latency, but image-heavy sites load very slowly. When this happens on a mobile, it sucks as you have to scroll around for ages to find the text between the unloaded images.

Browser, don’t talk to me about browser! I registered Opera for my phone – it’s better than IE because it supports tabbing. However, it’s vastly disappointing – its auto-completion is based on the last 10 or so addresses you visited, there’s no easy way to go to your homepage, and the real deal-breaker is the poor support of bookmarks. About 3 deep in the menu hierarchy to add bookmarks and 3 deep to change them.

2) Public Wifi is a Scam? No s***, Sherlock. You can’t depend on WiFi outside your house or office. Again, get yourself a decent phone on a 3G network and you won’t have this problem. I double-check prices inside Best Buy in seconds, chat on IM while having a coffee and entertain my kid with downloaded videos all via 3G networks, and I don’t think twice about whether there’s WiFi around.

In his own affable way, Russell agrees with the original poster, so nothing to say here. It was interesting to see the recent UK IPhone announcement based on free access to TheCloud wifi network as a poor compromise for the lack of 3G. If I was ever going to trade up for an iphone, that stopped me in my tracks – no way would I put my entire connectivity down to whether or not I happen to be near a hotspot.

3) Sites aren’t formatted for small screens… Um, well, then those sites aren’t part of the Mobile Web, are they? Even if you’re talking about *accessing regular web sites while mobile* it’s still a dumb-ass thing to bitch about as it just highlights one’s inability to use a decent mobile browser and or the lack of effort to bookmark a site’s mobile version. A couple years ago there might have been a dearth of mobile sites, but just about every major site out there now – from Typepad to Yahoo to Wikipedia, have m.* versions.

Um, well, then that means the mobile web sucks doesn’t it? Most sites don’t make it obvious they have a mobile version (m.) even when it does exist – am I going to try out m. just in case. Fine for a site you visit regularly but not worth the effort for the many sites you just drop in and out of. Yes, it’s possible to change the view by diving into the browser menu again – however, even with my speedy 400MHz phone, it usually takes 5-15 seconds to re-render, and you usually have to scroll back down again. You might even have to do this a couple of times before you get the view right, you might never get it right.

4) Mobile device screens are too small? Oh, well, that’s it then! By this definition, the mobile web will never un-suck, because if you’re looking at the web on a device that doesn’t fit in your pocket, IT’S NOT MOBILE NOW IS IT?!? I guess we can all go home now. Someone call me when they’ve figured out how to put an 20 inch XVGA screen in the palm of my hand. What a f*** dumb-ass criticism.

This is true for now, but not forever – foldable devices like old-school Game-N-Watches and the Nintendo DS hint at what’s possible in the future. Electronic Ink can be made in a form that folds up and it’s also possible to project onto a wall. For now, though, the manufacturers could do more to compensate for the small screen – e.g. better browsers and better use of text-to-speech and speech-to-text (two technologies which have been around for decades and a perfect fit for mobile devices, but are virtually non-existent in modern phones).

5) Advertising gets in the way? Again, what the f***? First, no ads means you’d be bitching about how everything on the mobile web costs money. Secondly, there’s hardly any ads on the mobile web to begin with. Thirdly, are there any regular websites out there that don’t have ads? Complaining about a website having ads is like complaining it’s not 1996 anymore. Grow up.

Ads aren’t a major problem to me, certainly not significant compared to the problems you have with images. The only issue I have with Russell’s comment here is his insistence to keep referring to “the mobile web”, which sounds like some kind of Compuserve-like parallel universe. I assume he means the tiny subset of websites that have a mobile version, but I don’t consider that a separate “web”. If for no other reason, they don’t even link to each other – if a yahoo page gets to the top of digg, then diggriver.com (mobile digg) is not going to link to m.yahoo.com. In some cases, the browser will end up rendering the mobile version (if you’re lucky), but this is a dual-edged sword – there are many mobile devices around, which means the main site is better than the mobile one, which simply doesn’t work.

(I covered up swear-words in Russell’s quotes – doesn’t do much for me either way, but some filtering software will block the post if I left it in.)

For these reasons, I mainly tend to stick to one website, the same website I’ve browsed on my phone for three years and one which has always had a decent mobile version. Bloglines.