As Mark explains, it’s Webmaker Planning Season, which includes writing user stories for where we want to take Thimble, Popcorn Maker and what we build to tie it all together. A really fantastic real world user story appeared over the weekend, courtesy of Notch and his army of followers.
It started with Notch tweeting about something he was experimenting with,
Then he finds a similar experiment from Mr.doob,
And a conversation starts around the code, licensing and aesthetics.
Soon, a fan posted a Youtube video that explores Notch’s original code in detail. Notch moves his example to another community site similar to JSFiddle, but with social bits baked in.
Why’s this like Webmaker?
Notch posts something he’s proud of, gets feedback from his peers (ignoring the fact that Notch is without peer for the purposes of this example), the community dives into his code and explains it to each other (the Youtube video), others remix or build off the original code (Mr.doob, I’m altering history here and pretending that the doob code came after Notch’s original post, artistic historical license).
The whole goal of Webmaker is to bring people together, show off what they’ve learned, help each other learn and get excited about making the web.
That’s cool, so how does Webmaker improve on it?
Right, that’s the big question. Everything you saw above happened today without the involvement of Webmaker, so what are we bringing that will improve it? A few things – in convenient bullet form,
- Make it explicit – Notch learned something, he shared the learning and others built on top of it. Notch’s experiment, regardless of whether it’s on Thimble or JSFiddle, belongs in a gallery where it’s easy for others to find, share and remix.
- Make it live beyond today – Twitter tied it all together. Twitter emphasizes real-time, it would be difficult to recreate this chain of events a year from now. It would be even more difficult to recreate the chain if a personality as large as Notch hadn’t initiated it. We need to see this chain of events as a unit without detective work.
- Build and acknowledge reputation – the video commentator is a bit anonymous in the chain. He did significant work, and will help scores of learners make sense of Notch’s code. He deserves recognition for that work in a way that pushes his career, or gets him reputation in a community. (In short, give that guy a badge)
What should we build?
In this context, what is Webmaker.
- A series of tools, Thimble and Popcorn Maker lead the way.
- A gallery, currently in the planning stages, but we’re looking to build much more than a listing of projects. The gallery needs to fit a variety of roles, it should show what you made, what your friends made, and what everyone aspires to make.
- Social‘y stuff. Take the conversation around a made item to the social network you choose, find better ways to let the work flow back and forth between tools and networks.
How are the Firefox people going to tie all this together? I love Firefox, it’s my browser, but Mozilla isn’t just Firefox. Mozilla has a manifesto. We, Mozilla, are more than the sum of the people who get a Mozilla paycheck. We’re a world spanning community of contributors and zealots that believe working in the open has meaning beyond the products we produce. Mark Surman and Mitchell Baker say that very product has a semi-secret payload – Firefox’s payload was belief in the open web and open source and open standards.
The payload for Webmaker is still being worked out, but my take on it is that we build together. We learn from each other, we make each other better than what we could be alone. Given that, everything on the web deserves a button that let’s someone else remix and comment on it in whatever way they see fit. The act of creation should encourage more creation, not just consumption and +1’ing.
It’s entirely possible to take all of this and make a product that fulfills basic requirements, and doesn’t worry so much about secret payloads and manifestos – but that would be boring, and unsuccessful. Mozilla doesn’t work in boring, we work on big stuff. The success of Webmaker is a world where the internet is writable, everywhere – and by extension, the world is writable, everywhere.
For more on the make the world writable idea, watch the Mozfest 2012 keynotes.
New software products start with a vision, solidify as a product plan, and are fully realized through design and engineering. A few days ago, Mark wrote about the clarified vision of Webmaker, then Erin followed up with what that meant to Webmaker as a product. This post is about that third corner of the triangle, the implementation. I’ll mostly focus on how Webmaker has affected the architecture of Mozilla Foundation projects,
which means Jess is on the hook for a post about Webmaker design Jess writes about the design over on her blog.
The rest of this post steps through the key changes we’ve made in how we work, what we work on, and how it all fits together. If you’re interested in contributing to Webmaker as a developer, this is a good overview, you’ll need to jump into the mailing list if you want to start contributing code right way.
I didn’t read any of the prerequisites
If you didn’t read the links above, here’s the story so far — The Mozilla Foundation wants to teach people how to make the web. Mozilla Webmaker: a quick way to make, remix or tweak a webpage or
video while learning how the web works.. This means that the bulk of projects the Foundation has been working on now fall under the Webmaker mission, Thimble, Popcorn Maker, Webmaker.org are all Webmaker tools. As someone progresses in their mastery of the tools and concepts, they earn Badges which they push to their Backpack, which will one day help them figure out the next thing they should learn. There’s really more to it than that explanation, you should read Erin’s post.
If you looked at MoFo projects in the beginning of the summer, you’d see teams dedicated to a single project, each with their own platforms, project management tools, testing practices…islands of development that all got along, but mostly worked independent of each other. The teams got a little closer in the June / July push to Thimble, but we had to really squish the islands together to start working on Webmaker.
Lots of organizations would just give up and die at this point. Not MoFo, the developers here are the most easy going, open minded people I’ve ever worked with. This wasn’t an exercise in protecting turf, from the beginning it was about figuring out how to make the large vision that pulled all our products together work. There was negotiation, but every negotiation ended with compromises that each team was happy with. It was way smoother than anyone could have anticipated. These are some great people.
The biggest decisions we had to make,
- Server side platforms aren’t uniform, should we push towards a common platform?
- We track bug’s and features all over the place, do we unify the bug trackers?
- We manage the projects in the individual bug trackers, how do we express cross team dependencies?
The answers to the above are kind of obvious, not super complicated, but still took a couple of weeks to work out. Picture a montage of lot’s of discussions about tools, failed attempts to organize with the wrong tools, wrong approaches to the right tools, all ending in a giant group high five freeze frame.
Here’s where we ended up,
- Asana tracks the projects, specifically new features and daily tasks. Asana is where the engineers go to figure out what to work on next, and where the product teams go to figure out what should be built after that. It’s a great tool, really well thought out, and easy to use. We still need to work out the details of what it means to work in the open, and build a community around the development of the products with Asana, but we’re confident we’ll figure it out.
- The whole development team meets with the whole product team once a week. By the end of the meeting, engineers know what they’re working on until next week’s meeting. Sounds ideal, right? It’s a total lie. It’s not this easy. It’s a bunch of work. Every completed task is a victory worthy of a million high fives.
- Server side decisions are still up to the individual product teams, but a series of services will decouple the architectures enough that there’s no advantage to unifying the platforms. Which means we’re still proudly a Djangoplaydohpythonnodejsexpressmysqlmongodb shop.
The Webmaker Roadmap in Asana
Services We Need to Build
Once we had the logistics of how we were going to work as a team worked out, we started talking about what exactly we were going to build. This is going to be an on-going conversation over the next couple of months, but we made a few decisions immediately that we’re moving on now.
Single Sign On – If you sign into your account on http://thimble.webmaker.org, you should be signed into http://popcorn.webmaker.org automatically, and you should be able to manage your profile (including seeing what badges you’ve earned) on webmaker.org. Persona manages authentication, but we need a service that authorizes an authenticated user to an application, and keeps the user logged in across apps.
Open Badger – I’ve written about it before, but to issue badges across the applications, we don’t want to duplicate the work of creating and maintaining badge systems.
Unified Publishing – All of our projects publish something, each of them use different storage systems and different security models. If we offer publishing as a service to our tools, we can consolidate backups, consolidate security and make developers feel are warm and special.
Project Database – Before you start working with a tool, you pick a learning project. The projects are described in a couple of different ways. If you want to make a list of available projects across tools, it’s not easy. It should be easy. The same goes for making a list of everything everyone has ever published with the tools, or anything a single user has published with the tools. We need services that make these queries simple.
Make it all look good – Not really a service, but everything needs to look like it’s all one. Jess, Chris and Kate are way on that. They already have a three stage information architecture in mind, and the start of a style guide. We’re still developing new stuff as they figure out the design, so engineering is working really closely with these folks to keep things fast and loose.
Make it work for everyone – Webmakers cross languages, cultures and devices. We need a common way of internationalizing, localizing and making the apps and sites accessible to a variety of devices.
Build it Right
We’re going to bring a lot of new work to Mozfest, some will be in production, some will be there purely to get feedback. It’s going to be an amazing couple of days. MoFo engineers are going to spend the time working with people working with their tools, figuring out how to make them better. MozFest is our next big milestone, it’s also our next big proving ground. We refuse to release bad products, so all of our timelines are based around the question, “how much time is it going to take to put something out that we can all be proud of?” The best way to figure that out is to start working and see how things shape up, if you want to be part of the discussion, join the Webmaker mailing list, or join our weekly community call.
A few days ago, Mark Surman wrote a blog post, Making tools for webmakers. I love the opening line, “We want everyone to tap into the full creative power of the web.” That’s a great mission. The rest of the post is a review of what we’ve done towards that mission so far, and some direction for the next few months. We’ve been talking about the ideas in the post inside of MoFo for some time now, trying to figure out what’s missing from the tools, what it means to learn on the web, and how to support the teaching goals of the Foundation with the software the Foundation is producing.
I’ve been focused on the idea that we need a central framework to hang all the learning pieces MoFo is producing off of, so that there remains a large amount of flexibility in the ways someone can interact with our tools, but without having to recreate a significant amount of architecture with each new tool feature.
Some constraints (fun-ppurtunities!) I had in mind,
- We want lots of data around the effectiveness of the learning.
- We want to give people a learning path, but also let them mess around on their own.
- Features should speed time to release, not throw up more roadblocks or add to the workload.
A Webmaker Project
The Summer Code Party is using Popcorn Maker and Thimble for most of the online webmaker activities. Both tools have a similar project pattern,
Pick a Project
Both Thimble and Popcorn start picking a project.
Pick a Thimble Project
Pick a Popcorn Maker Project
The metadata carried with the project is different, the assets are different, but the essential thing you’re doing is the same – picking something from a list of options, with information about what you’ll be doing in the project.
Work on the Project
The learner works on the projects inside of the tools.
Inside Popcorn Maker
Publish the Results
After the learner finishes the work, they publish. The publish step is similar in both tools, with Popcorn requiring a user account, but no user account for Thimble. The Popcorn team has had a gallery in the works for a while, which will change the way we publish projects, creating a gallery of published projects. Thimble has similar gallery in mind, but only publishes the finished project.
Thimble Publish Dialog
Popcorn Publish Dialog
Modularize all the things!
Given the similarity between the two tools, it makes sense to break out the common parts into modular tools you can mix and match to build future webmaking tools. The two obvious pieces are the project builder, and the gallery tool. In both cases, they’re responsible for either creating or displaying blobs of html & static assets. Both contain tool specific metadata, but they’re not so wildly different that we couldn’t make a base tool to create as much as possible, then extend it to include the tool specific bits. The gallery is the essentially the same thing – display a bunch of output html, plus some static assets.
All that said, it’s not a slam dunk, the details are…the details. There’s a fair amount of work contained in these humble paragraphs, so buyer beware. Let’s focus on the positives – if we’re working off a common codebase, we save time and energy. If we deploy these things as services, then we only need to work through security audit once. The bulk of our time should be focused on making the learning tools awesome, not recreating a gallery or a login system or a whatever. We’ll have all the lego pieces, if we build the sockets right, every day will be an exciting lego land adventure, rather than constant weeding and tending and digging.
OpenBadger, gluing it all together
So – lots of moving parts, everyone wants modular pieces, how do we glue it all together?
Badger Glue Fixes It All
The three parts to any webmaker project – pick, make, publish, match the three pieces of a badge pretty closely – criteria, evidence, assertion. The criteria are the list of things someone needs to do to earn the badge, the evidence is the result of them doing what the criteria asks, and the assertion ties it all together in badge form. The intent of the three pieces is to create a badge, but it’s not strictly necessary. We could use the three pieces as the scratchpads that each stage in the webmaker process looks to understand the context around the step it’s being asked to complete. Each of the three major pieces could be built on top of OpenBadger, like this convenient ASCII drawing illustrates,
ASSESSMENT BUILDER /
WEBMAKER.ORG THIMBLE / POPCORN MAKER GALLERY
+-------------------+ +--------------------------+ +-------------+
| | | | | |
|Create a Project +-|----|-> Do the Project +------>| |Publish |+---------------> MASTERY!
|/ Pick Project | + | + | | | +
| | | | | | | | |
+-------------------+ | +--------------------------+ +-------------+ |
| | |
| | | | |
| v v v |
| Create Criteria URL Ping Complete Confirm |
| Evidence URL Created Issue Badge |
Arrows pointing to OpenBadger are either webhook API calls, or posting next-step metadata.
By splitting the direct connections between the pieces, and passing them off to OpenBadger, we can leverage OpenBadger for all sorts of clever analytics – regardless of whether we’re offering a badge for a particular project. That’s an important note – OpenBadger doesn’t need to limit itself to issuing badges, it’s a platform for any sort of learning activity, if we use it in a way that makes sense. OpenBadger isn’t about issuing the sticker at the end of a process, it’s about keeping track of the steps involved with an online learning project.
The most Meta of Metadata
We’re not the only people in wide world web looking to make exchanging education data easy, LRMI is a Creative Commons project to bring common metadata to learning resources. If we use LRMI as a basis for our criteria url’s, and then extend it with tool & display specific information, we’ll be able to take advantage of other LRMI parsing infrastructure (like the Learning Registry).
Over the next week or two, we’ll be discussing the plans for Webmaker tools, and start working on making everything fit together in early August, with a launch of all kinds of new stuff for Mozfest London in November. Between the Thimble, Badges, and Popcorn teams, we have some super smart developers. I’m hoping they tear this blog post apart, rebuild it in a way that makes sense to them, so we can start pounding keyboards in dramatic software development montage sequences that end in high fives, hugs, and exploding fireworks over Big Ben (because we’ll be in London…get it?)