Mozilla is hiring a new user interface designer for Labs. I think some of the readers of this blog might be interested in that sort of thing?

This Raindrop thing seems pretty cool. I’ll use it even if for no other reason besides its ability to separate the bac’n from the real-human-conversations-that-I-care-about email.

Unfortunately, using the current demo version requires running your own server locally, which is a high barrier to entry. But keep an eye on the evolution of this project; it might be just the thing we need to take control of our inboxes again.

(When I say “take control of our inboxes” I am thinking of my Gmail inbox which currently has over 10,000 conversations in it, a third of them unread.)

Spilling over with enthusiasm as always, Aza gave a talk to a recent web developer conference in London about how he sees the future of the web browser. He takes together several strands that Mozilla Labs has been working on and ties them together into a story about how the browser can evolve into more of an intelligent user-agent. The browser really ought to bring the mountain to Mohamed, to borrow a phrase, rather than sending Mohamed to the mountain.

I’m glad he mentions Ubiquity, but I think Aza oversells it a little bit. For example, he talks about Ubiquity collecting your contacts from Facebook in order to auto-complete emails. Getting Facebook contacts is not something we currently know how to do. So I want to clarify that when Aza talks about Ubiquity in this video, a lot of the things he mentions are aspirational — “stuff we would like it to do someday” — not things that it does right now.

Ex-Mozillanoid JWZ writes of his “ongoing Kafka-esque nightmare of dealing with Palm and their App Catalog submission process.” (Part One) (Part Two).

His story shows, by counterexample, exactly why the Open Web is important. Part of the working definition I came up with in my previous post was that on the open web, no company can get between a developer who wants to publish something and a user who wants to use it. JWZ’s story shows what happens in a non-open environment when a company, Palm in this case, does get in the way. JWZ’s applications were innocuous free software which posed no conceivable threat to Palm in any way, and he didn’t even want to charge anything for them; nevertheless, Palm’s bureaucracy prevented JWZ from giving away his own software to people who wanted it.

When this happens, developers and users both lose.

Palm is not unique in this regard. The process for getting apps approved on the iPhone is no less opaque:

We’ve been getting more and more questions from customers wondering where the heck our iPhone App is. Unfortunately, we have no idea.
…
Despite sending a steady stream of emails to Apple requesting status updates, we continue to receive generic form letters in response – frustrating, to say the least.

Say what you like about Microsoft, but they never barred independent software developers from developing and distributing Windows software, did they?

A very snazzy video.

We’ve had over 5,000 users submit data from the Test Pilot tabs study!

Considering that people had to first hear about Test Pilot, then opt in by installing the extension, then opt in again by choosing to submit the data, 5,000 is a really good number. Better than we had any right to expect, certainly.

Over the past couple weeks, I’ve been sifting and analyzing the data, and working with Blake Cutler from the Mozilla Metrics team to generate graphs of interesting statistics about tab usage. I’ve just put up a results page showcasing several of these graphs.

We’ve also posted samples of the aggregated data which are free for anyone to download and use. There was some discussion on my previous post about how to aggregate the data in a way that was still useful to researchers. What we ended up doing was building files that include row-level data from a random subsample of the users that fit particular criteria. It’s stripped of any information on the language/locale, operating system, or installed extensions for any individual user in the sample.

Third-party researchers have already begun using the data to do their own analysis! Andy at Surfmind.com has a post containing some very cool-looking visualizations and has proposed an interesting theory about there being two classes of heavy tab users.

I get a lot of people contacting me by email, IRC, forums, or blog comments to say that they’re “worried that if I join Test Pilot I’ll skew the data” because “I’m sure that my tab usage is atypical”.

People! Don’t worry about being an atypical user!

First of all, we have already had almost 5,000 Test Pilot data submissions. One outlier isn’t going to do much to “skew” a data set of that size.

But more importantly, you shouldn’t assume that you’re abnormal. We don’t know what “normal” tab usage is! That’s why we’re doing this experiment, to find that out. If we started out with an idea of what normal tab usage looked like, and threw out things that didn’t match our preconceived notions, that would be a clear case of experimenter bias. Then we’d really be skewing the data.

For instance, I was surprised to find out that there are users who have over 500 tabs open at a time. Over 500! They’re surely outliers, but they’re not abnormal users &emdash; they’re just users. That number isn’t skewing the data &emdash; it is the data. Thanks to those users’ participation, we now know that having 500 tabs open is something that people do with Firefox, something we might not have known otherwise.

As I said in a previous post, I do believe we have a major oversampling of the power-user / early-adopter demographic in our current Test Pilot user base, and that we need to work on fixing this by reaching out to a wider sample of users. But note that word: wider. Excluding yourself because you think you’re atypical isn’t helpful. If you really want to help our sample — and I’m touched that so many of you do want to help " the best thing you can do is to let your less-techie friends know about Test Pilot.

Alexander Limi has posted a video, from the Design Lunch three weeks ago, wherein the UX leads answered questions about their provisional redesign of the Firefox UI.

Alex wants to warn you that the contents of this video are very rough, very much a work-in-progress, and very much liable to change. You shouldn’t watch it thinking "this is how the next version of Firefox is definitely going to be". You should think of it as a behind-the-scenes look at "how the sausage gets made", in Alex’s words. He also warns:

