I was a guest on this week's Mozilla Webmaker Community call, where I talked about my research into the best way the organization can support a future generation of Web-makers. Below are my notes, and here's a link to the post Mozilla's Matt Thompson wrote, which contains some of the questions from those present as well as an MP3 of my talk.

I interviewed over a dozen educators/technologists over the course of the last month, asking them what they thought about Web literacy, about the need for better tools, curriculum and support to help teach and learn Web development particularly at novice skill-levels, and about their thoughts on what Mozilla's role should be in all of this -- both at an educational level, but also at a broader philosophical and technological level -- that is, how do we support and enhance the future the open Web development?

Without exception, everyone I spoke to talked about the dire need to improve Web literacy. Whether the elementary school teacher or college professor or ed-tech entrepreneur or hobbyist -- everyone recognizes there's a huge gap in our collective knowledge-base about -- really, at its simplest level -- how the Web works. And while we can jump in with lessons on HTML and even on CSS or JavaScript, we're still faced with addressing this most basic level of understanding. How do we combat the notion that "the Internet is a series of tubes" and then by extension "the Web is a series of documents delivered by those tubes"?

So if you think about a long line of Web development knowledge -- let's pretend there's a line -- part of the question of teaching and learning about it involves how far down that track can we go with HTML5? How much technologically can the Web browser do, how much can it teach us? That's a thrilling prospect to many of us. It's thrilling in terms of capabilities but also in terms of taking a whole new generation of Web builders with us on that path.

But we can't forget the knottier and darker and perhaps less exciting and thrill-filled path of basic Web literacy. How do we help address this at a foundational level: Questions like, what is the Web? Is the Web Facebook? Is the Web Google? What is the browser? How does it work? Why should I care? What do I want to do? Why do I want to build? These are questions that many people I spoke with argued should consider before -- or at least alongside -- plans for teaching HTML and CSS and JavaScript.

So how then do we do this?

When I talked to folks this past month, many of them were really concerned with this question of "building a new tool." There was some agreement, on one hand, that we don't currently have good tools for teaching HTML5. But there was still, I think, a lot of reluctance about building something that would force learners to a decontextualized environment.

That is, if I want to learn HTML5, I want to learn the tool that "real" Web developers use. This is both the problem I should note here, of the analogies that I often used: "Scratch for HTML5."  Regardless, many folks reiterated that learners want and do best with a "real tool." They want to solve real problems. They want to build with real code. They want to build real Web apps. They want to do so quickly, authentically. And they don't want something that marks them as an outsider to the "real" Web development community.

Each of these points is worth restating -- I don't want to rush over them -- because I think they get to the core of both the hopes and the fears about, frankly, yet another learn-to-code tool:

• solving real problems:  that is, being able to help people build projects that matter to them, not just projects that are assigned or imposed by a tool or a curriculum
• getting on-boarded quickly: teachers said this time and time again to me. Kids want to be able to sit down and make something quickly. they want a take-away... and it's not just with minimal effort, although you could read it that way... it's a demonstration that there's an easy on-boarding for them and that they can do something that matters.
• a real tool:  one that real Web developers use.  Yes, I think we can problematize "real" here.  But one of the most interesting conversations I had was with Georgia Tech professor Mark Guzdial. Although he's a CS education prof, he works primarily with non-CS majors. So he has a lot of insight into the non-CS-CS mind, if you will. We had a great conversation about communities of practice, traditional mentorship and apprenticeship programs, and "authentic" entry points to the necessary skills and the "right" people.

The other thing that Mark talked about related to communities of practice was his reconfiguring of an analogy I frequently used -- "Scratch for HTML5" -- to talk about the history of Hypercard. He cited Alan Kaye's argument about Hypercard as one of the most popular user-oriented, entry-level development tools. But Apple abandoned it. And I think just as importantly for our purposes here -- "real" programmers hated it. Even though hobbyists and amateurs liked it, professionals didn't. And as such, amateurs then had this sense that they were using a tool that wasn't the "real thing."

It's funny when I talk to folks about Mozilla and Web literacy and Web education that we almost immediately run into just this distinction, although certainly not to the level that's frought like discussions of Hypercard. In this case, it involved Hackasaurus.  Many programmers and engineers respond with "Oh Hackasaurus is Firebug, right?" And in some ways, yes... Hackasaurus is Firebug. Or Firebug is Hackasaurus. Both of them let you peel back the layers to see see what's going on in the code. One purports to be about debugging. One purports to be about remixing. But the divide between "the real thing" that's Firebug and the tool that's Hackasaurus doesn't seem so great.

That's an interesting starting point, I think although the questions remain: how do we get from remixing to debugging to building?  How do we get from Firebug and Hackasaurus to something else... And is that step a tool? Or is it about community? Is it a curriculum? What do you choose to build upon? Technology? Or people? And when you think about the who and the what and the why -- what are the next steps forward for Mozilla?  Do they look like a software product? Or do they look like some other form of support?