The First Website

Twenty years ago today, CERN published a statement that made the World Wide Web freely available. To mark this anniversary, CERN – together with Mark Boulton Design – are starting a project to restore the first website and the associated assets of the World Wide Web project.

I first started using the internet in about 1988. I had a mate whose dad worked for IBM so he had an early PC connected – via the phone line – to a rather sophisticated little modem. The internet wasn’t the web back then, it was a mix of bulletin boards, rudimentary email clients and IRC. You may think that it was a primitive, but in reality, the prospect of near live discussions and collaborations with people all over the world was pretty incredible. As friends do, we lost touch, and my connection to the internet was lost with it. I did other things: failed my A-levels, learnt martial arts, chased girls, learnt the guitar and went to art college. My connection with internet picked up again in 1994. And, oh boy, was it a different place entirely. In just a few short years, the web went from idea to proposal to freely available. And the world was changed forever.

As web designers and developers, we spend a lot of time trying to explain the difference on the web. “It’s not TV, it’s certainly not print” (oh, no, it’s definitely not that). The web is its own thing. But unlike other media – ones which have physical artefacts, which get left behind to rot, to be found and stuck on a shelf in a museum – the web doesn’t have that. Pixels don’t decay, they just disappear. Forever.

Preserving our digital heritage is as important as preserving our physical heritage. There are a few people and organisations in the world who get this: The Long Now Foundation and Archive.org, to name a couple, but I’m not sure that’s enough. The need to preserve must come from our desire to learn from the past. I have two young children and I want them to experience the early web and understand how it came to be. To understand that the early web wasn’t that rudimentary but incredibly advanced in many ways. Currently, it’s impossible to do that. And, together with CERN, that’s what we’re hoping to provide.

From today, we’ve started work on the project objectives. The talented web team at CERN have already reinstated the first URL and uploaded a version of the website from about 1992. The restoration has begun.

To keep up to date on the project you can read the project blog where we’ll be posting updates on progress. You can also follow on Twitter @thefirstwebsite.

Read the announcement from CERN and two opinion pieces from Robert Cailliau and Vint Cerf

Filed under www, Design, Mark Boulton Design, Work.

Quietly working

When I passed my driving test, I had a couple of advanced driving lessons a few months after. One day I remember particularly well was when my instructor told me I had to provide a running commentary to my driving. It went like this:

“I’m currently driving at 38 miles per hour in a 40 mile an hour limit area. There is a child by the road and moderately close parked cars. I’m approaching a zebra crossing and there are no pedestrians so I’m proceeding with the flow of traffic. Up ahead there is a t-junction, so I check my mirror before slowing and approaching the junction in second gear. Indicating left. I look left and right…”

You get the idea. It’s a good exercise but I couldn’t keep it up for long – especially as someone who doesn’t really like to talk when I’m driving. The aim of the exercise was to put you firmly out of your normal driving preference and teaches you externalise your thinking and focus on your observation, rather than the physical mechanics of driving a vehicle.

Think Do Thinking

A good few years ago, I wrote about my experience with the Myers -Briggs psychometric questionnaire. Whilst the validity, and reliability, of them as a tool for assessing personality is certainly up for debate, I’ve found them useful in understanding my preferences. Probably the most useful to me is highlighting my introverted preference. To clarify: this doesn’t mean I don’t like people, overly concerned with my own thoughts or ability, or am socially outcast. What it means is I prefer – most of the time – activities which are solitary. It’s been that way my whole life. When I look back at the activities I’ve done over the years, they’ll always been solitary: martial arts, athletics (javelin), angling, using computers, drawing and painting. Now, I ride a road bike. Mostly on my own.

When I step outside of my preference – which I do all the time – it takes extraordinary amounts of energy. I’m physically and mentally drained, even if I’m having an amazing time. Simply being outside of my preference has that effect.

More does not equal better

Designing and building websites is a collaborative affair. It takes many people to build some of things we work on, and constant, close client contact is essential in doing so. But, I’d say we do it only when it’s appropriate to the best work given the people involved.

I see plenty of banner waving for collaborative working. Co-designing, pair programming, brainstorming, collaborative workshops. The overwhelming message is that these tools are better for reaching consensus, sharing work, and, ultimately, lead to better work. Well, I’m not so sure that’s the truth. Given my introverted nature, sometimes these activities can rush the process too much. They allow no time for me to think. Instead, I’m sitting there dreading the ‘tell everyone in the room what you do on this project, and a funny anecdote’ question. Yes. That still happens.

