Moving At Internet Speed

June 25th, 2011

In his book Program or be Programmed, Douglas Rushkoff writes:

For most of us, the announcement of the next great “iThing” provokes not eagerness but anxiety: Is this something else we will have to pay for and learn to use? Do we even have a choice?

At Mozilla, we talk a lot about user choice, but one choice we have a hard time giving our users is whether to upgrade to the latest version of our software.

This isn’t unique to Mozilla, of course. It’s fundamentally a social problem: once developers decide to push a product in a certain direction, there’s not enough human resources left to maintain the old version for an indefinite period of time. Eventually, the old version reaches its end-of-life; one can try to keep on using it, until a security hole that goes unfixed results in data compromise, or a dependency like the underlying operating system changes and breaks the program that relies on it.

Our inventions shift beneath us like tectonic plates.

Every company wants their product to be the next great iThing, but what about people who are content with what they’ve got? Or the ones that are so overwhelmed by the other changes in their life that they simply don’t have the time to figure out how to use the latest version of their software, which has been forced upon them at internet speed?

The Challenges of Developing Offline Web Apps

June 23rd, 2011

As I mentioned at the end of my last post, there’s a lot of usability problems that make writing an offline web app difficult.

When writing a “native” client-side app using technologies like Microsoft .NET or Apple’s Cocoa framework, it’s assumed that everything your program is doing, and everything it needs, is already installed on the local device. Anything not on the local device needs to be explicitly fetched over the network. Any app is therefore “offline” by default, and it’s very easy to tell, both when reading and writing code, when it needs to access the network.

Understandably, this makes it trivially easy to write an offline native app. One’s very first app works offline, unless there’s something related to the app’s purpose for which network access is obviously required.

On the other hand, offline web apps build on the already confusing, frequently opaque world of resource caching. They also break developer expectations in various ways that I’ll explain shortly. Furthermore, no browsers except Chrome provide tools for introspecting and understanding the behavior of an offline application, which adds to developer frustration.

Problem One: Simple Things Aren’t Simple.

Let’s say you’ve made a simple web-based currency converter, which is fully self-contained in a single HTML file and never requests any resources from the network. A browser won’t let it be accessed while the user is offline unless you do a few extra things:

  1. Create a manifest which enumerates every resource that needs to be available to the app.

  2. Make sure the manifest is served with a mime type of text/cache-manifest, which is done differently depending on the web server software you’re using.

    As I mention in my post On The Webbyness Of An Installable Web App, this single requirement vastly complicates the scope of the problem by requiring developers to understand the HTTP protocol layer and their web server software. Furthermore, Chrome’s Web Inspector also appears to be the only tool that provides helpful error feedback if the manifest is of the wrong type—developers using Safari, Opera, or Firefox will likely be confused as their application silently fails to be cached.

  3. Add a manifest attribute to their HTML file’s <html> element that points to the manifest.

Doing all this will allow you to deploy your simple currency converter app for offline use; it’s clearly much harder than writing an offline native app. But what’s worse is that adding offline support complicates further development of your app in a number of ways.

Problem Two: Your Development Workflow Is Now Broken.

Let’s say you make a simple typo fix in your HTML file. The fix won’t actually propagate unless you also alter your app’s manifest file in some trivial way; even then, because the cache manifest is checked after the cached version is loaded, the page needs to be reloaded an additional time to activate the new version.

Needless to say, this complicates the development workflow for the app, as it impacts the edit-test cycle. Workarounds exist, of course; for All My Etherpads, I’ve added an --ignore-cache-manifests option to the bundled Python development server that allows the server to pretend that the manifest doesn’t exist, so that the app’s offline cache is obsoleted and code changes propagate instantly. Even though such workarounds make it possible to develop as one normally does, developers still must remember to make a trivial change to their manifest file when they re-deploy, or else their existing users won’t see their changes.

Problem Three: Your App Can’t Access The Network When Online.

After creating your first completely offline app, you might think that adding a manifest file would just let you specify what files your app needs for offline use, and that accessing other resources would obey the normal rules of the web: they’d be accessible if the user happened to be online, and they’d fail to load if the user was offline.

