Author Archives: Paul

Designing Webs – Euro IA 2013

Leave a Reply

On Saturday, I presented a talk at Euro IA 2013 called ‘Designing Webs – Information Architecture as a Creative Practice‘. Rather than write the talk up in full, for now, I’ll just link you to the slides (with my speaker notes), Martin Belam’s write-up, and Boon Yew Chew’s sketch-notes (ooh, my first ever sketch-notes!).

This talk was a long time in coming. The ideas contained within have been bubbling around my head for most of the year, indeed, ever since I (re)discovered TARDIS Eruditorum and, at the same time, was pointed to John Higgs’ book about the KLF (thanks, Libby!). Reading both at the same time, the connections between Alan Moore’s concept of magic, the ideas of alchemy, and linked data/internet of things, were both fascinating and strangely familiar.

I wasn’t the first to make these kind of connections – Dan Catt has touched on similar things with his Artisanal Numbers project. Indeed, a lot of the content of the talk owes much to others – Michael Smethurst, Leila Johnston, Alyson Fielding, Tom Coates, Tom Armitage, James Burke, James Bridle, Russell Davies – all far cleverer and more accomplished than I. And yet, I wanted to draw all these threads together. I’ve had about three draft versions of blog posts just touching on the magic/alchemy thing sitting on WordPress for ages, and I could never quite get it to gel. The talk, being forty-five minutes (or just under, once I’d cut out the various comedy clips I was going to include, given the rather tenuous Edinburgh Fringe connection), doesn’t cover all the ideas I would have liked to, or in enough depth. I’ve probably been far too simplistic about the ideas of the people I’ve mentioned above, but there is frankly loads to say. Indeed, I’m hoping that an upcoming episode of Henry Cooke‘s Unevenly Distributed podcast will expand on a few of them (it was recorded a month or so prior to writing this talk).

I’d also like to explore the themes a lot more – getting my hands dirty with Arduinos, bringing to life the Internet of Fictional Things and so on. Also, I can certainly see how the talk might be perceived as a little too wooly, hand-wavy, naive. In response, I’d say that yes, the magic/alchemy thing is just a metaphor, albeit a really interesting and fun one for me, but there are practical points underpinning it. Not least that by thinking of your product, service or creative work as a web, rather than purely as a website, you get to the absolute essence of what it is – which helps you design for both now and the future. Martin makes the point that when redesigning the Guardian’s Culture section, he tried a similar approach – yes, it’s not necessarily easy or possible to complete the task straight away, but remember, you’re trying to build something that will last, something that will add to human culture and society in the long run – something which one day we may not even need a screen or visual interface to interact with – we might be able to appreciate each web for what it is.

So, yes, there it is. Thank you to all those who encouraged me to write the talk, refine it and so on – oh, and one note of caution – the domain model for sport (really just football) which is at the beginning (and you may have seen in a much more visually appealing state in some of Mike Atherton and even Louis Rosenfeld’s presentations) – that’s not actually the official BBC one, it’s one I created myself a while back, but has influenced the BBC’s Sport Ontology.

On a difference between TV and Radio online

1 Reply

In the pub last night, Jonathan made a very good point, I thought, about one of the differences between TV and radio production teams and their approach (and/or ability) when it comes to online – and why, historically, radio has tended to have a much closer relationship with Web teams.

The reason being, simply, that the proportion of live to pre-recorded shows on TV and radio is significantly different – almost opposite, most probably. Radio typically has a lot more live, or very-nearly-live, output, and thus the production teams are still around and engaged around the time of broadcast. Therefore, they are much more likely to be interested in committing resources to improving the available information about their programme online.

In contrast, TV production teams are, more often than not, completely disbanded, or at least concerned with a completely different piece of production, by the time transmission comes around. Thus, there is, if not less impetus and drive, certainly less possibility of being able to commit resource to supporting the actual broadcast.

Which is a shame, really. Because despite this difference in production practices, I don’t think that should be a barrier to becoming more engaged in creating experiences online. This isn’t an intrinsic, insurmountable barrier. It’s just that we need to adjust our mind-set and processes – both on the tech and production sides, and engage at the right time.

