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

App a Week #2 – Historical Narratives

I remember a conversation with Chris shortly before I got interested in iPhone development where he was talking about the idea of the “layers” of geoplaced information that are available floating around us. Whenever a person with an enabled device sends a tweet, or updates their Facebook page, or uploads a photo to Flickr, attached to the data is a location coordinate – the data belongs to the user, but also to the place. Matthew Kwan at RMIT is even working on a geo-location standard for SMS.

Chris’ idea was that one day soon it will be possible to stand in a particular location and using your mobile device, track the data history of a place – an augmented reality layer that we have (perhaps accidentally) added to the world.

Information is being attached to places, and that information combined with place is a public historical narrative that we are adding to all the time.

So for this week’s App a Week project I’m interested in building a simple iPad app that explores the idea of historical narratives, using Flickr’s geo-search API.

Visually I’m using two primary sources of inspiration.The first is Eric Fischer’s “Locals and Tourists” analysis of flickr users based on an interesting concept – he analysed geo location data for photos in a series of cities and using a time-based algorithm divided them in to “tourists” and “locals” – with fascinating results:

Locals and Tourists #5 (GTWA #20): Tokyo

The other is Isao Hashimoto’s artwork “1945-1988”, an animation tracking the history of nuclear explosions around the world – a really effective way to present some rather shocking historical data:

My app idea is still a little vague at the moment, but it will become much more concrete soon – I need to start programming if I’m going get something finished by Friday…

App a Week #1 – Some thoughts on process

I finished my first app for App a Week this week. Here are a few reflections…

Code first design later

I really have two competing aims with my App a Week challenge. One is to force myself quickly iterate and develop new apps and hence practice idea generation, rapid prototyping, and app design skills. The other is to learn how to develop apps using objective-c and Xcode. These competing goals, combined with time constraints, posed a bit of a problem.

I didn’t have time for a “good” iterative design process:

Instead, I found myself operating using what is usually considered a “bad” process:

Why is this bad? Because it’s inefficient. It is much better to test the designs and iterate through problems with design and usability well before you start coding, because implementation is complicated, and changing a paper design is far easier than changing a functional piece of code. I would have loved to test everything using lo-fi paper prototypes, briefs, photoshop files… but I had to code the thing, and I had to make sure I could code the thing.

I don’t yet know exactly what I’m capable of building.

So I programmed and designed in parallel. In fact my paper “designs” never got past this sketch level of fidelity. I found myself sketching up a a few screens, building partial, or even full functionality straight in Xcode, and testing it as a functional app.

The advantage of this was that I got a lot of coding practice in. When I ran in to design issues I had to solve them programatically (I originally used a modal view for creating new categories, but after testing realised that this interrupted the workflow too much and changed the design to use a navigation controller push) and had to refactor the code immediately – and learned a lot more in the process.

There was pushback too: when I realised I didn’t have time to make a custom keyboard for price input, I had to change the design to split the price input fields in to dollars and cents – not ideal, but not a bad functional trade-off.

I think App a Week will be a constant struggle between these two competing goals – it will be interesting to see where this takes me.

The power of structures

One design decision I made out of expediency was a simplified workflow – originally I had wanted to be able to add transactions from the home screen (the app as it stands makes you choose a category first). This would have been more complex programatically – with all transactions going in to a default “uncategorised” set, and the ability to reassign categories – and when designing the object model I ditched the idea.

This actually improved the app. Because there is no identifying data with any transaction except the date (in order to make transactions simple), assigning categories after the fact would rely on the user’s memory – I spent this much, but on what? – something I wanted to avoid. It also reduced the number of screens required (there is no “transaction category assignment” screen). And because there is only one way to create transactions, you only have to learn one behaviour.

In fact, because the app forces you to select your category first, it suggests that you must add all the relevant information to the app in a single exchange or risk losing the information – increasing awareness of the transaction. This structural limitation which I decided on for the sake of expediency just happened to align with my goal for the app: to force me to pay more attention to my spending.

This is certainly something that I want to delve in to further – how does the flow of the application affect how the user thinks about the task he/she is performing? When designing an application, how do you want the user to think about their actions?

Can an app be designed so that the structure of it helps to change a user’s behaviour, rather than just helping them complete a task?

App a Week #1 : Expenses – really simple expense tracking

