Author Archives: Paul

Your Favourite Song (30 Days of Music 2014)

Leave a Reply

Sometimes – Miami Horror

The slightly sickening music video with obligatory young pretty things

I’ve been making my way through Grand Theft Auto V.

The game doesn’t quite have the same seductive atmosphere as Red Dead Redemption, which I fell in love with. The story and characters, too, aren’t necessarily the best. But the sense of a world, just by wandering or driving around, is what I enjoy the most, in both games. Ironically, really, given that all the studying I’ve done so far around fiction and writing has been focused on plot and character. Hmm.

I’ve yet to experience a summer holiday of relaxing, carefree living and/or just being in the US, if only for a short while. This song speaks to me of the sunshine-soaked atmosphere of driving down the freeway, or taking in the sunset at the beach, albeit in a virtual environment. It’s an illusion, doubly so in GTA, of course.

Nevertheless, the lush electronica, similar to that found in Cut/Copy’s music, combined with a very New Order style bass guitar, hits the spot for me. Full of hope and promise, the summer to come.

30 Days of Music

Leave a Reply

Shamelessly cribbed from Matthew and Mark – let’s just call this attempt number 765 in the long, long series of me trying to establish a regular writing pattern. Oh yeah, the newsletter, I’ll pick that up again soon.

Thing is, whenever I’m writing something, I’m overcome by massive self-doubt – that what I’m doing is self indulgent, irritating and so on. Twitter is, for some reason, probably the only exception to the rule, and yet most likely to be the most irritating. Anyway, with this series of blog posts, I’m going to say this up front – I’m giving myself permission to be self indulgent. This is an exercise for me, primarily, with the hope that others might find it entertaining too.

Matt was worrying that he was writing too much about himself, and not enough about the music. With the greatest respect – have you seen the categories (below)? Each trigger is pretty much a shot across the emotional bows, so I don’t think there’s anything wrong with using the music as a stepping off point for something more personal. That’s what I’m planning to use it for. Yes, there will be some discussion of why I have a particular emotional reaction to a song, some attempt to describe its’ musical mechanics, but it’s also an opportunity to tell a quick story, a snapshot of where I am now.

Music has always been a big part of my life. Playing and composing, much less so – brief excursions into playing the recorder, violin, keyboard and guitar aside. But every commute is soundtracked, music is everywhere for me. So much so that the security guard in my previous job, when asked to identify me, called me ‘the bloke with the headphones’. My tastes may be more mainstream than most – if I offend you with my populism, I’m sorry – it’s just a stepping stone for something else.

I’ll do my best to post on consecutive days. The most difficult part, I fear, will be nominating a single track – but it can only ever represent my reaction to the prompt that day. Which makes future iterations of this project even more interesting, I hope. So, here we go.

The categories are:

day 01 – your favorite song – Sometimes (Miami Horror)
day 02 – your least favourite song – Just a Little (Liberty X)
day 03 – a song that makes you happy – Don’t Falter (Mint Royale & Lauren Laverne)
day 04 – a song that makes you sad – Exile Vilify (The National)
day 05 – a song that reminds you of someone – Robin The Hooded Man (Clannad)
day 06 – a song that reminds of you of somewhere – Suzie (Boy Kill Boy)
day 07 – a song that reminds you of a certain event – Map of the Problematique (Muse)
day 08 – a song that you know all the words to – Breaking the Law (Judas Priest)
day 09 – a song that you can dance to – Disco Down (Shed Seven)
day 10 – a song that makes you fall asleep – Agent Orange (Depeche Mode)
day 11 – a song from your favorite band – Enjoy The Silence (Depeche Mode)
day 12 – a song from a band you hate – Aqualung (Jethro Tull)
day 13 – a song that is a guilty pleasure
day 14 – a song that no one would expect you to love
day 15 – a song that describes you
day 16 – a song that you used to love but now hate
day 17 – a song that you hear often on the radio
day 18 – a song that you wish you heard on the radio
day 19 – a song from your favorite album
day 20 – a song that you listen to when you’re angry
day 21 – a song that you listen to when you’re happy
day 22 – a song that you listen to when you’re sad
day 23 – a song that you want to play at your wedding
day 24 – a song that you want to play at your funeral
day 25 – a song that makes you laugh
day 26 – a song that you can play on an instrument
day 27 – a song that you wish you could play
day 28 – a song that makes you feel guilty
day 29 – a song from your childhood
day 30 – your favorite song at this time last year

