I originally wrote these descriptions as part of a post on formats for learning material. I’m finding them useful in other contexts as well, so I’m re-posting them separately. Our description of our audience describes four scientific users in more detail.

• Zuzel likes textbooks. More specifically, she likes prose that she can read and re-read at leisure. She’ll use a tablet, but would rather listen to music while she learns than to someone lecturing.
• Yeleina prefers interactive learning. She wants to see things evolve on the whiteboard or on the screen; recordings of live coding sessions with voiceover are OK, but slide after slide of bullet points puts her to sleep. She also wants to be able to share ideas about learning content with her peers.
• Xanthe is a surfer, not a diver—she wants to skim the pages that Giggle searches turn up and piece things together herself. Bullet points and brief sentences work well for her, particularly in areas she’s already familiar with.
• Wafiya teaches programming at a city library. She needs to remix content created by other educators to meet her learners’ needs, but doesn’t have a lot of time to do so. She also needs to be able to find content that fits into her (individualized and group) learning plans.
• Veronique is a programmer who is passionate about teaching. She spends several hours a week writing short tutorials, answering questions in Stuck Underflow and other online forums, and occasionally recording screencasts. She’d like to do more with less effort (she finds today’s tools frustrating), to make the content she’s creating more useful, and to get more feedback from its users.
• Ursula‘s preferences are more constrained than Zuzel’s, Yeleina’s, or Xanthe’s because she is visually impaired. Her main assistive aid, a screen reader, can only “see” text (captions in PNG or JPEG images don’t count), and becomes confused when pages are modified in place by Javascript.
• Tahura is an assistant professor at a medium-sized university. She has to teach three undergraduate courses each year, one of which is always “Introduction to Scientific Programming”. While she’d like to experiment with new teaching methods, her priority right now is to get tenure, so she (reluctantly) sticks to the university’s traditional format: three hour-long lectures a week, one homework exercise every three weeks, a midterm, and a final exam.

Before going further with the redesign of the Software Carpentry curriculum, I need to define a few terms and their relationships. These definitions refer to another post on learners and their needs, which you may want to read first.

• A concept is an atom of learning. It can be a fact (e.g., what a call stack is), a technique (e.g., how to pass parameters to a function), or a rule (e.g., when to copy data).
• An association is any connection between two concepts. Obviously, all concepts in a topic should be strongly associated.
• A dependency is a prerequisite association between two concepts. Circular dependencies may exist (you can’t understand A unless you understand B, which depends on C, which in turn depends on A), but we’ll work hard to avoid such cycles, since every particular learner encounters concepts in some sequential order.
• A topic is a set of related concepts; for example, the topics “Parameters” includes all of the concepts described above. A concept may be part of several topics, but for learning purposes, we would like its first appearance for an individual learner to be gentler than subsequent appearances for that same learner.
• A lesson is an atom of teaching. It will typically comprise a small number (1-4) of closed-related concepts, and be a few minutes long. Where possible, it should be followed immediately by some kind of reinforcement (discussed below). A concept may appear in several lessons (same idea, different contexts).
• A tutorial is a specific sequence of lessons on related topics; for example, the tutorial “Functions” would include lessons on parameters, returning values, and so on. Tutorials aren’t strictly necessary for free-range learners—they can go through lessons in any order that respects dependencies—but we must define them:
  • to give learners like Zuzel the larger narrative arcs they need (learners like Xanthe only need lessons); and
  • to give instructors like Tahura, who are working in traditional classroom settings, guidance on how to fill an hour-long lecture.
• Reinforcement is something done to help people absorb a concept, such as further examples, class discussion, quizzes, or exercises. All four are problematic:
  • Further examples are based on guesses of what learners might not have understood correctly; such guesses are often wrong.
  • Class discussion is hard to implement for asynchronous, self-directed learners.
  • Multiple choice quizzes can mislead or frustrate learners (most questions have more than one right answer), or fail to clear up learners’ misconceptions (“You’re wrong, but I won’t tell you why”).
  • Long-answer quizzes and exercises require a human assessor’s attention (which is also hard to implement for asynchronous learners).
• Assessmentis anything done to determine how well something else has been done. “How well” is important: assessment will not always (or even usually) be black-and-white. Specific kinds are:
  • formative assessment, which provides short-term diagnostic feedback to learners and teachers;
  • summative assessment, which demonstrates attainment of some level; and
  • evaluative assessment, which tell us how well the teaching is working.

  Formative assessment is a kind of reinforcement; summative and evaluative are (usually) not.

The diagram below shows these relationships. I’ve drawn most relationships as many-to-many, but in practice, we hope that most will actually be one-to-many, i.e., that concepts will fit neatly into topics, and topics into lessons. The one-to-one relationship between summative assessments and topics is also a bit misleading: what it’s meant to imply is that any particular learner will eventually demonstrate mastery of some topic (e.g., Yeleina will show that she understands functions). This is the smallest “chunk” for which we’d contemplate awarding a badge, though as discussed earlier, we’re going to start with something coarser-grained.

Like many people, I’ve admired MIT’s Scratch for a long time. It’s a tool that makes it easy for kids to create simple games and animations. And, by design, it teaches some of the basics of programming and computational thinking along the way.

This approach is very much like Mozilla’s own Hackasaurus: invite kids to make something that excites them, and learning into the technology they are using to do the making. In fact, the Scratch approach really informed the ‘making is learning’ design philosophy that’s at the core of the webmaker work we’re doing at Mozilla this year.

Which is all to say, I see Scratch and Hackasaurus as cousins. And, as cousins, I think there is a great opportunity play together — for both to feed into the bigger picture goal of teaching and inspiring millions of new webmakers.

We did a first experiment in putting Scratch and Hackasaurus together at the Hive Tokyo Pop Up a week ago. The Tokyo Scratch community plus a handful of Mozilla people ran a combined workshop where kids used both tools to create a Scratch web page mash up. Concretely, we combined three things:

• Step 1. A short Scratch workshop where kids created simple animations and uploaded them to the Scratch gallery site.
• Step 2. A basic Hackasaurus Xray Goggles lesson where kids learned how to remix text and images on a web site.
• Step 3. A ‘be a famous game designer’ exercise where kids embedded their Scratch movie into their favourite gaming web site.

The whole thing took only an hour, so it was necessarily very simple and limited. But it still built two important web making concepts — ‘the web is lego that you can take apart and remix’ and ‘the basics of telling a computer to do something’ — into a single hour. And the kids seemed to have fun. A number of them kept hacking for an hour after we’d finished the initial session.

