by Jarren Harkema

Jarren Harkema is a home-schooled high school student who won his LiveCode license by entering a coding competition with RunRev. He is now sharing his passion for coding with his peers by mentoring The Sharks, a home-schooled FIRST LEGO League Team from Michigan.

——–

(This is Part 2 of Robotics, Research and Apps: Reporting from FIRST LEGO League.  Part 1 can be viewed here).

Loud speakers are playing Party Rock Anthem in a gym full of elementary and middle school students.  They wear brightly colored T-Shirts displaying fun team names, such as “The Fantastic Fourheads” and “The Sky Guys”.  Some are dancing around, cheering, or clutching their hair in anticipation.  The atmosphere is very energetic and tense.  The main event?  Three pairs of 4 by 8 foot plywood tables hold a brightly colored mat and are strewn with LEGO models.  

At each table are two students hunching over the robots, which they have spent the past 3 months perfecting.  Their fingers are poised to activate their robot on the announcer’s cue.  After a lively team introduction, the announcer declares “THREE, TWO, ONE, GO!!!”  Fingers press buttons, motors whirl, wheels spin, and off go the robots running around frantically solving challenges as fast as possible.  This is the accumulation of months of R&D, engineering, programming, trouble shooting, and practicing.  One robot cherry picks a green bottle while leaving orange ones undisturbed.  Another completes a patchwork quilt by sliding a square onto its correct mark.  Yet another knocks over little LEGO pins using a miniature bowling ball…. I am honored to be watching the future’s young scientists and engineers.  This is the West Michigan FIRST LEGO League Regional Tournament. 

48 teams composed of 3-10 students have come to show off their engineering and programming skills to judges, peers, and family.  Little do they know now, that the skills they have learned could land them a job in software engineering or mechanical design in the near future.  “The Sharks”, the home-schooled team I have mentored over the past few months, have prepared their robot to complete 9 out of 15 missions, which is quite an impressive number.  Teams have a stab at completing as many missions as possible during a 2 1/2 minute match, and to get even half of the missions accomplished invokes whooping and hollering from everyone watching. However, the points on the table only make up a quarter of the overall score.  There are three other judging criteria the teams must also complete.

There are also classrooms where interviewing is taking place.  Three categories of judging evaluate each team.  In the Technical judging room, teams are enthusiastically explaining the design process of their robot to a panel of judges who look over the team’s programs, building techniques, and strategies for completing the mission challenges.  Students demo their robots, answer questions, and illustrate problems they ran into during the development. 

In another room students are given a teamwork challenge to complete together.  The goal for this tournament was to build a gingerbread house out of the materials provided.  Seems simple right? Try having 20 hands working on a paper plate sized house simultaneously and see how simple it is.  The team must work together to solve the challenge, while exhibiting the FIRST LEGO League Core Values.  Surprisingly, the judges don’t care what the finished product looks like.  All they are observing is how well the students work together, include one another, and implement one another’s ideas into one cohesive solution. After the teamwork challenge is complete, the judges ask questions regarding their teamwork throughout their season.  What kind of problems did they face that they had to work together to solve?  How will teamwork help them in the future?

Finally, the least known aspect about FIRST LEGO League, and yet the most important, is the research project judging.  Along with the robot, there is a yearly real world theme that teams are given to research.  The goal is to find a problem within the subject, create a new innovative solution to the problem, and present it in a creative 5 minute presentation.  Teams present their research in a variety of different ways.  Presentations vary from infomercials promoting their solution, to plays acting out their problem, to songs explaining all that the team has learned. After their presentation, teams are asked about the feasibility of their solution, what experts in the field they talked to, and where they got their research from. (Read my previous post if you would like to know more about the research project for this years “Senior Solutions” challenge) 

All four of these events are run throughout the course of the day, with teams consistently running here and there going to their next interview or robot match.  But all of the hectic commotion is more than worth it.  Teams make new friends, learn new things, and have an opportunity to show off everything they worked on.  Oh, and did I mention trophies?  Yes.  Lots and lots of trophies, and the chance to advance to the state level competition!  At the end of the day there are over 20 trophies up for grabs, not including the 13 state qualifier trophies.  These awards range from Most Innovative Robot Design, to Most Creative Presentation, to the Rising Star Award – recognizing a rookie team that did an exceptional job for its first year.  

