Most popular toys


Since one of the features the students wanted was “Most Popular Toys”, I asked them how the app would figure this out. I received a lot of blank stares. Their reply: “It should just know”.

One suggestion “It could do a web search”. I asked “What would you search for?” to which they replied “What are the most popular toys this week”. We did such a search online, and they could see from the Google answers that the results were irrelevant for the app.

They also wanted TOP TOYS to be divided by gender, age group and category. I asked “How do we determine what category a toy is in? How can it know if a toy is an action toy that’s made for 10 year old boys?”

A student said why not look at what toys are being added to their wishlist with our app. That’s good, but what do we do until we have thousands of kids using the app? What do we show when there’s just a few dozen kids using it, when we first launch our app?

All good questions, but no real answers. Kids perceive the Internet is a place where everything is available in exactly the format you need. Our class was starting to open their eyes that information may be out there, but not easy to manage or use.


Press to see details


You would think that a screen just to show the toy’s name, picture and brief description would be trivial.

We spent an hour laying out this screen. The kids had to come up with how large the toy image should be on the screen, where the title should sit, where the description should sit. Then they had to revise their answers based on how the screen would act once the keyboard pops up (on an iPhone/iPod, the keyboard used to type in the title or description would occlude the lower half of the screen).

Now that they could imagine how the screen details would appear, they wanted to add more and more features:

  • Private notes for their parents
  • A button to NOT share this toy with their friends (if they felt the toy would be mocked)
  • A way to remove the toy from their wish list
  • The toy’s price

We determined the screen would have to scroll vertically to see all of the information on the toy, and when you type, it will scroll so what you type is in the upper part of the screen (and the keyboard is on the bottom).

While most of this is irrelevant for the iPad, I didn’t want to defocus now. Better to have the students contend with the design constraints of the iPhone/iPod and dive into proper layouts on devices with more “screen real estate” at a later time.

Here’s how the final version looked:


The wish list


As the app became more real, I wanted the students to layout the most critical feature of the app – the wish list itself.

We held a contest in class of which screen design to display the list. They had to consider:

  • Who’s list is it?
  • How many items should be seen on the screen at once?
  • Is the list in any order?
  • Should a picture of the item be included?
  • Should the price of the item be listed?

By analyzing each topic, the students were putting themselves into the role of a “consumer”, coming up with the best possible design. For example, when looking at your own wishlist, your name does not need to appear on the screen (which enables you to see about 6 items), but when looking at your friend’s wishlist, you need to be reminded of the name (at the top of the screen), and you’ll only see about 4 or 5 items.

To get the details on a gift, the students evaluated zooming into an item (that has a very tiny description) vs. “hyperlinking on the web” – pressing the item to see the details.

We settlted on the wish list would show a little picture of the toy on the left, a title, and a one-line description, and would scroll up & down, and pressing on the picture or title would bring up the toy details.

Here’s a screen shot of the wish list as it looks in the final version of the app:


Real names, usernames & icons


Now that we most of the navigation icons, the kids were really concerned about how to share their wishlists with other kids.

First we discussed whether or not to use real names. Most of the students understood Internet safety rules, so they quickly agreed that using a real name was a bad idea. We settled on using made-up usernames. Since the app would be used primarily by kids 8 to 14, we decided that the Club Penguin approach (where you assemble a username from a “safe” keyword list) was a bit too restrictive. We also agreed that their should be some parental control features (suggested by more than one of the students), just to keep things extra safe.

Everyone wanted to have a cute icon associated with their username, but we couldn’t decide how to keep that safe. We wanted to avoid kids uploading inappropriate pictures as their icon.

That opened up the flood gate of icon suggestions – Disney characters, video game characters, farm animals, planets, presidents, sea creatures, vehicles, movie characters, robots, food, candy – the list went on and on.

Each student selected a category and volunteered to draw out the icons for their category over the weekend, and submit them at the next class. In the end, here are some of those what we included:


Icons for the main screen


I wanted students to really believe that app was theirs, so each of their good ideas had to be included. The fastest way for them to achieve this was for students to design icons for each navigation item.

It took a while to get this idea to the students – that their hand-drawing of an icon can actually be used in the app. I tried several methods – have them draw icons at home, draw in class on paper, come up to the board – with few unique or interesting results. Each of their icons resembled something they’ve already seen on a mobile device or PC.

While that shows how computer savvy the kids already are – they’ve become accustomed to the user design frameworks promoted by Apple, Microsoft and Google, I was hoping that kid-created icons would give a more kid-friendly appeal to the app.

Since the kids couldn’t come up with anything new, I purchased a set of hundreds of mobile device icons, and proposed alternatives for each navigation item. We needed about 25 icons for the app; the kids selected the same icon as my first choice, but selected something much more “kid-oriented” for the other half of the icons.




This blog describes how 5th-8th grade students helped build the free iPhone/iPad/iPod app WishToList; info at


Navigation Menus


The goal for today’s class was to take all of the features and categorize them: what’s at the top level, and what’s at the sub-level.

For example, “ADD TO WISHLIST” is considered at top-level menu item, but ADD BY SEARCHING ON THE WEB, ADD WITH CAMERA and ADD FROM PHOTO GALLERY are considered sub-level menu items.

As before, most of the suggestions started off by what the kids knew about other apps, such as Instagram. When we discussed how to invite friends (and which sub-menu items are needed), they suggested – “Let’s do a shoutout” – “Wait – since the app is about wishlists, let’s do a wishout”. That opened up the idea of linking in to other apps – give kids a way to invite friends via Instagram, or post their wishlist to Instagram.

We continued down this path for a while, and the app was starting to become real to the kids, and the class took on a new tone. They began discussing how their parents would view their wishlist. Some said that their parents would just ignore the list, others thought that it should have a budgeting feature so they don’t ask for more than their parents can provide and some thought it have limits on the number of gifts you can ask for.

That lead them to including prioritization of gifts in their list, and include special notes to their parents about why getting a specific gift is important to them. The kids were turning this idea into a great app.

This blog describes how 5th-8th grade students helped build the free iPhone/iPad/iPod app WishToList; info at

Creating the first screen


For the students to appreciate how an app is built, I decided to start from the top-down: layout out the top-navigation menu, then determine what function each menu item should perform, and then create the features of each menu item.

We already had what the major functions that app can do; now we needed to create a way to select each associated screen. The kids started off by suggesting navigation menus similar to what they were used to one the iPhone. There were three major suggestions:

  1. A vertical scrolling menu, icons on the left, title on the right – like most iPhone apps such as Contacts
  2. A grid layout of icons – like the iPhone home screen
  3. Different rectangular and square tiles of icons – similar to the Windows Phone
  4. Horizontal scrolling tab bar at the bottom of the screen (like in the iPhone Phone app, but with scrolling)

Some choices had obvious downsides, so I asked each student to critique the layouts they didn’t like. The problems with the grid layout (#2) was that once you included a title, only about 4 icons would show. The problem with the tile layout (#3) was that we couldn’t decide which tiles should be big, and which should be small. They liked the horizontal scrolling bar at the bottom, but that’s fairly difficult to implement on an iPhone (and doesn’t follow iPhone standards), so I discouraged it.

The final vote was 9 for #1, 4 for #2 and 0 for #3.

This blog describes how 5th-8th grade students helped build the free iPhone/iPad/iPod app WishToList; info at