Of course, the experiment was not without hickups. In fact, we had to iterate the process three times to get to what I described above. In the first two sessions, the Hackasaurus and Scratch teams taught separately and tripped over each occasionally. It was only in the third round where we had one Scratch and one Mozilla person teaching side by side in each session, which worked well.

I’m not sure where this goes. We might want to do the exact same thing again, especially if we can build local Hackasaurus communities in places where Scratch is also strong. Or, we might use as fuel to brainstorm a more ambitious vision of how Scratch and Hackasaurus can play together. Where ever it goes, it was a fun and good first step.

PS. Huge thanks to the Scratch Japan community for having the trust to try this experiment. I was both grateful and impressed. You and your team really rocked!

PPS. Kudos also to famous ‘Mexican’ wrestler Chris Lawrence for awesomely MC’ing the event.

Frequency a page is viewed (as a percentage of total views) vs. pages (ordered by frequency); data taken over the last 90 days. I guess there’s something to this “long tail” stuff after all.

I’m still gnawing on the problem of how to construct content for 21st Century learning—or, more prosaically, what I should use to build the next version of Software Carpentry. My starting point is the need to serve several different kinds of users [1], whose descriptions I have moved to a separate post on learners and their needs.

Their learning options today are:

• Textbook: big blocks of prose in some narrative order, with pictures, either printed or electronic, read at the learner’s pace, alone.
  • Zuzel likes this.
  • Yeleina doesn’t.
  • Xanthe uses content out of order via the index or search bar.
  • Wafiya remixes content from several textbooks to create lessons (by photocopying, merging PDFs, or whatever). Like Zuzel, she has read content in order, but like Xanthe, she mainly uses the index now.
  • Veronique has thought about writing one, but (a) doesn’t think she has that much to say about any single topic, and (b) is put off by the effort that would be required.
  • Note: the comments below about the difficulty of copying, pasting, and altering also apply to electronic textbooks, as do the proposed remedies.
• Static slideshow: a page-by-page dump of a PowerPoint deck, possibly accompanied by a transcript of what the lecturer would say when delivering it.
  • Zuzel uses this as if it were a badly-written textbook, with the transcript as the prose and the slides as diagrams.
  • Yeleina finds it distracting to switch attention back and forth from slides to transcript.
  • Xanthe searches the transcript to find what she wants, then curses because her search engine can’t “see” the text in the slides. She also hates the fact that she can’t copy and paste the code in the slides (since they’re PNGs embedded in a web page).
  • Wafiya remixes this content like any other. She’s too polite to curse, but she finds it tedious to re-type the code that’s shown in the slides (but isn’t duplicated as text in the accompanying transcript). She’s also finds it wearying to have to re-do diagrams: since the slides are PNGs, it’s difficult for her to copy part of a slide, move its elements around, and add a few of her own.
  • Veronique doesn’t create material in this format because she thinks it’s old-fashioned and not useful.
  • Note: source code can be made available as copy-and-pasteable text directly in the page, or for download; diagrams can similarly be made available as SVGs to facilitate remixing. Doing either currently requires considerable extra work on the part of content creators.
• Voice-over slideshow screencast: a video recording of the slides (as they would appear on screen in a lecture) with someone speaking over them, and subtitles.
  • Zuzel ignores the video and reads the transcript as if it were a static slideshow. If a transcript isn’t available, she (reluctantly) watches the video.
  • Yeleina prefers this to a static slideshow, but prefers the doodling screencast described below even more.
  • Xanthe hits the “back” button as soon as she realizes it’s a video (unless there’s a transcript, in which case she curses because she can’t copy and paste code out of a video).
  • Wafiya directs students like Yeleina to these, but finds them harder to remix than other formats.
  • Veronique thinks this format is also old-fashioned and not useful.
  • Note: I’m assuming the subtitles are duplicated as a transcript, or available in some other searchable form. I’m also assuming that code is available for donwload or duplicated in the page for coying and pasting, though all of this requires extra work.
• Voice-over doodling screencast: a Khan Academy-style recording of someone doodling on a tablet or coding live.
  • Zuzel treats this like a slideshow screencast.
  • Yeleina likes this format a lot, particularly if she can add comments at specific points and see her peers’ comments.
  • Xanthe has mixed feelings: she dislikes explanations delivered this way, but frequently watches “how to” videos, since they’re more likely to be accurate and complete than written descriptions.
  • Wafiya treats these like slideshow screencasts.
  • Veronique creates these fairly regularly: they’re easy to do, and easy to re-do when systems change or she discovers a mistake.
  • Note: I’m making the same assumptions about transcripts, code, and diagrams as above.
• Recorded whiteboard lecture: someone with a camera has recorded someone giving a lecture in a lecture hall, and spliced that with whatever was on the lecturer’s screen.
  • Zuzel treats this like any other screencast.
  • Yeleina prefers this to doodling screencasts because she can see the speaker’s body language.
  • Xanthe treats these like any other screencast, i.e., she’ll use it if there’s a searchable transcript and things to copy and paste, or if it’s a recording of a live “how to” coding session.
  • Wafiya treats these like slideshow screencasts.
  • Veronique doesn’t create these, partly because of the setup required, but also because she doesn’t think seeing her adds value—the lesson’s supposed to be about the stuff.
  • Note: I’m assuming an electronic whiteboard, since video of someone writing on an actual whiteboard is usually illegible.
• Radio drama: a voice-only podcast-style presentation.
  • Zuzel ignores the audio and reads the text transcript.
  • Ditto for Yeleina.
  • Ditto for Xanthe.
  • Ditto for Wafiya.
  • Veronique doesn’t create these.
  • Note: but for Ursula, who is blind, this is the only format—all the others fold into it. She doesn’t need code samples as text for copying and pasting: she needs them so that her screen reader can tell her what’s that code contains.
• Star Wars: high-quality video with custom animations, cut scenes, and other special effects.
  • Zuzel watches these sometimes, but doesn’t learn any more from them than she would from a slideshow.
  • Yeleina enjoys these, which means she pays more attention to them, which means she learns more (but no more than she’d learn from an engaging lecturer).
  • Xanthe doesn’t see the point. Unless something blows up.
  • Wafiya likes their high production values, and remixes the special effects segments frequently.
  • Veronique can’t afford to produce this kind of material.
  • Note: again, I’m making assumptions about transcripts, copy-and-pasting, etc.