There’s swearing, there’s mumbling, there’s ranting, there’s hand-waving, there’s political incorrectness.

I’m also in the video, playing MC in my overalls.

Today we recorded Part 2, which goes into detail about the notifications interface and the downloads manager; it should be posted fairly soon.

For my contribution to Mozilla Service Week, I’m going to be helping the local Stanford Chinese School improve their student/teacher database. Should be an interesting learning experience. Among other things, they have a bugs where Chinese characters in certain places are getting mangled. Figuring this out will be good practice in the practical aspects of internationalizing the Web.

OK, let’s say I’m an amateur game developer. I’ve got an idea for a computer game where players build and manage a space colony and terraform an alien planet. I’d like to write it as a hobby project and play it against my friends.

First thing I gotta do is pick a platform. What are my options?

In theory, I could develop for a video game console. But that means super-expensive software development kits, and hardware-specific programming techniques, and besides, the company that controls the console will get to decide whether to allow my game or not. Console games are not practical for a hobbyist developer. I’d better write a computer game instead.

I could write my game for Mac OS X, using Cocoa or whatever. I’d have some pretty snazzy developer tools for building my user-interface, but only Mac users would be able to play it; that’s a pretty big drawback.

I could write my game for Windows. Same deal; snazzy tools, but only people with Windows could play it. As a one-man project, I don’t have the resources to maintain parallel Mac and Windows versions. And what about Linux users?

I could write my game using a cross-platform graphics/sound/UI library — for instance, I could write it in Python and use PyGame. Then it would run on any computer with Python installed. Yay!

But then I have the problem of how to distribute it: I have to write an installer that people can download. I need one installation method for Mac, a different one for Linux, and a third for Windows, plus the Windows installer has to bundle the Python interpreter since Windows doesn’t have Python installed by default. Then I’d have to rebuild and redistribute all three of these installers every time I made a change to the game code.

What a headache! Developing for a desktop operating system is so passe. What are my options for modern world of web 2.0 and cloud computing?

I could write it as an iPhone app, but then only people with iPhones could play it, and then only if Apple decided to approve it.

I could write my game in Flash and put it on the web. This is a much better option. I just send my players to a URL where they can play my game, Flash is supported on most browser/OS combinations, and when I make updates to my code, all players get them instantly. That’s a big thing! The drawback is that before I could begin development, I’d have to pay Adobe $700 for the professional developer kit. When it was ready to share I’d have to make sure my users install the latest version of the Flash plugin.

Or… I could choose to make my game a web application: Some HTML, CSS, and Javascript to run in the player’s browser, plus a database and some code on my server.

The open web is a development platform. It competes against Mac, Windows, Linux, the iPhone, Flash, Silverlight, etc. It’s one of the choices I have as a developer.

The hypothetical open web version of my game shares many benefits with the hypothetical Flash version. Like the Flash version, players could always play the latest version of a webapp game by just going to a URL. They can play using whatever browser and whatever operating system they want. But unlike the Flash version, nobody has to install a plugin. And there’s no SDK I have to buy.

True, the open web has many drawbacks as a game development platform. I can’t do realistic 3-D graphics or high-quality sound. The authoring and debugging tools available are very basic. And I do still have to worry about whether different browsers will interpret my JS and CSS slightly differently.

But the advantages, for me and for my users, are compelling enough that I choose to use the open web anyway.

No technology I use in my open web game development — HTML, CSS, JS, server-side SQL databases — is owned or controlled by any single company. They are standards with (mostly) interchangeable implementations. No company controls HTML, CSS, JS, etc. the way that Apple controls the iPhone, Nintendo controls the Wii, Microsoft controls Windows, or Adobe controls Flash. No company acts as gatekeeper over the open web; I don’t have to submit my game to an approval process. I only have to write one version of the game, and anybody with a computer can play it.

It’s easy to web developers to take it for granted, but remember: this freedom is the exception and not the norm. For most of the history of computing, I wouldn’t have been able to put my game in the hands of my players without the implicit permission of the company that made the hardware, the company that made the operating system, the company that controlled the software distribution channels, etc. I would have had to do my game within the limits of what these companies allowed, and I would have been able to reach only the audience that these companies allowed me to reach.

But on the open web, every single piece of the stack is a commodity. If you don’t like your operating system, you can change operating systems and still play my game. If you don’t like your browser, you can change browsers and still play my game. If I don’t like my webhost, I can change webhosts and still serve my game to you. If either of us don’t like our ISPs, we can change our ISPs and still connect to each other. And so on. The open web represents a phenomenal shift in power to the side of the user.

The open web is just one of many game development platforms, but it is the only platform where nothing comes between my game and the people who want to play it. On the open web, as long as I want to write software and somebody else wants to use it, nobody else can get in our way.

So that’s one of my answers to Jinghua’s question. Why should I care about the open web? Because when this platform is weakened by the encroachment of proprietary standards, my options for connecting to my audience as a hobbyist game developer get worse. And when it’s strengthened by more browsers supporting more open standards for doing more things, my options as a hobbyist game developer get better.