For many introverts, this is not good work. And it certainly doesn’t lead to better work.

If you’re one of those people who thrives when working in groups. Someone who gets a real kick out of developing product ideas in a brainstorm environment, or think it’s great co-writing user stories in a room of eight people, plenty of coffee and doughnuts, then great. I’m happy for you. And no doubt, you’ll end up with something you’re very happy with as you prefer to work that way. But, please, stop forcing this way of working on those of us who’d rather not under the notion it’s better.

Personally speaking, a lot of the time, I’d rather listen to what you have to say and go and have a good think.

For a great insight into the power of introverts (and how to get the best out of them), you should first watch Susan Cain’s TED talk, then buy her book.

Filed under design' 'responsive design.

UI is visible. Type is visible.

In 1955, Beatrice Warde gave a presentation to the Typographer’s Guild in London (now, the International Society of Typographic Design) which later became an essay titled: ‘The Crystal Goblet, or Printing Should Be Invisible’.

A wonderful piece of writing in which Warde describes the role of typography – or rather the role of the designer - in printing. The general premise is that good typographic design shouldn’t be seen.

When you listen to a song in a language you do not understand, part of your mind actually does fall asleep, leaving your quite separate aesthetic sensibilities to enjoy themselves unimpeded by your reasoning faculties. The fine arts do that; but that is not the purpose of printing. Type well used is invisible as type, just as the perfect talking voice is the unnoticed vehicle for the transmission of words, ideas.

Let’s take that last point. Morgan Freeman has a memorable, wonderful speaking voice. One that adds colour and weight to the words. His words are not just audible, and understandable, but they are rich with personality. His voice adds to the words he speaks.

I disagree with Warde. Type should not always be invisible, it should be appropriate. Sometimes, it’s a typeface’s job to be overt, loud and suggestive, in order to communicate the content in the best way. But, yes, sometimes typography has to melt away into the background. To support the content and the reader. To help them.

On the web, because we’re quite often presented with long-form text (and by that, I mean more than a few paragraphs), we get a little obsessed with body copy. Good typesetting of body copy should be like that of setting a novel; the type should disappear. But, not all typography is body copy, and to consider it in these narrow terms is to do the practice of typographic design a huge disfavour.

Whenever we design with words, we’re designing with type. And words are not always long form paragraphs designed to be very easy on the eye. Sometimes it’s a logotype, a button, a richly designed layout, a data table or form. The application of typographic design is just so broad that to say it all has to be invisible is to imply the goals of typographic design are the same across the board.

Legibility is a baseline requirement for typesetting anything. It’s like edible food. It shouldn’t really be a measure of what is good or not. Just like audibility and comprehension are baseline requirements for speech. There is more flavour in words; spoken or printed. There is more flavour in type, that if applied well, transcends content from being merely legible, to that of being pleasurable. After all, that’s why we have different typefaces: each brings with it characteristics that flavour the words.

Nick Cox says in his article, ‘Typography should be visible’:

In my opinion, there is merit to visible typography because in the hands of a competent typographer, a text can truly sing. Not because they have left their mark out, but because they have worked their art on the words.

I agree which him completely. It’s the difference between something edible and exquisite. The difference between average and better. Which is why all this invisible, reductionist UI approach is starting to grate on me a little because it suggests we have the same goal for all our work; to make it invisible. It’s more complex than that. It’s an over-simplistic measure of success that is put far more eloquently than in this post from Timo Arnall.

Of course, I say all of this under the one big caveat that, in typography, there are no rules. Just good decisions. But, let’s make some decisions shall we? Not make everything invisible because, apparently, that’s the way it should be.

Filed under Typography, Design, Invisible design, Critical thinking.

ATLAS

Eighteen months ago, I blogged that we’d started working with CERN on redesigning their site. A dream project for me. And one that is in its final chapters as the site went live last week. But, as with all great stories, as one chapter draws to a close, another starts.

This week I’m at CERN in Geneva, but I’m not working for CERN. Mark Boulton Design has been asked by ATLAS to help them redesign their public website. It’s another dream project.

