Here’s something I read in a blog post by Esther Dyson, where she describes a visit to Russia in which she was asked for advice on how to spur innovation in the country:

In fact, I started my discussion with Russia’s government leaders by talking about my experiences as chair of NASA’s Innovation and Technology advisory committee. The issue, I said, was not really about funding technology innovation; it is how to create a culture that rewards thoughtful innovation and considers mistakes the price of learning.

Another requirement is good customers – that is, customers who are willing to pay good money for good products and good services, who are willing to try out new things that show promise and to give feedback, and who are unwilling to take bribes.

One of the really interesting things I’ve noticed about Apple-created markets ever since I had my first Macintosh LC in the early 1990′s is that they attract consumers who think that good user experiences are worth paying money for—an easy belief for Apple to select for, since one has to have it to buy an Apple product in the first place.

This belief isn’t the case so much in the PC world, or at least it didn’t use to be; when I came to my first Mac from a PC and browsed the troves of third-party software, I was befuddled by how many of them expected me to actually pay for them. This “culture shock” became even more acute in late 2007, when I switched from Windows to OS X and found the same thing—only this time it was a welcome change, with a few exceptions.

From Dyson’s perspective, was I simply an un-civil consumer in the early 1990′s, spoilt by the notion that getting a mediocre experience for free was better than paying for a well-designed one? I believe the strength of Apple’s platforms today has something to do with it, and it’s an interesting question to ask of any potential marketplace: what do your particular customers value enough to pay good money for?

On Friday I attended CrisisCamp Silicon Valley. I didn’t really know what to expect, since I was unfamiliar with the nascent field of internet-facilitated crisis response and was unable to find a high-level overview of how people—both techies and non-techies—can really make an impact.

The Bird’s Eye View

As I understand it, this is the big picture of internet-facilitated crisis response:

1. People on the ground in a disaster are told, through various channels, to report what they’re seeing to the public through a variety of media: SMS, Twitter, Facebook, whatever’s easiest and most understandable for them. In the case of the floods in Pakistan, for instance, people are encouraged to report by sending an SMS text message to 3441, making sure to add FL to the beginning of the message.
2. These raw reports are collected or found by programs on the Internet that send them all to a site for processing by humans, who classify and categorize them in various ways: for instance, does the report represent an emergency that needs attention, or a dangerous obstacle that aid workers should be aware of? Does the report need translation from a different language? To what area of the disaster area does the message refer? In the case of the Pakistan floods, you can visit pakreport.crowdflower.com right now to do this yourself—all you need to enter is your email address, and you’re presented with a brief message that someone on the ground sent.
3. Multiple people actually process the exact same report, which allows a computer program to correct for errors and combine information in the various responses—much in the same way that having two eyes is better than having one. This means participants don’t need to get too stressed-out about accidentally providing inaccurate information.
4. The processed reports are then collected at another site on the internet, where they effectively constitute a public resource that anyone can use. The most obvious consumers of the data would be the relief workers on the ground. The public data set, its associated software, and its user interface is sometimes referred to as Ushahidi or an Ushahidi instance—check out the Wikipedia entry on Ushahidi for more background on why. There’s a Ushahidi instance for the Pakistan floods at pakreport.org.

If you’re familiar with real-time strategy games like StarCraft II, this whole process could be envisioned as crowd-sourcing a mini-map of a disaster area. The people involved in the crowd-sourcing aren’t directly helping in the sense of actually rescuing people, but their mediation between people on the ground is providing a valuable set of “eyes and ears” for everyone involved.

The Dirty Details

In practice, this process is a lot more chaotic than it seems, which creates new problems that need solving. For instance, while I’m very used to Google Maps containing highly accurate data about where I live, many of the cities, towns, roads, and other places mentioned in reports from Pakistan either aren’t visible on Google Maps at all, or are known by multiple names, depending on language and locale. Because of this, one of the ways people familiar with the disaster area can help is by using OpenStreetMap, a sort of cross between Wikipedia and an atlas, to add information about places that conventional commercial sources don’t contain.