But this isn’t the case at all. Simply having a manifest file changes the rules by which a page accesses any network resource, whether the user’s browser is online or offline. Unless a manifest explicitly lists a resource in one of its sections or contains an asterisk in its NETWORK section, attempting to access the resource from an XMLHttpRequest, a src attribute in a HTML tag, or anything else will fail, even if the user is online. No browsers currently provide very good feedback about this, either, leaving developers befuddled.

Problem Four: Cross-Browser Support Is Hard.

Not all browsers support the full application cache standard. Some browsers, for instance, don’t support the FALLBACK manifest category, which will cause apps on those browsers to behave differently.

Problem Five: There’s Not Much Tooling For This.

As I mentioned at the beginning of the post, Chrome is the only major browser that provides any information on the state of the application cache. Developers on other browsers at least need to add some code that monitors the state of the application cache and logs the many kinds of events it can emit, but even that information doesn’t tell you everything you need to know.

This is probably the most important problem, since it exacerbates all the others: if an offline app isn’t behaving as expected, a developer without the right tools can’t tell whether it’s due to many of the problems explained above, or something else entirely.

The Bigger Picture

These issues are symptomatic of a larger problem that most in-browser development tools face, which is that they generally provide little information that tells you exactly why a resource couldn’t be accessed. Aside from the complexities offline apps introduce, cross-origin resource sharing and the single-origin limitations put upon fonts and video make resource access in HTML5 incredibly complex. Yet most of our tools haven’t yet adapted to the development problems that arise when we use the new platform features.

The Good News

One of the best things about offline web apps, which is part of the reason for the additional complexity from the world of native apps, is that automatically updating is simply part of the way they work; you don’t have to put them on an online marketplace to benefit from the functionality, nor do you have to research and invest in any kind of third-party libraries that incessantly nag the user to upgrade. This is awesome.

As for the challenges facing developer ergonomics, help is on the way. Mikeal Rogers and Max Ogden are currently working on a project to make offline web apps easier to build. Folks at Mozilla believe that support for offline apps is an important use-case and want to make the user and developer experience better. Every major browser except Internet Explorer already seems to support the feature, which is also great. I’m already thinking of a few ways to ease these hassles myself.

In the long term, though, as I explained in my previous post, I think that the user perception of offline web apps—and the associated usability problems with even using a browser offline—are at least as important as the developer-facing challenges. Fortunately, the Open Web has some really awesome advocates, and I’m confident we can solve all of these problems once we put our heads together.

On The Usability Of An Offline Web

June 22nd, 2011

Last week I spent some time working on a simple offline web app called All My Etherpads. Creating it has made me think about a lot of things, one of which has to do with how the word “offline” constantly seems at odds with the word “web”.

When you’re using a web browser, it’s simply assumed that you’re online. Many argue that a resource must live in the cloud for it to be truly “of the Web”. Even though it’s possible for a browser to store resources on the local device, such caching is largely considered an implementation detail and has historically been done solely for the purpose of speeding up page loads and reducing bandwidth usage. One gets the distinct impression when using a browser or reading through web developer documentation that the very notion of a network being inaccessible is some kind of bizarre anomaly akin to having no water or oxygen.

Aside from raising some concerns about user freedom and tethered software, this means browser user interfaces are terribly unhelpful when it comes to serving users who are in the unfortunate position of having a temporary lapse in internet access. Even though some browsers like Firefox have an “offline mode”, there’s no easy way to tell them “hey, this page is really important to me, and I’d like to see a recent version of it even when the internet isn’t available”, which makes using the mode largely a crap shoot. Other browsers, like mobile Safari, raise modal dialogs if you dare start them while offline.

This alone makes me concerned about users’ perceptions of even using a browser while they’re offline; the experience has historically been so inhospitable that the very term “offline web app” sounds like an oxymoron.

Perhaps it’s partly because of this, then, that so few offline web apps currently exist, despite the fact that infrastructure for creating them has been around for a number of years. But I think it also has something to do with the developer ergonomics of actually writing an offline app, too, which I’ll address in my next post.

Making Hackasaurus Remix Easier

June 9th, 2011

I've been working on an experimental iteration in the X-Ray Goggles which addresses some problems we observed kids having with the Compose A Replacement (aka “remix”) dialog at the TEDx Kids Brussels 2011 event and other hack jams.

