September 23, 2012

I haven’t used iOS 6 in anger yet. I don’t know whether the maps are really that horrible. I just feel like a lot of entries on The Amazing iOS 6 Maps tumblr are a bit pathological, as if people have been looking for screwed up data. Yes, some of those satellite pictures look funny and walking directions that involve swimming are lol, but it’s not like Google Maps doesn’t have or had similar problems. And how much is this going to affect the usability of the app really?

As an engineer who’s involved in getting a crazily ambitious project off the ground, within an organization that has absolutely no prior credentials in the respective field, I don’t find all this very encouraging. And it’s not just because it’s Apple… Remember when Microsoft launched Bing? I already can’t wait for how much shit Mozilla is going to get when Firefox OS launches, just because this or that is not as good as on the iPhone. Can’t wait.

I actually think it’s kind of nice to see Apple trying to create a competitive maps solution. Seeing Apple be the newcomer that’s struggling against the big guy. In a strange way, this is an Apple I can relate to. Much like the Apple from the 90s. I want to pat them on the back and encourage them.

May it also teach them some humility. They’re doing this to prevent Google service lock-in for them and their users. Maybe they’ll figure out that reciprocity is a good thing. Creating choice means that your users stay with you for the right reasons, and not because you’re holding them hostage. When you don’t take your users for granted, you try to make better products. Especially since in this business, it’s not uncommon to be relying on your competitors.

Really, all of this, not even Clock Gate, seems all that dramatic to me. I just hope it will make Apple realize that their shit don’t stink less than others. Maybe then their users will be more forgiving when they make bold moves. C’mon Apple, be the underdog again. It suits you better, anyway.

There are many success stories like this in open source, but this is such a neat one, I have to call it out. It basically goes like this:

Webdev makes awesome app (I have seen it. It’s is truly awesome. For any app, really, but *especially* for a web app). But awesome app is not as awesome as it could be in places. Webdev investigates. Finds a bottleneck in Firefox. Files bug. Goes through the seven circles of hell (XPCOM). Submits a patch. Goes through several review iterations. Patch gets committed.

Bobby Holley tells the whole story in his blog post. It’s short and worth a read.

This contribution is a testament to open source and Mozilla’s open development style. I wish we had more contributions like this (duh), but you’re probably not surprised to hear that this is pretty rare. Sure, it has to do with the level of complexity of some of the code. But, there are tons of relatively easy-to-approach parts in Firefox.

So I ask, have you ever come across a bug in Firefox that you really wanted to fix but didn’t/couldn’t? If so, what stopped you and what could perhaps have helped you?

My take on webOS and Mozilla

December 11, 2011

HP announced yesterday that they’re going to open source webOS. No matter what one may think of webOS (or HP), this is great news. It’s an opportunity, but it remains to be seen what HP and others will do with it.

Several people I’ve spoken to or chatted with are wondering whether (or even suggesting that) Mozilla should embrace webOS. On the surface, it makes a lot of sense. “webOS” is about the “web”, right?

Unfortunately, I don’t think it’s as simple as that. webOS is a technologically interesting stack, but it’s just a stack. Sure, it happens to be one that is very portable and might have a low entry barrier for developers. But WebKit and V8 do not a web make. And an app written in JS does not a web app make.

Enter Mozilla’s Boot to Gecko (B2G) project. On the surface, this too sounds like just another stack: you’re booting into Gecko instead of WebKit — so what’s the difference?

Well, B2G’s goal is about moving the entire web forward to a place where it can run a mobile phone — not run on a mobile phone but run the phone. Sure, we’re using Gecko to do this, but this is just a means to an end. Just like most of our other efforts that drive the web forward also use Gecko and Firefox as a carrier pigeon. Mozilla’s mission, after all, is to move the internet and the web forward, not make a browser or a rendering engine.

So what does driving the web rather than just particular stack forward mean? It means introducing and standardizing APIs to control just about every bit of hardware on modern phones, from the various radios to the cameras and storage devices. The idea is to level the playing field: there’s not just one stack and there’s not just one vendor in control. Just like on the web.

