Comic by Toothpaste For Dinner

I can’t help but think of that fact when I glance over the list of statistics compiled from the 450,000 leaked yahoo passwords today.

5% of folks used 12 or more characters in their password, which is really commendable when you’re trying to prevent folks from guessing your password.

Unfortunately, when your passwords are stored in plaintext, the way that yahoo did, it’s kinda like adding extra locks to your door when someone else has left a window open.

The more I thought about it, the more I realized that there are still some big questions out there about what we mean by “instructor community”, and why we want them, and why they want us.  Here are my rough notes while thinking about this.  (Including some thoughts by Mark Surman.)

Three classes of instructors:

• 1) Already teaching “web making”
  • help guide their content to stuff we find important, via tools/curriculum/teaching culture that lean in that direction
  • help them expand?
• 2) Already teaching folks, maybe not web making. (eg: camp instructor)
  • inspire them that this would be fun to teach
  • make it seem easy to teach
  • help them learn it themselves
  • provide tools, curriculum, etc.
  • success stories?
• 3) Second-generation teachers: folks we could teach how to teach, and then they might. (ie: the learners becoming the teachers)
  • encouraging existing instructors to identify these stars
  • and providing a single pathway once they’ve been identified
  • lower barriers to teaching
  • teaching the teachers
  • how to host events, etc.
  • hooking them up with existing teachers to learn from

That first-touch experience:

• Meet an instructor at a conference, they “want more info” about teaching webmaking.
  • Where (URL) do I send them? How do we follow-up?
  • What do we offer them when they get there? What might they do w/ what we offer?
• We discover someone already doing this stuff.
  • What is our ask / offer re: doing ‘our stuff’ in addition to ‘this stuff’?
  • How do we tap them in? (mailing list, call, etc.)
  • How do we keep them engaged? why bother with us, rather than going alone?
• Instructor finds us via our tools, search engine, or media, etc.
  • How do they discover the instructor community from there?
  • What are the asks / offers? What can they DO right away?
• Instructor identifies a star pupil who’d make a great future teacher
  • How can we help turn that into a conversion?
  • How do we pipeline / onboard the potential teacher?

Providing them with things they find useful

• Inspiration
  • …?
  • point at each other / a peer group (mailing list, calls, MozFest)
  • mozillawebmaker.tumblr.com (feature good teachers / students here)
  • have dedicated folks (volunteers?) welcoming new people
• Content / curriculum / tools
  • webmaker.org, but where on the site?
  • email newsletter or just our mail list, regular ‘curriculum highlights’ or ‘try this’ tips
  • Teach them (so that they can teach others)
• …?

Providing them with reasons to contribute back

• [what are the reasons? ]
• How can we help make this feel like a movement that they are a member/hero of?
  • Showcasing other folks’ work, their own work, etc. Showcasing metrics.
  • Make them want to be a part of it, and able to see how their contributions matter.
• Lowering the barrier to entry for contributions
  • We shouldn’t need to be directly involved. Make clear processes. Then make those processes scalable, etc. Eg: “So you want to localize Thimble! Awesome! Here are the steps.”, or “Anyone can reply to #webmakerquestions (or whatever)!”
• If they do contribute back, making it a positive experience
  • Have a time-to-reply on all github issues as a MoFo standard
  • Have dedicated folks thanking them, keeping them engaged, etc.

These are important questions because I believe they should shape our goals.  For example, if we believe that what we’d be providing instructors with is A, B and C, then we should make sure to actually do A, B and C.

Lots of open questions, though.  I’d love any thoughts that you might have!

“Teach a man to fish and you’ll feed him for a lifetime.

Teach a man to teach fishing, and you won’t have to go around teaching fishing for the rest of your life.”

… okay, it’s a little less catchy than the original.  And, honestly, we already have so many overfishing problems in the world that this probably isn’t the right analogy.  But you know what I mean!

We’re at an interesting point in the Mozilla Foundation.  We’re in the middle of our Summer Code Party, and we’re starting to look at the roadmap for our tools like Thimble.  And, of course, there’s a million things we want to do with it.  From enabling javascript, to internationalization, to badges, to a gazillion other things, there’s a lot we want to do, and easily enough work for several developer-years.

There’s sort of two solutions to this problem.  One is to scale our engineering efforts: become a software company with tons of developers, engineering managers to manage them, product teams, UI teams, managers for those teams, etc.

The other solution, and one that feels more Mozillaey to me, is to use the developers we do have to build tools / processes / etc. that empower everyone else in the world to do the fishing.

For example, one of our top feature requests is to create a simpler version of MDN (the definitions we link to in Thimble) that would make sense to novices.  This seems like a great opportunity to create a quick interface to allow anyone out there to provide/edit the definitions.  If we open it up to the world, then not only can it evolve at the speed of the web, but we can also get things like localization.

There are often lots of folks who want to help and participate, but like all of us, they don’t want to do it if it’s going to be a lot of work to just get started.  These things have to be easy, designed processes.  That’s not to say that they have to be complicated.

Compare and contrast two tech support systems.

1) A form that you can fill out on a webpage somewhere to ask questions.  It emails an internal list, and someone there answers the question.

2) A twitter hashtag where you can ask questions.  Suddenly not only can internal people answer the questions, but maybe you know the answer too.

It’s a good example of how designing for community participation doesn’t necessarily mean creating a complicated tool or program.  It just means including participation as a first-order design principle.

There’s absolutely no way that the Mozilla Foundation can personally host events to teach web making to the world.  But I do think that if we do this right, we can build a movement that others build on, and make their own.

We can teach people to teach people to teach people to fish.  And soon there will be no fish left in the sea.  (But in this case, that means “everyone learns web making” so it’s not quite so ecological disastery.  … I hope.)