The current remix dialog looks like this when focused on a Facebook sidebar on the New York Times website:

There's a number of problems with this dialog:

  • The HTML Source Code column isn't formatted in a way that helps the reader understand much about the structure of a Web page.
  • Despite the syntax highlighting provided by Ace, it's very easy for newcomers to struggle with HTML syntax, missing out on more important concepts (and more fun experimentation).
  • The What Your Browser Sees column is frequently overlooked by users; as such, it doesn't effectively communicate the idea of a DOM hierarchy, and it also takes up lots of screen space.
  • The What You See column doesn't inherit the CSS styling of the page being remixed, which is very confusing.

The Easy Remix Dialog is an attempt to resolve the above issues, inspired by the interfaces of tools like Scratch and Yahoo Pipes. Here's what the new design looks like:

You can see it in action in the following silent screencast.

Read the rest of this entry »

Three Lessons Learned From Hack Jams

March 21st, 2011

The first five Hackasaurus hack jams taught us a lot. Here are a few lessons we learned from them.

  1. Know How Much Freedom You Have.

    At our hack jams in the New York Public Library, we discovered that their publicly-accessible Windows XP machines were so locked-down that we were unable to run Firefox or any other programs off a USB stick. Our prototype Web X-Ray Goggles don’t currently work with the built-in Internet Explorer 8, so we weren’t able to use them. Even more distressing was that we couldn’t even show kids the power of View Source, because that feature was actually disabled on the library’s computers.

    This gets to the heart of what Jonathan Zittrain has described as Freedom At The Endpoints, because such a thoroughly locked-down computer—particularly one with an aging browser that doesn’t support many of the Web’s greatest benefits—has relatively little generative potential.

    We still need to figure out how to make it accessible for people to experience the full awesomeness of the Web in public spaces, but in the meantime, we’ve learned to bring our own computers for kids to use when necessary.

  2. Digital Natives Know Less Than You Think.

    When I was a kid, computers were all the rage at schools around the country. Throughout elementary and middle school, my classmates and I were taught Logo, BASIC, HyperCard, touch typing, and more.

    These days, however, kids are apparently assumed by the school system to be “Digital Natives” and not in need of any technology education: as a result, many of the kids in our hack jams had never done any programming in their life, and few of them knew how to touch type. Aside from being a distressing discovery, this meant that we had to “calibrate” the jams to the experience level of our students. It varied a lot from one jam to another, since we couldn’t rely on the school system to give them a firm grounding in basic computer use.

  3. Engage Your Audience’s Interests.

    One of the broad goals of Hackasaurus is to help kids see themselves as hackers—especially girls and minorities who are traditionally under-represented in technical communities.

    The first four hack jams we did in New York City and Chicago were promoted as Hackasaurus events: the main reason to attend was to learn how to “hack the Web”. Unsurprisingly, we only got kids who self-identified as potential hackers, which meant that nearly everyone who showed up was male.

    In contrast, the fifth hack jam, held in San Francisco at the Bay Area Video Coalition, was actually a Web Made Movies Workshop where Ben Moskowitz decided to deploy the Hackasaurus tools. This was a perfect pairing, as understanding the basics of HTML and how the Web works are closely related to making movies with it.

    Since the event was promoted as a filmmaking workshop, however, we didn’t get kids who self-identified as potential hackers. They picked up hacking just as quickly as the kids from previous jams, and they enjoyed it just as much; but by teaching them about technical concepts that were directly related to things that they were already passionate about, we were able to make them really excited about the Open Web. Aside from attracting a more diverse group of kids, we were also able to engage them more directly.

    So, future Hackasaurus hack jams might not even be promoted as such. Right now we’re thinking about developing many different “genres” of jams that engage kids on non-technical issues that they’re already excited about. If you have any suggestions, we’d love to hear them!

Enter The Hackasaurus

March 14th, 2011

I’ve recently switched projects at Mozilla. I was previously the technical lead for the Jetpack project, but at the beginning of February 2011 I started working on a new project called Hackasaurus: a toolkit and curriculum to help kids and other “non-techies” understand the Web and how to hack it.

