The story of my latest app

-   Dec 15, 2011 -   iDevBlogADay, Software, iOS -   ,

In the past week, my latest app , RunNow Pro was approved and released in the Apple App Store. The app project began about 6 weeks ago. My wife and I were talking about running and my wife decided she was going to try to run a half marathon next fall. While it is pretty far away, we decided it was best to get started with a run / walk program so she'd be ready to hit the road come spring. I looked up some plans online and thought there would be an app out there to help with this.  There are lots of them actually, but of all the ones I looked at, none seems like the right one.  Later that week, I got an evening home alone with the kids and the idea struck me to make the app for her myself. That night, I had the kids record encouraging messages of when it was time to run and then when it was time to walk or recover.  After I got the kids to bed, I coded up the app and it was ready for her run the next day. Over the next few nights, I cleaned things up, added a settings page for controlling the workouts, and added a log so she could see the workouts she did.  It wasn't too fancy, but it worked well.  The personal messages were fun and it was very customized to exactly how she worked out.  She ran a timed workout of 20 minutes so she'd just run/walk for 10 minutes, the app would remind her to turn around and she be back in the driveway when her workout was done.  I decided I would make a version for release soon after. Over the next few weeks I spend a few more evenings polishing it up and sent the "Pro" version to the app store.  I removed the kids voices but added other notification options. It has a built in couch to 5k workout plan, but still has the manual settings which will make the app work well for running intervals or just doing a custom run / walk plan.  It runs great on our old original iPhone with iOS 3.1.3 which is the device my wife uses it on. I'm working on the free version of RunNow as time permits with less features, ads, and the ability to upgrade to the full version with in app purchase.  It is not my top priority, but I’ll hopefully be able to finish it up some time in the coming weeks.  It was fun to see this simple project come together so quickly and was a nice break from my larger iOS project that I’ve gotten back to in the last week.

 Perfect mockups

-   Sep 08, 2011 -   iOS, iDevBlogADay -  

There is nothing like drawing up your app ideas so you can visualize things better.  Like most of you, I’ve used the trusty paper and pen method the most.  I came across Balsamiq in mid 2009 and have used it a nice amount. It does some things really well and the end product is great for sharing.  However when there isn’t a widget for everything you need, it breaks down.  I usually found myself starting with paper and moving to Balsamiq if I need to communicate a design to others. Recently, I came across Noteshelf and it is my new mockup tool of choice.  Noteshelf is a slick notetaking app for the iPad that is currently at the top of the US iPad sales chart as I write this. Noteshelf is a handwriting app that just takes what you draw/write and saves it as an image (No keyboard input.)  As you would expect, there are lots of pen and color options along with the ability to import images.  You can create multiple notebooks to organize all your notes on the common bookshelf view.  Notebooks can be saved as images or PDFs.  Where this gets interesting is there is an in app purchase for designer paper which gives you an iPhone template and an iPad template for drawing mockups. Once you add these to your app, you can make notebook of mockup pages for your app.  There are some incredibly helpful features like the zoom feature which lets you make work a smaller section of the page to give you a finer control and wrist protection which when turned on keeps your hand from making marks when you are writing with a stylus. Pro Tip: Splurge for a stylus if you plan to give this a real test. It makes a huge difference. Once you’ve got your app mocked up over as many pages as you need, it is easily sharable. The export options are excellent. I linked up my DropBox account and that to me is the perfect why to export these at least until iCloud is fully rolled out. At the moment, the app is $0.99 and the designer paper pack is another $0.99.  $2 is a bargain for the perfect mockup tool assuming you have an iPad handy. Note regarding the marvelous sample images: I wasn’t quite ready to share any of the real mockup images I’ve done in Noteshelf yet, so I made up this fine sample of Rabbot.  I have no idea what it is or how it plays, but if you find an interesting game in there, I look forward to trying it out.

 Delayed release in progress

-   Aug 09, 2011 -   iDevBlogADay, iOS -   , ,