Some quick thoughts on URLs

Leave a Reply

This past week, there’s been a kerfuffle about an experiment within Google’s Chrome browser which hides URLs from the user. Lots of good folk have chipped in (three posts there, to give you an overview), which is good, but here’s a few thoughts before I forget to write this at all:

– As with any design decision, this has good and bad points. The discussion needs to be level-headed and focus in on the issues that the decision is trying to solve, and work out, clearly, what those issues are, and whether there are better ways of solving them.

– For instance, this has been described as (and I’m paraphrasing here) ‘using a sledgehammer to crack a nut’. That may well be true. What’s important, I think, is to have a public, open space where someone can say ‘hey, this is an issue in all modern browsers, let’s discuss how we might solve this’ – rather than announcing that some internal team has made a design decision and haven’t (as yet) explained their rationale. Again, this last point is key – show your working, explain your thinking. If you don’t, someone else will try to join the dots for you.

– The security faults and general ‘WTF’ of URLs to the ‘average’ user is such an issue. But I’m not convinced this is necessarily the best way to improve it. I might well be wrong, but let’s discuss it.

– Sir Tim Berners-Lee’s first browser didn’t show URLs. URLs were never designed to be seen by the user. Indeed, being visible leads to one of the most unfortunate side effects – people feel they have to be human readable. Now, I’m not saying that they shouldn’t be human readable, but it’s more that people often prioritise that aspect over, in my opinion, their key feature – they should be permanent and unique. Human readability is the next step after that (as is a clear, logical rationale, that makes them hackable).

– URL design, however, is, in my experience, a very sadly neglected art, with key principles, hard decisions and a profound impact on the user experience (if you read one article from this post, make it that one). Hiding the URLs, I agree, could easily lead to less effort being spent on crafting them well. Out of sight, out of mind, as it were. On the other hand, as above, it could take them out of the spotlight and therefore more easily kept in the hands of those who care about getting these things right.

– Equally, talk of ‘the death of the Web’ can be mis-interpreted, very easily, to have the same effect – those who don’t follow this stuff closely will thus assume that they don’t need to care about such things, and it all goes to hell. Basically, drama can multiply the negative effect, as well as drawing attention to the potential damage being caused.

– Whilst I don’t think there’s necessarily a sinister motive behind the experiment, I do agree with ntlk that this kind of thing could easily play into the hands of entrenched, powerful players – sleepwalking into an I intended consequence – and we shouldn’t let that happen without a fight.

– I dearly hope that the idea of the sustainable Web comes to fruition – as Dan Hon says, “One that is kind of adjacent to the indie web, but that builds long-lasting, reliable services, not ones that disappear”. I hope this happens in the industry. Because then we might finally start taking URL design, and hey, maybe a site architecture that is a Web, rather than a hierarchical file directory, seriously as a topic, both in terms of development and UX.

Update One: As expected/hoped for, Michael Smethurst has written something more precise on the topic – go read that.

Update Two: Please don’t get me started on these really, really stupid vanity TLDs like .london and so on. They are pretty much pointless, for people wanting to be duped into paying money for the latest fad. Sorry. It makes me angry. But hey, if it’s ‘seen to be important’, why not go ahead and buy a .HORSE domain name?

On Design as a Service

Leave a Reply

Yesterday, Tom Maslen wrote this piece, on responsive design and how the BBC’s User Experience and Design (UX&D) teams are set up to work with the various BBC ‘product’ teams. It’s good, you should read it, and then come back and read the rest of this.

