Category: app a week

App a Week #3 : Danger Mail – don’t email in anger

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.

App a Week #3 – Don’t email in anger…

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…

App a Week #2 : Flickrstory – photos in time and place

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…

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:

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.