Otter Software Blog

Introduction

This is an account of how I devised and designed Lunchbox, my first completed iPhone application that will hopefully be in the App Store in a few weeks. It’s much longer than I originally thought it would be but rather than try to trim it down I thought it might be an interesting read for other developers and maybe its users so that they can see what goes into creating a ‘simple’ application. In addition, I am planning on following this article up with a set of smaller articles detailing some of the development issues I had and how I solved them.

The Problem

Lunchbox was born out of a personal need to be able to keep track of when my daughter is having a school lunch and when I have to make her a packed lunch. At her school we select items from a menu a week in advance, specifying what meals we’d like them to provide and on what days she will be having a packed lunch. This creates two main problems for me, one general and one specific. The general problem is that I have to remember what type of lunch she is having on each day. The specific problem is that since her mum and I are no longer together we have to remember to let each other know what the plan for the following week is.

Initially I tried to manage things using a combination of iCal and email but iCal wasn’t an ideal place for me to store this sort of information and hunting back through emails we’d sent each other about meal plans wasn’t proving to be the easiest solution. On a couple of occasions I accidentally deleted the emails and with no specific keywords to look for it was all a bit hit and miss.

It then occurred to me that having an iPhone application to store the details would be the best solution. As an added bonus, we are both iPhone users so I could take advantage of that to allow us to share data.

The Requirements

Based on the general and specific problems I mentioned above I decided that the application had two functions that I wanted it to perform:

1. Store information about what types of meals were being eaten and when.
2. Allow the information to be shared with other people.

The second item needed a tighter definition since there are numerous ways you can share information but two key considerations nailed this down for me:

1. It is entirely possible that users would want to share the information with people who didn’t have a copy of the application.
2. People who are sharing the data electronically may never be on the same wireless network together.

These two consideration ruled out raw data transfers between devices and pointed to email as being the best solution. The emails could contain a plain text description of the plan and could also be used to transfer the plan in a form that the application could understand. Additionally, if the application generated emails containing consistent wording it would eliminate the problem I’d had of being able to search for them in amongst the multitude that fill my inbox.

With all of this in mind the final requirements became:

1. Store information about what types of meals were being eaten and when.
2. Allow the information to be shared with other people via email and allow the information within email to be imported into the application quickly and easily.

Designing the Interface

The core of the application needed to be a screen that would allow someone to enter and view a week’s schedule of lunches. For the purposes of the application, a week would consist of five days, Monday to Friday, and each day should have three lunch options: school lunch, packed lunch, and no lunch.

As a developer and iPhone enthusiast (verging on evangelist) it is great to think about building an application that looks amazing and is full of custom artwork and bespoke controls. The sad reality for me however is that I’m hopeless at creating graphics and artwork so I have to pay someone infinitely more skilled than me to do anything like this and because Otter Software is not yet my primary source of income I don’t currently have the funds available to pay a designer hundreds of pounds to perform Potteresque-levels of Photoshop wizardry for me.

This meant that I needed to design something functional using the standard iPhone controls, the bonus being that it would be easier for me to make the application accessible. The fact that I needed to display five days at a time hinted at some sort of list which then narrowed things down to basing the interface around a table. Each row in the table would need to display the day’s name and a way to select the type of meal.

The Main Screen. Note that
the icons are not the final ones.

There were a couple of options for selecting the meal type. The data was going to be displayed in a table so I could go down the route of creating a hierarchy of table views where the user would tap on a day which would then display a ‘child’ table listing the meal options. Tapping an option would select it and return them to the top-level table where it would be displayed. An alternative was to allow the user to select the meal type in the main table view using a segmented control. This would show all three meal options and the user could select the one they wanted with a single tap.

The second idea seemed much more practical. It would be easier to write and maintain (there wouldn’t be any need to create a navigation hierarchy and additional views) and it would be quicker for the user too. A segmented control would also allow for faster use, one tap compared to a hierarchical solution’s two plus the additional delay of the second table view being displayed and hidden.

Embedding a segmented control in a table cell is fairly straightforward. However I quickly decided that I would need to use images rather than text to denote the meal type. This would save space and was one less thing to worry about if the application is translated into other languages.

The Data Model and Data Management

Having decided that the core interface would consist of a table with five rows, one for each day, with each row containing a segmented control to choose the meal type, the next issue was data. The application would need to know which meal type was assigned to each day and in theory the data model should therefore be storing a date and an indicator of the meal type. However this would mean that each time a week was dispayed all of the data would have to be filtered to find the five days that were needed and then sorted to make sure the days were shown in their logical order. This seemed to be inefficient and overly complex for what was needed.

Taking an alternative look at the way the data needed to be stored, what was really needed was the date of the first day of the week and then the five meal choices in order. This would mean that the data search would only be for one date and that the data for that week would be returned with it, already sorted. With three meal options being available and because segmented controls identify the selected segment via a number, it seemed logical to simply identify them using the numbers 0, 1 and 2.

The question of how much data needed to be stored was also considered. Because meals are booked a week in advance the application would definitely need to be able to display the meal plan for the current week and the following week. Other than that all data would seem to be superfluous. There was no necessity to keep historic data and it was impossible to plan more than one week in advance.

Considering that only two sets of data needed to be stored, one for the current week and one for the next week, and that it was easiest to group the data by the first day of the week, a very simple, lightweight data model was created. This was based on an XML file format called a plist.