The closing ceremonies are always the funniest part of the tournament, with loud speakers blasting songs such as the Macarena, the Chicken Dance, and the Cha-Cha Slide.  Kids dance all over the place, form conga lines, and have a flat out good time.  After getting all the sillies out of the kids, the tournament director takes the microphone and begins awarding trophies.  When the team name is called, everyone cheers and the team stampedes down the bleachers to claim their reward. 

For “The Sharks”, the team I mentor, this closing ceremony was nerve wrecking!  They watched the trophies slowly disappear, as teams around them claimed the programming award, innovative solution award, and other such top honors.  Once all the standard awards were given out, the state qualifiers were announced.  Moving up the list, The Sharks grew more and more nervous. The tournament director holds up the giant first place trophy for all to see, announcing “And the first place grand champion, and final state qualifier goes to…” He then runs straight toward my team yelling at the top of his lungs, “THE SHARKS!!!!”.  We celebrated that night with some well deserved ice cream!  (No, the robot was not allowed to have any.)

The Sharks did an incredible job earning the champions award at the regional tournament. However, they still have a lot of work to do before the state competition on Saturday, December 8th.  Stay tuned to find out the results, and learn more about the team’s research project!

If you have an all singing, all dancing app, with amazing features, does it really matter what it looks like?

By Heather Laine & Steve Thomas

I think I should open this article with two statements: 1) I’m not a graphic designer and 2) interface design isn’t just about eye candy.

I’ve seen some beautiful looking apps that after 5 minutes of test driving have forced me to abandon them.  An app that for example led me neatly into the help screen and then provided no means at all to exit it, short of closing the app, springs to mind.  Or an app that greeted me with a loud, prolonged horn blast which refused to stop – that got quit within minutes and never re-opened.

I’ve used some very ugly looking apps very efficiently for years.  The important thing was that they did what they were intended for, without any unnecessary fluff.  The buttons may have been left in their default state, but as we weren’t trying to sell the app, it really didn’t matter.  That said, I currently work with a rather beautifully skinned and designed internal CMS.  Do I work better because the buttons I’m clicking are turquoise and pulse prettily?  Possibly.

Form should follow function.  If your app exists to perform a task, then every part of the interface should facilitate that task, rather than wandering off into side alleys and distractions.  If your app is a game, the graphics should not only be professional looking and attractive, they should convey the atmosphere of your game to the user.  Is it a horror and suspense type game?  Fluffy kittens and roses will be inappropriate (in most situations at any rate).  Is it a utility, to assist with a business process?  It should be professional looking and sleek, without unnecessary window dressing.

Navigation is vital.  Are the buttons where the user expects them?  Do they look like their function?  If they are not actually labeled, it’s even more important that they conform to user expectations of what certain types of button should do.  If I used a button that looks like this:

and linked it to the zoom function in my app… people might become confused.  This type of icon has become firmly associated with RSS feeds, so even though I could imagine it representing something getting bigger, it would not be a good idea to use it in this way.

I asked our resident graphic designer, Steve Thomas, for some tips I could share with you.  He came up with some top tips to bear in mind when designing your mobile app, and this beautiful screenshot of an app to consider.

Tips on good UI Design from the Master

Don’t reinvent the wheel
When considering the layout of your UI, take a look at how other Apps work and try and use a layout that people will be familiar with.

We often take if for granted that App users learn from their experience and are familiar with how how Apps behave.  So take advantage of that familiarity and use it within your App.

Everything in the right place
Make sure your buttons are clearly labeled and that they behave as they should.  So in our example, we have back button in the top left corner, action button in the top right (this can also be a menu or home button) with navigation along the bottom.

Warning: Add an action item within the navigation and the App may not behave as the user would expect it to behave.  So make sure your navigation items and action items are clearly separated.

Hit and Active states
We have used on (or active) states within the navigation so the user knows where they are within the App at all times.  You can also add ‘hit’ states where the button highlights on order to enhance the user experience and further engage the user.

Button sizes
When designing the buttons for your mobile App, remember that a finger is a lot less precise compared to a mouse cursor or stylus.  So make your buttons large enough so the user has control, but not so large that they dominate the screen.

All useful considerations, thank you Steve.

If you are making an application that needs to work across several different platforms and devices, e.g. on Mac and Windows desktop, as well as on iOS and Android phones, you have some very particular challenges.  

Firstly, there is the size and shape issue – an Android phone can be tiny, a Mac desktop can be huge.  Designing something that will work in both places means either some serious scaling up and down, or completely separate sets of interface elements.  You might want to look at a lesson on our website that discusses different ways of approaching this issue.

