The Emotional Design of Firefox

August 12th, 2010

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.

Ethnography, Usability, and Community

May 30th, 2010

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.

—Jon Kolko, Thoughts on Interaction Design

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.

On The Webbyness of an Installable Web App

May 26th, 2010

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.

The Paradox of Choice

March 1st, 2010

I wanted to quickly illuminate what one might call the flip side of the Open To Choice campaign, which is summarized by this Publishers Weekly review of Barry Schwartz’s The Paradox of Choice (2004):

Like Thoreau and the band Devo, psychology professor Schwartz provides ample evidence that we are faced with far too many choices on a daily basis, providing an illusion of a multitude of options when few honestly different ones actually exist. The conclusions Schwartz draws will be familiar to anyone who has flipped through 900 eerily similar channels of cable television only to find that nothing good is on. Whether choosing a health-care plan, choosing a college class or even buying a pair of jeans, Schwartz, drawing extensively on his own work in the social sciences, shows that a bewildering array of choices floods our exhausted brains, ultimately restricting instead of freeing us. We normally assume in America that more options (“easy fit” or “relaxed fit”?) will make us happier, but Schwartz shows the opposite is true, arguing that having all these choices actually goes so far as to erode our psychological well-being.

I haven’t actually read this book, mind you, but this feeling of being “overwhelmed by choice” is an experience I’ve faced daily as a consumer in America. I’m not sure how prevalent it is in Europe, where the Windows 7 browser ballot is being presented to users.

My first thought when I’m confronted by choices that I don’t fully understand—cars, for instance, since I’m not a car person—is to find some kind of primer that tells me what the salient differences between the choices actually are. As some have noted, browsers actually look quite similar to each other, and many of the most important features are shared between them.

I haven’t actually been able to find such a primer online, though. I’m not even sure if many others would find such a thing useful. In any case, I just wanted to bring up this issue that some might face: Okay, I have choices when it comes to browsers, but they all look the same to me. Now what?

Is there something the Mozilla community can do to help them decide? Or is that not the place of the Open to Choice campaign?

You Are Not a Gadget

February 15th, 2010

This is what a social network looks like.

Each dot represents a human being. Each line represents a social connection between two people, such as acquaintanceship, financial exchange, friendship, or love. The picture can become arbitrarily more complex as we take one-way relationships into account and add more dimensions to model particular interests and behaviors.

Much of the attention around technology these days has something to do with this picture. Authors like Clay Shirky write about amazing things that can happen when the amount of effort needed to transmit information through the lines is drastically lowered. Companies like Google harvest information from the dots to offer better services to them; products like Amazon’s Mechanical Turk harvest little slices of spare time from the dots to quickly complete otherwise unwieldy tasks; games like Zynga’s Farmville are designed to propagate through the lines like a virus.

Advertising companies and some advocates of open-source software don’t even refer to the dots as human beings: they call them “eyeballs”. The involvement of just one pair of eyeballs means just a few cents to a revenue stream or a single bug-fix in a software program, but when the process is scaled, it results in billions of dollars of profits or bug-free software.

Jaron Lanier, the author of You Are Not a Gadget, is not interested in dots and lines. Indeed, he finds it strange that the relationship between two people is reduced to a mere line, and that the people themselves are just dots.

Instead of reducing things, he claims, we should be using technology to deepen the connection between two people and make it more meaningful.

You Are Not a Gadget is a complex book. I originally bought it because, flipping through its pages at a bookstore, I found random fragments to offend me. Even though I don’t agree with everything the author has to say, I still found it a fascinating read that I’d recommend to anyone with an interest in technology and where it’s taking us.

Herdict-Firefox Integration and Better HTML Presentations

February 10th, 2010

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.

The Value of Nothing

January 17th, 2010

From what I’ve read of Tim Harford’s The Undercover Economist and The Economist, capitalism seems like a reasonable way to make the world a better place, given its assumptions of human nature. In particular, America’s brand of capitalism, which tries to lower the barriers to getting a job or starting a business as much as possible, seems compatible with notions of liberty and democracy.

I just finished reading The Value of Nothing, which provides a fascinating counterpoint to all of this. Its author, Raj Patel, doesn’t hate markets—he just wants to pluck from them “the overriding hunger for expansion and profit that has brought us to the brink of ecological catastrophe”. He also believes that what needs to be plucked from us is “the belief that markets are the only way to value our world”.

This last quote is something that resonates with me. Some of today’s most prolific companies rely on what I find to be odd business models: they make the money they need to survive as a fortuitous “side effect” that is relatively independent of their utility to the vast majority of their constituents. Firefox, for instance, relies on a sharing economy—open-source, community-driven development—to build a product that is mostly financed through something that few people are even aware of: the ads that a tiny percentage of users click on after performing Google searches at the upper-right hand corner of their browser.

These sorts of tactics strike me as clever “hacks” to capitalism. Obviously creating a browser like Firefox and making the Web a better place is something a lot of people value—yet this value isn’t really captured by the market.

The Value of Nothing is an exploration of alternative ways of valuing ourselves and our world, from Free Software to Food Sovereignty. Coincidentally or not, many characteristics of these alternatives—they are all transparent, participatory, and de-centralized—happen to share a lot in common with what makes the Web better.

Evolving Firefox Extensions

January 11th, 2010

Firefox’s extension platform is incredibly powerful and generative, but when I created my first extension in early 2008, I found a number of barriers to entry—difficulties echoed by a number of other newcomers I talked to.