While I was at CrisisCamp SV, one of the technical problems that needed a solution was the fact that Facebook was reportedly much more popular than Twitter in Pakistan; relief workers on the ground wanted to be able to tell the public that they could join a Facebook group and post their reports on its wall, but they didn’t know how to import the data from the wall into the site that processed raw reports, so I wrote a simple Python script to convert the wall data into an RSS feed using Facebook’s Graph API.

Crowd-Sourcing and Communities of Practice

The interesting thing about my contribution is that it was just one possible solution to a problem: humanitarian agencies on the ground didn’t actually know if posting to a Facebook group’s wall would be a solution that the population would use, but just having a solution available was better than complete uncertainty. I don’t typically write code when I have a low degree of confidence that the code will actually be useful to someone, but I nonetheless decided to write it up.

In general, a number of people I talked to at the CrisisCamp had a less-than-ideal degree of confidence that their individual contribution was providing concrete aid, but there was a lot of faith in the sum of what everyone was doing as a whole, the belief that people on the ground would benefit immensely from this crowd-sourced radar we were creating.

I’ve typically been very skeptical of the term “crowd-sourcing”, primarily because its use in language has a tendency to abstract away the notion of human individuality: people become fungible processors or gadgets that are doing things that we simply haven’t figured out how to do with computers yet. In a lot of ways, the language surrounding it dehumanizes us in the same way that assembly lines and mass production dehumanized the nature of work during the industrial revolution.

From this perspective, one of the greatest strengths of events like CrisisCamp, and organizations like CrisisCommons, is their ability to provide group membership, to create meaningful connections between people who want to help, and to create new kinds of communities of practice. If I hadn’t attended the CrisisCamp event, I certainly wouldn’t have written that Python script, but because of the social context—the notion that I would be creating something that could be recognized by people with similar interests and lead to connections with them—I found a lot more meaning in it than I otherwise would. This is, of course, the same kind of motivation that engages people to volunteer, to create resources for their World of Warcraft guild, or to contribute to an open-source project.

How Mozilla Can Help

A few days ago, Mitchell Baker wrote a blog post in which she wondered how Mozilla could help with humanitarian crises. One thing I noticed about the chaos surrounding the Internet-based efforts was that, like Mozilla, they were formed very organically: this meant that there were a plethora of activities going on which anyone could participate in, but the picture presented to a newcomer was confusing and messaging wasn’t always consistent. Tasks needed to be completed urgently; the changing landscape on the ground meant that problems and solutions were constantly changing, and assumptions were frequently challenged. Keeping the Web in-sync with reality could be difficult, especially since the Web doesn’t forget things.

Combined with the distributed nature of the solution, acquainting newcomers with a reasonably humane workflow for contributing was non-trivial: just processing a report on pakreport.crowdflower.org, for instance, often meant switching between tabs containing getlatlon.com, OpenStreetMap, and a Google Docs page containing advice and other resources. There was a lot of copying and pasting involved.

There’s many ways browsers could help with this. For one thing, addons or GreaseMonkey Scripts could make the experience of contributing easier. While I didn’t get around to it, for example, I could easily imagine an addon or Ubiquity command that mashed-up pakreport.crowdflower.org with getlatlon.com, OpenStreetMap, and other services to provide a streamlined interface, potentially eliminating the need to learn how to use those other websites and copy/paste. In other words, since the solution to these problems is on the Web, we can use the inherent hackability of the Web to make the solutions much easier to use.

Another thing I noticed was that the vast majority of browsing activity occurring while helping out was largely privacy-insensitive: reports were submitted from the ground with the expectation that they would become public, the CrisisCommons wiki was completely public, as was any activity on Twitter or even the Facebook group. There was also a lot of link-sharing and people looking at one another’s screens as they figured out workflows and discovered solutions, so the notion of a sort of “public browsing mode”, or perhaps a separate browser tweaked to broadcast all its activity to the internet or a specific group of people, is an interesting one.