But it’s not just about size.  A Windows user expects buttons and menus to look different from those on a Mac, and be in different places.  Android and iOS devices have a distinctly different look and feel.  You have two choices here.  You can either re-skin your app to conform to the user interface expectations on each platform, or you can choose to ignore the conventions and create a “universal” interface for your app, that will function everywhere and be distinctively different.  The latter option is dangerous – if you’re going to do this, you had better be a really excellent designer – but it can be done successfully, if you are really sure its the best route for your particular app.

What do you think?  Do you have an app you are proud of?  Something distinctly different to share?  What are your top design tips?  We’d love to hear from you, do enter a comment below!

by Monte Goulding 

Monte Goulding lives on a small farm in Tasmania, Australia where he built a straw bale house. When not working at M E R Goulding – Software development he enjoys spending time with the family, pretending to be a farmer, mountain bike riding, diving for and eating abalone.

_____________________________________________________________________________________________

Developing third-party extensions for a developer tool is a challenging business to run.  The market is an unknown size and only a small percentage are involved in mailing lists and user groups so it’s very difficult to make people aware of what you provide.

However, I’ve long believed that a proliferation of third party extensions can make a platform like LiveCode shine.  It can also be very fulfilling because you are creating tools used by people in a community you are involved in.  Your code is used in a wide array of apps all over the world and it’s really great when you find out what someone has achieved with it.

The flip side of that is developers rightly expect responsive support and well maintained extensions.  It’s difficult to strike the right balance between sharing with your community and the business aspects of doing so and I know of many great potential extensions that aren’t shared as a result.  

The business model for mergExt has evolved over the past year in an effort to find the right balance.  Product development is usually 50-70% funded by the community that need an external or feature developed so they can implement their app.  The rest of the funding (including for support and long term maintenance) comes from product sales. The whole concept is to create a win-win-win situation for the community and platform, the client that needs the feature implemented and my business.

Other times product development happens because I identify a great feature that I think users will love and I get a strong urge to spend a rainy weekend implementing it and sharing it with my fellow LiveCoders.

With roughly a billion users worldwide Facebook has become one of the most important marketing tools ever.  When iOS 6 by Apple was announced, I asked the community which features they would most like to see developed into an external.  Facebook lead the poll by a long way.  When I got my hands on a beta version I could see why.  Both the Social framework and the UIActivityViewController made sharing content on social networks a breeze.  

The next rainy weekend I targeted the UIActivityViewController which has great bang for buck in terms of what you get for the amount of code you need to write.  As with everything else in LiveCode it had to be done in a way that made it super easy to use.  I added it to my mergPop external with the mergPopActivity command.  With a single command LiveCode iOS apps could now share data to Facebook, Twitter, Messages, Mail and more. A simple script like this:

on touchEnd
mergPopActivity “This is the best app ever”,,appStoreURL
end touchEnd

Presents this to the user:

From there the user can choose whichever service they want to use to share your message. The addition to mergPop (one of my most popular releases) was very well received, however, it wasn’t long before Jaime Stuart from EuroTalk asked to be able to post to Facebook without going via mergPopActivity. He wanted to have a facebook button rather than a share button.  I had already looked at the Social framework but at the time I was in the midst of resolving some lingering issues resulting from the changes to iOS externals required by LiveCode 5.5.2.  

Once resolved I set to work implementing mergSocial as a natural successor to the existing mergTweet external that was based on the iOS 5 Twitter framework.  Once again it had to be super easy to use so even someone using LiveCode for the first time could see it’s easy to share on social networks. I ended up implementing one function to check if a service is available and another to present the dialog for the user to send a post.  It’s so simple to post to Facebook Objective-C coders will get jealous:

on touchEnd
mergSocial “facebook”,“Hello mergExt!”,picOfMyLittleGirl,”http://mergext.com”
end touchEnd

Presents this to the user:

From there the user can cancel, edit the message and post.  

For more information, visit http://goulding.ws/ or http://www.facebook.com/mergoulding

by Jarren Harkema

Jarren Harkema is a home-schooled high school student who won his LiveCode license by entering a coding competition with RunRev. He is now sharing his passion for coding with his peers by mentoring The Sharks, a home-schooled FIRST LEGO League Team from Michigan.

—————-

