Writing an iOS Kids App-Frog Draw

I recorded an episode of The Tablet Show this week where I talked about what I've learned about writing an app for the Kids section of the App Store, the kid's shape drawing app, Frog Draw.

The Parental Gate

Apple rejected my app three times. The first was because of sloppy layout issues on my part, but the last two were because of the Parental Gate. Basically, apps in the kids section have to ask for parental permission every time the kid wants to buy something or interact with the wider Internet. I somehow missed this, so the second rejection was because I'd missed this requirement. So, no gate on purchasing my beautiful stickers, and no gate on sending artwork via e-mail; bam another 5 days in the review queue. 

So I looked around at what that actually meant, and found these examples at Dreambot Studios. Amazingly, Apple didn't provide a standard API for providing a secure gate. I'd have expected there would have been an API that provided a localized challenge string, and a cryptographically secure method of validating a response. Instead, developers have to roll there own method to differentiate between a 12 year old and an adult. I chose a math problem I didn't think my precocious 8 year old could solve:

Frog Draw's Parental Gate

.

Apple provides a mercifully short set of guidelines for iOS app submissions and here is the entire relevant guideline for the need for a parental gate:

 24.3 Apps primarily intended for use by kids under 13 must get parental permission or use a parental gate before allowing the user to link out of the app or engage in commerce

So given this directive, I thought it would be easiest on the parent to provide a convenient one stop location for all the parental controls, so that the  parent could allow or disallow purchases, allow for making a quick trip to the App Store to rate the app, and turn on various means of sharing the drawings. All of these were off by default.

My Rejected Parental Controls Pane

I even put some Emoji characters in there so that non-English speakers could tell what they were agreeing to. And I submitted it to Apple and it was (I wish I could say promptly, but it was another 5 days) rejected. Why? Because while the guidelines make no mention of this, Apple has a rule that you cannot permanently enable a gated feature. Their rule is that the parent has to agree to its use each and every time.

I was pretty upset about this, but I kept calm and appealed the ruling to the review board, and was promptly told my appeal was rejected; this was indeed how the review team interprets rule 24.3. Two things, one I don't like arbitrary rules ruining my beautiful app with user hostile behaviors; I want to empower my users to have fun and draw some silly images.  And two, as a parent, I am not feeling empowered. As a parent, I would likely want to disallow in-App purchases even though Frog Draw only sells non-consumable clipart/stickers—I still remember spending $35 on Smurfberries—and allow e-mails. I don't care either way about rating the app. And turn off everything else.  But it's Apple's playground, so I did it their way.

Can Kids Apps be non-Skeuomorphic? 

As an adult with something approaching design taste, I am happy with iOS 7's lack of chrome and general removal of fake analog reality. I wish buttons had just a little bit of chrome, but otherwise, I'm a happy iOS user. But do children need something more? I guess I'll find out.

Here's my iPhone layout while displaying its color toolbox:

Frog Draw with Color Buttons

You'll notice that I am using recognizable buttons, but with light chrome. Also that the artwork projects into the status bar; this is under the user's control. Want to see what time it is? Draw something light under the clock. I'm using a light highlighting to show which tab is active, and in general I'm following the rule that controls should not be visually distracting. The important part should be the art. 

Frog Draw with Stickers

I hope this applies to kids too, and they don't require Fisher-Price controls and fuzzy bunny cartoons wasting space and distracting them; or more importantly for downloads that parents don't have a pre-existing view of what kids apps look like.

In my first version of this interface, I thought it would be cool to have iOS 7 style squircles behind my shapes. But testing with my kids revealed that children are already hard coded to tap on that shape (instead of what I want them to do, drag a copy off). So I removed the squircles which led me to change the color of my toolbox, which led me to change the color of my toolbox tab bar, which lead me to change my highlighting color which led to my final design, which I love.

An Early Design that had Issues. I missed Halloween.

The design choice I made which I'm most unsure of is the icon. On the one hand, modern iOS icons are geometrically simple, clean lined, abstract pieces of art. On the other hand it's hard to make a happy smiling abstract frog, it'll look too much like a duck. If my app doesn't sell, I'll blame the icon.

[Update: I've changed my mind on the icon. I'll dial back the cold inaccessible look and add some humanity to the 1.1 version's icon.

]

Kids and Gestures

I've already covered the importance of gestures in a modern interface but a few words about kids. Kids are more adept than we old folks at picking up gestures. They get the visual cues, they know what worked in other apps and they don't have a lifetime of mousing to unlearn. In fact, my daughter asked me the other  day, "what is a mouse?" when she was trying to figure out a Flash game on PBSKids (we use Magic Trackpads with our Macs). Kids pick up gestures if you give them enough clues or a visual explanation of what will happen when you do what. My major concern is communication with the user about the non-discoverable gestures like my 2 finger up down swipe to change the order of shapes. Thus, the importance of having a decent on boarding screen for the first time the app gets run. As I have the ability to animate the whole creation process of a Frog Draw document, my on boarding window has an animation of some gestures, and I hope this is enough, but I'll likely revisit this.

Make a Quality App