Aside from that, some of the affordances present in the Mozilla community and other open-source projects seemed like they could help the CrisisCommons efforts a lot. As far as I could tell, for instance, there wasn’t any kind of real-time virtual space or chat room where the community could hang out. There also wasn’t any kind of issue tracker, which seemed like it could be useful, too.

In any case, CrisisCamp SV was a really interesting experience, and I’m looking forward to attending more events like it.

Early this year, I had to start using Mozilla’s Bugzilla, an issue tracker that, while incredibly powerful, nonetheless confused and intimidated me to no small degree.

One of my most basic needs was to have a simple display containing bugs of interest to me. I couldn’t find a page in the product that satisfied me, so I used Gervase Markham’s excellent Bugzilla REST API to create an HTML page that fetched the information I needed and displayed it.

The page is designed to be read from left to right, with the most important information appearing earliest. The first column, Things to Review, contains patches and other artifacts that I need to provide feedback on—it’s most important because it’s blocking other people from getting their work done. The next column, Assigned Bugs, contains items that I’ve elected to work on. The columns continue through Reported Bugs (open issues I’ve reported myself), CC’d Bugs (open issues I’m interested in), and finally Recently Fixed Bugs, which contains resolved issues from any of the previous columns that have been closed in the past week. Issues that might appear in two columns, such as a bug I reported and assigned to myself, appear only in the more important column to avoid redundancy.

I’ve also added a few features on the panel at the top-right corner of the page to help with some other pain points of Bugzilla that I ran into: Find A User makes it easier to locate someone in the system and view their dashboard, while File A Bug makes it easier to file a bug when you don’t know what product or component it belongs to.

The page, which a number of friends and coworkers have been using for the past several months, is now hosted on GitHub:

Feel free to use it. Since it’s all client-side HTML, CSS and JavaScript, you can also easily fork it and tinker with the code. Please file a bug if you find any.

One of the most interesting uses I’ve found for this tool is actually to get a bird’s-eye view of what other people are working on. At the login prompt, you can type any email address and leave the password field blank to see the public bugs that someone is subscribed to, which makes it an excellent window into Mozilla’s mostly-transparent ecosystem. For instance, here’s what I’m working on.

Earlier this year I read Don Norman’s Emotional Design, and I’ve been reflecting on some of the reasons I decided to start using Firefox back in 2004.

When I hear most people talk about why they used Firefox, they sound pretty rational. They liked Firefox because it stopped pop-ups; it had tabs; or because it was faster than Internet Explorer.

My recollections of my first impressions of Firefox involved some of those things, but I mostly remember having a positive emotional reaction to the product. I’d always supported the mission of open-source software, for instance, but I’d never actually used any open-source software that acted like it wanted to help people who weren’t computer experts. There were a number of cues that indicated this, from the adorable yet professional logo of a firey-tailed fox hugging the world to a clean, simple, and unintimidating user interface.

Don Norman might call this a combination of visceral and reflective responses to the product I was using: “shallow” qualities that are usually associated with marketing rather than usability. Yet they changed the way I used the software, by making me actively want to use it, and not in the same way I used Internet Explorer. I feverishly explored all its dialogs and add-ons and learned everything I could about this new gem I’d stumbled upon. I’d just been a user of Internet Explorer—but with Firefox, I was a fan.

Early in his book, Norman states:

We have long known that when people are anxious they tend to narrow their thought processes, concentrating upon aspects directly relevant to a problem. This is a useful strategy in escaping from danger, but not in thinking of imaginative new approaches to a problem. Isen’s results show that when people are relaxed and happy, their thought processes expand, becoming more creative, more imaginative.

These and related findings suggest the role of aesthetics in product design: attractive things make people feel good, which in turn makes them think more creatively. How does that make something easier to use? Simple, by making it easier for people to find solutions to the problems they encounter.

In short, the social, cultural, and artistic context surrounding a product has a lot to do with its usability. If a product’s context is constructed such that users are positively engaged when they start using it, then it actually becomes more usable.

Today, one of my favorite examples of empathic design in Firefox is actually the title of an error page:

A comment in Firefox’s source code provides the rationale for this:

The title is intended to be apologetic and disarming, expressing dismay and regret that we are unable to restore the session for the user.

The very notion of trying to express dismay and regret is extremely rare in computer software. I love it, as the few times I’ve seen it, the disarming has worked—it’s made me chuckle out loud, and the humor conveyed immediately reminds me that I’m using software created by fallible human beings who care about my data. This sort of affective design needs to be done extremely carefully, since it could easily backfire and come off as ingenuine or patronizing—but in my opinion, it’s worth the effort.

Context offers fodder for innovation. Hidden in the physical work space, in the users’ words, and in the tools they use are the beautiful gems of knowledge that can create revolutionary, breakthrough products or simply fix existing, broken products.

I’ve been talking with my colleague Jinghua Zhang, the project lead for Mozilla’s Test Pilot program, about the usefulness of ethnography and qualitative research in user interface design, and it seems like something that could both strengthen Mozilla’s community and help make our products easier to use.

A few months ago I picked up Hanging Out, Messing Around, and Geeking Out, a book in the John D. and Catherine T. MacArthur Foundation Series on Digital Media and Learning, which contains twenty-three ethnographic case studies on how young people are “living and learning with new media.” The studies span an impressive variety of socio-economic groups and social contexts, and nearly all of the interactions that take place in these studies are mediated through a web browser—so I thought this might be a useful opportunity to learn more about our users.

One Example: Techne-Mentoring

While I haven’t yet finished reading the book, one of my favorite case studies so far is Megan Finn’s section on “Techne-Mentoring”. As I’ve explained in my post on Kids and The Open Web, when I was wee, learning about computers was very much about creating and hacking on things that I could share with my friends and parents. Computers were mostly a hobbyist’s toy.

Today, however, the computer is an indispensable information appliance that everyone needs to use. It’s also constantly beset with viruses, bugs, and design flaws that confuse and frustrate people. Finn’s study on Techne-Mentoring focuses on this when she asserts that many young people interested in technology gained their expertise not necessarily by creating or remixing things, but by learning how to get rid of viruses on their families’ computers, or learning how to work around some other technical problem. This knowledge becomes a valuable social asset, allowing the individual to become an informal mentor in their family or peer group.

This got me thinking: the primary gateway to messing around with advanced features in Firefox is the about:config page, which we currently caveat with this dire warning:

If a young person who’s fixing their family’s computer is seeing this screen, why not take this opportunity to invite them to share their expertise with our vibrant support community? Community is, after all, one of Mozilla’s strongest assets, so it may be useful to link to it at relevant touch-points in Firefox’s user interface.

Going Further

We can get even more meta: how awesome would it be to actually help our community members become amateur ethnographers, doing things like observing and interviewing their friends and family to help Mozilla learn more about its users and design better products? Maybe it’s a crazy idea, but ethnography does seem like an incredibly useful asset for interaction design, and I’m eager to learn more about it.

I’ve heard some talk lately, primarily from Henri Sivonen, regarding whether Google’s notion of an Installable Web App is “webby”.

I am not sure exactly what webby means, but if I had to guess, it would involve the kinds of qualities that Mitchell Baker and Mark Surman believe make the web better: more transparent, participatory, decentralized, and hackable.

Though I’m not fully sold on these newfangled apps, I can think of three ways that they could make the web better.

The Usability of Files

At first glance, one might say that putting some web pages and scripts into a ZIP file marginally reduces transparency, as one now has to unpack it to see the original code.

However, this simple mechanism addresses a significant barrier to web development that isn’t often captured by web standards: casual developers intuitively understand files because—for better or for worse—they’re something that’s an integral part of the way one interacts with their computer from day to day. The notion of creating some files on one’s computer and making them available to the rest of the internet is reasonably simple and profoundly powerful. The operative metaphor of a ZIP file—putting a bunch of files into a little box that can be delivered as a single file and unpacked later—isn’t hard to understand once one knows what a file is. While it’s a bit of a hassle to put things into the box and unpack them, most operating systems already offer tools to make this easier for ordinary users.