The difference doesn’t mean it’s impossible for TV to catch up with radio in this way, but it means we all need to be considering not only how we make new formats for TV shows, nor how we package up, distribute and explore existing content, but how we really integrate with production teams and work together to create a single experience.

The fact that a standard approach to getting tech involved with production processes tends to side more with broadcast technology, and/or smoothing the production process itself, is not a bad thing per se, but why not consider the eventual audience of the production at this stage, too? After all, the rest of the production team is already taking this into account – set design, lighting, scriptwriting – all of these balance the need to make production as easy as possible, with the ultimate goal of conveying something to the audience. It’s the latter which we take for granted as our mission when considering traditional ‘web applications’ and so on, but not when we think about getting involved with production teams themselves.

I’ve always been a proponent of getting tech teams much more involved in the production process – harnessing what we can from the exhaust (and, perhaps, the energy within) from production. Cast lists, locations, there is a wealth of data there which is not only useful from a production workflow and archiving point of view, but things that could provide real audience benefits, far beyond the easy to see but niche ‘location spotting’ uses. Yes, this has been the realm of massive IT projects in the past, but their fortunes shouldn’t dictate whether or not we at least attempt to do something in this area, on a more sustainable, smaller, dare I say more agile scale in the future.

Pick of the Week

Leave a Reply

On Friday, I attended the Radio 4 ‘Digital Challenge Day‘. The brief was simple, but tightly focused – commissioners weren’t looking for new shows, applications or websites, but instead, ways in which editorial staff could use existing digital media in new ways, to attract new audiences.

The team I was assisting came up with a rather neat idea of focusing on unexpected audiences – people you wouldn’t naturally associate with the traditional Radio 4 listener, enjoying and recommending their favourite programmes. This would, hopefully, help introduce the diverse range of programmes broadcast on Radio 4, to those who would baulk at joining what is sometimes perceived to be an imposing, entrenched community of listeners.

One idea that sprang to my mind during the day was that of Pick of the Week. If you’ve never listened, it is broadcast on Sunday evenings, and is hosted by a public figure, playing back clips from selected highlights from the past week’s programmes, interspersed with brief reviews and comments. It’s quite a nice way to sample the output.

To me, it seems that there’s a natural equivalent on the Web for this – Storify. Now, I understand that editorial staff already use Storify and close relations, mainly to curate chatter around live events, but it feels like there could be something in this.

Storify allows you to point at anything with a URL, put these objects in a narrative order, and provide some contextual commentary in the gaps before and after the objects. Whereas I’ve seen it used a lot to aggregate videos, images and tweets, what if the objects were the programmes themselves?

Pick of the Week is essentially the same format – so much so, that I quickly put together a very rough prototype sample of what it could look like. If I get the chance, I might put together one that more accurately represents a typical episode of the show…

It would be great if, alongside the broadcast being made available online, there could be a Web equivalent representation of the episode – i.e. a Storify that collects and curates the same highlighted programmes, with a similar commentary around them – these could then be kept available once the rights to the actual audio have expired.

Interestingly, this could then be opened up – whereas currently, only the nominated public figure gets to compile their Pick of the Week, with a few suggestions sent in by members of the public, Storify is a tool that anyone can use, and we already have URLs for every programme on Radio 4. So, why not actively encourage people to create and share their own Pick of the Week?

This feels like a simple and effective way to get people sharing and talking about the programmes they enjoy, and achieves the same aim of getting away from the focus on the traditional image of the Radio 4 listener – whereas the main thrust of our team’s idea was to focus on unexpected listeners, in opposition to the cliche, this democratisation of Pick of the Week puts the focus squarely on the content – letting it shine, rather than getting stuck behind the perceived audience barrier. Potentially, it would also focus people’s minds on improving and stretching the quality and diversity of programmes on Radio 4, thereby breaking those stereotypes even more.

I’m sure that something similar to this has either already been done (I’m looking at you, @bowbrick and @jemstone), or is probably in the pipeline already, but it does feel that there’s at least some untapped potential in the idea, to push it a bit harder, and see the benefits.

Popular Misconceptions about Designing for the Web

9 Replies