• Write your own adventureexploration: typically a set of connected ideas or challenges with explicit dependency information (i.e., you should/must learn A and B before tackling C).
  • Zuzel finds the lack of narrative difficult.
  • Yeleina enjoys these if each node in the graph is in one of her preferred formats. She enjoys them even more if she is exploring with peers.
  • Xanthe ignores the ordering and searches for what (she thinks) she needs. If content is locked down—i.e., if the system won’t let her see or search C until she’s “completed” A and B—she writes an angry tweet and moves on.
  • Wafiya likes this format for several reasons, but only if everything is always visible. First, it tells her how other teachers think ideas connect (something that is missing or out-of-band for other delivery formats). Second, it’s easy to remix: again, providing it’s open, she can reorder things as she thinks best for particular learners.
  • Veronique would like to do this, but has discovered that creating the metadata about dependencies and recommended paths is as hard as writing a textbook.
• Wander aroundexploration: lots of little snippets, but no explicit dependency information.
  • Zuzel finds this even more difficult.
  • Yeleina likes this less than the “write your own adventure” format: she thinks it’s no different than just using Giggle to find things.
  • Xanthe likes this because it’s just like using Giggle searches. In fact, she uses every other format as if it were this one.
  • Wafiya feels the same way as Yeleina: she likes having stuff to remix, but she has to do that remixing before this material is useful to those of her students who aren’t as independent as Xanthe.
  • Veronique creates content like this almost without realizing it by answering questions at Stuck Underflow.
• Jam session: a bunch of learners in a room working through material simultaneously.
  • Zuzel doesn’t like it: it’s too noisy for her to concentrate, and she can’t go back at her own pace to review.
  • Yeleina thinks this is the best… thing… ever.
  • Xanthe is Giggling for information as soon as the presenter tells people what the topic is, but will stop and watch carefully when the presenter is typing live on screen.
  • Wafiya can only book space to do this occasionally, and even then, she doesn’t enjoy improv teaching.
  • Veronique enjoys doing this—she’s volunteers with a local free-range learning group—but can only find time once every couple of months.
  • Note: in theory this can be combined with any of the formats above. In practice, it’s almost always short, live lectures interspersed with hands-on practical work.
• Personal tutoring: one-to-one instruction, a.k.a. “pair learning”.
  • Zuzel doesn’t mind this, but she really does prefer books…
  • Yeleina actually prefers jam sessions, since they tend to be more lively.
  • Xanthe likes having someone available to answer questions on demand, but is happy Giggling on her own for most of what she needs.
  • Wafiya wishes she could do this with every one of her learners, but there simply aren’t enough hours in the day. The personalized lesson plans she draws up are the closest approximation she can manage.
  • Veronique does this a lot, but is frustrated that it doesn’t scale—she really wants to help more than one person at a time.

I’m sure some of the above is inconsistent or just plain wrong, but here are my takeaways:

1. Different people want content in different formats. Yeah, OK, we knew that already, but:
2. Everybody needs first-class content, in the programming sense of the term. In practice, it means that every kind of content can be copied and pasted without losing its meaning. A bunch of colored pixels in an image that look like letters aren’t actually letters; if you copy a region of an image and paste it into a text editor, you don’t get the text [2]. Similarly, search engines like Giggle can’t “see” code evolving line-by-line in a video, so you can’t search for that. Together, I think that point #1 and point #2 imply that:
3. We need model-view separation in learning content. I apologize for the computerese, but I don’t know any other way to say it. A model (more fully, data model) is how information is stored, while a view is how people interact with it. Models should be designed to be easy for computers to work with; views should be designed to meet human needs, and the plural there is important: different people want to interact with information in different ways, and even a single person may want to use different ways at different times. Search engines want the information that’s in the model, such as the captions on the boxes in a diagram, not some arbitrary view of it (like a bunch of pixels in a PNG). People usually want that as well when they’re remixing, since their goals are to combine that information with information from other sources, and/or to present that information in different ways (i.e., views).
4. We also need first-class metadata. I haven’t been able to find a standard format for summarizing and exchanging lesson objectives, learning dependencies, and everything else needed to stitch individual facts together. The closest thing seems to be SCORM, but I’d rather stick a fork in my eye [3]: it’s bloated, it mixes data models with meta-models with presentation layers with everything else its authoring committee could think of, and did I mention the fork? I could provide metadata as data, e.g., put a point-form list at the top of a lesson saying, “Here’s what you need to know before tackling this,” but that mixes model and view: since it’s just a convention, computers will have a hard time stitching things together accurately.
5. Finally, we need social learning. Even the Zuzels of this world learn best in collaboration with other people: peer learners are often better at understanding and clearing up misconceptions than instructors, and having a “running partner” helps people stay focused and motivated. This isn’t really a matter of format, though, but of the tooling used to deliver content, so I’ll skip over it below.

OK, so how well do today’s tools and/or formats do by these measures? The fact that “PowerPoint” is both a tool and a format is one indication that the answer is going to be, “Not well.”

• Plain textis highly searchable and remixable, plays nicely with accessibility aids (i.e., screen readers), and runs everywhere, but:
  • it doesn’t do diagrams (unless you count ASCII art);
  • it doesn’t directly support metadata (except by convention); and
  • it doesn’t separate models from views
• HTML is also highly searchable and remixable—until you start doing dynamic updates with Javascript, at which point today’s search tools (and accessibility aids) can’t keep track of what’s going on. Unlike text, it provides standard ways to include other media, so we’ll delay discussion of images and video. And while it doesn’t offer a standard way of providing metadata out of the box, HTML5′s custom data attributes were designed with exactly this kind of use in mind. And modern HTML partially separates models from views: I can use CSS to tell the rendering engine (e.g., a web browser) to display things differently for different use cases.
• DocBook, LaTeX, and wiki text separate models from views even more than HTML does. What’s in the file is a description of content, information about the content, and just enough formatting to make things pretty when viewed in specific ways, e.g., “Break the page here to avoid an orphaned line.” Diagrams and metadata can be handled the same way as it is for HTML; in fact, I can’t see any advantage these formats have over modern HTML any longer [4], so I’m going to take them off the table.
• PNG and other raster formats: fail the searchability and copy-and-paste tests.
• SVG and other vector formats: do better. Since (some of) the content and relationships are explicit, search engines can find things in SVGs, and you can actually select and copy a box or an arrow, rather than a region of pixels. It only goes so far—Visio-style information about “this arrow connects the box labeled A to the box labeled B” is mostly implicit—but it’s better than raster. I’ve seen people do entire lessons as a series of SVGs, or as one large SVG with progressive reveal; I’ll talk about this more below.
• PowerPointand its kin: model, view, and authoring tool are inextricable from one another. You can copy and paste things, and modern search engines understand the format well enough to index textual content, but metadata is just a convention, and remixing takes a lot of work (even if the version you have is the original, rather than an exported ZIP file containing an HTML page that references PNG representations of the slides). That said, authoring rich presentations is easier than it is with HTML+SVG:
  1. You use the same tool to create textual and graphical content, rather than having to switch between tools and stitch content together.
  2. You can connect textual and graphical content, i.e., you can draw a circle around a word in one of your bullet points, then connect it with an arrow to a particular box in a diagram, just as you would when writing freehand on a whiteboard. This is what HTML-based slideshow packages lack: right now, they force authors to segregate text and graphics, which I view as a throwback to the era of hot metal typesetting.

  The fact is, most presenters continue to use PowerPoint (or something similar) because it makes it easy to create a reasonably good presentation in a reasonable amount of time [5]. HTML slideshow packages fail this test: authors must sacrifice the quality of the presentation (e.g., skip graphics, or embed segregated graphical files), and do a lot of non-content typing (tags, page IDs, and so on).