ATLAS is a collaboration of three thousand physicists, engineers, computer scientists and support staff, in forty countries, in one hundred and seventy institutions from around the world. One big scientific melting pot, who have built one of the most complex machines known to man which is connected to the Large Hadron Collider. They’re one of two experiments to independently observe a particle that behaves consistently with the Higgs Boson. In other words, whilst they share similarities with CERN, they’re actually quite different.

I’m thrilled to be working with such a progressive, interesting group of some of the smartest people on the planet, working on some of the most historically important work that humans have ever done.

Filed under Mark Boulton Design, ATLAS.

CERN

Last week, CERN quietly redirected their URL to the new site. And Mark Boulton Design and the CERN project team saw the chapter close on nearly two years of work.

There is much to talk about with a project of this scale. Probably the first thing to say is that this was not a website redesign project. The project started with the very simple statement: ‘we have a content problem’. I’d like to think it’s a problem we solved, but it also went much deeper than that.

Community

CERN is an organisation that supports collaboration. In fact, CERN is comprised of many collaborations; more community than organisation. We have a bit of experience designing with communities, and the teeth we cut with the Drupal community came in very useful here.

As we all know, the question ‘why wasn’t I consulted?’ can derail almost any endeavour. This was no exception. So, early on in 2011, the Mark Boulton Design team spent months talking and listening. In fact, the majority of our first six months on the project was spent trying to understand CERN’s audience – both internal and external – and what CERN does for them.

As in 2008 and 2009, when we worked with the Drupal community, designing for community relies on one thing: listening for trends. Design by committee doesn’t work because there are relatively few stakeholders and sometimes with big egos. Design by community works because of the sheer numbers and relatively flat hierarchy. Instead of ensuring the boss is consulted, it’s more important to consult with just two types of people: those who have influence, and those who have a big mouth. Get both of them on-side, and your job will be easier.

Content

CERN started with a content problem. To really understand how content was to be reorganised, rewritten, and – in some cases – deleted altogether, we needed a plan. Not only that, we needed to understand how this content was being consumed and where. We needed a content strategy.

We embarked on a good few months of content research – audits, interviewing, process-audits and the like – before producing a strategy that sat alongside a new Communications strategy from the CERN comms team. Together, these would redefine how content is created and managed at CERN, and how it gets published to the web.

The new content for CERN is Future Friendly. It’s adaptive – meaning it’s carefully chunked into small fields in the CMS and tagged with really great meta data so it’s able to shift and flex into different containers. No WYSIWYG here. Just really smart, well-structured – and reusable – content.

Research

To my mind, good design decisions rely on good research. And for this project, we had some great research throughout. A broad amount of data was gathered by various means and filtered down to the design and product team. Not by way of reports and documents, though. In my experience, these often get cast aside. No, in our team we had Emma embedded with the design team. Always present with up-to-date insights into the audience needs so that she could literally sit beside us to help us guide some of the design decisions.

But it’s not just for us.

CERN now has detailed information about their users available for anyone who creates a website, or writes for the web, at CERN.

Design strategy

I’ve written about the design strategy for CERN before. How the content needed to inspire, educate and inform the various audiences of the website, but we needed a simple model in order to map the content and the subsequent presentation of the content. Our Make Mantra – Create Wonder – was born, and is still used today as way of gauging how content is to be created and presented.

Practically, we did a lot of prototyping and very little else. Prototypes became the way we experimented with concepts, discussed and communicated ideas, worked on responsive elements. These prototypes then quickly moved from static HTML into dynamic lo-fi Drupal prototypes. This was so editors could get writing content quickly – actually using the tools they would eventually use on the site. All the while, we were continuing to iterate. In all, I think there were 5 or 6 alpha releases, 8 betas and many, many pre-alpha prototypes.

Drupal

The new CERN public website runs on Drupal 7 (the most recent version of Drupal, that we designed the UX and UI for). It’s mostly an out-of-the-box installation with a few bespoke modules that integrate with internal services such as CDS (CERN’s media server) and Indico (the event management database).

Team

I don’t often do it, but this is the bit where I get to gush a little. The people involved in the project is pretty epic. But, there was a core team of designers, developers, product leads, researchers, content strategists and journalists that deserve a mention. Without them, this project would not have turned out the way it did.

Mark Boulton Design