As a result, carriers, OEMs, and most importantly users, will be able replace and/or improve bits of the stack as they see fit and there’s also absolutely no red tape that keeps them from doing so (except for broadcasting/networking regulations, of course). This is quite different from, say, Android. It also nicely illustrates the difference between “open source” and “open”. Android is just one of those two, and it remains to be seen what webOS will be like.

I think herein lies webOS’s opportunity. The mobile landscape already has enough red tape stacks and it’s starting to disenfranchise people, and I’m sure companies too, at a large scale. If one could get anybody engaged in something new, it would be them. But not with another proprietary stack. With one that’s open.

If HP wants to give webOS the web credentials it doesn’t deserve right now, they should join Mozilla at the standards table and make webOS a “Boot to WebKit”. Competition and choice is what made the web great. Let’s do it again. And again.

About half a year ago Mozilla bought me a Nexus S. It is a close cousin to the Samsung Galaxy S marketed by Google. The difference is a slightly different shell, the lack of a card reader, and a plain vanilla Android 2.3 “Gingerbread”, as opposed to Samsung’s own hacked up version of Android 2.2 “Froyo” (I think). But I don’t really want to review this phone so much as the experience, which is a lot due to the operating system, Android. I haven’t used Android versions that were customized by manufacturers much, but they all disappointed in one way or another.

That’s not to say Gingerbread doesn’t have problems. Visual feedback and haptics aren’t as refined as on iOS, particularly when scrolling. It can be quite slow and drain the battery. The built-in browser is even more useless as Mobile Safari. The App Store application is a UX clusterfuck. I could go on…

So it’s not perfect. But I have to say, I prefer it to iOS, mostly for one reason: the back button. It makes going from, say, email app to the browser to the Twitter app and back a piece of cake. It’s incredibly predictable and is exactly what I want: follow a link in an email or a tweet and get back to where I was when I’m done.

It still surprises me that iOS doesn’t really have a solution for this at all. Apple poorly retrofit multitasking into the UI and the solution they came up with is throw back to 1990s: the double click. Instead of having multiple apps work together like on Android, iOS apps are silos. The Twitter client, News Reader, etc. all contain a little web browser. I want a real browser, not a lobotomized web view!

Android apps, on the other hand, have many hooks that allow them to work together, not just the back button. My favourite one is the Share feature. Apps can register themselves as share providers and other apps can share things through them. It’s so brilliant, I wish the web would work this way. (And indeed here at Mozilla we are working on making it so.)

You also get a real choice of web browsers. This doesn’t sound very important, until you actually try to open more than one web page at a time with built-in browser. Help is at hand with a variety of web browsers that have UIs geared towards power users, such as Dolphin HD and others. But unlike on iOS, these are not restricted to using the built-in WebKit, which is getting on a bit in Android.

Indeed, they’re not restricted to using WebKit at all, which means you can use other, possibly more modern browser engines like Mozilla or Opera. I’m biased for sure, but it’s probably safe to say that the most modern Andorid browser these days is Firefox Mobile. Its startup time could be a bit shorter and it can be a bit of a memory hog (help is on its way.) The browsing performance itself is pretty fast, though.

But the real game changer is Sync. You’re probably laughing even harder now since I work on Sync, so I’m outrageously biased. But up until I got the Nexus S, I had only ever used it between desktop computers. Hand on heart, it changed my mobile web experience by multiple orders of magnitude. Having access to all my browsing history, passwords, and bookmarks from my other computers means I can use the web on my mobile device exactly like on my desktop. I just can’t tell you how of a difference this makes.

Anyway, back to Android itself. The choice of web browsers is just an example of the way the device feels to me as a power user. The smell of choice is unmistakable. I can install my favourite web browser. I can tether whenever I want to how many devices I want. I realize not many people may care about this. I do and others might too.

Lastly, another positive surprise was the keyboard. I thought the iOS one was already pretty good, but Android’s keyboard (at least the stock one in Gingerbread on the Nexus S) is even better. As you type, it already comes up with suggestions. Most of the time you don’t even have to finish typing a word, it will already be in the list of suggestions and you can save yourself a lot of tapping. On iOS, on the other hand, you have to tap on the suggestion to dismiss it. It still confuses the heck out of me, even though I know how it works.

