Before anyone thought that home improvement could be sexy, WGBH Boston started a series on house restoration. This Old House is  still going strong after 36 seasons. If you’ve never watched, each season a house in bad shape undergoes restoration. The cast goes through the paces of find what’s wrong, finding solutions and doing the work to make a new, beautiful home.

Recently, I headed over to my often neglected iTunes connect account, logged in and was met with the bright and friendly message:

 The following apps have unresolved issues and have been removed from the App Store:

Interval RunCalc

Going into the app, I found the message I expected to see:

Dear Developer,

On September 1, 2016, we announced that we’re implementing an ongoing process of evaluating and removing apps that no longer function as intended, don’t follow current review guidelines, or are outdated.

We noticed that your app has not been updated in a significant amount of time.

Next Steps

To keep your app on the App Store, submit an updated version for review and make sure it follows the latest App Review Guidelines. If you are unable to submit an update within 30 days, your app will be removed from the App Store until you submit an update and it is approved.

If Your App is Removed

Your app will remain fully functional for current users. They will experience no interruption to services, will still be able to buy in-app purchases, and can re-download the app while restoring from an iCloud or iTunes backup. However, we recommend that you update your app as soon as possible to reinstate it on the App Store and ensure that it remains functional and engaging for new and existing customers.

You can continue to use your current app name, as your app has not been deleted from your account.

Yep my app was one of the one removed in the great culling Apple threatened back in the fall of 2016. IntervalRunCalc was one of the apps that hit the chopping block. I wasn’t upset since the app had  only 13 sales in 2016. This isn’t big money, so really its no big deal if it lives or dies. If it had been more popular,  I would have been doing the revisions necessary to keep the app

I’ve just finished writing a piece for LinkedIn on Peanut butter and programming, which was a metaphor on what developers go through on a regular basis. I thought to follow up on that metaphor, I ‘d go through the process with a real app. I could go through the whole development process of Interval RunCalc, rebuilding the app using Swift instead Objective-C. Unlike my usual API of the week column, I thought of a This Old House type series on rebuilding an old app.   So for the next couple of weeks, I’ll be doing just that. We’ll explore the old application, then build models, new interfaces and putting it all together in controllers. We’ll go through the debugging process for the new app, and my adventure in getting the new app processed for Apple.  Along the way I’ll go through some good habits, find some old bad habits, and let you see my decisions as I rebuild the app.

The Original Interval RunCalc

Before we begin, you need to know the story of the app. Knowing the story of your app sets a lot of your design decisions.  You’ll need to know a little bit about running and one particular running coach, Jeff Galloway.  Running is a very popular form of physical exercise around the world. There is a lot of concern among non-runners and beginner runners about injury. Jeff Galloway, a 1972 Olympics  10,000 meter competitor for the U.S. and later running coach formulated a simple solution to the injury problem: don’t run so much by walking a little. His Run/Walk/Run method adds walk breaks or intervals during a run. You could for example run one minute, recover for thirty seconds, and the run another minute. You can workout on more complex patterns.  My current training runs for the upcoming race season is run four sets of  30 seconds run, 30 seconds walk, then pause for an full minute walk break, then repeat those for the length of the run.

For beginner runners, this has made entry into running easier, and has probably been one of the contributing factors to the popularity of race running. For older runners, the impact on bones is far less. There is a lot of evidence for cardio benefits of alternating between high intensity to low intensity activities repeatedly. Some faster distance runners are beginning to experiment with 30-second and less walk breaks once a mile to combat fatigue and run faster late in the race.

If you want to plan out a run walk run interval pattern to achieve a specific time or pace, there was no calculator to do it.  As a runner, I originally did it on spreadsheets, but the measurements systems necessary for pace, time and speed made such efforts clumsy. I wanted a tool, and figured others did too that did the calculations for me quickly. Input some numbers for intervals and walk breaks. Get back a pace, time and distance traveled. That’s why I wrote version 1.0 of Interval RunCalc.

The home screen contained basic information on pace, distance, time and speed. By changing one of these four variables you could see how it affected the other four.

This interface was very confusing, since you need to press the correct button and enter the figures correctly. Even for me, the developer, this was confusing. I fell victim to a very easy trap many developers fall into: Not testing the UI and believing what works is good enough.

Unless you know better, there were two more views in the app.  They were hidden in a button at the top.

 

Tap the button and you got a menu:

The Splits Calculator gave the splits at mile intervals and calculated your time if you decided to run some of those miles slower or faster.

  The interval calculator was the reason for the app. The user would input a series of intervals for the Pace,Speed,distance,and time.The calculator would give average pace, distance, and elapsed time back. The idea was to plan interval training runs using the app. Again, these interfaces worked, but was not easy to use.  I also added a few buttons at the bottom of the app that were confusing for adding and duplicating the intervals.

The last series of scenes I made were input scenes. Users would enter in values for HH:MM:SS time or MM:SS pace. A decimal keypad would enter  distance and speed. These all presented huge data validation problems, particularly the time.

    

Enter the Watch

A few months after the launch of Interval runcalc the Apple Watch came out. As fitness watch, it worked well with Apple’s products but not other companies. As of this writing, many still have annoying latency problems. You might  look at your watch for several seconds before getting an accurate number for your pace, time and distance. When I moved to an Apple watch from my Nike+  GPS watch, this drove me nuts. There is one exception to this latency problem: Apple’s native fitness app, which also has the active heart rate monitor data. Apple’s watch app however has no interval notifications. You can find those on a few of the big run-tracking apps, but not apple’s fitness activity app.