• Nathan Ford: Creative direction, Design
• Emma Boulton: Research lead
• Alex Morris: UX
• Jo Brewer: Project management
• Jen Simmons: Drupal theming / Front end development
• Relly Annett-Baker: Content Strategy
• Andrew Travers: Research
• Yours truly: Design strategy, Creative Direction
• Mark Boulton Design team: Nicola Jones, Nick Boulton, Colin Kersley & Jan Colyer.

CERN

• Dan Noyes: Project lead
• Silvia Tomanin: Drupal development
• Cian o’luanaigh: Editor
• James Gillies: Department head, project sponsor

Such a smart team. There are of course countless others – probably hundreds of people – I could thank. But, this isn’t the Academy Awards. If you helped, you know who you are, and I’m very grateful.

A special project

This project always was a bit different. CERN is a special place, yes, but it takes a degree of risk and subsequent trust for an organisation of this scale to work with an external company for such a length of time. CERN invested time and energy to work with us at Mark Boulton Design. When we suggested radical changes to process due to our research findings – things that have had disruptive effect on the communications of the organisation – they didn’t flinch. They knew it was the right thing to do. And supported us in our proposals. That takes a very special type of client; one that is willing to truly partner with a design company. And, I’d like to think the results speak for themselves.

Not just a website

When I reflect on the past two years work on this project, it’s easy to think of it as ‘bloody hell, that’s a long time to make a website’. Well, yes, it is if that’s all we did. But, in the words of James Gillies, Head of CERN communications team and project sponsor:

The launch will mark a significant change in how the Organization facilitates communications within the CERN community, as well as how it presents itself to the world. The first thing that you will notice is that the website looks different, but the most significant changes run deeper, and they form the basis for a new communications architecture.

He goes on to say:

There are many ways we could have chosen to build the new CERN website. We could have asked designers to create something beautiful. We could have created a template for content. Or we could have tweaked our existing websites. Instead, we went back to basics and reflected on who we want to reach and what their needs are. Then we asked them to help us. All our stakeholders have had an opportunity to influence our new website, and many of you have taken that opportunity. We have conducted regular audience research through online polling, usability testing, and in-depth one-on-one interviews, receiving feedback and input from thousands of users. I would like to thank everyone who got involved: your feedback has directly shaped many of the design decisions and turned this into a real community effort.

You see, it wasn’t just a web site. It was helping CERN understand who they’re talking to, what they’re saying, and how to say it. Then, giving them the means to do it.

You can read more about the CERN launch from James Gillies.

Filed under design' 'process.

The In-Between

Breakpoints. Break. Points. Points at which things break in your design.

But, at what point did they start becoming ‘the point at which I will create a new layout entirely’, or ‘the point at which I introduce a new canvas’. What started out as a method to optimise your designs for various screen widths has turned, ever so slowly, into multiple canvas design. We’re creating pages again, and we probably need to stop it.

A breakpoint should not necessarily be a point at which we wholesale swap out to another layout. It can be – and I think there are good reasons to make some of those big, macro changes to grid system or navigation patterns. BUT, I think we’re missing a trick for using breakpoints to make lots of subtle design optimisations.

Jared Spool said in his recent article strategy for responsive design

A responsive design can have multiple breakpoints, say for a small-screen phone, then a large-screen phone, then a tablet, then a laptop/desktop. Many teams try to decide on breakpoints using average screen sizes.

However, it’s better to look at what the content and navigation wants to be. By letting the content and navigation drive the breakpoints, teams find they can often get away with fewer screen configurations. For example, a high-resolution Retina iPad might easily share the same configuration as a well-constructed laptop display, while lower resolution tablets might just need a little adjustment to that same configuration.

Our experience at Mark Boulton Design is that we can actually tend towards more breakpoints than fewer if we take the approach of optimisation rather than a device-centric, display-size approach. We’re moving towards including all media-queries in-line in the CSS, rather than abstracting them into their own 480.css file, and we keep the big macro-layout changes in the Gridset CSS. But, interestingly, what we’re seeing is we have less styles associated with more breakpoints as we’re not creating a whole slew of different, fixed layouts and all that goes with that.

‘But, what is content-out design?’

I first discussed the idea of content-out design in the context of a page. A page with edges that is used to define an aesthetically pleasing layout within. On the web – especially the responsive web – we don’t have edges, so it’s best to define your layout from your content. But – and I get asked this a lot – what does that actually mean in practice?

