Empathy For Software Conservatives

July 6th, 2012

Recently my friend Jono wrote an excellent blog post entitled Everybody hates Firefox updates. I agree with pretty much everything he says.

What most struck me during my time in Mozilla’s Mountain View office was a complete lack of empathy for people who might want to “stay where they were” and not upgrade to the latest version of our flagship product. Whenever someone asked a question like, “what if the user wants to stay on the old version of Firefox?”, the response was unequivocally that said user must be delusional: no one should ever want to stay on an old version of a product. It simply doesn’t make sense.

I’ve always credited this bizarre line of thinking to everything I dislike about the Silicon Valley bubble, though I don’t ultimately know if it’s endemic to the Valley or just tech companies in general. I personally have always despised upgrading anything–not just Firefox–for exactly the reasons that Jono outlines in his post. Most people at Mozilla–and likely other software companies–seem to think that it’s just the outliers who dislike such disruption. Maybe they are, I have no idea. But I and most people I know outside of the software industry view upgrades as potential attacks on our productivity, not as shiny new experiences. If there’s any desire at all within Mozilla to cater to such “software conservatives”, the first step is having actual empathy for folks who might want to stay right where they are, rather than treating them as an irrelevant minority.

Learning and Grammatical Forgiveness

April 26th, 2012

HTML is a very interesting machine language because, like human languages, most things that interpret it are very forgiving.

For instance, did you know that the following HTML is technically invalid?

<video>
  <source src="movie.mp4"></source>
</video>

It’s invalid because <source> is a so-called void element: since it can’t have any content inside it, you simply don’t need a closing tag for it. The <img> tag works the same way. The technically correct way to write the above HTML snippet is as follows:

<video>
  <source src="movie.mp4">
</video>

However, in practice, all Web browsers will interpret both of these snippets the exact same way. When a browser sees the closing </source> tag on the first snippet, it realizes the “mistake” the author has made, and simply pretends it isn’t there.

What’s interesting to me is the way this mirrors human languages, and what it means for teaching. For instance, the following sentence is grammatically incorrect:

The dog loves it's owner.

However, no one who knows English will actually be confused by the meaning of the statement.

When I was trained as an adult literacy tutor several years ago, one of the most important principles we were taught was that fostering a love for writing was vastly more important than grammatical correctness. The “red pen” commonly used by school teachers for correcting grammatical errors was seen as anathema to this: when we found a grammatical error in a novice writer’s work, we were encouraged to ignore it unless it actually made the piece confusing or ambiguous for readers in a way that the author didn’t intend. Otherwise, the novice writer would become quickly distracted and discouraged by all their “mistakes” and view writing as a minefield rather than a way to communicate their thoughts and ideas.

We’re running into similar issues in the design of the Webpage Maker. On one hand, the fact that Web browsers are so forgiving when interpreting HTML enables us to follow a similar philosophy as that of progressive adult literacy tutors.

But sometimes, the forgiving nature of Web browsers backfires: they actually render a document that is vastly different from the author’s intent, which is just as frustrating as a pedantic nitpicker. We’ve created a library called Slowparse—soon to be renamed—which attempts to assist with this, providing the logic needed for a user interface to gently inform users of potential ways their HTML and CSS code might be misinterpreted by machines. A full specification of errors and warnings is also available, as is an interactive demo that uses the library to provide real-time feedback to users.

It’s been interesting to see how different Slowparse is from a HTML/CSS validator, whose goal is not one of learning, but of ensuring conformance to a specification. From a learning perspective, a validator is like the pedantic teacher who loves their red pen: some of its feedback is quite useful, but the remainder is likely to confuse and intimidate a newcomer.

Partly as a result of its learning goals, Slowparse actually “warns” the user of things that are technically valid HTML/CSS, but which likely don’t reflect the intent of the author. One current example of this is in regards to the use of unquoted attributes in HTML5, though that particular example is still subject to change.

At this point, I think the challenge will be to work with our learning team and user test our interface to the point that we achieve a good balance between being a pedantic nitpicker and providing useful feedback that helps users as quickly as possible. In my opinion, if we do things right, we’ll help people develop a love for HTML and CSS—even if what they write may technically be “grammatically incorrect.”

Prototyping Presentations

March 31st, 2012

Presentations take a long time to make. Particularly when I’m just conceptualizing my presentation, it takes a lot of work to record myself talking, use a tool to sync it with the proper visuals, and then repeat the recording and syncing process as I iterate on the content.