I agree with almost everything in there, but thought there were a few points that needed fleshing out, perhaps with a slightly different viewpoint. Obviously everything which follows is personal opinion, and is offered up in the spirit of open communication, with the aim of making things better, rather than personal attack or criticism.

Some background

From October 2008 to December 2013, I worked in the aforementioned UX&D team. From 2008-10, I was part of an embedded team within BBC Audio & Music (A&M). From 2010 onwards, the department, alongside most of BBC Future Media (FM), was reorganised several times, and we became more of a central team.

It’s fair to say that I found the time embedded within A&M much more productive and fulfilling, though of course there were rough patches too. I strongly believe that the embedded nature of the team was a big part of why it worked so well – but there were plenty of other factors.

Although Henry Wood House wasn’t the shiniest of buildings, the three floors that we were based on were open plan and yet small, giving the air of a small business. Open enough to share, and not large enough to be overwhelming and faceless.

Thanks to the sterling work of Tristan Ferne and others, we had what was known as 10% time, similar to Google’s 20% time, which was a chance for anyone, of any discipline, to work on their own personal projects, as long as they were somehow related and beneficial to the BBC. We had monthly show-and-tell meetings, where people could come with ideas or requests for help, and this all promoted a very positive atmosphere of shared expertise and mutual learning. I’d bring it back in a heartbeat. But anyway…

Taking the emotion out

One thing it’s important to state clearly, is that any critique of current practice or organisational structure has to be divorced from personal criticism. As Jake and Crystal both pointed out, correctly, there is no-one at the BBC, either within or outside UX&D, who is actively trying to keep designers and developers from working together. There is no evil master plan. That said, several very good ex-BBC people cited this way of working as one of the reasons for leaving the BBC, so it’s something that shouldn’t be swept under the carpet as a non-issue.

Most of the designers I worked with in UX&D are great people, who would be more than happy to work alongside developers. And there are good people within UX&D working on figuring out how we should adapt to responsive design and the main truth that Tom, and others, have pointed out – online, you simply can’t control completely, how your users will experience your content. How do we provide the best possible design solutions with that in mind? I agree, we start from the bottom and work up.

And finally on this point, I think it’s important to have this discussion in the open – like I say, no-one wants to make things worse, so we need more discussion between developers and designers – and I know that there are plenty of people at all levels of the UX&D structure who want to make things better. So let’s make something good happen.

Here be problems

That said, there’s no denying that there are problems with how things are done at the moment. Again, this isn’t necessarily the fault of personalities, it’s just the way the organisation is structured, and how working practices easily fall back on ‘traditional’ waterfall-esque design approaches. This really needs to change. Everyone needs to be focused on delivering the real thing, and realise that User Experience includes loading times, page weight, caching and so on, all the way down to how you structure your content and your data. As Tom says, start with understanding your content, not just your users – really understand it, and design around that.

Tom is also right that the ‘4-screens’ mantra, and break-points approach, is holding us back as much as it is helping. Again, I think both of these things have good intentions – the first is to underline, to those of us not familiar with the mobile web at all, that we need to change from simply designing a desktop site, to something which works across multiple screens. The second is simply an attempt to be able to design *something* given the vast array of screen proportions.

But ultimately, both things are flawed – Tom advocates ‘all screens’ – I’d go further and say ‘no screen‘ – because what’s really important is the information, the content, the meaning and interaction with your users, and this needs to be designed to work in any possible medium. That’s why I’d start with designing your domain, API and URIs, then build up from there.

Defending the Centre

And yet. I’d like to somewhat defend the ‘central UX team’ approach, just a little. Or, rather, extend some empathy towards understanding why such an approach has been taken. Because one of the problems of such a large organisation such as the BBC is its’ traditional silos. The ten products strategy, although great at reigning in the sheer volume of wildly-varying-in-quality online output, has, unfortunately, reinforced silos as much as it has broken them down.

