Last weekend (11th Feb) I was at Hack to the Future (H2DF) in Preston, organised by Alan O'Donohoe and held at his school - OurLady's High School, Preston. What's that I hear you say ? Well, the blurb for the event was this:

What is Hack To The Future?

It is an un-conference that aims to provide young digital creators aged 11 - 18 with positive experiences of computing science and other closely related fields, ensuring that the digital creators of today engage with the digital creators of tomorrow.

We plan to offer a day that will inspire, engage and encourage young digital creators in computing/programming ... -- [ from here, snipped ]

Originally, I'd intended to attend as just someone interested in this area, and perhaps putting on a session (it was an unconferences after all) teaching the basics of something. In the end I helped BBC Learning Innovation in a more official way (ie wearing my BBC id, etc), helping them test out a bunch of ideas, created some tutorials, acted as a mentor/guide on the day, and yes, taught a bunch of people young and old about various aspects of coding.

How the Day Went

In short, brilliantly. Very tiring, very long day, but very rewarding and learnt lots.

After an initial quiet period when everyone was setting up, and they were having welcoming sessions, we started getting a few visitors. They were made to feel welcome, and we chatted about what we were doing, and very quickly kids were sitting at laptops, learning to hack (in many cases) their first bits of code.

There were six laptops in use at any point in time, and we were after that initial start then very busy for the entire day. (Only stopping briefly for lunch) 3 devs who'd worked on the prototype BBC Learning were testing, and a few helpers from BBC Learning and one from BBC Childrens, and myself were all acting as mentors working through the tutorials I wrote as well as the prototype's built in tutorial.

Some learnt to bling up a simple hello-world style web app. (Which you can think of as being like a e-greeting card really) Others extended the quiz with different questions and answers The vast majority I worked with extended the image editor to add a collection of user interface elements, model elements and actual filters for flipping the image, inverting colours, embossing it, brightening it, or changing the HSL values, as well as changing mosaic tile sizes. (These used the Pixastic library)

Given these were done in 20-30 minute chunks by small groups of 1-4 (depending on how many came round), I think this was a great result. Crucially, I think kids took away the fact that you could do this, and that all you need is time, a text editor and a browser (at least for javascript)

As well as the reward of writing some task, each child that attempted it received a BBC Owl Badge, and a BBC Owl cloth patch, and some other bits and bobs.

Primarily because I had the documentation for the Pixastic library open in a browser window on a second desktop, I tended not to use the platform BBC Learning created, choosing to use my laptop instead. The other 5 groups though used the platform all day long, with as much success as I had with the kids.

For the large part, the children were doing the driving - they did the typing, they decided what they would code, how they would code it and why. I purposely stood behind the screen with them in front of the computer, making it clear it was their opportunity. I'd feed some information about code structures - by pointing at code printouts, and then guide by asking questions about "Where do you think X is? How might you add Y? Can you see anything similar to what you're after ?", but otherwise left all the decisions to them.

At the end of the day, some key takeaways for me were:

• Whilst tools are needed, they only need to be sufficient to get started.
• What is far more important is content - tutorials. The more of these that can be written, the better.
  • To emphasise this, there were a number of teachers asking for the tutorial materials and asking when/if they could be made available. I'm hoping sooner rather than later. ( Since I wrote them on my own time, I could just publish them, but they'd be less likely to be found if I do that.)
  • This need makes perfect sense when you consider that many teachers - especially primary school - are not specialists in coding. A handful may have these skills, but nowhere near all, so there's clearly somewhere support could be given.
• A huge level of demand of interest from children - of all ages - even the very youngest who attended both wanted a go, and also "got it" when walked through.
• An unexpected level of interest from digitally literate adults who want to do the same, BUT with the huge caveat of not having the time/task orientation
• To me, it confirmed that the issue isn't just coding, but in being able to create controlled automation of intellectual tasks. (Akin to Nintendo's focus on "play" and "games" rather than on "gamers")