The upshot: I really like Android, so much in fact that I want an Android tablet. I’m just not sure they’re there yet. Maybe I should try out the new Galax Tab II. But that might mean I’d have to put up with a badly hacked up version of Android at which point an iPad might be the better choice.

As we’re getting closer to shipping Firefox 4, less of us have any blockers to work on while the pressure increases on the few people that do. Here are some thoughts and experiences on how to level that.

This past month we picked up a few blockers in Sync that had people’s bookmarks duplicated and reordered. An embarrassing and unfortunate scenario, especially since it was hard to reproduce and our unit tests were all passing, of course. We had gotten reports of duplicated bookmarks in the past. So while we had recently made some changes to bookmark sync that may have made situation worse, it certainly looked an old lurking bug.

After two days of staring at the code, writing tests that passed and getting nowhere, I asked my colleague Richard Newman to help me out. In previous projects I’ve had extremely good experiences with pair programming. In this technique, two developers sit down over one machine and one text editor. The “navigator” dictates the general direction while the “driver” writes the actual code. Developing code this way has a lot of advantages:

  • Two sets of eyes see more than one. Simple mistakes that can slow an individual developer down, such as typos, off-by-one errors, etc. happen less.
  • Code is reviewed before it’s checked in. Granted, we already do that at Mozilla.
  • Code is reviewed instantly. Less developer and reviewer time is wasted with an asynchronous review cycle and less time has to be spent explaining why a particular change was made this or that way.

However, Richard works remotely, nearly a thousand miles away, although fortunately he’s in the same timezone. As it turns out, pair programming over a distance works great when you have the right tools. Here’s what we did:

  • We both had hands-free phones available, so we got on the phone and started walking through the code together.
  • As we bounced ideas off each other, we collected our findings in an Etherpad. This allowed us to write down our ideas in a structured manner, while allowing the other one to reorder and restructure them as we filed bugs.
  • On some of those bugs, we paired up in the traditional pair-programming sense. To compensate the lack of a common screen to stare at, we used a shared GNU screen session where I brought up an instance of emacs so that we could take turns in “driving.”

We ended up doing this this for three whole afternoons. We found potential culprits, filed bugs and fixed a bunch. The experience very much reminded me of on-site pair programming. I suggest you try it some time, be it with a colleague who’s remote or not. You’ll feel extremely productive even if you’re not writing a single line of code yourself. Not only that, you’ll end the session with a much better understanding of what the code does (instant r+!).

Let’s kill those blockers dead.

In the excellent Coders at Work book, Doug Crockford advises programmers to rewrite their stuff every six months or so. He says rewrite, but I don’t think he actually means that. Developers love rewriting stuff and most of the time it’s absolutely pointless — I know, I’ve been there.

I think what he means is refactoring. Basically streamlining the good parts and getting rid of cruft. In an ideal world, refactoring can be done in small, atomic steps. It should create no or few incompatibilities. And most crucially, it shouldn’t in any way affect the product’s shipping date.

This past week I have given BarTab this treatment. Since its creation in late January, it has grown organically. After a few months of fixing bugs, adding features, releasing early and often, and observing it “in the wild,” it was time to step back and clean it up. And boy did it need cleaning up.

My precondition for this refactoring was that I wouldn’t add any new features. Nada. Zip. Even though it would’ve been very tempting at various stages. I did manage to fix a few lingering bugs, though. In the end I turned over almost every line of code, some even twice. It was a deeply satisfying experience, and I’m glad I stuck by my no-new-features rule. It wasn’t an ideal refactoring in the sense that it was completely backwards compatible. The old API was horrible, it is now much more symmetric and free of horrible puns.

So BarTab 2.0 (available now as beta) is leaner, meaner, less invasive (no eval() hacks!) and more compatible with other Firefox add-ons. In a lot of ways it’s the BarTab that I should always have written. But you know as well as I do, that’s not how it works. Very few people write perfect code the first time round.

To me, BarTab is the perfect example of why Release Early and Often and the occasional Refactoring works extremely well for small, self-contained pieces of code such as a library, plug-in or extension. It isn’t by far the first time I’ve done things this way, but it’s certainly turned out very nicely this time.