Introduce the notion of HTTP Response Headers, however, and barriers start to appear: this is a completely different concept from files, requires an understanding of the Hypertext Transfer Protocol to not be completely mysterious, and requires learning the particularities of tools that one may not even be aware that they’re using.

Dump some files onto a server and you don’t even need to care whether that server uses Apache, Microsoft Internet Information Services, Lighttpd, or something else. Add a requirement to a Web standard that an arbitrary file be served with a special MIME type via an HTTP header, however, and suddenly a casual Web developer has to become aware of an entirely new layer of technology that they were previously blissfully unaware of.

The reason I mention this is because there are at least two different web standard proposals I know of that involve the use of ZIP files to make it easier for casual developers to participate in the web and make it better. One of them is Alexander Limi’s Resource Packages specification, and the other is Google’s proposal for Installable Web Apps. Both of them involve taking things that are currently arcane—configuring a web server to automatically serve files with compression over a keepalive connection and serving an offline web application with a cache manifest of type text/cache-manifest, respectively—and make them easy and understandable for non-professionals.

With some browsers already capable of introspecting into ZIP files, the effectiveness of View Source—the enabler of transparency and hackability—need not be reduced. In fact, it could even be increased: if putting JavaScript into a compressed ZIP file reduces its size enough to make minification less of a necessity when it comes to delivering Web content quickly, then more web content will be delivered in way that others can learn from and remix.

Untethered Applications

Google’s proposal for Web Apps actually makes the internet a more decentralized place, because it contains provisions for creating and sharing entirely serverless, untethered applications. Using the terminology of Jonathan Zittrain, this makes it easier for control to be transferred to the endpoint that users are (hopefully) in control of. That said, there are other proposals that could technically enable similar use cases, such as Brandon Sterne’s excellent Content Security Policy.

Webs of Trust, Not Heirarchies

Another area in which Installable Web Apps could decentralize the internet has to do with the field of trust. It’s currently very difficult to actually prove that a piece of Web content or functionality I created came from me, and wasn’t altered at some point by someone else. The only viable way to do this is via Secure HTTP, which requires asking an authority for permission to issue you a certificate. That this frequently involves paying them money and that the system is susceptible to corruption are besides the point. As Mark Surman mentions in a draft of Drumbeat’s mission statement:

Ultimately, our goal is a strong, safe open internet: an internet built and backed by a massive global community committed to the idea that everyone should all be able to freely create, innovate and express ideas online without asking permission from others. (Emphasis mine)

It should be possible to prove to other people that something came from you without having to ask permission from someone else, and in this respect, even though this mechanism is part of the Web, I would argue that it is profoundly un-webby. Google’s proposal for Installable Web Applications associates an application’s identity with a public key that doesn’t require a blessing from any kind of authority; all versions of the application are self-signed by the key, which makes it far easier to establish trust between a user and an application. The trust model is also more granular and secure, because it creates a trust relationship between the user and the particular application they’re using, rather than the server they’re connecting to—which often isn’t even under a web developer’s full control. It’s because of this that we’re using a similar mechanism in Jetpack; extending it to the entire Web would be very webby, not coincidentally because it establishes a foundation for what could eventually become a web of trust.

Conclusion

While I’m still on the fence regarding whether Google’s proposal for Installable Web Apps are the best solution for a better Web, I do think that they’re a step in the right direction. In particular, they address social issues and usability concerns that, if resolved, will make computing life more transparent, participatory, decentralized, and hackable for everyone.

I recently wanted to create a short, two-minute and thirty second “pitch” for the Herdict-Firefox integration prototype I’m working on with Jennifer Boriss, Laura Miyakawa, and Jeffrey Licht.

Here is the result. It turned out that the pitch itself was an experiment for me: after fiddling around with Screenflow and iMovie for a bit, I got frustrated with their limitations and decided to just use HTML to put together the presentation.

After writing out the script for the pitch, and recording my narration with Audacity, I saved the file as both Ogg Vorbis and MP3—different browsers support different formats—and set up a directory structure.

