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.
Good, simple advice. If you go ahead hit send on that email, there’s a very good chance you’ll regret it. You could lose a night’s sleep, a friend, a job. Please don’t send it. Please.
On the other hand, writing in anger can be a positive cathartic experience – ask any 15 year old with a journal. There is something about the process of writing what you really think that allows you to get those thoughts out and on to a page, out of your head so that you can take stock and approach the problem in a more considered way.
So here’s an idea – how about an email client specifically designed for writing emails that you know you shouldn’t send?
I mentioned the other week a thought I had about developing apps that have structural qualities that are designed to modify a user’s behaviour in a specific way. The idea behind this app is that the mere act of using it should help the user consider their email content just a little bit more than usual.
So that’s what I’ve been working on this week – an email app that gives you a chance to change your mind.
An aside: read the instructions first.
When I was quite young, maybe eight years old, I remember buying a new plastic model WWII tank. I was never a particularly diligent or careful model maker and this was the largest and most complex model I’d ever bought. In my hurry and excitement I skipped over the instructions and started cutting an gluing, and (much to my parent’s amusement I seem to recall) within a short amount of time I’d somehow managed to glue the hubcaps on before the wheels. Anyway, you’d think I’d have learned my lesson by now…
It turns out Apple’s MessageUI framework explicitly doesn’t allow any interference with the email process – you can present a mail composition view (designed by Apple), but you can’t modify the view in any way apart from pre-populating editable fields – no custom controls or colours. You may set a delegate to receive a message after the mail has been sent or cancelled, but not before.
I have now gone so far as to build a prototype of the whole app using a dummy messaging view – I’d just assumed that I’d add in the messageUI after I’d done the complicated part (I’m also using this app as an exercise in animating with the CoreAnimation framework so I’ve had a lot of learning to do). Unfortunately, the entire flow of my app as it stands depends on me being able to intercept the email before it is sent. Which I would have known was impossible if I’d just taken the time to look it up.
So I’m rethinking (late in the game again) – how can I keep the general idea intact and still make it a useful app? Updates to follow…
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…
Because ActionScript is an ECMA based language, strings are declared a literals using quotes:
var string = "This is an ECMA string";
var anotherString = 'So is this';
Objective-C on the other hand, uses the class NSString for string access, and you declare a constant string using a convenience method by putting an @ in front of your quotes:
NSString *string = @"This is an NSString";
“Yeah…? So?”
Well, I spent 2 hours yesterday tracking down a dreaded EXC_BAD_ACCESS somewhere in my app – being new to Objective-C I just assumed that I’d messed up my memory management somewhere and double-released, or used an autorelease where I shouldn’t have. But I checked and checked and checked and couldn’t figure it out. I finally managed to track the crash down to a particular message call to a method that took an NSDictionary as one of it’s arguments:
Whenever I sent this message, the program would crash. I checked for a memory leak in every object in my class, I even looked for memory leaks in the ObjectiveFlickr framework… But you see the issue right? Look again:
... ,@"photos","media",nil]];
It looked right to me because I’ve been an ActionScript developer for so long that anything in quotes just looks valid. And in C it is a valid character string constant (so there was no compile-error).
But if you pass a C string (rather than an NSString) as they key in an NSDictionary, you get an EXC_BAD_ACCESS. And a lot of wasted time.
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?
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.
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.
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 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.
“Oh no,” you say “not another post about memory-management from a new iPhone developer… retain counts, autorelease pool, alloc, copy , blahdy blah blah… weget 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).
