2010 May Archive at Toolness

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.

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.