At the start of this year I had this crazy idea. My crazy idea was this: Somehow I could enrol in a ‘full-time’ PhD research program, and yet (crazy, I know) still find time on top of my ‘full-time’ PhD research program to do other work on my own iPhone app(s).
Turns out I was wrong. Wrong wrong wrongity wrong. I guess I’m writing this post as something of an apology to all users of Time Flies, especially those who I foolishly promised changes ‘coming in the next update’.
I do hope the app is still useful to you all in its current incarnation (after all, it hasn’t changed), and I hope you all continue to find it useful. While updates are coming, I can’t honestly say when they will be, other that they won’t be soon.
How do you think about time passing? Do you think about start dates an end dates? Periods? The passage of the sun across the sky?
I’m asking because I’ve just finished a new feature for Time Flies – the most requested addition to the app – a history log for your event updates. Time Flies as it stands is a memory aid that uses a single metric – when you last did something. Adding a history log to an event adds 2 additional metrics that can be used in all sorts of ways – frequency (how many times have I done something?) and regularity (how often do I do something?) The challenge was to present these on a single coherent screen without compromising on the fundamental simplicity of the app (which, based on user feedback, has been a large key to its success).
I had a few constraints to consider – the history needed to be in a list format (for consistency with the main app screen, and for the functionality I wanted to leverage from within the UITableView framework), and I wanted to avoid using icons or images – part of the simplicity of the existing design is in it’s text based interface. I also wanted the feature to be unobtrusive – not all events require a history, so it shouldn’t be too prominent – for this reason I decided that the history log should be accessed via the “edit” screen, not on the main event listing.
I went through a lot of design iterations figuring this out. The main edit screen fell in to place very quickly – I’d designed it originally with a lot of space just in case I did decide to add a new metric – a button below the date did the trick. But what about the history log itself?
My first functional iteration was really just a tech demo – it shows the start and end dates and a time period so that I could be sure that the data was tracking properly and the database upgrade ran smoothly. The long dates are conceptually too far removed from reality to be a useful reference (unless you are really good at calendars), and the time periods sitting above are meaningless out of context (15 days since what? Or to? From? Between?)
From here I moved through a lot of different configurations. I tried showing From: and To: labels(too messy), time from now (not relevant anymore, once an item is in the history the important metric is time between events), just the start date and the intervening period (almost right, but still confusing). After some discussion with K, I understood that confusion was arising because the periods (3 hours, 2 days etc…) still weren’t clearly being read as a time between one event and the next in the list.
The solution seems very simple now but took a lot of getting to – I removed the the lines between entries to connect them conceptually as a single stream; added of a small red arrow to indicate time direction and to link each period with the next event – now you can see when an even started (the date), and how long it was between updates (period description+arrow); the large space for the event description at the top places emphasis on the most recent update (a stated goal in the original design) and demarcates all below it as historical.
I’ve been using the new feature for the last few days and I see why so many people have emailed me requesting it – it really does enable another level of understanding of your own actions – it’s all about self awareness, mindfulness. I really thought I went for bike rides more often…
On top of that, the app will now store some very useful data points for future additions if I go down the track of implementing built-in data analysis, which could be a very interesting path to pursue.
Partly as a consequence of all the feature requests that I’ve been getting for Time Flies, I’ve been thinking bout the tension that exists in the design of software between specificity and generality. Time Flies was designed with a very specific action in mind – to help you remember the last time you did a particular action – and most of the features requested are natural extensions of this: history logging, notifications and alarms, expiry dates for events, [online] calendar integration, statistics, data export, categories… all perfectly valid ideas for extending the functionality.
What I’ve realised from this feedback is that Time Flies is what I’d call specifically general. It does a single, specific thing (track an event and a time period), but the contents of that event are not specified – meaning that it can be used in an enormous range of use cases (many that I hadn’t considered until I started getting feedback emails). This is where the specificity can become an issue for some – by being so specific it excludes some actions which are natural extensions of some of these uses. Everyone does things they need to remember, and all events have a start time – hence the design of Time Flies. But some events have an end time too – expiry dates. Some events will start in the future – notifications. Some events repeat on an interval, or relate to goal tracking – history logging. Some events you want to remember for longer than the life of your device – export, calendar integration. You get the idea.
I think that people are generally very good at managing a wide range of specific tools for specific tasks – think of all the kitchen implements that you own, the different shoes that you have. I own a single piece of metal specifically for adjusting the seat on my bicycle.
Over the last ten years we have been trained to assume that a piece of software should do everything – work as a ladle, and a sieve, and sneakers and dancing shoes, and adjust your bike seat. Look at Photoshop or any number of Microsoft products for extreme examples of this. The idea that software should do everything often leads to designs that add complexity out of proportion with the task at hand. I’d like to call these kind of design generally specific – a single tool that does so many different things it is hard to use for just one of them.
I’ve been thinking about this a lot in the context of a new app (as yet unnamed) that I’m working on – a photo presentation tool for presenting travel photos, in person, to someone else – a simple concept, with a lot of interesting space to explore. Once again it’s an app for me – I take a lot of travel photos and like talking about them and showing them to others.
It would very be easy for this design to submit to feature creep – there is so much that could be added to the app as it stands now – a few immediately pop to mind: photo editing, photo export, flickr/picasa integration. But each time I think of a feature I ask myself – does this feature add complexity that is out of proportion with its benefits?
What I’m hoping is that I can keep making apps that are specifically general rather than generally specific. I think people can handle it.
After just one day in the App Store, Time Flies has been featured on both Gizmodo and Swiss Miss. I’ve also been getting a steady stream of emails and tweets this morning full of positive feedback and ideas for new features (the number one request being to release an iOS 3.1.3 version, which I’ll be getting on to as soon as I get my hands on an old iPod touch for testing).
I honestly didn’t expect to be getting all this attention!
What I’m happiest about is the fact that a lot of people have been telling me how useful the app is – when I gave up my commercial flash development job to start making software on my own, my main reasoning was that I really wanted to start making things that were useful to someone else.
A tried and true product development practice is dogfooding (as in “eat your own dogfood”) – make something you want to use, because then you’ll be passionate about it and really care about the result. I started this app as part of my “App a Week” project (it took much longer than a week in the end), and at the request of K (whom I have to credit with the initial idea). I went ahead and built an app that we would find useful in our own lives, and that fit with our tastes – simple, minimal, friendly, fast. And I’ve also often thought that if you think something is a good idea, chances are that at least one other person out there feels the same way – I guess I was right in this case.
So keep the feedback coming – I couldn’t be more pleased.
After reading all the horror stories about Apple’s App Store review process I was all set for a few rounds of rejections, some frustrating back and forth, and a long, long wait. Maybe I’m just lucky, but after 8 days in the queue and 6 hours “in review”, my first iPhone app, Time Flies, is now for sale on the App Store !
I also completed my last stray piece of ActionScript programming a few weeks ago – I guess that means my transformation from a Flash Developer to an iOS app designer and developer is pretty much complete. Not too bad for just under 3 months work (if I do say so myself).
A process I went through a lot in my years as a flash developer went approximately as follows:
The client/agency would supply a finished design of a flash site (with complex interactions specified)
I’d question the interaction ideas, but my questions would be dismissed and I’d have to build the entire site to a full working version
The client/agency would see the finished version, but be unhappy with the interactions (which they had designed)
50+ rounds of changes that involved me rebuilding and refactoring huge chunks of code until the client was satisfied
What caused this problem in most cases was the lack of allowance early on in a project for prototype time.
I love prototyping – it’s great to be able to get a working model of an idea up and running and iron out (or dismiss totally) any issues that arise well before you get in to production.
So… right now I’m working on a few different iPad concepts that involve the same general principles:
Adding items to a scrollable list from the a library of items
rearranging said items
dragging an item onto another area of the interface to update its properties
While I’ve espoused the advantages of paper prototypes in the past – I’m finding it difficult to model complex interactions like multi-touch and drag+drop using lo-fi models. With complex interactions speed, responsiveness, and device limitations are extremely important things to test.
To get around this issue I’m trying a new prototype workflow: as I come up with an interaction that doesn’t suit a paper prototype, I’m building a small, standalone prototype that I can use to test the idea accurately without investing too much time building fully-functional parts of the interface:
The additional advantage of working this way is that while I’m in the design phase of these projects I’m still keeping up my coding practice (I’ve still got a lot to learn with Objective-C) – each little prototype is a discreet programming challenge that I can commit to without worrying or getting overwhelmed. Each prototype I make is also helping me build up a library of interaction code that I can use in the future if I decide that the idea doesn’t suit this particular project.
Five days ago I was feeling overwhelmingly positive about App a Week. Now, not so much. I’ve almost completed this week’s app (a time & event history tracker called “Time Flies”), but I’ve decided not to post a demo this week – in fact, I’m not going to try and complete the app in it’s current form.
What’s the problem?
The problem is that I am finding myself getting in to a rhythm of rushing, taking shortcuts, and discounting good ideas just to meet my arbitrary deadline. All these things are things which I disliked about my previous work as a flash developer in a commercial environment.
One of my major goals when I decided to quit my job and learn iPhone development full time was to go back to practicing a measured, thoughtful, iterative design process. A deadline of 1 week, while highly motivating, simply isn’t enough time to do things properly. Sometimes it can be prudent to take shortcuts in order to release on a deadline, but this stage of my development is not the time.
I’m counting my 4 apps in 4 weeks as a relatively successful experiment. I’ve been forced to do a lot of coding very quickly (which has improved my Objective-C skills dramatically), and coding to produce stable builds at every iteration (a really useful skill). I’ve been forced to practice rapid idea generation and rapid prototyping techniques. But I haven’t produced any great apps, because trying to produce a great app in 4 weeks is kind of ridiculous.
So I’m going to call it off.
One of the positive outcomes of the last 4 weeks has been that I’ve seeded some ideas that I think I will be able to develop in to viable, saleable apps. But they are not apps that take less than a week to design and build.
So I’m going to take it more slowly for the moment. App a Week was worthwhile, it got me started, it was fun, but now it’s time to do things properly.
So I had plans for an extensive post about how I’ve made three apps in three weeks (half way to my six week goal) and all of my learnings and thoughts so far; discussing design process, coding practice, the unique interaction approach needed for the iPhone and iPad, etc. But something must be working with my App a Week project, because I don’t feel like writing that post. I feel like designing and building new apps.
So instead of long ruminations, here is a neat little list of some of my thoughts so far:
A week isn’t a realistic amount of time to build a polished app, but it is plenty of time to design, prototype and test a concept
I’m learning as much about what I don’t want to be doing with my app development process as what I do want to do – these short deadlines are forcing me to take shortcuts that I definitely won’t be taking once the project is over
I’ve learned an enormous amount
I’ve got an even more enormous amount to learn
None of my apps so far are the “best” ideas, but I am learning how to quickly iterate and generate ideas (and I’m getting faster at it)
I’m having a lot of fun
That’s it for now. I’ve got an app to make, and only 4.5 days left to make it.
I had a few constraints to consider – the history needed to be in a list format (for consistency with the main app screen, and for the functionality I wanted to leverage from within the 
My first functional iteration was really just a tech demo – it shows the start and end dates and a time period so that I could be sure that the data was tracking properly and the database upgrade ran smoothly. The long dates are conceptually too far removed from reality to be a useful reference (unless you are really good at calendars), and the time periods sitting above are meaningless out of context (15 days since what? Or to? From? Between?)
The solution seems very simple now but took a lot of getting to – I removed the the lines between entries to connect them conceptually as a single stream; added of a small red arrow to indicate time direction and to link each period with the next event – now you can see when an even started (the date), and how long it was between updates (period description+arrow); the large space for the event description at the top places emphasis on the most recent update (a stated goal in the original design) and demarcates all below it as historical.
Five days ago I was feeling overwhelmingly positive about App a Week. Now, not so much. I’ve almost completed this week’s app (a time & event history tracker called “Time Flies”), but I’ve decided not to post a demo this week – in fact, I’m not going to try and complete the app in it’s current form.
What’s the problem?
The problem is that I am finding myself getting in to a rhythm of rushing, taking shortcuts, and discounting good ideas just to meet my arbitrary deadline. All these things are things which I disliked about my previous work as a flash developer in a commercial environment.
One of my major goals when I decided to quit my job and learn iPhone development full time was to go back to practicing a measured, thoughtful, iterative design process. A deadline of 1 week, while highly motivating, simply isn’t enough time to do things properly. Sometimes it can be prudent to take shortcuts in order to release on a deadline, but this stage of my development is not the time.
I’m counting my 4 apps in 4 weeks as a relatively successful experiment. I’ve been forced to do a lot of coding very quickly (which has improved my Objective-C skills dramatically), and coding to produce stable builds at every iteration (a really useful skill). I’ve been forced to practice rapid idea generation and rapid prototyping techniques. But I haven’t produced any great apps, because trying to produce a great app in 4 weeks is 
So I’m going to take it more slowly for the moment. App a Week was worthwhile, it got me started, it was fun, but now it’s time to do things properly.
