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’.

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.

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.

Second piece – The Stories in Enchanted Objects

Third piece – Telling stories to our computers

I hope they’re of interest – feel free to get in touch if you’d like to discuss any of the themes I uncover.

Probably my best experience of ‘organised’ innovation in my career so far has been the ’10% time’ organised by Tristan Ferne (and others) at BBC Audio & Music in 2008-2010. The premise was simple – 10% of your time each week, i.e. every Friday afternoon, you could spend on your own project, providing you shared the results with others, and it was in some way relevant to the BBC. Every so often (monthly, I think, but possibly fortnightly), a meeting would be called, where people would share work in progress, and those with new ideas could pitch them and ask for help. This was an excellent way of fostering a community spirit amongst disciplines – no-one claimed to be an expert, there were no cast-iron commitments to finishing a piece of work, it was simply this – if you want to help build something, to build upon an idea, take it and run with it, to contribute to helping someone else’s idea come to fruition, or to learn and share knowledge, this was the space to do it. It was excellent.

But, for whatever reason, 10% time is no more. There are, of course, more organised or formal ways of ‘doing’ innovation – hack days, R&D groups, the BBC’s Connected Studio. Not all ideas fit nicely into work remits or structures though. Sometimes you don’t really want or have a brief, or a challenge, or a short time frame and a competitive environment. Sometimes you just want a friendly space where you can share half-baked ideas – people are free to build upon them, help you realise them, or ignore them entirely. And, as is probably obvious to anyone who’s been reading this blog or has spoken to me recently, there’s things I’d like to try, things I’d like to learn, that just don’t tend to fit in those existing boxes. Sure, I could take these on as completely personal projects, learn and build them on my own – but that can be a difficult and frustrating experience. I don’t want to avoid this entirely, but when I know there’s people out there who could help, it feels silly to ignore all that, struggle and most probably give up in the end. Similarly, you could just blog and share it with Twitter and the rest of the Web – this is fine, but sometimes you need more of a bounded box of interested parties, so things don’t get lost in the noise.

Today I met up with Mark Simpkins (somehow, for the first time), after planning to meet with Chris Thorpe (another time!). We talked about an idea that Mark had been discussing around an alternative conference format – something in between a formal, present your slides, conference, and a completely free-for all unconference. What was needed, he said, was somewhere you could take a half baked idea, maybe show a very small amount of slides, but mainly discuss it with a group. The notion of a ‘salon’ was brought up.

To me, though, this brought to mind the atmosphere of a comedy improv, or sketch group – one where anyone could contribute an idea, and it would be quickly worked up into something (prototyped, if you will..). Half-baked ideas were celebrated. Ideas should be met with a ‘yes, and’ rather than a ‘no, but’. This doesn’t always work – sometimes when you have an idea, you want to follow that exact idea through – but this should be possible – you can follow through an idea, see what happens, but you could also let others be inspired by your idea and go off in a completely different direction. It’s all good.

So – I know there’s plenty of talented people out there. People who’ve got interesting ideas, and the ability and/or skills to help bring them to life. You don’t have to commit any time to this – just listen in, and if there’s something that takes your fancy, you can volunteer to help, in any way you see fit. Bring your ideas, too. Any and all skills are welcomed, even if you’re not a coder or designer etc. I’d expect we’ll need a mailing list, a wiki-space, and perhaps somewhere to meet up (pub?) once a month to share things.

As I say, no commitments necessary – but if you’re willing, able and interested, why don’t you join -

a Reasonably Interested Community of Hackers?

(is richlist.org or similar available??)

Anyway, there’s something about standing on the shoulders of giants, being behind/ahead of the times, collective forgetting of a movement if it’s not shared, and all that, awaiting a different post – a kind of retrospective, and perhaps needless nostalgia for those times, but for now, here’s the twenty-two links I was able to source via Twitter this evening on the subject, organised (approximately) by author – expect this to be tidied up in time:

http://www.frankieroberto.com/weblog/1621

http://www.frankieroberto.com/weblog/898

http://www.bbc.co.uk/blogs/radiolabs/2007/12/show_your_workings.shtml

http://www.bbc.co.uk/blogs/radiolabs/2008/07/some_ical_views_onto_programme.shtml

http://www.gyford.com/phil/writing/2007/10/19/bbc_programmes.php

http://www.plasticbag.org/archives/2004/06/the_new_radio_3_site_launches/

http://www.plasticbag.org/archives/2004/06/developing_a_url_structure_for_broadcast_radio_sites/

http://www.plasticbag.org/archives/2005/03/on_reinventing_radio_enhancing_onetomany_with_manytomany/

http://archive.org/details/NativeToAWebOfData

http://www.plasticbag.org/files/misc/pips_etech.pdf

http://lanyrd.com/2005/etech/sfzp/

http://www.cityofsound.com/blog/2004/07/ripples_or_the_.html

http://www.cityofsound.com/blog/2006/03/why_lost_is_gen.html

http://www.cityofsound.com/blog/2006/01/work_quick_revi.html

http://www.flickr.com/photos/mildlydiverting/tags/wireframes/

http://www.bbc.co.uk/blogs/radiolabs/2008/06/the_simple_joys_of_webscale_id.shtml

http://web.archive.org/web/20060220172755/http://www.hackdiary.com/slides/xtech2005/

http://www.fabricoffolly.com/2008/06/bbc-radio-player-happy-birthday-rip.html

http://www.fabricoffolly.com/2007/12/chat-around-tv.html

http://www.tomski.com/archive/new_archive/000063.html

http://vanirsystems.com/danielsblog/2008/02/18/semanticcamplondon-favourite-photo/

http://smethur.st/one-from-the-archive-the-programmes-manifesto

The Comedy of Design

I was impressed with what I saw, and there was a definite theme which emerged from the exhibition as a whole – that of taking a material, pushing it to its’ limits, and stretching, straining it into different shapes and uses. It almost felt that Heatherwick was researching a material, or a product, and taking it to its logical conclusion, or even an illogical one. The plank which could be disguised as furniture; the rolling bridge; the stretchy, re-mouldable furniture and carpets; the zip bag – all of these felt like magic tricks, or jokes. The equivalent of a Monty Python sketch, it really did feel like comedy, expressed in manufacturing. There’s something in that, but I’m not quite sure what, just yet. His works felt almost unashamedly futuristic, immaculately researched but also almost from a naive, playful starting point – why *not* do this with a material – again, every piece felt like it was playing a joke on the original brief – c.f. this almost Bond-villain-esque boat design. I like that.

Web Design as Art

The other thing is something that I think about every time I go to a museum. We regard sculpture, painting, music, writing, even manufacturing as works and processes of art. But when it comes to the Web, our approach is often couched in very utilitarian terms – either in that of technical prowess, or from a position of usability. Not that there’s anything wrong with either of those – but it feels like currently there’s not much consideration for web design as an art form. And by that I don’t mean interaction design or visual/screen design – those are catered for. I mean the design of webs. They shouldn’t just be functional. They can be elegant, they can be works of art, too. I’d love there to be more art based on this. I’m sure there’s been similar, looking at things from a more mathematical/theoretical point of view around networks, but why not have exhibitions devoted to great design of webs. The design of a website is so often a careful balance of technical constraints, usability and art, we should be proud of it, and make more of it. Break it free from the screen, and show the topology of different websites. Study it, learn from it – but also allow more artistic freedom in it. Is there comedy in web design, too? (and not just in ‘bad’ design, of course!)