Firstly, it means defining your grids (your big macro break-points, and the columns and what-not) from actual content and not from devices or screen widths. This could be the size of an image, or an ad-unit, or the typographic measure. Just some ‘fixed’ constraint. This will give you your grids.

As you’re building out your responsive design, you should be focussed on watching how the content adapts as the viewport changes. Somethings I look out for:

• Type size and leading. Does it need to change?
• White space (macro and micro). Do you need to adjust margins and padding?
• Vertical space. Do you need to reduce it and make the content more or less dense?
• Flow. How is the readers eye movement going to change as you change these elements?
• Words. Are there now too many on one line? Or too few?
• Source order. Are the right things in the right place?

Focus on the in-between

Content-out design means defining your underpinning design structure from your content, and then focusing on what happens in between ‘layouts’. This approach of optimising your design by adding media queries (I like to call these optimisation points than break points, because nothing is broken without them, just better), means you are always looking at your content as you’re working. You become more aware of the micro-details of how the content behaves in a fluid context because your focus shifts from controlling the design in the form of pages, to one of guiding the design between pages.

For more reading on this, have a look at ‘There is no breakpoint’ by Ben Callahan in which he details optimisation points in a little more technical detail.

Things are a changin’

I find this period of change we’re in right now fascinating. Not only is centuries old design theory being rewritten, but the process of how design happens is changing too. It’s becoming more collaborative, more fluid, lower fidelity. Less about being squirrelled away in a dark corner crafting a beautiful thing, and more about scribbling away in public and repeatedly throwing our work in a big trash can. And the more we’re doing that, the better we’re getting.

Optimisation points are just one way we can start thinking content-out. And thinking content-out is what we need to be doing to create truly native experiences on the web – wherever the web is.

Filed under design' 'responsive design.

Change your mind

My four year old daughter attends a rural primary school in the Vale of Glamorgan in Wales. The school performs in the top 3% in Wales. Consistently. It’s over-subscribed with waiting lists to attend. The head teacher greets every pupil – by name – at the school gates in the morning. She even knows my name. It’s a school you feel part of. And the government wants to close it.

We learnt this week that, as parts of plans to change catchment areas for secondary schools, that my daughter’s wonderful school is in a list of a few schools that are pencilled in for closure. The pupils will be sent to other, under-performing, under-subscribed, urban schools. We have a small window to fight these changes, but it seems that once this process gets started, it’s difficult to reverse.

When I picked my daughter up yesterday, she told that the head teacher had told them in assembly that everyone is going to fight for their school. That mummy’s and daddy’s should write letters, they should too, and we should make posters. A wonderfully simple attitude to a dreadful situation. I gave her a hug.

As soon as we got through the house door, my daughter went straight to her desk and asked me if she could write a letter to the men in charge. This is it:

Change. I love my school. Please don’t close it. Change your mind. Love, Alys Boulton.

This is what the men in suits don’t see. They don’t have to sit there and explain it to a four year old that thinks it’s all going to be stopped with a couple of posters. They don’t think about the illogical idiocy of closing a top, over-subscribed primary school. They think about numbers and averages. They don’t think about rural communities, or try to understand why this school is doing so well. No. Thinking about averages leads to average. And who wants that?

So, we’re going to fight. With every last breath, I’m sure this school is not going down without a fight.

Filed under personal.

Design is veneer

On the run up to Christmas, that wonderful annual advent calendar 24 Ways published an article called: How to make your site look half decent in half an hour . In some designer quarters, this was jumped upon as a load of unconsidered twaddle written by a developer who shouldn’t be dishing out design tips. Aral Balkan took this task and has written a great article that follows my thinking as to what ‘design’ is. All good. But, I’d like to comment on what I thought that 24 Ways article was about, and really the indication of a perception of design across web professionals.

For the past few years, I’ve been teaching a workshop based on my book, Designing for the web, to lots of web people, but mostly to developers, front-end devs, UX folk and project managers. All of them have come along to the workshop to learn just one thing:

‘How do I make this thing I’ve done look less shitty?’

Now, if you’ve read my book, or my blog for a while, you’ll know that I see design as a holistic practice; a practice of understanding content, of audience needs and goals, of brand, of psychology, and, of making things look less shitty. As much as designers would like to think we’re the guardians of all things considered practice, taste, and learned process. We’re really not. Some of the best designers i’ve worked with have embraced the passionate learning of students and amateurs. People who are not interested in becoming professional designers, but want just enough knowledge about an aspect of design to make their thing better: be it their resume, their website or their father’s cafe menu.

