I'm Reuben Stanton: PhD student, interaction designer, occasional app developer, amateur cook.
August 28th, 2010

Lo-fi

I spent some time today developing a rapid prototype of an app idea using Briefs, a brilliant open source framework by Rob Rhyne. I’ve only been using it for 6 hours, but I can already see it becoming an essential part of my design process.

I’ve been drawing flow diagrams, rough screens, building paper prototypes (using my iPhone “template”, pictured above), but the benefits of being able to quickly test functionality directly on the device are huge – there is nothing like being able to interact with your sketches to get a sense of how the app will feel.

Briefs is a very clever idea – you write instructions in a simple CSS-like syntax (it actually reminded me a bit of my early days of timeline-based flash scripting), compile the actions and images using a command line tool and load them on to your device through XCode – what you get is a functional imitation of an app.

Because it’s basically just a list of images, links, and transitions you can use anything from rough sketches to fully fledged designs, all without having to invest the time coding – great for trying out screen flows and sequences without any risk.

In building my prototype today I’ve already identified a few flow issues that I missed on paper and that would have been much more difficult to change after implementation.

What I love about briefs as compared to other similar concepts is the fact that I can test out ideas in extreme low fidelity – when I’m playing around at this stage of a project I don’t want to get bogged down in small implementation details or finicky design changes (that all comes later). I just want to know if I’m on the right track. For this purpose I actually find very rough wireframes more useful than hi-fidelity ones – it helps keep focus on the action (and interaction) instead of the superficial aspects of the application, and for working at that level of detail Briefs is perfect.

Posted in design, iphone, redefinition with no comments »
August 24th, 2010

Memory management

“Oh no,” you say “not another post about memory-management from a new iPhone developer… retain counts, autorelease pool, alloc, copy , blahdy blah blah… we get it already, memory management in Objective-C is hard.”

Actually, no. This is about something else – I’ve noticed that most of the apps that I use on a regular basis are about memory management in a literal and concrete sense – I’ve come to rely on my iPhone to remember things for me.

I write lists (in a list app), I take notes (in a notes app – that syncs with my mac so I don’t have to remember to copy the notes across), I have train, tram, bus timetables, my calendar (with reminders), alarms, email alerts… and I have quick access to wikipedia and the rest of the internet (my default second brain). I don’t have to remember things because my pocket computer remembers for me.

I travel and I check my maps application over and over again, forgetting my directions and location between each access.

But I’m not complaining, nor is this another technology rant about being lost in the shallows – I’ve actually always had a terrible memory for certain types of  things – before the iPhone I would draw a map and write directions and would still have to check them over and over. I would write phone numbers on a piece of paper, and then lose the piece of paper. I would write cryptic notes on my hand and then be unable to decipher the notes.

Here’s the big deal for me — and an early stage of an idea — on the iPhone, I can potentially find (or better yet, make) an app (or collection of apps) that is particularly suited to my type of memory. A device that assists my memory management in a specific, tangible way.

(And yes, for you programmers, the photo is of a post-it on my monitor reminding me to release).

Posted in design, iphone, objective-c, reflections with no comments »