As K and I are preparing for a long holiday in Spain, we decided to watch a slideshow of K’s parents on a road trip around Europe in the late 1970s. It was the real deal: magazines of slides, stored in metal and plastic boxes, labelled in pencil, the whirrr of the fan, the heat from the globe, the k-clunk-click of the slide advance. Not to mention some awesome 70′s fashion.
Watching slides in a projector is a considerably different experience to browsing digital photos. Sometimes I look through my Lightroom catalogue at the thousands of photos that I have taken during overseas travel over the past few years, but looking at a photo on my computer screen never evokes the feeling of a slide projected in a dark room from a tungsten globe.
It’s not that I don’t feel nostalgic looking at my photos – of course I do. Looking at the images can’t help but force me to remember details of the travel experience – but there is something in the physicality of a slide that makes it different.
Each slide is a unique object that can be held up to the light – a miniature window to another time and place. Each little window is “real”. Each little window says: “this is proof”.
Slides degrade over time, and the damage and disintegration is a clue to it’s age – older slides feel old because they are old. Even the technological limitations of photo processing in each era – the colour balance, the roughness of the edges, the sharpness of the image – mark each photo as from that particular time.
The audible click and visual shift from one slide to the next marks a space in time – like the gutter in a comic, this gap between images says: “then this happened”.
Digital photos have none of these qualities – they are clear, sharp, clean, ageless. You can’t hold them up, hand them around, flip them over to look for a note on the back… let alone store them in a box to be found accidentally years later by curious grandchildren.
I think this partly explains the recent popularity of “vintage” photo apps – by digitally adding the trappings of analogue technology – borders, scratches, vignettes, light leaks, scratch marks – you also add a level of (albeit contrived) “reality” to digital photos that isn’t inherent to the medium.
Watching a slideshow is not a simple as just flicking through a series of photos – it is a shared experience, full of stories, questions, sometimes arguments over a shared history. This storytelling is part of what makes the slideshow special. It is not a passive activity of watching and remembering – it is an active experience of re-remembering (or sometimes mis-remembering) and retelling.
This really struck me about the way that we look through old slides: the element of surprise. Even if we travelled to those places, lined up the viewfinder, took those photos – our memory is malleable and unreliable and forgetful enough that it isn’t until we see the slide projected on the wall that we recall the details. This is not inherent to slides of course – it applies equally to photo albums, diaries, journals, even digital archives. But there is something about the discreet nature of a group of slides arranged in a magazine that adds a level of excitement to the experience: you’re never 100% sure what comes next.
Slides are old technology now – like black and white photography before it, the slide’s time has past. There will always be enthusiasts, but photographing on transparency is becoming less and less economically viable (not to say impractical).
This isn’t something I really worry about – technology moves on, and I certainly wouldn’t want give up the convenience of digital photography. But perhaps there are things that we can learn from the emotional experience of the slideshow in the design of image storage and presentation technology.
My frequent collaborator Jeremy Yuille is off at Interaction 11 in Boulder this week, where he’ll be running an activity focused on interaction design fundamentals. Over the last few months, Jeremy and I have been working on a new iPad app… which I’m not going to write about here (at least, just yet).
I do want to note down something about our process that struck me as interesting though – there was very little “visual” design involved at all.
We did almost nothing in the way of sketches and wireframes, and the only visual work I did in photoshop was a few png files for shapes that were a little harder to draw in code. There was very little documentation other than some notes taken down after meetings or recorded sketches (which, incidentally, I never referred to).
Instead, we worked almost entirely with interactions and prototypes: Jeremy would establish a scenario or use case, and we’d develop a prototype – through discussion, a “test” (usually no more than pointing at pieces of paper or a post-it on a wall) – then I’d code a quick demo to check the interaction and performance on the iPad.
Each step of the design process had two basic questions:
1) What is the desired outcome (for the user)?
2) What is an interaction that will achieve that outcome with a minimum of friction?
This approach seemed to free us from traditional design patterns and solutions (though we did use traditional patterns where appropriate to the outcome) – by sticking to the pattern of “interaction supports outcome” you stay focused on the user experience in a way that other design approaches don’t always afford.
In fact, when we didn’t ask these questions we tended to get stuck. When we asked ourselves “how will we implement groups?” (a question about a specific information structure) we spent a long time trying to solve complex implementation details. When we instead reconfigured the question: “what is the outcome we want when we use the word ‘group’?”, we discovered that “groups” weren’t actually what we needed at all – we needed a different interaction altogether.
It was very important that this was done collaboratively. We would do thinking and coding separately, but all the “design” happened through discussion – this way questions could be asked, interpreted, and designs modified on the fly. The design happened through constant rethinking and questioning.
The process was iterative – each demo that I coded was tested against the outcomes and modified – so our finished alpha is essentially just a sum of the interactions that we kept from each demo.
The interactions are the interface
So what does all this mean in terms of a design outcome? It means that the visual design of the app is nothing more than a set of interactions that facilitate specific actions. Any visual “flair” either arose from an informational requirement (user feedback – a highlighted state), or a hierarchical need (size, position, object delineation).
Now, the app that we’re working on is unusually suited to an “invisible design” – it is a visual thinking and presentation app designed to work with a variety of user generated content, and designed to keep out of the way of the content wherever possible (much, much more on this when it is ready for the public). But I do think this process could easily be applied to all sorts of product development, and it is one that I’ll be using regularly in the future.
The format of this blog has been holding me back a little – something about it makes me feel like I need to write long, involved posts for them to be worth putting up – so I’m trying something new – notes: shorter thoughts that I think should be recorded here, but don’t warrant full post just yet, formatted just like this…
As part of my preparation for my PhD I’ll be spending a fair amount of time over the next few months thinking about and observing how people create, record, interact with, various types of archives and histories.
An almost ubiquitous sight in Australian family homes (and possibly around the world?): The Height Chart. Usually on a door frame, usually in or near the kitchen (which is an interesting space in its own right for the interactions that it encourages).
A record of the family’s physical development – sometimes including guests, friends, even pets – the height chart feels temporary – written in pencil (because pencil sticks to paint? Or because it can be removed easily?) , each entry is temporary – soon to be superseded, out of date as soon as it is made.
It seems as much about the act of creation and comparison as it is about keeping a record: who even looks at the chart when they are not adding a new entry?
What makes the height chart interesting is that it is one of the few places where you can see a singular record of someone’s development (albeit on a very specific metric) – from childhood all the way through to adulthood. I can’t think of another. (Maybe photo album collections come close).
It is a specific and personal kind of history, attached to the frame of the building itself. You don’t take the chart with you when you move, in all likelihood it will be painted over, ready for the next family to record their progress.
This post is an experiment in using the WordPress iPhone app, hence the brevity – the app seems ok so far… though I haven’t figured out an easy way to add links yet…
I’ve just about to leave Melbourne for a few months, first to Perth for 3 weeks, followed by 2 months traveling around Spain. I’ll be posting here sporadically when I can get wifi.
Over the last few weeks I’ve been really busy with PhD preparations, some really interesting new iPad work, a few prototypes… hence the lack of updates – I hope to write up some of this in Perth this week.
So I won’t be doing any programming while traveling, but I do hope to do a lot of initial design work and thinking for the PhD and a few other things… I’ll do my best to write about them here when I can.
When I am reading online and find a great article that I don’t have time or inclination to read immediately, I use Instapaper. It’s great – I just hit my “read later” bookmarklet, and then I can easily find the article, or (more often than not) download it in text format to the Instapaper iPhone or iPad app and read offline – on public transport, in a cafe, on the couch. Instapaper is a great idea, and has been very successful for its developer Marco Ament.
For a while now, I’ve also kept a folder on my bookmarks bar in Safari that I use to save videos (YouTube, Vimeo etc) that I want to watch, but not right away. The folder’s name is “Watch Later” – kind of my own lo-fi version of Instapaper for videos. When I find a video I want to watch later I drag the link into the folder. When I finally get around to watching the video (or decide that I don’t really want to watch it after all) I remove it from the list.
So anyway, today I was reading a blog, the blog post contained a YouTube video, and I was just about to copy the link to save to my folder when I noticed a new little button in the top right corner of the player. Watch later it said. My brain did a little jump – OMG Google just read my mind.
Now, I know that YouTube has been playing around with playlists for a while now. (Hitting the “Watch later” button actually adds the video to an automatic playlist which you can access when you are logged in to YouTube). Because of the same use of language (“Watch later”), and because I’d been having that exact thought at the time that I saw the button, I didn’t care about the mechanics of the action – there was no “what does this button do?” moment. I just wanted to watch the video later. I pressed the button.
This is one of those instances where language is extremely important in interaction design. The button could have said “add to my playlist”. It could have been some obscure icon. I would have ignored both. So much of my positive reaction and hence my willingness to try a new feature was tied to the fact that the software was speaking my language.
Things sure change fast around here. (No, not another Time Flies post, although time is a bit of a theme). I’m taking another unexpected turn – not directly away from iPhone development, but something new, in tandem: I just enrolled in a full time PhD at RMIT University.
I’ve been doing quite a bit of work in and around RMIT for the last few years, and when the potential PhD candidate for the Circus Oz Living Archive project fell through, I was there to catch it. This is something very new and very different for me – I’m used to being employed to perform a particular technical task or to solve a specified design problem, but as a PhD candidate I’ll have to define a research topic and act on it. I’ve never even worked in a single job or on a single project for three years, let alone defined my own boundaries and focussed intently on a single research question.
What I’ve found from talking to academics that I’ve been working with lately is that a lot of what I am currently trying to do in my design practice is, in fact, a process of design as a way of inquiring and producing knowledge – design as research. What I don’t have is the theoretical background and frameworks to back up and support and know about what it is that I am practicing. Yet.
So this blog will be changing again too, (the third shift in its short life) to document my PhD progress along with my iOS development work.
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.
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).
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.
Digital photos have none of these qualities – they are clear, sharp, clean, ageless. You can’t hold them up, hand them around, flip them over to look for a note on the back… let alone store them in a box to be found accidentally years later by curious grandchildren.
When I am reading online and find a great article that I don’t have time or inclination to read immediately, I use 
For a while now, I’ve also kept a folder on my bookmarks bar in Safari that I use to save videos (YouTube, Vimeo etc) that I want to watch, but not right away. The folder’s name is “Watch Later” – kind of my own lo-fi version of Instapaper for videos. When I find a video I want to watch later I drag the link into the folder. When I finally get around to watching the video (or decide that I don’t really want to watch it after all) I remove it from the list.
So anyway, today I was reading a blog, the blog post contained a YouTube video, and I was just about to copy the link to save to my folder when I noticed a new little button in the top right corner of the player. Watch later it said. My brain did a little jump – OMG Google just read my mind.
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.