• Video: fails all the “first-class content” tests [6], and isn’t effective [7] unless:
  • authors have the resources to produce Star Wars-quality content [8], or
  • they’re showing learners how to do something, like dissecting a frog or using a debugger.

So after all of this, what do I actually want?

1. I want content stored in HTML5 with purely semantic markup, so that it can be searched, copied and pasted, and styled for presentation in a variety of ways [9].
2. I want an agreed-upon meta and data-* vocabulary for educational metadata, like dependencies, introduction of key terms, questions and answers, and so on. I want a similar vocabulary for commenting and other social interactions that plays nicely with things like the Salmon protocol.
3. I want an authoring tool (note the singular there) that lets me:
   1. write and draw WYSIWYG instead of typing in tags and IDs;
   2. freely mix drawings and text; and
   3. manage parallel streams (or channels), so that I can keep slide content, presenter’s notes, prose, and translations of all three into other languages together.
4. I want to be able to animate my drawings and text, which is emphatically not the same as “embed video” (though I may want to do that too). Instead of recording the pixels drawn on the screen as I type Python into an editor, I want to record and play back the text that’s being created, so that learners can pause the animation, copy the text, and paste it somewhere else. Equally, instead of painting pixels to fool your eyes into believing that a box just moved off the screen, I want to move the damn box; once again, if you pause the animation, you should be able to click on the box, attach a comment to it, paste it into your own drawing, etc.

Freeling mixing drawings and text feels like it ought to be doable today: we could either put the text in blocks inside a canvas element, or layer a transparent canvas over the page and dynamically resize it. Anchoring drawings to the underlying text (e.g., keeping the arrow from a term to the corresponding bit of the diagram in the right place) is “just” Javascript (for some value of “just”). Making it all WYSIWYG is just more Javascript [10].

But animation… Ah, that’s a big one. It’s an intrinsically hard problem, but canned effects can do a lot to put simple things within reach [11]. The big question is, how far do we push it? If I want to show you how to use a debugger, or how to draw something with a painting program, I can’t re-create the whole UI—I’m going to have to record pixels off a screen.

Or am I? I know this is never going to happen—we’re not that organized a species—but just imagine what the world would be like if every interface was built using HTML5 and CSS. Any tool at all could export widget descriptions and a semantic trace of what they did (i.e., “the file menu was pulled down” rather than “the cursor moved to pixel (132,172) and the user clicked”), and any other tool could consume it and play it back. The consuming tool might draw the widgets differently, or display the interactions in its own way, but that would be exactly the same as applying a different skin to the original tool [12].

Returning to this universe for a moment, we can store things as HTML5 right now—I’m already using it for Version 5 of Software Carpentry. I could create a vocabulary for instructional metadata, but I’m not an information architect. WYSIWYG authoring tools for HTML5 abound, though the HTML5 they produce can be idiosyncratic (and doesn’t play nicely with version control, but that’s fixable). I haven’t seen a WYSIWYG tool that supports freehand drawing mixed freely with text, or one that supports parallel content streams, but I think half a dozen people working could deliver something substantial in half a dozen months [13].

As for animation, I think we’re stuck with video for now: prototyping an HTML5/SVG/Javascript animation framework for use in a learning tool would be a great research project, but we really do need to build a couple to throw away to find out if it’s workable. If you’d lke to tackle it, please let me know—I’d be happy to be your alpha tester.

Notes

[1] There was a lot of talk in the 1980s and 1990s about different people having different learning styles, inspired in part on Gardner’s theory of multiple intelligences. The idea has mostly been discredited, but like many memes, it lives on in popular culture.

[2] Although I bet someone’s working on an Emacs mode to do that…

[3] I’ve actually done this, so I know whereof I speak.

[4] Except that LaTeX and wiki text require slightly less typing than HTML, but if you’re using a smart editor, even that advantage goes away.

[5] Please don’t quote Tufte’s complaints about PowerPoint at me—I don’t think it encourages bad presentations any more than the tangled rules of English spelling and grammar encourage bad writing.

[6] In particular, almost all video content makes life harder for the visually impaired: a screencast in which someone talks over themselves typing in an editor or sketching on a tablet is tantalizing but useless to someone who can’t see the pixels. I committed this sin when I created Version 4 of Software Carpentry; I’d like to do better in Version 5, and would like to see high-profile online learning sites make some kind of effort as well.

[7] But wait a second: if video isn’t effective, why do MIT Open Courseware and the Khan Academy work so well? The short answer is, they mostly don’t: if you take out the 15% of people who can learn almost anything, no matter how it’s presented, watching videos and doing drill exercises works less well than other options. The longer answer is, watching a good teacher (and Khan is a great teacher) work through a problem, instead of just presenting the answer, moves the content into the “how to” category that video is well suited to.

[8] Research dating back to the early 1990s shows that higher-quality material improves student retention. I don’t know whether it improves it enough to justify its higher production costs, though.

[9] HTML5 will also help with version control, since I expect HTML5-aware diff-and-merge tools to start appearing Real Soon Now. Of course, I’ve been saying that for almost ten years…

[10] These days, you can wave away almost any technical objection with “it’s just more Javascript”.

[11] In my mind, the animation interface looks more like Scratch than it does like PowerPoint’s menus and dialogs. It definitely doesn’t require people to type in code, unless they want to create and share an entirely new kind of animation effect.

[12] We could even call that format XUL…

[13] “6×6″ is as big a team/timescale as I’m able to contemplate these days.

Remember those awesome pop-up videos on VH1? Thanks to Mozilla Popcorn, the new HTML5 tool for supercharging web video, the pop-up format is about to get a whole new lease on life.

Exhibit A: this wicked “Buffy the Vampire Slayer vs. Edward from Twilight” remix, created by the mash-up maestro from Rebellious Pixels. Check it out here. Then get started making your own pop-up video here.

“Hacking pop culture”

First posted in its original form in 2009, the “Buffy vs. Edward” remix video has garnered over 4 million views, been subtitled into 30 languages, and received media attention from NPR radio to Vanity Fair (“Buffy Could Kick Edward Cullen’s Precious Sparkly Emo Ass“).

