I have two little boys. They aren’t school-age yet, but I’m already fascinated by everything I’m reading about how technology may be implemented in their future classrooms. Last week, I came across this article on how a pilot iPod Touch program in third-grade classrooms led to radically improved reading and math results on standardized tests.
When you think about it, these results make complete sense. Let’s look at two scenarios:
Scenario A: Standard-issue math class
You get your sheet of problems, which you work out as best you can, and then turn them in to your teacher without knowing which ones you got right and which ones are wrong. Your teacher marks them that evening, and you get your marked-up paper back the next day. The problem with this scenario is that your brain is, by now, a thousand miles away from the problems you got wrong. Most adults are incapable of internalizing delayed feedback efficiently. Why should we expect children be any different?
Scenario B: iPod-equipped math class
Your teacher gives you your math problems. You start working away. Each time you get a question right, you get positive feedback from your device before you’re taken to the next problem. When you make a mistake, you get immediate feedback, too. After receiving a few prompts and tips, if you’re still struggling with a problem, you’re directed to get a bit of immediate coaching from your teacher. He or she comes over, talks you over the hump, you nail the problem, and then move on to the next one.
Which scenario do you think would result in a more successful learning experience?
Since this is a performance blog, you can probably guess where I’m going with this…
When it comes to kids and website performance, how fast is fast enough?
If web- and app-based learning is the wave of the future, designers and developers will need to develop expertise in the unique online behaviour of children. There’s already a lot of data out there, about everything from preferred fonts (14 pt Arial, FYI) to the best kind of “close” button (a big red circle with an X in it).
What there’s not a lot of: data about children and site speed.
It’s surprisingly hard to find this information. Like the Victorians, our tendency seems to be to pretend that children are just miniature grownups, and to assume they have the same expectations and behaviours that we do. Are we as misguided as the Victorians?
I did find this recent usability study by user experience guru Jakob Nielsen, but I have to admit, I balked at shelling out $188 just to read the small section on page load times. Instead, I gleaned what I could from the summary, and then did more digging around the web. Here’s what I found:
- Research consistently shows that most children under the age of five have an attention span of between 8 and 15 minutes. Many children have even less.
- Like adults, children are quick to judge a site, and to leave if they deem it no good.
- While adults have some (if limited) patience with waiting for pages to load, children want instant gratification. They expect to see some kind of picture right away when they hit a button.
- A recurring theme in many studies is that children tend to wait for images to completely load on a page before navigating to another page. They don’t understand that a complete page load is not needed for the page to be functional. Not surprisingly, all this waiting makes them frustrated and likely to be discouraged from using a site.
So how do you design a fast site for kids?
The obvious challenge in creating a fast user experience for children is in the fact that kid-oriented sites tend to have more, not fewer, bells and whistles than sites for adults. Graphics, animation, third-party apps — how do you serve these nigh-instantaneously?
When I went digging for workarounds, I found an interesting comment on this O’Reilly Radar post from a reader named Preston Austin. He said:
Back when under a few seconds load time was still considered a “good” page and aol dial up mattered a lot and still wreaked havoc with everything (late 90s) I was developing lots of little activities for a very popular children’s web site. We saw traffic in excess of 5 million dynamic hits on a good afternoon and wrote our own stats package – so it was easy to measure fine changes in user behavior.
In an effort to increase kid’s satisfaction with the site, we started experimenting with simplifying pages to get some kind of page showing fast and then precaching subsequent content in certain non-game activities so that things would be gamelike – and happen near instantly on a click.
It was pretty interesting – we discovered that we could readily lengthen all of number of sessions, estimated repeat sessions, length of sessions, number of clicks per session, and most interestingly rate of clicks per session by pre-caching likely next moves while a child was viewing current content (we used various horrible hacks, and tools like Shockwave and later Flash to do this). To really make a difference, we had to get the response to clicks down under about 200ms.
Even though Preston is describing events from the late ’90s, I’m willing to bet that his conclusion — optimal page response time is under 200ms — holds true today. It makes sense given Jakob Nielsen’s persistent findings about how human beings react to page delays:
- 0.1 seconds gives us the illusion of instantaneous response.
- 1 second keeps our flow of thought seamless.
200ms doesn’t quite give the illusion of instantaneousness, but it’s well within the threshold for keeping the user’s flow of thought seamless.
Report card: How fast are kids’ sites today?
With that 200ms goal in mind, I ran some quick tests on a handful of well-known kids’ sites.* The results aren’t pretty.
|Website||Page load time (in seconds)|
|Sports Illustrated Kids||9.571|
Ouch. Clearly, the bar is low. If we want to deliver websites and web-based apps to children, we need to do better than this.
(On a related note, Google recently launched the Family Safety Center, a collection of tools and resources to help parents and educators figure out how to help their kids safely navigate the web. Definitely worth checking out.)
*All tests were conducted using Webpagetest: IE7 on DSL via the server in Dulles, VA.