Codename “dogfood”, a New Side Project

Last August, whilst I was working on releasing version 2.0 of Reminder+, I had an urge to work a text-entry (and editing) style application. The goal of the app:

Make it fast to write snippets of text on an iPhone.

I spent a handful of hours putting something basic together and then went back to Reminder+. I kept the (very rough) app on my phone, to use in the background… it disappeared when I upgraded to iOS 9.

Was there any value?

I started to think about the app again over the Christmas break and so put it back on my phone.

The ‘app’ was essentially a collection of controls to manipulate the cursor position or text selection. In isolation these controls were useful for writing and editing text, but I was less certain that the overall package was compelling as an app.

This is what I was considering:

  • A single text entry screen, like a “scratch pad” of sorts, with an advanced keyboard accessory view.
  • Workflow: write the text you need and then jump to the app where you want to use it.

So I put it to the test.

The first course of dog food

The app went onto the dock. I used it. Daily.

Fairly quickly, I started to form the opinion that, working with this original vision, the app simply wasn’t appealing enough. There was too much effort in switching between apps for a small task (even in cases when it was a net win).

But the controls did work nicely, and I do like to be able to write, productively, on the phone1

A second course of dog food

So what about more general purpose note taking and writing?

A new goal emerged:

Enable users to be productive, writing on an iPhone, by improving the review, editing and correction of text.

No longer a scratchpad, a writing app, for short and long bodies of text.

An app I that I would use, myself2.

And now I really am eating my own dog food. I’m using the app regularly – to write my blog posts – and have been doing so since early January. And I continue to find it useful.

Stepping back, it feels like a great example of having a customer / user to help drive the development of a piece of software.

Every time I use the app I refine my view of what works and what doesn’t. What is the next most important feature to add? For the 1.0, what is necessary and what can be left behind?

So it’s a new side project. Codename dogfood.

  1. Note that, around this time, I did consider a keyboard extension. I dropped that notion for a combination of technical and user experience based reasons.
  2. In place of another writing app, for example, the rather awesome iA Writer that I’ve been using, previously.

How Many Apps Should I Try to Support?

I’ve had a post in my drafts folder for a while now, it details a kind of development strategy1, which among other things, is based around maintaining “one or two apps”.

I’m not sure about other developers, but I often have the urge to work on more than one idea; more than one app. I’m drawn by how an app might work and look, the problems it could solve. I want to see the idea done well, and of course, part of the lure is the possibility of success.

As I worked on that draft, restricting myself to only two apps felt like a good compromise. However, over the last handful of months my view on this has been changing…

So, how many apps should I try to support?

In my situation (hobbyist iOS dev and new dad) one of the biggest challenges is finding time. I’ve found that working on too many projects reduces my ability to focus and introduces a negative feeling of not being able to make adequate progress.

Going back to that development strategy draft, the thinking behind me maintaining one or two apps, was that I could, at least, alternate between releases; progressing the other application could always be the next project to work on.

But something happened during the development of 2.0 Nudg’em that changed my view: I dropped from 4 apps down to 2.

That was April. In a slightly more recent post about prioritising (June), I hinted at the positive impact this change had on my focus.

To say more: even though I was midway through the development of 2.0, those other apps still took up some of my time. Ideas, notes, conversations, download numbers, what ifs…

Removing those apps from the store stopped me thinking about them. Open loops were closed. It felt obviously right and I felt better about my App-Store-situation.

It made a big difference.

Such a difference that I started to consider reducing the number of apps further, to one.

Fast forward to now. I’m considering what to work on next. I could switch over to a second app, or, I could…

  • Get an iOS 9 update ready
  • Make a promo video
  • Make a website
  • Add new features
  • Make it universal
  • Add functionality for the watch
  • Etc.

Knowing that I struggled with time to finish the 2.0 project, switching to develop another application would simply halt all progress on Nudg’em.

It’s obvious: in my current situation I should focus on a single app, only.

About that development strategy.

I will go back to that draft as it involves more than just how many apps to work on. In some ways it is like a personal manifesto2.

For now however, the app of choice is Nudg’em. That means no further development for my newest app, Alter; I should remove it from the store.

I’ll explain the decision to go with Nudg’em in a future post.

  1. I’d considered calling it a “business plan”.
  2. Actually, I think “manifesto” is most fitting. – A Best Practice Resource for iOS and OS X Developers

For whatever reason it took some time before I started to consider best practice for iOS development topics…

Initially I was mostly supporting a friend’s development as we worked together on a couple of apps. Spending little time in Xcode myself, I followed his lead1. My role was handling the other stuff.

As I started to write more Objective C, I continued to focus primarily on the app itself, and other aspects of launching a product; in code I just wanted to get stuff done.

It wasn’t until later when I decided to produce an iOS app from start to finish, solo, that the notion of best practice crept up on me2.

I haven’t read every article that’s been published, but I have been following since they started it in 2013, dipping into the material that interested me.

Some examples that stood out to me:

As I’ve written above, despite following along for some time, it only recently occurred to me that this website provides an excellent collection of best practice articles for iOS (and OS X) developers.

Although the authors have taken a break from publishing monthly issues3, each of which have around 4 or 5 articles, there’s a substantial catalogue from a 24 month period to dig into.

I’ve written this post because previously, in my head, was just one of the tech-related sites that I read when I had time. I’ve made a distinction now4. To anyone looking for iOS (and OS X) articles with a development best practice slant, it’s definitely a resource to check out.

  1. Which was generally pretty good.
  2. I intentionally wanted to write an app by myself so that I’d have to overcome all of the hurdles; as it happened, this included consideration of best practice in some areas of the development.
  3. To (their words) focus on some more long-form writing.
  4. And I’m of a mindset to go back to all of the articles I haven’t read yet.