I recently made a simple tool called Quickpreso to make the process of “prototyping” a presentation quicker, and more like writing a simple HTML page.

A presentation in Quickpreso is just an HTML file with a series of alternating lines for visuals and voice-overs, like this:

<img src="slide-one.jpg">

This text will be spoken for slide one.

<a href="http://mozilla.org/">I am slide two.</a>

This text will be spoken for slide two.

The visuals can contain any HTML markup. Each section of voice-over text is rendered by the OS X say command; they’re all concatenated together into an audio file by ffmpeg. Finally, the visuals are synced to the audio in a Web page using popcorn.js.

Quick iteration is facilitated by a simple Python web server that regenerates the audio file when it detects changes to the voice over text. The final product is all static content that can be served from any web server.

I used this tool to create a Webmaking for Knitters presentation in January. The result is quite robotic, obviously, though it can be made a little more natural-sounding if newer voices from OS X Lion are used (I’m still on Snow Leopard).

One particular advantage of this approach, however, is that you get subtitles/closed-captioning for free. There’s also nothing preventing you from re-recording the final audio in your own voice once you’re happy with your prototype.

The source code is available on Github at toolness/quickpreso. The code is in an alpha state, so your mileage may vary; fortunately, though, the source code is miniscule, so understanding and changing it shouldn’t be hard.

Coffee Machines And Community

March 28th, 2012

The Toronto and San Francisco Mozilla offices each feature very different coffee makers.

The Toronto office has a Rancilio Epoca espresso machine. It has lots of knobs and switches, and one has to be taught how to use it. When one learns, the first few drinks they make are likely to taste very bad; a conscious effort must be made to learn from one’s mistakes and create better drinks.

The SF office has a Miele espresso machine with three buttons and an LCD display. It’s comparatively easy to use, and makes fine drinks at the push of a button—until something goes wrong in the opaque innards of the machine. The sight of error dialogs like this one are extraordinarily common:

The machine probably has as many different kinds of error messages as a modern computer operating system. Like an operating system, it also offers little to no assistance on how to fix the problem that’s occurring.

Both of these coffee machines reflect very different philosophies about the nature of tools, and about the people who use them. For me, one of the most interesting aspects concerns the communities that have grown—or failed to grow—around them.

Actually, the very existence of the Toronto office’s espresso machine is due to community: as I understand it, a core group of Torontonian espresso aficionados decided to buy a small communal machine with their own money, and upgraded the machine later on. The result I’ve noticed, whenever I’ve visited the Toronto office, is that the kitchen area becomes a place for learning. People are constantly teaching each other how to make a better drink, asking questions, debating the proper pressure to use when tamping (“approximately the weight of a cat”, says one coworker), and so forth. In a growing workplace that is constantly in danger of being segregated by organizational boundaries, a community of practice that’s centered around something completely unrelated to work is an amazing asset.

In contrast, there isn’t much of a community that can form around the push-button Miele machine in the San Francisco office. Because there’s no way to go “under the hood” and customize one’s coffee-making experience in a positive way, there’s not really any technique to share with others. An interface that is so “self-serve” and “easy to use” that it prohibits nuance and customization is also one that doesn’t encourage people to talk about it.

This might be an acceptable trade-off, except for the fact that the Miele isn’t fully self-serve. Like any machine, it needs maintenance, and because there was never an incentive for anyone to understand how it worked, very few people know how to fix it—if anything, I’ve experienced a sense of resentment when I’m presented with an error, as though the machine has violated its contract of being mind-numbingly easy to use. Consequently, the only talk I’ve ever heard about this machine revolves around its inscrutable error messages, which only the office manager knows how to fix.

The same dynamics I’ve described here apply to all of our tools. No matter how easy and “self-serve” we try to make our software, a significant portion of its users will still run into problems and use cases that they don’t know how to get past on their own. I don’t know if it’s possible to foster communities of practice through tools designed for freedom and empowerment—even if we put the Rancilio in the San Francisco office, for instance, it may languish if no one there thinks a good espresso is worth learning how to make. But it’s certainly worth finding out.

Storything Interactive Prototype

March 26th, 2012

Last week I merged the Webmaking Tutorial Prototype with the Webmaking 101 for Journalists prototype we made during our three day sprint in NYC in February.

The result, which is code-named Storything, is currently hosted at storything.toolness.org. Give it a try!

