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.
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 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.
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.
Only a prototype this time, so by my own metric I’ve “failed” this week… but I’m still pretty satisfied and I’m making serious progress.
The idea behind this app was that looking at personal data in a time and place based display adds a layer of meaning that is implicitly read when viewing the data, and that connections between data points in time and place can be made more easily when it is done visually. Or to put it more simply, looking at photos in sequence on a map is different from looking at photos in a sequence.
As I built this prototype I spend an inordinate amount of time just browsing people’s photos. There was something about following a sequence of personal events across a map that was inherently interesting in a way that the photos in isolation weren’t. Seeing the photos in particular locations over time had an added “storytelling” element which was fun to follow.
When I showed K an earlier version, her first comment was “that would be a really good way to view travel photos” – and I think that is the direction I’ll be taking the concept. How often have you been viewing someones travel photos and asked “where did you take that? And what about that one?”
My original plan was actually to build a more time-based interface – a timeline slider where you could select start and end dates, and view photos in the time-space between the two – but this was far too complicated for me to fit in to a week of development time.
I had other some issues with this one, not least of all the fact that my iPad died on Friday – so after a morning of frustration and a trip to the Apple store, I did a little more development in the simulator, and decided to call it “finished”. For now.
My other major problem was really just cockiness and over-ambitiousness – I totally underestimated how long it would take to build my first iPad app, learn to load asynchronous data, customise MKMapKit, and a million other things I didn’t think of until I was half way through.
But I’m happy with the result as a base to build on – I’m certainly getting a lot of new ideas…
Well, not quite dead – there seemed to be a little bit of backlight there, but nothing else. After some extensive googling, I tried restoring the software (both from backup and a full restore) with no luck – the iPad seemed to be “on”, (and iTunes seemed to think it was fine), but the screen was completely blank.
In a last ditch attempt I turned on the accessibility voiceover (a few people have reported an unintentional blank screen when accidentally turning on the “screen curtain” function) – and using the 4 finger triple-tap gesture I was able to get a happy female voice to tell me (with a little too much certainty for my liking) “Screen curtain on! Screen curtain off!”
But the screen stayed black…
So the iPad is now off at the Apple store for service, which has set back the development of my app for this week a bit. I’ll continue working on it using the simulator (and will upload a demo this afternoon), but it won’t be as polished as I would have liked.
UPDATE: The Apple store gave me a brand new iPad, so I’m guessing that the dead screen is actually due to a hardware fault – if this happens to you don’t hesitate to take your iPad to the Apple store.
In my years as a commercial developer I’ve discovered quite a few things about myself and the way that I work – one of these is the following: I’m good with deadlines, and I work well within limited constraints. I like getting things done, I like quick wins, and I’m happy with a little imperfection.
Now that I’m my own master again I’m constantly thinking: “how could I be using my time more effectively?”
This is meant to be a time of freedom and exploration, but some constraints can be useful. I’ve also wanted to try the idea of rapid prototyping for a long time, but I’ve never worked in an a development environment where it was encouraged or appropriate, now I decide what is appropriate.
I know that one way to make me a better application designer and developer is quite simply to do a lot of it. So I’m going to try something…
With more than a little bit of inspiration from K, I’m planning to start doing a “thing a week” with my iOS development – more specifically an “App a Week”. Starting this week. For the next 6 weeks.
Time for some rules:
Apps must be complete by Sunday. Preferably Saturday
Complete means it is a working piece of software that will run on my iPhone or iPad. It does not mean feature complete
Apps must be significantly different from each-other, but can build on ideas from previous apps
It is preferable for each app to include some functionality that I’ve learned only recently
I do not have to submit to the app store, but I may release the code open-source. (Still thinking about the implications of this one)
I will post my results/learnings/discussion of the process as I go, but each app requires at least one blog post with discussion on completion
These rules are mine, I can break any of them with justification. Breaking rule #2 requires significant justification
I think that’s enough for now… time to get to work.
This one was drawn with the free Adobe Ideas – the best drawing app I’ve used on the iPad so far, and with a surprisingly usable interface especially considering – a) the cruft floating about in the Adobe CS5 suite and b) the fact that all of the UI elements are non-standard. Maybe I’ve found a sketchbook replacement after all…
I’m typing this on my new iPad which I purchased today. I’m using the open source wordpress app (which has it’s fair share of issues), but seems ok for basic text. I had plans for a big “first impressions” post, but i think that should wait until I’ve been playing around for a while – needless to say, first impressions are pretty good. The keyboard will take some getting used to, however.
I’m not sure how useful it will be for note taking/sketching (check my scientific accuracy test below) – I’m not giving up on pen and paper just yet.
UPDATE: (Not from my iPad)
I just stopped using the iPad and went back to using my regular laptop and for a few seconds I couldn’t work out why I kept scrolling the page in the wrong direction. And then it clicked – the scrolling gesture on the iPad and the gesture on the MacBook trackpad are exactly opposite.
On the iPad you scroll by moving the content to where you want it to go, while on the MacBook (and all trackpad devices) you are moving an imaginary cursor or “scroll bar” in the direction “you” want to move – the former seems so much more natural that the iPad managed to undo years of hard-wired assumptions in just a few hours and my brain was completely confused when I went back to a “normal” computer.
The effect of the direct interaction with content is nothing short of astonishing…
