I’ve been a fan of Sennheiser headphones for a long time. My HD25s have followed me around the world, they have wonderful sound isolation and a great flat frequency response that I love, and I’m a big fan of supra-aural headphones (not for everyone, I know). I’ve just bought a pair of smaller, lighter, Sennheiser PXC-250 II for travel and work. They are lightweight, have great sound, and the noise cancelling works quite well – the sound quality isn’t perfect (with noise cancelling headphones it never is), but it’s a lot better than iPhone earbuds and they are more convenient to carry than my HD25s.
I’ve always, almost without exception, listened to music while working. For the majority of this period, “work” consisted of programming – working with other peoples designs, making them interactive, making them move, solving minor technical or technological or design or architectural (in the software sense) problems. Plus the other minutiae that goes along with any freelance or programming job – emails, code maintenance, communication, business management issues. This was “work”.
And my work could always be done while listening to something. In more recent years as my programming skills improved and my programming work became more straightforward (I’d developed patterns to solve the same problems over and over – most websites are pretty much the same after all), I began listening to podcasts – my brain was at a point where my work was done in some subconscious part, separate from words and language. I could listen to people talking and comprehend that information at the same time as “working”. Very occasionally I would run in to a problem where I had to turn off my audio for a minute or two to get through something, but that was it. I liked this about working – in later years as a bored programmer it was something to look forward to: work was my music and information time.
I’m no longer a programmer in the same sense anymore. Although programming will be part of my work for the next few years, my work is not primarily programming – my work is now “research”. And as a PhD candidate, that means reading. Reading reading reading reading. Reading and paying attention. Reading and thinking and writing about and around what I’ve read.
Problem is, I can’t read and comprehend an academic paper, or journal article, or thesis, or book – and listen to music at the same time. I can’t think through a complex conceptual problem and listen to music at the same time. I can sometimes listen to music and write, depending on what I’m writing about, and as long as the music is repetitive or very familiar, or both. I can’t do any of these things and listen to podcasts.
I remember hearing on a Radiolab episode that included an experiment where subject’s language centres were effectively “shut down” by being forced to repeat strings of random words piped to them via headphones, while they tried to complete basic tasks. Without access to language, people were unable to make the most basic conceptual links: unable to connect “direction” and “colour” in ideas such as “left of the blue wall”. This is how it feels when I listen to music and read at the same time. I can read all the words and sentences, but the ideas just don’t connect.
Now, this doesn’t really surprise me – somehow it makes sense that I can separate “programming” and “language” in my brain but not “language” and “music”. Programming always seemed a technical, craft-like, mechanical problem. Music is a steady flow of connected concepts and ideas.
My problem is really related to routine – for me, forever, I listen to music when I work. It’s part of who I am. Was. I mean was: right now, I’ve got some reading to do.
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.
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).
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.
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.
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.
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.
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 othersimilarconcepts 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.
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.
