How have Bitsbox's materials evolved since we started?

When we created the first set of Bitsbox materials way, way back in 2015, we were pretty committed to the idea that our system was about something we called coding appreciation, rather than overt education. The idea was that Bitsbox wouldn't expressly teach kids to code; it would expose them to code in a way that would make them feel more comfortable around it as they got older.

As such, every monthly book that we published included a spectrum of app projects from very simple (2 lines of code) to much more complex (60 to 70 lines of code). We made a list of coding concepts (coordinates, variables, arrays, functions, etc), and every book also featured at least one example of each. There wasn't any particular order to anything; our thought was that kids would pick and choose the apps they wanted to build. And they did — mostly.

Before too long, we started to hear from parents and educators that they'd like to see our materials progress over time. They wanted their kids to do more than just appreciate coding; they wanted them to actually learn how to code.

There were other problems with our materials. People thought the books were beautiful, but kids had a hard time propping them up to see the code while they were working. Families with more than one Bitsboxer told us that the books were hard for two or more kids to share.

After a lot of thinking, much discussion, several prototypes, and some testing, we decided to make two major changes to our materials:

1. From "book-of-the-month" club to pre-planned learning system

   We moved from a model where everybody gets the same set of new apps every month (regardless of how long they'd been coding) to one where our subscribers receive materials in a prescribed order. New Bitsboxers get Box 1 their first month, Box 2 their second month, and so on. This allows us to introduce coding concepts in a logical order, with projects that progress and get more complex as kids are ready for them.

2. From glossy books to colorful "supercards"

   We shifted from printing books to printing big cards. Cards have several advantages over books. They're easier to use while you're coding; they're easier to share among several kids; they can be more durable in certain situations; and most kids LOVE cards. Also, printing each project on a separate card lets us vary the number of apps in each box. If we see that one app is really tripping kids up, we can fix it and swap out just that card. Eventually, we can package dozens of copies of the same card together for use in schools, coding camps, libraries and other places where kids learn in groups.

• We've added "Challenge" apps to the mix. Instead of providing the code, we describe (visually and with words) what the app should do, and provide lots of hints.
• We've added "Tips & Tricks" cards that feature simple, step-by-step explanations for how to accomplish very specific tasks. An example: How do I make something explode when I tap on it?
• We include a Grownup Guide in every box. This simple one-sheeter explains the month's coding concepts and commands in a concise way that adults — and precocious kids — can understand.
• We designed a nifty "Apper Keeper" binder to provide a place for kids to keep their cards and other materials.

So here we are. About 20 months into our practice, we've shifted our entire methodology AND our product's form factor in response to the things we've learned (and you've told us) over time. It feels good, but we're still evolving. What do you think of our changes?