To keep the data file clean and lightweight, when the application is launched the data file is scanned and any data relating to weeks other than the current and next one is deleted.

An Interface for Two Weeks

Displaying a table of data for a single week is pretty straightforward. The consideration was how both weeks could be optimally displayed. Having them both on the same screen was quickly ruled out because everything would be too cluttered and having a clear distinction between which week was which was important to the usability of the application.

I then had two options to consider:

1. A single view whose data would change, preferably with some animation to show that the weeks were changing.
2. 2. Two views, one per week, which would be swapped, again with animation, to show the change.

Mid-drag of changing weeks.

I actually did some testing of the first option but it really didn’t work well. The table could be made to appear to slide off the screen and then back on with the new set of data but it didn’t look smooth enough and just wasn’t right and there certainly wasn’t enough animation to make it really look like you were moving from one week to the next.

The second option, using two views, opened up all sorts of possibilities. For example, the views could flip over, hiding one week and revealing the next, or they could use the page curl effect. However I also wanted the user to be able to swap between the two weeks by swiping horizontally so two side-by-side views were ultimately used, the same approach as is taken in Apple’s Weather application. However, rather than showing the page control (the little dots) at the bottom of the screen I decided that since there were only ever going to be two pages I could put a segmented control in a toolbar and label it with ‘This Week’ and ‘Next Week’, making it very clear what was being displayed.

Data Sharing via Email

With the core user interface and the data model dealt with I next focussed on the email aspect of the application. I needed a way for a user to get the data out of an email and into their copy of Lunchbox as quickly and as easily as possible and the obvious candidate appeared to be to use the iPhone’s URL system. Essentially this allow limited communication between applications using URLs so ,for example, a URL in an email can be used to launch an application and pass it some data, exactly what I was after.

The standard email.

The first job was to generate an email and I took advantage of a feature that was introduced in version 3.0 of the iPhone operating system which would allow the user to generate an email from within the application rather than having to switch to Mail. The main body of the email would describe the data for the week so that it was comprehensible to a person. Following this is the URL that launches Lunchbox and contains the data that needs to be imported. Finally, for a bit of marketing I added a URL to my own site’s page about Lunchbox so that if someone received the email and had no idea about my application then they could go and check it out. It also reminds the user that I have a section of my site dedicated to the application.

The data-sharing URL contains two parameters. The first is the data of the Monday of the week the data relates to. The second is the day-by-day choices for the lunch types. This is a sequence of five numbers, 0 to 2. When Lunchbox launches and detects that it has been launched by a URL it performs some checks to make sure that the data it has received is valid. This ranges from making sure that the date is either the date for this week or the next week and that the lunch type information consists of five numbers between zero and two.

Two Small Details

With most of the application planned there were two small thing that were still bugging me.

The first was how the user would generate the email. The toolbar along the bottom of the screen seemed to be an ideal place to put a button which would launch the email editor but the segmented control used to select the week took up most of the space and if I put the button in the toolbar lost its symmetry. The segmented control needed to sit in the middle of the toolbar and adding a button made it all too squashed up and unbalanced. The solution ended up being adding a new row to the table, completely separate to the main part, which, when the accessory button was tapped, would display the editor. Having this row towards the bottom of the screen with a large gap between it and the rows relating to the days means that there is enough visual separation to allow the user to realise that it is a completely separate area of functionality.

The second annoyance related to the fact that most people who use the email feature will only ever send the message to the same person. I wanted to help the user by pre-populating the recipient’s email address but the editor provides no mechanism for me to find out what email address they entered so I needed an alternative approach. The only real solution to this was to allow the user to define a default email address and this was done via a settings screen within the application as opposed to using the iPhone’s Settings application for one main reason: I would be able to provide a system whereby the user could select an email address rather than type one in.

The Settings Screen

The Settings Screen.

I initially mocked-up a settings screen that used an image as a background and contained buttons to allow the user to select the default email recipient, send me a feedback email, visit the Otter Software web site, and visit the Otter Software Twitter page. It looked awful and totally out of place with the main screen in the application.

I therefore re-designed the screen to use my old friend, the table view, segmenting it to split it into a section for the settings and a section for the contact items. To brighten it up I added icons to the three contact items but the default email recipient row then looked a bit bare. A silhouette graphic helped but to add a bit more style to it and because the default email recipient was selected from the Address Book data I decided to display the contact’s picture if they had one.

The Next Steps

As of today Lunchbox is fully functional and is being used by myself and my ex-wife. I’m waiting for my designer to finish work on the application’s icon and on the three images used in the segmented control and then I will be in a position to take on the big challenge: getting the application approved.

Whilst I’m waiting for these two things to happen I need to spend some time working on my web site. At the moment this is currently consists of one page: a teaser for Digestive. I need to create a Lunchbox-specific page and create the basic elements of my site such as a feedback page and a support section.

I have to also make a decision about pricing. Initially I thought I’d release this as a free application but I’m now leaning towards charging for it. I’m not expecting to make many sales but it would be good to at least go some way to covering the design costs. I’m under no illusion that my development time will effectively have to be written off but getting a small return is definitely better than nothing.

Lunchbox was born completely out of a personal need and I did consider never releasing it but it will be a good initial toe in the water of the App Store and will at least give me some experience of what to expect when I release something more significant such as C-Log and I’ll be using this blog to document the experience.