Posts written by Matt Mayer
I recently presented at the Game Developers Conference China on the topic of Educational Kids' Apps. Here's a summary of my talk.
We all know that kids really love tablets: the immediacy of interacting on them, the games they can play, and the creative opportunities. But what do their parents think?
A lot of parents’ concern is that if their kid uses an iPad too much, they’ll end up looking like this:
A lot of research has already been done into how kids use phones and tablets and how their parents react to this usage. In the United States, PBS ran a study on how kids use mobile devices and mobile apps from pre-kindergarten to grade 3.
Parents restrict the time their kids spend on phones and tablets.
"A very popular control tactic for parents was to limit the time a child could spend on the device."
A common tactic is to limit screen time. But there's an important caveat:
“As long as their child was playing with what they deemed to be an educational app, he or she could stay on their device for longer periods.”
If you are creating an educational app, you have an exciting opportunity because parents are willing to let their kids play with your app for much longer than they would otherwise.
Let's explore that opportunity in thinking about what makes a great kids app: what is it that really distinguishes the educational apps that reach the top of the App Store from the rest?
I narrowed it down to five things: the CUBED model of educational app success.
Creativity, Understanding, Branding, Emotion ...and one more, which I’ll come to later.
C is for Creativity
A friend who lives in Shanghai was recently looking for a coloring book for his child. He went to one of the local bookstores and tried to find a coloring book. Here's a photo of one of the books he found:
This is a typical Chinese coloring book. On the right, the child is supposed to color in the bird. However, on the left the book tells you exactly which colors to use and where. Looking through all the books in the bookstore, they were all like this:
There’s even a notice on the page:
“When coloring, be sure to use different colors for the different parts of the dragonfly’s body.”
Now, what if your child wants to do this:
What if your child wants to color over the edges of the lines? What if your child wants to make a dog that is bright pink? Or a sky that is yellow?
When thinking about your app, you must be really careful not to limit the amazing imaginations that children have. Kids won't do what you expect them to do. They won't carefully drag a character across the screen. Maybe they'll smash both hands on the screen at once. Can your app cope with that?
In designing an educational app, there’s a continuum in terms of how much freedom we allow the player to have.
On the left hand side, we have a storybook. If you have an existing, printed book it's relatively easy to make an iPad app version by layering interactivity on to your existing graphics. Now, a character will speak when tapped on, or you can trigger an animation when the child taps on an item. I’ve seen a lot of really great storybook apps, but they don’t really make the most of the opportunities the medium allows.
On the right hand side, you have sandbox games. We know kids love real-life sandboxes! And there are plenty of non-digital examples of "sandbox" toys, like Lego. Give children building blocks and you have the potential to unlock a huge amount of creativity. Minecraft is a very popular game amongst kids, as well as being a powerful tool. But launching a new sandbox game is hard. It requires a lot of pre-planning in terms of what building blocks you are going to create, how you’re going to encourage people to create amazing things, and how you can demonstrate the educational value of your app to parents.
In the middle is guided play, as you see in a Piiig Labs app. When you're doing an experiment in Piiig Labs, you aren't told exactly what to do. But we guide the child in the right direction though positive reinforcement. If you’re trying to get the child to do something quite complicated, like building a volcano, designing a circuit, or making a radio, you need to gently guide them in the right direction.
U is for understanding
There are two critical things that you need to get right for making an education game for kids:
- 1. Understanding your audience
- 2. Your audience understanding your game
Educational games have two audiences. There is the parent, who typically is the person who buys the app, the person who leaves reviews, and the person who sets time constraints on the child's use of the app. And there is the child themselves, who wants to be entertained and delighted.
So, being an educational game designer, you have to act like a psychologist, getting into the minds of these two distinct audiences.
How can we make kids understand your game? One powerful tool you can use is repetition. One powerful tool you can use is repetition. One powerful tool you can use is repetition. Keep repeating something and kids notice.
But isn't repetition boring? When I was a child, I really enjoyed a television program called Postman Pat.
It’s about a postman who goes around a village and delivers letters. Every week, I would sit and watch this program, and I really enjoyed it. A few years ago, I was reading Wikipedia and I discovered that only 13 episodes of this program were made. I’d been watching the same 13 episodes again and again and again as a child! And yet, I never remember finding it repetitive or boring.
And it doesn’t need to be exact repetition. So for example in Piiig Labs, we use a conveyor belt. The conveyor belt is used to bring in the different pieces that are required to solve the particular experiment that you’re currently working on. For each experiment, different sets of items are brought in. By repeating that mechanism of bringing them in on the conveyor belt, that helps children understand how each new kit works.
B is for branding
I was inspired by this quote from James Huggins who runs an educational game company called Made In Me.
“Always think about more than one app with every single idea that you’re doing.”
Why do you need more than one app? Well, educational games are special. While the rest of the industry is heavily dominated by freemium, you can still charge premium prices in kids' categories, but upfront pricing means a lack of ongoing revenue. If you only have one app, you constantly have to find new customers. If you have a portfolio of apps, you can sell more than one app to your loyal customers.
Who does this well? TocaBoca is one of the most popular and enduring kids apps brands. Here's a selection of apps that they’ve made.
Why is TocaBoca so successful in branding? It's because, as a parent, if I buy a TocaBoca app, I know what to expect. I know the kind of game play, I know the style, I know it will be educational, I know my child won't be pushed any in app purchases, I know the value I can expect my child to derive from this game.
At ReignDesign, we have published many games, and a few years ago we decided to put these under a single brand called Reign Games. But there was a critical problem that limited the success of this as a branding exercise: all of these five apps were really quite different genres:
- Spot the Difference, a photo hunt puzzle game
- Pig Rush, an infinite runner action game
- Zombies and Mummies, a real-time strategy game
- Flockwork, a quick-thinking puzzle game.
- Monster Chorus, a kids’ music app.
Without the consistency between our apps, there was no guarantee that a player who had downloaded and enjoyed Pig Rush would also enjoy, say, Spot the Difference.
But build a brand that parents trust and you’ve got a really powerful tool for cross promotion, and for generating a recurring stream of revenue for you to develop your next concept.
E is for emotion
The best kids’ apps are apps that allow kids to experience varied emotions. There’s a tendency with many games to really focus on fun, which is understandable - after all, it’s a game. But look outside of games for a moment: if you read some children’s books or look at children’s television, you’ll see that the characters are not always happy. There are moments in these media where characters are lonely, scared, sad, or frustrated.
To create an experience, which is more than an endless "sugar rush", we need those same emotions to come through in our games.
So any character you put into your app needs to be capable of expressing multiple emotions, even something as simple as the light bulb in Piiig Labs. We didn't want the lightbulb to feel like an inanimate object: we wanted him to have some personality. Sure, sometimes he's happy, but sometimes he’s sleepy; sometimes he’s cheeky.
So that brings me on to my final letter, D. We have discussed Creativity, Understanding, Branding, and Emotion. But there's one more factor that separates the really successful games from the really unsuccessful games. And that's Dumb Luck.
D is for Dumb Luck.
I’ve been attending the GDC conference in Shanghai every year for the last six years, and this is the first time I have given a talk. For many years, I sat in the audience trying to understand: what really is it that separates me from the people who are standing on the stage? Why is it that all their games are successful, and mine are not? They must have some sort of top-secret formula for understanding what makes a perfect game.
Imagine you throw lots of darts at a dartboard. This is the app market.
Look! The yellow one in the middle hit the bull’s-eye. What was special about that yellow dart? Actually - nothing, it's the same plastic dart as all the other darts.
When you only consider the winners, the successful people, the successful games, that's called Survivorship bias.
In World War II, there were many soldiers who flew fighter planes like this one.
And it was a very, very dangerous profession.
Many of the people who set out in the planes would be shot down by enemy gunfire and never make it home. And so the General asked some scientists to have a look at the planes and try to find ways to protect the planes to make them safer. And so the scientists looked at the planes that returned back to the base, and they saw that a lot of gunfire (there were a lot of holes), a lot of damage on the wings of the plane, and so they were saying, well, it looks like it’s the wings that are taking a lot of damage. What we need to do is add some extra armor, some extra protection on those wings. But that would have been a mistake. Because then someone pointed out that the planes we’re looking at, the planes with the holes in the wings, these are the ones that survived; these are the planes that made it back home. The planes that were hit with gunfire in a really critical place, crashed. They never made it back home. So if you look at the battle scars, that’s telling you where not to put the protection.
And people go on stage and say things that are completely wrong. I attended GDC five years ago, and I remember there was an executive from Zynga who was talking about social and mobile games.
So while you’re at GDC, listen to the inspiring stories that people up here on stage are telling you. But don’t think that there’s anything that special about the people. They’re just regular developers like you and I, who did all the right things and then hit it lucky and had a great hit.
Be inspired by the people on stage, but don't feel like you have to copy everything they do. And if you can create a game that kids love and parents love, and that really teaches kids amazing things then you have to be much less worried about this happening: and more about this….putting amazing ideas into the brains of children.
Thank you very much.
For iOS app developers and designers, one of the most significant changes is to the screen sizes of the new iPhones, which differ significantly from what came before.
The first iPhones, up to the 3GS, had a 320×480 screen. When the iPhone 4 was launched, it came with a Retina display, doubling the number of physical pixels in the horizontal and vertical directions, while keeping the screen and UI elements the same size. Developers rushed to add @2x assets to their apps for the 320×480@2x screen.
The iPhone 5 was the first iPhone which changed the aspect ratio, and increased the usable screen area to 320×568@2x. Since only the height changed, it was relatively easy for developers to add additional height to certain elements, and fit the new screen.
Now we have two new screen sizes to contend with. The iPhone 6 is an effective 375×667@2x, both wider and taller than the iPhone 5 family.
The iPhone 6 Plus's screen is a weird beast. Assets will need to be provided @3x for a 414×736@3x screen, meaning for example a full screen image would be 1242× 2208. However the physical iPhone 6 Plus's display panel is only 1080× 1920, therefore software downsampling will be used to scale down the assets to the physical display panel.
Note the aspect ratio of the two new screen sizes is identical to the iPhone 5/5C/5S. iOS8 will take advantage of this, running apps which have not yet been updated to be optimized for iPhone 6 in a special scaled mode, avoiding the black "letterbox" we saw with the iPhone 4 to 5 transition.
Here's a handy reference to summarize the new screen sizes side-by-side:
What does this mean for developers and designers:
- 1. If you don't update your apps immediately, you can benefit from the auto-scaling to get a reasonable temporary solution for the two new devices
- 2. When you update your app to properly support the new resolution, you'll need to deal with more available width and height
- 3. Designs will need to be more flexible, using features like the new Adaptive Layout introduced by Apple. Instead of being at fixed pixel positions and sizes, buttons and UI elements will have to stretch and scale to fit various screen sizes - not unlike designing an Android app!
- 4. Icons and UI elements will need to be provided in @1x, @2x and @3x versions
- 5. It's unclear how some elements will render on the iPhone 6 Plus, for example 1px hairline lines may become antialiased due to the software downsampling.
- 6. Additionally, Apple showed off the iPhone 6 Plus running in landscape mode, which used a two-pane UI similar to the iPad. The iPhone 6 Plus even has a landscape version of the home screen, so we can expect more pressure to get your apps working in landscape mode.
There's an old story about two pharaohs. Both wanted a magnificent pyramid to house their tombs, so each hired a pyramid builder. The first builder started constructing his pyramid from the base and working upwards.
However, one day, the pharaoh suddenly died, and the pyramid was left incomplete. The pharaoh was sad (and dead).
The second pyramid builder started by building a very small pyramid.
Then he built a new layer, making a larger pyramid.
He knew that whenever the pharaoh might die, he would still have a completed pyramid shape.
How can we apply this tale to software development?
Work on the Core first
The second pyramid builder started with what would become the core of the pyramid. Similarly, you should start with the core of your app. If you're making a photo-filtering app, start with the photo filtering functionality. If you're making a news app, start with the article page.
Use Scaffolding instead of Permanent Structures
We're still not quite sure how the Egyptians built the pyramids, but travel to any building site and you'll see plenty of scaffolding. Scaffolding is not intended to be a permanent fixture, and when you're starting a project much of your code and data will also be temporary. Perhaps your photo filtering app will have a fancy login flow - but when the project starts, just hardcode in a username as temporary scaffolding.
In the next stage, perhaps you will replace this with a textbox for the username and password.
In the next stage, you might implement the fully designed screen.
Don't break the build
A common mantra among programmers, particularly when working with continuous integration is, "don't break the build". You should ensure that your code is always in a state that it can be built without errors, or quickly shown to a colleague or client as a demo.
Deliver value quickly
I was discussing our agile retainer model with a client recently and he remarked "this sounds interesting, but how long will it be before I have an app that's useful? Two months? Six months?" I replied "we deliver beta versions every two weeks, so our aim is that you'd have something useful and functional after two weeks. And something even more useful and functional after four weeks. And something even more useful and functional after six weeks, and so on."
As a software developer, that should be your goal, to deliver value throughout the development process. Start small and build iteratively, and you won't believe what wonders you will be able to build.
As an app developer, a question you are very used to hearing is "how much does it cost to make an app". It's also a question you quickly learn to dread. Why? Because providing an accurate fixed price for designing and developing a mobile app is next-to-impossible. Worse, comparing fixed-price quotes from different companies is misleading. In this article I'll explain some of the reasons why, and some better ways of pricing and organizing app development that we've found.
There are too many unknowns
How much an app costs depends on a large number of factors, many of which are unknown at the start of the project. We can try to minimize these unknown factors. We will always clarify which platforms and OSes it makes sense to support, what screen sizes, what features are essential and what are "nice-to-have". It's much harder to figure out how many iterations it will take to make a game fun, or to make a logic screen intuitive to use, or how long a vague feature like "add sharing" will take. Developers have to add in extra "padding" to cope with unexpected additions that occur as a normal part of development.
Changing your mind should be expected
When making an app, changing your mind is good. Iterating on an idea as it undergoes design and development leads to a far better outcome. But if the scope has already been precisely defined in the contract, this may not be possible. As of 2014, the app industry is rapidly changing. A business model which worked six months ago may not fit user's needs or market trends any more. To keep ahead of the game, you need to be willing to change things, and to pivot on your original vision.
All developers are not alike.
A popular metaphor is to compare asking how much it costs to make an app with how much it costs to make a car. A car could be very cheap, if it is simple, mass-produced and uses low-quality components. Or it could be complex, hand-crafted, unique and incredibly expensive.
If you give the same request to multiple developers and get very different pricing, what does that really mean? Why is this developer so much cheaper? Are they low-quality? Why is this developer so expensive? Did they misunderstand the scope of the project? As a client, how can you be expected to tell?
Apps are never "done"
The car metaphor has another problem. Because if you're building a car, you generally reach a point where the car is "finished". With apps, it's not so simple. It's important to get real users using your app as early as possible. So you typically want to do a "minimal viable product" release as soon as you can, and development work should not stop when you reach your v1 release.
As soon as people get their hands on your app, you'll get user feedback you want to incorporate into your app. There's always new features to add that didn't make it into the first version. You might even need to "pivot" how the app works, or change the business model from paid to freemium.
Even if it's not visible to the end-user, you may need to add analytics, email reports or dashboards to keep track of how people are using the app. The app needs to be marketed, perhaps ported to another platform. If you burnt all your budget developing v1, you are in trouble!
Fixed price projects: riskier than they appear
So, to summarize, the disadvantages with fixed-price contracts include:
- • It's hard to know in advance how much work an app will take
- • Developers often "pad" their quotations to account for unknown issues
- • Different developers will have different standards, so comparing quotes is hard
- • It's difficult to add in extra functionality, reorder or change functionality once the contract is signed
- • It suggests that there is a cut-off date where the project is "done", which is not realistic or recommended for most apps
At ReignDesign, we've recently started taking a more "agile" approach to estimating projects. Agile Development started in the software world, where it describes a way of planning software development projects which embraces the frequent changes that occur, rather than fighting them.
A backlog of features
The "user stories" to be performed are arranged in a backlog, which the product owner or client helps to reorder into a priority list. When new stories (things you want the app to do) are added, they are simply slotted into the backlog in the appropriate place. The developers then work down the list in order, in a series of typically 2-week long "sprints" they commit to completing the items on the backlog.
Applying agile to project planning
It turns out what works well for development can also work well for pricing of a project. Once we move away from a fixed-price model, the question is not "how much would it cost to develop this app", but "how much can I commit to developing this app, per month". When we move to a "agile retainer" style model of project pricing, the typical issues of project planning are turned on their head.
First we recommend a monthly budget to the client, based on their needs, the complexity of the project, and approximate dates for releases. We ensure the budget is sustainable, to make sure the client can afford to keep working on the app for at least several months after launch.
We then calculate how much work the developers and designers will do each month for that budget. This will allow us to estimate delivery dates for different stories, but these are advisory only. If it turns out we complete tasks faster than expected (in agile-speak, our "velocity" increases), we may be able to deliver features earlier. If the client requests certain extra features be added urgently, other items will get pushed down the backlog and delivered later.
Overall, an agile approach allows the client and the app developer to work in a way where their goals are aligned, and much better reflects the actual effort involved in creating and sustaining an amazing product on the App Store.
But, does it work in practice?
That's the theory: but does it actually work in practice? I asked two of our recent clients their thoughts on the agile retainer method.
We've been working with KindyNow for the last six months. KindyNow is a mobile app for childcare centres in Australia.
Parents who use the app can notify their daycare centre of last minute cancellations, immediately triggering an opening for other parents wishing to book the same space. We built the first version of the app on a fixed-price model but then switched to a retainer, which has allowed us to develop features in a faster and more flexible manner.
Here's Sean Collins, CEO of KindyNow: "Technology developments evolve at a greater rate than you will anticipate. Having a fixed fee each month allows us to prioritize and manage the work flow coming in. We can focus our attention on the right projects each month without being hit with constant quotes for specific jobs. The fact is by the time the first version is built you’ll have so many new ideas that your fee structure needs to allow for this constant evolution."
We've also been working with Peter Stoyles of Tasklinks, building a new version of their productivity tool from the ground up.
We discussed several methods of collaboration with Tasklinks, and decided that an agile retainer was the most effective way of building this app.
Peter: "Initially we were focused on getting a set price for the scope of work required, as the customer you feel safer that costs won't spiral and you have some budget security. The agile retainer model flies in the face of this conventional thinking but there are clear benefits. The first benefit is the retainer gives you a clear project outline, you can see the work in progress and are constantly in contact with the development it is no longer a remote process. The second benefit is as the app develops you can change the build feature priorities. This gives you more control over the development and can allow you to adapt quickly to market changes and user feedback.
To our surprise and to the credit of ReignDesign the development process has actually been ahead of schedule and we are now in a position to develop and include more features ahead of our target release date. It is very important that you work with good developers such as ReignDesign who have a good understanding of your expectations and can guide you through the development process, with that in mind I would recommend the agile retainer."
Matt is attending GMIC Beijing 2014 today and tomorrow, and guest-blogging for the GMIC Blog! GMIC is the major mobile internet conference in China, and this year's theme is "mobilising the next 5 billion".
— GMIC (@theGMIC) May 5, 2014