The new Mozilla Popcorn-powered “pop-up” version adds a new interactive layer over top, with added annotations, commentary, and tips on protecting yourself from real-life stalkers.

The video’s creator, “pop culture hacker” Jonathan McIntosh, says the remix is all about hacking gender roles and Hollywood cultural coding — a theme he’s explored in other projects like the hilarious “Gendered Advertising Remixer,” now also available in HTML5 format.

Create your own pop-up video with Mozilla Popcorn

Want to add annotations and pop-ups to your own videos? Popcorn Maker is designed to make the power of Mozilla Popcorn more accessible to non-developers and mere mortals. Popcorn Maker’s “pop-up video” template makes it (fairly) easy for you to add annotations and context to just about any video on the web.

The software is still in early alpha version, so there’s still lots of rough edges. But you can check it out and get started now. Just pick “Pop Video” from the “Choose a Template” menu. Or have a look at the Popcorn Maker user manual here.

Remember those awesome pop-up videos on VH1? Thanks to Mozilla Popcorn, the new HTML5 tool for supercharging web video, the pop-up format is about to get a whole new lease on life.

Exhibit A: this wicked “Buffy the Vampire Slayer vs. Edward from Twilight” remix, created by the mash-up maestro from Rebellious Pixels. Check it out here. Then get started making your own pop-up video here.

“Hacking pop culture”

First posted in its original form in 2009, the “Buffy vs. Edward” remix video has garnered over 4 million views, been subtitled into 30 languages, and received media attention from NPR radio to Vanity Fair (“Buffy Could Kick Edward Cullen’s Precious Sparkly Emo Ass“).

The new Mozilla Popcorn-powered “pop-up” version adds a new interactive layer over top, with added annotations, commentary, and tips on protecting yourself from real-life stalkers.

The video’s creator, “pop culture hacker” Jonathan McIntosh, says the remix is all about hacking gender roles and Hollywood cultural coding — a theme he’s explored in other projects like the hilarious “Gendered Advertising Remixer,” now also available in HTML5 format.

Create your own pop-up video with Mozilla Popcorn

Want to add annotations and pop-ups to your own videos? Popcorn Maker is designed to make the power of Mozilla Popcorn more accessible to non-developers and mere mortals. Popcorn Maker’s “pop-up video” template makes it (fairly) easy for you to add annotations and context to just about any video on the web.

The software is still in early alpha version, so there’s still lots of rough edges. But you can check it out and get started now. Just pick “Pop Video” from the “Choose a Template” menu.  Or have a look at the Popcorn Maker user manual here.

I’m trying to be systematic about re-designing the core curriculum of Software Carpentry. So far, I’ve identified 11 common questions:

whose answers depend on three fundamental principles:

These break down into 11 more specific principles:

which in turn translate into 11 recommendations:

Here’s how I see all this mapping onto the curriculum (assuming we replace agile development with number crunching):

• The Shell: files and directories; creating things; pipes and filters; permissions; shell scripts; finding things; variables; loops
  • Q03: How can I reuse code that other people have written?
  • Q10: How can I automate this task?
  • P04: We can trade human time for machine time and vice versa.
  • P06: Programming is about creating and composing abstractions.
  • R03: Automate repetitive tasks.
  • R04: Use a command shell.
  • R06: Reuse existing code.
• Version control: update, edit, commit, and history; merging conflicts; recovering old versions; setting up a repository
  • Q04: How can I share my work with other people?
  • Q05: How can I keep track of what I’ve done?
  • Q09: How can I manage my data?
  • F01: It’s all just data.
  • F02: Programming is a human activity.
  • P01: Code is just a kind of data.
  • P02: Metadata makes data easier to work with.
  • P05: Anything that’s repeated will eventually be wrong somewhere.
  • P07: Programming is about feedback loops at different timescales.
  • P11: Paranoia makes us productive.
  • R02: Use a version control system.
  • R03: Automate repetitive tasks.
  • R08: Use structured data and machine-readable metadata.
• Basic Programming in Python: variables and assignment; repeating things; lists; reading and writing; conditionals; nesting control structures; design patterns
  • Q01: How can I write a simple program?
  • Q02: How can I tell if my program is designed well?
  • Q08: How can I get data into my program?
  • P04: We can trade human time for machine time and vice versa.
  • P05: Anything that’s repeated will eventually be wrong somewhere.
  • P06: Programming is about creating and composing abstractions.
  • R01: Use the right algorithms and data structures.
  • R11: Design code for people to read.
• Interlude: aliasing
  • P10: Sometimes you copy, sometimes you share.
• Interlude: text
  • F01: It’s all just data.
• Interlude: Booleans and while loops
  • R11: Design code for people to read.
• Interlude: Using a debugger
  • Q01: How can I write a simple program?
  • Q07: How can I find and fix bugs when it isn’t?
  • F01: It’s all just data.
  • R10: Use a debugger.
• Functions and Libraries in Python: how functions work; aliasing (again); multiple arguments; returning values; libraries; standard libraries; functions as objects
  • Q01: How can I write a simple program?
  • Q02: How can I tell if my program is designed well?
  • Q02: How can I make the program I’ve written easier to reuse?
  • F01: It’s all just data.
  • P05: Anything that’s repeated will eventually be wrong somewhere.
  • P06: Programming is about creating and composing abstractions.
  • P10: Sometimes you copy, sometimes you share.
  • R06: Reuse existing code.
  • R09: Separate interfaces from implementations.
  • R11: Design code for people to read.
• Interlude: provenance
  • Q05: How can I keep track of what I’ve done?
  • Q09: How can I manage my data?
  • Q10: How can I automate this task?
  • F01: It’s all just data.
  • P09: Let the computer decide what to do and when.
  • R03: Automate repetitive tasks.
  • R08: Use structured data and machine-readable metadata.
• Program Development: creating a grid; randomness; neighbors; handling ties; putting it all together; fixing bugs; refactoring
  • Q01: How can I write a simple program?
  • Q02: How can I tell if my program is designed well?
  • Q11: How can I make my program faster?
  • F02: Programming is a human activity.
  • P06: Programming is about creating and composing abstractions.
  • P07: Programming is about feedback loops at different timescales.
  • P08: Good programs are the result of making good techniques a habit.
  • R01: Use the right algorithms and data structures.
  • R06: Reuse existing code.
  • R07: Design code to be testable.
  • R09: Separate interfaces from implementations.
  • R11: Design code for people to read.
• Interlude: configuring programs
  • F01: It’s all just data.
• Interlude: assertions; exceptions
  • P11: Paranoia makes us productive.