Tabs, tabs, tabs

May 1, 2010

Choosing the web browser as the application for most of your daily tasks means that it better well be usable. In my case that primarily means dealing with lots of tabs. So it happens that much of the time I’m spending hacking Firefox is on improving the tab story.

Lazy tab loading FTW

A few months ago I was fed up with the long (re)start times of a tab encumbered Firefox and came up with BarTab, a Firefox add-on that changes tab loading behaviour so that they’re loaded only when they’re accessed. As I wrote in a blog post then, it was initially intended for tab addicts like myself, but thanks to lots of feedback from all kinds of users — tab addicts and novices alike — BarTab has continually improved to serve related use cases as well.

Firefox after a restart. The three tabs on the left haven't been loaded yet, hence their dim appearance.

I’m really overwhelmed by BarTab’s popularity. It’s been reviewed by various online journals such as LifeHacker, scrutinized for its memory and CPU cycle conserving powers, featured on Rock Your Firefox and suggested for integration into Firefox proper. That’s a steep career for an add-on that’s barely three months old!

Making bookmarks obsolete

On the other hand, three months was enough time to take a step back, observe my own interaction with the browser and analyze the user feedback. I think there’s some real usability potential in lazy tab loading.

Novice users typically don’t keep a lot of open tabs. What many of them do is bookmark regularly visited sites. This behaviour is encouraged by the bookmark toolbar being visible by default in Firefox. However, with bookmark-related UI elements in the location bar, a toolbar, the sidebar, and the menubar, I’m sure you’ll agree that the usability of the current implementation could definitely be improved. Or in the words of a Reddit user:

“It’s like someone taped a bunch of cats together.”

I would even go as far as challenging the whole concept of bookmarks. I think they require too much user interaction. Tabs, on the other hand, are easy to open, close and discover. They’re a reasonably simple concept and one that’s part of the browser already anyway. When the brower supports lazy-loading tabs via a BarTab-like mechanism, tabs can essentially serve as bookmark substitutes. You simply remember a site by keeping its tab open. The difference to bookmarks is that you don’t need to do anything to “bookmark” them. In fact, you have to do one thing less: close them. Memory wastage won’t even be an issue with smart unloading. BarTab already supports this, albeit in a crude manner.

Improving tab discoverability

Eradicating bookmarks in favour of tabs will, at least to a certain degree, make everybody a “tab addict.” This has a few scalability implications. There’s of course the challenge of making the tab mechanism itself scale to hundreds, possibly thousands of tabs. That certainly is a tricky one to say the least, but I’ll leave that aside for now. Another real issue is the tab UI.

First there’s the tab arrangement. There are very good reasons for having a vertical arrangement to the side of the browsing window. Most computers have widescreen displays these days, so vertical screen real estate is more valuable than horizontal one. More to the point, a vertical arrangement provides more space for more tabs, so it scales better to a higher number of tabs. When I maximize Firefox on my laptop, I can see about 14 tabs in a horizontal and 40 in a vertical arrangement. That’s a factor of about 3 or half an order of magnitude more.

About 14 tabs are visible in the horizontal tab bar.

With a vertical tab arrangement one can overlook about 40 tabs.

Of course not everybody needs to or wants to see that many tabs. The novice users just have a few sites they visit regularly. In this case, one could still make good use of all that vertical space, for instance by showing thumbnails for each site. This scales well even to tens of tabs and helps users visually recognize their sites.

But even tab addicts might be interested just seeing a selection of all tabs available. The current tool of choice here is Tree Style Tab. It not only displays your tabs vertically, it also allows you to arrange them in arbitrary trees. In addition to that it has about a million other features. Don’t get me wrong, it’s a fabulous and brilliant add-on, but I think it’s a bit too complicated. And the complication comes at a price: Yes, thanks to BarTab restarting Firefox with about 100 tabs is quite fast — until you enable Tree Style Tab and have it restore your tree hierarchy.

