The Story of Stories

When I wrote my first story, Pea and Carrot, for tapStory, I started with the text, which came very quickly—less than an hour. Creating the images took longer, but I had those done within a couple weeks. The harder part was building the story itself.

How do I build stories for the app? That answer has changed over time. That first story was laborious. Four years later, the process is considerably easier—it probably takes a quarter of the time, maybe even a tenth. That process will have to continue to improve, because I want to be able to produce new content for the app on a regular basis.

Structure

Stories in tapStory are not very complicated. They are, in essence, just a collection of images (each one representing one of the items in a scene, including images for each block of text), a set of accompanying files that define which parts of each image respond to touch and provide other information about them, and a text file that describes how the scenes are constructed. When I first came up with the structure of a story as the app understands it, I had to create all these text files by hand.

Each scene in a story is laid out on a 1024-by-768 pixel display—the standard screen dimensions of an iPad. Each element in the scene has a number of properties. Among them are position, size, and whether the item responds to touch. (There are other properties as well, but we'll restrict ourselves to these three.) If we wanted to put together the first two scenes of Pea and Carrot, it would look something like this:

---

* Scene 1
    * "Pea Looking Straight"
        * Position: (100, 100)
        * Size: 100%
        * Touchable: Yes
    * "Carrot"
        * Position: (900, 350)
        * Size: 100%
        * Touchable: Yes
    * "Text: Pea"
        * Position: (100, 200)
        * Size: 100%
        * Touchable: No
    * "Text: and"
        * Position: (400, 400)
        * Size: 100%
        * Touchable: No
    * "Text: Carrot"
        * Position: (700, 60)
        * Size: 100%
        * Touchable: No
    * "Text: Credits"
        * Position: (150, 700)
        * Size: 100%
        * Touchable: No

---

* Scene 2
    * "Pea Looking Right"
        * Position: (850, 350)
        * Size: 80%
        * Touchable: Yes
    * "Text: Pea was a pea"
        * Position: (300, 350)
        * Size: 100%
        * Touchable: No

---

Very Typing, Such Wow

For each scene in Pea and Carrot, I wrote text similar to this, only with quite a bit more information for each item. Just writing it all out took a while. Then, scene by scene, I tested it out in the app. Every scene needed adjustments, because I could only estimate the positions and sizes of the elements without seeing how they would look in the app. So I would make a tweak, re-run the story in the app, decide on more changes, and repeat. Partway through the development, I added a little display on the screen in the app that would indicate the positions of the elements as I dragged them, which reduced the back-and-forth estimation cycle. All the same, the whole process took quite. A. While.

All of Pea and Carrot was assembled in this way. I had enough other work to do that I didn't dedicate any time to improving this process until my next story, My Puppy Has a Puppy. I knew there was no way I could waste so much time on hand-editing the file for each scene.

Automation 101

For My Puppy Has a Puppy, I worked on code that would write this file automatically. With the new system, I could move elements around the scene by hand, and at the press of a button, the app would generate the file for me.

However, the file still needed lots of tweaks by hand. Setting things like touch responsiveness, or how the app transitions between two given scenes (pan, fade or cut), were not handled by the automated system. Also, there was still no way for me to put the elements in the scene in the first place, so I had to make the initial version of the file by hand. It was a start, but there was lots more I could do.

Evolution of a GUI

During the development of the next several stories, I continued my effort to make the story development process smoother. I began building a dedicated interface for editing scenes, independent of the interface that was in the app that would be published to the App Store. In this separate app, I had free reign to create exactly the controls I needed to define how scenes were constructed. I could also bundle all of the images for composing the story with the editing app. Now, without leaving the app, I could create a blank scene, pick its constituent elements from the catalog of all elements, lay them out, and generate the file which described it all.

It was at this point that I realized that what I had created could become a feature in tapStory. That original editing code is, in fact, at the core of the editing interface that's in the app today.

With the knowledge that I was building not just a tool for my own use, but a real feature, as I continued to make more stories and refine tapStory, I also made improvements to the editor. It gained the ability to control all aspects of scene construction, streamline selection of elements for scenes by adding them in bulk rather than one at a time, and make changes like changing the order of scenes and the transitions between them.

Today and the Future

As of tapStory 2.5, the editor in the app has almost as much power as the private story construction app. There are still some features, inappropriately advanced for young users, that will probably never make it into the consumer app. However, I no longer have to develop very much parallel code for my own purposes.

Despite all these advances, though, the process is still entirely dependent on me. I'm the only person who can create the stories, because it relies on a toolchain that includes the unpublished iPad app (which must be run in the simulator—not a device—via Xcode) and a separate Mac app to prepackage the elements and create the touch maps for them. I'm the choke point for the production process, and that can't continue for much longer.

So, this is not the end point. In order to be truly efficient, I need to hand over control of the story production process to others—interns, collaborators (writers and illustrators), and eventually, employees. I plan to create a separate iOS app that builds on the editor functionality but also includes the storage for the images and all the features of the Mac app. Once it's done, I'll have an app I can release on the App Store, or at least distribute in a limited way using TestFlight or enterprise distribution, that will allow anybody to create a story for tapStory and hand it over to me as a completed product.

How long will it take to get there? I have no current timeline, but I'm keenly aware that my limitation for getting new stories into the app will become a problem sooner or later. I'm looking forward to completing the process and relieving myself of the workload, giving the creators of stories full control of their construction for the app, and enabling a much faster pace for producing new stories.

The Hard Part

The journey of creating tapStory has been long and interesting. From concept to prototype to initial release in December 2013 (which was essentially a public beta), through to version 2.5 (my true 1.0, with a professional looking UI, a solid content library, and a mature feature set), I have learned a lot about developing and maintaining an iOS app.

Almost all of this work has been in a realm in which I am very comfortable. I earned a Masters degree in computer science and have a strong background in programming. I am also a good writer, a fair artist, and have a good eye and sense for quality, and I enjoy the creative process—all of which has made the process of creating a library of stories fun and exciting. I also worked at my own pace as my creativity and motivation ebbed and flowed.

Quitting

Then, on March 23rd of 2016, tapStory became my full time job. (Or, rather, I made it my full time job, after much deliberation and planning.) A job that made me essentially no income. I'm now at the point where I have to make money from all my hard work. When people ask me how it feels to be on my own, working for myself, doing something I'm passionate about, I answer truthfully that it's the pinnacle of my professional life. I also say, however, that I've done all the easy stuff.

I don't have any background in business, or in marketing. In tapStory, I have a product that I think is great. Unfortunately I can't rely on my opinion or those of my friends and acquaintances, who have unanimously pronounced it so (a bit of hubris I'll allow myself as a necessary measure of confidence for starting a new business). To date, word of mouth has not magically spread far and wide to give me the audience that I'll need in order to become viable. Every app developer wishes that this were the case, and I'm not any different.

The app has been downloaded a couple hundred times over its life (at a price of $0), and well less than $100 of stories have been purchased in-app. I've taken no investment capital, nor do I plan to. I have no interns and no employees. A more humble start is difficult to imagine. How can I possibly build from here to sustainability?

What I Know

First, it's obvious that there's no guarantee I'll succeed. Luckily I don't have much fear about trying, because iOS developers are in high demand right now. If I get to a point where I need income to survive, I'll be able to find contract work or even take a full-time job again. Of course, I hope I don't need to make such decisions.

Second, I try to remind myself that many people start from the same place, with an idea and nothing else. I have tons of examples to learn from, and I'm doing my best to make connections with peers who can give me guidance. I'm reading lots of blogs about the app business, attending conferences, listening to podcasts. I joined the Switchards Downtown Club here in Atlanta, a startup hub that specializes in consumer-oriented companies, and I've already benefited hugely from the educational and networking opportunities there.

And finally, I'm just having to learn by doing. I don't have the time to spend studying without acting. I try to do as much planning and thinking as possible before acting, but a lot of the time I'm winging it. Again, there are lots of people who have been here before, so I'm glad for being in good company. Some succeeded, even more failed, but all of them have interesting stories.

Stories

Luckily, I like stories! :-) This is the first of a series of blog posts about all of the things that I do that aren't related to coding or story development—marketing, business development, and anything else that doesn't directly contribute to the making of the products that I sell. So, no matter what happens, I'll have my own stories to add to the vast library of the ones that precede mine. I doubt that much of what I say here will be original, but I hope that at the very least my personality comes through in my writing, and that people who come after me will find camaraderie and kinship here.

A Perfectly-Timed Conference

I'm writing this on my 12.9-inch iPad Pro somewhere over the American West. (I'd tell you exactly where, but I'm too cheap to pay for in-flight wifi.) I'm on my way to San Francisco—incidentally during WWDC week—to attend the Developing Apps For Kids conference.

This is a really exciting point for me. I've spent a long time developing tapStory. It's been through lots of rounds of testing and improvements, a story development process that has resulted in 10 stories with more on the way, and most recently a redesign that included an entirely fresh coat of paint and a rebuilt user experience. (Although to call the work of my designer Claudia Monroy a fresh coat of paint is to understate the magnitude of her accomplishment.)

So finally it's time to market this thing. I can't believe I'm finally here, and I can't wait to get the word out. This will be taking lots of different forms, but literally the first significant thing I'll be doing following the release of version 2.5 last Friday is attending this conference.

I'm really glad that I found out about it. I took a circuitous route. I've never been that great at research, so the path led from one blog post to another, to a video from AltConf 2015. (References!) That presenter mentioned this conference, and when I searched for it online, I discovered (lo and behold!) that it was taking place in a month's time.

I anticipate tons of great connections with other app developers, a mountain of information and advice from the panelists, and a first mass-audience live demo of tapStory. I have tons of business cards to hand out.

I don't know what else will come out of this. Perhaps some lasting relationships. Perhaps a business deal. Maybe some press. At the very least, I hope that I will get the word out about my product and get people excited about it.

tapStory Origins, Part 1

This is the first of a series of posts about the origin of tapStory. It's been almost four years since I had the idea, and in late March I quit my full time job as an iOS developer make it into a real business.

All the iPad children's books that I've seen seem to follow a model in which each page contains the standard images and text, and then the child can tap on various items to cause animations and other kinds of interactivity. The problem I have with this is that it seems to encourage the "tap everywhere to see cool/cute things happen" mentality, which definitely increases engagement with the book, but what level of engagement is it?

What I'd like to do is provide the child with the ability to tell her own stories after/while reading the book. For instance, the child adds her own narration with her voice. Add to this the idea that she can move elements around as she talks and creates a story for them. Now she can also go to a play area with blank pages to put story elements together and narrate new episodes. All of the above scenarios can be saved, replayed and shared. A more sophisticated or older child could write his own text narrative and build pages like a true work of fan fiction.

This is a lightly edited quote from my iOS App Ideas file, which I keep to remember any cool potential projects that bubble to the top of my brain at random times. If you've used tapStory, you know how close the app is to this original idea as I write these words four years later.

I remember very clearly visiting with my mom, dad, brother and sister for dinner one evening, sitting around the dining room table and bringing up this app idea. I've shared ideas with them over the years, but they had a level of enthusiasm about this one that spurred me to make a proof of concept. It helps that I love writing, drawing and telling stories, and I view programming as a creative medium as much as clay or paint or charcoal.

Writing the proof of concept was fun. It was a way for me to figure out the basic mechanism of putting characters on the screen, moving them with my finger, and playing back those motions. A week of programming yielded this small kernel of code.

Moving stick figures!

Working on and off in my spare time over the next two months, I built a structure around this kernel to handle multiple pages and a means to transition between them. The basics of the app were in place.

Of course, I also needed a story to tell.

Just like the app itself, Pea and Carrot seemed to have just been waiting for me to discover it. Somewhere during that first two months, in one of those rare moments when an idea springs fully-formed from your imagination and you transcribe it, I wrote the story in one sitting. I then sat down with my Wacom tablet and Pixelmator to draw the two main characters. I tried to use a style that was cute without being silly, loose and sketchy but not shoddy. The colored-outside-the-lines look was one I decided on quickly as a way to meet those basic design goals. The fact that I only had to draw each one once and then make multiple facial expressions made the process much more efficient than drawing more sophisticated characters with lots of different poses. (Plus it closely matched my illustration skills.)

Pea was a pea.

All stories in tapStory are just a collection of images and a few text files that describe how they are grouped and laid out in scenes. For Pea and Carrot, I wrote all those text files by hand. (It took a while.) I also had to solve the problem of how to look at a finger touch in the rectangular area of the image for a character and decide whether it had actually landed on the character rather than the empty space around it. In a future post I'll dig into both of these challenges in more detail.

Because I use Git, I can go back in time and check out snapshots from any period in tapStory's history. (That's how I produced the GIFs above.) I think I'm really going to enjoy writing more about the evolution of the app. It's interesting to go back and see how something so big and complex evolved from humble origins.