And so having purely embedded design teams can lead to massive differences between the ‘products’, and a lack of joined-up thinking or overarching strategy. With that in mind, a central team which can work across many products, makes sense, of a sort. It also helps foster a community spirit, and shared knowledge and expertise between designers.

However, it also encourages and highlights the differences between disciplines, and, just like with the different products, a separate team with separate objectives will lead to people pulling in different directions. It also leads to organisation structures and layers of process and management which result in unexpected side effects like completely separate desk spaces for different disciplines.

To be clear, I think there is a very good rationale behind the idea for a central UX team – from within News, or any other single product, it may make perfect sense to have an embedded team, but when you’re responsible for establishing a quality standard of design across the whole of the BBC, you’ve got a more macro-scale problem to deal with.

Forever Cycling

The other problem Tom highlights is the cycling of UX&D staff through different products. Again, having witnessed things from the other side, there are good intentions behind this. As David hints at, rotating staff gives people a chance to try new things, to learn from different teams. It helps spread knowledge around, so that if a member of staff is away or ill, and again, reinforces the sense of a consistent approach to design across all areas of the organisation.

And yet Tom is right – it also means that you have to spend an overhead of time training up new joiners, a lot of expertise can just disappear overnight, and, quite frankly, the resource management of all this can be a nightmare from the UX side of things too. Personally, I also felt under more pressure in this system, as I was never fully in control of my own resourcing (but then unless you’re freelance or run your own business, you’re never fully in control, so that’s almost certainly just my hangup!).

In Summary

Overall, then, I think Tom is pretty spot on, if veering a little towards a too-negative perception of the people that make up the UX&D team. But a) I don’t think that’s intentional, and b) this is exactly why open discussion, sitting and working together is needed – because the more we continue to define ourselves as separate and different, the more that others will make assumptions about our attitudes, and communication breaks down, being replaced by suspicion. Gosh, that’s just defined multi-cultural tensions in a nutshell.

I would advocate embedded design teams, or rather, completely multidisciplinary teams, focused on the same goal – making the best possible thing, for the most number of users, via any form of interaction. But I do think there’s important and complex problems to be solved on a more macro level across an organisation such as the BBC, if we are to maintain a good level of quality.

I’d suggest this can be achieved not by separation of disciplines, but more by a loose and regular discipline meet-up/network type approach, perhaps, so that people of similar skills can keep some sense of community and share ideas and expertise. Having said that, the sheer size and geography of the organisation doesn’t make that easy – but it’s not impossible, we just have to try.

And finally, as Michael quite rightly points out – all of this is pretty useless if the rest of the ‘business’ is unengaged and even more separated from development than design.

There are good people who want to help solve this. Let’s keep talking, but more importantly, do something. Maybe moving back into Henry Wood House is a (completely impractical and impossible) start.

My Mission for 2014: Writing is Structure

3 Replies

It will come as no surprise to anyone that I’m interested in writing, and specifically the writing of narratives. I’ve always harboured a desire, if not the will or confidence, to write stories – scripts, sketches, that kind of thing. And, in the realm of technology, I’ve long been interested in structure. It’s often said that structure can be bad – too restrictive, too cookie-cutter. That’s not the kind of structure I’m interested in.

Things like Mythology Engine, Storybox and the Stories Ontology were attempts to convey the kind of thing I am interested in – but they, too, can be interpreted as trying to dissect narratives, and thus ultimately destroy them. In contrast, I guess what I’ve been trying to investigate is the structure which informs the creation of narratives, as well as the analysis, with the latter being only so that the narratives can be discussed, shared, and in turn, inspire new narratives. So my interest is more in conveying meaning, where possible – telling stories to the machines, as I’ve noted elsewhere. But also in using structure as a guide, as an inspiration.

Many times when I’ve tried to start writing a story, I’ve struggled. At first, the fear grips you that it’s down to two things – you can’t write, and you don’t have any good ideas. The first fear can, after a while, be dismissed, especially with the adage that is prevalent in technology as well as writing – just make/write something, a terrible first draft, just so you’ve got somewhere to start from.