The design for this prototype is based on Jess Klein’s instructional overlay mockups. A separate two-pane editor for example snippets is included in the movie frame; my hope here is that by setting the tutorial movies in an actual editing environment, users will obtain a better understanding of how to use our tool. This is further aided by the ability for the tutorial movies to highlight parts of the user interface outside the movie frame.

At present, the prototype awards badges for a few simple things, like creating your first paragraph and header elements. These badges aren’t necessary to advance the tutorial, however; this is partly because we’d like the tutorial to be approached in a non-linear way, and also because the assessment algorithms for the badges likely can’t capture every possible edge case in user input.

The prototype’s source code can be forked at toolness/storything on Github.

Webmaker Tutorial Prototyping

March 9th, 2012

Recently I’ve been playing around with creating interactive tutorials that teach people how to create things on the Web.

Check out this prototype. At the end of a movie-like tutorial, you’ll be given a challenge to write your first bit of HTML. At any time, you can use the scrubber at the bottom-right to review any part of the tutorial; anything you’ve typed so far in the challenge is undone while you’re scrubbing, and is automatically re-applied once you’re back at the challenge.

This prototype is an evolution of an idea that Jess Klein wrote about regarding instructional overlays for our webmaking tools.

How It Works

The tutorial uses Popcorn to construct a “movie” that automates the user interface of a two-paned HTML editor with an instructional overlay. I made an ad hoc mini-framework called tutorial.js to make it easy to script these sorts of experiences; for example, here’s what the beginning of the prototype’s tutorial looks like:

Tutorial
  .dialogue("Hi! I am Mr. Love Bomb and will teach you how to be a webmaker now.", 0)
  .typechars("you're really cool.")
  .dialogue("Check it out, this is HTML source code—the language of the Web.", 0)
  .spotlight("#editor")

The dialogue() method just makes the tutorial avatar—in this case, Mr. Lovebomb—say something. typechars() types some characters into the HTML editor, and spotlight() draws the user’s attention to part of the page. Each action is queued to occur serially, in a style inspired by the chaining API of soda.

The full tutorial script is at tutorial-script.js, and the full tutorial source is available on Github.

The Role of Performance in Online Life

February 11th, 2012

In Sherry Turkle’s Alone Together, the author writes:

Brad says, only half jokingly, that he worries about getting “confused” between what he “composes” for his online life and who he “really” is. Not yet confirmed in his identity, it makes him anxious to post things about himself that he doesn’t really know are true. It burdens him that the things he says online affect how people treat him in the real. People already relate to him based on things he has said on Facebook. Brad struggles to be more “himself” there, but this is hard. He says that even when he tries to be “honest” on Facebook, he cannot resist the temptation to use the site “to make the right impression.” On Facebook, he says, “I write for effect. I sit down and ask, ‘If I say this, will it make me sound like I’m too uptight? But if I say this, will it make me sound like I don’t care about anything?’” He makes an effort to be “more spontaneous on Facebook . . . to actively say, ‘This is who I am, this is what I like, this is what I don’t like,’” but he feels that Facebook “perverts” his efforts because self-revelation should be to “another person who cares.” For Brad, it loses meaning when it is broadcast as a profile.

I’m not a teenager like Brad, but I share a lot of his concerns. Turkle uses the word performance frequently when describing public and semi-public life on places like Facebook and Twitter, and it’s an apt description.

Perhaps it comes from the reaction many have when they’re sent a mass email, but I’ve always felt that the meaning of a message changes as the number of people receiving it increases. Most of my electronic communication tends to revolve around email and instant messaging with close friends; the few online communities I’ve truly felt a part of have all been gated and largely inaccessible to the general public. Communications within these realms is bounded, and context is well-defined; it’s easy to figure out what my message will mean to its recipients, whether it will be interpreted as spam, vulgarity, hilarity, or saving face. Yet beyond the mechanics of conversation lies a basic belief that the fewer people receive my message, the more it will mean to each of them.

Consequently, however, places like Facebook, Twitter, and public forums mean little to me, at least when it comes to creating and maintaining authentic connections with others. These may be places for carefully crafted banter, rational discourse, or using humanity as a lazyweb—but they are not places that feel like home.

Achievement and Playfulness

November 30th, 2011

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?

Playfulness and Learning

November 29th, 2011

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.

Hacking The Web With Interactive Stories

August 15th, 2011

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.