MapGate

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.

Advertisements

A Mozilla and Open Source success story

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

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.

The future of BarTab

BarTab has a faithful user base. Every day I get emails that look approximately like this:

Thing is, I made BarTab when I was a grad student because it was something I and Firefox needed at the time. Things have changed. I no longer am a grad student with lots of disposable time (yeah, right) and frankly, there are more important things at stake in Firefox land.

Firefox is stepping up

But! The good news is that Firefox is slowing assimilating BarTab’s feature set. That’s right! Let me show you how:

Since Firefox 8, you can tell Firefox to only load your tabs on demand, just like with BarTab. You can find this setting in the Firefox options/preferences dialog:

What’s more, my tireless colleagues Paul O’Shannessy and Tim Taubert are working on bringing even more BarTab-like features, e.g. the auto-unloading.

Who wants the keys?

As far as BarTab’s future is concerned, there might be hope. People have forked it on GitHub and apparently made it work (great work, whoever you are!), other people have made XPIs with fixes available. This is awesome, but I can’t just merge their work and release it. At least I don’t want to put my name on something that I haven’t thoroughly reviewed and tested. But, if somebody else wants to take than on, I’d be more than happy to hand the keys to BarTab over. Please get in touch with me if you’re interested!

Taking a break from Firefox Sync

It’s been a year and a half since I joined Mozilla and the Sync team. We’ve done exciting things since then: integrated Sync into Firefox, simplified the cryptography scheme to get rid of expensive RSA encryption and auto-generate a key for the user, provided an easy device pairing mechanism, improved performance and memory consumption, made sync scheduling smarter, error reporting less and less obnoxious, tons of reliability fixes under the hood, … the list goes on.

At the same time we’ve grown a team of three engineers to a team of a dozen or so, plus a product manager, QA, and an Ops team. There’s a roadmap and weekly client and server release trains ensure a tight and timely engineering/QA/deployment cycle. And while we’ve hit some bumps along the road, it feels like we’re doing proper software development and stuff. More importantly it feels like proper, feel-good teamwork.

With this many resources are devoted to Sync, I am happy to announce that for a while I’m going to devote most of my attention to some new stuff happening at Mozilla right now: Boot to Gecko. This rather geeky name stands for something incredibly exciting: developing a truly open and transparent phone stack that is for and of the web. It ranges from creating a phone’s complete UI and functionality with HTML/CSS/JS down to writing a GSM stack in JavaScript. I expect to dabble with all of it here and there and learn a ton from a bunch of rather intelligent people. As you can imagine, I’m pretty excited about that.

That said, taking a break from Sync, even if it may be temporary, won’t be easy. I will sorely miss Mike Connor’s mentorship, sharing two halves of a brain with Richard Newman, collaborating with battle-hardened server engineers and ops people, and being a mentor to a bunch of incredibly talented people that are all going to be much better at this stuff than I am right now. Thank you all.

Now, if you don’t mind, I’m going to put the intarwebs in ur phonez. Kthxbai.

Six months with the Nexus S

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.

about:sync-log

The past

For a long time Firefox Sync has had the ability to write a continuous log of what it’s doing to disk which is  pretty easily accessible via about:sync-log. In the Firefox 4 beta cycle, we disabled the log by default because the disk activity of writing the log can hurt your browser’s performance, particularly on mobile (it also didn’t help that the writes to the log blocked the UI thread.)

Only problem is, having the log disabled by default means that whenever Sync fails somehow, the user won’t have a log of what happened. Right now they have to turn on logging in about:config, restart the browser, and then sync again. That means we really only have a chance of catching reproducible problems, not the intermittent ones.

The future

Last week I spent a few days fixing the logging situation and with today’s nightly (and eventually Firefox 7) things have changed. Sync now keeps the log in memory and usually discards it after a successful sync. If an error occurs, however, the log will be written to a file (but not on the UI thread!) Consequently, about:sync-log has been changed to show you the directory where the individual log files are dumped. The most recent log files will be at the bottom of that listing. (Eventually we might make this a bit prettier, e.g. by taking some inspiration from about:crashes.)

Like before, it’s still possible to tweak logging behaviour in about:config, except now you get two preferences to define what should happen on a failed and successful sync, respectively:

• services.sync.log.appender.file.logOnError (default: true)
• services.sync.log.appender.file.logOnSuccess (default: false)

If you had logging enabled before, services.sync.log.appender.file.logOnSuccess will be turned on for you automatically.