Michelle Levesque is tearin’ it up with her rapid pace of blogging and it’s inspiring me to blog more myself.

Yesterday in her post Things I Have Done, she ruminated on different kinds of categories for achievement badges.

I personally have conflicted feelings about badges, and sympathize with something Jessica Klein mentioned in a blog post a few months ago:

My colleague Jack Martin and I participated in this local learning incubator where we told a story with twitter. It was a fantastic and fun day and we loved what we made just as much as we did making it. However, after the activity was over, a learning assessment team came over during our presentation of our story and gave us badges for our story. It somehow cheapened the experience that Jack and I had and sort of reminded me that, yeah this was about learning and grading–not the fun experience.

In Freakonomics, Steven Levitt and Stephen Dubner describe an Israeli day care center which decided to start imposing a fine on parents who arrived late to pick up their child. Rather than reducing the frequency of late pick-ups, however, the opposite occurred, because a moral incentive was replaced by a financial one. The fine made picking up a kid late suddenly seem perfectly acceptable (yet costly), rather than negligent.

This is my main concern with achievements of any kind: they have the ability to twist existing, healthy incentive structures–making stuff for friends is fun and earns you their gratitude–and replace them with less interesting ones–making stuff for friends earns you badges which will increase your earning power.

I’m not certain that badges would actually change things for the worse, of course; it’s just a concern of mine, and I think there are things we can do to help ensure that they add new incentives without taking anything away from existing ones.

One of the ways we can do this is by creating badges for things that don’t currently have any incentives.

Let me use an example from World of Warcraft. One day I was wandering around the desert when the sky turned red. I had no idea what was going on, but I kept walking; after several seconds, my screen was filled with flames and my character was dead.

This kind of thing happens often in massively multiplayer games: giant computer-controlled creatures wander the world and crush unsuspecting players who were in the wrong place at the wrong time. In this case, I had just been slain by Deathwing, the most powerful dragon in the game.

What’s really interesting, though, is that the instant I died, an achievement blazed across my screen: Stood In The Fire.

This achievement is significant to me because it turned an experience that’s normally frustrating into one that’s serendipitous, hilarious, and socially rewarding. It also communicated a few things behind the scenes:

• Bad stuff happens to everybody. It’s okay.
• You can gain recognition by doing some weird and unconventional things.

Achievements like these can infuse badges with a sense of playfulness that encourages experimentation, and make earning them feel like fun rather than like getting a report card or a Ship It award.

What might the analog be for Web literacy badges? How about achievements for things like…

• not closing an HTML tag?
• writing a CSS rule that never gets applied to a page because it’s overridden by other rules?
• falling for a harmless phishing scam?
• having your behavior tracked by the same company across 30 different websites?
• putting a security vulnerability in your code?
• making a web page that’s perfectly legible to blind people, but incoherent to those with vision?

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.

I’ve been reading Eli Pariser’s book The Filter Bubble and was fascinated by his description of how data collection companies operate. Independently of that, David Ascher suggested that I add a feature to the Hackasaurus goggles which helps learners understand how cookies and tracking works.

I actually didn’t know a lot about tracking myself, so I whipped up a Firefox add-on called Collusion to help me visualize it better. The results were a little unsettling.

I’ve put a demonstration up at collusion.toolness.org, which takes you through five popular websites and visualizes the data collection companies that track you across them. From there, you can download the add-on if you want to see the tracking visualization of your own browsing behavior evolve in real-time.

Special thanks to the Mozilla Add-on SDK team for making a great foundation to build on. This experiment also gave me a chance to play around with d3.js, which is a fantastic successor to Protovis. And thanks to PrivacyChoice for their excellent tracker list, which I’m sort of using without their permission. I hope that is okay.

I’m also not really a privacy expert, so I’m not sure if everything I say in the demonstration is completely true. If you find any inaccuracies, please let me know.

Finally, if you need the source code, it’s all at github.com/toolness/collusion. I’m particularly interested in seeing better visualizations than the force-directed graph I’m using, which regrettably requires a lot of user interaction to explore and understand.

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?

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.

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

1. Know How Much Freedom You Have.

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

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

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

2. Digital Natives Know Less Than You Think.

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

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

3. Engage Your Audience’s Interests.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tools

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

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

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

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

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

Now all I needed were some students.

Guinea Pigs

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

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

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

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

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

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

This is why I like making things for people.

Remixes

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

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

Drumbeats

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

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

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

Either way, I’m excited.