I’m standing by a 4×8 foot table made of 2x4s and plywood.  On the table is a colorful mat with lines, patterns, and a home base.  Strewn about the mat is a wide variety of LEGO models.  Bowling pins are set up in one corner, stair steps leading up to a rocking platform sits in the middle.  A LEGO stove sits to one side, burners showing on. 

These models, along with ten others, are being scrutinized and discussed by 8 middle school students.  “Well, we could put the blue quilts out on their mark first, then complete similarity, then send the dog back to base.”  Says one team member.  “Yea!  Then we could grab the broken chair on the way back!”  Says another.  What are these kids discussing, and why am I watching?  They are The Sharks, a homeschooled FIRST LEGO League Team from Michigan,and I am their mentor.

Front to back, left to right: Trey, Cole, Brennan, Jamin, Abby, Ryan, Ashly, Alex

FIRST stands for “For Inspiration and Recognition of Science and Technology” and was founded by Segway inventor Dean Kamen.  FIRST LEGO League (aka FLL) is a science and technology competition for elementary and middle school students ranging from 9-14 years old.  Last year alone there were over 18,000 teams from all over the world.  During that year, The Sharks were honored to win the Michigan state competition, and asked to represent Michigan at the world championship in St. Louis, MO.  Only 80 teams out of that 18,000 were invited.

FLL is comprised of 3 sections, the Robot Game, the Research Project, and Core Values, also known as teamwork.  Each year there is a theme that encompasses the research project and robot game.  Themes have ranged from how to conserve energy, to making transportation safer and easier, to keeping food safe from contamination.  This year’s theme is all about making the lives of seniors better.  Teams are challenged to build and program a robot out of LEGO to complete challenges on a table to earn points.  Each challenge relates to senior living/challenges, such as physical therapy, or needing the use of a service dog.  Teams have from the beginning of September, to the middle of November to build and program their robot to complete as many missions as possible. 

So far, The Sharks have achieved 235 of a possible 723.  This year The Sharks have also implemented LiveCode.  We have created a scoring app which allows teams to quickly time, score, save, and share their robot score!  Due to the speedy nature of LiveCode, we were able to get the app up and running within 3 days of the challenge announcement.  We are using this as a fundraiser to pay for tournament fees and the like.

However, the robot game is only a third of challenge.  Another part of the challenge involves a research project.  The goal for this year is to find a problem seniors face today, and come up with an innovative solution.  Each team must find a “senior partner” who will help them learn more about senior life, and problems they have.  Once they narrow their problem down, teams must find an expert in the field who is currently working on the problem.  The teams will then take this information, formulate their own innovative solution, and present it to those who it would benefit. Currently The Sharks have found that falling is a big problem, and are going to research preventative solutions.

The last third of the challenge is Core Values.  On the FLL website, The FLL Core Values are described as “The cornerstones of the FLL program.  They are among the fundamental elements that distinguish FLL from other programs of its kind.  By embracing the Core Values, participants learn that friendly competition and mutual gain are not separate goals, and that helping one another is the foundation of teamwork.”  The teams learn that teamwork is what holds the other two parts of the challenge together.

The Sharks and Jarren in the black “innovate, don’t imitated” shirt.

FIRST LEGO League is a big commitment, but has huge rewards.  Students will gain knowledge and experience in science, technology, communications, research, and presentation.  FLL not only gets kids excited about science and technology, but provides the life skills essential for making the world a better place.

If you would like to learn more about The Sharks, or FIRST in general, visit www.paradiseteams.org, or www.firstlegoleague.org.  To check out our app, go to http://itunes.com/apps/fllseniorsolutionsscorekeeper.

Market trends are vitally important for app developers, and for companies like RunRev that provide developer tools for app developers to use.  We need to provide the right tools for you to use today, tomorrow, next week and next year.  Since it takes time to update software, provide new features or support new platforms, we need some kind of crystal ball that will help us predict the future, stay ahead of the curve and anticipate what you are going to want in a few months’ time.

We call this crystal ball “market surveys”.  They may be an annoying interruption to your day, or you may greet them eagerly as a way to express your views and expectations, but either way, if you’re an app developer it’s well worth taking a few minutes to fill them out.  Like voting, this is your chance to make your voice heard, and influence the providers of important aspects of your life – namely the creators of the developer tools you use every day.

Because we believe this is important, we are again sponsoring the latest survey launched by Vision Mobile, Developer Economics 2013.

