Blog Category: 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?
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:
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:
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.
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.
…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.
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.
Updates: Joe Gooden pointed out on Twitter that this of course is of particular importance on touch devices where we do not have the benefit of hover interactions (such as Alt text reveals), and status bar
Abstractions After The Fact
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.
A New Canon
The evolution of the grid from geometric form and canons of page construction is quite clear. In no other period of history was the grid used as a core aesthetic as was in the 1950s and 60s where it emerged – almost simultaneously – from several design schools in Europe. From then, the grid system’s influence has been pervasive.
Today, the grid is viewed by many designers with equal amounts of distain and fervore. Its detractors – and there are many – claim a grid system is visual straight-jacket, designed to inhibit creativity and that using one produces dull work. Of course, I think that’s rubbish; there are no bad grids, just bad designers. In the hands of a competent designer, a well-constructed, considered grid system is the frame on which the fabric of the design is hung. It should create balance, provide landmarks and visual cues. It should allow the designer to exercise just the right amount of creativity and provide immediate answers to layout problems.
For the past 800 years, the printed page has been constructed in pretty much the same way; from the edges. The desire to create the most aesthetically pleasing book always starts with the size of the physical page. That page is subdivided to give us the optimum place to put our text and images.
Fast-forward 800 or so years to 1997.
The web is just about hitting the mainstream. I was working as a junior designer in a small firm in Manchester, UK. Typically, as the young guy in the studio, it was my job to create the websites for clients whilst the ‘serious’ designers looked after the large fee-paying clients on their branding, print design and advertising and what not. Remember, this is the early days of the web.
Designers who were exclusively designing for medium back then were doing what they knew; applying the rules of print design to the screen. We used tables for layout, shim-gifs and all manner of terrible ways to achieve our goal of ordered, controlled layout. And it drove us all crazy. And you know what? Despite all the great progress made in the last 15 years – web standards, inclusive design, UX, semantic thinking etc. – when you really think about it, as designers we haven’t really grown that much. Or rather, we’re still trying to force what we know into a medium that it doesn’t quite fit. Our practice of creating designs for the web is still mired in the great thinking that was done over the last 800 years. But who can blame us? 800 years of baggage is hard to get rid of! But that’s what we need to start doing; we need to start thinking in a new, and different way.
‘There is no spoon’
For print design, the ‘page’ is the starting point for creating your layout. The proportions define the grid within. The content is bound the book for pleasing effect. The ratio of the page is repeated in the smaller bodies of text for a feeling of connectedness when the reader moves from one page to another. For print design, the process of designing grids, and the layouts that sit on top of them, is a process with one fixed and knowable constraint: the Page. On the web, however, there is no page.
Consider the browser for a moment. The browser is a flexible window into the web. It grows and shrinks to the users screen size. The user can move it, stretch it, scroll it. The edges are not fixed. It is not a page, but a viewport.
Let us pop back to 1997 again. I’ve just been asked to design a website for a new art & architecture gallery in Manchester. The project is an exciting one, with some great potential for some really creative design and layout work. Typographically, it was a bit of a dream project. I’d been involved in the branding, the logotype design and the design work for the publications. I’d designed a grid system that would work across all of the media from flyers to signage – a kind of universal grid with the proportions of the logo as its starting point.
The time came when I had to knuckle down and design the web site. I started the design, as I usually did, on paper. Then Photoshop. Then Dreamweaver (trying to avoid looking at the code it produced – not because I was purist, but because it scared me to death!). The website design I created was based on a fixed width, fixed height modular grid. It had it all: ambiguous navigation, hidden content, images instead of text, all created with tables. It was cutting edge. But I know now, I hadn’t created a website, I’d created a brochure that happened to be on screen. I knew then, as I do know, that it was wrong. What I’d created had no place on screen at all – the wrong design for the medium. Instead of trying to understand the web, and the browser, I’d taken my existing thinking and shoe-horned my controlled design into it.
Now, let me ask you a question. If you replace Photoshop with Fireworks, Dreamweaver with Textmate, and tables for layout with Web Standards, how many of you are still designing this way? How many of you are still thinking of pages and edges? It’s ok. I am still, too.
800 years of baggage is hard to shed. There’s a lot of engrained thinking. Thinking that is, in fact, really great design and compositional theory. But, because of the attachment to the fixed page, we’ve not accepted the web for what it really is: fluid, chaotic, unordered, open. On the web, there is no page.
If there’s no page, no thing with edges, then how can we begin to define a grid? One of the goals – as described by Jan Tschichold – was to create a layout that is bound to the book. How can we bind anything on the web if there is no page from which to start? I propose we stop trying to find the browser’s edge. We stop trying to create a page where there isn’t one, and we welcome what makes the web, weblike: fluidity. We start creating the connectedness Tschichold talked about by looking at what is knowable; our content.
It has been said that as web designers, we’re not designing around content, but rather we’re designing places for content to flow into. Particularly in large organisations, it was commonplace for designers not to know what the content is, or would be, but rather, at best, they’d have some idea of how the content would break down. At worst, they wouldn’t have a clue and basically guess. ‘Oh, this is an article page, so it must have a bunch of headings, some body copy, some lists’. Feel familiar?
Separation of content and presentation is the mantra of the Web Standards movement. So you may think this disconnect started when the web standards movement was in full flow, but it started way before then. I look back at when I worked in web design agencies in the early 2000’s and, as a designer, I was off in my little corner designing the three templates that the client was paying for, and that the Information Architect had defined. I had wireframes of these exemplar templates and was pretty much following them the number. What I was doing was designing in the dark. I had my blinkers on. I had no idea what the content would be in 6 months, 1 year, 2 years time. In fact, I’m pretty sure the client didn’t, either.
What I was doing was designing a box. A straight-edged, inflexible box that couldn’t grow with the content as it didn’t take into account existing graphical assets, either. Thankfully, skip 10 years to the present day and things are getting better. We have content strategy. We have a relatively mature UX industry. As designers, we’re in a much better position to know, not just what the content will be right now, but what it will be in 1,2 ,3 years time. Now we have this knowledge, we can use it to our advantage: by using it to create our grid system.
A NEW CANON
I’ve talked about baggage. Hundreds of years of thinking in the same way: canvas-in. We’ve taken grid design theory from the world of the physical page and tried to make work in a medium where there are pages with no edges. A medium where the user is able to manipulate the viewport. Where context matters – is the reader sitting at the TV, a desk, using an iPad or hurredley walking from one meeting to another snatching some news on the way on their mobile device. Where do we begin to design on these shifting sands and still retain the reason for using a grid system? Before I get on to that, let’s remind ourselves what those reasons are:
Creates connectedness Grid systems help connect or disconnect content. They help people read and aid comprehension by chunking together similar types of content, or by regular positioning of content, they can help people navigate the content. Connectedness helps brands tell a consistent story in layout.
Help solve layout problems We all need answers to layout problems. How wide should a table be? What should the whitespace be around this boxout? Grid systems help us with that with predefined alignment points.
Provides visual pathways for the readers eye to follow A well-designed grid system will help use whitespace dynamically and in a powerful way. By filling a space with negative space instead of content, we can force the direction of the readers eye more effectively than anything else.
As with the printed word, the word on screen would benefit from some rules of form; a new canon of page construction for the web. A way of constructing harmonious layouts that is true to the nature of the web, and doesn’t try to take constraints from one medium into another. That starts with the content and works out, instead of an imaginary fixed page and working inwards. I’m going to repeat that, because it’s important: we start with the content and work out. Instead of starting with an imaginary fixed page and work in.
The new canon can be best described as an approach. A series of guidelines, rather than a single diagram to be applied to all. This first part of the canon are a series of design principles to adhere to. These design principles were created to provide a simple thought framework, an Idea Space; a set of guiding principles to be creative with.
Define a relationships from your content. If none exist, create some. A grid for the web should be defined by the content, not the edge of an imaginary page. Look to your content to find fixed sizes. These could be elements of content that is out of your control: syndicated content, advertising units, video or, more commonly, legacy content (usually images). If none of those exist, you must define some. Make some up. You have to start somewhere, and by doing it at a content level means you are drawing content and presentation closer together.
Use ratios or relational measurements above fixed measurements. Ratios and relational measurements such as pixels of percentages can change size. Fixed measurements, like pixels, can’t.
Bind the content to the device. Use CSS media queries, and techniques such as responsive web design, to create layouts that respond to the viewport. Be sympathetic to the not only the viewport, but to the context of use. For example, a grid system designed for a small screen should be different to that intended to be viewed on a laptop.
By using these principles to design to, we’re drawing closer relationships between our layout, content and device. Tschichold would be proud.
– This blog post is an excerpt from my upcoming book on designing grid systems for the web, published by Five Simple Steps.
CSS Spreadsheets, er, I mean Grids
Today, the working draft of the CSS Grid Layout module was published.
I wrote about this last year voicing my concerns that the proposals do not match a designer’s mental model of how grids – and subsequent layouts – are constructed, and the historical terminology. I wrote an open letter to to the W3C CSS working group, too:
In reference to: http://dev.w3.org/csswg/css3-grid-layout/#core-concepts-of-the-grid
I’m confused as to the need to invent new terminology with regards to grids that have existed for centuries. I’m also a little concerned that the mental model this terminology builds is one more similar to tables and spreadsheets (where these terms could be interchangeable) than to grids and layout.
Specifically on the terminology:
- Grid Lines are known as Gutters.
- Grid Cells are known as Modules (or Units – the term is interchangeable). They represent the smallest building block of the grid.
- Combinations of modules vertically are Columns if they run the full height of the grid.
- Combinations of modules horizontally are Rows if they run the full width of the grid
- Combinations of modules both vertically and horizontally are Fields.
There’s a lot of great stuff in this draft, but some of the theory of designing grids has been around for centuries. If we could start to align CSS with existing terminology, and existing mental models of how layout is designed, then all the better.
Just a thought…
For more information on this, I wrote a blog post last year that expands on some of this thinking.
Thanks for your time and consideration, Mark Boulton
A number of people replied from the group, but a few notable points were discussed:
Tab Atkins responded by saying:
We’re killing grid lines, but more importantly, the grid concept of “gutters” will be added properly, so you can actually have separation between grid cells. (Right now, “grid lines” are just an alternate placement mode - you can place items by their edges rather than by the cells you want them in.)
Which I was pleased to see, but dismayed to see today – a year later – that it was still in the draft. This doesn’t address my concerns over terminology. Basically engineers inventing words for things that have been called something else for, oh, maybe a hundred years.
Bert Bos then replied, beginning with a sweeping statement:
Mark. I think our terminology is based on table terminology (rows, columns and cells) on purpose. Just about everybody is familiar with tables, so building on that shared knowledge makes sense.
I’m not so sure about that. Yes, everyone understands tables because we hacked them for layout in the bad old days. We’ve spent a decade unlearning that only to replace layout with the same broken mental model? Designers understand grids. We understand the terminology, and it’s really not that difficult for other people to learn it, too. I know, I’ve taught them.
Bert went on to discuss my proposal for a better way to do things – more aligned with how designers think about grids, and how we might unite development and theory that’s been around for ages.
And then the discussion pretty much stopped. And it seems the underlying theory of this proposal is still built on nothing more than “people understand tables, so we think this makes sense”. May as well say, “well, people understand spreadsheets, so we’re doing it like this”. If the W3C adopted this stance when they first looked at proposing basic typography for the web, then we’d be in a world of ‘line spacing’ with no ‘ems’ or ‘ens’. But they didn’t! They adopted – largely – good typographic terminology and theory. What happened? And why does layout and grids have to be any different?
There are other issues, too. The proposal combines the idea of layout with the underlying foundation of a grid. To my mind, that’s just confusing. Like separating content from presentation – one of the fundamental principles on which web standards is built – applies to grid design, too. Grids should be abstracted from layout – they facilitate layout, but combining the two words is just potentially confusing for me.
I think there is an opportunity to get this right. The typographic control we have in browsers is generally built on existing, good typographic design theory. There is no reason why layout and grids shouldn’t be either.
Mr Katzmarzyk was my art teacher in high school. A fresh-faced man in his 40’s, he was a pivotal influence on me learning some of the craft of art and design I still use today. He taught me 3-point perspective, pencil techniques like cross-hatching, colour theory, how to see tone and line. But the single most important lessons he taught me – back in 1984 – was to be patient with my work, to discard first ideas, and to look at my work with a view to removing, rather than to adding. Pretty heavy lessons for an 11 year old. But they stuck fast. He would have me redraw and redraw the same still life study, not with a view of perfecting, but to explore the subject and the way I was representing it. Every time, the drawing was more simple, elegant and efficient.
He also taught me about noise. Noise in my work, noise in my technique. He described efficiency of thought and process in a way my child-like brain could grasp. He taught me that by doing less, we can get to something in our work so much more appealing. And that underpinning concept is something that I realised only recently I refer to almost every day. It’s in my design DNA. I can still smell the power paint as he told me:
“Doing more is easier than doing less”.
And that’s it.
When someone hires me for my work, they’re not paying me for what I give them. They’re paying for what I don’t give them: the iteration, the obvious ideas, the sub-optimal solutions, the years of experience, the learning I do. They’re paying me to make mistakes, to produce work that isn’t quite right so I can get to right. I rarely get to right first time.
I may produce more quantity of work this way, but the end result is always less than when I started. More simple, elegant, efficient.
When designing a user interface ask yourself not ‘what does this need?’, but ‘what can this do without?’. As Brendan Dawes says: ‘Boil, Reduce, Simmer’. Remove, iterate, remove some more. Sleep on it. Come back in a day or so. Chances are, you’ll need to remove some more. Get back to the essence of the materials you’re working with.
So, for all of this, when someone asks me what they get. I tell them: they’ll get less, but they’ll get better. And for that, thank you Mr Katzmarzyk.
Look Mum! No gutters!
Here’s a small tip about designing grids for single column use. If you hit shift command G, you should see an overlay of the grid used on this blog.
At desktop, it’s a 9-column asymmetric grid – which means the columns are different widths. I’m using the columns in this grid to define margins and gutters, not just space to fill with text. The grid is based on the golden ratio, too. Why? Well, the gutters and margins are also different sizes.
The column ‘d2’ is twice the width of the column ‘d5’. The former is being used as a margin, and the latter as a gutter between columns. Also, d1 and d9 are acting as margins, but in Gridset, these are all being defined as columns with gutters set to zero percent.
Reduce the width a little, and you’ll see how the grids shifts to ditch a couple of columns to go to a seven column grid (the ‘t’ grid). Reduce a little further to the ‘m’ grid and you can see that the final grid is using s1 and s3 as the margins.
Just a little under-the-hood explanation of how this blog is constructed.
Yesterday, after 38 years, the BBC’s Ceefax ceased transmission in line with the UK digital switchover. And with that, the digitally disenfranchised across the country have lost a trusted, faithful news service.
When I worked for the BBC one the little known facts about news consumption stays with me: that a large portion of the older generation get their news from the children’s news program – the long running, Newsround. Newsround is to TV what mobile-first is to web design: simple (not simplistic), economic, no-nonsense news reporting. Which is also like Ceefax.
Ceefax was the world’s first teletext system. Initially developed as a way of transmitting closed-caption information for programming, it quickly morphed into a system for delivering other information as well. For many, including me, it was a pre courser to the web.
I spent many-a-day checking the local weather service, TV listings and football scores. Like the web we take for granted today, Ceefax came into its own for on-demand content for breaking and developing news stories. I remember this distinctly for one example: the Manchester IRA bomb in the 1990’s. I’m from near Manchester and this event was local to me, and impacted me directly. Ceefax filed the gaps between scheduled news bulletins on the TV. And it was perfect for my generation who never quite got used to the idea of consuming up-to-date news information on radio. But, it was – up until yesterday – the same continued source of information for people who don’t have access to the web in their living room. They may have it on a computer somewhere else, but they don’t own a tablet, don’t use their phone for the web, or don’t even think to. They just want to check the football scores as they have done every Saturday for the last 30 years in their comfy chair. And with it’s speed, reliability and trust, Ceefax was the best place to go.
Ceefax also embodies a wonderful creativity with the constraints of the system. Low resolution, 8-bit colours, pixel fonts. The only thing missing was bleep, bleep music. As it happens, Ceefax transmitted with a rolling soundtrack that blended into the background and you began very quickly associating with the content: football scores to the “Treasure Eyes” by Robin Jap.
As you can see with these images, the designers at Ceefax were inventive, creative and, well, funny with how they squeezed every last ounce of power out of this wonderfully simple little system.
As you may tell, I’m going to miss it too.
Adaptive Content Management
Yesterday at Web Directions South in Sydney, I gave a talk about Adapting to Responsive Design. I didn’t talk about media queries, responsive images or fluid grids (yes, I know – that’s not like me). Instead, I talked about some of the other things that responsive design challenges: process, business, advertising and content. In the fifteen minute segment on content, I very briefly touched on something I’ve been thinking about for an awfully long time: content management.
The first content management system I worked on was in 1995. It was built in Hypercard, it didn’t publish to the web – in fact, it didn’t publish anyway other than a local, hacked together network in university. Never-the-less, I was pretty happy with it. Fast forward ten years and I’m working at the BBC in Wales working on the design of a new content management system that will drive all of the websites the BBC produced in Wales – for English and Welsh language. I was part of a small, three person team: a designer (me), a developer and an editor. Together, we created a system designed around reusable content objects with really great meta data. Of course, back then, the content objects were being slotted into a fixed width page template according to the editor’s wishes.
Fast forward to today.
Dumb content. Smart Systems.
Okay? Good wasn’t it?
Now, when Karen talks about adaptive content, I don’t think she’s actually talking much about the content being smart enough to respond to its environment. It’s not content’s job to know how, when and where to be used. That’s the job of the content management system and the business and display logic to say: ‘hey, you there! Bit of content! Yes, you! So, in this instance, you need to display like this’. The content goes: ‘oh, ok’. See? Dumb content. Smart System.
What Karen is talking about is a system that can display content gracefully in given circumstances based on some content management rules. As she points out, this relies on a few things:
“adaptive content you need to create multiple sizes, you need to have meaningful metadata attached to it, and it needs to be written for reuse”
“The goal of any CMS should be to gather enough information to present the content on any platform, in any presentation, at any time”
He goes on to explicitly describe the difference between Content Management Systems (CMS) and Web Publishing Tools (WPT):
“WPT’s capture content with the primary purpose of publishing web pages. As a result, they tend to manage the content in ways focused on delivering it to the web. Plug-ins are often available for distribution to other platforms, but applying tools on top of the native functions to manipulate the content for alternate destinations makes the system inherently unscalable. That is, for each new platform, WPT’s will need a new plug-in to tailor the presentation markup to that platform. CMS’s, on the other hand, store the content cleanly, enabling the presentation layers to worry about how to display the content not on how to transform the markup embedded within it.”
“True CMS’s are really just content capturing tools that are completely agnostic as to how or where the content will be viewed, whether it is a web page, mobile app, TV or radio display, etc. “
And here’s the thing. To create responsive design experiences, we need to use content management systems – as defined by Jacobson – not web publishing tools. Why? Because web publishing tools publish web pages, not chunks of content with great meta data that are agnostic to how they’re displayed.
And think about it, what are you using in your organisation? Or for clients? A CMS or a WPT?
As Karen says in her presentation:
“what we have today are publishing tools, we have content management systems that force us to think about content management + authoring and content publishing + display as the same thing.”
And this is a problem for producing content, especially the type of content we need for designing responsive web sites.
A form is a form is a form
Since 2004, and working on the content management system at the BBC, I’ve been involved in a number of content system designs: from a peer publishing tool for Biomed Central – a system designed for facilitating and publishing peer reviewed scientific papers, to the most recent version of Drupal: Drupal 7. Without exception, all of these systems share the same DNA: They’re complex forms, big data tables and buttons. Maybe the odd list. But that’s about it.
Now let’s think about the process of publishing content a minute.
A writer may use IA Writer, Notepad or Apple Pages. But most likely, they’ll be using Microsoft Word. They’ll create the content, edit it, save it, re-edit, print it and scribble all over it, get it reviewed, talk about it, throw it away, re-write it. Once they’ve done all of this, they’ll need to publish it – or maybe they’ll just need to put it in the editorial workflow for review. To do that, they generally copy and paste paragraphs into the CMS. They’ll then need to fill in all of these other required fields: some meta data, pick some categories, a 140 character standfirst, a standfirst for the mobile display, upload some images, but damn, they forgot to crop them.
You get the idea. And so it goes on. Publishing content with a content management system is a royal pain in the arse. Almost without exception.
A page is a page is a page
People think in pages: users, authors, writers. You. Me. My mum. It’s a comfortable metaphor. We have the word ‘scroll’. There are web pages. A location on the web is talked about as having edges, and we all know that’s a problem that’s not getting any better with new devices with new screen resolutions and physical sizes. In swallowing the red pill of responsive design, we also need to feed that pill to our users, readers and producers of our content management systems. We need to start talking about content in terms of bits, not pages. And we need systems that help us think that way.
A better way
As Karen says, a CMS is not an authoring environment, it’s a management environment. Mostly, it’s a painful environment and the headwind from these tools is increasing, especially as we start to think about breaking out content into chunks, not pages. In doing so, our management of that content – meta data, images, display rules – also grows. So what do we do?
In-house development teams developing content management systems need to focus a little more on workflow and a little less on features. Understanding the needs of editorial teams goes a long way. A suggestion might be to start a CMS working group that is comprised of designers, developers, editorial, product and other stakeholders who can guide the system more holistically. Create tools that allow for curation. Content management needs to allow for the ebb and flow of content, not just the creation and publication.
We’ve all started talking about content again. For a long while, our content problems were hard problems and nobody wanted to confront them. But as far back as the monks, good designers have always concerned themselves with content however difficult it was. So let’s not think about our pages of content anymore, let’s think about bits of content. Let’s think about stories as collections of resources, meta data and links that never have a beginning, middle and end. Let’s think of our stories as adaptive. And let’s build systems so we can make them that way.
New design, new CMS, a return to writing. Hopefully.
Since it was released, IA Writer has changed the way I write. Including on this blog. It has changed to such an extent that Wordpress – the blogging software I used to run this site previously – started to get in my way. I wanted a way of simply publishing words, rather than getting all wrapped up in php, theming files and database problems. All of which I seemed to be doing more of.
What I needed was a way of publishing markdown files easily. That would fit more with my writing process with Writer. I tried Jekyll and fell at the first hurdle because of my lack of Ruby know-how. What I needed was all the things Jekyll offers, but with the ease of PHP. Now, if it had a similar tempting language to Expression Engine and a good dose of YAML thrown in, then I’d be on to a winner. In steps Statamic to save the day. I’m not going to harp on too much about it, but it lets you write your posts in Markdown, then you just upload the file – no database, no clunky admin interface. Just you and your words.
This new design is a return to a design I ditched a little while ago. Single column. Sized to be easy on the eye. There’s a bit of Gridset in there to create the grid. Type from Process type – specifically, the serif is the rather lovely Elena and the sans serif is Colfax.
Note. There are bugs and bits and bobs not complete. RSS, some squiffy type, margins, padding etc. I’ll get to them, but I’d rather get it out there and fix those as I go.
Gridset and the Red Pill
Last week was an exciting one. After nearly a year in the design and development, Gridset launched – our tool for making grids on the web. The beta is now closed, although if you signed up, don’t worry, you still have your account and all the grids you created. If you’re new to Gridset, head on over, create a free account and have a play.
Last year, at Mark Boulton Design, we were working on about five or six concurrent responsive website design projects. All of them were at various stages, but mostly they were in various stages of prototype – from the grey-box, to the high fidelity.
One of them included advertising. Two others were asymmetric: meaning one or more of the columns wasn’t the same width as the others. Some of the requirements came mid-way through a project which meant we had to go back and refactor CSS and HTML to accommodate it. All of them were sizeable projects. The maths got difficult quickly, and we sat down and had a chat about making something to make our lives a little bit easier. That Wednesday, the seeds of Gridset were sown.
Responsive by default
Responsive design is time-consuming. Not just writing the code, but all the way back to content requirements, typography, layout, managing client needs and expectations, Q.A and bug testing. Making websites this way adds time. In some cases, too much. Or rather, we’re spending time on the wrong things.
One of the things that is clear, is that if you build websites this way, you need to get out of Omnigraffle or Photoshop and into a browser sooner. You need to get content into a real browser environment soon to see how it responds to different screen sizes etc. We found that we were spending too much time either a. coding layouts over and over, b. bug fixing things we shouldn’t.
Luckily, grids – along with some other things like iconography and typography – can be abstracted from our design work. They can be worked on independently before coming together in the browser. This way, we spend more time focussed on answering some of the design problems than banging heads with layout code and the responsive headwind is a steady breeze instead of a gale.
Choosing the Red Pill
I can’t design just in a browser. Neither can other people. Which is fine, I think; architects don’t design using steel, glass and bricks. Personally, I design using a bunch of tools that I have a good knowledge of: pencils, paper, Photoshop and HTML. You may do something different. But over the course of the past couple of years, as responsive design has jolted us from our lie of control on the web, we’ve needed to do more in the browser because doing it in Photoshop doesn’t make sense anymore.
Sometimes I hate Responsive Design. Like Cypher in the Matrix, if I had to choose between the Matrix and the real world, I’d choose the Matrix. Why? Because designing for the web before responsive design was easier. And most people – including me – want an easy life. But once we’ve accepted the reality of designing for the web, I don’t think there’s any other way to work now. Even if you can’t design in a responsive way – because of advertising, or content problems, or your CMS makes it difficult – then you shouldn’t ignore it.
The tools we use
The next step on the web, now this disruption is settling down a little, is for us to invent new tools to help. Tools that are fit for purpose – specialist – and that do one thing well. I’m very much looking forward to the next few years where more people swallow the red pill and we start producing more and more web products using these tools. It can only get better, right?Previous Next