I imagine an exhibit of a dark room, filled with laser/light-emitting objects, perhaps similar (but much less deadly) to those found in the Portal series of games. Each object represents a node of a website. Each object emits a light in the dark, which connects it to another object. Perhaps the light also spells out the semantic link. The objects fill the room, and a visitor can type in a website, and, in a short space of time, the lights reconfigure to represent the topology of that website. Perhaps even make it so people can wander amongst the links, navigating the Web – breaking the links, too – redirecting them. Make the design of the Web almost physical, but forget the screens. That would be an interesting exhibit. Reminds me, too, of Listening Post.

Perhaps the final thing to think about is the way in which we conceive of the world when we think of computers – so often we think of pixels – boxes that sit snugly against each other, and we build stuff out of them. Perhaps we need to think more about networks, and re-imagine worlds out of them.

Over the past year or so, I’ve noticed that time, as a concept, is becoming one of these whirlpools that people are being drawn to. And personally, I think there’s something really exciting that hooks them all together – it may not be a fully fleshed out thought, but it feels like the right time to get it out there and provoke further discussion. The thought – perhaps time travel really is possible – but not quite how we’d imagined it.

Firstly, though, a quick review of some of those bits and pieces that keep me coming back to this idea. As others have noted, we’re fast approaching the point where we’re not only concerned about the personal information we’re putting online in terms of privacy, but there’s also enough of it for us to want to understand it better. Call it personal informatics (as in various health tracking systems), or something like Memolane – history is becoming a big deal. I’ve written before about the ‘tyranny of breaking news’, so I’m all for something that gets us out of constantly being bombarded with the ‘new’.

One of the most interesting applications of this, in my opinion, has been the ‘Momento‘ app. Nothing revolutionary, you might think – it’s a system that brings together your activity on various social networks, and allows you to annotate ‘moments’. But the important bit for me is the elegant way in which tweets and so on are organised – by date. There’s very few applications (that I’ve encountered) that do this.

A few other, tangential projects, deal with a similar theme. James Bridle’s ‘A Ship Adrift‘ has a stationary object, the titular ship, drifting through time. And Mark Hurrell’s ‘Places I’ve Been‘ is a tumblr of photos he’s taken, with a great big dirty timestamp slap bang in the middle of the photo.

‘London, Now‘ is a live feed of Instagram photos as they come in, again, with the time/date to the fore. And finally, Ben Ward wrote a really good piece on using time as a design principle. And this, I think, is the main point – too often, time and date have been an extra piece of metadata, on the side, unloved. If we’re lucky, then it’s been used as a quiet way of navigating through archives.

What’s missing, I feel, is the idea of time as the central organising concept on the Web. Matt Sheret, in his dConstruct presentation from 2011, talked about how pocket watches and railroads conspired (not literally..) to bring about a change in the consciousness of the nation – time was becoming much more synchronised across geographical boundaries. It became a thing that you could reference, point at, and organise everything else around.

Of course, as I’ve said to anyone who’ll listen, the Web is all about pointing-at-things. And those things, I feel, can be conceptual as well as physical – this isn’t just the Internet of Things, it’s the Internet of Conceptual Things. And screens aren’t a given, either. So, why not make time addressable, point-at-able?

A couple of years back, myself, Rob Styles and Jonathan Tweed were sitting in a bar discussing our work – we were talking about the foundations for a storytelling platform at the BBC (one which is, as I speak, hopefully coming to fruition). We wanted to make the building blocks of stories point-at-able. Sure, they wouldn’t be everything that makes up a story, the Web not yet fully able to deliver the same tricks that we’ve grown used to in print, audio, images and film. But it was a start. And one of the things we discussed was – what if we didn’t just treat time as a property of an event – what if it was a first order object?

Why bother? We’ve managed to teach computers how to calculate dates and times with ease (save a mass panic over the millennium) – so why go against the grain?

The grand sage Wikipedia tells us of a philosophy of time, called Eternalism. This is the idea that time isn’t something that we are doomed to speed through, but rather that packets of time will always exist. And if there are discrete packages of time, then they can be referenced, they can be accessed. So again, this isn’t time as a property, a query string – it’s time as the main thing.

