I’m Reuben Stanton. This is an intermittent blog of relatively random things: thoughts about technology, reflections on my life and work, and some historical stuff.

My ‘real’ website is here, and I tweet intermittently @absent

Monthly Archives: February 2014


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.

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

Sent from my iPad #2

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…

The benefits of being your own client #1

I spent some time today watching a video from the latest WWDC on using the Model View Controller design pattern in iPhone development – a software design pattern that I have been trying to correctly implement in flash for years now.

I tried, I really did. I would start with a grand class diagram and a beautifully loosely-coupled group of classes… and then I’d end up with application logic in a view, or a bloated controller class, views directly referencing a model, multiple lines of switch and ifs in places that they shouldn’t be, or (worst of all) exceptions thrown in to the empty-catch-black-hole. My beautiful, reusable classes would end up being site-specific monsters that would need be re-written again and again for each project.

While some of this can be attributed to me and my lack of knowledge, an awful lot of this poor design was from expediency  – when developing for the web with a multitude of clients and rapid turnarounds, often the “just make it work” solution was the only solution (or at least, the only solution without pissing off the account manager and giving the studio manager yet another 50 grey hairs). Projects always had a “few” (read 25 to 50) design and or functionality changes that would require either a) a total re-design of a large number of the model, view and controller classes, or b) a whole bunch of hacks to get the project out the door as rapidly as possible. Needless to say, the manager(s) always wanted option b.

Now that I’m working for myself, I’m finding a certain joy in sitting with a  pen and paper and designing. Design is what it looks like. Design is how it works. Design is how it will be built. Slowly. Thoughtfully. Carefully.

Sent from my iPad

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…

Baby Steps

I finished up for good as a Flash developer last week. A few years ago I really thought that Flash would become a viable application development platform and In some ways I’m truly sorry it didn’t work out. Oh well… as they say…. Upwards! Forwards! Towards the Sun!

“Don’t plan the plan if you can’t follow through” – Dr. Horrible

And just how do I think I’m going to change from being a Flash developer to an app developer and interaction designer? I’ve set myself a few modest goals:

Within 3 months I want to be confident writing Objective-C – I want to understand the language and the foundation framework the way that I understand ActionScript-3 now. From the small amount of Obj-C I’ve done so far I think this is achievable.

Within 6 months I want to feel comfortable with the iPhone and iPad development frameworks – by this time I want to feel confident designing an app and building it from scratch. I also want to use this time to explore (and re-learn) various design and development methodologies and practices – exploring idea generation methods, rapid prototyping, the user-centered design process (among others).

I’ve lined up a few projects to work on to get me started – I want to make sure I stay working in the “real world” as much as possible – making apps that people are actually going to use: I’m working on an iPhone app (in collaboration with Chris Marmo) to do with data mapping and tracking, and an iPad app (with Jeremy Yuille) exploring ideas around visual representation and organisation of knowledge (more on both of these later).