What do you think?

The big caveat here was that the students already had:

1) Two days of Python.  (In other words, programming wasn’t brand new.)

2) Two days of HTML/CSS.  (So writing for the web wasn’t brand new.)

Overall, I’m going to say that the lesson plan was a stunning success.  The kids picked it up remarkably quickly.  There was enough open-endedness in the activities that the faster kids had stuff they could work on, and most of them managed to get their very own image search engine working by the end of the day, which is awesome.

Some of the kids had questions that indicated that they wanted to better understand what was going on under the hood.  One example of this was I got two questions about how Javascript’s passing-a-function-as-an-argument worked, though nearly everyone else was happy to just accept it as “you put a name of a function as the third argument, and that’s what’ll get called later”.

There’s only three big things that I’m going to change when I run this next time in August:

1) I don’t think they reeeeally understood how APIs work; at least not deep in their bones.  What I mean by this is that they were able to rattle off the definition back to me, but further probing revealed that I don’t think they actually understood that when they called the flickr api, flickr was giving them information that they did not have hardcoded anywhere.  They were talking to a different computer.  They were one half of a two-computer conversation.  That said, they’ll be writing their own backend later this week, so by then I’m sure they’ll understand it better.

2) I relied pretty heavily on “this works just like foo in Python”.  While that’s fine for teaching these kids, it means that the curriculum isn’t reusable with a group that doesn’t have those two days of Python experience, so I want to re-think this a little.

3) A few kids were pretty confused at the end about best practices in terms of when to use HTML versus CSS versus JS.  This is a reasonable confusion since it is confusing.  But I want to give some thought to how to better break down some rules of thumb for them.

So there you go.  One student later blogged:

“

Today we worked on JavaScript, using the JQuery library. Though I do know some JavaScript through Codeacademy [...], I never really formally learned it like Python or Java. It was nice to learn all the things that make like easier. Like how [...] importing the library was inside the html. I really like JQuery.  We made some cute animations and then an image search engine for flickr. We also looked at lots of cat pictures. That made me happy. This class made me hate JavaScript a bit less now that I’m not frustrating about using a language before getting to learn it.

“

Hating Javascript a bit less?  That’s all any of us could ask for!

Source: Abstruse Goose

Want in on the action?

• Find an event near you, or
• Create your own <– It’s easy, and can be as simple as gathering a few friends in your living room this weekend.  Which you were gonna do anyway, right?

This huge convergence of awesome has been the work of sooooo many people.  Big shout outs and twinkles to all of them!!

Make sure to get plenty of sleep tonight, because the party’s just gettin’ started.

For the interested, you can take a look at my Javascript lesson plan here.

One of the things I’m kinda excited about is trying out a totally different way of teaching JS.  First off, the kids will have already been introduced to both HTML/CSS and Python: a few days of each.  But most importantly, I’m gonna try diving straight into making things.

Changing colors dynamically, moving shit around, animation, building your own image search engine, etc. they’re all in the first few hours of learning the language.

What I’m not touching on is the fundamentals.  ”This is an array”.  ”This is passed by value, this is passed by reference”. “This is an object.”

It’s an interesting (and potentially dangerous) way to approach this stuff.  For example, they won’t have a memory model of how a lot of these things work, which I suspect is going to really hurt debugging.  But we’ll see.

On the other hand, I suspect we’re gonna get a lot more enthusiasm from the kids than we did with the same class last year.  It’s kinda hard to keep them awake through yet another syntax lesson.

Anyway, I’m still iterating on the lesson plan.  (And it doesn’t contain all my voice overs.)  But feedback welcome!

Today we are proud to launch a new Mozilla Webmaker app to the world. Meet Thimble, the new tool that makes it incredibly simple for anyone to create and share their own web pages and other projects in minutes.

Thimble is webmaking made easy. It’s an intuitive visual editor that lets you write and edit HTML right in your browser, preview and correct your work, and then publish and share fully functional web pages with a single click. Thimble removes many of the barriers for novice users trying to learn code, and includes a series of starter projects and templates to help anyone get started quickly.

Wired Webmonkey calls Thimble “one of the friendliest, easiest-to-use code editors we’ve seen.” We’re extremely excited about it, and it’s at the heart of Mozilla Webmaker’s mission to move people from using the web to making the web — and to create a more web literate planet.

Meet the new webmaker.org web site

To mark the launch of Thimble, we’re also unveiling a new Mozilla Webmaker web site today. Check out the new webmaker.org.

The new site includes projects to help users make and learn with Thimble, plus other Webmaker tools like Popcorn and the X-Ray Goggles. We’ve got great new projects to help you do everything from tweaking your blog template, to making interactive videos, to creating fantastic 3D web pages — including projects from partners like Tumblr, the London Zoo, the New York Public Library and many others.

The Summer Code Party starts this weekend!

We’re inviting the world to use these new Mozilla tools and projects as part of our big summer learning campaign, the Mozilla Summer Code Party. The party starts June 23 with a “Global Weekend of Code” and rolls all summer long.

So far, more than 330 Summer Code Party events have been created by community members around the world. It’s a great chance to learn more about coding and how the web works by making something fun with family and friends. You can find an event near you or start your own here.

Learn more and get involved

• Try Thimble for yourself now.
• Learn more about Mozilla Webmaker and check out the new webmaker.org site.
• Join Mozilla’s Summer Code Party. Find an event near you, or start your own using our handy event guides.

People around the world will get together to make and learn this weekend using Thimble and other new Webmaker tools and projects. It’s all part of the Mozilla Summer Code Party, and it kicks off June 23.

Via jwz.  And let’s be honest, the real travesty is the implicit braces, the uncapitalized ‘foo’ and the lack of docstring…