So, the first week is almost over, and I’ve completed my first app:

(Sorry for the shaky camera work).

Ever since I stopped doing commercial work, I’ve had to keep a bit more of an eye on my finances – I’ve been tracking my expenses using a Google docs spreadsheet. This is fine for most cases, but all too often I would come home and have forgotten how much I spent, or I’d remember, get distracted, and forget to enter it into the spreadsheet. This app was designed a solution to that problem – I carry my phone all the time.

This ties in well with an approach towards app design that I’ve thought about quite a lot:
Take something useful, and make it portable.

Another important approach is simplicity. For my needs, an expense tracking app doesn’t have to be accurate and detailed (for example, in my app a transaction has only a category and date, no description) – it just has to make me pay some attention to what I’m spending.

So my goals for this app were a few simple ones:

  • Quick and easy to enter new transactions
  • Track expenditure against a category and a date
  • Calculate running totals and averages (daily, weekly, monthly)
  • Compare percentages for categories

No CSV exports or bank account tie-ins, no budget planning, no calendar functionality or repeating expenses. No to-do lists, no shopping lists. No income vs expenditure. Just expense tracking. I’ve been using the app in developing forms for a few days and it’s doing everything I wanted so far.

The app is certainly not ready for release yet (lacking among other things, an application icon, as well as some serious beta testing), but I’m happy that I’ve met the challenge that I set myself. I’ve learned an enormous amount trying to design and build a whole app from scratch in under a week – especially seeing as I’ve never really built a working iPhone app before.

App a Week has thrown up some interesting design and development challenges – because App a Week is so closely tied in with me learning how to program in objective-c, I took some steps in the that were (in the end) inefficient and cumbersome, but were necessary to meet my learning goals. I’ll be outlining the design process and some of my learnings in a later, more detailed post.

Fail early, fail often. Really often.

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:

  1. Apps must be complete by Sunday. Preferably Saturday
  2. Complete means it is a working piece of software that will run on my iPhone or iPad. It does not mean feature complete
  3. Apps must be significantly different from each-other, but can build on ideas from previous apps
  4. It is preferable for each app to include some functionality that I’ve learned only recently
  5. 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)
  6. 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
  7. 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.

All in the past

As I’m not planning to do any more Flash development (possibly ever), I decided to put together a quick showreel of some of the commercial work that I’ve done at various agencies over the last few years.

I find it’s very easy to forget about old projects once you’ve moved on – in the process of compiling this footage I uncovered a few things that I’d already forgotten about. But I think it’s worth keeping a record, because it’s sometimes good to look back and see your progression.

If it’s not easy…

I’m working on an early prototype of an app with Chris, and the first stage is testing out the location finding properties of the iPhone and learning to use CLLocationManager and MapKit.

The UI is pretty simple – a bunch of saved locations in a list view or map view (switched via a tab bar), a modal view to save a new location, and a detail view that shows a single saved location (accessed via a navigation stack from either the map or list view). So – a TabBarController, two NavigationController stacks, a TableView – easy right?

In my first design I thought that each navigation stack would needed a parent controller to “own” it – leading to a pretty complex structure, which (somehow) made sense in my head… here is a simplified diagram.

Well, you get the idea. It did work – mostly – all the functionality was there, the tabs would switch views, the CLLocationManager was finding the user location correctly, the annotations were being updated in the map view when I added an item in the list view, you could drill down to the right places in the application.

But my viewWillLoad/viewWillAppear methods on my navigation controllers weren’t firing… I had to call them manually for some reason. The list wouldn’t resize properly… it got stuck scrolling behind the tab bar. My detail view had to be manually positioned to take the tab bar height in to account. To update the model I was passing messages (via delegates) through what seemed like way too many middle-men. Something about it just felt clunky.

So I pulled the whole thing apart, and thought about it again, knowing that it should be easier than this. I re-architected in an attempt to a) use as much framework functionality as possible and b) simplify the messaging so I wasn’t using so many “middle man” controller classes. Instead of parent “container” controllers, I just let the UINavigationControllers act as the containers (which is what they are anyway), and added them to the TabBarController. I moved the table and map views from their child view controllers so that they mapped directly on to the main list and map view controllers: one view –> one controller. Here is the new structure:

My instance messaging overhead dropped considerably, I had fewer delegates to manage, and it was suddenly a lot easier to get a handle on what was going on. I ran the app and all the scrolling and viewWillAppear issues had completely disappeared.

That’s when I remembered one of the best pieces of design advice from Apple:

“Don’t fight the framework.”

UIKit is designed to make implementing the navigation structure and basic UI behaviour as simple as possible so that you can focus on the core functionality of your app.

The reason my list view wasn’t resizing correctly was because I was attempting to re-implement functionality  that already existed in UINavigationController. The reason viewWillAppear wasn’t firing was because I’d overridden the navigationController in my UIViewController subclass and it couldn’t send the message properly.

It was a round-about way of doing things (I could have just used an example template after all), and it took me a long time, but I’m considering this an important lesson learned. Next time I try to do something that I’ve seen before (especially in Apple’s own apps) and I’m finding it strangely difficult, then I’ll just check the design again… because I’m probably doing it wrong.


I’ve been re-arranging my workspace again (well, the workspace I share with K) – I’ve been thinking for a while about trying out a standing desk for all sorts of reasons, but mostly as an experiment. As you can see, my lo-fi solution was to put an coffee table on top of our  desk, along with a few stacks of books for my laptop and monitor. It’s working well so far – I seem to be getting less distracted and I’m less likely to procrastinate. I don’t hunch or slouch like I used to, and there is room under the desk for my printer and scanner, and under the coffee table for books and stationery.

As I’m in a process of redefinition I’ve been thinking a lot about space and how it affects my modes of thinking – what I’ve found is I can be productive, but not creative at my standing desk – my desk space works for programming, app testing, photo editing, and certain types of writing – all systematic modes of thinking. But when I try to be creative at my desk I feel under pressure to produce.

For creative modes it’s different –  I can be more creative at the dining table or on the couch (so relaxed spaces are important). I’ve also found that I’m more creative in active and anonymous spaces – walking on the street (I have most of my app ideas while walking), in a library (seems to be good for design work), in a cafe etc. Creativity needs a certain amount of procrastination, a fair amount of distraction, and a lot of mind wandering – and I agree with John Cleese who says that for the mind “to come out of it’s shell”, it needs “boundaries of space, and boundaries of time”.

When I’m free to not think about a problem, my unconscious seems to utilise that opportunity to
solve it.

So what about when I need to solve a creative development problem? A standing desk is great because it makes it really easy to step away from production – I don’t feel attached to the desk the way I did in a chair – one step back, and I can look out the window at our constantly changing prunus swaying in the wind, 2 steps back and I’m on the couch, or 10 more steps and I’m out the door, and my unconscious can get to work.

Staring at a blank screen with growing impatience

I’ve only been studying Objective-C seriously for three weeks now, and I’m already  frustrated. To go from being totally competent and confident in one field (ActionScript) to being confused and clumsy in a very closely related one isn’t why I decided to go down this path.

I am trying to study as thoroughly and carefully as possible – I don’t feel like it’s good enough to stumble through some sample code, twist it in to my own design and upload it to the app store. (It’s amazing how many apps I see where the only reviews are “It crashes all the time” or “Doesn’t work as advertised” – I’m determined that won’t be me). And I learn better when I work from first principles (coding my TableViewControllers from scratch, for example), and through repetition (coding in a blank document every time instead of copying and pasting from previous projects).

For me to be satisfied programming I need to know what I’m doing. (I was always amazed by how few Flash developers I met were curious about the available frameworks or who would even bother reading Adobe’s documentation). I want to be proud of what I make. So I’ve put myself in the unfortunate position where I won’t be happy until I’m at least as confident in Objective-C as I am in ActionScript.

In Outliers, Malcolm Gladwell talks about a kind of magic number – around ten thousand hours – of practice that seems to be required to really excel at a particular skill – and seven years is about how long it took me to clock up that many hours of Flash.

I actually feel like I’m progressing at a reasonable pace – I’ve already producing totally functional (if flawed) apps as learning exercises, and the way that XCode and Apple’s frameworks allow you to get up and running quickly really is a thing of beauty. If I can remember to remind myself that ActionScript and Objective-C are both classes of the same activity – “Programming”, then I don’t get so dejected about the Ten-Thousand-Hours thing. And I’m still sure that I’ve made the right decision.

I just think that maybe I fooled myself in to thinking that it wouldn’t be hard.