Getting stuck in

There is nothing wrong with getting stuck in. I’m not a carpenter, but I’ll get stuck in and learn and renovate my bathroom. I’m not a bike mechanic, but I’ll learn enough to maintain my road bike. I’m not a developer, but I’ll hack around with a bit of PHP to get to where I need to be. Many people would not class themselves as designers, but they can arm themselves with techniques to make themselves better at an aspect or technique of design.

There are many ways to Define The Damn Thing, but for me, design is really just the result of a bunch of questions and answers. These questions may be asked by the materials you’re working with, the constraints of the project, or the audience you’re designing for. They may be big questions such as ‘how can we increase quarterly revenue by redesigning this checkout procedure?’ Or, they may just be small questions like: ‘how can I make this content just look a little less shitty?’. These are both equally valid questions.

The answers to these questions are design. Some answers are big. Some are difficult. Some seem like magic. But most, in my experience, are well-trodden cowpaths of practiced techniques. Simple little things we do to make less shitty things.

So, design is veneer. But Aral is right, it’s not just veneer. Even if you wanted it to be, visual design is not a thing, and we should be mindful to not present it as such. But that’s not to say we shouldn’t help people who aren’t designers make less shitty things by giving them a few hints and tips along the way.

Filed under design.

Sparkicons and the humble Hyperlink

The humble hyperlink is an incredibly simple, powerful tool on the web. In fact, many would say that our ability to link one resource to another via hypertext is what makes the web what it is. But, I think this humble link could do a little more than it currently does.

What’s the problem with links?

When the web was invented, the hyperlink linked resources together. That hasn’t changed. What has changed is the type of resource that may be linked. In the early days of the web, resources were documents of text. They then changed to images or tables of data within text, but it was still text. Now, an html document is still the resource, but the primary piece of content maybe something completely different: video, audio, a download to a file, it may be secure. A link may trigger an action along with linking, such as going fullscreen, a pop up, or linking to another site. All of these things are valid links, but we have just one element with a bunch of attributes in the code to describe them. I’m not so sure it’s enough any more.

What do I get when I get there?

Here’s a link to some content

It’s correctly marked up in the HTML, but perhaps badly framed editorially. You, as the reader, do not know what that destination is until you click it. ‘Just make the link text better’, you may be saying. Ok, how about this:

Here’s a great article about cats

That’s better. It’s implying a link to an article. The meta data for the user expectation of this content is in the content itself. But, we can’t always rely on our content creators to reliably do this. And what if the content was more complex, like a report:

Read our annual report

Is this a link to a web page, a PDF, a word file, a link to download an app from the app store? What is this?

And that’s the issue. I’d like to know what I’m getting before I click it. I think we need more meta data around our hyperlinks that can give us more of an indication what we’re getting before we get it. I became painfully aware of this just a couple of days ago when I clicked a link and started downloading an HD video, over Edge, that started auto playing. Luckily I wasn’t on data roaming at the time.

How can we give more meta data with our links?

There could be a few ways we could do this. Obviously, we could just write the type of link, destination and other stuff in the content. But, if that destination changes somehow, that’s an added overhead for the content creator. Plus, you could end up with quite verbose link texts.

We could use the <type> attribute introduced in HTML5 to specify the Media type (formally MIME type) of the linked document. This is exactly what we should be doing, actually, but the options don’t necessarily map to our content needs, or provide all of the content type requirements. For example, I may want to link to a video, as that’s what I want the reader to watch, but the HTML resource is not a video at all, but a video embedded in an HTML page with a whole bunch of other things. In that case, the <type> attribute would be inappropriate. The same could be said for audio, or any other primary content that is embedded within an HTML document.

I feel we need two things: some visual affordance for the user that they’re going to a particular type of content; and this affordance is rendered through an attribute, or something similar, in the HTML of the link.

We’re already doing this. Sort of.

In designing around this problem, I’ve noticed through my research that we’re already doing this. We already have conventions used on sites like Wikipedia, and others, for indicating, after a link, what will happen when you click it. Here’s are two examples from the BBC and Wikipedia.

Typically done with CSS or Javascript and it just includes an icon after the link. But, that’s it.

