Monthly Archives: February 2014

Specifically general

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.

Things for others

A little aside from programming now. Last year for new years eve Kate and I had a party at our apartment, and for our invitation we made a short stop motion animation using a chalkboard. It was pretty low quality, but good fun to make, and our first creative project together. The video was a bit of a hit (amongst our friends anyway), and recently we were invited by some very good friends of ours to produce another stop motion video, this time as an invitation to their wedding reception.

What was interesting was that they gave us total creative control. “We trust you – just make something great” was the sum total of the instructions, along with a suggestion of a musical track. We decided as this was a wedding it needed something a bit more high quality and involved than our animated chalkboard – we decided on making the invite using cut out letters and scenes from around their house in a way that would capture the essence (for people that know them) of their lives together.

We spent one afternoon in their house planning the animation, and then last Saturday we took over their house for the day, shot the whole thing in about 6 hours, and then spent most of Sunday editing.

It was all shot on a Lumix GF1 (my favourite digital camera), with the standard 20mm lens and a Pentax 50mm lens with a Voigtlander adapter for very low depth-of-field effects. Instead of a standard stop-motion process of shooting still frames, we shot it all on video for speed (just stepping in and out of frame to move the objects), and then used AfterEffects to time-shift the frames to turn it in to stop-motion. The process had a few similarities with a photography project that I worked on in Tokyo a few years ago with Manabu Iguchi in that all the lighting and effects were done in-camera.

The total control thing, while great (and unusual) from a creative perspective, made things a bit difficult. We were constantly asking ourselves “what if they don’t like it? What happens if they don’t like it but don’t feel like they can tell us?”

Lucky for us, they did like it. Loved it in fact. I’ve realised that something even more satisfying than producing things you have designed for yourself is producing something especially designed for someone else. You can watch the animation here (sorry iPad users, only a flash version for the moment).

That sure was fast…

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.

Well, that sure went smoothly…

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).

Waiting for review

I mean, they have to get to it eventually, right? At least I know how long it’s been…

Prototype time

A process I went through a lot in my years as a flash developer went approximately as follows:

1. The client/agency would supply a finished design of a flash site (with complex interactions specified)
2. 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
3. The client/agency would see the finished version, but be unhappy with the interactions (which they had designed)
4. 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.