 Hello, so I am responsible for technology at the Microbit Educational Foundation and I want to talk about some of the things we've learned and some of the ways we've approached trying to inspire the next generation of students and teachers to get creative and feel digital confidence, not necessarily all become coaches. So I'm going to start with a quick reintroduction to the Microbit in case people aren't aware of what the project is and the Microbit Educational Foundation. Then I'm going to talk a little bit about technology and magic, so you understand the context for the rest of the talk. Then I'm going to give you some examples because the technology magic might be a little bit philosophical, I don't know. Then I'm going to talk a little bit about what we're thinking about now and finally I'm going to look at whether I think there are lessons from the Microbit process that can apply to the wider world. So I'm going to start in 1981, I'm not going to go year by year, but in 1981 the BBC created the BBC Microcomputer and that was a project to put one computer in every school in the country and I think everybody here will know it had tremendous impact both educationally but also commercially. And in 2015 potentially aligned with Charter Renewal, I don't know, but the BBC wanted to do something with a similar impact in schools and in education and it came in the context of curriculum change as well. People think that the BBC is a broadcaster but they also have a remit for education and to teach a wide range of people about the curriculum. So as the curriculum changed to include computer science, the BBC wanted to create something that they thought would help teach computer science to a diverse group of people. And so in 2015 they did the BBC Microbit project and they put one million devices into the hands of year seven students in the UK. But the BBC never had an attention of running that project forever. And so in 2016 the BBC separated out the Microbit Educational Foundation with the help of a number of founding partners who said these people were involved in the original project. I think it's important to say there were 29 partners involved in the original project to create the Microbit. So a lot of what I'm talking about is not the work of one organisation, the Microbit Educational Foundation, but the work of a massive partnership pulling together sometimes very disjointedly, sometimes in a very unified way. But it's kind of a bit of a journey with lots of inputs. I'm just the one talking about it now. In the BBC Foundation we have to say thanks to these founding partners for helping us exist, but we're not of a profit. And our goal is to inspire every child to create their best digital future. And I'm going to unpack this sentence a little bit because I think it's quite important to kind of finesse, think about the words we've spent a while finessing. So firstly, every child. Our goal is not just to reach the kind of students that already know computing is interesting to them, although it would be really nice for those students to enjoy the Microbit. We want to reach out to a broad audience. And I think in some ways, you know, one of the reasons that we exist is because we think that if the future of technology is not shaped by a diversity of people, we're going to get the same very narrow kinds of thinking and the same very narrow kinds of products. And that probably doesn't serve society best. So part of that then, inspiring a diverse audience, is inspiration and creativity. Computing is fundamentally, at least for me, a creative process. It's about solving problems. It's about creating. But that can often get lost in the early stages of teaching computing, where there are a lot of rules. There's a lot of stuff you have to know before you can make progress. And if your brain doesn't already work in a very rules-based way, that can be really problematic. So we want to make sure people get that experience of computing being creative and inspirational. And then finally, their best digital future. This is actually really an anti-statement. This is us going, we don't know what the future is going to be. We don't know what the technology of the future should be, but we want to empower this generation of students to create it. So it's carefully worded to say, we don't know what you're going to make, but we want you to be the people that make it. And the way we can achieve that is by making sure that education with the micro-bit is about kids inventing things and expressing themselves and doing things they care about. The idea needs to come first. And I think that's one of the approaches, at least initially, that set micro-bit apart. And that was something that had been in research with other groups. Micro-bit kind of helped bring it to a large audience, was that kids focus on what they want to do and learn computing almost as a side effect of really caring about whether they're expressing themselves, whether they're solving a problem. And part of that then is making sure that we don't hide away what's going on. We don't kind of push the detail under the carpet too much, or we don't just kind of make it magic. And that's when we got started thinking about this idea. So everyone, I think, will be familiar with this quote. Any sufficiently advanced technology is indistinguishable from magic. And that's great. Magic actually can make complicated things look simple. It can be fun, it's definitely intriguing, and it really engages people. People love magic shows. But there's another side to magic that is relevant when we start applying it to technology. If you are watching a magic trick, magic is not under your control. It's not meant to be understood. Actually, understanding the magic trick ruins it. It's not empowering. It's a trick. And I think it's inscrutable. So if technology is not under my control, it's inscrutable, it's not empowering, how are kids going to get engaged and start shaping the future with it? But there is a balance to be struck because people these days live their lives around such compelling, such brilliant technology that just works. They throw them something which is super-paired back, really basic. It's really problematic. If you watch kids trying to create games and they're used to playing really high-fidelity games and they create something that's fundamentally not, you know, it's text-based or it's not as interesting as the thing they're playing, that can also be disempowering. So the balance that the project has come to strike over years is to present simple analogs of the complex technology that people have in their lives that gives students confidence and control over the technology in their hands but allows them to extrapolate to the more complicated things that they see. But in order to do that, in order to present really clean, clear analogies, we have to do a lot of kind of paddling under the water, a lot of stuff to make that experience of physical computing intuitive and magical. And just a quick detail here on physical computing. One of the things that I kind of just found out, initially I think there was some research at Manchester University, the Codebug Project as well, looked at this, that if you take the computing experience off the screen and let kids do something in the real world, that can actually be really compelling. But physical computing has a bunch of hassles because you've got to plug something in, you've got to get the code onto the device. So we have to do a lot in order to give that kind of compelling physical computing experience well. So some of the ways we do that in Microbit, we've got a very simple LED display. That's a simple, very simple display. It's the most essential, I think, version of a display you could do that still gives people an idea about pixels. We've got block-based programming to get rid of some of the kind of errors, so you focus on your logic. We've got a simple on-loud block, we'll talk about radio messages. But also to enable this, we've got a Microbit drive. We've got a whole bunch of kind of software running on the device to present a USB mass storage device. We've got web-based editors, a simulator, a bunch of other stuff that I'm going to go through. So here's the Microbit. And we often like to say, here's one in real life, so you know how big it is. We often like to draw an analogy between a Microbit and a mobile phone. And I think that Microbit is possibly the most kind of stripped-back version you could have of a mobile phone. It's got a display like your phone does. It's got some buttons. It can do wireless communication between other Microbit devices. It can run code or apps. And you can power it with a battery and it can sense motion. So if you feel like you understand the Microbit and the Microbit is under your control, we see that students can then feel more confident that they would be able to understand the different parts of the phone if they wanted to kind of take that step. But we don't just kind of throw them the most basic interface. So here's the Microbit display, which is on Microbit V1 and V2 slightly differently laid out. It's an array of LEDs, rows and columns, and actually to be drawing a heart on display, you need to be constantly updating those rows and columns to make it work. But we, alongside the buttons, throw a much simpler abstraction to students. And even with the simple abstraction turning individual LEDs on and off, you don't have to worry about the matrix driver, but you still get that conceptual understanding that your mobile phone display is turning pixels on and off. And you can scale it up and have confidence about that. Quickly through the other bits of the Microbit, touch input and output pins, some holes for banana plugs or crocodile clips, an edge connector for accessories, and then back. So the back of the Microbit is where some of that magic I was talking about happens. And so we've got two processes on the Microbit. Most people who've used the Microbit maybe don't know there are two processes on there. One of them is where your code runs, and the other one is infrastructure to make sure that your experience of running your code is good. It's actually a full debugger as well. If you want to kind of write C++ code and debug it, that interface chip can debug it. It's a USB drive feature of the Microbit. So when you plug the Microbit into your computer, it shows up as a USB mass storage device and you can take code, a hex file, and drag and drop it onto the Microbit drive and that programs your Microbit. So these days that's a really familiar model. It was pioneered by Embed in ARM and Embed kind of helped contribute that into the Microbit project. And because you only need to drag and drop a file to put it onto your Microbit, that allows us to deploy the Microbit code editors to the web browser. So if you're in a school and you can't install any software, which is probably the case if you're in a school, then being able to just use your web browser, rock up, type in the URL and program the Microbit from a file that you've downloaded is really important. And likewise, because you only need to create that hex file artifact to program a Microbit, it's also easy to create other editors. So we've got a whole host of third-party editors that target the Microbit device using that hex file mechanism. So some pretty neat magic in the web-based editors. So this is stuff that the Microbit Foundation didn't do. It's partners we work with, both MicroPython and Microsoft. So when we first did the project, we had a compile server. So we basically turned the students code into C++, send that to a compile server, compile it and send it back. It doesn't scale. It's slow. It's prone to errors. And what Microsoft realized, well, first what we did with MicroPython was you can catenate an interpreter into the hex file in the browser and distribute it. You don't need any servers. And crucially, you don't need to send any student code to a server, which means we don't need to worry about person-identified information or anything else like that. So schools are really kind of happy that we're not sending the information to any servers. And then Microsoft actually do something even more crazy. They compile the students code into ARM assembler in the browser. They've got an in-browser assembler, which they then concatenate with a pre-built C++ blob and the assembler calls into the C++ blob for most of the key functions. And so that I think is sort of neat. There's a slide on that later. This is a picture of our new Python editor, which is in beta right now. And I'd love you to go and try out. There's a feedback down here. Please give us any feedback on that editor. We'd love to hear what you think about it before we finalize it and release it. So this is, if you're interested in how to write an in-browser assembler for thumb 2, this article is really great. I would recommend it. Take your photos at the QR code now. Right. But I want to talk a little bit about the downsides of this USB interface as well because I think it's really clear that when you present this magical stuff you can't reasonably on small low-cost devices push that magic all the way to the edge. You cannot emulate every aspect of a master's device if you don't have real flash. So there are some downsides. We get students that think they might be able to store files on the microbit because we just told them it was a USB drive. They think they should be able to write data from the microbit and copy it off and that's not possible. And also there are these slightly weird things where kids that are paying attention go, I've got a 1.2 megabyte file here and I just put it on a device that you told me had 128k or 256k of flash. So there's this kind of dissonance and I would say potentially inauthenticity that we present. And we kind of wrestle with that and we've come to the conclusion that it's okay. It's a kind of valid trade-off. So long as we're thinking carefully about the fact that we're still empowering people and why we're doing it rather than just doing it because we think it's cool. So, okay, so far, so 2016 I've only really talked about the microbit original project. So thinking forward, when we started the microeducational foundation we went out and spoke to a bunch of teachers and said cool, right, we're here, let's do a microbit v2 and the teachers went, whoa, no, please don't do a microbit v2. I really don't want you to change the microbit. It's a really good idea for you to have a lot of conversations around the product just keep it exactly the same. And so microbit v2 looks exactly like microbit v1, really. It does everything that the microbit v1 can do, but it does some additional stuff as well. So it can make and sense sound. It can detect touches on that logo, that capacitive touch which actually kind of allows us to talk about capacitive touch on mobile phones as well. And it's got a much more powerful processor And the reason we felt it was important to do a microbit V2, despite the fact that teachers were kind of saying microbit V1 is serving us very well, is that we felt there were important aspects of the current technological world that we were going to struggle to teach and expose in this way, like we have a mobile phone with the technology that was on the table for microbit V1. So I haven't shown you any block diagrams yet, and I feel like that's mandatory. So here's a block diagram of microbit V1. You can see you've got the target processor and the interface processor, the Cal26Z. Microbit V2 looks really similar, but crucially has this I2C, the communication interface, between the target microprocessor and the interface microprocessor. And that allows us to start to communicate between these two things. And because the interface processor is the one providing that USB drive, that kind of slightly obtuse magic causing us some problems, we can potentially, using this I2C interface, do some stuff that mitigates those. But we gave ourselves another problem in making microbit V2. If I hold up these two devices, which one is a V1 and which one is a V2? So these have different microprocessors on them. They've got different amounts of flash, different amounts of RAM. But it's totally reasonable for a student or a teacher to think that they should just be able to put any file that works on one of them onto the other one. And in fact, we know teachers that have just bought new microbits, they've got a mixed class set. So it's not reasonable to ask students to determine which device they've got. So we needed to find a way to keep that magic programming experience and make it work. So we created something called Universal Hex, which we kind of stole the name from Apple. We were calling it Fat Hex. And then we realized that Apple had gone from Fats Universal, and that was much more friendly and inclusive. So we called them Universal Hex Files. And they basically just be one hex file and a V2 hex file whammed together. We had to do a little bit of kind of reverse engineering of our own technology here, because microbit V1 wasn't designed with this in mind. So we had to kind of shape the Universal Hex format to avoid the things that would trip up a V1. So you wouldn't have to update your firmware on a V1 to be able to consume these hex files. So microbit V1 actually kind of reads through these things. And then in certain versions of the V1 firmware, we kind of trip it up here so it fails and doesn't see any other stuff, just so we can kind of make it work without a firmware update. So that means you can create one hex file. That's the file you programmed onto your microbit that works anywhere. It can work on a V1 and a V2, which is fine if you're only using features that exist on a microbit V1 and a V2. But if you start to use features that don't work on a V1, well, how do we signal that to a user? They've dragged and dropped a file across you. You know, you actually, in many cases, don't have any connection between the programming editor where the student wrote the code and the device works running because you've just got this one way channel. So we needed a way to signal that. And we didn't want the failure to happen if it didn't need to happen, right? So if you're using a program, if you've got a program that has some button stuff that's on both of the devices, it should work until you do something that doesn't work on the microbit V1. And that also makes it clear what in your code cause it to fail. If you're looking at a big program and it fails on boot, well, that's not very helpful for diagnosing what the problem is. So we've actually done a lot of work to make failures on microbit V1 if you use V2 features kind of happen instantaneously. And then the final little magic that we did here was that if you use an older hex file from a microbit V1 and put it onto a microbit V2, that should also fail explicitly because we think explicit failure is a really important part of helping kids have mastery and understand what's going on. Kind of failures where you don't know why it's failed, you don't even know it has failed, they're really disempowering. So we actually pre-build a tiny little error binary which we ship inside the interface firmware of the microbit. And if we put a V1 program onto a microbit V2, we instead of flashing that V1 program, we flash the little error program instead which goes, fail, I can't do it and tells you what's going wrong. So I'm gonna do a very quick demo of a teleporting duck. I might do a quick demo. Let's see how it goes. So that should be, I need to move that to another display somewhere. All right, right. So here is my microbit editor. I've got, I've set a radio group. I've got sending a string. If I shake my microbit, I send the string duck and if I receive a string, any string on the radio then I'm gonna show an icon of a duck and I can kind of simulate this here in the browser with a shakes, if I shake this one, I will send the duck string and this one receiver and I'll teleport the duck between the two microbits. So kind of like really simple example and what I'm gonna do is I'm gonna download this hex file. So I've got a hex file here. I'm gonna show that in Finder, hopefully on the right display. No, drag it across. And I'm gonna drag and drop this file onto the first microbit which is the microbit V2. So drag, drop and the LED on the back of this microbit is blinking, hooray. So while that's copying over, we're gonna go back and look at the code. I've also put in this program a little bit of V2 only codes. If I push button A and B and hold button A, I'm gonna show a bar graph of the sound level in the room on the microbit display. So that's on my microbit V2 now. I'm gonna unplug my microbit V2, plug that into a battery pack maybe and then plug in a microbit V1 and copy the program onto the microbit V1 as well. So this is exactly the same hex file that I downloaded onto this microbit V1 and LED blinking. I'll plug in the V2. So in the meantime, we'll have a look. Right, so can everyone make a loud noise? And now go quiet. Right, so I hope you can see on the screen of the microbit, it's showing the sound level in the room and that's the microbit V2, great. Microbit V1 is ready now. I've got a duck because I shook microbit V1 so I'm gonna shake. Can you see the duck moving? I don't know if you can see the LEDs. Okay, great, right. So I've got a teleporting duck. But if I now try and do the same thing on the microbit V1, then I've got a sad face that tells me I've got an error because I don't have a speaker or a microphone. So if I just switch over to camera, so you can see this, right. There's my sad, you can't see it. There's fresh rates wrong. That's a shame. Okay, so I've got my sad face. I think the ones at the front saw my sad face. Back to slides. All right, right. So that's the teleporting duck. And you might have seen when I started doing that sound level thing that there was another LED that turned on on the microbit. Did anyone notice that? So there's a little LED at the top right corner of the display on a microbit V2 that tells you that the microphone is on. And when we put a microphone on a device that we were gonna sell into schools and give to children and put in classrooms, we had quite a lot of discussion and thinking about how we could expose the implications of that potential privacy risks of putting a listening device in the hands of kids. And we came to the conclusion it was unrealistic and impossible to prevent, to create something that was compelling and would let kids code stuff, but to prevent any kind of situation. And what was really important was to have the discussion with kids about privacy and what that meant. So we put this LED on the microbit, but we are trying to, the microbit V1 was an iconic design. I think it looks pretty sweet. It was designed by Tech Will Save Us. And we didn't wanna kind of ruin the face of the microbit by sticking another LED on the front. So we stuck the LED on the back and put a whole, well, kind of cut out in the copper on the back until the LED shines through. And this LED is actually on the power line of the microphone. So if you turn the microphone on, if you want to use the microphone, you basically have to have this LED on. And it's a trade off. Like we basically have heard the power performance of the microbit while recording in order to turn this LED on brightly. But that's the kind of trade off that I think is acceptable and reasonable in order to make something that goes into a school and allows us to kind of have this privacy preserving or at least privacy indicator on it. And because it's EMF, I thought I'd take a bunch of photos of our like first experience with this. We first just like sold the LED onto the antenna of a microbit V1 because it was some useful tracks that we could do. Scratching the silk screen. Here's the like initial board. And here's us playing with like exactly the right size and shape and style of the icon. Right. So I mentioned that one of the reasons we did V2 was that we felt like we wanted to kind of expose more of the technology in students' lives. And we were looking at the rise of smart speakers and how popular these were becoming in schools and in homes and felt that microbit V1 was struggling to expose kind of analogistically. As an analogy, what these smart speakers were doing because it couldn't really do anything with sound. So we wanted to kind of make sound engaging and not magic. And we spent a bunch of time experimenting with kind of teaching the microbit. Clap patterns, wake word. And actually came to the conclusion that it's so much simpler just to have a loud sound trigger an event. And that in itself, immediately kids go, right, I get it. And I think we've got a bit to fill in the gaps between loud sound and, you know, Hey Siri or Alexa. But even just with a loud sound, it was amazing how effective it was in giving kids that sense of like, Yeah, I understand. It's like responding to an event and being programmed. But we also wanted the microbit to have kind of to make sound that were cute and playful and compelling. And we have this, I'm going to call it low cost speaker on the back of the microbit, which has different resonances and lots of different places. It's very hard to get good kind of sound across all frequency ranges. So we went, okay, how can we make the most of that? Well, Clangers, it turns out, speak mostly between about a thousand Hertz and five kilohertz. And that is where our speaker is quite resonant. So we kind of looked at making sounds that would fit well on our speaker. But I think if you kind of look at these, we put this block together, play sound and it was kind of kids loved it. They made nice sounds. But if you ask them, like, what is that sound? What's happening? They were like, oh, I don't know. It's a cool sound. And I think we, in our initial release of the sound stuff, I think we've failed to kind of give people that sense of knowing what the sound was and what was happening. So what we've been working on and it's gonna be released in the next release of Microsoft MakeCode is this new sound editor that gives you all of the controls you need to make each one of those micro bit sounds that you've got. So you can play with the wave type, the duration, the ramp, that kind of stuff. And like talking about magic, this picture at the top is a total lie. I was really worried about that kind of picture. It gives you an intuitive understanding that as you change frequency, you're changing the waveform, but it is not an actual representation of the waveform because the real waveform is just too hard to fit. You know, there's far too many peaks and drops to fit there. But when you click play, you'll see in a moment, we actually show the real waveform when you hit play. So we kind of got this compromise between trying to give an intuitive understanding of what's happening and giving a kind of reality when you hit the play button. I hope I hit play button in this demo. Go on, hit play, previous Johnny. Wait, there you go. And on a screen, it's a bit clearer. So there's definitely not time for the lonely duckling demo. So we kind of talked about the micro bit being a USB driver and that having challenges of its own because kids want to get data off. And that's the other thing we've been able to do with micro bit v2 is do this slightly weird magic where we use half of the storage of the interface chip as a way of letting the users kind of store files, which is kind of neat. You can get a new file on your micro bit called mydata.htm, which contains the data that you logged from your micro bit. So here's an example of the mydata file. You can download and you get a CSV out. You can view the data as a graph. And people ask why isn't this just a CSV on the micro bit drive? And as I mentioned before, the micro bit drive is not a real drive. So if you make just a CSV on the micro bit drive, you double click on it, you make some changes, you try and click save, your program may crash or the micro bit may eject itself, you might lose data. So by kind of shifting away, we've been honest, this is not a CSV. This is your data, it's some kind of special format. And I feel like the part of what we learned from this is that the honesty is an effective way to kind of make things work. And these have some simple blocks which are gonna be in the next release of make code as well. Right, so finally a few other places that we do some magic. We kind of fill in the gaps between the audio capabilities of the two devices. We totally debounce button events. So when you click a button on a micro bit, that is not like an interrupt hand or anything like that. We actually sense like using the LED matrix, we flip the LEDs to reverse bias and measure the current leakage through them based on the light level. So those are all kind of neat things that we do in order to get more capability out of the micro bit device. Okay, in the last five minutes, I just wanna talk very quickly about the things we're thinking about. So we're trying to do machine learning better. There was a workshop at EMF that kind of gave us a lot of information about teaching people about the kind of reality of machine learning in this exposed way. I want to make radio a lot more visible to people that teleporting duck, I think it's still a bit too magic. And I would like to be able to do a version of it where I'm sending the messages with sound and then corrupting the sound with noise and maybe shifting the frequency so I can have multiple micro bits on different channels at the same time. And I think that will help kind of expose the magic in radio as well. And lastly, we've been struggling with the silicon crunch and we've just done a revision of the micro bit which uses a different micro processor on the interface just to allow us to continue producing it. Okay, so finally, does this approach have any relevance and utility to the wider world? Are there lessons that we can apply to other products? And I think as I was thinking about this, I realized that working for an education and not for a profit is quite a privilege because you get to focus on some very specific kind of use cases like making sure people understand what's going on in their world. But I firstly realized we're absolutely not alone here. So like there's loads of magic in your everyday life, like your car steering wheel is sort of not, it is still directly connected to the wheels but there's a lot of other stuff going on to make your steering kind of fluids, drone controls, batteries really aren't just one battery anymore, there's loads of batteries inside your battery or pretending to be one battery. But one different thing about these is they aren't designed explicitly to expose the technology, they're designed purely to give you a magical experience and sometimes that has real downside. So I think actually if you hide those realities, people don't necessarily understand what's actually going on and that can be exploited. So like one example for me is we started hiding URLs in browsers generally, both Chrome and Safari do different things to hide the actual URL. So this is a Google search, I can't get the URL of my Google search if I want to copy and paste it to another browser. Even if you copy that and paste it in somewhere else you just get the search terms. There is really no way to do it and I think there are a bunch of things going on that contribute to a lack of understanding of what a URL actually is. And I think that's a bad thing because it makes people vulnerable to kind of exploit like this. Here is for someone who doesn't understand URLs a kind of reasonable looking text message about a delivery fee that you've got. But if you do really understand what's going on in a URL you know that that subdomain bit, the only bit that says Royal Mail in that could be any string that the person setting up the web server wants to do. So there's this kind of downside to some of the magic that we do if we don't kind of also think about making sure people have the appropriate understanding of what's going on to empower them. And I also think this is relevant to fixing stuff. So here's me at Repair Cafe, fixing someone's tablet, probably I'm not sure if I succeeded. But I think one of the things that happens at Repair Cafe is you see a lot of people with fairly trivial problems that would be soluble but they didn't necessarily have the confidence to do it. And I think we have to ask ourselves actually would more confident consumers with better mastery of technology be kind of demanding better of manufacturers of their technology? And I think the answer is probably yes. So finally I think if we can encourage people to build technology that is understandable, is clear, we can improve people's trust in their technology, we can improve their confidence in technology and I think that leads to a sense of mastery and I think that will result in people in general demanding better and even if you aren't actually implementing technology, a mastery of the technology in your life I think will result in a much stronger idea about how you can use technology in the work you're doing, whether you're an artist, a lawyer, a marketing director, I think kind of mastery of our technology is a really important thing. So I'm gonna leave you with that slide. Thanks very much.