James Higgs's posts

One of the fundamental principles we lived by throughout the process of redesigning the ITV News website was that we needed to ground what were doing in the real needs of users. Cath explained our approach in an excellent post a few weeks ago.

All too often on content management projects a very significant group of users are taken for granted: those who will create and manage the content. On this project, we were detemined that we would really try to understand the editorial experience in depth, and provide tools that fit the journalists’ requirements.

We started with a fascinating and intense day in the ITN newsroom with Jason Mills and his team. We were allowed to attend the morning editorial conference and busy journalists tolerated our interruptions and stupid questions throughout the day. Finally, we were allowed to have a nose around in the studio and then watch the ITV Evening News transmission from the gallery.

Alastair Stewart in the ITV News Studio

When one talks about Apple's design, one immediately thinks of Jony Ive's modernist, rational industrial designs for computers, peripherals, and of course the iPad and iPhone.

Yesterday, I tried to explain the concept of technical debt. Today, I’ll try to suggest a practical way to track and deal with debt in your project.

As with debt in the real world, the trick with technical debt is to track your liabilities and make sure you have a plan for addressing them. Allowing debts to build up without thinking about what you’re doing is a terrible way to run your personal finances and your software development project.

So long as you are making informed and deliberate decisions about when to incur debt and when to pay it down, you do not necessarily need a plan to eliminate your debt entirely. Rather, you should aim to keep it at a sustainable level so that you’re able to add new features to your product relatively easily and without too many side-effects.

Almost all communication between developers and non-technical colleagues or clients is done through a set of metaphors. Some of them (the construction metaphor, for example) are actively harmful, but others are potentially very useful.

The idea of technical debt is one of these but, as with any metaphor, it’s important to understand where the limits of its applicability are. For these metaphors to be useful, they need to be used accurately.

There’s a pronounced tendency within the agency world to appropriate technical terms and then to use them incorrectly (‘operating system’ is the trope du jour), presumably in order to appear more technically knowledgeable but, to anyone who knows what these things really mean, the effect is just to reveal the metaphor abuser as a bullshitter.

Abused in this way, useful terms gradually become stripped of their meaning and replacements have to be found. I worry that this is happening with the term ‘technical debt’. Hopefully, this post will help to clarify its meaning.

Last year we made a well-received iPhone app for vinspired. The idea behind the app was to make it even easier for young volunteers to find volunteering opportunities and to document their activity and to share it with the world. We recently started work on an updated version of that app – look out for it in the App Store in the next few weeks – but we haven't been idle in the intervening time. Today, vinspired are announcing BlackBerry and Android versions of the app at ND11.

The conventional wisdom is that Google will be or is the big challenger to Apple in the mobile computing market, but it turns out that we've been digging in the wrong place all this time. The way I see it, the real competition is going to come from Amazon.

Recent announcements from Amazon make me more certain than ever that they will shortly be launching a Kindle-branded phone and tablet based on Android.

As programmers today, the code we write sits atop an enormous stack of abstractions. There are so many excellent frameworks, libraries and how-tos out there that it sometimes feels as though there's almost nothing that we have to work out for ourselves, and that the focus now is on execution rather than the intellectual challenge of working out how to make something work. For non-programmers this is all good, but for programmers it's tinged with a little sadness.

An Arduino Uno board wired up to display an animated pattern on an LED array.

Today, the process of writing code is that of creating and chaining abstractions together. The apparently simple act of writing, proof reading and publishing this blog post probably involves making use of several thousand of them.

When I'm asked what I like best about being a programmer, I talk about how satisfying it is to see someone else using and enjoying the software I help to build. Today, it's human factors rather than technical ones that make achieving this difficult because, although the technical underpinnings exist to make great software, it still takes talent and care to shape these together into things that users like using, even if there are no complicating factors like politics or hobby-horses. But, this leaves us with an intellectual hole to fill.

I’ve been working on an iPhone app for the last few weeks, which I’ve really enjoyed. Every now and again, though, you hit what seems like a bug in the iOS SDK.

 This seems to happen much more frequently than it ever did when I was coding in C#. As a result, my default debugging approach – that any problem with my app must be my fault rather than something in the framework – has shifted slightly. I’m now much more likely to question the framework itself, and with a quick Google search it’s common to find other developers who have experienced the same problem.

Here’s one that bit me recently. NSString has a method calledstringByAddingPercentEscapesUsingEncoding, which purports to make the string safe for use, say, as a parameter to a URL. There are several characters that are reserved in parameters toURLs – for example the slash character, or the ampersand, because these are characters that are used to delimit the URL itself. Therefore we encode these, and this is done using the percent encoding scheme.

Ever since the media eruption over the iPhone 4′s antenna design, I’ve been thinking about how we assign meanings and experience real emotions in response to representations, or illusions.

Adapted from a photo by Jamais Cascio

We’ve held some interesting talks here at Made by Many over the last couple of years, and I’m thrilled to announce that we’ve got an exciting one coming up next week.

We’ve invited John-Henry Barac, the designer of the tremendously successful Guardian iPhoneapp, to come and share his experiences in designing a newspaper app for the iPhone. Our friends at BBH London have kindly agreed to provide a room for the talk, for which we’re very grateful.

The Guardian iPhone app has been a huge hit, and recently won the innovation award at the AOP awards, where the judges said that it “broke the mould of how content to mobile can bemonetised”.