As with Mozilla: The Big Picture, I basically stuffed everything into the structure of an HTML page. The first two slides of the presentation, for instance, look something like this:

  <div id="slides">
    <div data-at="0.0">
      <a href="http://www.mozillalabs.com"><img
         id="logo" src="images/labs-logo.png"/></a>
      <h1>Firefox-Herdict Integration Pitch</h1>
    </div>
    <div data-at="4.0">
      <img src="images/server-not-found.png"/>
    </div>

The data-at attribute is an example of the HTML 5 data- attribute and records how many seconds into the audio the slide should be displayed. I marked up subtitles for the presentation in a similar way.

After that, I wrote some JavaScript that just attaches a timeupdate event listener to the presentation’s audio element and synchronizes the current slide and subtitle to its position. The result is something that looks and feels to an end-user like a YouTube video—one can even “scrub” the position slider to quickly rewind and fast-forward. However, I’d argue that this approach is actually superior to standard video in a number of ways:

1. Slides can have any valid HTML content embedded in them. Text can be copied and pasted, their look and feel can be altered through CSS; images can be hyperlinked to their original sources.
2. It’s easier to eliminate compression artifacts without sacrificing bandwidth and download size. Text, for instance, is always super-crisp.
3. Since everything uses HTML, CSS, and JavaScript, anyone can view-source or use a web inspector to investigate how things are put together; as I explain in The Open Web is Magic Ink, they can take it apart, see how it works, and put it back to together in a different way. Doing such things with a pure bitmapped video representation wouldn’t be possible: you’d need the source “project files” for whatever program was used to compose the video, not to mention access to said program.
4. Subtitles can be toggled on or off, and adding new languages isn’t hard.

This approach has its downsides, too, of course: there wasn’t a really easy way for me to embed the presentation in this blog post, for instance, and it can’t be viewed at all on Internet Explorer, as far as I know.

Still, it was a fun experiment to try, and for this particular use case I actually found it easier to compose everything using Open Web technologies than with the proprietary tools at my disposal.

Please be sure to check out the actual presentation, too, as the stuff we’re doing with Herdict is way cool.

Every time I think about why I like the open web, I basically think of how well it fits with the way I learned to use and program computers as a kid: my first computer, an Atari 400, came with everything I needed to do programming, and I (or my parents) didn’t have to spend hundreds of dollars or sign an NDA to get a development tool.

My favorite technical book as a child was Creating Adventure Games On Your Computer, which contained plain BASIC code for games that you could play, augment, and make your own. A column in one of my favorite magazines, 3-2-1 Contact, featured the same kind of content.

All of this was easy enough for a child to grasp—often far easier, as Jef Raskin observed in The Humane Interface, than today’s development tools. But being able to use a tool that provided an incredibly low barrier to generativity is something that I value a lot about my childhood. It’s in part where a lot of the real passion and excitement for open source and the Open Web come from: people like me see in them the qualities that made them truly excited about computers as a kid. Qualities that we’re constantly in danger of losing today as the field becomes more professionalized and controlled.

So that got me thinking about Drumbeat again: what if promotional materials for the Open Web focused on how it makes lives better for children who are budding hackers? Lots of adults aren’t tech savvy, but they know that their kids are, and if we can prove that the Open Web is better for their kids, and that they can make their kids’ lives better by choosing a standards-compliant browser, maybe they will.

After playing around with this idea for a bit, I came up with this:

The photo on the page is taken from Flickr user .sick sad little world.’s The Taste of Ink. Feel free to get the source and remix!

Over the last two weeks, I gave two tutorials to our Design Challenge students.

The first was called Engineering Prototypes, and centers on the most challenging part of working on prototypes for me, which is the balance between expediency of implementation and robustness. Prototyping involves prioritizing the former over the latter, but it’s unwise to throw engineering principles out the door: for instance, a prototype that constantly crashes or runs slowly may not be usable enough to dogfood, and one whose implementation is poorly designed can be difficult to iterate and evolve. My tutorial attempts to present some of the factors one should take into account to produce prototypes that are both quick to implement and robust enough to dogfood.