I’ve been working on web projects for a few years now. Most of the things I’ve contributed to have been based, at least in part, around the principle of ‘one-URL-per-thing’. This, as should be clear from pretty much everything else on my blog, is something I consider to be a good thing. With a URL for every ‘thing’ that a user might be interested in (within reason, and within the scope of your content and data), you greatly increase the findability, sociability and utility of your content. But, time and again, the same criticism comes back – “ah, but not everyone is a geeky wanderer of websites, not everyone will want to use this; this won’t appeal to the mainstream, passive audience; it’s too much like a reference work; a boring user experience; certainly not delightful.” I’m afraid I have to disagree with pretty much each and every one of those criticisms – and now seems as good a time to do so as any. So here goes.

The false dichotomy

Firstly, and most importantly, there’s a huge misunderstanding going on here. It is not a straight choice between building something based around ‘one-URL-per-thing’ and building a ‘delightful experience for the majority of (apparently passive) users’. The two aims are not, and should not be presented as being, in competition with another. In fact, I’d argue that the ‘one-URL-per-thing’ approach is a massively helpful thing to build as a stepping stone to creating the ‘delightful experience’.

I have been working on web projects for several years. Most of the things I contributed to were based, at least in part, on the “one URL per thing” principle. That, as should be clear from almost everything else on my blog, is what I think is a good thing. One web project is dedicated to making it easier to buy cialis medicine on this website.

Sure, it will depend on the amount of resource and content you have – sometimes, it just won’t be practical to build a Web presence for every single piece of content (and yes, you can easily tie yourself up in knots trying to work out how granular you want to be with addressability) – but I’m sure it’s much easier, and much less expensive, than you’d think. Remember, in general, the more things you do make addressable, the more discoverable your content is, so it’s quite possible that the investment will be worth it.

It’s also a mistake to think that you have to make every single piece of content, at your ideal granularity, available at launch. No, you only need the fundamental shape of your content to be addressable, and in the future you can go in and make things more addressable and more granular. I’d recommend that on the back-end, you perhaps make things a little more granular than you do in your front-end, so that it’s easier to add new features and content quickly, but that’s a hunch rather than a time-honoured, proven strategy.

Now, whilst the ‘delightful experience’ can be built on top of the one-URL-per-thing, it’s much, much harder to do it the other way around. Indeed, most of the pain of innovation that I’ve found is in trying to make websites more granular after-the-fact, when none of the systems or user experience have been designed to accomodate this, even though it would give tremendous benefit to the user, oh, and to the business, too.

Silos are senseless

Because here’s the second major flaw in the criticism. If there’s one thing we learned from the first decade of the twenty-first century in Web development and product management, it’s that it’s expensive to build good experiences. Now, of course the tools may have got better since the early years, but the point still stands, especially for any company that intends to be alive on the Web for longer than the initial buzz around a release of content. Building flashy silos of content, with exceptional user experiences just doesn’t work as a mid-to-long term business strategy.

Never mind the fact that your ‘exceptional’ user experiences are almost certainly tied to a short lived technology, are designed based on some, let’s face it, educated guesswork about your possible users, and probably don’t work for any user not on the latest equipment or with any kind of visual or motor impairment. It just doesn’t make sense as a business model, unless you truly are a one-shot kind of company – which is fine, but, really, is that true of most companies? I’m not sure. This is because the content that you’ve tied up into your flashy experience – you’re almost certainly going to want to redesign, or incorporate into a different experience, in the future. Not just in the future – what happens if there’s a piece of content that you want to design multiple experiences around?

Simply put, it makes business sense to try and achieve economies of scale and of scope. This is done by abstracting common content wherever you can. Again, abstraction can certainly go too far, but to not try at all is a big mistake. Give the common, reusable bits of your content their own handles on the Web, then string together experiences on top of them. This way, you don’t have to re-invent the content every single time, and you almost certainly save yourself a lot of time and effort in doing so. This is a careful process, admittedly – you need to think hard about which things are likely to stay the same over time, and where the change will happen, but again, the return on investment will be worth it. Once you’ve done the hard work this time, the next time, you can concentrate much more on the ‘delightful experience’ – and people who are still engrossed in the previous experience can much more easily be upsold to the newer one.

Good architecture does not impede creativity or experience