For one thing, extensions were difficult to get started with. Perhaps the best indicator of this is Myk Melez’s video tutorial titled Extensions Bootcamp: Zero to “Hello World” in 45 Minutes, which actually ended up being 90 minutes long.

In May of 2009, we tried to resolve a number of issues for newcomers with our original Jetpack Prototype. The complex (but powerful) Gecko API was hidden behind a much simpler facade; no tedious setup was required to get up and running, and the effect of changing any part of your code was nearly instantaneous, obviating the need for restarts when developing or even installing a new Jetpack. Familiar, well-documented technologies like HTML and CSS were used to build interfaces.

Yet there were a lot of things lacking in this prototype. For one, Jetpacks created by developers required the Jetpack extension to be installed in order to use them. There was no mechanism for code sharing and reuse—not even any kind of packaging system, which made building on another person’s work or creating more complex Jetpacks very cumbersome. It also had no security model, which meant that Jetpack developers were effectively playing with a loaded gun: a single mistake in a Jetpack’s code could actually blow a security hole in Firefox that might expose the user’s computer to all kinds of threats from the web.

We wanted to fix all of these problems, but the one that presented the most challenge to us was that of solving what Jonathan Zittrain calls The Generative Dilemma: is it possible to make Firefox Extensions safer without compromising generativity? The sheer inventiveness of the Add-on Community—NoScript, Adblock Plus, Greasemonkey, and the tens of thousands of other add-ons out there—never would’ve been possible if Firefox’s extension platform wasn’t as powerful as it is. Enforcing some kind of “top-down” security model on Jetpack that told developers what they could and couldn’t do simply didn’t feel right.

Instead, it felt like a better solution would be to create the conditions for a secure platform and allow anyone to create capabilities that securely expose privileged functionality to it. Such capabilities, or superpowers as we sometimes call them, can expose any part of the Mozilla platform—which means that it’s theoretically possible for a Jetpack to do anything that a normal extension can do, while still obeying the Principle of Least Authority.

There’s a number of other features present in the latest in-progress iteration of Jetpack, which we’re calling the “reboot” because rebuilding it from the ground-up with the new goals in mind was much easier than continuing to hack on prototype code. We’re now using the CommonJS standard to make it easier to reuse code between Jetpack and other JavaScript-based platforms like the Web and narwhal, for example; Jetpacks are also now fully self-contained XPIs that require nothing but a Mozilla-powered application to run.

There’s a lot more to the reboot, but it’s all a little overwhelming to write up in one blog post. This is an indicator that I should’ve started blogging about this a lot earlier than today, and I apologize for that.

While the reboot is still in-progress and won’t be ready for “prime time” for quite a while, you’re welcome to check out the in-progress Reboot Quickstart and the various JEPs it links to. Please feel free to leave comments on this blog or post them directly to the Jetpack Google Group.

Mozilla: The Big Picture

December 13th, 2009

I realized over the past year that the Mozilla community doesn’t just generate cool software—it actually produces a wealth of great visual assets, too.

I thought it’d be useful for both folks on the periphery and on the inside to use images as a way of understanding what’s going on at Mozilla—sort of like about:mozilla, but using pictures instead of words.

Here’s what I’ve got so far:

This prototype is a showcase of what happened in the Mozilla community during the month of November 2009. It includes community-created artwork, photography, screenshots, logos, and UX sketches and mock-ups. Mousing over each thumbnail displays a high-resolution version of the image on the lower half of the screen, dynamically fetched to take advantage of the viewer’s screen resolution without wasting network bandwidth.

The mini-gallery is stored using an ad-hoc sort of HTML microformat. Feel free to take a look at the source code and reuse or remix it for your own purposes.

(A word of warning: I’ve only tried out this prototype on Firefox 3.5 and Safari 4.)

Web Application Memory Profiling, Take Two

October 6th, 2009

Back in July, the Mozilla Developer Tools Lab released an experimental memory tool that allowed a web developer to get a better picture of Firefox’s memory usage. That tool was a great start, but it had a few issues:

  1. It was slow.
  2. It showed the entire Firefox JS heap, which included lots of objects internal to Firefox that weren’t of much use to web developers.
  3. It was a bit of a hassle to set up, as it involved freezing Firefox and accessing a local web server from a different browser.

I’ve spent some time trying to resolve these issues, and have a usable prototype for Firefox 3.5 that you can try out. The new tool has an entirely different front-end from the last one and runs in Firefox itself—no need to launch a separate browser. It also runs a lot faster, and allows you to profile the JavaScript memory use of individual browser tabs.

Here’s a screenshot. You can also click on it to read some annotations I’ve added through Flickr:

The above profile was taken while this page was open in a tab. Feel free to look at the page’s source code and compare it with the profiling output.

One of the first things you’ll notice is that there’s no information about actual bytes used. This is partly because we need to add more instrumentation to Firefox in order to get you really accurate information about that—something that’s currently being done with the advent of about:memory. But it’s also because raw byte counts aren’t necessarily helpful in debugging memory leaks in web applications: what’s really useful is information about what kinds of objects are staying in the page, which this new iteration of the memory tool tries to provide.

If you’re interested in learning how the tool works or hacking on the code, check out the wiki page and my Fun with SpiderMonkey blog post.

What I’m really interested in knowing is: do web developers find this useful? What could be added to it to make it more useful in diagnosing the memory use of a web application? If you’re a web developer, please download the addon, choose “Memory Profiler” from the “Tools” menu in Firefox, and let us know what you think!