It made me feel that there is a need for compelling, useful, interesting and sufficiently featureful and sufficiently understandable content, code, examples and metaphors. (My tutorials/examples filled that gap for the day, but there's a genuine wider need) That content can't be written by non-experts but needs to be written or translated perhaps for complete novices.

I'm painfully aware of many many good things being done in this area, but is it reaching those in the teaching profession? My impression, based on reactions I saw, is "not really". There's going to be a variety of needs there I think, both in terms of pulling together existing resources and in terms of creating new resources, but also in terms of getting the resources in the places they need to be.

On this note of "relevant support material", it's perhaps worth noting that I also took along my inspiration for my tutorials - in the form of my collection of kids coding books from the 80's...

This turned out to be quite useful. After all, these days programming languages are generally focussed on giving instructions to computers in ways that make the programmer's life easier. This really means communicating in a way that other developers understand. Being able to show kids books which were kids books back in the day, which actually assumed that teaching machine code was a sensible and plausible thing to do (and it was) really helped in showing them "yes, you can".

For me, this aspect of opening eyes to "yes, you can", and then seeing the light go on in children's eyes when they realised "Yes, I really can! I made it do THAT!" was fantastic.

Adults!

Also, there were a small handful of adults who came in asked "How do you do that ?". I found this both interesting and useful in that I could clearly explain to them, but also learn why they wanted to know. What I've learnt from that encounter could easily take up a whole blog post in itself. However, some key takeaways:

• Whilst kids can spend hours focussed on playing with something - given a good enough motivation, generally speaking adults simply do not have the time to do so.
• Adults need task oriented tutorials, that actually match the tools they have available in practical terms
• Recording a macro as a script for later editting/driving the app may be enough.
  • But too many apps don't allow this, or it's inconsistent between apps or difficult to use or even find.
• This task orientation is also more like what happens in a class room where you also don't have time to spare.
• Having the usborne books reminded some "yeah, I remember that, you went 10, 20, 30 and had to leave space for 11,12,13". This means they learnt the ABC's but never had a route to actually use those ABC's.

This makes me think two key points:

• There's potentially also a big need/market for task oriented computational tools among adults. (This helps explain the enduring popularity of spreadsheets despite their problems)
• When talking about computational literacy, it's not just children.

BBC And Hack to the Future

(Caveat: In this bit I'm talking about another part of the BBC, I've probably got something wrong here :-)

If you scan through the list of attendees at Hack to the Future, you'll see a number of attendees there from the BBC, and specifically "Innovations, BBC Learning". This is the bit of the BBC that tries to figure out the things that BBC Learning could commission. ie They try out things BBC Learning could do, see what works, what doesn't and based on all sorts of criteria suggest specific things that BBC Learning could do. They're also the bit of the BBC that asked Keri Facer to explore interest & possibilities.

So, ask a 100 engineers, you get a 100 different answers. Some people thought that a Micro 2.0 would be hardware - either Arduino/mBed/BeagleBone like, RaspberryPi/Tablet/Netbook/Net Top like, a pure webapp, through to downloadable Apps, etc. Unless you try something you won't learn.

So BBC Learning Innovations decided to try something - specifically "can we build a kid friendly IDE that enables them to get started using Javascript & HTML5". Now, Javascript is far from my favourite language, but I can see the logic behind picking the language, and it's both unavoidable and ubiquitous - in a similar way that BASIC was 30 years ago. (Well, things actually, but I'm going to focus on what was taken to H2DF for this post) Heck, faced with a similar problem 14 years ago, I reached similar conclusions.

So, Parmy has been leading a small dev team to test out the idea, and built a very simple IDE by taking Eclipse and either skinning it, removing chunks of functionality, or rebuilding from constiuent components (not sure which approach :-). The upshot is one idea of what a BBC Micro 2.0 could look like. However, it IS a testable, concrete, real thing that you can put in front of kids and see if it helps.

Someone reading this is likely react to any/all of the decisions in various ways... but as I've said privately: it's a typical geeky thing to go "how can I improve this hammer that I have?" which I think is a good reaction, but I really don't want to overshadow the "We've got a Hammer! We've got a Hammer! And we can do This! and This! and This! " thing that is going on. . (Once you have a hammer, you can see what you can do with it and whether you want that, a nail gun or screwdriver :-)