The other session was called Prototyping with jQuery but it included a heavy dose of Firebug as well.

For the second session, I created a prototype of something that I’ve wanted to make for a while: Open Web Challenges.

These are essentially a series of interactive web-based problems that require “hacking the page” using real-world tools to solve. They’re inspired by a number of my favorite pedagogical dilemmas, such as the time someone in LambdaMOO made me program my way out of a paper bag; the inventive exercises from Graham Nelson’s Inform Designer’s Manual 4th Edition; the labs from Bryant and O’Hallaron’s Computer Systems: A Programmer’s Perspective; and the mathematical proofs from Carol Schumacher’s Chapter Zero. Obviously, being a one-day hack, these Open Web Challenges pale in comparison, but the prototype was fun to build and I’d like to continue creating more interactive exercises like this.

All in all, I thought the Design Challenge was an awesome opportunity for students around the world to learn more about open-source design and development, as well as a great way for Mozilla folks to get a chance to talk to students, teach, and obtain a better understanding of what we need to do to make the Web as a platform easier to learn. If you’re interested, I recommend checking out the rest of the tutorials at design-challenge.mozilla.com/spring09.

I’d also like to thank Pascal Finette for putting the Design Challenge together—it’s unquestionably a success and I’m looking forward to participating in more Mozilla Education projects in the future.

We want to make Ubiquity awesome at reporting errors. In our original release, a transparent message with JavaScript exception information was displayed, which wasn’t very useful to the average user, and was downright annoying when dozens of exceptions were logged in the same instant.

At present, running a command that raises an error just results in that message being logged to the JS Error console, which very few people know how to access—so most people are left scratching their heads and wondering why their command is taking so long to run.

For the next release of Ubiquity, we’re going to be trying something more user-friendly: if a command encounters an error, a transparent message will be displayed telling the user that it didn’t work. The message will also recommend using the “report-bug” command to send information about the bug to the Ubiquity team. If the user decides to run this command, a page is opened that looks like this:

Aside from inviting the user to describe their problem, a lot of information is included about their system: what OS they’re using, what extensions and plugins they have installed, what recent exceptions were thrown, and so forth. We’re hoping this will lower the barrier to entry both for receiving and providing technical support, since most of the information needed to describe and investigate a problem is contained in a single link.

We don’t yet have an interface for browsing existing bugs, but we do have a display for viewing them. It looks pretty similar to the page for submitting a bug:

One interesting aspect of our bug reporting system is that we’re not using numbers to identify bug reports: they get big fast as many reports are submitted, and big numbers are hard to remember. Instead, we’re mashing two random words from the dictionary together. For instance, the first bug I reported using this system was called anaphorically-spinach.

Under The Hood

The bug reporting system is pretty lightweight: mostly it’s just static HTML/JavaScript code that talks to a web service that’s implemented in under 100 lines of Python. The actual bug report is just a JSON object, and is deposited into a CouchDB server.

The big advantage of using CouchDB here is that we’ll be able to easily create really rich queries using plain old JavaScript. For instance, here’s a query that shows all reported error messages that contain the text “Invalid chrome URI”. It won’t be hard to create complex queries that, for instance, give us all the bug reports in which the user had a certain extension installed and had a command crash at a particular line in a particular file.

A Public Asset

Right now all reports are submitted to the public domain, and as such the report database is a public asset; users are informed of this before they submit the bug, and encouraged to look at the additional data that’s being sent with their report to ensure that there’s nothing sensitive in there. In the future, it’d be nice to allow the user to click on any parts of the data that are personally identifying, so that they can submit a version of the report that masks out the sensitive information.

Reuse

The bug report system has been designed to be decoupled from Ubiquity itself. For instance, the report viewing application is designed as a reusable JavaScript component, so it should ultimately be easy to embed into any web page. In other words, it should be easy to use as a bug reporting mechanism for any Firefox extension—and possibly for any web application in general. If you’re interested in adding the component to your own project, please let us know; the code is still a work-in-progress, and any contributions or comments are appreciated.