• Testing: goals; tests as specifications; structuring unit tests; using a unit testing framework; design for test
  • Q02: How can I tell if my program is designed well?
  • Q06: How can I tell if my program is working correctly?
  • Q07: How can I find and fix bugs when it isn’t?
  • Q10: How can I automate this task?
  • F02: Programming is a human activity.
  • P01: Code is just a kind of data.
  • P07: Programming is about feedback loops at different timescales.
  • P08: Good programs are the result of making good techniques a habit.
  • P09: Let the computer decide what to do and when.
  • P11: Paranoia makes us productive.
  • R03: Automate repetitive tasks.
  • R05: Use tests to define correctness.
  • R07: Design code to be testable.
• Sets and Dictionaries: sets; storage; dictionaries; simple examples; longer examples
  • F03: Better algorithms are better than better hardware.
  • Q11: How can I make my program faster?
  • R01: Use the right algorithms and data structures.
• Interlude: numbers
  • F01: It’s all just data.
• Number Crunching; basics; indexing; linear algebra; making recommendations; statistics
  • Q03: How can I reuse code that other people have written?
  • Q11: How can I make my program faster?
  • F03: Better algorithms are better than better hardware.
  • P04: We can trade human time for machine time and vice versa.
  • P09: Let the computer decide what to do and when.
  • R01: Use the right algorithms and data structures.
  • R06: Reuse existing code.
• Databases: selecting; removing duplicates; calculating new values; filtering; sorting; aggregation; joins; missing data; nested queries; transactions; programing with databases
  • Q08: How can I get data into my program?
  • Q09: How can I manage my data?
  • F01: It’s all just data.
  • P02: Metadata makes data easier to work with.
  • P03: Separate models and views.
  • P05: Anything that’s repeated will eventually be wrong somewhere.
  • P09: Let the computer decide what to do and when.
  • R08: Use structured data and machine-readable metadata.

Comments and suggestions would be very welcome.

Based on the feedback we’ve received so far (both as comments and by email), it looks like we should take development methodologies (i.e., agile development) out of the core curriculum and replace it with two hours on:

1. Nothing: there’s already too much in the core.
2. Spreadsheets: because many scientists use them badly.
3. NumPy and/or Pandas: because many of them are crunching matrices/doing stats.
4. Visualization: which in practice would mean the basics of matplotlib.
5. Image manipulation: because it’s fun as well as useful, and lets us talk about binary vs. text data.

I am quite arbitrarily limiting options to those five. Please cast your vote (one vote, not three out of five) in comments. We’d be grateful if you could include a brief explanation as well.

Once again, Cameron Neylon explains things much better than I ever could:

“The impact factor of a journal is a better predictor of the chances of a paper being retracted than…of the number of citations.”

As described in the last post, we’re working on general event types that can plug in Mozilla’s programmatic content. See the Mozilla Event Menu Lite for more background.

Brett Gaylor and I took a first stab at a hack jam kit for video-makers. This kit builds on previous workshops run by Brett & the Popcorn team together with partners like Independent Television Service (ITVS) and Bay Area Video Coalition (BAVC). This piece in WIRED summarized the recent ITVS jam quite well.

This is the draft we sent to a few film festivals and other video-related programs looking to host hack jams for Popcorn. You can also grab the PDF or check out the wiki page. Let us know what you think — and if you’re interested in getting involved!

Mozilla Hack Jam for Video-Makers

What

A Mozilla Hack Jam for Video Makers is a two-day event that teams up video makers with web developers. Interactive video projects are built from concept to running code over the course of the event, using open tools and collaborative design.

Every team is expected to make a “minimum viable product” that works, albeit roughly, by the end of the hack jam.

The motto: Less yak, more hack!

Participants will learn about the power of web cinema, how to develop projects based on their interests, and about the benefits of collaboration and working in the open.

Hack jams can be hosted in partnership with Mozilla, who provides facilitation experience and extensive knowledge of key software, in particular Popcorn.js, a Javascript library for HTML5 video.

Mozilla will work with partners to ensure participants leave with both a deeper understanding of the web as a storytelling medium and improved video projects.

Hack jams can also be self-organized following this handy guide! PDF

Who

Teams consist of:

• Video-makers with an existing project
• Web developers skilled in Javascript

Each video project is paired with at least one developer. Facilitators and web designers are also key roles at the hack jam.

How

Pre-Hack Jam Engagement

Mozilla and partners identify the participating video projects. Ideal candidates are video-makers with existing video and a vision for improving it with interaction on the web.

Through lightweight interviews, each video-maker is paired with a web developer whose interests and skill-set meets the video-maker’s vision.

The newly-formed team discusses the vision determine if any further preparation should be done in advance of the hack jam.

Agenda

All the participants and facilitators meet on Day 1 for a group briefing. Demos of web cinema, including common templates and plugins, are shown and discussed. If needed, a quick crash-course on Popcorn will be provided. Each project presents it’s vision for the hack jam.

The group breaks into the small teams and determine how they’ll work together. Some might use napkin-sketches to quickly test ideas and interfaces. Some might already have code prepared. Some might address shared problems and team up. This is where facilitators can be especially helpful ensuring each team makes the most out of the time together.

Two-thirds through Day 1, projects should be writing code and creating the broad strokes of their experience. Day 1 ends with a group recap of where each project stands and would like to achieve the next day.

Day 2 opens with a quick welcome, and teams go to work on their project. The remainder of the day is a “sprint to the finish”, always with the expectation that teams will “ship” a final project at a screening and party.

A screening and party is held in the evening of Day 2 to demo final projects, collect feedback, and to celebrate all the hard work.

Before leaving, participants should decide on next steps for their projects. Examples include: continue hacking at an upcoming event, fold outcomes into an existing project, or publish results from the hack jam. Decisions on next steps are shared with the group and key stakeholders.

Resources

• At least one computer per team.
• Video-editing software as well as a fast, modern browser.
• Popcorn.js installed.
• Video files for each project.
• Reliable wifi.
• Power outlets.
• Projector with suitable adapters
• Meals – events must be catered
• Amenities such as coffee, water, and snacks.
• Travel support to the hack jam, where needed.

Case Studies

Independent Television Service (ITVS) + Mozilla, San Francisco. http://www.wired.com/underwire/2011/10/coders-filmmakers-popcorn/all/1 Video: http://mozillapopcorn.org/the-living-docs-hack-day/

“ButterCamp”, NYC, March 2011. http://mozillapopcorn.org/videoblog-buttercamp/

Mozilla Festival, London. November 2011. http://mozillapopcorn.org/what-we-made-at-mozfest/