The origins of this project go back to a blog post I wrote in 2009 called Kids And The Open Web, where I compare a Web page to “magic ink”. This metaphor is based on a realization I had when I joined Mozilla in early 2008.

Before joining Mozilla, the last time I had done anything with HTML was in the late 1990s, when Web pages were very static and boring. After joining Mozilla, I learned about new tools and concepts that had emerged over the past few years: Firebug, jQuery, Greasemonkey, Ajax, bookmarklets, and browser add-ons. All of these suggested a completely different metaphor for the Web page, from something that was immutable to something that was dynamic and remixable. Learning how to use these tools was also empowering: since I already lived much of my life on the Web, being able to alter any website at will was effectively like being able to see through the Matrix.

Most people don’t know about these aspects of the Web, though. And whenever we’ve talked about what makes the Web great, we’ve always had trouble explaining concepts like remixability and transparency to newcomers: to them, the Web is just as immutable and opaque as Flash, iOS, or any other platform.

But as Mitchell likes to say: at Mozilla, we don’t just talk. We make things. And Hackasaurus is a toolkit and curriculum to help ordinary people see through the Matrix and understand, at a visceral level, what makes the Web so awesome.

The project is still pretty young, but we’re moving quickly: we’ve held 5 events over the past month in New York, Chicago, and San Francisco that have given us a chance to put the tools in the hands of kids, see what they do with them, and quickly iterate in response.

For me personally, working on the project has involved a blend of heads-down coding, teaching, engagement, and user testing that I find challenging and fulfilling. My teammates—Ben Moskowitz and Matt Thompson from Mozilla, Jessica Klein from the New Youth City Learning Network, Taylor Bayless from YouMedia Chicago, Jack Martin and Chris Shoemaker from the New York Public Library, and Rafi Santo from Indiana University—have also been terrific to work with. It’s inspiring to collaborate with people who are so passionate about learning and the Open Web.

If you’d like to know more, feel free to check out the nascent Hackasaurus website. I’ve attempted to maintain a concise history of the project there to make it easier for newcomers to get involved or stay up-to-date without being overwhelmed.

Adventures in Code Review and Pair Programming

November 8th, 2010

A key component of Mozilla’s development process is code review, which consists of a trusted expert reviewing the material comprising the changes to a piece of software in order to fix a bug or add a feature. This is a great idea for a number of reasons:

  1. It helps increase the project’s bus factor, or number of people who understand how the software works and why decisions were made. If any trusted member of the community could simply push changes without requiring another person to be aware of them and understand them, then if that person were hit by a bus or truck, some amount of understanding about the software would be lost, especially rationales that could only be uncovered by the conversation that occurs during code review.
  2. There are many qualitative aspects of code that aren’t understood by a computer interpreting it. For example, if a developer writes some code that talks to another component, having someone well-versed in the other component read the changes can help correct any implicitly incorrect assumptions about the communication before flaws occur further downstream in the development process, when they will be more costly to detect and fix.

However, code review can also have its own costs. Because it requires two people instead of one, by necessity any changes one person wants to make are blocked by the other. Most code review at Mozilla is done asynchronously, which means that one developer writes and uploads a patch that a reviewer reads at their convenience. Because reviewing isn’t much fun and reviewers have lots of other things to do, the back-and-forth process of reviewing and correcting a patch can take several days, weeks, or even months—and that’s not even including the implicit task of finding a reviewer in the first place. All this can sometimes make the pace of development slow to a crawl: imagine a complex conversation occurring for one hour every other day over a period of weeks, requiring each participant to remember the state of the conversation every time their focus came back to it.

Another problem with asynchronous code review is that changes which are considered relatively low-priority, such as paper cuts, might be constantly stuck in a state of needing to be reviewed or revised because they’re constantly pushed to the bottom of someone’s queue as more important changes are discovered and prioritized above them. Even worse, developers may be reluctant to voluntarily fix such smaller bugs because they have little confidence they’ll ever get reviewed.

Enter Pair Programming

One potential solution to this is pair programming, whereby the developer writes code while the reviewer looks over their shoulder, effectively serving as a “navigator”, fixing potential mistakes before they even occur.

It sounded like something worth trying out, so I ran the idea by Myk Melez, who agreed. A little while later my colleague Brian Warner and I started fixing a Jetpack SDK bug together using this technique.