One solution did present itself. One of the 3rd party apps I used did intervals and sent a local notification to the phone when it was time to change intervals. When the phone went to sleep two minutes into a run, the notifications went to the watch — I had my notification by a tap on my wrist. I’d run both the app and the the apple fitness app at the same time.

If we’re going to update runcalc, there’s this one active thing it could do: send local notifications at the run/walk/run intervals. That way you can run this app in the background while using an apple watch to do the run.

Other Possible Changes

The original app was for iPhone only, I’d like to get it working well on a iPad, and iPhone plus in portrait might need a different look. These are both the regular size width class, and thus the issues would be related.

There’s one more feature I might want that isn’t there. Most of the running apps that allow additions of intervals for your workout want to know how many repetitions of the interval you want. For a one minute walk and one minute run, this is relatively easy. But for a 30 second run and 16 second walk, it isn’t so easy.  Knowing how many repetitions of this interval set make up a workout would be a helpful number.

Evaluating the Changes

Given the app’s current condition, let’s summarize the problems and ideas so far:

1. The initial scene is confusing to use
2. The two secondary scenes, splits and intervals are hidden
3. Intervals are not easy to read
4. I never use the splits
5. The intervals are hard to use
6. Input of data is difficult
7. Add notifications for intervals
8. Repetition calculation
9. iPad use(regular width size classes)

I’ll find more as I go on, but this will give me my starting point, and set me planning.

There’s a bit of advice I’d like to start with before evaluating these. When writing an app, keep to your story, the reason your app does what it does. Consistent stories make stronger products. The story of Interval RunCalc is a calculator for running interval calculations. I’m working with the number for planning purposes, not running with this. With that story firmly in my mind, I start to make decisions.

The story is about calculations for intervals, yet I set intervals on a secondary page, not the main page. It needs to be up front. Looking at the first page , I have a lot of extra whitespace. What if I added the intervals in that whitespace?

Here’s another thought: a simple continuous run is a single interval. As long as I always have one interval in the table the data on top summarizes all runs. I’m now doing two pages on a single page.

I’ll start wire framing, sketching what this might look like:

I used the simplest, fastest way to wireframe. In this stage, don’t get overwhelmed by apps and templates letting you lay out a wireframe app. Paper,  pencil, and a few highlighters works fine. As I did here I used the sketching mode of the Apple Notes app. I can clean this all up later. Work fast, or you’ll get so bogged down in distractions you’ll never get anywhere.  I’ll add two buttons on the bottom for adding an interval and clearing the calculator:

Then I get into a debate with myself: Should there be a third button, a totals button? If I select an interval on the lower half to edit it, Should I edit it in the upper Half? If so, I’ll need a button to deselect all intervals and set the upper half to totals? While compact, It again presents me with a problem: A hidden or confusing interface. It would be better to select a row in the intervals, then go to a second view to edit and enter there.

 

This would look nice and consistent on the home screen too.Each might be a button, and tapping it could change it.  I’ll also add a button for the repetitions as well.

In a few user interface changes, I cover most of the issues with 1-5.

What to Cut

My first cut is notifications. That should be a separate app.  I do have data that would make the notifications easy to add, but that does not mean I add it. Notifications are not in the story.  This happens a lot in development, often referred to as feature creep.  One keeps adding functions to an app that it becomes, slow, unwieldy and overall unusuable. One classic example is Microsoft Word, which has so many extra features outside its core story of typing out a document. I’d rather use a simpler general word processor like Pages or Google Docs instead of Word for most documents. In updating an app, unless its a feature demanded by users, avoid adding anything outside the story. If you are an independent developer, this is a lot easier than being in an organization however. You might have teammates, upper management or marketing telling you to put something in that makes no sense. The advantage of getting the entire organization to  buy into the app story is keeping everyone focused.

For the same reasons, I’m dropping the splits calculator.  Since this is an Interval Run calculator, Splits are  not in the story.

Input Views

I’ll make one more change that I have been thinking about. I didn’t like the input in V1.0.  My original notes for 1.0 tell me I hated the time it takes to use a UIPickerview as a user.  In V2.0 I’ll change all my input to picker views to restrict the user, which they are very good at doing. Unlike other picker views I’ve seen, I’ll speed up the picker with more components. Instead of 60 rows in the seconds of minutes picker component, ill have components of 0 to 5 in one and 0 to 9 in the other, so I can quick dial any number.  My time pickers would look like this:

This solves a lot of the validation problems I had with the text fields by restricting input, but speeding up the input.

The Regular Width Devices

Our final problem in our list is the regualr width devices of iPad and iPhone plus in landscape. I have a simple solution to that. I’ll have two major views, the intervals and the stats. In regular width mode, they will be next to each other instead of on top of each other

With all that decided. I have the beginnings of a new version of this app. Many of the user interface decisions were made and those influence the structure. I was a good boy and for the moment I added only one more new feature, and killed several features. I have a few more user interface decisions to make, but I’ll get to those a little later.  My next step is to get into the code, and I usually start that with the models I’ll be using in the app. In the next lesson, we’ll build those new models, and look at the old code to find some of the problems I encountered with the old model I might want to change in the new one.