Real World Privacy

A few summers back, I worked on the Firefox Metro project. The big challenge I ran into the first summer--back when the project was at a very early stage--was figuring out how to distribute early builds.

I wanted to quickly test work-in-progress builds across different devices on my desk without having to maintain a working copy and rebuild on every device. Later on, I also wanted to quickly distribute builds to other folks, too.

I had a short-term hack based on Dropbox, batch scripts, and hope. It was successful at getting rapid builds out, but janky and unscalable.

The underlying problem space–how you build, distribute, and test experimental prototypes rapidly?–is one that I’ve been wanting to revisit for a while.

So, Gossamer

This summer, Lyre Calliope and I have had some spare time to tinker on this for fun.

We call this project Gossamer, in honor of the Gossamer Albatross, a success story in applying rapid prototyping methodology to building a human-powered airplane.

We’re working to enable the following development cycle:

1. Build a prototype in a few hours or maybe a couple days, and at the maximum fidelity possible–featuring real user data, instead of placeholders.

2. Share the prototype with testers as easily as sharing a web page.

3. Understand how the prototype is performing in user testing relative to the status quo, qualitatively and quantitatively.

4. Polish and move ideas that work into the real world in days or possibly weeks, instead of months or years.

A First Proof-of-Concept

We started by working to build a simple end-to-end demonstration of a lightweight prototyping workflow:

(Yeah, it took longer than two weeks due to personal emergencies on my end.)

We tinkered around with a few different ways to do this.

Our proof-of-concept is a simple distribution service that wraps Mozilla’s browser.html project. It’s a little bit like TestFlight or HockeyApp, but for web browsers.

To try an experimental build, you log in via GitHub, and pick the build that you want to test…and presto!

About the login step: When you pick an experiment, you’re picking it for all of your devices logged in via that account.

This makes cross-device feature testing a bit easier. Suppose you have a feature you want to test on different form factors because the feature is responsive to screen dimensions or input methods. Or suppose you’re building a task continuity feature that you need to test on multiple devices. Having the same experiment running on all the devices of your account makes this testing much easier.

It also enables us to have a remote one-click escape hatch in case something breaks in the experiment you’re running. (It happens to the best developers!)

To ensure that you can trust experiments on Gossamer, we integrated the login system with Mozillians. Only vouched Mozillians can ship experimental code via Gossamer.

To ship an experimental build…you click the “Ship” button. Boom. The user gets a message asking them if they want to apply the update.

And the cool thing about browser.html being a web application...is that when the user clicks the "Apply" button to accept the update...all we have to do is refresh the window.

We did some lightweight user testing by having Lyre (who hadn’t seen any of the implementation yet) step through the full install process and receive a new updated build from me remotely.

We learned a few things from this.

What We’re Working On Next

There’s three big points we want to focus on in the next milestone:

1. Streamline every step. The build service web app should fade away and just be hidden glue around a web browser- and GitHub-centric workflow.

2. Remove the refresh during updates. Tooling for preserving application state while making hot code changes to web applications based on React (such as browser.html!) is widely available.

3. Make the build pipeline as fast as possible. Let’s see how short we can make the delay from pushing new code to GitHub (or editing through GitHub’s web interface) to updates appearing on your machine.

We also want to shift our mode of demo from screencasts to working prototypes.

Get Involved

This project is still at a very early stage, but if you’d like to browse the code, it’s in three GitHub repositories:

• gossamer - Our fork of browser.html.

• gossamer-server - The build and distribution server.

• gossamer-larch-patches - Tweaks to Mozilla’s larch project branch containing the graphene runtime. We fixed a bug and made a configuration tweak.

Most importantly, we’d love your feedback:

• Tweet at us! We’re @CaptainCalliope and @hellojwilde.

• Come say hi in #gossamer on Mozilla IRC.

• File issues on GitHub. We’re centralizing issues in the gossamer repo for now.

There’s a lot of awesome in the pipeline. Stay tuned!