This proceeded quite smoothly. In particular, I noticed a few unintended consequences of pair programming:

  1. Coding can be a rather solitary activity, and when working on a major change, it can get lonely. Pair programming makes the activity social, which makes it more fun for me personally.
  2. There’s a tremendous amount of knowledge the coder and reviewer can learn from one another in a face-to-face or voice-chat based interaction that often is too burdensome to communicate via written text. For Brian and I, at least, I definitely felt that both of us learned more from pair programming than we would’ve if we stuck to the standard process of writing to each other.
  3. Both Brian and I had an implicit social contract of staying focused on the task at hand, or something related to it, which allowed me to focus much better than I do on my own. When I’m by myself, it’s surprisingly easy to get sidetracked by new emails or IRC messages, but because I didn’t want to waste Brian’s time, I never digressed while pair programming. Sometimes we’d stray off the main path to discuss the semantic intricacies of JavaScript or Python, but such excursions generally supported our goal rather than distracting us from it.
  4. Because I actually enjoyed the activity, I was much more likely to get more out of it: ask sharper questions, provide better answers, and write code with fewer flaws.
  5. Low-priority bugs were fixed rapidly because of the super-fast synchronous communication. One morning Brian and I just took a few to “warm up” and were able to make the Jetpack SDK significantly more usable by getting rid of paper cuts that may have taken months to fix using traditional code review.

Being able to simply push changes to the codebase after pair programming them made development about as much fun as hacking on my personal projects. At a very high level, in fact, I think of asynchronous code review more like asking for permission while code review feels more like simply having a conversation. Or, in pedagogical terms, the former feels more like taking a test, while the latter feels more like peer-based learning.

In short, pair programming required no context-switching and felt faster, more effective, and more fun than what I was used to.

Risks

Because pair programming introduces a strong social aspect into the development process, a lot of psychological factors can come into play. For instance, if the navigator is overbearing, like a sort of “back-seat driver”, then I suspect pair programming could quickly become less efficient, less effective, and less enjoyable than alternatives.

On the opposite end of the spectrum, I think it’s also important to ensure that the person at the keyboard has at most the same amount of knowledge about the code they’re changing as the navigator. Otherwise, it’s easy for the driver to simply go off on their own way and leave the navigator in the dust. Keeping the principle that the navigator was effectively the reviewer made it easy for Brian and I to ensure this: whenever we had to make a change to code that Brian understood more than me, I’d be the driver, and vice versa. This meant more peer-based learning would occur, improving the bus factor.

Another potential problem with pair programming is that it can become harder to record the review process for posterity. Unless the dialogue occurring between the two programmers is recorded and made available to the public, part of the development process effectively becomes closed. That said, though, Brian and I tried to remain vigilant about other people reading our code in the future: when we spent more than a few minutes discussing how to do something, we’d take a moment to write a comment explaining why we picked the solution we did.

It should also be remembered that alternatives have their own share of risks: for instance, I’ve noticed that when I review code asynchronously, I have a tendency to only skim over it and comment on the surface-level details. In contrast, while pair programming, it’s much easier to ask intricate questions about how or why something works because the cost of doing so is much lower.

Variations

Pair programming need not be at odds with code review. In fact, a fair amount of the “pair programming” Brian and I did actually consisted of one of us writing the code alone and later walking the other person through the changes in a kind of synchronous code review, fixing any problems on-the-fly. In other words, simply turning the standard asynchronous code review process into a synchronous one looks a lot like pair programming.

In any case, I’m glad that all of these development processes are available at Mozilla, since different ones seem more appropriate depending on the personalities and technical challenges involved. None of them will be effective, however, unless both participants have a vested interest in making them work.

Prelude To Barcelona

October 13th, 2010

I recently wrote about a talk I gave at the Mozilla Summit on What Mozilla Can Learn From 826 National. Shortly after my presentation, Mark Surman dared me to teach a class on Web hacking for non-techies at the Peer 2 Peer University School of Webcraft, which got me thinking about how I’d teach a class in such a distance-learning environment.

