May 20, 2013 § 3 Comments
Open Badges started as a modest experiment: build open source badge issuing software for ourselves and others. As momentum around this experiment has grown, it feels like the opportunity is bigger: we could build openness and user empowerment into how learning — and professional identity — work all across the web. With Open Badges 1.0 out there in the world, now is the right time to ask: where next for Mozilla and badges?
When Mozilla and MacArthur Foundation first started work on Open Badges about 18 months ago, the plan was to build a badge interchange standard (like SMTP for skills) and a collection of open source software for issuing and sharing badges (Badge Backpack, Open Badger, etc.). We’ve built all these things. And we’ve put up a reference implementation that Mozilla and others are using. This was really the limit of our original plan: build some basic open tech for badges and put it out there in the world.
The thing is: there has been way more excitement and pick up of badges than we expected. Even though Open Badges only launched officially in March, there are already over 800 unique providers who have issued almost 100,000 badges. We are also starting to see the development of city-wide systems where learners can pick up hundreds of different badges from across dozens of learning orgs and combine them all into a single profile. Chicago is the first city to do this (June 1), but Philadelphia and San Francisco are not far behind. And, this is just the tip of the iceberg: orgs like the Clinton Global Initiative and the National Science Foundation are focusing on badges in a way that is likely to drive even more educators to pick up the Open Badges standard, making their badges interoperable with others.
Of course, the fact that educators and policy makers are interested in badges doesn’t represent a victory in itself. It just shows momentum and buzz. The real opportunity — and the real impact — comes when learners and employers get excited about badges. Mozilla never planned to build offerings for these audiences. Increasingly, it feels like we should.
In the Internet era, people learn things online and out of school all the time. Whether you want to make a web page, knit a sweater or get better at calculus, the internet makes it easy to learn on your own or with a group of friends outside of a school setting. However, there is no good way to get credentials or recognition for this kind of learning. And, even if there was, there is no trusted, verifiable way to plug that recognition into Facebook, About.me and other places that make up your online identity. People have no good way to show ‘what they know’ online.
Similarly, employers are increasingly turning to the internet to find talent. They use sites like LinkedIn that let you search online resumes. Or, increasingly, to sites like Gild and TalentBin that use data mining to find potential hires. The problem: these services do not offer granular or variable skills profiles. And, with some of them, there are significant issues around privacy: people are being offered up as potential hires without even knowing that these sites are collecting data about them.
Mozilla could offer a distributed, open source and privacy-friendly solution to problems like these. We could help learners show their skills in all their online profiles and also help employers search for talent reliably. However, to do so, we’d have to build a Firefox-quality offering for learners and employers on top of Open Badges. While this hasn’t been our focus up til now, I’m thinking more and more that this is something we should consider.
In some ways, there is a parallel to Gecko and Firefox. Gecko provides the underlying platform for shaping standards around our vision of the web. But we need a popular consumer offering like Firefox if we want this vision to actually become relevant in the market. Right now, with Open Badges, we’re mostly just playing at the underlying standards layer. If we really want to shape how learning and professional identity work on the web, we probably need to build our own offerings directly for the people who most want and need badges.
Now is the time to be looking at where the opportunity is in this space. Momentum and demand is amongst educators is growing. More and more start ups are appearing in the badges, portfolio and skills spaces. And likelihood that badges will be important for learners and employers is growing. We need to be asking ourselves: how can Mozilla — and its values — shape this space?
With this in mind, Erin Knight is leading an effort over the next few months to look at different badges product options. She’ll be providing updates on her blog. And I’ll be summarizing here as well. If you have ideas on where Mozilla should go on all of this, we’d love to have you involved as we think this through. Comments here on this post are a good place to start.
February 13, 2013 § 4 Comments
‘Making is learning’ is a big theme for Mozilla this year. It’s at the heart of Mozilla Webmaker. More importantly, it’s the north star idea guiding the grassroots mentor community we’re building around the world. We want millions more people to get their hands dirty with the web. And we expect they’ll learn something as they do.
I realized today that we need to add two concepts into this theme: tinkering and social. This thought came from a good discussion on the Webmaker mailing list that starts with the question ‘is making learning?’ Rafi Santo both asked and began to answer this question:
The short answer: yes, but it’s complicated. The longer answer is that the best maker-driven learning is never just about the making. It’s about all the things that happen around the making. That initial spark of curiosity, the investigation and early tinkering, the planning and research that follow, the inspirations and appropriations from other projects, the prototypes, the failures, the feedback, and, perhaps most importantly, the iterations upon iterations towards a better make.
He then went on to say:
I’m willing to say that someone is always learning something when they’re making, but they learn best when it entails the sort of process, community and well configured structures of participation.
In part, the discussion around Rafi’s post is a debate about tag lines. Should we rally people under a ‘making is learning’ banner? Or should we be more subtle like ‘making as learning’ or ‘make to learn’? We’ll probably do the later.
However, there are also two important substantive points worth pulling out from the conversation: a) it’s the process of making that drives learning and b) the best learning happens when the making is social. Both of these points are critical to the success of Webmaker.
The process point may be obvious. It’s not just what I made, it’s the journey of the making. But it’s worth calling it out explicitly. Mozilla Rep Emma Irwin writes in response to Rafi’s post:
This spoke to my own learning in programming. I think I learned (and got confidence) more from debugging and being stuck than simply making. The sense of accomplishment of overcoming things that seemed really hard at first have motivated me more than anything. I think those experiences are why I am crazy enough to think I can ‘teach’ now.
Designing tinkering and iteration into Webmaker is critical. A first step is creating content built from the ground up for remix. And, then to support that with tools that let you tinker and play with that content, and share it again with your friends. The idea is to use remix as an onramp to tinkering with the web.
You see an early example in Jacob’s awesome Valentine’s video project on Webmaker.org. The thing about this video: it is designed to be forked. It wants you to add your own photos and change the text. It’s an invitation to tinker. It’s an early invitation, to be sure: we clearly have a lot to learn about how to do this well. But it’s clear to me that this kind of design for tinkering is ‘thing #1’ of key things Webmaker needs to pull in from this conversation.
Rafi’s other big point is about social: we learn best when we make together. Making together can mean a lot of things. At events. In school. With friends at home. In IRC. On Facebook. Etc. What all of these things have in common is that I can see what you are making and you can see me. We can critique each other. We can help each other. We can fail together. We can iterate together. And we can laugh together. Which makes learning funner, faster and deeper.
Making it easy to ‘make things together’ is ‘thing #2’ that Webmaker should pull from this conversation. Making it easy to riff on content on Webmaker.org and in places like Facebook will be a part of this. But, as Rafi hints in his post, the most important factor here won’t be tools and web sites: it will be people. This is why the building a global mentor community is such a huge priority. Everyone needs a place where they can just show up to make and learn. A place filled with people. And a place you can find in 100s of cities around the world. Building on Hive and ReMo, I think Mozilla can create this place. It’s what we want our mentor community to be.
Anyways: thanks Rafi, Emma and others for getting this conversation started. It’s the kind of leadership this nascent Webmaker community needs. And it’s a great way to dig into what do we really want to build together with Webmaker.
September 25, 2012 § 9 Comments
We’ve been honing our description of Webmaker recently. Partly, this is so we can explain Webmaker to the world. But it’s mostly aimed to clarifying what we’re building and who we’re building it for as we move into the next phase of development.
At a recent meeting in Toronto, Erin Knight led a set of discussions on this topic. I came out of these discussions with four big takeaways:
1. Webmaker is a peer to Firefox and FirefoxOS.
Mozilla has big priorities right now: the web on the desktop; the web in the mobile environment; and web literacy. We need to start positioning Webmaker in this context, showing how Mozilla’s three big bets / priorities all tie back the same mission.
Also, we need to make the link between the value of a phone you can re-program because it’s made from the web (FirefoxOS) and the value of knowing how the web works (Webmaker). Getting web phones into the hands of millions of skilled and creative people is the key to a next wave of innovation on the web.
2. We should describe Webmaker by simply explaining what you can make.
We need to describe Webmaker more simply and concretely. We’ve been able to say ‘Mozilla wants to create a generation of people who know how the web works and can reprogram it.’ But describing what we’re building to make this happen has been difficult. We took a shot at fixing this in Toronto:
Mozilla Webmaker: a quick way to make, remix or tweak a webpage or video while learning how the web works.
While this isn’t quite right yet, it opens up an important new direction: we should be explaining what you can make with Mozilla Webmaker. This creates a more tangible picture in people’s minds and helps them understand how they can engage. I’m hoping others can come up with better wording than what we have above, but based on the general approach of saying what you can make.
3. Our audience is people with something to share.
Up to now, we’ve been a bit fuzzy about who we’re targeting with Mozilla Webmaker. In Toronto, we narrowed in on ‘people how have a maker attitude and something to share’ as a core audience.
There are two pieces to this. The first is is about an approach to life: one that involves tinkering, remixing and iteration. The second is about having made something that you are proud and excited about, something that you want to share or show to other people: a picture you took; a video you made; a game you’ve modified; a big idea you’ve dreamed up. We build the needs and desires of this audience into our design process as we work on the next phase of Mozilla Webmaker.
4. Educators are also a key audience.
During the last thee months, almost 700 people organized Mozilla Webmaker Summer Code Party events. Whether they gathered 100 people or simply brought a few friends around a kitchen table, these people have played a critical role in getting Mozilla Webmaker off the ground. And they have done so because they care about inspiring and educating others about the creative potential of the web.
Personally, I hadn’t really thought about this group as one of our key audiences before. But clearly they are. These are the first people to ‘get’ what we’re trying to do with Webmaker and to feed back in to help improve it. Like the early adopters who first installed Firefox on other people’s computers, these grassroots educators and evangelists could be the core of our global community. Over the next couple of months, we need to figure out ways to more actively help them and bring them into what we’re building.
These four insights aren’t particularly radical. They fit with where we’ve been going with Mozilla Webmaker for the past year. However, I do think they make it easier to explain what we’re doing. They also offer increased clarity on what we need to be building and who we need to be building it for over the next six months. Erin is going to do her own post on this aspect of the Toronto discussions, looking at how we practically pull all the pieces of Webmaker into a more cohesive offering.
June 21, 2012 § 12 Comments
Mozilla Webmaker takes its first big step this weekend: asking people to help out. And, just as important, asking how we can help others working for the same cause.
Why? Because getting together with people to make and learn is essential if we want to build a generation of webmakers. It will fuel the community we need to reach our big goals. And, more immediately, getting people together will help Mozilla figure out how to work well with partners and to identify potential community leaders (is this you?).
The good news: many of you have already stepped up to help. There are already 394 Summer Code Party meetups and events in 320 cities and 67 countries scheduled for this summer. And, if all goes well, people will continue to do more and more events over the course of the summer.
Also, we’ve had a great response from partners who share Mozilla’s philosophy and goals: helping people learn how to create cool and powerful things on the web. Tumblr. CoderDojo. The London Zoo. Codecademy. Young Rewired State. Creative Commons. The San Francisco Public Library. NESTA. DoSomething.org. Code for America. Campus Party. And dozens more.
We’re stoked to have these partners are involved, and we also hope we can help them by connecting them to new communities and promoting their work. Helping partners succeed is critical to the success of Mozilla Webmaker overall.
Of course, we’re still just planting our first seeds this weekend. Mozilla’s Webmaker tools are still very basic (I’ll say more about our long term plans soon). And, we’re still in the early days of figuring out how to organize the community around our making and learning goals. But you have to start somewhere. You have to plant seeds.
Which leads me to a second ask: help us grow these seeds. Mozilla Webmaker is premised on the belief that we can build a global community of people who share our goals. We chose Summer Code Party as our first big step because we know we need to start building this community early: to figure out how to organize things; what tools people need; and how we can help others working on similar projects. So, jump in. Push us. Help out. Ask for help. Also, be patient. Growing things takes hard work from alot of people. And it takes time.
June 6, 2012 § 12 Comments
Later this month, we’ll be releasing Mozilla Thimble. Thimble is a simple web page editor combined with a series of ‘projects’ that help you learn the basics of HTML and CSS. The idea is to get people to learn basic web coding by just diving in and making something. Thimble projects make that easier by giving people guidance and a head start.
Thimble will go live just in time for our Summer Code Party campaign that kicks off on June 23. We want people using Thimble at their ‘kitchen table’ events, so I thought I should give people a preview of what’s coming.
The first thing you’ll see is a gallery of Thimble projects. The initial projects are designed to grab the interest of 8 – 14 year olds and to invite them to start making. We’ll be rolling out projects for older teens and adults later in the year.
As a part of this ‘interest grabbing’ approach, a number of the projects have been developed by organizations that already work with young people. This one is from the London Zoo. It teaches basic HTML and a bit about endangered species at the same time.
The Thimble interface itself is a simple side-by-side web page editor based on Code Mirror. The left pane is the code, and the right pane is the page preview rendered in real time.
The project pages are a mix of instructional comments and actual page elements. In the London Zoo Awesome Animal Builder project, the aim is to create your own species by combining image files from real endangered species that the Zoo wants you to learn about.
Here I was able to change the background of my species picture by changing the CSS class. As the code comments explain, I can choose between ‘ocean, rainforest or desert.’
If you’re new to HTML and CSS (that’s who this is aimed at), we’ve put in a bunch of features designed to help you if you get stuck with tasks like this. For example, you can click on any tag to get info on what it does.
Also, we’ve included pop-up hints that help you figure out what the right syntax is for a particular element.
After changing my CSS class (above), I then started moving different PNG files from different species into the frame with the question marks at the top of the page. These files are all given to me lower in the page along side info about the real endangered species. All I have to do is cut and paste the image URLs in order to build my animal.
And, voila! After moving a few more image URLS I now have a completed animal. I’ve also learned a) how headline tags work in HTML, b) the idea that CSS can be used to change the look of a major element of a page and c) that images in a web page are just references to a file somewhere on a server.
These may sound like small things to learn — but it’s exactly these small things we want people to start with. There are other projects in the gallery that deal with more advanced HTML and CSS topics. And, in a later release, anyone will be able to submit a project page to teach whatever aspect of web development tickles their fancy. Our hope is that Thimble can become a ‘Wikipedia of webmaking lessons’, which would be an awesome resource for the world to have.
Early next week, we’ll release a preview version of Mozilla Thimble to people who are organizing Summer Code Party events. Most of these events are small and short — just you at your kitchen table or in your living room teaching two or three people a bit about how to code for the web. If you want to organize an event like this (and see the Thimble preview), sign up here on the Mozilla Webmaker events site.
April 30, 2012 § 3 Comments
Small webmaking events that you can run in 10 minutes are a central part of the Summer Code Party concept. We’re calling these ‘kitchen table hackjams‘. But, really, they are just you sitting with two friends (or two kids, or two parents) doing a very tiny starter web project. The idea is to have fun and learning something.
We started beta testing this kitchen hackjam concept a few weeks back. I did one with my two sons (Tristan is 12, Ethan is 10) and a friend (Rowan, 10). We sat down to play with the LoveBomb prototype, a tool that introduces basic HTML by inviting people to edit a greeting card.
A learned some good things and bad things about the process. Three highlights:
- It’s possible to do a quick webmaking session with almost zero preparation or notice. I proposed the event and we were doing it five minutes later.
- You can do alot in 10 or 15 minutes. We’d basically finished the ‘lesson’ in that amount of time. Then two of the kids got bored (my kids) and one of the kids (Rowan) kept tinkering.
- For older kids especially, relevant content is key. Tristan gave the ‘toy’ content in the LoveBomb at ‘WTF is this?’ reaction. He’s a regular YouTube game commentator. If he was going to learn HTML, he wanted to be making something ‘real’.
At least half a dozen people ran and blogged about their own kitchen table beta tests. Here is a list of postings that I know about:
- Family + kitchen table = hack jam, Lainie DeCoursy
- Kitchen Table Beta-Testing, J Dytrych
- Beta Testing Kitchen Tables, Jess Klein
- Our Hackasaurus Kitchen Table, Peter Rawsthore
- Scaffolding / tips for kitchen table jams, Peter Rawsthorne
- Kitchen Table Beta with Adults, Laura Hilliger
- Initial Distill of Kitchen Table Lesson, Laura Hilliger
Update. Matt Thompson posted this awesome ‘Webmaker Recipes 101: How to host your own kitchen table hack jam‘ just after this went up. Worth the read.
April 26, 2012 § 9 Comments
Kicking off on June 23, we’re calling this experiment the Summer Code Party. It’s an invite for anyone who wants to teach — or learn — webmaking to spend a few minutes building something with friends. Like the Product (Red) campaign, it’s a big tent for anyone who shares our goal of a more web literate planet. Tumblr. Girls Learning Code. Soundcloud. CoderDojo. Creative Commons. etc. Over a dozen partners are already signed up.
The most basic version of participation: do a small Hackasaurus project with two friends around your kitchen table or in your living room. Taking a cue from Jess and Atul’s LoveBomb prototype, we’re developing half a dozen small starter projects that will make this easy. Of course, the hope is that people will do this more than once after they’ve tried it — but even a single kitchen table event is a great way to show people how the web works.
In addition to Hackasaurus projects, we will also offer up a collection of DIY web projects from partners. For example, we’re working with Tumblr to develop some well-commented templates that both help people make their Tumblr look cooler and help them improve their HTML and CSS a little. Other partners will be posting their own small projects on our wiki.
Some partners are taking on more ambitious projects under the Summer Code Party banner. For example, Girls Learning Code is hoping to offer a week long summer camp at the Mozilla Toronto office. This will cover HTML, CSS, Python and Scratch. Other partners will simply plug their existing summer code efforts into the Party, sharing out what people are learning and making with people around the world doing similar things.
Which brings me to how this all fits together: everyone will be invited to share out what they’ve made, both online and at a series of local events in September. The best projects will get badges. And the best local organizers and instructors will get an invite to the Mozilla Festival in London to help us figure out how to improve our webmaking tools and grow out our community.
For now, there are three ways to get involved: 1) Put your name of the list of people who want run a small code party at home or in a cafe; 2) Sign up as a partner or collaborator; and 3) Put yourself on the volunteer list for our June 23 and 24 kick off event. Or, if you want to get even more involved, join one of our weekly Webmaker conference calls. They happen every Tuesday.
Would love to hear ideas, reactions and partner leads. This should be fun.