The second fear, of no ideas, is a harder one to shake. Primarily because, in a lot of the writing I’ve read on writing, it concentrates literally on the process of writing, of scrawling on paper or typing on a computer. Giving yourself time to write, setting a target of a certain number of words a day, even in terms of writing prompts, little sentences designed to spark your mind.

But I’ve never really found this helpful either. What is helpful, I’ve found, is structure. Again, not as a ‘this is how you must write your story’, but as inspiration – ‘try this way of structuring your story, and see where that takes you’. Robert McKee’s book, Story, is a step in the right direction, but it felt a little too focused solely on screenwriting, and was a tad too opinionated and didactic for me. I got about a third of the way through the book, and, feeling it wasn’t for me, gave up, falling back again on the thought that you just had to sit in front of a blank screen, perhaps with a writing prompt, and see what happens.

Then, two things happened – David Varela’s tweet – ‘Writing is structure’, provided a spark of light, for me. For so long, I’d been under the impression that structure was always viewed with suspicion by writers, for the ‘cookie-cutter’ reasons above. But this gave me confidence.

And then, I read FilmCritHulk’s Screenwriting 101. I found it incredibly inspirational, broad-minded and enlightening. It doesn’t really talk about the process of writing as I’ve mentioned above (the ‘just sit down and write’), nor the slightly worn phrase ‘writing is rewriting’ (the latter, which may indeed be true, doesn’t help, in terms of a narrative, if you’re trying to work out how to start).

What it does, is help you focus on the inspiration for narrative and character, and suggests several structural approaches for both analysing and creating. Things like the five-act structure, character trees, snowflakes, ‘therefore and but’, and so on. Seriously, read the book. Again, it doesn’t insist that you write every story in these ways, but it gives you frameworks, approaches – things you can try, which will help you structure a narrative, before you get to the stage of literally writing the dialogue and so on.

That, that is what I’m interested in. And I want to know more. Firstly, because ever since reading the book, whenever I watch a film or TV show, I’m consciously looking out for five-act structures and so on. But secondly, because I want to build something. You see, as far as I’m aware, all the tools out there for writers are either ones that are very general purpose ‘idea collection’ tools (mind-maps, post-it notes etc), or purposely script-writing ones (things like Final Draft, or Adobe Story). But I’m not sure there’s anything in between. Something which takes the structures and frameworks and leads you through them, or helps you create narratives using them, or even just helps you analyse existing narratives through that lens. So that’s what I want to build.

To that end, this year, I want to learn and understand as much as possible about the structure, craft and process of writing narratives. I’m not as interested, as I say, in things like ‘how do you find time to write’ or ‘do you just sit down at your computer, type, look over it, and type again’. I want to find out more about the different ways you can structure a narrative – what are they, how often are they used, where are they helpful, how might they be combined.

I want to speak to as many writers as possible about this. If you’re interested, get in touch (I already have a short list of folk I’d like to talk to, so expect emails, but get in touch anyway!). If you don’t really use structure, that’s absolutely fine – I’m not trying to force everyone to use it – I just want to provide something for those who do use it, or are interested in it. Similarly, if there are tools which already do this – I’m interested in terms of research, but I’m still going to build something, if only for my own learning – please don’t bring me down 😉

I’m thinking this could result in a series of blog posts, or perhaps even a podcast series, of interviews with writers – and then ultimately a tool, based on all that knowledge.

Let’s see where this takes me.

P. S. Things that also helped inspire me to write this – John Yorke’s Into the Woods, Matt Locke’s Don’t get bigger, get weirder, and Kim Plowright’s Guiding Principles.

P. P. S. Oh, and I guess I should write a blog post about the slightly-different new job at some point, too..

P. P. P. S. Also worth clarifying – I’m not looking to build something whereby machines auto-generate stories. Whilst that may be an avenue worth exploring, I’m not interested in taking authorship out of the hands of humans. This is about giving more tools to humans to create stories, and, perhaps, to widen the audience of those stories to include machines as well.