My favorite kind of teaching is face-to-face, one-on-one mentoring. I think it works well because teacher and student have easy access to each others’ “state”: they can see what each other are working on, and infer how they’re feeling based on body language and other non-verbal cues. This makes it much easier for a teacher to gain insight on a student’s thought processes.

So at the very least, I needed a tool allowing HTML to be written and rendered collaboratively in real-time. I also wanted to prototype a solution as fast as possible, so I could quickly iterate, learn from my mistakes, and respond to the needs of my students.

Tools

The simplest and most effective collaborative environment I knew of at the time was called Etherpad, which allows non-technical users to easily collaborate on simple documents, or pads, in real-time. No “saving” is necessary because every keystroke is remembered and the whole pad is undoable back to the moment of its creation.

Etherpad lets you create a pad by just inventing your own URL. For instance, if you want to create a pad called hai2u on Mozilla’s Etherpad server, you can just visit etherpad.mozilla.org:9000/hai2u and then share the link with friends to work on it together in real-time.

The fundamental fabric of the Web—HTML, JavaScript, and CSS—is all plain text, so Etherpad had enough functionality to serve as a source code editor. The only other thing I needed was a way to get the user’s browser to render and execute that code, instead of just treating it as plain text.

So I bought the htmlpad.org domain and set it up with a few lines of Python to essentially serve as a HTML “viewer” for pads on Mozilla’s Etherpad server. The aforementioned hai2u, for instance, could now be viewed at htmlpad.org/hai2u.

It was far from ideal; I’d actually tried setting up Etherpad on my own server so I could modify its user interface to make this process much simpler, but ran into technical problems as Etherpad required more memory than my server had. Still, the simple hack would allow students to experiment with HTML in one browser window and view it in another, collaborate or receive assistance in real-time, and instantly share their work with friends, which was good enough.

Now all I needed were some students.

Guinea Pigs

The awesome Mozilla community engagement team has bi-weekly meetings to discuss things like local community events and the latest fundraising, download, and education campaigns. I noticed, though, that they used Keynote to create presentations that were uploaded to SlideShare and only viewable with the Flash plugin. Besides requiring proprietary technologies, it was just a crummy user experience.

Aside from that, our engagement team isn’t comprised of techies, which made them an excellent specimen for my pedagogical experiment. If the Web is so great because it’s open and hackable and remixable, then surely they wouldn’t mind doing their slides using HTML, right? I had my own doubts about this theory, but I wanted to try it out.

I hastily grabbed screenshots of their Keynote template, combined them with the hacked-up JavaScript from my Summit presentation, and cobbled together a makeshift template. Then I scheduled a meeting with the engagement team.

Teaching them how to write HTML at the meeting was easy—they’d all had at least a little experience with it before. Also interesting were my answers to their questions on how to do specific things: most of the time, I just told them to find another slide that did what they wanted, copy its code, paste it into a new slide, and modify it as necessary. I’ve read about the power of the browser’s View Source feature, but actually seeing it used by non-engineers was inspiring. And perhaps it was just because they were part of Mozilla, but it was great to see them having fun hacking on HTML.

Before leaving the meeting, my coworker Mary Colvig wrote up instructions for the rest of the engagement team to use. That evening, some people who hadn’t been able to make the meeting tried things out for themselves.

When I looked at the first slide of my template the next day, it had changed:

This is why I like making things for people.

Remixes

The engagement team used my hacked-up template for their July 28 meeting, but after that I worked with Sean Martell to make one that didn’t suck.

Paul Rouget and the European engagement team later used htmlpad.org and the slides to do some amazing things. Because we now had an easy way to play with the very fabric of the Web, we could start using all its awesome power in our own meetings. In particular, Paul hooked up WebSockets, a chat widget, and open video to create a fully synchronized experience that allowed people to see the meeting’s video, the current HTML slide, and chat with other participants at the same time.

Drumbeats

Mark Surman has recently put me in touch with Ari Bader-Natal, the creator of sketchpad.cc, which is a beautiful Etherpad-powered collaboration and learning environment for processing.js. I’m hoping to work with him to vastly improve htmlpad.org.

The amazing Anant Narayanan also joined us at Mozilla at the beginning of October, and I’m working with him to push forward experimentation with webcam and microphone input, so we can make our meetings even more participatory while also moving the Web platform forward.