Bay Area Video Coalition + Mozilla (For youth), San Francisco. http://mozillapopcorn.org/bavc/

Photos: CC BY-NC-SA by Jonathan Mcintosh

First, a contextual clarification: Facilitation is herein used in the context of learning. For me, facilitation is teaching, but there’s a difference in connontation for most people. For most people, “teaching” is a kind of directive transfer method while facilitation is more learner focused. There’s a nice raging debate on the topic, actually. “Teachers” who self identify as such might not be too happy with the term “Facilitator” because some think it depreceates their education and training. Meanwhile, a new wave of educators are perfectly happy calling themselves “Facilitators”; they just think of it as “facilitating learning”.

I’ve been trying to figure out whether or not being a good facilitator is something any and everyone can do. I like to think it is, but at the same time, I’ve been to a lot of sessions, workshops, conferences, classes, events and themed backyard barbeques. Ok, the themed backyard barbeques might be stretching it a bit, but the fact remains – I’ve been on both sides, facilitator and facilitatee.

As a facilitatee, I have to come to the conclusion that being a good facilitator is a personality trait.

As a facilitator, I have to come to the conclusion that any one can do it.

Facilitating learning is a personality trait because a monotone, disinterested, mentally dissociated space cadet who sounds like a prerecorded message can have a clear, concise, well crafted lesson plan and full on fail to transfer the learning objectives while an enthusiastic, spastic, sporadic social butterfly can have a random stream of consciousness unfit for human consumption because of its ridiculous disorder that changes perceptions and inspires real growth and learning. Do not underestimate FUN.

Facilitating learning can be done by anyone if they just let the fun in.

At the moment, we’re working on repackaging the Hackasaurus Hacktivity Kit to fit with the P2PU Challenges structure. The Hacktivity Kit was designed to help any and everyone learn how to run a Hackasaurus Hackjam. It inspires an almost natural teaching method that helps facilitators run sessions that use constructivist theories to build knowledge about remixing the web. The curriculum is coming along nicely.

At first, I wrote the curriculum using a fairly complex and strange narrative. However, after talking to an eighth grade English teacher working in a public school in the USA, I decided to get rid of the narrative and just focus on the process of organizing and running a hackjam. After I hashed out the draft, I started to wonder how we could create a challenge that helps a person develop the, in my mind fully necessary, personality trait of guided crazy.

Surman-san had a post yesterday called “Every event is a laboratory.” He detailed the Hive Popup they ran in Tokyo last week and talked about lessons learned. My premise in this post is that facilitation is key. I congratulate the Hive members who inspired those kids to play, hack, and remix the web. I’m pretty sure that “fun” component I told you not to underestimate played a huge part in the success of the Tokyo popup.

So. Every laboratory needs a mad scientist to facilitate the twists and turns the human psyche needs to make in order to learn. Every laboratory needs that special mixture of knowledge and enthusiasm. The question is, can the madness be taught? And should we try and create a challenge for it?

Related articles

• Hackjam Parking Lot (zythepsary.com)
• Every event is a laboratory (commonspace.wordpress.com)

With a little over a week of digestion since the Mozilla Foundation All-Hands, I’ve revised the event menu shared a few weeks back.

The most resounding feedback was: “great to see this overview, but there’s too much stuff!”

So much of the revisions in version 0.2 are about cutting back. We asked ourselves what are the clear calls to action for participants versus an overview of all the event types the Mozilla Foundation is working on.

Version 0.2

To that end, this new version is a cleaned-up, “lite” menu (pdf).** Rather than paralyzing people with too many choices, it’s about giving simple options — which of course can be hacked and remixed as preferred. This is hopefully a step towards making this model more accessible and scalable.

Together with colleagues Jess Klein, Ben Simon & Matt Thompson, we spent a while crafting the language. Let us know what you think!

Criteria

Criteria for the event names included:

• Comprehension. Mozilla has a history of rapid neologisms. We tried to stick with words commonly used, even outside of the Mozilliverse. While we are assigning specific meaning to some of the terms, many people can at least grasp part of the word and decipher what the term as a whole could mean. This is especially important for events, which will invite in a lot of new people who may not be familiar with our jargon.
• Current Usage. That said, we didn’t want to default to names not in use at Mozilla. So we tried to strike a balance between quick comprehension and currency among existing projects. That’s why “fireside chat”, “learning lab”, and “hack jam” have been retained: we’re already using these terms in our programs.
• Localization-friendly. We recognize parts of the event names are a little Anglo-centric, but we hope that at least the general term is readily translatable into other languages. If you have suggestions or feedback about this aspect, that is particularly helpful. We hope that these events are accessible across many languages and cultures as well.

Event Types

We’ve kept the same structure as Version 0.1, but focused on five events, instead of a baker’s dozen:

• Meet Up — A fun, local gathering for people with shared interests in webmaking. Meet friends, new and old, to discuss projects in a relaxed setting. 2hr – until drinks run out.
• Fireside Chat — Thoughtful, informal presentation from a subject matter expert followed by discussion. Learn about a program or webmaking idea. Online or in person. 1 hour.
• Learning Lab — A simple learning activity for the classroom, a workshop, or the pub. Learners become teachers. Suitable as a one-off or part of a curriculum. 15 minutes – 1 day.
• Hack Jam — Design, code, and build solutions to real-world challenges. Bring skills together. Test and iterate with users. Share outputs with global community. 2hr – 2 days.
• Mozilla Festival — A yearly celebration of webmaking that blends the activities above and then some. It brings together hundreds of passionate people to explore the open web and to chart the way for the future.

Each of these events will have resources that pull from Mozilla’s webmaking programs: journalism, video-making, and youth education.

As an example, you can do a Hack Jam for video-makers by plugging in the Popcorn module into the general hack jam kit. We’ll provide quick recipes for how to do that. If you’re feeling ambitious, you can then remix the event further by adding in a youth education module or a Learning Lab kit, depending on your need and interests.

At events Mozilla directly organizes, we’ll also follow the same recipes, which not only makes life easier, but also helps us understand if these tools and resources work. Dogfooding the menu, if you will. ^^

What’s Next

My goal over the next month is to work with community members and colleagues to scope the supporting resources and the platform around events so that organizers and participants have a simple way to get involved, give feedback, and run with this stuff.

A huge thanks to Henrik Mitsch and Alina Mierlus for their suggestions on this version!

Next up, I’ll share an alpha version of the Hack Jam for video-makers kit, plus give an update about the Mozilla event calendar and plans for make.mozilla.org, our new home for webmaking galore.

Images: “Meet the Makers” by Mozilla Popcorn team and “Paper Prototyping at NYSCI hack jam” by Mozilla Hackasaurus