Developer Economics 2013 focuses on the best practices for the tools, services and APIs that app developers use to build, market and monetize their apps. Take the survey, have your say on your favourite tools and win prizes, including an iPhone 5 and a Samsung Galaxy SIII.  The survey will soon be available in Chinese, Russian, German, French, Spanish and Korean.

A service economy develops around app ecosystems

The mobile development landscape has undergone a massive transformation since the early days of the iOS and Android platforms.  In the early stages developers faced a limited supply of tools and services to assist them with crossing platforms, beautifying the UI, bridging fragmentation, integrating with ad networks or analysing user behaviour.  They had to create most of the building blocks from scratch using their own means.

As mobile application development continues its growth from 100,000s to millions of apps, the rush for gold has sparked a rush for spades.  Across the developer journey, there is now a tool for (almost) every developer need, from app testing to ratings management.  The app economy is evolving towards a service economy where app developers can pick from a range of developer tools and services to assist them along the plan – develop – market journey.  But best practices are yet far from clear.

Third-party developer services, ranging from user analytics, location APIs, bug-tracking tools, app-store optimisation services, and cross-promotion networks are, today, vying for mindshare among app developers.  Developer Economics 2013 aims to identify the most popular developer services among these and measure their Developer Mindshare.  Furthermore this survey aims to understand the reasons developers choose the services they do and how they rate them across a range of key performance indicators (KPIs), such as reliability, availability across platforms and ease of integration within an app.

Which tool should you use and which one should you trust?

These sectors are becoming increasingly crowded with new entrants while merger and acquisition activity is changing the landscape almost on a monthly basis.  The tools and services benchmarked in this survey are becoming the building blocks of modern apps and Developer Economics 2013 aims to establish best practices for the key developer tools sectors across the developer journey.

Developers are often at a loss when it comes to selecting the right tool or partner among the hundreds of services available to them.  Cost is just one variable in the selection process but quite often, it is not the most crucial.  The reliability of a service, the regional reach, key metrics (such as eCPM or fill rates), as well as the flexibility to adapt to the developer’s needs are sometimes more important than cost, particularly when developers invest time, money and resources to integrate a third-party service with their apps.

Developer Economics 2013 aims to assist app developers with the selection process by benchmarking a number of third-party tools and services across a range of KPIs.

As a developer tools vendor, RunRev is keenly interested in this research.  The results of this study and others like it will feed into future decisions about the direction we should take with LiveCode.

If you are a developer your input into this research is very valuable to us and we’d like to invite you to take the survey.

Computer science education is under threat. Secondary school computer science courses in the USA have decreased in number by 17% since 2005, with advanced placement courses decreasing by a massive 33%. Here in Scotland it is a similar story. 8% of schools no longer have dedicated computing teachers, there is just one teacher training college available and those teachers that leave are often not being replaced. Computing is the only STEM subject (science, technology, engineering and mathematics) that has seen a decline in student numbers over the past 20 years.

This might all make perfect sense if the tech sector was doing badly. But computers, smartphones and tablets are not exactly on their way out. The industry is thriving. It is the shining light in an otherwise challenging economy. In almost every field of endeavor, from healthcare to aerospace to finance, computers play a pivotal role. And it is set to continue shining: the sector is projected to grow faster than all but five industries by 2020. It has the highest average salary of any growing industry. In the USA we will add 800,000 new tech sector jobs by 2018, a growth rate of 21% which is more than double that of all occupations in the USA. The mobile apps market is due to grow to $101 billon USD by 2017.

Here at RunRev we work with teachers from around the globe to help them teach computer science effectively.  I’ve spoken to dozens of teachers over the past few weeks alone.  And I personally started this business after having the right inspiration in high school, something that included exposure to a wide range of tools, teaching and opportunities.  So I know from personal experience what the potential upside can be when we do get this right.  And how important it is that we do.

Here are 6 reasons I think computer science education is failing our students:

1. Parents don’t value the subject.

There is a widespread misperception that computer science education is about learning how to use a computer.  Today’s generation of students has of course learned how to use a computer, smartphone or tablet from a very young age.  By the time they get to school they are often more fluent in using technology than their parents.  With this perception of the subject, it’s hardly surprising then that some parents don’t push their children to take computer studies.  But of course good computer science education should be about understanding how computers work, how to create software and how to apply critical thinking skills in the context of technology.  Using Facebook is not the same as creating a new social network, any more than learning how to turn the microwave on is the same as understanding how to construct a meal from scratch.  Going below the surface is what education is all about.