What did this platform actually look like though? Well, I happen to have a screen grab from a screen cast created by Parmy, which I feel no qualms copying here since it was demonstrated to dozens of people at Hack to the Future:

Hack to the Future's organisation was happening concurrently with this, and it looked like a pre-pre-pre-pre-pre-alpha version of the codebase would be ready for the event, so the BBC Learning Innovations team decided to take the platform to H2DF to try it out. My understanding of the plan behind this was:

• Inspire, engage and encourage young digital creators in computing/programming
• Take the downloadable platform there and see whether kids could use it
• What's the level of interest from kids, teachers, and professionals ?
• Was that sort of platform a good idea ?
• Should it be a downloadable app?
• What's missing?
• Is this even a good idea ?
• etc.

ie all lots of very good reasons.

I think the day also went a very long way to achieving either the goals, or answers to the questions listed above.

Like any time you take a new piece of code on the road, there were teething issues:

• Power was at the side of the room, so rearrangement of the room was a clear necessity
• The tutorials assumed a working network connection, and the school's wifi was too locked down
• The platform's codebase was very much pre-pre-pre alpha, ready only days before the event. Whilst for basic "hello world" tutorials it worked one way (which I expected), it worked a very different (more eclipse like) way for non-hello world tutorials. This threw me somewhat - I use Kate and commandline tools normally. (Parmy and 2 other devs who'd been working on the codebase were there as mentors as well, so this was fine for them :-)
• When I did use the platform I found it worked, but a little rough around the edges. For example it currently masks errors. I'd flagged this up before, but I guess there hadn't been time to resolve this before the day.

(Given this, you could ask, "why take such pre-ready code on the road?", the answer of course being it was a priceless opportunity to answer the questions above)

I pondered whether to list these, and then figured a warts and all thing was a good idea, primarily because mentioning warts makes it easier for everyone to avoid them in future.

What I did in prep for H2DF

As background, I've been recently trying to figure out how BBC R&D (the dept I work for) can help BBC Learning with their goals (BBC R&D's job, in short, is to support the R&D needs of the full spectrum of what the BBC does). So on a limited time basis I've been spending time with them, and helping out however I can. After all, IMO, first step to anticipating someone's needs is to understand them and their goals, and mucking in is one way to learn that :-)

In this case, it struck me that the best way I could help out with testing the ideas was to:

• Help out on the day as a mentor
• Write tutorials & cribsheets
• Provide a mental model about how to teach building basic browser/client side based web apps.

So I wrote 2 tutorials:

• A javascript based quiz, using a little bit of jquery to download the quiz and update the screen
• The other was a simple image editor/manipulator using the pixastic library to pull in filters.

My aims for these tutorials were:

• To be sufficiently interesting/useful to be engaging.
• To be sufficiently simple to be comprehensible by kids who'd never coded in a very short time period. (Each session was to last 20 minutes)
• To be also sufficiently clear to be able to be modified by kids
• To make it clear that it was possible to do so, and that the modifications reflected "real" coding
• To be no more than around 100 lines long, including HTML, style sheets, and javascript.
• For each to teach a basic structural principle by example. Eg
  • The quiz demonstrated a data driven game engine, obtained by an ajax call, with a staged user interface
  • The image editor really demonstrated how to add user interface elements dynamically, how (and why) maintaining a model of the user interface was a good idea, and how to interact with library of functions.
  • Both were designed to show common structural elements common to client side based web apps.

This is a trickier balance than it might seem, and both took a procedural view of coding rather than object oriented approach. (Once you've demonstrated the value of having a model, I think you have better justification from the learner's perspective for increasing the code complexity in favour of flexibility)

The reason I took this approach is, in addition the the old Usborne books, probably attributable to Dave Hunt of the pragmatic programmers. There's a great book he wrote called "Pragmatic Thinking and Learning" which describes lots of learning models. One of them is called the Dreyfus Model of Skill Aquisition, which has 5 levels:

• Novice - Follows Recipes
• Advanced beginner - Adapts Recipes
• Competent - Understand when recipes don't work, can plan their own
• Proficient - Want the big picture, self correct and self improve, understand context (why you don't do that ?!)
• Expert - As well as all above, work from intuition. eg "I think X has this illness, I'll run these tests". This is the inverse of earlier levels of skill.

The key point really, is that many computing books are really focussed on competent and proficient and very few on the true novice. By contrast if you look at the old Usborne books, they they were packed with what are effectively recipes. In part this is also why I picked the Pixastic library - its documentation is entirely geared towards the novice or advanced beginner.

If you're writing documentation or tutorials, I really think you should be thinking "which level am I targetting?" and "am I addressing the boundary - how do I enable someone to leap from one level to the next?". Clearly on Saturday though I was targetting Novices, and enabling to jump over the first hurdle of "I can't" to "I can".

So, along with writing the code, I produced A3 PDF's describing, in the style of those old Usborne books, what the code did and why. These were deliberately that size to encourage readability by groups, and used friendly fonts :-) Sadly, I didn't have time for little hand-drawn robots or manga cats. (I think using manga cats would be more gender neutral :-)

I'll probably blog about the analogy I used on the day for web apps at a later point in time.

Where Next ?

What BBC Learning do next is very much up to them, and I'll support them in their plans.

This whole event though did get me thinking about Micro Development Environments - MDE's - as opposed to Integrated Development Environments (IDEs).

• The platform we had was a micro development environment for javascript based apps
• The Arduino development environment is a micro development environment for a particular type of embedded system
• Microsoft's Gadgeteer platform is another, for a similar type of system. Microsoft's Kodu, again, is another with a different focus.
• Rapsberry Pi, has the possibility of being either a micro dev environment, or as a host environment.
• Yousrc is a flash based / basic like language for creating web embedded games and similar, again a micro dev environment.
• Scratch, is another.
• Play My Code, is again, another Micro Development Environment, targetted at making it fun to write games for the browser. Personally I think Play My Code falls into the category of "most likely to hook kids and those who are kids at heart". Really neat :-)
• And so on.

In essence there are a growing number of Micro Development Environments, and each focusses (rightly) on a particular domain and has its own strengths. Personally, I think "there next", along with tutorials focussed on the different micro dev environments, and perhaps looking at "what micro dev environment is missing?".

Since H2DF I've spent, a couple of evenings in the past week I've tried knocking up what could be a web version of the BBC platform, incidentally, since it looked like a reasonably plausible thing to do, and I think this looks pretty nice as a possible browser based dev platform:

That allows you to load 2 different apps, and the source for the MDE, edit them, and run them. (No saving, but you could copy and paste to a local editor). The fun thing is that as well as running on my laptop that it runs on a Kindle and even in my (non-iOS, non-android) phone's browser. There are downsides to this approach, but does no-download outweigh that as well?

Early days to say the least for that anyway, and more for a blog post another day.

Thanking Alan, AKA The Perils of Hoaxing

My closing note is really to thank the irrepressible Alan O'Donohoe for organising this Stone Soup. If he hadn't hoaxed everyone at Barcamp Media City and again at Pycon UK, then it's very likely that certain reports around H2DF wouldn't've been taken as a hoax as well. I think the lesson there is do it once, and make sure everyone understands it was a hoax and why, and people will be happy. Do it twice, and when something happens that sounds the same then it might be assumed to be a hoax. I think that's a real shame because what he organised really was amazing, and hopefully people will forgive him the hoaxes now :-)

Also, whilst I thought the hoaxes were a bad idea, but the more I heard about the detail he went to - setting up stooges in his audience for example, the more I can't help but admire the audacity. I don't agree with it, but I can't doubt Alan's determination, impishness, and element of wanting to bring fun to the table.

So many thanks to Alan for organising H2DF, it was lots of fun, we all learnt lots both adults and especially the kids :-)

Yes, he cried "The BBC at my school!" twice, but the third time, yes, the BBC really did go to his school and like many others there, I wish we'd had an IT/Computing teacher like him when I was at school ;-)

Continuity

I'm painfully aware that I haven't really followed up on my last blog post about "what I'm actually going to do", but rather been "doing it". This is probably a good way round, and my next post will pick up from the last. ex-Scout's honour. :-)

This is also because a fair chunk of what I was planning has been done by the Play My Code team. Go take a good look and play with their site.