The thing is both of these examples use the icons to append list items. They’re not in paragraphs immediately following the link wherever that link may be.

Sparklines

Like Jeremy, I like Sparklines a lot, too. Edward Tufte describes them as:

…a small intense, simple, word-sized graphic with typographic resolution.

Sparklines are efficient representations of complex data that typically sit within content to provide additional semantic value to the content. They’re a small hit of additional information. A picture speaking a good few words.

And I think he’s onto something there and it’s something we could use for this problem.

Sparkicons

What would it be like to expand on what we have now? How could we provide more meta data – where appropriate – than just an icon as demonstrated on Wikipedia and the BBC.

What we could do, is include some more information, for quick visual digestion, alongside an icon. We could take Tufte’s Sparkline rationale and apply it to this small, inline iconography. We could use a Sparkicon.

I’m defining a Sparkicon as a small, inline icon with additional link meta data to describe either the content and/or the behaviour when the user clicks the link.

I’ve looked a couple of examples of how this might work. The first example shows two icons to indicate behaviour when we click the link. The first is a full screen icon, the second is one we already know: an ‘external site’ link.

The second set of examples are icons for particular content or media types: comments and video. The comments includes a count of existing comments attached to the link document. The video spark icon includes a video duration. This could also include things like aspect ratio, or HD, or whatnot.

Degrading the reading experience?

I think the challenge with sparkicons would be to give enough feedback to the user to let them know what’s going to happen, or where they’re going to go, or download and what are the consequences of clicking this link. That’s the important thing, and history tells us we can’t rely on the words to do that.

But we also need to be mindful how much of an interruption this will be to the ebb and flow of reading long form content. Also, how much added visual noise would this add? At this point, I just don’t know, but I plan on putting this to test soon on a couple of projects: both personal and professional.

There are plenty of challenges, particularly how this could just be some kind of applied graphics through a simple addition to a link attribute. Standardisation is also an issue – this type of icon would be only really useful if it’s a shared convention.

But, it’s just an idea right now that i’m plugging away at. More to come.

Filed under design.

Abstractions After The Fact

Pattern primers, style guides, pattern libraries. They’re all the rage. And they make good sense, but I think we’re in danger of working back to front.

At Mark Boulton Design we get quite a few project enquiries and over the past twelve months we’ve seen an increase in requests for these repositories as a project delivery. This is just fine for us, as we tend to propose them anyway in some form or other to document our work. But there is an inherent concern in delivering this type of thing to a client. When is it done? And how is it created? And making sure that is discussed with a client, in depth.

My first exposure to style guides was through print and branding. Corporate style guides are rules of execution; position this logo like this, use these colours, this type, crop photos this way. Adherence to the guide is critical and there’s always someone policing them. Having been involved in the creation of a few of these printed style guides, they are always designed after a body of work and then – almost without exception – never updated to reflect slight organic changes as a brand or design system grows. This is why digital style guides are good. They allow growth.

I’ve read recently that some designers are starting with patterns. Taking small modularised chunks of content and then compiling for display in different circumstances. This, of course, if great for taking an adaptive content approach. Thinking of our content in small chunks is useful. But, I can’t help but thinking that approaching design in this way is a folly and will result in generic, cookie cutter work.

When to abstract?

DHH from 37signals wrote a great post recently about the abstraction of code and when it should be done.

Future coding is a lot like playing the roulette. If you can guess where the requirements of tomorrow will land today, you’ve just scored the ultimate programmer’s prize: looking like a wizard. You saw the future and you were right! High five, brain!

That’s the almost irresistible draw of “flexibility”—often just a euphemism for building half or whole features before you know how they’re supposed to work or whether you need them. Just like in Vegas, the worst thing that can happen is to be right about this once in a while.

And that’s exactly how I feel about creating style guides. There’s a lot of talk about us designing systems for the web. Well, sometimes, we’re not designing systems at all. We’re designing a couple of pages for a marketing web site. Creating a whole pattern library for a project like that is not only overkill, but completely inappropriate.

But the same can be said for a large scale project too. If you don’t know what the patterns are, you could be abstracting too early – bowing to the lure of future flexibility.

I guess it’s a question of balance, and one I’m becoming acutely aware of recently. For me, style guides are still there to document a design system. But they’re not a tool kit of parts. Before you design a tool, you have to know what to fix first.

Filed under design.