2. Head teachers don’t promote the subject.

Head teachers often misunderstand the value of computing.  They have a similar perception as parents, that the subject is about teaching students how to use a computer.  Given that this is not a popular subject, they prioritize resources for those subjects that are more popular.  Computing gets squeezed from the schedules.  It often has significantly less time allocated to it than other sciences (“pure” science courses get 4x as much time in many schools here in Scotland).  It also gets squeezed when it comes to ensuring there are sufficiently flexible IT arrangements to allow the subject to be taught correctly.  In one school I spoke to, the computing infrastructure is locked down so that teachers are unable to install their own software, yet installing software is an actual part of the curriculum.

3. There is a lack of investment.

Unlike subjects like maths, the tech industry moves fast and in order to keep teaching relevant, departments need to move with the times.  That means upgrading computers and software on a regular basis.  It also extends to training (CPD).  Some of the teachers I spoke to here in Scotland told me they have had only one day of CPD since 2004.  Computing departments struggle to get access to enough machines to teach with, let alone the latest kit.  Some departments have a total budget per year of £300 ($500).  That’s barely enough for photocopying,
let alone any relevant new technology.

4. Teachers lack the skills to create exciting courses.

The natural consequence of not investing in training is that teachers know little about programming.  Yet they are being asked to teach programming.  This can result in worksheet teaching: dry, boring and inflexible lessons.  Worksheets may not get updated very often and often teach using a tool that is 10 or even 20 years out of date.  They lack the skills and therefore the confidence to update their lessons or go beyond the worksheet.  Even if they do get updated, it is unlikely they teach programming for the devices that are so relevant to today’s generation: tablets and smartphones.  This all adds up to teaching that is not engaging and simply results in students dropping the subject.

5. It’s a victim of its own success.

The difference in average salary between a computing teacher and a computer programmer working in industry is substantial.  A computing teacher gets just over half as much on average.  So teaching salaries are in competition with those available for working directly in industry.  Of course this gap isn’t unique to computing, but the software industry is perhaps more accessible for those that want to make that leap and has such a demand for jobs that it is easier to jump ship in this industry than in some others.  Strong investment in teaching and training would go a long way to making the profession more attractive.

6. Poor tools get chosen.

Up to about age 13 there are some excellent tools in widespread use, most notable among them being the free and popular Scratch from MIT and MIT App Investor  However students outgrow Scratch by around age 13 and schools often don’t make a good choice of language for the next phase in a child’s education.  Many traditional programing languages such as JavaScript or C++ are completely inappropriate for this age group.  Students struggle to understand what they are learning and often spend their lessons searching for a missing symbol.  The current generation of students use smartphones and so selecting a tool that allows them to create their own apps is another great opportunity to make learning directly relevant to them.  Our own LiveCode platform provides a handy solution to these issues by allowing students to create their own mobile apps using a programming language that is close to English.

I firmly believe that a strengthening computer science education program has to be one of the most obvious and cost effective things we can do to ensure future economic prosperity.  Israel has the highest rate of startup per capita anywhere and that in part stems from its strong computer science education program.  Estonia, another country with both a strong tech sector and economy, recently announced a plan to expand teaching of computer science to all primary school children.  Do we want to be left in the dust by these countries, or left unable to compete with the growing economies of India and China?  What is it going to take to get computer science education moved up the agenda in the USA and here in the UK?

Here in Scotland we have a new curriculum coming in, the Curriculum for Excellence (CfE).  This represents a big opportunity to teach computing in a new and exciting way.  Unfortunately the feedback I’ve received from teachers so far has been that it is being rushed in, with the minimum of resources and a great deal of confusion as to what exactly is going to be required.  In England and Wales, the education secretary has torn up the curriculum and so teachers who have never taught programming before are now being asked to teach it.  This represents both opportunity and the risk that we will get more of the same.  In the USA initiatives such as Computing in the Core and Girls who Code are both working to promote better computer science education.  Let’s all work together to ensure that history does not repeat itself and that we create the outstanding computer science education programs our students deserve.

I’d welcome your comments on how we can improve computer science education.  Thanks for reading.  Stay tuned for more on this subject soon.

RunRev are the makers of the LiveCode platform. LiveCode doubles engagement and uptake of computer science courses in those schools that have adopted it.