When I am reading online and find a great article that I don’t have time or inclination to read immediately, I use Instapaper. It’s great – I just hit my “read later” bookmarklet, and then I can easily find the article, or (more often than not) download it in text format to the Instapaper iPhone or iPad app and read offline – on public transport, in a cafe, on the couch. Instapaper is a great idea, and has been very successful for its developer Marco Ament.
For a while now, I’ve also kept a folder on my bookmarks bar in Safari that I use to save videos (YouTube, Vimeo etc) that I want to watch, but not right away. The folder’s name is “Watch Later” – kind of my own lo-fi version of Instapaper for videos. When I find a video I want to watch later I drag the link into the folder. When I finally get around to watching the video (or decide that I don’t really want to watch it after all) I remove it from the list.
So anyway, today I was reading a blog, the blog post contained a YouTube video, and I was just about to copy the link to save to my folder when I noticed a new little button in the top right corner of the player. Watch later it said. My brain did a little jump – OMG Google just read my mind.
Now, I know that YouTube has been playing around with playlists for a while now. (Hitting the “Watch later” button actually adds the video to an automatic playlist which you can access when you are logged in to YouTube). Because of the same use of language (“Watch later”), and because I’d been having that exact thought at the time that I saw the button, I didn’t care about the mechanics of the action – there was no “what does this button do?” moment. I just wanted to watch the video later. I pressed the button.
This is one of those instances where language is extremely important in interaction design. The button could have said “add to my playlist”. It could have been some obscure icon. I would have ignored both. So much of my positive reaction and hence my willingness to try a new feature was tied to the fact that the software was speaking my language.
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.
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.
After just one day in the App Store, Time Flies has been featured on both Gizmodo and Swiss Miss. I’ve also been getting a steady stream of emails and tweets this morning full of positive feedback and ideas for new features (the number one request being to release an iOS 3.1.3 version, which I’ll be getting on to as soon as I get my hands on an old iPod touch for testing).
I honestly didn’t expect to be getting all this attention!
What I’m happiest about is the fact that a lot of people have been telling me how useful the app is – when I gave up my commercial flash development job to start making software on my own, my main reasoning was that I really wanted to start making things that were useful to someone else.
A tried and true product development practice is dogfooding (as in “eat your own dogfood”) – make something you want to use, because then you’ll be passionate about it and really care about the result. I started this app as part of my “App a Week” project (it took much longer than a week in the end), and at the request of K (whom I have to credit with the initial idea). I went ahead and built an app that we would find useful in our own lives, and that fit with our tastes – simple, minimal, friendly, fast. And I’ve also often thought that if you think something is a good idea, chances are that at least one other person out there feels the same way – I guess I was right in this case.
So keep the feedback coming – I couldn’t be more pleased.
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.
I’ve been trying to read recently on topics directly related to technology, technological development, and how technology affects our lives. I think that there is a tendency in the technology and interaction design industry to (consciously or unconsciously) avoid thinking about the philosophical implications of what we make.
You Are Not a Gadget: A Manifesto by Jaron Lanier is a compelling argument against a certain kind of “technological idealism” that pervades silicon valley culture – one that treats computers as if they are perfect (or at least capable of – very soon – achieving perfection) and humans as if they are reducible to algorithms – process that leads to the design of systems based on speculative computational theory and elevating computer “intelligence” at the expense of humanity.
One of Lanier’s many claims to fame is that he was the technological pioneer who coined the term “virtual reality” and was instrumental in developing the first VR technology (including the first “avatars”) – it’s hard to argue with his credentials in terms of technological innovation. His book is fascinating and detailed argument about way that the design of technology has a profound influence of the way that we use it, the way that technology directly influences the way that we think about ourselves and hence society, and the way that current trends in technology are at odds with humanist principles.
“People, not machines, made the renaissance.”
Lanier argues that by idealising computer interactions and using the computer as a metaphor for human experience we in turn make ourselves more and more stupid: Google only “knows” what we want because we ignore the times that it gets things wrong, and we learn to construct logical queries that work for Google. We are all too willing to bend over backwards to accommodate technology designed as if humans are machines, rather than designing technology that treats humans as people.
Lanier is worried about the focus on the “crowd” as a reliable and accurate source of information – its not that the crowd is wrong (it can be right in certain circumstances and for certain kinds of questions), but that the crowd isn’t good at producing new ideas – it just congregates around existing ones. On Clay Shirky’s argument that if we spent just 1% of the time we spend watching television “producing and sharing … that amounts to 98 wikipedia projects”, he shoots back: “So how many seconds of erstwhile television time would need to be harnessed to replicate the achievements of, say, Albert Einstein?”
For Lanier, innovative technological advances are (in nearly all cases) the products of individuals or small closed groups, not of crowds. Perhaps true innovation can’t happen in large groups due to our tendency toward mob mentality. Perhaps the ideology of openness in fact leads to large scale, boring, unambitious projects: How about a new version of UNIX? Or an encyclopaedia!
So You Are Not a Gadget in turn rejects the pervading ideology of “open culture” (a rhetoric that Lanier himself was instrumental in conceiving and has now turned against) as a culture that discounts individual achievement and pushes us toward averageness and mediocrity. Lanier argues instead for a move toward a new model designed around what he instead calls “punctuated openness” – anyone is always free to share, but the system is designed so that everything isn’t necessarily free and equal, mixing together all the time into a “giant mush”.
Something I hadn’t really considered (other than in vague feelings) is something else that Lanier discusses in great detail: The danger that technological lock-in, and fundamental design decisions made when building technology, can have flow-on effects for society. When you assign your “relationship status” on Facebook (a list, he suggests, borne out of an expedient database design rather than any particular insight into human relationships) you are allowing yourself (and everyone who has access) to think of you and your interactions with others within this set of predefined categories – a directly dehumanising act – reducing you to “bits” that can be stored in a particular kind of system rather than part of a continuum of human experience.
I found this argument very persuasive – the fact that designs conceived to erase the boundaries between people (Web 2.0) break down the concept of individual authorship. Wikipedia is designed to seem oracle like rather than like a collection of individuals (which of course is what Wikipedia actually is). Or the design of the internet itself (arbitrary multiple copies of data, dispersed and difficult to trace networks) while useful in some ways, makes it difficult to build an economic model for data sharing that benefits the individual producers rather than large content aggregators and gatekeepers (Google, Amazon) or walled gardens (Apple, XBox).
In the way of solutions to these (and other) problems Lanier presents some new (and some old) virtual, physical and economic models for the way that we produce, share and distribute information online (which I won’t go in to here for want of simply copying large passages from the book – suffice to say they are quite compelling).
I highly recommend You Are Not a Gadget to anyone working in any technology related field if for no other reason than to read a different point of view to the “open” advocates that make up most of the technology related media.
Unlike many technologists, Lanier is humble and well aware that he may be wrong. Despite his concerns about the current direction of technology, Lanier is still extremely optimistic about our future with technology. What Lanier hopes for is that we take care: care with our metaphors (just because we can use computationalism as a metaphor for human experience doesn’t mean that it is right) and care with our designs – because what we create directly affects us and our conception of ourselves. For Lanier, the way to write decent software is to assume that people can’t be reduced to an algorithm – we are much, much more than that – we should be trying to design technology in a way that respects individuals and and treats them with dignity.
Five days ago I was feeling overwhelmingly positive about App a Week. Now, not so much. I’ve almost completed this week’s app (a time & event history tracker called “Time Flies”), but I’ve decided not to post a demo this week – in fact, I’m not going to try and complete the app in it’s current form.
What’s the problem?
The problem is that I am finding myself getting in to a rhythm of rushing, taking shortcuts, and discounting good ideas just to meet my arbitrary deadline. All these things are things which I disliked about my previous work as a flash developer in a commercial environment.
One of my major goals when I decided to quit my job and learn iPhone development full time was to go back to practicing a measured, thoughtful, iterative design process. A deadline of 1 week, while highly motivating, simply isn’t enough time to do things properly. Sometimes it can be prudent to take shortcuts in order to release on a deadline, but this stage of my development is not the time.
I’m counting my 4 apps in 4 weeks as a relatively successful experiment. I’ve been forced to do a lot of coding very quickly (which has improved my Objective-C skills dramatically), and coding to produce stable builds at every iteration (a really useful skill). I’ve been forced to practice rapid idea generation and rapid prototyping techniques. But I haven’t produced any great apps, because trying to produce a great app in 4 weeks is kind of ridiculous.
So I’m going to call it off.
One of the positive outcomes of the last 4 weeks has been that I’ve seeded some ideas that I think I will be able to develop in to viable, saleable apps. But they are not apps that take less than a week to design and build.
So I’m going to take it more slowly for the moment. App a Week was worthwhile, it got me started, it was fun, but now it’s time to do things properly.
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.
A bit of a silly one this week – a thought experiment exploring some of the inherent risks in having instant communication devices with us all the time, even when we shouldn’t be using them. Danger Mail is for when you need to write an email that you know you should never send.
Here’s the idea – If you have to choose between two clients to send your email (the normal Mail app and Danger Mail), then perhaps you will consider why you are sending the email – are you really communicating something that is necessary? Or are you doing it for you own (perhaps risky) gratification? Run the two apps alongside each other and you may think a little more about what you are putting out in to the world.
Danger Mail is intentionally non-functional. You cannot send an email with Danger Mail. It is a space for you to vent, to whine, to rage without consequence. You can write whatever you like, and write it “to” whomever you like, with no risk.
That’s the real issue at the heart of the Danger Mail – instant communication isn’t just instant anymore, now it’s public and permanent (cf Twitter, Facebook, et al). I think there are some serious dangers in all of the off the cuff, seemingly fleeting communication opportunities at our fingertips. I’m not advocating for a return to snail-mail; just a chance to think a little more before your message is out in the world. The advantages of instant communication are clear, but when that communication gets added to your permanent online record, the risks are enormous – who hasn’t said something in their past that they regret?
Half way there
This is my third app in as many weeks – half way to my six week goal. None of the apps are release-ready (one week of design and development simply isn’t enough time), but all three have sparked new ideas and forced me to do a lot of learning and practice which was the real goal of App a Week. I’ll be writing more about the process so far in another post.
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…
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:
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…
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?
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.
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’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.
When I am reading online and find a great article that I don’t have time or inclination to read immediately, I use Instapaper. It’s great – I just hit my “read later” bookmarklet, and then I can easily find the article, or (more often than not) download it in text format to the Instapaper iPhone or iPad app and read offline – on public transport, in a cafe, on the couch. Instapaper is a great idea, and has been very successful for its developer Marco Ament.
For a while now, I’ve also kept a folder on my bookmarks bar in Safari that I use to save videos (YouTube, Vimeo etc) that I want to watch, but not right away. The folder’s name is “Watch Later” – kind of my own lo-fi version of Instapaper for videos. When I find a video I want to watch later I drag the link into the folder. When I finally get around to watching the video (or decide that I don’t really want to watch it after all) I remove it from the list.
So anyway, today I was reading a blog, the blog post contained a YouTube video, and I was just about to copy the link to save to my folder when I noticed a new little button in the top right corner of the player. Watch later it said. My brain did a little jump – OMG Google just read my mind.
You Are Not a Gadget: A Manifesto by Jaron Lanier is a compelling argument against a certain kind of “technological idealism” that pervades silicon valley culture – one that treats computers as if they are perfect (or at least capable of – very soon – achieving perfection) and humans as if they are reducible to algorithms – process that leads to the design of systems based on speculative computational theory and elevating computer “intelligence” at the expense of humanity.
Five days ago I was feeling overwhelmingly positive about App a Week. Now, not so much. I’ve almost completed this week’s app (a time & event history tracker called “Time Flies”), but I’ve decided not to post a demo this week – in fact, I’m not going to try and complete the app in it’s current form.
What’s the problem?
The problem is that I am finding myself getting in to a rhythm of rushing, taking shortcuts, and discounting good ideas just to meet my arbitrary deadline. All these things are things which I disliked about my previous work as a flash developer in a commercial environment.
One of my major goals when I decided to quit my job and learn iPhone development full time was to go back to practicing a measured, thoughtful, iterative design process. A deadline of 1 week, while highly motivating, simply isn’t enough time to do things properly. Sometimes it can be prudent to take shortcuts in order to release on a deadline, but this stage of my development is not the time.
I’m counting my 4 apps in 4 weeks as a relatively successful experiment. I’ve been forced to do a lot of coding very quickly (which has improved my Objective-C skills dramatically), and coding to produce stable builds at every iteration (a really useful skill). I’ve been forced to practice rapid idea generation and rapid prototyping techniques. But I haven’t produced any great apps, because trying to produce a great app in 4 weeks is 
So I’m going to take it more slowly for the moment. App a Week was worthwhile, it got me started, it was fun, but now it’s time to do things properly.
A bit of a silly one this week – a thought experiment exploring some of the inherent risks in having instant communication devices with us all the time, even when we shouldn’t be using them. Danger Mail is for when you need to write an email that you know you should never send.
