Monthly Archives: February 2014

Time flies when you’re having fun

Well, I’ve just submitted my first finished app to the app store. I guess now all I can do is wait…
http://www.timefliesapp.com

Book Review – You Are Not a Gadget: A Manifesto

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.

For anyone that is interested in any of this I strongly suggest listening to this podcast of a talk he gave on the event of the book’s release. There is plenty more about the book and Jaron’s philosophy at his website.

Iterations

Progress

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.

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…

An ActionScript developer with EXC_BAD_ACCESS? Just check your strings…

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:

[self.flickrRequest callAPIMethodWithPOST:@"flickr.photos.search" arguments:
    [NSDictionary dictionaryWithObjectsAndKeys:OBJECTIVE_FLICKR_API_KEY, @"api_key",
    @"1",@"has_geo",lat,@"lat",lon,@"lon",@"5",@"radius",@"photos","media",nil]];

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.

... ,@"photos",@"media",nil]];

That’s better.

iPad + dead screen = expensive paperweight + development disaster

I woke to find my iPad screen dead this morning.

Well, not quite dead – there seemed to be a little bit of backlight there, but nothing else. After some extensive googling, I tried restoring the software (both from backup and a full restore) with no luck – the iPad seemed to be “on”, (and iTunes seemed to think it was fine), but the screen was completely blank.

In a last ditch attempt I turned on the accessibility voiceover (a few people have reported an unintentional blank screen when accidentally turning on  the “screen curtain” function) – and using the 4 finger triple-tap gesture I was able to get a happy female voice to tell me (with a little too much certainty for my liking) “Screen curtain on! Screen curtain off!”

But the screen stayed black…

So the iPad is now off at the Apple store for service, which has set back the development of my app for this week a bit. I’ll continue working on it using the simulator (and will upload a demo this afternoon), but it won’t be as polished as I would have liked.

UPDATE: The Apple store gave me a brand new iPad, so I’m guessing that the dead screen is actually due to a hardware fault – if this happens to you don’t hesitate to take your iPad to the Apple store.