I recently finished up my 3rd App Store game, SudokuKids for iPad.  While I can't wait to see it available in the App Store, I decided this was a good candidate for delayed release. I know many people advocate the delayed release.  Usually, the main point is to try to build up a buzz around the app. Noel Llopis wrote a nice short description of delayed release at the end of his review of the Business of iPhone and iPad Development.  You can contact media/review sites and even give out promo codes for your app ahead of time with the goal of having most of your PR hit right around the launch day.  To be honest, I’m not expecting to be able to generate a lot of buzz, but any buzz does help.  The main reason I delayed the release of this app was to give myself sometime to work on some of the tasks I’ve been neglecting.  I’m not sure how important these tasks are but I was beginning to feel they were pulling me down.  I decided I would give myself a few days to try to get them in order before this app hit the store. First up was a new RazorAnt Software web site.  It still isn’t quite done yet, but is getting closer every day.  I needed to make more information available about my apps and this is the place for that.  I’m not sure how valuable the web site is for iOS game developers, but as I have some different apps coming up yet this year, I figured I really can’t neglect it any longer. Next, I needed to start getting some social media connections going.  I’ve just focused on making games in the past and hoped the marketing would come.  Word of mouth has been ok, but hopefully this will propel it a bit better.  Lastly, I wanted to work on getting better pre-release details together.  Better images, write ups, a press release.  Hopefully, I’ll be able to get a video done this week as well. I was kind of hoping this would be the calm before the storm type of thing.  So far, I’ve been busy, busy, busy and feel like I’m not producing a whole lot, but I feel better about the image RazorAnt Software is projecting and that counts for something.  Since this is my first iPad app, I’ll have no idea if any of this helped compared to my previous releases, but I feel better about what I’ve done. SudokuKids for iPad was approved last week and will be available in the App Store this Thursday, August 11th.  If you have kids, be sure to check it out.

 Getting the most out of Ad-Hoc testing

-   Jul 12, 2011 -   iDevBlogADay, iOS -   ,

I’m sure most iOS developers are familiar with ad-hoc testing.  For the uninitiated, it is a way of testing where you can put a development version of your app on someone else’s iDevice without having to have it sync to yourself. In the early days of iOS development, this was a somewhat painful process, but with the advent of services like TestFilght, this is now a breeze to do. Without going into to all the reasons you might want to do this, I want to focus this post on how you can make this process more valuable to you.  I’ve done Ad-Hoc testing with 4 separate apps now and each time I’ve changed up the way I did the testing to get better results from my testers. Test it early Now that Ad-Hoc testing is so much easier to distribute, bring it into your development cycles earlier. I’ve been running early tests with small groups of trusted friends.  It is super valuable to get some great feedback at very early stages in the development process.  Some of this feedback has saved me a lot of time pushing in the wrong directions.  It is just so easy to do now, I don’t hesitate to get those early builds out to those I trust. Be specific The first few times I did ad-hoc testing, I just included a message that said, “Check this out. Let me know what you think or if you have problems.” Oddly enough, I didn’t get the kind of feedback I was hoping for. As I’ve done more releases, I’ve found that highlighting new features and asking specific questions with the release has given me the type of feedback I was looking for. There is nothing wrong with asking your testers questions or asking them to take a look at a function and requesting their feedback on it.  You don’t want to lead them to answers though, so take you time and ask good questions. Make it easy to give you feedback Now that you are testing often and asking specific questions, you want to make it as easy as possible to have your users give you feedback. The easier you make it for someone to give you feedback, the more likely you are to get it. In my more recent testing process, I’ve taken to putting “Send Feedback” buttons right in the app to encourage testers to get in touch.  It can be as simple as a button that opens an email addressed to yourself or as advanced as you want it to be. Make feedback count Lastly, if you are going to get some feedback, you might as well get a serving of data to go along with it. When a user presses the “Send Feedback” button to send you information, there is no reason you can’t load some stats, error reports, logging details, or whatever else into the feedback message.  It is best to be up front with your testers that you are doing this, but I’d guess most won’t mind a bit. If you have suggestions on getting more value out of ad-hoc testing, I’d love to hear about it in the comments.


-   Jun 28, 2011 -   iDevBlogADay, iOS -   ,