This is why I’ve started work on Vertical Tabs (code on GitHub). Its proposed feature set is simple and much constrained: arrange tabs vertically in such a way that looks native on all platforms and allow grouping of tabs. In a second iteration there might be room for some additional group features such as previews and automatic unloading of tabs (via BarTab) when groups are collapsed. But all in all I’d like to keep it simple, fast and open to as many types of users as possible.

Tabs arranged with Tree Style Tab. A bit too much structure, methinks.

Tabs arranged in groups with Vertical Tabs.

Outlook to history

To sum up, a simple experiment with tabs has shown that the browser UI and is concepts can yet be improved. Merging tabs with bookmarks to a unified concept, both in terms of the UI as well as the underlying mechanics, is without doubt a challenge. But conceptually I think it makes a lot of sense.

What’s more, this way tabs become invariably linked to the browsing history. They essentially represent an open window or link to a certain item in that history. A loaded tab is an active link, an unloaded tab is a inactive link that just happens to be represented in the UI as a tab.

This, no doubt, should make us think about how to represent the browsing history as a whole in the UI. Of course the browsing history is riddled with information that you’re normally not interested in, so you need some sort of filter. This is what the tab bar could eventually become: a filered view on your browsing history.

Right now we’re seeing stuff happening in the webbrowser that starts to go beyond the traditional web application. I’m talking about things that make either the browser itself or the interaction between different web applications a richer experience.

On the browser side, the basket of technology commonly referred to as HTML 5 falls into this category. It makes the browser a much more powerful client, thus rebalancing a lot of weight between web server and client to an IMHO much more natural equilibrium.

On the web application side we are seeing are starting to see lots of interesting application mashups, thanks to technology like OAuth and cross-origin AJAX hacks. Facebook’s recent innovation, the social graph and the ability to embed it into other applications, is a powerful example.

As many have noted, there are huge problems with this and they all have to do with security and privacy. Virtually none of the technologies coming forward under the HTML 5 umbrella help with security. Yes there are some attempts to fix one of the most backwards security policies in the browser. But these are mere sticking plasters over oozing flesh wounds.

Weaving a richer web

As I’ve written here before, I think we need a browser designed for the cloud. Back then I was mostly speaking in terms of usability and explicitly ignored the privacy issue. It think it’s time to come back to that now. With HTML 5, we’re giving the browser many ways to be a richer client. But in terms of user data, we’re still treating it as a dumb terminal.

Weave, a Mozilla Labs project, has a different vision. Its broad idea is to create a richer web experience while still having users control their data. Concretely, the Weave Sync service allows you to synchronize your tabs, history, bookmarks, settings and passwords between different browsers. And here’s the thing: the data is all encrypted, on the client. All that Mozilla is storing on their storage nodes (which you don’t have to use, by the way) is a bunch of encrypted JSON.

Sure, you may be saying, that’s great for making Firefox a richer browser, but how does that help the general web?

Well, it turns out that doing RSA and AES cryptography in JavaScript isn’t such a far fetched idea at all. With some inspiration from an abandoned project, I was able to hack together a (very rough) version of Weave Sync for Google Chrome. Since it’s entirely written in JavaScript, it actually works in any browser.

See for yourself. (To try it out, you need to create a Weave account with some tab data in it, e.g. by installing the Weave Sync add-on in your Firefox and syncing your tabs).

Sure, you may be thinking, encryption is great for dealing with personal data, but it would be impossible in a social web. What if you wanted to share your bookmarks with other people?

Well, is it really that impossible? Let’s look at what Weave does. In a nutshell, it encrypts your private data with a symmetric “bulk key.” This bulk key is stored along with data on the server, but in encrypted form: encrypted with your public key. That means to get to your data you’ll need your private key to decrypt the bulk key which in turn can then decrypt your private data.

If I now wanted to share my bookmarks with you, I could simply give you my bulk key by encrypting it with your public key. Job done. You can see my data (and only the data I’ve encrypted with the particular bulk key that I’m sharing with you), but nobody else can. Not even Mozilla.