There is nothing about writing for kids that means you can cut corners. My son knows what a good app looks like and how it acts. Last night, he was making sure I knew I should have a longer tutorial/level  up section just like his best games have. At release of 1.0, I have a good app. I've profiled it to look for speed bottlenecks, I've rejected my own submissions to Apple more times than I'd like to count when something came up which would result in a child having a bad experience. The last month of development has humbled, but I think the end product is worthy. 

I don't know if people value this, but I do. The packaged up App is only 4MB. It would have been under 3MB, but at the last minute I had to add 64-bit support or Apple's face recognition functions wouldn't have worked on A7 based iOS devices. This was all possible because pretty much every pixel in the interface is drawn either in code or by rendering lightweight SVG, and not with bulky bitmap images. I hope potential customers don't see the small download size and think there's something missing, I value efficient use of a user's limited space. Being bulky will get an app booted off my iPad if I don't use it daily.

Frog Draw 1.0 Free in the App Store, no Ads, no consumable in-app purchases, just some child-friendly vector clip art. Thanks. [Update: now the app is $.99 and there are no in-app purchases. I'm trying different ways to make money. Still no ads.]

Change of Distribution Policy for Signal GH

Today I saw this review for Signal GH my HDHomerun utility: Don't buy if you're in Europe 1 Star Bought this without detecting that it is USA only. I wasted my money. Should have said on the App Store. Ripped off. Now obviously, this user didn't write me to try and resolve his problem. And I don't know if he didn't notice there was a setting for using the European TV standard, or if he did and it didn't work, or if he was upset that US users got the benefit of a map of broadcasters, but the fact of the matter is I don't know that Signal GH works in the UK or not; I just assumed it would. So, I am stopping distribution in Europe (excepting Denmark where I've been distributing for years without complaint). If someone in the UK or any other European country would like to try it out, let me know and I'll turn distribution back on temporarily. And users of the App Store should know they can contact Apple support shortly after purchase for refunds. [Update: Apparently the version I just put on the App Store 1.4.1 is broken for people who haven't done an initial scan and this is probably the problem the U.K. user saw. I've removed it from distribution and will be posting a 1.4.2 update presently]. [Update 2: I've submitted a 1.4.2 update to the App Store, and I apologize for the bad impression I've given to new users over last week. It was my error in not testing a clean install.]

Touch GUI and Replacing Buttons With Gestures

I've been thinking a lot about gestures lately. I submitted a kids drawing app, Frog Draw, to the App Store this week, and while I'm proud of it, it certainly ended up different than the plan in my head when I first sat down in Xcode and started coding it. Much of this, comes because of a gradual realization that gestures are better than buttons. Here for instance was my first thought for a interface for modifying objects:
The idea behind this was that the user would tap an onscreen object, a square perhaps, and this item would appear to give options in button form, including a rotation button which would follow the finger in a circle as he twirled the whole edit ring and object around. I had it all worked out that the buttons would rotate with the ring's rotation. I was quite proud of the geometric perfection of its layout; it was a perfect hexagon inside a perfect ring. And then I actually tried to use it.
The ring was in the way of things, preventing me from selecting other objects. And what if the object was up in a corner, obscuring a button, which required redundant buttons such as the doubled X delete buttons in the above. No, this would never do.

So I went with gestures. Translating via dragging a finger and pinch and scale gestures could be easily enough done, but what was the gesture to delete something? At first, and for much of the development cycle, I went with an analogous gesture to the Mail app's delete swipe, a quick leftward flick.
But that turned out to be too unreliable, as it was hard to both distinguish between a normal leftward translation and a delete, so half the time, I just ended up moving the object a bit to the left, or worse, an unintended deletion. Yes, I have unlimited undo, but still. In the end, I just accepted a drag of both the finger and the object into the toolbox area as a delete. Easy to do and easy to understand.

Which brings up another idea, the unimportance of direct manipulation. In the real world, if you wanted to drag a card around on a table top you'd put your finger down on the card and move it around, the finger always obscuring some of the card. In the digital world of the touch screen the programmer has a choice. If I have a selected object, why do I have to have my finger over it, preventing me from seeing where exactly I want it to go. Oh, I could bring up a loupe view to show what's under my finger, and perhaps magnify it, but won't that take up even more precious screen space? So, I decided that I could pinch, rotate and translate anywhere in my document view and it would change the selected object.
As I was testing my app, it became more and more obvious I needed an easy way to change the front to back order of objects. Many times, I'd draw a mask (maybe a frog's face) and want to put a photographic face behind it, peering through a hole. In the old days of desktop apps, this would be a menu item or a button or both, but not in mobile where space is precious. For a long time, I was intending to have a table of all the objects in a document layer, and the user would manipulate z-order by dragging one object cell to a different position (and I still might do this) but it seemed like this was a good opportunity for another gesture, and the easiest that came to mind was a 2 finger up or down drag.
This worked out quite well, as I could bring an object up or down several levels in a single swipe. I even used the same mechanism to re-order layers if no object was selected. What I'm giving up here is discoverability, few users will discover this behavior on their own. I put a diagram in the initial onboarding dialog, but time will tell if that's enough.
Not that the button is dead, I had thoughts of dragging color swatches onto objects, but that was just too much to ask of the user in terms of consistency, so I just have simple buttons to apply colors or other style settings to the selected object. Look for Frog Draw in the App Store next week.