Everything that man has created has been created with an audience in mind.  We create things for ourselves, for others and sometimes, we create for both ourselves and others.  As application developers, this is just as true. As we design apps, we need to determine who our core audience is.  This can be tricky enough but when looking at mobile apps, I believe we often miss the mark by including one extra person in the target group who rarely belongs there.  This extra person is ourselves. Building this for me As developers, you have likely created tons of little programs or scripts that are just for you.  These work great for you and might even be extremely helpful for someone else but they are not very polished and they rarely seem worth the extra effort to generalize and package them up for general consumption.  If you ever have taken one of these personal projects and made them available for the public you likely have had to make plenty of changes to make it understandable or even workable. In my experience, if you ever decided to share them with a group of general public (read non-developers), you will wish you had not or at least wish you had started with that in mind to begin with.  The transformation here can be huge. This app is for people who love ‘x’, just like me Building something that you will use yourself and will share with others for their use is a lot of fun.  You are excited about what you are building and if you are honest with yourself, you are sure the most everyone else with a similar passion will love it too.  While these projects are great, they often tend to focus on what you want the app to do.  You love ‘x’ and this is the best way to do/share/collect ‘x’.  (You get the idea here.)  Depending on your true aim for the app, this likely is not ideal.  If you are really just building the app for yourself and will let people use it if it suits them, then keep on truckin’.  There is nothing for you to see here.  However, if you are really building it for the masses (of which you happen to be a passionate member of), then you need to tread carefully. First off, as a developer, we tend to be tech savvy.  We know how things work, how to find and set options, and are often considered a master of every thing software related by most everyone we know.  What we see clearly, the average users often sees through a fog.  You likely already know this, but when things seem so easy to us, we tend to not see how it might not be clear to others.  This is always a trap for developers. Our passion for ‘x’ and our desire to see it ‘done right’ tend to lead to complexity. We want to build a better mouse trap so to speak.  It might be called “no feature left behind” syndrome.  More does not equal better. This kind of thinking tends to make us think of pruning.  We are trimming back the features and the UI to make things easy, light and wonderful.  However, I disagree.  Pruning is not the ideal answer. I made this for you When we do a project for someone else, we are not a user and have no idea what they need.  We need to watch, learn, and ask a ton of questions.  It is not uncommon for me to do a client project and build something I think is a bit odd, but my clients love.  Sure, I help them make design decisions.  We work on things together.  I share from my experience the things they should consider (and sometime beg them to reconsider), but in the end, I’m building something for them and they tell me how it should be. As a mobile developer, we likely don’t have that kind of contractual deal going on and I think we miss out on the give and take with the client.  Often, we are trying to imagine our audience, what they need and what would delight them.  We might have a few perspective customers to bounce things off of, but it often comes back to us and how we envision our audience. When we are part of that audience, the possibilities tend to get endless.  There are tons of ways to go with the app and things we could do.  The process can be become a pairing down of features and fitting in the things we need to stand out. When we can keep ourselves out of that audience, I believe we get a different product.  The general audience would tell us to start with the very basics that they need.  Get them done right.  Make them drop dead simple to use.  Make them shiny.  If (and really only if) we get that knocked out, it might be really special if they could do one or two other things.  The number of times my first project meeting with a small business client end up with this basic message is close to 100%.  Yes, I add to the value of the project and design, but it is as a compliment to the client’s vision, not the driving force. Experience My first iOS app was another learning experience in audience as I made a simple game for children.  SudokuKids started out as a test app to get my feet wet in the iOS world, but I learned a ton along the way.  My in-house audience for this app start out to be my 3 oldest kids, ages 7, 6, and 4 at the time.  (Note: A app for young kids has an odd audience.  Parents are going to be selecting and buying the app.  Children are going to be my users.  From a design and usage perspective, I was mainly worried about usage by young kids.  Some things were done with the parents in mind though.) So while I am a parent and could fit into the perspective buyer role, I was not a target user and was easy to keep out of the audience. I decided to spend lots of time watching my kids work on puzzles.  I watched them work on puzzles on paper.  I watched them with different interfaces and a few others puzzles.  I saw how they did things and what things they did.  I also saw many things I would have done they they never did.  I had to learn to hold my tongue as I watch them search for what to do or press next. I know that my kids, who had not spent a lot of time on the iPhone, had to be able to play the game without help or frustration and it should give them a good sense of accomplishment. This was an incredible learning experience (and lots of fun too). As it turned out, a number of the things I had on my initial brainstorming list for my test app, never made it there.  I don’t feel like they are missing, only that I misunderstood what my audience might have wanted before I got to know them better. I have heard a number of indie developers make comments to the effect of re-designing their apps so more people could understand them better.  I doubt this process is as effective as starting with that audience firmly in mind. Since we are often left with the job to envision our audience anyway, I'm just saying we should do our best to exclude ourselves from that group.  This is not to say that our design experience and awesome ideas are bad, just that they should not be the driving force of the design.  They are there to compliment it and make it special.