Theoretically, of course, there are holes in the idea – just as we’ve always thought of time travel into the past, via conventional means (some would say, in reality..) as pretty much impossible. But perhaps it’s possible in a conceptual, constructed manner, instead.

Make time addressable – give packets (i.e. spans of time) URIs, and then we can link to them, we can build services, applications, imaginative creations on top. Web Standard Time.

Imagine a dome, say, the size of the O2 arena, with the inside covered in flat screens. Now imagine that every Google Street View photo has been linked to a packet of time. Before entering the arena, you input details of a street, and a particular date and time. When you step in, you are completely surrounded, immersed, as if you were stepping on to that street on that day. That, is a time machine. And I think we should build one. Just to try it out.

(Thanks to Ben Bashford, Chris Sizemore, Alyson Fielding and Henry Cooke for the nudges to finally get this blog post written, and many others for the inspiration!)

So I’ve been thinking a lot about what motivates me, what gets me interested – what made me want to get involved in all this in the first place. I can code, and I have some Photoshop skills. Looking back on my childhood, I realise I’ve always been into what we’d now describe as ‘the Media’ – I was always creating newspapers and magazines; my brother and I recorded details of our lives on countless cassettes, I remember vividly compiling fictitious TV listings. I spent probably four years as a Youth Leader, creating activities and often doing, well, ‘Pervasive Gaming’, probably.

But the thing that has caught my imagination since I began full time work was always the innate feeling that there was something new to be discovered. Some new way of making something fun. At the end of the Siemens Graduate Scheme that I was fortunate enough to win a place on, I summed up my career ambition thusly: “to make a significant (positive!) contribution to the Media Industry”. Wishful thinking, I know. But it’s still a mission. And so when I discovered the simple, poetic beauty of the Semantic Web, that’s been it, for me. I know it’s not perfect, there’s a myriad of things we haven’t solved, and may never solve. But not to try them? Not to experiment? Not to create, and have fun? That would be a waste.

And so, it always comes back to job titles. Again, they are, of course, not so relevant as what you actually do. But it’s always struck me that the term ‘web designer’ has pretty much become a synonym for graphic (and possibly interaction) design of, and for screens, accessed by the Internet and the Web. Not that there’s anything wrong with that role. So much of what we call UX is incredibly important and has a rightful place in an organisation. But it’s not really web design.

As I said before, I can code. I can do entity-relationship diagrams, I can do your standard business analysis techniques. But the pleasure I seek isn’t in designing elegant code (though that does, I admit, hold some sway). Nor is it, frankly, in designing visual or interaction masterpieces – important as they are. I don’t want to design database structures, either.

What I want to do is design webs. Web. Design. That’s what I do. And I want to do it in a way that is creative, that brings Web Design in to the realms of drama, entertainment, comedy, sport. Elegant Web Design. That’s what I can do. My material is the Web. It’s URIs, it’s hyperlinks. It’s creating on the Web, just as much as creating a physical thing. So yes, that’s what I want my future to be. Someone who designs Webs – helps others to design them, and creates Webs of literature, of art. That’s me.

UPDATE: I know it’s passé, but a trawl for inspiration and direction came up with this (relatively famous) diagram by Jesse James Garrett. And you know what? The definition of Information Architecture doesn’t sound that different from the above, really:

“Information Architecture: structural design of the information space to facilitate intuitive access to content”

Anyway, onwards to the ontology itself. It’s fairly simple, once you ignore the markup. We start off by defining a number of classes, or ‘things’, that can be represented by a URI, and themselves represent an element of a comic. They are as follows:

Card - A Card is the equivalent of a Page in a paper-based comic. It can contain one or more Panels. (Note: I’m happy to change the language here, it was just the term that came to mind at the time)

Panel - A Panel is a framing device which captures some form of action or narrative within the ‘story’ of the comic.