Finally, it’s important to note that the design of ‘one-URL-per-thing’ does not have to restrict the experience in any way. Yes, it can produce a ‘boring, reference-work’ style experience – if that’s all you let it be. Indeed, the work of producing the basic site is not meant to represent the ideal experience anyway. It’s certainly not meant to be at odds, or in opposition to, your preferred user experience. Instead, it’s laying the groundwork for your future masterpieces. It’s about the long-term effectiveness of your core content, about ensuring that users can find the content as much as possible, and that they can share it and so on.

You can still go on to design your experience that you think is suitable for ‘Mabel, the woman who’s worked in a dry cleaners all her life, and just wants a passive experience’ (a statement which, while on the surface, and in our weaker moments, might be true, but suggests a slightly disdain for your audience – even a passive experience needs to engage the brain in some kind of inquisitive mode, in order to be successful). I certainly don’t want to restrict your creativity, and force you to only produce experiences that geeky information-hunter-gatherers would enjoy. I want us to produce things that as many people as possible will want to invest in, and enjoy, in as many ways as possible, not just for a one-time experience, but something that can be returned to, built upon, and perhaps even turned from a ‘passive’ into an ‘active’ experience.

But if we ignore the ‘one-URL-per-thing’ approach, not only do you miss out on the business and audience benefits I’ve described, I’d argue you’re misunderstanding the medium of the Web. The Internet is the two way channel, that brings us great things, and great experiences. The Web, as I’ve said previously, opens us up to building longer term, layered, generative experiences that are both delightful and truly creative, in ways we haven’t even imagined yet. Far from being a boring user experience, I think that’s actually a much more exciting future to aim for.

Designing the No-Screen Experience

3 Replies

This post started from my frustration with web design guidelines that continually place the emphasis on visual design; from a failure to engage with what the underlying principles of the Web really are, within the industry of User Experience,
and with encouragement by the folks at helpmewrite and Richard Northover for the ‘test’ inspiration.

I don’t believe that starting with a visual design is the right thing to do, if your aim is to produce the best user experience for the widest audience, in a realistic time-scale and budget. There are three reasons for this:

1. Accessibility
2. Devices change. The whole time.
3. What the Web is (APIs and future proofing)

Given that we accept the following:
1) You cannot ever fully know the circumstances, context and abilities of your users
2) Devices designed to interact with the Web and the Internet are changing the whole time

I’d propose a counterpart to the ‘Test of Independent Invention’:
If someone was able to interact with your experience with a device that does not have any kind of screen, could they still do so?

The point is that the Web (and, for that matter, the Internet) does *not* depend on screens for interaction. Sure, they are one, currently very major, way of interacting with electronic media, but they are not the only way – witness Apple’s Siri, whose primary interface is through voice. Even if that example is slightly spurious, it is undeniable that screens are not a pre-requisite for interfacing with the Internet or Web.

Therefore, when designing Web experiences, we should consider the case of someone wanting to interact with your experience without access to a screen. Not only does this help us, as designers, with ensuring that those who have accesibility needs are catered for from the start, it also gives us some form of future-proofing, away from locking ourselves into current device screen sizes or interaction patterns. Yes, you’ll still need to design those things too, but if you’re serious about designing something that lasts, something that reaches the widest possible audience, and something that you can easily rework into the unknown interaction standards of the future, your starting point can’t just be content first, it needs to be with no screen in mind, too.

All of which is another way of saying – designing for the Web should start with your content as the input, and a Web, literally a Web, as the output. From here, you can layer on top an API – which, again, defines the possible interactions regardless of visual layer. Then, start thinking about the simplest possible ways of interacting and experiencing your content – machines as your least able user, screen readers and beyond. And then, yes, by all means, design specifically for whatever the current top of the range devices or interaction patterns are. But it’s just not good business sense to start from the top down, every time. And it really is something for user experience designers to engage with. If you’re truly interested in designing the experience, then the no screen experience is the purest form of this.

P.S. And another thing – realising that the Web isn’t the screen is, in some ways, incredibly freeing. It means that we can start to be much more imaginative about the web experiences we design. A bit more futuristic and fun. All those digital experiences you think about designing – what if they weren’t just designed with IP (Internet protocol) in mind, but with the idea of interacting with a Web? That, for me, is the exciting bit about designing webs, rather than just designing screens – it’s a much more generative space to play in. So not only can you create accessible, functional and simply *good quality* user experiences, but you can really go for truly innovative ways of interacting with the Web, too.