I’m also looking forward to working with Ingrid Erickson and Taylor Bayless at the Drumbeat Festival to build something that makes it easy and fun for newcomers to learn and hack together on the Open Web—perhaps it will build upon htmlpad.org or the Open Web Challenges that I made for my Design Challenge Tutorials, or maybe it will be something completely different.

Either way, I’m excited.

Reviewer Dashboards

October 4th, 2010

As I mentioned in my post on The Social Constraints of Bettering The Web, finding a code reviewer can be difficult in Mozilla projects. At least, it’s definitely the case with the Jetpack SDK, which I’m actively involved in as both a reviewer and contributor.

Last week, on casual observation, it seemed like Myk Melez had been getting a lion’s share of code review demands placed on him. While I had some theories on why this might be the case, I also realized that I had no idea what the big picture was as far as code reviews were concerned. As such, I often had no idea who to assign a review to if I could think of more than one person who’d be qualified to do it.

So I put together this prototype dashboard for the Jetpack SDK project:

It’s really simple, but it’s a useful enough start that Aza took the code and adapted it to serve as a reviewer dashboard for the awesome Firefox Panorama project.

As with my Bugzilla Dashboard, this is just an HTML page that uses Gerv’s glorious Bugzilla REST API. There is no Django or Rails or other server-side code, so you can fork it on Github and modify it without setting up a server.

There’s some other things that could be useful here:

  • I have a cross-site XMLHttpRequest service up on my server that lets anyone grab the rendered HTML content of Mozilla wiki pages from any web page. This allows reviewer dashboards to use the Mozilla wiki as a backend for some information, e.g. for storing information about who the module owners/peers are instead of hard-coding it into the app.
  • As Patrick Walton mentioned to me, it’d be great to have basic status/availability information about reviewers. In the case of the Jetpack SDK, for example, Myk is currently on vacation, and Dietrich and Drew are both heads-down on Firefox 4 work so they shouldn’t be assigned any reviews. It’d be nice to have that kind of information up there too, perhaps pulled from Benjamin Smedberg’s weeky updates app.

I think this sort of application could also be used as a “leaderboard” to incentivize code reviews. A few weeks ago, Shawn Wilsher issued the following tweet:

I have this problem where I measure how much work I do based on how much code I write. I haven’t been coding much and feel largely useless.

I assume he wrote this because he’d been reviewing tons of code. If that’s the case, a dashboard like this could also be used to help reviewers feel awesome about their work by being publicly recognized for it, while also providing more transparency and accountability about the review process as a whole.

What Mozilla Can Learn From 826 National

October 3rd, 2010

At the Mozilla Summit in early July, I gave a short presentation on what Mozilla could learn from an awesome non-profit family of writing centers called 826 National.

One of the many things that really impresses me about this organization is that their chapters ooze with a love for writing and creativity, and encourage and showcase it everywhere. For example, their San Francisco chapter, 826 Valencia, masquerades as a pirate supply store that’s filled with products like kitten and hamster planks, beard extensions, and scurvy remedies—all with hilariously-written labels and instructions for use, and whose proceeds go directly to the writing center’s many tutoring programs. Alongside these fake products are real ones: books published by McSweeney’s, and anthologies of poems, non-fiction, and fiction written by kids at the writing center.

It might sound strange, but it’s brilliant. You walk through the store and realize how awesome the printed word is, because every single word you see is so wonderfully crafted, contextualized, and packaged, regardless of whether it was written by a professional or an amateur. Embodied in everything is the idea that writing is fun, being creative is fun, and you can do this too.

At Mozilla, we often talk about how hackable and remixable the Web is, and I wrote about it once myself. But to most people, it’s not obvious: the Web seems just as immutable and opaque as any other commercial product. That’s because techies are the only ones who really know anything about it.

But what if we could make people as excited about the Web as 826 Valencia makes us about writing? What if everyone just knew that the Web was hackable and remixable, because they knew how to do it themselves and saw examples of it all around them?

Maybe it’s impossible, but I want to find out. I’d like to work on this at the Drumbeat Festival on Learning, Freedom and the Web coming up in Barcelona next month—but I’ve already started a few experiments which I’ll write about in my next post.