With those last set of changes made, we were ready to start testing the app on the student’s mobile devices.

Apple provides a way to test an app (called Ad-hoc Installation) prior to submitting it to the App Store. That’s how most apps are tested, to make sure that all bugs have been repaired.

The first round was a disastor. The iPod brought by one student was running iOS 3.1 and that app was designed for 4.3 or later. The screens on the iPad look horrendous since we were concentrating on the iPhone & iPod. The performance was extremely slow, since we had tested it only on WIFI and not on the 3G network. The app crashed a lot.

I built diagnostics into the app so that it recorded everything it did, and came up with an easy way for the students to email me the diagnostic log. These logs have been vital to resolving problems in the app – no one actually remembers what they did before it crashed (memory is quite subjective), but the diagnostic log would tell me exactly where the flaw was. The first live demo was done on Tuesday; by Thursday all of those issues were fixed, and we were back to testing again.

In the second round, we ironed out the issues of inviting friends and seeing each other’s wishlist. Lots of bugs, but quickly resolved. When class was over, we had about 8 students ready to test over the weekend. I’ve included what they’ve found so you can see what the “quality assurance cycle” is like:

• Click on ADD FROM PHOTOS – nothing happened on the iPad
• Long press on SAVE GIFT doesn’t always work
• INBOX doesn’t automatically refresh
• Description with SAVE GIFT doesn’t make sense
• Stars to rate a gift is too awkward since each star must be touched
• Top Toys is too hard to use
• Selecting an icon takes too long
• If not Internet connection during install, the app is forever hung
• App sometimes crashes after playing intro video on new installation
• Friend requests don’t always work
• If there’s only 1 item in the wishlist and you press on it, the app crashes
• No notification was sent out when a comment on a gift was made

A couple of these items are worth describing further.

Initially, the students wanted the app to pick up the toy’s name, picture and description from the web page. Finding the title and picture is pretty easy (as talked about in an earlier blog), but finding the description wasn’t. One student suggested that after you press on the toy’s picture, you let the user press on the descritpion.

To implement that, the user first presses on the picture, then presses SAVE AS GIFT – NOW GET DESCRIPTION instead of just SAVE AS GIFT. When we implemented that idea, the students thought it was way too confusing, so we dropped it.

The next feature that changed a lot was selecting top toys. First we used a web page that listed the top toys based on gender and age. The page was maintained by one of a toy vendor (such as Toys R Us), but it was not designed for a mobile device, so it looked awful on the iPhone. We eventually switched to an RSS feed from another toy vendor that is much easier to use.

Likewise, when a kid selects an icon (such as cute dog or robot or pokemon) was done by displaying a web page containing the icons. The look-and-feel was different from the rest of the app, so we switched it around to a set of screens that simply pulled the icons from our cloud server and displayed them on the screen (and showed a progress bar as the icons are downloaded to the mobile device). We decided NOT to preload the icons with the app since the icons take a lot of space, and we’ll be constantly adding new icons as kids come up with more suggestions.

While I was working on the changes the students ask for, we started talking about notifications: what did the app need to notify kids about, and how would it notify them.

We came up with the following list – the app would send notifications for the following:

• When a friend comments on your wish list
• When a friend adds new items to their wish list
• When a friend accepts your “friend” request
• When a friend’s birthday is coming

The last item requires the app to ask for the child’s birthday (month & day – not year), but its delayed until the child has used the app for at a week. This avoids the child from having to fill out another “boring” screen when the app is first installed.

We also created an INBOX where any messages (from a friend, or from WishToList – such as a birthday notice) – would appear in the INBOX. If the app is running, the red badge would appear on the INBOX icon at the bottom of the screen. If the app was not running, it would appear (using the standard iPhone manner) as a small circular red badge on the app’s icon on the iPhone Home Screen.

The students came up with ideas such as a countdown of the days before christmas or hannukah or kwanza, and maybe even allow the wish list to be sent to Santa Claus. We’ll reserve those for a future version.

First we demo-ed the initial user experience – what happens after its first installed. They hated it, and complained that it was too long, and they would reject the app. The said that an app that asks for their parent’s email (which the app does need, to be able to send the wishlist to the parent), was not an app they would play with.

To solve this, for each screen, we voted on whether to simply eliminate the screen altogether, or to delay the screen until that information was needed.

For example, we decided to not ask for the parent’s email at the start, but ask for it only when they are ready to send their wishlist to the parent.

Similarly, we eliminated the password screen, and only ask for a password after a few days. The app really only needs a password when it is reinstalled (on the same or different device).

The liked the screen that asks for the app’s colors, and icon and username, but they didn’t like the help text screen. It was too wordy. They said all help should be videos, since kids get bored in reading several paragraphs of text. Any screen that needed help on it should have a question mark somewhere on the screen that displays the corresponding video.

The students didn’t like the buttons on the top bar when searching for toys:

The symbols on the top bar were confusing (go back, hide) – they wanted words on the buttons, not a mix of icons and words.

That wrapped up the demo – lots of work for me to make those changes, but the the app’s getting closer and closer to “done”.