Caption - A Caption describes the action or adds extra information to the story.

These are then broken down into sub-types:

Narrative Caption - A Narrative Caption is a Caption that contains narrative information, rather than ‘in story’ information.

Effect Caption - An Effect Caption is a Caption that contains ‘in-story’, atmospheric information, for instance sound or visual effects.

Back we go to the other elements that make up a comic:

Note - A Note is a comment or set of comments which provide extra information about the contents of a panel or balloon. (This was written mainly with the Lovelace & Babbage cartoons in mind, which make extensive use of footnotes. Other comics do likewise, from time to time, so it may well be a useful element to have in the ontology)

Link - A Link is a URL which can be attached to a Note to send the reader to a primary source. (Again, added with the Lovelace & Babbage app in mind – ideally I might not have something as generic as a ‘link’, but it is a simple construct that can easily be used)

Balloon - A Balloon is a container for dialogue within the story, be it spoken, whispered, thought or broadcast.

And now, into sub-types of Balloon:

Thought Balloon - A Thought Balloon is a container for dialogue or thoughts that are not spoken aloud by characters.

Speech Balloon - A Speech Balloon is a container for dialogue which is spoken aloud by characters.

Whisper Balloon - A Whisper Balloon is a container for dialogue which is spoken aloud, but at a reduced volume, by characters.

Exclamation Balloon - A Exclamation Balloon is a container for dialogue which is spoken aloud, but with an emphasis, for instance surprise, by characters.

Broadcast Balloon - A Broadcast Balloon is a container for dialogue which is heard by characters but delivered indirectly, for instance via radio, television etc.

So, those are all of the ‘things’ that an author has at their disposal to play with. Now come the ‘properties’ that can be used to link these things together. (I’ll ignore the domains/ranges for now)

hasPanel - A Card can have one or many Panels inside it.

onPanel - A Caption can be placed upon one more more Panels.

location - This property gives the events portrayed in a Card or Panel a location in the ‘story world’.

caption - This property allows a Card or Panel to have a Caption attached.

panelOrder - This property assigns an order to a Panel on a Card.

character - A panel can feature one or more characters.

balloon - A panel can have one or many balloons inside it.

balloonOrder - This property assigns an order to a Balloon within a Panel.

linkedBalloon - This property links one Balloon to another, e.g. to suggest they are part of the same speech.

narrative-content - This property links a narrative caption to its content.

effect-content - This property links an effect caption to its content.

speech-content - This property links a speech balloon to its content.

whisper-content - This property links a whisper balloon to its content.

thought-content - This property links a thought balloon to its content.

exclamation-content - This property links a exclamation balloon to its content.

broadcast-content - This property links a broadcast balloon to its content.

source - This property links a balloon or a caption to the character or object from which it emerges.

directed-at - This property links a balloon to a character or object being addressed in the content.

in-reply-to - This property links a balloon to another balloon which has content being referred to in the content.

has-note - This property links a balloon or panel to a explanatory or side note.

has-link - This property links a note to a URL of a primary or secondary source which provides background evidence.

note-content - This property links a note container to the contents of the note.

So, you can see, a bit of a mish-mash of classes and properties that describe the form of a comic, and some that describe the narrative within it. The hope is that at first, authors can mark-up existing comics with these elements, so that they become more findable in search engines like Google, more linkable for people blogging and tweeting (generally, more ‘point-at-able‘), and then secondly we are able to develop tools that allow authors to create comics that are truly of the Web – they may retain the same visual appearance, but their insides are made of the life-blood of the Web – URIs and hyperlinks. (Doing some mapping to the existing models I mentioned would also be helpful!)

I hope people find this ontology useful – please get in touch via Twitter if you’re interested in finding out more, want to enhance it etc. You don’t need my express permission to go ahead and use it, but it would be nice if you could a) let me know if you are, and b) give credit where due for its development.