Michelle Levesque recently wrote a post about the importance of play in learning.

We need to change people’s mindsets to make them comfortable fooling around, making things, breaking things, and playing on the web.

I totally agree. This is one of the design goals of the Hackasaurus tools and events, actually—it’s a combination of stylistic touches and emotional design to help people feel that what they’re doing is fun, along with humane functionality that makes experimentation easier, such as infinite undoability.

This is something I feel that Apple has managed to do with their products, too: I see non-technical people like my father who are typically terrified of using their personal computer take joy in installing apps on their iPad and playing with them in a way that they never would have dared to do on their PC. Partly it’s due to concrete features, like the fact that it’s impossible for an app to impair the behavior of another app—but it’s also partly due to stylistic touches, like all the device’s glee-inspiring animations.

It’s ironic that tech-savvy folks like me berate the iPad for its lack of generativity and hackability, yet it manages to orient its users towards a sense of playfulness and empowerment in a way that other tools rarely have.

I recently made The Parable of The Hackasaurus, which is a game-like attempt to make web-hacking easy to learn through a series of simple puzzles in the context of a story.

The parable is really more of a proof-of-concept that combines a bunch of different ideas than an actual attempt at interactive narrative, though. The puzzles don’t actually have anything to do with the story, for instance. But I wanted an excuse to do something fun with the vibrant art that Jessica Klein has made for the project, while also exploring possibilities for the Hack This Game sprint and giving self-directed learners a path to understanding how the Hackasaurus tools work.

If you know HTML and CSS, you’re welcome to remix this and make your own “web hacking puzzle” where the goggles are the controller. Just fork the repository on GitHub and modify index.html and bugs.js as you see fit. Almost all the puzzles, achievements, and hints are data-driven and explained in documentation, so you don’t actually need to know much JavaScript.

For more information on my motivations in creating the parable, check out the experiment’s README. Jess is also thinking about making an interactive comic that teaches web-hacking, which I’m looking forward to.

The URL is a very powerful concept; it represents a universal way to access any resource anywhere in the world. Here’s one of them, as it appears in Firefox 5′s address bar:

The first few letters before the colon are called the protocol, which tells the computer how to interpret the rest of the URL. The http protocol is the most common and specifies a resource on the World Wide Web, while the tel protocol specifies a telephone number, and https specifies a resource on the Web transferred over a secure channel that can’t be eavesdropped. Those are just a few; there’s lots of other ones.

Many user interface designers for browsers believe that most users don’t understand what a protocol is, which is probably accurate. Google Chrome’s solution is to hide the protocol when it’s http, but to display the protocol in all other cases. Firefox is now adopting the same behavior.

There’s a number of things that trouble me about this approach. I’ve already written about the behavioral impacts, whereby user expectations of copy-paste are broken and a confusing mode is introduced. Furthermore, because protocol information is still displayed for any non-http resource, understanding how to read the address bar is (ironically) made more complex.

Aside from those concerns, however, there’s something else I’m worried about. The main argument I’ve heard against exposing protocol information to end-users is that, if we present it, we might as well present all kinds of other information about the TCP connection, CPU registers, and other obscure technical statistics.

Now, I know I’m biased because I’m on the Hackasaurus team and trying to teach people the basics of HTML and CSS, but browsers have historically been very friendly to learning web-making, in part because they keep protocol information in the address bar. My guess is that removing the http:// neither helps nor hinders someone from using the basics of the web—but it definitely makes it harder to learn what hypertext is.

Understanding technology is relative. Someone can know the basics of writing an anchor tag without knowing what TCP/IP is, and it’s still quite empowering, in much the same way that it’s empowering to know how to grill vegetables without necessarily knowing everything about the chemical reactions taking place underneath.

Doing little things in the interface that promote transparency and help people move from being a web-user to a web-maker is important, so long as we don’t make things difficult for the people that just want to be users. I’ve never found my parents or other non-technical users to be confused by the presence of http://, which is part of why I don’t see much gain in removing it—especially given the behavioral shortcomings of this change. Far more exciting to me is the exact opposite approach: designing experiences to help users understand what the URL in their address bar means, and encouraging them to create things on the Web instead of just browse.

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?

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.

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.

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.

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.