I know, sharing bookmarks is so 1998. But it’s essentially the same thing as the Like button (or the LUUV button). Or your address book. Or your whole social graph. Point is, we no longer need the server to do the heavy lifting for us because the browser environment is getting richer — be it the HTML templating, session storage or even cryptography. The server can become a dull data storage that we can scale the heck out of and, more crucially, potentially ditch for different one if you like. While all the data is in the client’s hands and leaves it only in encrypted form.

This is the kind of cloud I can definitely get on board with.

A few months ago I wrote a post about JavaScript titled Curly braces are not the problem wherein I pointed out one of JavaScript’s biggest weakness, the new operator and how to spell an object constructor as well as methods on the corresponding prototype. Some commentators mistook that post for critique of the prototype model itself. It was far from it, I think the prototype model is great, just the spelling was awful. Consider this:

function MyObject() {
    /* constructor here */
MyObject.prototype = {
    aMethod: function () {
        /* method here */

which is alright until you now want to inherit from this and add methods:

function YourObject() {
    /* constructor here */
YourObject.prototype = new MyObject();
YourObject.prototype.anotherMethod = function () {
    /* another method here */

There are several problems with this. First of all because YourObject inherits from MyObject, it has to be spelled differently. Secondly, we can’t reuse the constructor, at least not without resorting to func.apply() tricks. Thirdly, we have to know what to pass to the constructor of MyObject at definition time.

It turns out, Doug Crockford not only agrees with me on this but also has come up with a better way. Back in January I thought that we needed more syntax to fix this, but it turns out we need less (by which I mean ditching the new statement). In Vol. III of his excellent Crockford on JavaScript lectures, he defines a constructor maker:

function new_constructor (extend, initializer, methods) {
    var prototype = Object.create(extend && extend.prototype);

    if (methods) {
        methods.keys().forEach(function (key) {
            prototype[key] = methods[key];

    var func = function () {
        var that = Object.create(prototype);
        if (typeof initializer === 'function') {
            initializer.apply(that, arguments);
        return that;

    func.prototype = prototype;
    prototype.constructor = func;
    return func;

I’ll let you work out the details of this yourself and instead just show you how you would define the equivalent of the two cases above:

var new_my_object = new_constructor(Object, function () {
    /* constructor here */
}, {
    aMethod: function () {
        /* method here */

var new_your_object = new_constructor(my_object, function () {
    /* constructor here */
}, {
    anotherMethod: function () {
        /* method here */

See how symmetrical both forms are now? And if both object constructors really were were to share the same initializer, I could easily define that as a separate function and reuse it.

Btw, if you do any sort of web development, I highly recommend you watch the Crockford on JavaScript talks. They’re not only entertaining but are an excellent lesson in history of all the technology that makes up the web.

Programs must be written for people to read, and only incidentally for machines to execute.

Abelson & Sussman, SICP

There’s a programming paradigm which I shall call, for the lack of a better name, bail out early. It’s so trivial that it almost doesn’t deserve a name, not to mention a blog post. Yet I often come across code that would be so much clearer if bail out early was used. Consider some code like this:

function transmogrify(input) {
    if (input.someConditionIsMet()) {
        var result;
        result = processInput(input);
        if (result) {
            return result;
        } else {
            throw UNDEFINED_RESULT;
    } else {
        throw INVALID_INPUT;

There’s a lot of if/else going on here. In the bail out early paradigm, you would try to write this without any else clauses. The trick is to sort out the problematic case first:

function transmogrify(input) {
    if (!input.someConditionIsMet()) {
        throw INVALID_INPUT;

    var result;
    result = processInput(input);
    if (!result) {
        throw UNDEFINED_RESULT;
    return result;

See how much flatter the structure of that program is? There are some other advantages:

  • Because you no longer put the main flow inside if statements, your programm is often easier to refactor. If for instance the sanity checks occur in multiple places of your program, you can simply factor them out into a utility function without messing up the structure of your code.
  • You generally have to indent less. And when you move code around, you have to reindent less — particularly pleasant when you’re coding in Python where indentation is significant.
  • In languages with curly braces like my fake JavaScript above, you don’t have to worry about blocks spanning many many lines, thus putting the opening and closing brackets so far a part that you no longer can tell what the closing bracket is actually closing.

Get every new post delivered to your Inbox.