One of the things we need to do in the next six months along with running boot camps and updating our online content is to create some sort of badging to recognize people’s skills and contributions. As we said in the proposal to the Sloan Foundation, “A badge program will provide near-term incentives for both learning and mentoring; a framework to support viral, peer-driven engagement with the program; and facilitate recognition by partner institutions and potential employers.”

We’re going to rely on Mozilla’s Open Badges project to handle the mechanics of storing and validating badges, so we only have three questions to answer:

1. What do we award badges for?
2. How do we determine that someone has earned one?
3. What do they look like?

The obvious answer to the first (and most important) question would be, “You get a badge for completing the core curriculum.” However, one of the purposes of badging is to provide a finer-grained inventory of people’s knowledge and skills, so there’s an argument to be made for giving one badge per topic, e.g., a version control badge, a Unix shell badge, a basic imperative programming badge, and so on.  The argument for is that their meaning will be clearer: if I say, “Jane knows the basics of Subversion,” that’s more immediately understandable than, “Jane has completed the core of Software Carpentry.” The argument against is that if someone has collected two hundred small badges, we’re going to aggregate them anyway (“Jane knows basic software development skills”), so why not just do that in the first place.

I’ve gone back and forth on this, but currently think that one badge for the core curriculum (“Basic Software Carpentry”) will work best. We will offer two other badges as well: one for organizing a boot camp, and one for contributing a medium-sized chunk of content (on the scale of one 5-minute video episode).

Having decided that, the next challenge is to determine when someone has earned a particular badge. The “Boot Camp Organizer” and “Content Contributor” badges are straightforward; telling when someone has mastered the core skills is not. We can tell that you’ve attended the boot camp and viewed the videos, but how can we tell how much you’ve actually learned?  “Solve this problem and email us the result” isn’t good enough: you could get someone to do it for you [1], and even if you’re honest, we can’t tell how quickly you did it, how many blind alleys you went down, how often you did something in ten steps instead of one, and so on. In the short term, I think the solution is to do assessment in real time using desktop sharing, i.e., you share your desktop with me, I give you the problem to solve, and I watch you do it.  This won’t scale to hundreds or thousands of learners, but it’ll get us through the next six months.

What will badges look like? A badge is just a small PNG file with a digital signature embedded in it (it’s a neat little hack), so the graphic design is up to us. I like our current logo, but (a) it doesn’t size down well, and (b) I’ve been wanting to redesign it anyway, since the blue-to-white fade in the background doesn’t print well on t-shirts, coffee mugs, and other media. In keeping with our carpentry theme (“We’re not teaching people how to build the Channel Tunnel, we’re teaching them how to hang drywall”), I’d like an image that combines tools like hammers and saws with something like 1′s and 0′s to represent software, but I’m a lousy graphic designer—if any of our readers would like to take a crack at it, please let me know.

Finally, and most importantly, how can we get existing institutions—specifically universities—to recognize badges in some way? As much as we’d like people to value skills for their own sake, everyone is always busy, and always has more to do than time to do it. Can we persuade a few schools to list badges as non-credit items on students’ transcripts (just as they might presently list a short course in presentation skills or entrepreneurship that doesn’t count toward degree requirements, but required some work on the student’s part)?  If so, it would give people an extra incentive to complete the core curriculum, organize a workshop, or create some content for us, particularly in a tight job market where every small distinction counts.

[1] It’s unlikely that someone would cheat on a Software Carpentry exercise, but in general, if badges take off and actually start to matter, the people who sell college students essays on Steinbeck at $30 a pop will start offering to write their online exams for $50 each.

This weekend’s Hive Pop Up Tokyo reminded me that every event is a laboratory. Events are a great places to test our products and our ideas. They provide a chance to iterate quickly, improving our products fast. And, they can be a pipeline for new ideas. This kind of labby goodness is one of the reasons I’m committed to do more and better Mozilla learning events this year.

The Hive Pop Up format offers a particular kind of lab: one where you bang different products and ideas together. Format-wise, it’s a mash up of a workshop and a science fair. Building on MacArthur Foundation’s Hive learning network concept, the event recipe is:

1. Find six to ten groups that teach some kind of web making lesson.
2. Set up shop in a big room for a day on weekend or school holiday. Give each group their own area.
3. Invite young people who are keen to play and make with technology. Schedule them in waves / cohorts (e.g. 3 hours).
4. Quickly intro the kids to each program, then let them move to whichever stations they like, making and learning as they go.
5. Watch for patterns. Take notes. Have fun.

We’ve  done two of these now. One in London, another in Tokyo. Both of them have focused on late primary and middle school kids, but you could do this for older ages too.

Apart from the actual fun and learning that goes on (that’s our actual goal and also why the kids showed up), the Pop Ups provide and opportunity for experiments, pattern recognition and quick improvement of our learning offerings.

One experiment we ran in Tokyo was to combine Mozilla’s basic Hackasaurus lesson with a short workshop on  MIT Media Lab’s Scratch. I’ll do another post detailing this, but bottom line is that we found a way to mash these two things together: the kids ‘busted a hack’ by embedding their Scratch game in their favourite gaming web site. The kids seem to enjoy this. A bunch of them kept working on these pages for an hour after we’d wrapped up the session.  More importantly from a lab perspective, we found a way to combine two important web making concepts — ‘the web is lego that you can take apart and remix’ and ‘the basics of telling a computer to do something’ — into a single hour.

There were more wins from the ‘many learning experiments loosely joined’ experience of Hive Pop Up Tokyo. We learned about a cool paper-protyping-for-interface-design Firefox add on called Domova that Keio University and Mozilla Japan have created. This is something we can roll into other learning events. We had a chance to see Jono’s Run Jump Build HTML5 side scroller in the wild as something kids were excited to play with (thanks, Jono!). We flagged the idea of mashing up Run Jump Build w/ the SVG animation elements of Mozilla Japan’s ParaPara. And, we identified a number of improvements for both the Xray Goggles and the Hackasaurus curriculum. Phewph. Lots of good and meaty stuff.

Not every Mozilla learning event should be a Hive Pop Up. In fact, the most important thing we can do right now is package up the basic Hackasaurus Hackjam so lots of people can be running those in their own local community. But we definitely should do a few more Pop Ups this year: they offer a rich way to test out our thinking and bring new ideas. These are both things we need as we critically need as we solidify our webmaker learning offerings in 2012.

PS. Hugest thanks to the Mozilla Japan for taking the leadership to make Hive Pop Up Tokyo happen. Special thanks go to Tetsuya Kosaka who really rocked it as organizer and thought partner. I look forward to doing more stuff like this with all of you in future.

Filed under: drumbeat, education, learning, mozilla