Category: design

The Fast and Slow of Design

Move fast, break things. Fail forward. Fail fast. Always be shipping.

These idioms are all around us in the tech industry. Establishing themselves in small, garage-band startups, they are now deeply entrenched in working cultures of even the most traditional publicly listed companies.

Working fast is alluring for every board-room executive. Especially if, over the course of months, speed (and failure) results in faster product releases, more revenue, bigger and faster growth. Capitalism, right? However, I'm of the opinion that speed – and those arbitrary deadlines – create an unhealthy balance that can eventually lead to the demise of the company. Moving fast and breaking things tends to be at the expense of paying attention to slower, subtle, more stable, 'boring' aspects of a system.

So what happens when we focus on the entire system? How can we create sustainable, balanced design systems that serve our companies and products for the long term?

The Fast and Slow

My family and I moved into our current house about six years ago. At the time, we were living in a modern semi-detached house that we'd spent about ten years making our own. We knew we wanted to move into something older and a bit more characterful. A place we could grow old in. After a year or so, we happened upon the house; a charming farm workers cottage on the edge of town. Having a look around it the next day, we instantly fell for it. It was perfect. Sort of. Just like all old houses, we knew there was some work to do.

Amongst many, many things that required some attention this fireplace was one of them. The house was cold – yes, the central heating was one of those things requiring work – so we needed fires in the winter. Fitting new log burning stoves required enlarging the fireplaces, and in the case of this one, opening up ones that had been blocked up.

My fireplace

The day before this photograph was taken, Dai – our Welsh stonemason – called me at work and asked me not to come home for a while. That sounded ominous. In their wisdom, the builders who had blocked this chimney had thrown the rubble down it. He managed to dislodge about three tonnes of rubble that came down in a small explosion in our living room. We could taste the resultant dust for weeks. This is just one example, over the past six years, where this house has surprised us. When you start peeling back the layers, you start to see what a building is made from. What its story is.

In his book, 'How Buildings Learn', Stewart Brand has a useful concept to explain this.

Building shearing layers

He describes a building having layers that age at different speeds. These 'shearing layers' are very apparent in my house!

In his follow-up book, The Clock of the Long Now, he expands this concept and applies it to our world.

Pace layering from The Clock of the Long Now

On the top layer there is rapid change. On the bottom, change happens at a glacial pace. It's this combination of everything, from seconds at the top, to millennia at the bottom, that give resilience to the system. As he says in this talk:

'The fast parts learn, the slow parts remember'

A key concept to this is that each layer has to respect the pace of another. There are examples of when this has gone wrong in the past in society:

Regime change in Iraq – removal of governance in a system – has resulted in change to all layers. The system collapsed and we are still feeling the effects of this today and into the foreseeable future.

In 2008, as so wonderfully documented in the film 'The Big Short', the housing market in the US failed. The cause was complex, but central to it was the failure of the CDO – the not-so-wonderfully-titled 'Collateralized debt obligation' – and the sub-prime mortgage market. The collapse of both put modern global civilisation on the brink. A decade later, we look set to make the same mistake.

The part of this diagram I like the most is that it forces you to think in time instead of other ways of organising things. As this relates to design, time – or rather longevity – is not generally a consideration. Like much of our lives, modern design gravitates to those upper layers of commerce and fashion. We get paid well to make desirable things that people consume. Once we're done with one thing, we move onto the next.

But how can we apply this thinking to design? How can structure design organisations and systems based on time rather than resources or products?

Why is this hard?

I'm currently just a few months into the job, but already it's clear EMBL (the European Molecular Biology Laboratory) is a special place. Like CERN, and other organisations that provide infrastructure for basic research, the currency of EMBL is science. Not profit. Or shareholder value. But by providing the very best environment for groundbreaking scientific research to happen. And it's precisely this reason that makes design in places like EMBL challenging.

Perched on a hill outside Heidelberg in Germany is the headquarters of EMBL. Like its other campuses in Barcelona, Rome, Grenoble, Cambridge, and Hamburg, the Heidelberg campus is a small gathering of laboratories and supporting buildings. It feels more like a university than a multinational organisation; full of students and young scientists embarking on their career. It's a place of energy.

There's amazing work going on at EMBL. This story recently caught my attention.

In about 40 years, the demand for data storage will outstrip the supply of silicon. Our need to store data will continue to increase, but we will need to focus the usage of silicon on more critical things such as computer chips. To address this, scientists have been working for a little while to encode digital data in DNA. Turns out there's quite a bit of space available but at the moment it's costly. A few years ago it cost about $13000 per megabyte to encode. Like all things, the price comes down as the technology and methods improve, but even this is palatable where long term storage is considered.

Recently, scientists at ETH Zurich did a study into the stability of DNA data storage. The results showed incredible stability. Data would be stable for ~2000 years at 10C and over a 1,000,000 years at -18C. And the additional benefit of DNA is it's really, really tiny. Last year a new method at Columbia University estimated that DNA has a 215 petabyte: 1 gram storage ratio.

The latest instalment on this 40 year deadline, was last year Nick Goldman of EMBL-EBI encoded an encrypted bitcoin into some DNA and gave away samples at a conference with a simple challenge to the attendees: decode it and you can keep it. Recently, someone did just that..

Why am I telling you all of this? Basic scientific research spans the pace layers. From fast. To slow. The field of scientific research is structured to accommodate this; except for senior staff and scientific research group leaders, EMBL employees are not at EMBL very long. The result is a startup-like culture working fast on problems that span decades. Since working with scientific institutions like CERN, now EMBL, it's also the answer to the question I ask myself almost every day: 'Why is this hard?', and why structuring design systems by time may be more useful.

What's in a system

If we look at the constituent parts of a design system, we might see something like this list:

  • Governance
  • Patterns
  • Tokens
  • Logo
  • Typography
  • Colours
  • Icons
  • Content
  • Tooling
  • Documentation
  • People
  • Committees
  • Infrastructure
  • Animation
  • Data entry
  • Data display
  • Layout
  • Localisation
  • Markup and style
  • Messaging
  • Search
  • Navigation
  • Voice and tone
  • Accessibility
  • Grid
  • Image

That's quite a lot. And, if you look at a lot of existing design systems and style guides, this stuff tends to be categorised into large groups such as 'Brand', 'Marketing', or 'Product'.

Typical design system groupings

But if you look at a system more holistically, there are many other things:

More holistic view of a design system

These large, holistically focussed groups can be layered according to their rate of change:

Pace layers view of a design system

Remember, rate of change at the top is rapid, at the bottom, things should barely ever change. If we start to map on top of this our items from our lists...

The layers of a system

Let's look at each one in turn. Starting at the top with 'Tooling'

Tooling

Tooling is fashionable. The way we design, build, deploy and update digital products changes as fast as users consume them. This will probably always be the case, and, you know what, that's ok if your system is built to accommodate it. For me, that means ensuring that the means by which the system is distributed and deployed is in step with your organisation's way of doing things. The moment these two things don't match, tooling becomes an issue.

Patterns

Design patterns are closely linked to product design and user behaviour. As these things change, patterns need to change too. In this layer I'd include the look and feel of design patterns in addition to their code. Admittedly, there is somewhat of a grey area there with tooling – many design patterns are linked to methods of deployment and distribution. According to this model, that isn't a great idea. When tooling – which changes at a different rate – is combined with patterns, it leads to what Stewart Brand calls 'layer turbulence' and often the answer to my question: 'why is this painful?'.

People

The people in a system are seldom acknowledged as a component of a system. Instead, they are people who act on a system. I think this is a mistake. People take work. In most organisations, the people of a system represent continuity and sometimes the only thing stopping it from being rebuilt and redesigned from external HIPPO (Highest Paid Person's Opinion) influence. How I'd define people would be any real person interacting with the system; the team building it, stakeholders, open source community etc.

Documentation

As we move down the layers, things become more stable. There are many things in documentation that require stability. Change needs to be more visible and apparent, such as repo commit messages, or 'last updated' footers on website content. Documentation could also include design principles, brand guidelines, or editorial guidelines. For many systems, this represents the lowest layer of stability, but I think we need to go further.

Governance

Systems need governance. How else is change managed? A key thing to note here is that the work of governance is managed at a higher level in 'People' as it's faster. This layer is concerned with the process and methods of governance; how a system is governed rather than the act of governance.

Foundations

Like the foundations of a building, the foundations of a design system should not change. Examples that I would consider foundational are things like the URL of your design system; elements of the brand; the repository; the design system and brand nomenclature.

With all that in mind, let's have a look at those idioms again:

Move fast, break things. Fail forward. Fail fast. Always be shipping.

These phrases drag us to the top layer and keep us there. They prioritise speed over stability. I'm interested in creating sustainable systems with longevity, so I don't think it's an appropriate way of thinking. What might be more appropriate, but probably more boring, is:

Structure for pace. Move at the appropriate speed.

But I guess that doesn't sound as cool.

Note: This article is a rough transcript of the talk I gave at SmashingConf in San Francisco in April 2018.

Write it down

This is a post in defence of process. Yes, I know what you're thinking: 'urgh, process is a thing put in place to make up for mediocre teams'; or 'prioritise discussion over documentation'; or 'I get enough red tape in other parts of my life'. You know the response. You've probably said it as many times as I have.

Conversations are cheap

I am the first person in the room to defend the delights of working in a lightweight, agile (lowercase 'a') way. You make stuff faster, generally better, and you build team or product momentum. The real benefits I see are people benefits: a closer-knit team; shared understanding; less things on fire. The wholesale shift to this way of working – outside of slow-rotting corporations, that is – has many benefits. But the cultural distain of the 'P word' is not one them. Process has a place.

The main issue I see time and time again is that conversations are low effort. Not only that, but certain ways of working prioritise them over slower, reflective, considered decision-making. I use one method that works to counter-act this.

'Write it down'

Whenever someone asks me to do something that I think seems ill-conceived in some way, I ask them to write it down. That's it. Because writing is high effort. Making sentences is the easy bit, it's the thinking I want them to do. By considering their request it slows them down. Maybe 30% of the time or something, they come back and say 'oh, that thing I asked you to do, I've had a think and it's fine, we don't need to do it'.

This little method isn't about doing less. Well, actually it is. It's about doing less important things instead of important things. It's not about being obstructive. I certainly don't ask someone 'why?' five times (which is a shortcut to being called a smart-arse in my experience). This is about a light-touch way of asking someone to slow down.

Time for reflection

In the UK, medical doctors are required to 'reflect on an aspect of their work' every month. This is time that is monitored as part of their self-development and self-improvement. Doctors are amongst the busiest, pressured people I know and if this wasn't mandated by the British Medical Council, then I'm pretty sure it just wouldn't happen. They have to make time. And we should, too.

We're all running at 100mph. Making things faster and faster. In my own experience, time reflecting on work tends towards sitting in front of screen – like I am now – thinking about the next thing on my todo list, or beating myself up about the latest ball I've dropped. How does that Elbow song go? 'Cramming commitments like cats in a sack'

These days, I welcome being asked to 'write it down'. It gives me permission to take a breath. To pause and reflect on what I'm asking. I'm convinced my heart rate drops a little. You see, in some environments this would be called 'process', or 'red tape'. 'Being asked to write something down is a blocker to my flow'. Those kinds of responses miss the mark. When being asked to 'write something down' it's really shorthand for 'take some time and think about what you're asking'.

Next time someone asks you to do something, try it. I bet 3 times out of 10, they say 'oh it doesn't matter'. You'll have that time back. They'll be a little wiser and have a lower heart rate.

Editorial planning with Trello and Zapier

As long as I've been working with editorial teams a content pipeline has been a problem. Knowing the state of a story, its context to those around it, and who has done what, when, is vital in managing a content throughput. Generally, this figures itself out in a busy, noisy, physical environment. But, the more remote a team becomes, the more challenging it is to communicate on the state of stories.

When I joined EMBL a couple of months ago, this was a problem we had. Content status was done weekly, but a continually available overview by the entire team was not. Nor was there a tool or process to push stories around. As I said, my experience is this is not unique to EMBL. Almost every editorial team I've worked with struggles with this.

Dan and I got our heads together and worked on a process that would fit with the existing team and tools. The team here use Trello extensively for planning, so we started there.

The one board to rule them all

It was important we didn't interfere with existing processes using Trello. The team all use Trello in different, interesting ways to collaborate and manage their content; from ideas to final copy. We needed to integrate with that best we could. This is what we settled on:

1. A Pre-production Trello Board

Once a story is ready to go into the workflow. Meaning it is agreed, planned, assigned to a priority etc, then it is added to the pre-production Trello board. This board is organised by story type: features, updates, press releases. Once a story is complete and ready to publish, it is moved into a column 'Move to Production'. Zapier then copies the card, with everything in it, over to the Production board. Once that's done, it moves it to an archive list.

2. A Production Trello Board

The production board is not focussed on collaboration or story type, but arranged as a pipeline of approvals, sign-offs, edits and publishing. Once a story moves through these linear stages then published, Zapier goes in again and moves the card entirely over to the archive board.

Some notes about Zapier

I've used Zapier a bunch of times over the years but never really had the time or focus to work on automation that fits within a team environment. It's great, but it requires some wrangling to work if you move beyond the default app integrations.

Zapier integrates really well with Trello. There are a whole bunch of predefined tasks that you can chain together to do stuff with your Trello boards. For the most part, the challenging thing is working out the sequencing of what you want to do. For our 'move to production' task, this is what we ended up with:

  1. Find the Pre-production Trello board
  2. Find a list on that board called 'Move to Production'
  3. Find cards moved into that list (this is the trigger to run the whole zap)
  4. Get information about the card and move it to Production. (In fact, here, I didn't move it but copied it. I wanted a safe-guard in the system so that if something went wrong, there would be a backup)
  5. Once it's moved, confirm by then moving the card into the archive list.
  6. Once all that's done, check the card has actually moved.
  7. Then post to Slack and let everyone know.

The only stage out of all of these that is out of the ordinary is the 'copy' task (number 4). To complete that little task we need to use webhooks in Zapier to POST directly using the Trello api. After a bit of Twitter help Hat-ip @sprawsm, we figured it out. It's probably easier if I just show you in Zapier what the important bits are:

Zapier webhooks fields

You can see from this image that the web hook field has a bunch of form fields. I'll concentrate on the important ones:

URL

When we create a web hook, we need a URL for the api endpoint. For Trello, this is the one we need: https://api.trello.com/1/cards/key=(your key here)&token=(your token here). You can get the key and token from your Trello settings.

Payload type

Set this as JSON

Data

These are the fields of data you are going to pass to Trello via the api. The content of these fields will be populated from the fields earlier in the Zap. It's important each of these field titles is copied exactly for the task to run. Let's go through each in turn:

  1. 'name'. This needs to map to the title of the card to move.
  2. 'idCardSource'. This is the ID of the card.
  3. 'due'. This is the due date for the card if it has one
  4. 'KeepFromSource'. This one is important. It will make sure when the card is copied from one board to another that all the cards contents are retained.
  5. 'idList'. This is the ID of the list we want to move the card to.

Wrap request in an array

No

Unflatten

Yes

And that's it. These are all the changes you need to make below the data fields. When it is run, this little task will take the values from the other tasks before it and populate the data fields, it will then post that to the Trello api, and Trello will copy the card into the Backlog list on the production board.

Broader use

After using this for a little while, I realised I'd really like to use this workflow for managing my simple, personal Trello backlog. I have a pretty standard kanban-style backlog/doing/done Trello board for all sorts of stuff. A mix of personal, side-projects, work, thoughts, writing. It's a dumping ground. Every day, though, I may need to pick some cards out and replicate them on the team board or a project board. Now all I do is replicate this task. I've added a couple of additional lists in my Trello board, and I move the cards into them when I want them copied somewhere else. Zapier watches those lists and copies the cards. I'm finding it a useful way for moving cards around and getting work stuff out of my personal board, and into a work board.

A bit of gaffer tape

Whilst this automation works well for the most part, sometimes either Zapier or Trello craps out a little bit. When that happens, it's normally some snafu with the Trello api and the post. That's why the notification is an important part of the process. Using a quick ping into Slack let's me know a couple of things: that the zap is actually working still, and that there is a new card that has been created.

I'm sure there could be technical improvements to make here to make this a bit more robust. But as a scrappy self-serve solution for an editorial team to manage their through-put of stories, so far, so good!

Defining design principles at EMBL

For a little while, since leaving Monotype, I've been working with the communications team at the European Molecular Biology Laboratory (EMBL) on a holistic corporate design project. It's pretty exciting work.

I'm lucky that the project is being headed by Dan Noyes, who I worked with at CERN, so he and I know how to work together pretty well. There is a fabulous team in place, and we've been tackling some fundamentals of the brand, the strategy to implement the it, all within the context of a complex scientific organisation.

To help keep us arrow straight whilst navigating this problem we defined design principles to do it. Now, I'm sure there are many ways to define principles but here's how I do it and it's really quite simple. I was shown this by Leisa when we defined design principles for the redesign of Drupal 7 years ago. All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.

Throughout the sprint, we defined the following design principles for EMBL:

  1. Make it sustainable

We will create a long-term, sustainable system. Designed for efficiency, re-use, and scale.

Sustainable systems are diverse and productive indefinitely. Being holistically focussed on how EMBL interacts with its audiences internal and external, means we create meaningful, sustainable experiences over the longer term.

  1. Show our work

We will prioritise demonstration over discussion. Through prototyping we will show how these principles and values apply to the work.

We will embrace modern design practices by starting small and iterating quickly. We will avoid big reveals and develop a process of publishing early and often. This requires a change of mindset of the team: to be comfortable with ‘not done yet’; to be satisfied to prioritise function over form; to get the things we make in the hands of our audience so we can understand their needs more quickly.

  1. Keep it simple

We will do the difficult work to keep the things we make simple, approachable, and put the user’s needs first.

EMBL is complex. As are the audiences, services, applications, and communications material that operate within the brand. We will do the hard work to uncover and expose the simplicity of the core.

  1. We are all one organisation

We will cultivate cross-pollination of services, products, ideas, and collaboration.

We will proactively seek out opportunities to collaborate on the design of services across all channels throughout EMBL and invite feedback and new perspectives. We will share and discuss our methods.

  1. Physical, digital, and environmental are in sync

We will ensure a holistic approach for one system for all printed, digital and environmental touch-points.

Design systems across media evolve at different rates. We will ensure systems across all channels are relevant to the media, but also share nomenclature, design patterns, and are built from the same principles. We will think and act as a cross-disciplinary design team.

  1. Pave the cowpath

We will make the design language accessible where people are already working.

Forging a new path is hard. And sometimes a waste of energy. By understanding how the brand is expressed currently, we develop new ways to provide the ingredients of the brand to the people already doing the work, in the place they are doing it. We will invent new ways with which to distribute the brand across a constantly moving, evolving system. We shouldn’t press pause.

  1. Repeat the words we use

Through consistency and repetition, we will create and maintain a design nomenclature that will become part of the EMBL vernacular.

The words we use are important. By repeating these words about EMBLs products and services, they can remind us many times every day what we believe. Changing the words we use can help change the culture of an organisation to be more design and brand aware.

Another important aspect to these is the way they are structured. A design principle is a belief. It's something we promise to do and should be worded as such.

You can read more about the design process on EMBL's communications blog.

Design systems and Postel’s law

I was first made aware of Postel’s law by Jeremy in his fabulous talk about design principles. Incidentally, he’s documenting lots of design principles here.

Postel’s law – or the Robustness principle - states:

Be conservative in what you do, be liberal in what you accept from others (often reworded as “Be conservative in what you send, be liberal in what you accept”). From Wikipedia

Jon Postel was talking about TCP and how implementations should follow this principle. Putting TCP and networks to one side for a minute, you can see how this principle can apply to many systems where there is input and output. Specifically, design systems.

The basic premise of Postel’s law is that what comes into a system can, and invariably, is a mess. Non-Compliant, delivered in a weird way, unconventional.

When thinking about this, I recall some work I did years ago on a ticketing system for a help desk. The single biggest hurdle, in order for the system to be successful was it had to be liberal in what it accepted. Tickets needed to be created from email, phone applications, web applications, voice recognition etc. The hardest part was getting stuff into the system. Only then could a single ticket be created - from various sources, in varying quality of data – in a single useable ticket for use with the large team.

Be liberal in what you accept (from emails, apps, voice, websites) and conservative with what you do (creating a single, well-defined ticket).

I see this same principle being applied to design systems.

Collaborating across an organisation to create a meaningful, impactful design system means you have to be liberal in what you accept from others into the system. Be it code, thoughts, design work, content, or criticism. That input can also come from many different teams, strategy, executives, products, people. You see, it’s a big mess! And the only way, really, to work with a system like this is to be open to all input from wherever it comes, in whatever form takes. To be liberal with what you accept.

This approach does a few things:

  1. Makes people feel involved, consulted, and listened to. This a good thing.
  2. Exposes the system to the dirtiest, out-of-date, horrendous use-cases possible. This is also a good thing. Mostly these use-cases are ignored because they are horrible.
  3. Helps turn a system that is owned, to one that is shared.
  4. Helps identify themes across an organisation.
  5. Helps the design system core team operate at a holistic level.

Policing a design system never works in my experience. It never works because people don’t like rigid systems, being told what to do, and will straight up do the opposite. Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.

So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable. It needs to turn the messiness of a liberal input into a defined, purposeful output that people can easily slot into their workflow and use.

Once again, I find myself in a place banging heads with how work happens rather than what the work is. Someone once said to me that ‘design principles are the stars to sail our ship by’. I’m certainly going to be using Postel’s law to sail my particular ship in the months and years ahead.

Design systems in difficult places

A street in Manchester

This is Manchester. I grew up on the outskirts of Manchester. I have memories like this picture. Black and white. Snowing. Wildlings. It’s grim north of the wall.

But what this picture doesn’t show is the rich visual culture that Manchester had throughout the 80’s and 90’s. All that rain and grim weather makes people creative. It’s no accident most of the best music in the world came from the North West of England.

Tony Wilson

This is Tony Wilson. Tony was a journalist in Manchester, appearing on Look North West as a roving reporter. I have lasting memories of his wind-swept hair, stood in a gaudy cagoule talking to a farmer on some moor somewhere. He was on telly every evening at teatime when Look North West was an ‘appointment to view’ (as they call it in telly-land) across the region. But as well as being a journalist, Tony was also involved in Factory Records, founding it with Alan Erasmus in 1978. Factory went on to define an era of music in the 80’s and 90’s signing bands such as Joy Division, New Order, and the Happy Mondays. I’m not a big fan of the music, but of the graphic design produced at the time.

Graphic design from Factory Records

Graphic design from Factory Records

This work was everywhere in Manchester. On every street corner. In every record shop. In every music shop. There were posters, fliers, newspapers, TV adverts. The hum of the city became entwined with the output of Factory. And, without really noticing it, started to take on this DNA. It became Manchester’s design system. It’s visual life-blood.

Imposing order

The challenge with any design system is they normally don’t work, don’t get adopted, don’t grow or get used if they are imposed top-down without an awful lot of consultation. Like any language, they have to be adopted by the masses through continued daily use. The tricky thing for us designers is that is rarely how we’re engaged to create these things.

Normally the brief goes something like this:

We’d like you to design us a living style guide (replace with ‘pattern library’, ‘design language’, ‘brand guidelines’, ‘identity’). We’ll then use that to provide consistency to our entire product range – of which we’d like you to help us.

Now, this works in some circumstances if control is maintained by a marketing department or brand manager. But, it’s my experience, that unless design is valued then control is absent. Nobody has the authority to own this. They just have some budget and see a problem that needs addressing, but do not have the money, authority or organisational environment to make this work succeed. So what do you do then?

Well, you just do it anyway. But over the years – taking some inspiration from my home town – I have a few principles…

1. Repeat yourself consistently

Let’s get one thing out of the way first. Meetings are not bullshit. Suggesting that is actually bullshit. Meetings – where people talk and resolve things, plan, decide – are probably the most important thing you can do to get a design system off the ground in a difficult place.

Remember, you have no authority. Your client, or stakeholder, has no authority. You’re doing this for better, holistic good of an organisation that almost everybody there cannot see. So you have to persuade, provide insight and data, and in my experience you have to do it over and over and over again.

2. Establish a mandate

Over the last 10 years i’ve worked on quite a few, large scale design systems. In all of them, there was a distributed technical system that had grown organically. A few CMS’s here and there. PHP, .net, etc etc. It’s not like you could create a bunch of HTML and it would work everywhere. Far, far from it.

And then, editorially, many of the departments of these organisations were creating content without any joined up thinking. It was common for them to have their own budgets to create their own mini projects (yes, with their own CMS) and they’d hire a little design firm to do it.

From a branding perspective, there was normally a small, internal, over-worked branding team who were constantly and consistently putting out fires that the organisational structure creates. Everywhere you look people were degrading the brand.

In my experience, this is the norm. How do you create a design systems that not only gets adopted, but thrives, in this environment? You have to establish a mandate. An editorial, technical and brand mandate. A troika of disciplines working together to establish order.

3. Be where the creator is

In the case of Manchester, the work of Factory was in front of every young designers eyes. Everybody looked up to the work of Peter Saville and created work to replicate it. So, on every street corner, the inspired work appeared. All of a sudden, Manchester’s visual DNA expanded beyond the world of record shops and club night posters, and made it into plumbing brochures, margarine packaging and pub fliers. The bread and butter for jobbing designers in the North West.

This was because the work was accessible and in the places designers where looking for inspiration.

I like to apply the same thinking for the adoption of a design system: be where the creator is. A few examples:

  • Provide ready-made templates for design tools. Not just for in-house designers, but so external designers (you know, hired by the small department trying to use their budget before the end of the year) can use them too.
  • Provide tools to make things. If you’re building digital things, provide a UI library and maybe prototyping and deployment tools that make consistency easier.
  • Be where they are. If an organisation uses Sharepoint, or some other God-awful intranet software, then put your tools where they are and don’t try to force other documentation if it won’t fit.

How do you know you’ve been successful?

I get asked this a lot. How do you know if your work will stick? You’ve spent a year designing a new design system. How do you know it will really hold? I’ve learnt to look out for a few indicators…

  • The design system becomes how design is talked about in an organisation. It becomes a shared vocabulary. And not just by other designers, but by management and all levels of an organisation.
  • The quality of design (and editorial and technical) becomes self-policing. It’s no longer the responsibility of just one person or team, but ownership becomes distributed. People start to care.
  • Design and KPIs. Clear lines get drawn between good design and measurable outcomes.
  • Lagging and Leading indicators become more apparent. So you can better predict how those indicators affect quality, brand, product roadmap. In this case, design can help indicate the health of an organisation.

What’s Manchester got to do with all of this?

You may well ask. When I was growing up in Manchester, I never really took much notice of the graphic design around me. It was only when I left – or years later – when I decided to become a designer that this stuff leaked out of me. It was stored somewhere deep inside my brain and with it, I like to think, I absorbed some of that taste. By being part of the Zeitgeist.

What you do now for your client or in-house will have an effect that will be felt years later. You will change how people think about design. Change their relationship with the company they work for. All by consistently using Helvetica, or something. It’s not that hard. Is it?

The difference between a goldfish and a human

In the 2012 Olympics, the UK cycling team dominated the track. Winning 12 medals: 8 Golds, 2 Silvers, 2 Bronzes. They also broke 7 World Records and 9 Olympic Records.

The French cycling team director suggested that the UK team were using ‘magic’ wheels. That was until it was pointed out the wheels were designed and manufactured in France.

No, aside from the unbelievably hard work of the team, the superb conditions of the track and the humidity of the building, there was one person who was credited as the brains behind the performance; Sir Dave Brailsford. Sir Dave is also credited as instilling a culture of measurement, data, and, ultimately, well-being into the team. A key component of this was a philosophy of ‘Marginal Gains’.

“The whole principle came from the idea that if you broke down everything you could think of that goes into riding a bike, and then improve it by 1%, you get a significant increase when you put them all together.”

This is also something he applied to his job as manager of the Sky cycling team.

When Brailsford formed the commercial cycling team he had one goal: to win the Tour de France. Clean. Within five years. He did it in two. And then again. And again.

The challenge he had was this: cycling has long been a sport which uses performance enhancing drugs. In order to compete against teams using these drugs, Team Sky – and any other clean team – had to bridge a gap of about 16-19%, depending on which source you read. Regardless, that is an enormous distance in performance in any professional sport. And they did it through the aggregation on marginal gains. Looking at every aspect of an athlete’s life – their diet, weight, sleeping patterns, physiology, well-being, the pillow they use at night. Even how they wash their hands – they were able to bridge that gulf.

I’ve been a fan of professional cycling for a long time. Even before I owned a road bike and rode myself. But recently, I’ve become interested in how coaching has created this performance. How Team Sky’s, and before it Team GB, management team has created a culture for riders to succeed by the continued improvement of tiny, tiny little things. But, I’m also interested in the opposite.

Marginal Degredation

Here’s a few fun facts… - Gorillas share 98.4% of our DNA - Goldfish share 68% - Bananas share 50%

Bananas. Are 50% the same as us.

Well, you think about it, it kind of makes sense. We’re all made from the same elements. The same star dust. Just arranged in different ways. But, we’re very, very different to bananas.

Let’s talk about design for a second.

What happens if 1.6% of your brand is left unchecked? Or 1.6% of your user experience of your product. Doesn’t seem a lot, does it? How about 32% Again, for some, this is within acceptable margins. Especially if your brand or product is growing quickly, acquiring companies here, there and everywhere.

But, 32% is the difference between a human and a goldfish. Even just 1.6% – probably acceptable margins for almost every brand or product out there – is the difference between a gorilla and a human. Think about that for a second.

Your brand or design is supposed to be a human, but people perceive it as a gorilla. Or a banana.

Applying Marginal Gains to brand or product design

What can you do about this? How do you stop a distributed organisation degrading itself? Well, entropy happens and this is always the struggle with any branding or design work on an ongoing basis. Like any garden, it needs tending.

But, here are some of the things I do to stop the rot:

  • Keep talking. To everyone. My job is to help create the environment in which marginal degradation doesn’t happen. I do this by talking to everyone across an organisation - so they feel involved, empowered, excited, free to be creative. I did this before working at Monotype too, but with other companies.
  • ‘Show the mess’. Design work is not that scary. Expose people who are not designers to the design process. By doing this you get better buy-in, involvement, and culture.
  • Maintain a holistic view. It’s so easy to get dragged into the weeds. But sometimes, the weeds is exactly where some delightful little design problem exists. Who knows, maybe I end up doing some actual design work. You know, keeping my hand in. Well, no. Keep above the weeds.
  • Draw straight lines between design and KPIs. This is a big one. What design and brand do should be measurable. Not by some data Goloms like the Net Promotor Score, but by committing to understanding your customer’s behaviour. You can only make incremental tiny improvements on a foundation of understanding. Measuring against real-world indicators puts design in black and white numbers all levels of an organisation can understand.
  • Just be consistent. Even if you know it’s not ideal. It’s not something you’d do. Maybe you inherited a design system, or jumped on board half way through it’s creation. Maybe you just don’t like it anymore. That’s ok, you can take your time to get it changed, but in the meantime, be purposefully consistent.
  • If you do deviate, make sure you do it with a plan. If you plan on being a gorilla, and deviating that 1.6%, then do so with purpose, not just because you are lazy.

Plugging away at this tiny stuff is relentless. It’s the tiny details that, when viewed together, look big and insurmountable. But, taking one tiny improvement at a time, in the bigger scheme of things, you may be surprised at how quickly your product or brand starts perform. Not only that, but now you have a way to measure it.

Designing a good portfolio

It’s 1998 and I’ve just arrived in Bangkok and it’s 90F at night. I’ve arrived at a small hostel just around the corner from the Khao San Road and, just like everyone else travelling or on a gap year, I’m a walking stereotype. From my flip flops, overly loose trousers, consumption of banana fritters and cheap Thai beer. Oh, and well-thumbed copy of The Beach.

Like I said; a walking stereotype. Except for lugging around the 2kg A3 sized portfolio case rammed into my already weighty backpack.

It’s 1998. The web is still in its infancy, but it’s there and pretty good. Fireworks was on version 1. I used Internet Explorer 5 and Eudora The first iMac had been recently released. Not really the dark ages, but here I am, lugging around an additional 2kg of dead trees for two months around South East Asia. Why? Well, I wanted a good job when I got to Sydney. And, as a designer, a good portfolio – or ‘Book’ as it’s called in advertising – would get me one.

Let me back-peddle a bit to my first job as an intern at an ad agency in Manchester. There worked an Art Director called Tom. Tom was quiet mannered, quick to smile and laugh, and much quicker to point out a small opportunity for improving a design. Together with the other Art Directors, he taught me about hierarchy and how to make type fit on a page (this was a distinct problem when designing plumbing catalogues). But he also taught me the value of a good Book. How to design one; how to tell a story through your work; how to present your work and do enough in the portfolio to get you a foot in the door which is what junior designers needed so much back then.

“Leave your book and pick it up tomorrow”

My experience of looking for a job early in my career was probably quite usual amongst my peers: I never replied to a job advert. Instead, I was encouraged to get together a list of the places I’d like to work and then to sell my portfolio around them. So, there I was; fresh out of school, full of ‘I got a First Class honours degree’ confidence selling myself from agency to agency. It was a baptism of fire. I remember the first day was particularly horrific. Out of the six or so agencies I’d arranged to visit, only one was happy to let the art director see me rather than just leave my Book and pick it up tomorrow. And then, my work was systematically ripped to shreds by an Art Director with too little time on his hands.

Now, this isn’t meant to sound like ‘oh, woe was me and my hard time finding a job’. But, I am trying to recall how my portfolio was the start of a conversation. And, generally, a conversation I wasn’t there for. I didn’t really plan for that so had to adapt the work to invite that second meeting.

Oh, those soft skills

So much of what we do is working with people. Sometimes, though, I think I need to have experience in counselling or negotiation tactics in order to usher through design changes which impact organisations at their core. It’s difficult work. And, if you’re not the type of person who like talking to other people, then the impact of your work will only go so far. The question is, how do you demonstrate this in your portfolio? How can you demonstrate the value of design games, or collaborative moodboard exercises? Or that it took six months of negotiating with dozens of facets of an organisation in order for a content strategy to be adopted? My advice would be to write a story. Show photographs of workshops. Demonstrate how you approach these things. List the methods you’ve used and those that have worked. List those that haven’t and the reasons why.

This may seem odd for a portfolio, but if you think about it, design agencies have been doing this for decades. This is because they have similar problems. A lot of agencies sell the process of design, not the end result. In order to charge money for things like strategy, research, collaboration and what-not, all of which is difficult to show in a piece of design, they have to demonstrate it in other ways; case studies, stories, photographs. Packaging the work to show the full range of what was worked on.

A few pointers Tom gave me (and a few of my own)

Let me take you back to Manchester in 1995. I think it was early in a week in July. It was probably raining, as is usual in my home city. Anyway, Tom and I are discussing university and where I’d like to work and doing what. I start talking to him about my final year and the projects that await and he begins to advise me on not leaving my portfolio work too late. That I should be working on it throughout my final year and how I shouldn’t under-estimate the amount of work it will take. A year! Surely it couldn’t take a year, I said. It’s just a dozen prints after all. ‘No’, he said. ‘It’s probably the most important piece of work you’ll do in your final year, and one you won’t get marked on until you try and find a paying job’.

Over a nice hot cup of tea, he and I chatted for an hour or so about what makes a great portfolio and all of the things he considers when a dozen or so would land on his desk every single week. At the time, this was for a print portfolio, but looking at these now, you could easily see how they’d apply to all types of portfolio, including those for a small studio or agency.

Here are the highlights…

Snapshot

Who was the client? When did you work on this. What was the Date? What was your role? What was the value to the client? But keep this brief. This meta data way-finding is important when skimming through a portfolio.

Show a progression

Show work that didn’t cut it. Demonstrate your ability to change and iterate and show variance to get to a solution. This also demonstrates your graphic design capability, copywriting, and visual thinking.

Be honest

If you worked under a senior, say so. Talk about why projects might not have been completed. Honestly, if you bend the truth, it’ll catch up with you at some point.

Breadth

If your work is just a bunch of posters, of a certain type of client or work, then it’s easy to pigeon hole you. If you just design icons, that’s the type of work you’ll get. Demonstrate breadth, even if it means working on your own side projects or setting yourself your own briefs.

Fewer and better

Be very, very picky about what you show. If you only done three projects you are really proud of, then just show them. Talking passionately about how it went, what your contribution was, and what happened after it was finished will shine much brighter than ten single pieces of work. It’s easy to spot things made with care and love, even those commercial projects that fell short of the mark (and it’s ok to say that if you know the reasons why).

Walk the walk

If you can code, then demonstrate it. If you can’t, be clear about why you don’t think that’s applicable for your role and growth. Either way, conviction in your own abilities or not will tick boxes.

Work is more about pictures

The big difference between junior designers on the web and print is quite stark, but the more experienced you become, the roles become similar. It becomes less about pretty pictures, and more about facilitating a process from beginning to end. Think about how you can convey something before hand that isn’t a picture. This is where writing about your work trumps showing pictures. Because sometimes there just aren’t any pictures to show.

And, the last point I think nicely rounds off this post.

It’s the start of a conversation

This was applicable when I started my first job, when I ran a small agency, and now I work in-house at Monotype. Any portfolio is the start of a conversation. It needs to invite discussion, further questioning, and that all important call-back.

Going back to that stereotype traveller type, wandering around Asia with an extra 2kg in his backpack… Well, I arrived in Sydney. I had a very short list of studios I wanted to work for and proceeded in doing what I’d done before: making myself a nuisance until I had the opportunity to either leave my Book, or talk it through with someone. I managed to get the job I wanted with a great little company in Sydney called Spike. It was my first web design job. All thanks to Tom and his advice. And a sturdy rucksack.

A Design SDK

A software SDK is a set of tools that allows the creation of applications for certain software, or video games, or a hardware platform. A hit could be as simple as a bunch of APIs or software that talks to embedded or proprietary systems. An SDK is a collection of tools to make something with. It’s a leg-up for development. And they’re needed for design, too.

Guide me, don’t tell me

When working with identity guidelines, pattern libraries, or styleguides, the biggest pushback I hear from designers is ‘I don’t want to be this specific. Point me in the right direction, but don’t be prescriptive’. The chances of a pattern library or styleguide answering every design problem that comes along is slim, but providing an overall understanding of a system is probably the best position you can put a designer in in order for them to do good work. That, and providing them with the right tools.

Giving someone a design SDK may be better than asking people to look for, navigate and understand an entire website dedicated to your design language.

For example, let’s say you work for a large bank in their in-house design team. Your design language is years old and grown organically to become a place of internal collaboration for stakeholders and silos – not really the place for external suppliers. One day, you need to get a very small web project designed and your team is maxed out so you outsource it to a freelancer. Now you’re faced with a problem.

Your design language documentation and collaboration site is housed internally, behind the company firewall, and you can’t give her access. You try to collect some material together for her, but it takes all morning before you even have an idea of what might be needed. And then you can’t find the logo in the right format. All you really need to do is send her what is needed and nothing more.

All of this takes too much time. And a styleguide doesn’t solve the problem. A design SDK is what you need.

A style guide is about providing the right help for every use case all in one place. An SDK is about providing the right help for a specific environment. In software development, APIs may have middleware wrappers like a PHP and Ruby. But regardless of the wrappers, the endpoint is always the same: the software at the end of the API. In the same way, a Design SDK should provide an end-point — a design language — typically via different methods such as HTML and CSS, or Sketch files, or Photoshop files, or text documents, or InDesign swatches.

The key to this is to be where the designer is. Learn where your designers and design partners do their work and provide tools that help get your design language adopted in those tools.

The problem with style guides

Style guides can be great for documenting a design system and providing a way for design to be consistent across multiple projects, products and people. But they can also be a shackle for creativity. A firehose of difficult to navigate content that compromises clarity for brevity. The key thing with style guides is they rely on you going hunting for what you need. They are everything for everybody. They are pull rather than push.

A design SDK I’m talking about is push rather than pull. It’s given to you, and it contains just what you need and nothing more.

What would be in a design SDK?

The key here is to provide just enough for someone to get going with their work. For some projects, this may be all of the following, but for others, it could just be a couple.

  • Moodboards and inspiration
  • HTML boilerplate
  • CSS or Sass snippets
  • Template assets
  • Suitable example images
  • Icons in various formats
  • Licensed typefaces or links to the correct typefaces
  • Branding identity guidelines

It would be ideal for me if an SDK could be created on the fly for different people based on project needs. So, for example, for freelancer ‘A’, I don’t want to send them HTML or CSS as I know they’re not building anything, so I just send them mood boards and inspiration, image assets and branding guidelines. For freelancer ‘b’, a front-end developer, I send boilerplate, CSS, template assets and icons. I mix and match and provide the design SDK, rather than send along a URL and expect them to know what they need and how to use them.

‘Isn’t this just for big, in-house teams and projects?’

No, I don’t think it is. There were plenty of times when I ran my design agency that we could use a design SDK as a deliverable for a client. Because, after you have finished working with them, chances are they will need other people to take forward your design in one way or another. And maybe the client isn’t the best person to determine what is needed to do that. A design SDK would be a great deliverable to ensure design integrity is maintained after you move onto other projects.

Visual Design might be a thing

If you recall, a few years ago, I wrote about my belief that the term ‘visual Design’ was propagating through the UX community and the potentially damaging effect that was having on the problem-solving roots of graphic design practice. This was swiftly followed up by a longer piece for The Manual.

I’ve had a lot of comments from people since then – either agreeing or disagreeing (y’know, the web) but over the past six months or so I’m coming around to the idea that Visual Design might actually be a thing. It’s just incredibly rare and is dependent on a number of rarely addressed factors.

Following the problem

Michael Bierut explains in his piece ‘You’re so Intelligent’ that graphic design has long suffered from what he calls ‘Problem Definition Escalation’:

Like many designers, for years I used a tried-and-true tactic to hoist my way up the respect ladder, a technique I will here call Problem Definition Escalation. If you've listened carefully to the lyrics to "Gee, Officer Krupke" in West Side Story you already know how this works. The client asks you to design a business card. You respond that the problem is really the client's logo. The client asks you to design a logo. You say the problem is the entire identity system. The client asks you to design the identity. You say that the problem is the client's business plan. And so forth. One or two steps later, you can claim whole industries and vast historical forces as your purview. The problem isn't making something look pretty, you fool, it's world hunger!

This behaviour is everywhere I’ve looked and worked for my whole career. From designers to content strategists, product managers to researchers. Almost always though, unlike Mr Bierut, I don’t think this is a need to elevate ones self through any sort of professional low esteem. I like to look at this a different way.

This is a result of people trying to find the problem. It just so happens the problem is rarely the logo.

From board room to your users and everywhere in between

If you think of Visual Design as being on top of a stack of other activities and functions, it might look something like this:

  1. Visual Design
  2. Stuff
  3. Customer needs / Value proposition
  4. Board of Directors / Leadership
  5. Organisation environment / culture

‘Stuff’ of course is a big, fat catch-all for all other tactical product design and development.

Customer needs have to be balanced with the product value proposition and opportunity. This is built up on a capable and supportive leadership team. But the bottom layer is probably the most important of them all. The environment.

The environment has to be right for all of the other things to happen. Unfortunately, ‘environment’ or company culture is hard to define and replicate. But how we use processes – such as agile, or defining market opportunities, through to how you refer to customers and evaluate designs - is probably the most important of them.

The Problem Story

It wasn’t until I saw Leisa Reichelt talk through how the UK Government Digital Service team work – from the Creative Director through to the developers and researchers – that I saw a corporate culture and structure where Visual Design could be a thing. Why? Because the problems had been defined, researched, worked through, solved, iterated upon in the layers below. Doing this means that probing the problem results in answers quite quickly. And the more the problem is probed, instead of it all unravelling, it builds into a cohesive narrative. The problem has a story that can be easily tracked back.

Visual Design might be a thing

If the problem has a story that can be traced back, the environment is supportive, and answers are available, then I can certainly see instances where designers learn not to go hunting for the problem. And, thinking about it, I wonder if this behaviour is more probable in in-house work, rather than agencies? Why? Because agency designers are used to clients coming to them with bigger problems than they initially present. This is how agencies generally get more work from larger clients – we follow the problem and, together, make projects to address them.

But, anyway, back to visual design.

If the problems are solved. If the designer is used to not going hunting for the real brief. Then, and only then, I think visual design could be a thing. When a designer has the right information, is working on the right graphical problem where she can focus on, what Michael Bierut describes as:

our miraculous fluency with beauty, our ability to manipulate form in a way that can touch people's hearts… the gifts that matter, and the paths through which we create things that truly endure.

Yeah. Maybe that’s when visual design might well be a thing.

My Handbook – Environment

I’ve been doing a talk this year called ‘My Handbook’. it’s a rather silly little title for a bunch of principles I work to. They are my ‘star to sail my ship by’, and I’m going to start documenting them here over the coming months, starting with Environment – a post about how, for me, design is more about the conditions in which you work.

I’d describe myself as an armchair mountaineer. I enjoy reading about man’s exploits to get to the roof of the world, or to scale precipitous walls under harsh conditions for no other reason than the same reason George Mallory said he was climbing Everest: ‘Because it’s there’.

In any expedition to a mountain, great care and consideration is taken over the kit, the climber’s skill, the team around them, the communications, the list is seemingly endless. But, the biggest single factor in a successful trip are the conditions of the mountain. Will the mountain let them up. And back down again. Assessing the condition of a mountain takes experience, time and careful consideration; it may be snowing, too warm, too much snow on the ground, too cold, too windy. The list of variables is endless, but the climber considers all of them, and if necessary moves to adjust the route, or simply doesn’t attempt the climb.

Now, let’s shift to design – not necessarily web design, but commercial design of almost any kind. Let’s say you take a brief for a project, you begin the work and suddenly in the project, other stakeholders come on board and start to have comment on your work and direction on strategy that was unknown to you. We’ve all had projects like those, right? Suddenly, your work becomes less about what you may think of as ‘design’, and more about meetings, project management, account management, sales, production work. You know, all of those things that have a bad reputation in design. Meetings are, apparently, toxic. Well, I’ve started to look at this in a different light over the past few years.

As I’ve grown as a designer, like many, I’ve found myself doing less ‘design’. Or, rather, less of what I thought was design. Five years ago, I thought design was creating beautiful layouts, or building clean HTML and CSS, or pouring over typefaces for just that right combination. Now, this is design. But, so are meetings.

Experienced designers spend time making the environment right whilst they are doing the work. Because, frankly, you can push pixels around forever, but if the conditions aren’t right for the work to be created and received by the client in the right way, the work will never be as good as it could be. But, what do I mean by ‘conditions’? Here are a few practical things:

  • The physical space: I see a large part of my job as making the environment in the studio as conducive as possible for good work to happen. That means it’s relaxed, and up-beat. Happy people make good things.

  • A Shit Umbrella: It’s my job to be a filter between client and my team on certain things. Someone recently described this as being a ‘Shit Umbrella’.

  • Politics: Wherever you get people, you get politics – because people are weird. I spend a lot of time on client projects trying to traverse a landscape of people to understand motivations, problems, history or direction. Once you understand the landscape, you can assess, and work to change, the conditions.

  • People first, process second: We fit the processes to the people rather than the other way around. Our team runs things that works for us, but that’s the result of a lot of trying & discarding. Like tending a garden, this is a continual process of improvement.

  • Just enough process: I’m a firm believer in working to the path of least resistance. Being in-tune with how people work, and changing your processes to suit, helps create a good environment. But we ensure we impose just enough structure. To much, and it gets in the way. This doesn’t work if you don’t do the previous point, in my experience.

  • Talk. Do. Talk.: It really is true that the more we talk, the better work we do. We talk in person, on Slack, on Skype, on email. Just like meetings, there is an industry-wide backlash against more communication because the general consensus is we’re getting bombarded. But recently, we’ve been working to change that perception in the team so that talking, and meetings, and writing is the work. It’s tending the garden. Making the conditions right for good work to happen.

  • Making things is messy: This is actually another point from my ‘handbook’. Since the 1950’s clients and designers have been sold a lie by advertising. Design generally isn’t something that happens from point A to Z with three rounds of revisions. It’s squiggly, with hundreds or thousands of points of change. A degree of my time is spent getting people – clients, internal clients, the team – comfortable with the mess we may feel we’re in. It’s all part of it.

I see all of this as design work. It’s also my view that much of the disfunction from large agencies to other organisations is that this work isn’t being done by designers because they don’t see it as the work. It’s being done by other people like account managers who may not best placed to get the conditions right. Designers need to take responsibility for changing the environment to make their work as good as it can be. Sometimes, that means sitting in a board room, or having a difficult discussion with a CEO.

Mountaineering is so often not about climbing. You may do some if the conditions are right. Design is so often not about designing beautiful, useful products. But, you may do some if the conditions are right.

Collaborative Moodboards

Creating moodboards is something I was taught from a very early age. In primary school, they were a simple mixed-media way of expressing a form of an idea.

The thing I find interesting about mood boards is not the end-result, but the process of creation. Watching my children make posters from torn up bits of newspaper and magazines is really no different to watching my clients do it. Similar to watching other activities – such as affinity sorting, or depth interviewing – it's the listening that I find interesting. Every moodboard tells a story, and as a designer, listening to your clients tell that story when they make them can be very insightful.

Making moodboards for you, not for me.

I have to be honest, I don't make moodboards for myself. Not physical ones anyway. When I familiarise myself with a brand, or make some suggestions for design context, I always try to place those things in a context the client understands. This is where design visuals are important. They are almost unsurpassed in their immediacy of understanding for a client because they show the design in context. Of course, replace that with a high fidelity prototype, and you get the same thing. But, I want to step back a little here, as to when I find creating moodboards valuable.

Let me ask you a question: how many times have you heard this from a client?

'I'm not so sure I think the design is heading in the right direction'. 'It needs more pop'. 'It's just not us'.

These are all because a client cannot communicate about design at the same level we do. So, it's abstract. Either that, or:

'I don't like that green'. 'That button is great! But, it needs more pop'. 'The logo needs to be bigger'.

Then things get subjective and extremely detailed. Why? Because these are approachable things people can comment on. More often than not, these comments are a failing that should rest firmly on our shoulders. We need to give our clients the words and understanding to express their thoughts. Either that, or we tease out these issues earlier in the process, in a way that is abstracted from the design work that will come later. This is where I feel collaborative moodboards work extremely well.

So, why would want to try and run one of these sessions?

  1. When a client's brand is repositioning, sometimes we're brought in very early on the back of a strategy. No tactical work as been done. So, it's up to us to navigate the waters of implementing the branding strategy. Making design work on the back of a few bullet points in a slide deck can be challenging.

  2. Usually in a discover process, I will get a few red flags from speaking with a client. Generally these come through when talking about competitors, or things they like.

  3. When I get conflicting stories from different stakeholders. The homepage team has a completely different view on the branding than the marketing team.

  4. When branding needs evolving. A lot of organisations have mature branding collateral for print and advertising. Not so much for web (still!), so these are useful exercises to start to tease out differences or how they can align to the web in future.

I'm sure there are more, but those are few I can think of off the top of my head for now.

How to run a collaborative moodboard session

  1. Get the stakeholders in a room. 3-4 is ideal. 9 is way too many.
  2. Bring with you lots of magazines, newspapers, flyers – just physical paper stuff – that you can all cut up.
  3. Glue. Lots of glue. One tub each.
  4. Large (A1) pieces of paper.

The thing about this that I find interesting from a people-watching/behaviour perspective, is that the act of cutting things up and sticking them down is something that most of these people wouldn't have done since school. The process involves collaborating, getting stuck-in and discussing the work. I find it a great leveller for the client team (hierarchy quickly disappears), and a very good ice breaker.

You set the brief for the morning/afternoon (all day is generally too long for the making part of this process). The idea is to find content that communicates part of the visual story of the product – and that could be anything:colour, type, texture, image – and stick it down.

For the agency team, it's our job to ask questions throughout the day. To tease out the insights as people are in the moment of choice – before they've had chance to post-rationalise. And you know what? Answers like: 'I just really like this green' are great, because our next question is 'Why?' and it forces rationale. Without us being there, and asking that, almost always post-rationalising and 'business stuff' gets in the way of finding the truth behind those choices.

Quite often, just like cave paintings, moodboards are an artefact of a conversation. We often discard them from this point because they have served their purpose. We have the insights. The marketing team are best buddies with the homepage team. We all heading in the same direction.

So, next time you start a project and you need some steer on branding, or reconciling differences of opinion on a client team, try collaborative moodboarding as a way of coming together to try and solve the problem.

Responsive Web Design – Defining The Damn Thing

Unlike many design disciplines, web design goes through cyclical discussions about how to define itself and what it does – anyone who's ever spent any time in the UX community will know about this.

I was prompted to write about this from reading Lyza's column on A List Apart, and Jeffrey's follow-up post this weekend.

In 2010, I attended An Event Apart in Seattle. During that show, I saw three or four presentations – from Eric Meyer, Dan Cederholm, Jeremy, and of course, Ethan. All of them, independently, talked about how using media queries and CSS we could change the content using a fluid layout. It was a perfect storm, and indicative of the thinking that led Ethan to write – and A Book Apart to publish – Responsive Web Design a year later. The rest, they say, is history.

Responsive Web Design had a simple formula: fluid grids, media queries and flexible images. Put them all together, and your web product will be responsive. As Jeffrey said:

If Ethan hadn’t included three simple executional requirements as part of his definition, the concept might have quickly fallen by the wayside, as previous insights into the fluid nature of the web have done. The simplicity, elegance, and completeness of the package—here’s why, and here’s how—sold the idea to thousands of designers and developers, whose work and advocacy in turn sold it to hundreds of thousands more. This wouldn’t have happened if Ethan had promoted a more amorphous notion. Our world wouldn’t have changed overnight if developers had had too much to think about. Cutting to the heart of things and keeping it simple was as powerful a creative act on Ethan’s part as the “discovery” of #RWD itself.

The idea of responsive design has taken a few years to go from cubicle to board room. But now it is a project requirement coming directly from there. For the past eighteen months, at Mark Boulton Design, we've seen it as a requirement on RFPs. And with that, it brings a whole other set of problems. Because what does it mean? Hence, we have to Define The Damn Thing all over again. And recently, to be honest with you, I've stopped doing it. Because, depending on who you speak to, responsive web design has come to mean everything and nothing.

There are some who see it as media queries, fluid grids and scalable images. There are those who see it as adaptive content, or smarter queries to the server to make better use of bandwidth available. There are those who just see it as web design.

Me? I think it's just like Web 2.0. And AJAX. It's just like Web Standards (although to a lesser extent) and exactly like HTML5 (in the minds of those of you who aren't developers) and its rather splendid branding. Responsive design has grown into a term that represents change above all else. To me, responsive design is more about a change in the browser and device landscape. A change in how people consume content. A change in how we make things for the web. And responsive design is just the term to encapsulate that change in a nice, easy solution that can get sold to a board of directors worrying about their profit and loss.

'Responsive design is forward-thinking and means it will work on a phone, and that's where things are headed'.

We've heard this line time and time again over the past couple of years. You see, responsive design is a useful term and one that will stick around for a while whilst we're going through this change. How else do we describe it, otherwise? Web design? I don't think so. No board member is going to get behind that; it's not new enough.

How we work

I've had a few people ask me recently about how we work at Mark Boulton Design. And, the truth be told, it slightly differs from project to project, from client to client. But the main point is that we work in an iterative way with prototypes at the heart of our work every step of the way.

Work from facts AND your intuition

We always start by trying to understand the problem: the users of the website or product, the organisation on their customer strategy, the goals and needs of the project, who's in charge and who isn't. There's a lot to take in on those early meetings with a client. One of the first things we do is to try and put in place some kind of research plan: what do we need to know, and how are we going to get it.

This could be as simple as running some face to face interviews with existing or potential customers coupled with a new survey. Of course, good research should provide some data to a problem, not just 'what do you think of our website?'. Emma has written some good, quick methods for doing this yourself.

We couple that with trying to extract the scope from the client. I say that because, half the time, we're given a briefing document – or something similar – and most of the time that document hasn't been written for us. It's been written for internal management to sign off on the budget of the project. So, rather than ask for a new document, we run a couple of workshops to tease out those problems:

User story workshop

This workshop is designed to tease out the scope of the project – everything we can think of. We ask the client to write user stories describing the product. Nothing is off the table at this point and our aim is to exhaust the possibilities.

Persona / user modelling workshop

Personas have been called bullshit in UX circles for years now. Some say they pay lip-service to a process, or they're ignored by organisations. Whatever. I think, sometimes, something like personas are useful for putting a face to that big, amorphous blob of a customer group. Maybe that's just a set of indicative behaviours or maybe a lightweight pen-portrait of an archetypical user. The tool is not the important thing here, but how you can use something to help people think of other people. To help an organisation to think of their customers, or designers to think of the audience they're designing for, or the CEO to think in terms of someone's disability rather than the P&L.

What I find generally useful about running a workshop like this is that it exposes weaknesses in an organisation. If a client pays lip-service to a customer-centric approach, it will soon become very evident in a meeting like this that that's what's going on.

Brand workshop

This is a vital workshop for me. As a design lead on a project, I need to understand the tone of a company. From the way it talks about itself, through to the corporate guidelines. But, my experience is, that's only half the story if you're lucky. So much of a brand is a shared, consensual understanding in an organisation. Quite a lot of that can go un-said. This workshop is, again, about teasing out those opinions, views and arguments.

Bonus!

The first three workshops have the added bonus of finding out who runs the show in an organisation. I make it my business to find out – and get on side – the following people:

  • The founders / CEO. This should be a given.
  • The people with a loud mouth. It's useful to find the people who have a loud voice and get them around to our way of thinking. Then they can shout about our work internally.
  • The people with influence. Sometimes, these are the quiet, unassuming people, but they carry great sway. If we want things done, these people need to be our friends.

That's quite a lot of people to keep happy, but if we get these three groups on side, we find projects run a lot smoother.

Prototype your UX strategy

Leisa gave a great talk at last year's Generate conference in London about prototyping your UX strategy. The crux of this was it is way more efficient to demonstrate your thinking and design, than it is to talk about it. If you can quickly make something, test it, iterate a bit, and then present it, then you can massive gains to cutting down on procrastination and cutting through organisation politics like a hot knife through butter. Showing that something works is infinitely more preferable to me than arguing about whether something would work or not.

Wherever possible, we've been making prototypes in HTML. It gives us something tangible and portable to work with. We can put it in front of users, show a CEO on their mobile device to demonstrate something.

The right tool at the right time

I've spoken before about designing in the browser, or designing in Photoshop, or on pencil, or whatever. Frankly, we try to use the most appropriate tool at the right time. Sometimes that's a browser, but a client may respond dreadfully to that because they're are used to seeing work presented to them in a completely different way. Then, we change tack and do something else. My feeling is the best design tool you can use is the one that requires the least amount of work to use: be it a pencil, Photoshop or HTML.

agile not Agile

I feel that design is a naturally iterative process. We make things and then fix things as we go. Commercial design, though, has to be paid for. And so, in the 1950's, the Ad industry imposed limits to this iteration – 'you have three changes, then you must sign off on this creative'. Of course, I can understand this thinking; you can't just get a blank cheque for as many iterations as you like for a project until something does (or does not) work. But, what we gain in commercial control, I've found we've definitely lost in design quality. It takes time to make useful, beautiful things.

So, from about 2009, Mark Boulton Design have been working in the following way:

  • We work in sprints that are two weeks long. We never have a deadline on a Friday. Sprints run from Monday to Monday, with a release end of play Monday.

  • 'Releases' are output. Sometimes code. Sometimes research. Sometimes design visuals.

  • We front-load research into a discovery sprint. This is to get a head-start and give the designers (and clients) some of the facts to work around. Organising, running and feeding back on research takes time.

  • Together with the client, we capture the scope of the project with user stories. These are not typical Agile user stories – for example, we don't find estimating complexity and points, useful in our process – but they are small, user-centred sentences that describe a core piece of the product. It could be a need, or a bit of functionality, or a piece of research data. The key point here is, for us, they are points of discussion that are small and focussed. This helps keeps us arrow-straight when we prioritise them sprint on sprint.

  • We conduct research each sprint if it's required. This is determined by the priorities for that sprint. For example, if the priority for the sprint is focussed on aesthetics, or typography, or browser testing, then usability testing is not going to be of much use for those.

And now for some of the commercial considerations:

  • Contracts are most often fixed-price, but broken down into sprints. Each sprint has an identical price.

  • We bill as we go. The client pays a degree up-front, and that is then factored into cost of each sprint.

  • We explain to prospective clients how we work: each sprint, we work on agreed priorities, with no detailed functional spec to work against.

  • Points. In the past, we've worked on Agile agreements where we would be delivering against agreed estimated points. This was to see if we could make web development agile work in a project environment. It didn't. We found we were delivering to the points, rather than to the project. Plus, if we didn't hit the points for that sprint, we were penalised financially.

  • Coaching our clients through this process is as challenging as coaching through clients of a responsive design project. When the project is in the early-mid messy stages – when client preconceptions are being challenged, the prototype is not being received well by users – it takes a strong partnership to push through it. Design is messy. Iteration, by it's very nature, is about failing to some degree or another. Everyone has to get used to that feeling of things not working out the way they first thought.

  • The sticky end. When we get to the final stages of a project, we should be in a good place. The highest priority items should be addressed, we will have buy in and sign off from the right people and we should be focussed on low priority features. But sometimes, that's not the case. Sometimes, we've got high priority things left over which are critical. And that's the time when we have to go back to the client and discuss how these need to be addressed. Sometimes that's an extra sprint or two. Sometimes it's an entirely new contract.

What we don't do from 'Agile'

We don't do:

  • Estimating tasks. We don't assign time to design tasks. In our studio, work just doesn't happen that way. Generally, things are a bit more holistic.

  • Tracking velocity. For the same reason above, if we're not measuring delivering against user stories in a numeric way, we can't track our velocity.

  • Retrospectives. We don't run traditional retrospectives on sprints. Maybe this is more a symptom of a close, high-communication level of our team. We're talking all the time anyway. We have found that retrospectives have been a useful forum for clients to feed back on how they're feeling about progress in the past, but this has felt like a somewhat forced environment to do it. So, recently, we have points of checking in with a client to see how they're feeling about things.

So, that's about it. A whistle-stop tour of how we like to work. As much as possible, we've tried to tailor our process to what works for us, built on some useful structures that agile gives us. I guess the most important thing for us is that we're not wedded to our processes at all. We regularly shift focus, or the way we work, to meet the needs of particular clients or projects. Just as long as we align those processes to how design naturally happens, then I'm happy.

Al Jazeera & Content shelf-life

From speaking at the phenomenal MK Geek Night All Dayer, to launching a project three years in the making for Al Jazeera, the releasing a new design language for one of the oldest university in London, to Mark Boulton Design being nominated in four categories in the Net Awards. It's been a busy couple of weeks.

Last week, I was up in London visiting a client when I heard that another project of ours was to be launched shortly. It was part of a project we've been working on for just over three years: the global design language for Al Jazeera Network digital, with the first two products being launched in Turkey and a beta of the Arabic news channel.

There is so much to talk about on a project of this scale. Here are just a few highlights:

  • Spending time with journalists and the newsroom to understand how news is reported.
  • Working with Al Jazeera during the Arab Spring; from the uprising in Egypt to Libya.
  • Course-correcting throughout the project. Responsive Design wasn't really a thing three years ago.
  • Designing in four languages – Arabic, English, Turkish and Slavic – when the MBD team primarily speaks one.
  • Adopting an Object Oriented approach from content through to code. Modular, transferrable and scalable. It required a level of detailed thought right down to how content types were defined in the CMS.
  • Working with three development partners across three independent content management systems.

I could go on and on. And I probably will at some point. Needless to say, none of the above could achieved without a patient, smart and agile client-side team. Good job the Al Jazeera team are just that.

There are many buzz words you could label this project with: content-first, responsive, atomic, OOCSS. Again, I could go on. But the one thing that was first, central and always through prototyping and early strategy was good research. It was a research-first project. That probably won't come as a surprise to some of you given we have our own in-house researcher, Emma. What may come as a surprise, however, is the degree in which that early research led approach laid the foundation for a fundamental shift in how Al Jazeera thought about their content.

Content shelf-life.

Many news journalists think of their content as a few distinct types:

  • Rolling news: Typically taken straight from the wire and edited over time to fit the growing needs of the story.
  • Editorial: Longer form piece. Still highly topical and timely.
  • Op-ed: Opinion piece from a named author.
  • Feature: A story. With a beginning, a middle and an end. Long-form content, and not necessarily timely.

These can all be mapped to timeliness; both in terms of how long they take to create and their editorial time-life. The more timely a piece, the shorter it takes to create and the shorter the shelf-life.

  • Rolling news: timely, short shelf-life.
  • Editorial: timely, long-form, short to mid shelf-life.
  • Op-ed: Long-form, mid shelf-life.
  • feature: Long-form, long shelf-life.

Publication schedules are often focussed around this creation with journalists having several pieces of the different types in various degrees of completion to various deadlines focussed on different stories. This is a comfortable mental model, one that newspapers have been arranged around for decades. But it isn't necessarily how users of websites look for content. Users will not typically look for a type of content, but will look for a context of a story first: the topic.

The new information architecture of the Al Jazeera platform has been built around a topic-first approach. But also, the modular content and design allows for the rapid changing of display of the news as a topic or news story moves through the various content types. It's a design system, connected to a CMS that accommodates what news naturally does. It changes.

The Design System

The whole platform is built on top of Gridset using modular design principles. The content is modular and multifaceted, designed for re-use, as is the design. For years now at Mark Boulton Design, we've not designed websites, but an underpinning design system with naming conventions, rules, patterns. This is particularly useful when many CMS software thinks of content objects in this way. Our systematic thinking can applied all the way through CMS integration. Software engineers love designers giving them rules.

It's funny, we seem to have just discovered this in web design, but many other design disciplines have been approaching their work in this way for decades. Some for centuries. Take typography, for example. The design process of creating a typographic design is systematic thinking at its purest. Designing heading hierarchies and the constituent parts of written language can be approached in an abstracted way. This is exactly the right approach when designing for other languages.

Arabic has obvious challenges for an English-speaker. Not only is it written right to left, but the glyphs are non-roman. To approach this as a English-speaker, we needed to create tools and process to help. Words no longer look like words, but shapes of words. Page designs no longer look like familiar blocks of text, type hierarchy and colour. We saw form more than we saw function.

Just the start

Three years is a long time to work on a project. I'm so delighted to finally see the design system in the wild. For such a long time, we only saw it in prototype form, but you can only take prototypes so far. We needed to pressure-test content types, see where it breaks, adjust a hundred and one small details to make it work. All of this just underpins the fact that now the system is being rolled out, there needs to be changes made every day to evolve the system. This is the web after-all. It's a feature, not a bug.

Running ragged

In my fourth article for 24ways over the years, I wrote about typesetting the right rag.

One of the first little typesetting trips I was taught – in my internship at an advertising agency – all those years ago, was how to make text fit within a given space, but still read well. This involved a dance of hyphenation, letter-spacing, leading and type-size. But a crucial ingredient of this recipe was the soft-return.

Scanning a piece of text I was looking for certain criteria – or violations – that needed a soft-return (or, in Quark XPress, shift-return). Using those violations, I would typeset the right-rag of the piece of text, and then use hyphenation, and what-not, to tease the rag into as smooth a line as possible. All whilst ensuring the content was pleasurable to read. In a perverse kind of way, I always enjoyed this part of the typesetting process.

My article on 24ways is about how we can apply this thinking to the web, where the inherent lack of control on the medium means we have to apply things in a slightly different (read: clumsy) way.

Emma read the article this morning and pretty much summed up the way I feel when I read text sometimes.

“Another article by @markboulton which gives me a glimpse into how broken the world looks through his eyes” – Emma Boulton

Just like a musician listens to music, I view text in a different way to most people. I just forget that I do it most of the time.

I can hardly believe that 24ways has been running since 2005. In the web years, that’s like 72 years ago. It’s a credit to Drew, Brian, Anna, and Owen. It’s not easy running this year in, year out, on a daily publishing schedule for a month. Hours and hours of work go into this, and we should all be thankful for their time and effort. Oh, and let’s not forget Paul, who has given 24ways a lovely redesign this year (you can read more about that on his blog)

Design Abstraction Escalation

What are we losing by abstracting our design processes? Could it be as fundamental as losing a sense of humanity in our work?

A few years ago, Michael Bierut, wrote about a natural progression in a designer's career.

"The client asks you to design a business card. You respond that the problem is really the client’s logo. The client asks you to design a logo. You say the problem is the entire identity system. The client asks you to design the identity. You say that the problem is the client’s business plan. And so forth."

He calls this Problem Definition Escalation. Where a designer takes one problem and escalates it to a 'higher' plane of benefit and worth – one where it will have greater impact, and ultimately, make the designer feel like they're doing their real job.

Constituent parts

Designing in a browser, in your head, on paper, on a wall, on post-it notes. It doesn't really matter. What matters is the work. Is it appropriate? Does it do the job well? Will you get paid for it? Does the client understand the benefits?

Really. Who cares how you get there? We're all coming around to the idea that designing responsive web sites in Photoshop is inefficient and inaccurate (if things like web font rendering matter to you).

Let's look at the arguments:

  1. For those familiar with the tools, designing in Photoshop is just as efficient as designing in code.

  2. I design using the tools of least resistance. Preferably a pencil, sometimes Photoshop, and a lot of HTML. Photoshop is my tool of choice for creating website designs.

  3. Presenting static visuals to clients is different than using them as a tool yourself as a means to an end.

All of that is good news. Good for clients. Good for the work. Good for us.

A natural result of this is abstraction.


Design patterns are everywhere. The often-repeated chunks of content that we find ourselves designing and building time and time again. User's get used to seeing them in certain ways, and over time, perhaps their performance is hindered by deviating from the norm. We see this all the time on e-commerce websites, or in new user registrations. Over time, we all collect these little bits of content, design and code. They build up, and eventually they need organising.

Why not group them all together, categorise them, and iterate on them over time? Throw in your boilerplate templates, too. Maybe group them together as a 'starter kit' with included navigation, indicative content – for different types of sites like ecommerce, blogs or magazine sites?

And... wait a second, you've got all you need to churn out site after site, product after product for clients now. Excellent. All we need to do is change the CSS, right? Maximise our profits.

No. It's not right.

Conformity and efficiency have a price. And that price is design. That price is a feeling of humanity. Of something that's been created from scratch. What I described is not a design process. It's manufacturing. It's a cupcake machine churning out identical cakes with different icing. But they all taste the same.

Documenting things that repeat is an important thing to do. I have my own pattern library that I've been adding to for years now – it's an electronic scrapbook where I take snapshots of little content bits and bobs that I find interesting, and that keep on cropping up. It'll never see the light of day. I'll never use it on a project, because what I'm doing is building up a head full of this stuff so that when a problem presents itself, I will have a fuzzy recollection of something – maybe – that is similar. Instead of going straight to my big 'ol database of coded examples, I'll try to recreate this little pattern from memory – and that's when something interesting happens.

Recreating something just slightly differently – from memory – means you end up with something new.

That's why I wanted to be a designer, after all. To create new, beautiful things.

The Business of Responsive Design

Responsive design affects a lot more than just our website's layout. From content, and how it's created, to the structure of teams and organisations can all be affected by the processes responsive web design brings.

This post is a rough transcript from my talk at Handheld Conference last week in Cardiff on just that.

Opening slide for talk on the Business of Web Design

I've a confession to make. I'm an armchair mountaineer. I'm too much of a coward to actually put myself in the type of risk mountaineers do, but for the last decade or so, I've been reading as many mountaineering books as I could get my hands on. And I'd like to start by telling you a famous story of Alpine mountaineering.

The Eiger Nordwand in the Bernese Alps in Switzerland. An 6000 ft, vertical, concave face perpetually shrouded from the sun. Facing North, the Eiger's north face has been the scene of some of the Alp's greatest mountaineering victories, as well as perilous catastrophies.

The North face of the Eiger

This is the North Face of the Eiger in the Bernese Alps in Switzerland. The Eiger (meaning: Ogre) is a staggeringly difficult face to climb. Nearly two vertical miles high of ice-coated loose rock. It's a treacherous place. It's also the place I proposed to my wife in 2003. But that's another story. The story I'm going to tell you starts in 1936.

Andreas Hinterstoisser, a talented German climber, in the meadows below the Eiger enjoying the sunshine.

Andreas Hinterstoisser

In the winter of 1936, Andreas Hinterstoisser (pictured), Toni Kurtz, Willy Angerer and Edi Rainer set about tackling the face of the Eiger – then unclimbed. They'd established the rough route, and after a day had reached an impassable, sheer area of rock just underneath the Rote Flüh – a prominent feature on the face.

Let's leave that story there for now and come back to it later.

Let's talk about responsive design.

Responsive design has changed my work and, ultimately, how I do business. This talk is about how it's done that. But before I do that, I'd like to tap about the definition of responsive design.

If you talk to some people, responsive design is just fluid grids and media queries. To other people, it's that your website fits on a tablet or mobile phone and changes to adopt. To others, it's the way to save money by consolidating teams. Responsive design – like AJAX, or Web 2.0 – has become a buzz-word to represent a change. A change in our industry. A change in the way people are consuming content. That's the type of responsive design I'm going to talk about.

I'm going to talk about three specific areas of how it has challenged the way we work at Mark Boulton Design.

1. Structured content

It's strange to think that there was a time on the web where content was a second-class citizen. As a student of editorial design, I've always found this odd. In the past, whenever I heard 'content is king', my response was generally 'er, yes'.

Responsive design has challenged how we commission, create, edit and design for content. I'd like to talk a little bit about how this has affected two clients of ours. Firstly, our work with CERN.

Different content for different people, at different times, on different devices.

I've talked about CERN before at conferences, but not really in this amount of detail. When we started working with CERN a few years ago, the whole project was framed in one sentence by the head of the CERN web team…

We have a content problem.

And they did. They didn't really know who their audiences were, how to talk to them, or what they wanted. Following months of research, it became clear the audience for the CERN site was comprised of students, scientists, the general public and CERN staff. Interestingly, all of those four large groups had a common need: updates. They wanted to know what was going on. But here is the problem: each group of people needs to hear the same update in different ways. Let's take an imaginary use-case of an announcement for a new particle that's been discovered.

For the general public, they are generally learning a lot about CERN from elsewhere. Not on the CERN site. So, they are coming to the site from another trigger – either another website, or the TV, or a magazine or newspaper – and their overall comprehension of the work done at CERN is minimal. The update needs to be worded to accommodate that. But that update also needs to appeal to scientists working in high energy physics and associated fields. They want the detail, in the language that suits them. Already, our one update is fragmented. Throw in students and educators, then our update is going to have to work very hard if it's just one piece of content.

Therefore in the CERN redesign process, the editorial structure of updates needs to be fragmented and structured in such a way to accommodate different words for different audiences. A responsive design challenge that has nothing to do with how something looks, but how it is structured and how it works in the CMS.

This brings me onto my second point on structured content.

Fractured content

We've also been working with Al Jazeera for a few years on redesigning their digital platform. Throughout that process, in just that short space of time, we've seen the rise of responsive design and how it affects how content is created and viewed. One example of this is just the process of how news works.

We often think of a news story as a page. A useful, familiar construct. It has a headline, a stand first, some paragraphs and maybe an image or a map. But after studying how their editors work, it became clear that this is not what a news story is. News is always moving.

Drawing of a seed

A story starts as a seed. Something that comes down the wire…

There has been an earthquake in Japan.

Nothing more. Not yet.

Content starts as a seed. Something small. Then grows over time to pull in various content types.

Diagram showing content being pulled together

Then, over time, the story grows and, like a snowball rolling down a mountain slope, more content starts getting attracted to it – maybe a tweet, other articles, images, video, timelines, quotes etc.

Because a news story is not a page. A story is the link between bits of content. The question here is how do we – meaning editors and designers – curate and cajole this content to most effectively tell the story?

Meta Data is the New Art Direction

The answer does not lie only in design. The answer lies in how content is structured and categorised. Meta-data is the new Art Direction.

2. Process

Responsive design has been perhaps most visible in its ongoing challenges to process. How we do what we do is coming under increasing pressure, and here are several ways in which I've noticed how.

Proximity

I started out working in advertising. As a student, I was an intern for a couple of years at an agency in Manchester. Other than the work, one of the things that has become clear now I run my own design business.

When advertising agencies talk about work, they talk about it in terms of accounts, not projects. When you win work, you win an account – for a period of time. An account is commitment over a period of time.

We will work with you on all our projects for 12 months.

This means a client will invest in you, and the time it takes you to learn their business, familiarise yourself with the challenges and give you the space (and budget) to do great work.

Projects are not a commitment. Projects are relatively risk-free.

You will deliver this website for this much money in this time-frame.

Approaching work this way leaves little room for any ongoing commitment, from client or agency. It's like a first (and only) date. And with that comes a distance.

Over the past couple of years, I've seen my peers move from agencies and studies move to products and client-side. In doing so, they are closer to the problems. With the space to move in an agile way without the constraints of any binding commercial relationship. This reminds me of a story from Kevin Spacey about his work on the House of Cards

Kevin Spacey recently gave a rousing talk at The Telegraph in which he talked about how TV commissioning works in the US. He went to all the networks in the US to pitch the show. They were all interested, but each one wanted to do a pilot. A pilot which, in 45 minutes, would establish the major plot-lines, introduce the characters, the love-triangle, the cliff hanger.

Kevin Spacey delivers one of the best talks I've ever seen (oh, to be an actor with this sort of delivery!) about why and how the House of Cards was commissioned on Netflix.

"It wasn't through arrogance that we weren't interested, but we wanted to tell a story that took a long time to tell. We were creating a sophisticated, multi-layered story with complex character that would reveal themselves over time and relationships that would need space to play out."

The House of Cards was about the long game.

To me, many web projects can feel like a pilot. Relatively low risk, low on commitment to work together without the time and space for the problems to play out. Proximity to the problem – a hand forced by responsive web design's challenges – comes from working closely, over a long period of time. An account, not a project. A season, not a pilot.

The project rope-a-dope

In 1974, Muhammad Ali and George Foreman fought in the 'Rumble in the Jungle' in Africa. Forman was the favourite having beaten Ali three years before. he was strong. Young. And a great boxer. He was sure to win.

Muhammad Ali vs George Foreman in the 'Rumble in the Jungle' in 1974.

Muhammad Ali vs George Foreman

Throughout the fight, Ali let himself get hit on the ropes. To give the impression he was tired, lose, and close to defeat. All the while, he was whispering in Foreman's ear 'You've got nothin''… 'nothin''. Forman blew himself up trying to knock Ali out. In the dying moments of the fight, Ali knocked Forman out and won the fight. This technique was coined the 'rope-a-dope'.

Just going back to my last point for a moment. One of the results from being closer to the problem is that you have more exposure to the mess of design. Making things is messy. And to some people – especially clients, who can expect nice shiny things handed to them – may not be expecting to be exposed to that.

Sometimes they will freak out. And it's our job to sit back on the ropes and take it on the chin. But, instead of goading them, we should offer words of reassurance. We should shift our process to something that may feel more comfortable. You have to break a few eggs to make an omelette, after all.

Where is the design?

Getting in the browser sooner. Looking at content sooner. Iterate. All of these things have a knock-on to design and how it's received by a client.

The Fidelity Curve. As a project time-scale increases, so does the fidelity of the design work being done.

The Fidelity Curve

For a few years now, I've talked about the fidelity curve. A simple graph to explain to clients that over time, we increase the fidelity of a prototype and slowly layer on the visuals. This is so we can fail quickly on low-risk, low-fidelity work. Mostly this is good and works well, but recently, I had an interesting discussion with a client in which they asked where the design was.

It's an interesting question, because in this process, the design is everywhere. And unless you take the client along every step of the way – knee deep in the mess of design, being closer to the problem – then how do you manage the expectation that, at some point, a client will expect a presentation, or a reveal' of how the product will look.

3. The Trend

"I want a responsive…"

As I said, responsive design is a trend. Or, rather, an awakening. As such, a lot of organisations and businesses are behind the curve . But one thing many people aren't asking (and, I know this because I ask) is 'is it worth it?' or 'Do you really?'

In 2011, our first responsive site was a site for World Skills London. It was a fun project, geared around a single event in London in which 200,000 visitors would attend and watch the various activities in the competition. As part of this project, we designed a responsive map. A cool diagram with a responsive image map that would scale and allow users to get from A-Z in the event by using their phone. Cool.

The World Skills London 2011 Map

Except, during the project retrospective, it became clear that, actually, only 25 people used it. It was not needed.

Back to Hinterstoisser

Let's go back to the Eiger and Hinterstoisser and three other men trying to climb the North Face. If you recall, after a day or so, they had arrived at a seemingly impassable face of rock under the Rote Flüh. After much deliberation about trying to re-route, Hinterstoisser decided to have a go at traversing the feature. And he succeeded, and with that, opened the gateway to the rest of the face and rest of their climb.

The Hinterstoisser Traverse on the North Face of the Eiger is a 150ft pitch of vertical, and often ice-glazed, rock. Now, with a fixed rope in place, the traverse was undertaken by Hinterstoisser by tensioning a rope high above him and traversing downwards and across.

The Hinterstoisser Traverse

Today, the same traverse is still used across the same slab of rock.

Last week, I did a survey on Twitter about the business of responsive design. After 500 or so responses, it's clear that everyone is finding everything hard right now. The change is so big, and so rapid, that we're struggling to keep our heads above water. And this especially goes for those working in-house or clients.

Breaking new ground is always difficult.

But, just like Hinterstoisser, take heart in knowing that what we're working on right now is a legacy for designers and developers in the months and years ahead.

The Lull

There is a storm coming.

For those of you reading this who have experienced a severe weather event know all too well the sequence of events leading up to it. First, there is a warning – either through the media, verbally, or from the old woman in town who can feel it in her bones. Then, there is the sense of it coming, and that can take minutes, hours or days. Either way, there is a feeling of calm before the havoc. Battening down the hatches, preparing your self, property, business and family. Preparation is important in surviving something potentially catastrophic.

I read a post today from the Karen Mcgrane called Responsive Design Won't Fix your Content Problem. It was nicely validating for me reading what mirrored so many of Mark Boulton Design's clients, especially over the last eighteen months. The post describes the difficulty organisations are with adapting to their digital content being published across a variety of channels. Reconciling that against existing business and technology structures is hard for big organisations but, in my experience, that's what's been happening for the past years.

Responsive design is our storm. Acknowledging the way the web really is, and reconciling it against the plethora of new devices and reading behaviours has been a seismic shift in the creation and reading of digital content. Organisations have been spending the last couple of years coming to terms with it.

Quoting Karen's article from a recent project she was working on:

Our executives assume that since they made the decision to go responsive, every other decision would just be tactical details. In fact, implementing responsive web design raises issues that strike right at the heart of our business and the way we work. We need to fix our review and approval processes, our content management system, our asset management system, our design standards and governance. We need to clean up our outdated, useless content. But it’s hard to get people to step up to solve these bigger problems, because they don’t think they’re part of “responsive design.”

This exactly mirrors my experience.

What starts out as desire to change for the better, to make a web product responsive, is the start of problem escalation. Before you know it, organisations are talking about needing structured content, but to do that they need a new CMS, but to do that, they have to procure a new CMS and migrate content. Now, that's not all bad. Organisations have been doing this. Preparing solid foundations on which to create digital experiences for wherever the user may be.

The storm. The critical mass of creating content for an increasingly broad digital space is just around the corner. Are you prepared?

WYSIWTFFTWOMG!

I get the content in Word, copy into the various boxes in the CMS and then see how it looks. Normally I spot a few typos, or it doesn't appear where I want it to, then I have to go back and find the article again – which isn't so bad, it's normally at the top. The real pain is when I have to add another link to that list over there. (whispers) Normally I ask James (a developer) to do that for me, though as I can't do it.

This was a conversation I had with a person recently about how they use their CMS. A real-life content person. I say content person, not 'creator' as you may have noticed she doesn't write the content. She just 'gets it'. She's a piece in the publishing workflow. A cog in a machine. And our tools are failing her and are only going to get worse.

In that workflow, there is a bit that's a clear trend amongst the people I've spoken to about this.

then see how it looks.

And that's the thing, right there.

Since we've been using computers to make websites we've tried to make them like print. Of course, early on, that was fair enough. It was familiar. We knew the rules and tried to make the web like it. Even now, with the realisation that the web has changed – or rather, we're being honest to the way the web is. It never really changed, we just tried to make it something it wasn't – we're still enforcing a print-like mental model on it. Not necessarily us designers and developers, though. This is coming from people who write and manage content. Just like printing out an email before they send it, they will want to preview a website to see how it looks.

The problem is this: The question content people ask when finishing adding content to a CMS is 'how does this look?'. And this is not a question a CMS can answer any more – even with a preview. How we use the web today has meant that the answer to that questions is, 'in what?'.

WYSIWTFFTWOMG!

Let me first off define what I see WYSIWYG. WYSIWYG is not a limited toolbar for adding semantic value to your document. The kind of toolbar you find on Medium, or on Basecamp. As you can see they are similar. They are used for applying semantics to document structure; giving words emphasis, making unordered lists, or numbered lists, making words headlines. However, they're not there for the user to get creative. They do not change the colour of a word.

When I think WYSIWYG, I think of the Word toolbar. This type of WYSIWYG is for adding tables, images, forms, type and colour. It's a toolkit to create pages of content. Just like desktop publishing. And that's the dangerous thing. Content creators are used to having these tools at their disposal so they can craft their document. Why? Because writing isn't done in a CMS, it's done elsewhere.

Times -are changing- have changed

It's been a turbulent few years for web designers and developers. We've had to relearn what we've created and finally acknowledge – through the timeliness of Responsive Design – that the web is a fluid and chaotic place, and we should be embracing it and not making it like print. We've learnt to deal with the loss of control. The problem is, though, our content people are still thinking of pages. They're still thinking of previewing. Of designing for the desktop. They're writing in Word and fine with it.

So, that's the challenge. How can we help people – just as we have – relearn how the web is now?

Just like when people have a content management problem, a lot of people are turning to technology for the answers. And just like content management problems, my experience is software can't fix it. Because it's a people problem, not a software problem.

The three places of content management

There are three spaces * for content people – not creators, because not all content people create loads of content. Some just manage it – push it from here to there. Those places are:

  1. A space for writing. For writing and structuring.
  2. A space for management. For adding meta data, workflow, configuration and managing roles and people.
  3. The website space. Basically your website. A place where you begin the access user journey. Or preview your content. Generally the starting points for lots of little administration tasks.
  • There are other spaces, too. The developer space, where the site is administered and created, managed and evolved. Sometimes this is through an administration interface, but not always. Sometimes it's just through an API.

The problem I see is that the CMS tries to deal with all three spaces equally well. And as such, generally fails to deliver an optimal experience because it's trying to do too much. What if your content management system was actually three distinct applications designed to work together? Just a thought.

But, back to WYSIWYG.

The issue with WYSIWYG for me is that by using them the content person is considering the content as what they see. But content is more than that. Especially if it has meta data, and is split up and compiled from here and there. A 'page' maybe a dynamic template pulling in content from a dozen places. How do you change meta data there?

If we consider the majority use-cases of correcting typos, restructuring slightly, or small on the fly editing, then the smaller toolbars for adding semantic value are useful. But for most use cases, a WYSIWYG is not useful for content people. It's just familiar.

Inline-access, not inline-editing

One of the other pain points of a complex dynamic website, where 'pages' are created with bits of content from all over the place is 'where the hell do I go to find that bit of content to edit it?'. That is a painful moment in a content person's daily life. Normally, after watching them, they go off deep into search, or ask someone else who knows better. Accessing these smaller nuggets of logic-based content is problematic. This is why inline-editing and WYSIWYG is coming to the fore – addressing the use case in the live environment.

Why is this a problem?

As I said before, it's hiding the truth. That being, the content is more than you can see. Instead of inline editing of the content, why not just make the start of that journey a little easier? Why not provide a way of quickly getting to exactly that bit of content with a link? There we will see all of the stuff that is the content but not the words: the display logic, taxonomies, meta data etc. But if we want to change a type, we can do that with our little toolbar.

Not one tool, but many. Not one way, but many.

Structured content is the right way to go. It makes our content portable and malleable. In fact, it makes it much more useful. Slapping a WYSIWYG on top of a form field is not the way to go. That's not structured. Live WYSIWYG is not the way to go for large-scale websites because it reinforces that content is just what you see. When, in fact, a piece of content could have a whole bunch of other headlines and summaries that would only be displayed in certain contexts, along with meta data and rules. We need access to ALL THE CONTENT and provide simple, little tools to let people make typo changes and apply semantic structure and the like once they're looking at the content in a staging environment.

'How does this look?'

should change to:

'How does this read?'

Device agnostic. Screen size independent and devoid of design. Let's help content people focus on what the words and pictures are, rather than what the words and pictures look like.

I'm not a Craftsman

My uncle is a quiet man. He smokes a pipe with a wry smile. Like he knows something you don't. For years he restored traction engines; huge, victorian, steam-driven machines. He did it for the love of it. I have wondered if he did to escape. Like a lot of men that age, he spent a lot of time in his shed on his own, surrounded by the smell of oil, grease and pipe tobacco. A dusty pile of tabloid newspapers in the corner. Slowly whittling away on a small piece of metal, making some grommet or flange or something.

Sounds romantic doesn't it?

Now, how many times have you heard web designers and developers talk this way about their work? For me, it's been increasingly. And personally I find it concerning. For starters, it's a designer-centric way of working. It's a selfish exploit to pour love into your work. If you're working commercially, who pays for that time? You? Well, that's bad. The client? Well, that's ok if they see the value. But many don't.

Giving your work love is not just about giving it time. But, time can often be better spent than whittling away on some nubbin' or grommet just because you think that's where you can give the work your love. Your craft.

Over the past few years, I've spent more time on projects not whittling. Whittling happens in the very latter stages of work and I really don't find myself in that place very often. Mostly that's because the clients I work for have a myriad of big, sticky problems that need working out before you start 'crafting a user interface', whatever that means. I'm more often than not in a place where my own job, as a designer, is to not make something I love. But to make something appropriate. Something that does the job well. Something that responds to a hypothesis and serves a need. Not necessarily something loved and beautiful. And that's ok.

Craft is an emotional word not appropriate to describe the job of designing. It's too self-centred. Too mired in arts and crafts and puts a difficult-to-measure parameter into the minds of clients.

'I want a beautifully crafted interface from a passionate designer'

Translates to:

'I want a self-centred designer to spend way too long on the shiny than actually solving the problem or having the difficult discussions'.

If my uncle was restoring traction engines for a living, he would've been out of business. Craft is love. And love takes time. And time is scarce and probably best spent elsewhere.

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

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.

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.

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.

Wikipedia example showing icons in list items BBC example showing icons in list items

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.

Example Sparkicons showing full screen and external site behaviour

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.

Example Sparkicons showing comments and video

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

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.

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.

Canvas In

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.

Content Out

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:

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

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

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

Design Principles

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.

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

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

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

Doing less

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.

Goodbye, Ceefax

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.

Ceefax screen

Ceefax screen

Ceefax screen

Ceefax screen

Ceefax screen

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.

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.

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.

My friend, Karen Mcgrane, talks about adaptive content. If you haven't seen her talk of the same name, go and watch it now, then come back.

Go on.

Seriously.

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"

She cites NPR as an organisation who has taken this to fruition with their publishing methodology: COPE: Create Once Publish Everywhere.

Daniel Jacobson, then from NPR – now Netflix, says that:

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

He continues…

"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?

Open letter to W3C CSS Working Group re CSS Grids.

Since I'm knee-deep in grids at the moment – both the book and Gridset – the theory, and thoughts on how it could and should apply on the web, is very much at the front of my mind. Last night I had a reminder on Twitter of the upcoming CSS3 Grid Layout draft. I recalled I wrote about it last year proposing some slight amendments regarding the addition of the module attribute. This would be a big change. It'd be great if it were considered, but I'm not hopeful.

However, that change not withstanding, one thing that really needs to change in this draft is the terminology used. Terminology (with some slight interchangeable differences) that has not really changed for many years in grid and layout design. Why reinvent it? Why define existing terminology to that more suited to spreadsheets and tables?

So, this morning, I emailed the working group to consider these changes. I'm posting this here for those who are not on the working group who may have opinions on this who can get in touch with me. I'd love to hear your thoughts, concerns and questions regarding this draft and how it fits with the established graphic design theory. I am of course on Twitter, or you can email me on this site.

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: http://www.markboulton.co.uk/journal/comments/rethinking-css-grids

Thanks for your time and consideration,

Mark Boulton

Responsive Content is not a thing

Last year, I spoke at New Adventures about A New Canon: three rules by which we can create modern websites. At the start of that talk, I spoke about responsive design. Not Responsive Web Design, as such, but the practice of responsive design more generally.

To summarise: responsive design is a design approach whereby a design system has three components: a sensor (a thing that senses stuff, whatever that may be); a design system (that takes the sensed data and applies system rules and logic); and then an actuator that actually does stuff that the design system tells it. A simple example of a responsive design system is your central heating in your house or apartment. A thermostat senses the temperature. Normally, this thermostat also has a bunch of programs in there (a design system) that tell the boiler (the actuator) to turn the heating on or off.

An understanding of this, and how it relates to web design –- and specifically at this time of responsive-adaptive-mobile-contentfirst-progressive time –- is useful for us. Why? Because responsive design is an emergent practice outside of the web –- notably in architecture, but also in environmental design and engineeering. And when things are so confused right now, semantics matter.

Responsive Content is not a thing

Recently, I've been hearing rumblings of content being talked about as responsive or adaptive – mostly in the mobile context. 'If I'm near a thing, maybe the content on a website changes to tell me that'. That's great! Of course, that would be useful. But it's not the content that is adapting there. The content isn't doing anything. It's just static. The content is being controlled by a responsive design system. Let's break it down:

  1. Sensor: In this case, it would be location. Something on your device is letting the web site or app know where you are.
  2. Design system: The logic in the code that takes the sensed location data and does stuff with it. This could be a CMS or some other type of publishing system.
  3. The Actuator: The code that tells the system to swap out the content for something that is of more value for you. This could be a bunch of technologies from server-side changes, or client-side.

Nowhere in that system is the content doing anything intelligent. It's just existing in different forms and being pulled in based on the Design System's rules. And that's the thing.

Dumb(ish) content

For great responsive design systems, we need good output. The output that we're lacking at the moment are the fragments of content that Karen McGrane talks about. Content that travels around with a set of rules or meta data that will allow responsive design systems to make good use of them. But this does not make this content responsive. On its own, it's pretty dumb: just floating around with additional information attached to it, until some smart design system grabs it and displays in the right context.

I've been working with a news network for about eighteen months now on doing just this. And it is incredibly difficult to even come close to making it work. Why? Well, in a high pressured newsroom, it turns out that people don't generally have the time to re-write the same story umpteen different times for different contexts and outputs. Let alone add the meta data differences to each one. And that's just a process problem. What about the tech? What about the design?

I guess this is a post about being careful about tacking on trendy adjectives to a process that organisations have been trying to do -- and generally failing -- for a long time. We need to be careful about the services we sell to our clients and the industry in general.

Digital Patina

The opening scene in Jaws still gives me goose-bumps.

It's a dark, moonlit night and a group of increasingly drunk teenagers are sat in the dunes playing guitar and listening to the crackle of a camp fire. You can almost smell the smoke and pheromones.

Chrissie, and her would-be admirer, take off for a swim. Where she is promptly attacked, and eaten, by the star of the film. That first scene is horrific. Mostly because it seems so real. The actress is crying, screaming and writhing in completely believable pain. That's because -- according to some -- she was. The frame that was holding her was attached to the sea floor and then two ropes were taken up to the beach where teams of men pulled them back and forth. Apparently, she broke ribs in that scene.

It's over an hour before we see the fish in Jaws. And that was accidental. Everything broke. 'Bruce' -- the name of the fish -- just broke down all the time. The film we see, when we watch Jaws, is not how it was intended. Instead, the music was the fish.

Jaws is coming up for thirty years old. Over that time, Jaws has aged well. What I find interesting is that the 'Patina' of the film didn't rely on fancy technology. Accidently, it relied on being honest with the materials it used: sound, light and great acting.

We talk about Patina as sheen -- a thing that changes appearance over time. That change can be damaging, or it can give an object more value. It does this by demonstrating what it's been through. In the case of a pair of jeans, it's the little rip, the pen mark, the small hole that's been repaired in the pocket.

In chinese cooking, a wok is seasoned to make it non-stick. A well seasoned pan will go beyond simply making the pan non-stick. It will impart flavour to the food in what the Chinese call 'wok hey', or 'breath of wok'. You see, to me, Patina is more than surface level sheen, or the aging of something. It's the flavour. It's an individual 'taste' that can only come from that thing. Not all woks are alike. This one is mine. And all that.

Working with this definition of flavour as a Patina -- which is imparted over time -- got me thinking about digital products. The problem with digital products -- our websites, applications, phone applications etc -- is they don't age the same way as some physical things. They either don't age at all: locked in a permanent state whilst the world changes around them. Or they age in the same way plastic does: slowly decaying into tiny chunks that float about for eternity. Always there. Never to be used. Of little significant value. You see, producing digital products is not a sustainable practice.

How can we impart a digital patina on the things we use. What is the flavour of an application? Iteration? Code? UX?

I believe digital patina can be achieved in products that are designed to last. Built honestly, using the true materials of the web and minimal on cliched skeuomorphic concepts. Being true to our materials will produce better, more sustainable stuff. Stuff that will age well. Stuff that will become more useful and more beautiful with age. How can we impart flavour to our work?

Let's stop designing things that turn into little bits that float about. Always decaying.

That's a sad story.

It's Not Working For Me: #crit

"What we have is bricks. I don't see a house, yet."

Don Draper

I started 'formal' art and design training when I was about fourteen years old. I took Art as an option at secondary school and progressed to an exam when I was sixteen. For some reason, I then decided I wanted to be a Forensic Scientist and pursued the sciences as a route to doing that. Big mistake. I failed, and went back to Art and Design for the next 7 years; ending up with a degree in typographic design.

In the middle of all that time, I did a one year course called 'Art Foundation'; a gateway course into University. I went to a good school to do this: one which had a long, traditional history in Fine Art. As part of the course, we were given an project to do over the preceding summer. This was a 'reinterpretation' project: taking a familiar work of art and recreating it. I chose to repaint the Madonna dal collo lungo by Italian painter Parmigianino but to recreate it in post-impressionist style similar to Paul Gauguin. I toiled over this painting all summer using oils and just a palette knife. It stood a little over three feet high and in parts was over a centimetre thick in paint. It was a labour of love.

The day came when I started the new course: a Monday in September. It was sunny in Stockport, and my Dad had given me a lift to the college with the painting stuffed in the back of the car. I was nervous. In fact, I felt a little sick.

The intake that year was about sixty five students or so. All of us were of a certain standard as we'd had to be interviewed and accepted onto the course, but standing there I felt crippled by self-doubt. Pinning my painting on The Wall, the lecturers proceeded in walking the length of the wall observing the work like a doctor quietly observes sick patients in a hospital ward. And, as it turned out, the prognosis wasn't good.

"Hello everyone. Welcome to Stockport Foundation Course." Said the head lecturer.

"Please come and collect the work you've just put up and throw it away."

You can imagine the looks on our faces. Thousands of hours had gone into this work. There were tears, anger, but mostly just disbelief.

"On this course, we want you to unlearn all you've done before. It's crap. We're not here to teach you how to draw. Or paint. Or sculpt. We're here to teach you how to look and how to think."

And with that, we were divided into groups and sent to various rooms to start the course. Every couple of days – extending to every week – all of us got together in a room, stuck our work up and had it ripped apart by the lecturers. It was like bootcamp. People left (about 20% of the intake). People cried every two weeks. But slowly over the weeks and months, we all learnt the Rules. The public critique (crit, for short) had rules and a framework. It wasn't personal: everything was about the work. We learnt to take harsh, harsh comment from lecturers and peers alike. We learnt not to take things quite so personally. Our defence mechanisms were tempered.

In Work

My first professional job, whilst at University, was an internship with an advertising agency over summer. I worked in the studio learning what it was like to be a junior designer. I worked in the cutting room inhaling way too much Spray Mount. I learnt what it was like to critique work in a professional environment.

Critique at work is different to what I was used to. All through my design education, critique was a discussion: sometimes harsh, sometimes heated, but was always a multi-way thing involving lecturers and my peers on the course. All with the aim of taking the work as far as you could. And in academia, you had time. In a professional setting, time is at a premium: my time, my Creative Director's and our clients. Time is, quite literally, money.

Professional critique still operated within the rules, though. It wasn't personal, it wasn't dictatorial: it was about efficiency. I lost count of the amount of times my Creative Director looked over my shoulder and immediately zoned into an element of the content that was causing problems.

"That's not working", he would say. Sometimes he'd walk off leaving you to sort it out. Other times, on asking why, he'd sit down and go through the problems with you. Design critique from an experienced designer is efficient, clear and without ego.

Over time, I found my academic critique 'muscle' atrophying. I find long debates over whitespace, or interaction patterns, or whatever, quite tedious. In my job, I have to do what my old Creative Director did: identify a problem very quickly and steer the design in the right way. Sometimes suggesting, sometimes telling, but always within the Rules of critique.

Web Designers

There are many designers in our industry who have never attended traditional design school. I feel there is a glass ceiling for people who haven't, and one of the aspects of that is design critique. Design critique is a learnt skill. It's something you do within an academic environment where you have the time and the space to learn it without the fear of losing your job.

Many web designers have learnt their craft to an exceptional level but lack the personal contact with an experienced designer who can conduct critique in the right way. Distributed teams are a problem, in this regard: your peers are not available in person to attend a crit. All in all, I feel the web industry is not a place where design critique happens. And it's because most of us are either out of practice, or haven't been taught in the first place.

In practice

I feel crits are a place where you can fail without the fear of failure. A place where you can explain your work, debate outcomes, and move the work forward. We do them all the time at Mark Boulton Design. We get a comp, prototype or whatever up on a screen. We stand around and we have a proper design critique. Our work is better for it, and we are too.

I'm finding Twitter a great tool for initiating critique, too, because of the constraints (140 chars), it forces brevity. Brevity that is similar to a busy Creative Director who drops the 'It's not working' bomb. The trick is to understand the tweet in the right content. If it's framed within The Rules, we know not to take it the wrong way. And this brings me onto just that.

#crit

From now on, when I critique design (or a product or something) on Twitter, I'm going to append the tweet with a #crit hash tag. This means I'm saying this within the rules of critique:

1. Listen: Then talk. Don't interrupt. Don't judge. Wait.

2. The Work: It's not personal, it's about the work.

3. A Conversation. I want you to explain. It's the start of a conversation, i'm not dropping a bomb and walking off.

4. It's Public. The benefit is in a shared conversation. You can't get this in a book, and with many web designers working in distributed teams, they don't get from a real person, either.

5. What's said in the Crit, stays in the Crit: Things can get heated. Feeling can get hurt – it's human nature where you feel emotionally attached to the work you do – but, it's important to keep those comments in the framework of the crit. Don't keep a grudge.

This gives us a framework of understanding. Of course:

"This is SHIT #crit"

is not really in the spirit of the thing.

Not kinder, just better

Snark, ill-feeling, trolling. These are things we see on Twitter every day and they have no place in design critique. Design critique is not a place to be mean, but it's also not the place to be kind. You're not critiquing to make friends. Kind designers don't say what they mean. 'Kind' is not about the work, and design critique exists to make us better, but mostly, it's to make the work better. As soon as you throw words around like 'bullying', 'being mean' etc you are not critiquing design. You're being personal and defensive. Let's stop that.

So please join me in starting proper, considered design critique on the web. If you use the hashtag, I'll know your intent.

A New Make Mantra: A Statement of Design Intent

When I first worked in a design studio, I was taught that the first thing to do, as part of the project discovery, was to 'interrogate the brief', or 'rewrite the brief'. This normally involved getting a brief from a client, for us to ask questions, conduct research and then write our own brief and deliver it back to the client to demonstrate our understanding of the project and what we've learnt about their business. It's important to note, this isn't a proposal. This brief did not include the how, it was the what. What is the project.

At some point in my career, I stopped doing that. I still spent time trying to understand audiences and business, but the 'creative brief', as we called it, was something that wasn't produced. Instead, we normally had a plan. This would exist as documents, or conversations, or outcomes from workshops. The point is, they were many things - all collectively known as 'The Strategy'.

Recently, I've been trying to go back to something a bit more formal and create a single, actionable sentence that can be used to guide a project. This started out as a selfish endevour: I had trouble keeping all of this project stuff in my head in a way that could help my design work. It needed to be simpler.

A Make Mantra

Guy Kawasaki wrote about something similar in 2006, calling them a 'Make Mantra'.

A mantra is three or four words long. Tops. Its purpose is to help employees truly understand why the organization exists.

The examples he cites, if he had his way to create some, were:

  • Federal Express: “Peace of mind”
  • Nike: “Authentic athletic performance”
  • Target: “Democratize design”
  • Mary Kay “Enriching women’s lives”

So, in 2006, they could be used by organisations to describe themselves. However, what I wanted to do was something different. The statement I was after was not a description of what an organisation does, or the story it's telling its customers, or how it talks about itself, but rather a description of what we must do on the project. A Statement of Design Intent. A new Make Mantra for the Maker, not for the organisation.

Why do this?

  • It's a guide. When you meander on a project, it can help bring you right on track
  • It's a springboard for ideas.
  • It helps frame an otherwise complex strategy into an easily digestible statement that creates pictures in your head.
  • They help communicate change. In big organisations, and big projects, change is painful.

These statements of intent are a tool. Used to communicate, guide, as a springboard for ideas. A central theme on which to build. They're a star to sail your ship by.

Putting it into practice

Since last year, Mark Boulton Design has been working with CERN in Geneva redesigning the public website and creating a design language to be used throughout all their other websites.

Redesigning the CERN website is a complex project. It involves a lot of discussion, research and laying the foundation to ensure we can do our best work. A key part of that work for me was to distill our design strategy into something I could use daily. So how did we do that?

How?

The important thing about these mantras is they are tools that you should use every day, not just some strategy artefact, to be created, delivered, agreed and then forgotten. How did we use it in practice?

  • Research. For CERN, we ran spent a few months talking to people: internal stakeholders, and visitors to the main public website. We gathered a lot of data and then we spent weeks doing the analysis. Really distilling the data to try and define who the audience was and what they want.
  • Competitor Analysis. Find out who is doing something similar. How does that apply to your project?
  • Understanding the problem. Through the research, we spent a long time learning about CERN, learning about the problems with the existing site and editorial workflows.
  • Create a clear strategy and goals. What are you trying to achieve and how you're going to do it. My experience is this always changes following the research.
  • Boil, simmer, reduce. Through a number of workshops and discussions, we reduced the strategy into a single statement of design intent.

Through our research, we know that people are curious, inspired and intrigued by what goes on at CERN. But the content they read on the CERN site does not – in a large part – delivers on the 'can this user accomplish this task' success criteria.

We also knew that the different audience groups we identified for the project need to be spoken to in very different ways: the general public needs to be spoken to very differently to high energy physicists.

Through our competitor analysis, we identified NASA as doing similar work on a human scale: the exploration of science. But, you see, it's really easy for NASA to inspire people visually because they have pictures of space rockets and planets. CERN had pictures of magnets the size of a house and lots of wiring. Cool, but only to a certain amount of people. We needed to show that what NASA is doing with outer space, CERN is doing for inner space. We needed to Create Wonder. To inspire, to inform, to tell the right story. So, that became our simple, two word statement:

'Create Wonder'.

We use this simple statement in the project every day this way:

  • To check that we're on track with the design language. Even as simple as something like a photograph. Is is doing this?
  • To talk about our design strategy in CERN to stakeholders. Not just initially, but as we design new elements of the site too.
  • To create pictures in our heads. It is a challenge to us when we're approaching the work: 'go on… create wonder'.
  • As a scale: The Wonder Scale.

The Wonder Scale

The strategy very quickly morphed into a scale we could apply to different audience groups. The issue was that presenting some content in a wondrous design would not be appropriate for some audiences. For example, the latest research that's been published by one of the experiments at CERN should not necessarily be highly visual. The content should be clear, legible, easily scannable etc. But it shouldn't be shiny. And the opposite is true for other content that is designed to inform, inspire and educate the general public. In that case, the wonder is 'high', the former, it is 'low'.

Let's have a close look at this.

CERN's Wonder Scale

On this diagram, you can see our four audience groups: Scientists, Educators, Students and General Public. We created personas for each of these, and each of them had a comprehension level: how much they understood about the work CERN does. This went from high for scientists, to low for the general public.

CERN's Wonder Scale

We can then map an inverse 'Wonder Scale' on this. The more comprehension you have, or closer you are to the science or organisation, then the lower the Wonder.

CERN's Wonder Scale

So, we had this scale based on our statement of design intent. How did we actually use it in the design work?

How does it look?

This is a screenshot of our latest prototype for the homepage of CERN. Let me walk through what we're trying to do.

CERN Alpha Screenshot

The Goals.

  • Create Wonder. The CERN homepage needed to show what CERN was doing as well as say what it was doing.
  • The main thing that came through time and time again from the research we conducted was that all the different audience groups need updates. They need to know what's going on. That was probably the largest need.
  • Demonstrate that there are more experiments going on at CERN than just the Large Hadron Collider.
  • Effectively funnel people into sections of the site that are appropriate for them.

The How

  • Create Wonder. Because the work going on at CERN is subatomic, it's very difficult to get imagery that is remotely interesting. You can't photograph these particles, and as such, the default option is to rely on imagery of the engineering. The engineering at CERN is unique, and awesome, but you'd need to know what you were looking at to appreciate it. The level of comprehension required is high. What we settled on was Event Visualisations.

    Every 600 million times a second, protons are smashed together at near the speed of light at various points in experiments in CERN. The computer than creates an image of this. Part of our strategy for the homepage (and how we 'Create Wonder') was to show what was happening at CERN right now. Demonstrate these collisions were happening in real time.

  • All about the updates. We make the updates panel the primary content on the homepage. It's updated with links to articles, research, press releases, but also includes statements such as 'LHC shutdown for Holidays'.
  • A lot of people think CERN is just the LHC, but the LHC provides the beam of protons and there are many, many experiments that use it. The small panel on the bottom right will rotate through a status update of a selection of experiments.

Throughout this process, 'Create Wonder' was an invaluable tool to sense check our progress. Are we on the right track? Is this content appropriate for this audience, and how should it be presented? Are the stakeholders on board with this strategy?

A New Make Mantra

Now, this is an example from a big, complex project, but you can use these for small projects, too. It's just the time you take to get to it might be shorter. I'd highly recommend giving them a try: stick them up next to your desk, refer to them constantly, use them as a metric to define how you talk to potentially different audiences for your designs.

I'm excited to use these in my work more. They move a Make Mantra from being about the organisation to a tool for designers to use. Moving it from the organisation to the Maker.

Gridset

The Gridset Logo Last Friday, Mark Boulton Design announced something we've been working on for the past six months or so: Gridset. A tool for creating advanced grid systems on the web.

For a long while now, we've been designing tools and frameworks to help us create grids from HTML and CSS. Some of these frameworks give us a lot of flexibility, and some of them tie us down quite closely with the type of HTML markup we have to use. Since about 2007, this has all been very helpful is giving us some code structure to help us understand, and then build, fairly simple grids.

But, then something happened.

Building responsive grids has forcefully jolted us from our 12-column comfort zone. Now, we're having to think about appropriate grids for different device widths. This in turn is having the effect of making us readdress our needs for desktop. It's certainly my experience over the past year or so, that this rather cookie cutter approach for designing grids needs re-evaluating, but we're lacking good tools to help us with the sometimes painful maths and advanced CSS chops.

Gridset will help with this. And more.

I've had a few questions since Friday around some of the features we announced. I'd like to address some of those here:

Gridset is a tool, not a generator.

Nothing is prescribed… you build a bespoke grid system for your project.

Gridset is not a bunch of code you download from Github. It's a browser-based tool to create grid systems.

Create advanced grid systems.

It can create asymmetric grids, golden ratio grids, or completely bespoke arrangements, not just a row of columns. It allows for fine-tuning of column widths.

For the past few years, the grid systems we've seem on the web have all been evenly spaced columns (usually either 12 or 16), and that thinking is now being applied to the latest crop of responsive grids. There is simply more to grids than 12 or 16 columns and Gridset is designed to allow the creation of many, many types of grid.

Generate smart CSS.

There is no need to add lots of classes for offsets and margins. It anticipates every possible configuration and styles accordingly, allowing you to focus on layout.

CSS grid frameworks are great if you're flexible enough to not worry about an extra div here or there, or a particular class syntax in your CSS. If, however, you care about the semantic structure of your markup then this is a problem. We care. So Gridset has been designed to anticipate every column, margin and padding column configuration of your grid and give you the appropriate classes to use.

Designed for your workflow.

Tinker, save, return. Iterate and publish. Your grids are there whenever you need them.

I'm of the opinion that good grid system design can be abstracted from layout design. Layout gets built on a grid. Most good design systems work this way: the grid is designed, locked down and then layouts are used on top of it. Think of Gridset as your library of grids in one place. There for you to create, iterate and publish. To be used with simply the addition of a single line of CSS.

What next?

Gridset is currently in a pre-alpha stage: working with a few people in the industry that represent what we think our core audience will be. We'll be quickly moving into a closed Alpha and then a semi-closed Beta selected from the people who sign up to the list on the site. We're shooting for a summer launch.

In the coming weeks, we'll be talking more and more about what we're doing. Follow @Gridset on Twitter for more updates.

Responsive Summit: The One Tool

Last week at the Responsive Summit, we discussed tools a fair bit. Especially in relation to workflow and how it effects a designer and their output.

Since 1997, I've been working almost exclusively on the web. Throughout all of that time, the realisation of what the projects would look like are done in Photoshop. That means, yes, I've been using Photoshop in a production environment for fifteen years. Malcolm Gladwell said it takes 10,000 hours, or 10 years of repetitive use, to become an expert in something. I guess that means I'm an expert in creating pictures of websites. Photoshop is like an extension of my mind. To use Photoshop for me is as effortless and almost as fast as a pencil. I get stuff done; quickly.

The change in process to Responsive Web Design means we need to get in the browser faster. But please don't read this as 'we need to get rid of Photoshop and/or equivalent tools'. It doesn't mean that at all. What it means is that we need to be aware and understand our materials. That means we need to understand how -- when you're designing in Photoshop, or Fireworks -- you have one half of your mind in a browser. Not necessarily HTML, or CSS, but thinking about behaviour.

There has been talk for a while of designing a tool for the web that is more aligned with our processes than Photoshop. A lofty goal. And I'm not even sure how worthy a goal, to be honest. Because, at this point in time with Photoshop, HTML prototyping and a pencil, my workflow and tools are okay, thank you. I don't think i'm suffering as a result of having inappropriate tools. That's because I understand how each of them works, the material they work with, and how they all come together in my mind.

Understanding materials

I think one of the key aspects of a good designer is to understand your material; be it pixels, ink or markup. That doesn't necessarily mean you have to design in that medium. Print designers don't design in ink (well, not much anymore). Architects don't design in bricks and steel. And web designers shouldn't need to design in HTML or a browser canvas. If you're any good at your job, you will understand that media, create for it well and then communicate that well to other people.

Our takeaway last week that the tools we have for certain parts of our job could be better. Photoshop could be better. So could fireworks, and the browser and CSS... the list goes on. RWD adds some complexity to the mix, because we need a good way of increasing fidelity of our work over time, in the browser, whilst retaining some of the things that, say, Photoshop gives us.

Last week, I tweeted: 'You can't have happy accidents designing in the browser'. Jeremy corrected me: I can't have happy accidents in a browser when I'm writing specific rules and then watching the results in a browser. There is too much in the feedback loop. Photoshop is an extension of my mind and my hand. Through 15 years of continuous professional use, the feedback loop is small. My mind is free to explore options whilst my hand (via the mouse) executes them. Rinse, repeat, explore, iterate. For me, writing explicit instructions in code and hitting refresh in a browser is a long, long way from this.

I said during last week's Summit that in all likelihood a Web Design Photoshop tool is not likely going to solve any problem we have now. Maybe a small suite of tools will where we can extract certain parts of our process: like designing a responsive grid, for example, or defining a colour palette, or iconography. But when it's a holistic process, then a designer's own experience, preferences and ability will trump any tool. Each very much to their own.

Responsive Summit: Workflow

These are my notes, conclusions and thoughts from yesterday's Responsive Summit in London.

Last week, Alex Morris – UX Director at Mark Boulton Design, Chris Armstrong, Designer from Front, the company responsible for Typecast, and Josh Brewer, Principle Designer at Twitter, were discussing the idea that – whilst Josh is in the UK – we should all get together and have a chat about Responsive Web Design; the problems we share, the tools and solutions we're individually developing, and how we can collectively we can get a better understanding of what RWD means for us and our daily business.

Yesterday, the 'Responsive Summit' took place in Microsoft's offices in London. And huge thanks must go to Martin Beeby from Microsoft for not only providing the room and also the tea, coffee and lunch. Oh, and cake.

In attendance were:

In Person

On Skype

Ahead of yesterday I was a little sceptical as to the format and the practical value from getting 25 people in a room and have them discuss Responsive Web Design. I thought it'd be a bit of a bun fight. But, actually, that couldn't be much further from the truth. The people who attended represented a broad range of websites, products, agencies and clients. We had people representing websites and products that have issues of massive scale: the BBC and Twitter. Through to individual freelancers working on site designs and builds for primary schools. The range of considerations on the table was therefore also as broad.

Last week when Chris, Alex and Josh decided on trying to make this happen this week, they had the brainwave of putting a form up on a website to gather questions, concerns or comments from the community. We had a hundred responses or so. All of these were broadly grouped around the following topics:

  1. Workflow
  2. Layout
  3. Sensors
  4. Images
  5. Advertising

This first blog post of mine is just about the first point. Specifically, these are my thoughts based on the discussions not necessarily the consensus of the day.

Workflow

We broadly agreed that from our experience, Responsive Web Design affects workflow considerably. Speaking personally, Mark Boulton Design have been building all our projects responsively for the past 18 months – typically HTML/CSS templates for handover to clients or development partners. And it affects workflow a lot. Here's what we used to do:

  1. Create planning and design artifacts: site maps, wireframes, user flows and journeys, scenarios etc. All of these were up for revision and change by the client.
  2. Create flat Photoshop comps based on those artifacts, but only when they were signed off. Oh, and typically that would tally with a billing point.
  3. Build templates from signed off comps.

Typically waterfall process. This doesn't work well for us with Responsive Design. For the past few years, we've been working the following way, but only in the last 18 months or so has it become increasingly crystal clear for me that there has to be a structure of project flexibility to accommodate the inherent fluid nature of RWD.

  1. Sketch. Get the ideas down *amongst* the requirements. Meaning, we don't have design specification documents, we dont have lengthy requirements documentation. We have user stories (or something similar) and we combine them with research, thoughts, sketches, ideas to document the scope of the project.
  2. Prototype. In HTML. This allows us to get the product – in whatever form – in front of the client. The aim is to remove The Big Reveal. It also lets them see how the site responds on different screen sizes. Also, we can start to think about problems that may arise due to a responsive approach *now* instead of when the templates are being integrated into a backend, or at other production sensitive times.
  3. Design. However you increase the fidelity is up to you. I use Photoshop, other people use Fireworks, some do it in a browser.
  4. Iterate. Have a project structure that embraces change. That means a focus on priorities.
  5. Talk. This approach requires much more collaboration with a client. I mentioned The Big Reveal: the thing designers do where they squirrel away for a few days and then come back and go 'ta da, look what I made!'. That's just so risky.

Some of you will think I just described an Agile process – and partly that's right. There are some things from Agile that are useful for us when designing Responsive sites: prototyping working code, iterating based on priorities, increasing the fidelity of your design work in the browser instead of comps.*

* Note: I'm not saying design in the browser. I'm saying increase the fideltiy, or apply a design system, not do it all in there.

Yesterday, we discussed similar issues around this process. How, in large agencies which are crippled by siloing of design and front-end development resources and their own immovable processes, are finding it very difficult to work with RWD. It's not because RWD is difficult, appropriate for a project or anything else. It's because their process can't accommodate it.

One of the issues is to do with the delivery of design 'comps' to a client. The old way was easy: we do wireframes, we make comps from those wireframes, clients sees them, signs them off, we build it. We can't do that now because we'd be delivering comps for every viewport size. We can't do that. More the point: we shouldn't do that. This is when RWD comes under criticism for not being commercially viable. It's because it's trying to be shoe-horned into an existing, fixed-canvas, inflexible process.

The take-aways for me, based on yesterday's discussions, were that we're on the right track. Prototyping in HTML early, showing and involving clients in the process early – so they can see how a site will respond to different viewports – actually showing them in different devices helps mitigate the 'The Big Reveal' and the associated risk. It helps clients understand – and this was a great point made by Cennydd – that RWD is sustainable design and a cost effective, future-compatible, approach to building websites for an ever-increasing myriad of display sizes.

The next part of the day was to discuss Layout. But, I'll leave that for the next blog post.

A Responsive Experience

Since I saw Ethan's talk in An Event Apart in Seattle 2010, I've been thinking a lot about Responsive Design. Not just the layout techniques Ethan gave name to and wrote the book on: fluid grids, plus media queries and flexible images, but taking a step back from that into the field of responsive architecture and abstracting that into responsive design in general.

Responsive Design is everywhere

As I discussed in my talk at New Adventures Conference last January, Responsive Design is comprised of three things:

  1. Sensors: Things that sense the environment (not the weather, but the stuff around it - whatever it is)
  2. Systems: A system that takes the information from the sensors and tells the actuators what to do.
  3. Actuators: The things that actually do the moving. The motors, the CSS, the cables.

A simple example of this is your central heating. Mapping central heating to those three:

  1. Sensors: This is your thermostat. It measures the temperature.
  2. Systems: This is the software in your thermostat, or on your boiler, that you can programme.
  3. Actuators: This is the thing that turns your boiler on or off.

This is a responsive design system. Now, looking at web design, let's try and map Responsive Web Design to it:

  1. Sensors: This is the browser
  2. Systems: This is our CSS -- specifically the @media declarations
  3. Actuators: This is our CSS too -- specifically what falls within our @media queries

You see, in the browser world, it's not so cut and dry. Using @media queries, the browser detects the width. The browser is the thing that is sensing here. The system -- the bunch of rules that tell the actuators to do something -- they live in our @media queries. At this width, do this. The actuators are also in our CSS. They are the 'this' in the previous statement. eg. At this width, make this button blue. System > Actuator.

For the past year or so, we've been getting to grips with the Actuators and the Systems through using CSS and Javascript. What's proving difficult, is the Sensors.

More sensors, please!

At the moment, all that we can do reliably (well, fairly), and knowably, is use the browser as our single sensor by which to sense. We have one sensor. We need more. Just for a moment, let's consider what would be useful information for us:

  1. Network infrastructure
  2. Device capabilities
  3. Screen size
  4. Context
  5. Content

If we could have sensors that could detect if you are browsing on a particular browser, could detect what screen size, network and context -- eg. on your couch, on a train in a certain geo-locale -- we'd be going in the direction of Responsive Architecture and Responsive Design generally. As it stands –– and this is fine for now –– we're changing layouts based on a screen size. We're capable of so much more.

Now, am I talking about device specificity? Is this the browser detection days gone nuts? I don't think so. I'm not talking about deviating from standards here. I'm talking about having better tools to monitor the browsing environment, whatever that is.

A Responsive Experience

Responsive Design (the field) changes a thing because of the environment. Responsive Web Design currently changes a layout because of the environment. I think Responsive Web Design will grow into a practice of changing an experience because of the environment. That means: content, layout, behaviour, perception, brand, feel. All of those things are open for change if we have a good set of sensors, and the right actuators to to create them. Our job will then be focussed on designing the systems knowing that all this good stuff is in place.

It does feel that at the moment, we're very preoccupied with the component parts of responsive design: how do we sense the environment the user is browsing in,? How do we create a system to change the layout? What's the CSS to do those changes?

That's all OK. This is still new.

Over the past year, Responsive Web Design has quite rightly shifted the web standards based design community to a new way of thinking. It's not really just a layout technique. Responsive design –– if you consider the above sensor > system > actuator components –- is a much broader, holistic practice. It involves every step of the design process in determining the outcomes of the actuators, or defining the sensors and then designing systems around those inputs. The whole thing is involved.

I think we're at the start of this for web design. This is exactly some of the pain we're feeling with Responsive Web Design workflow right now. And it's encouraging we're seeing a focus on techniques and tools to create better sensing, better systems for controlling more sophisticated actuators. However, I'd love to see more joined up thinking. How does Responsive Design effect our content? Our messaging? The story? How can we shape better experiences by using these simple inputs and outputs?

Responsive Web Design is just the start of us challenging and rethinking our perception of what the web could be. We used to think it was like newspapers. Or computer programmes. Now, we've had a glimpse of a web that understands us and can adapt to our needs. That could either be incredibly exciting, or bloody terrifying!

Structure First. Content Always.

We have to start somewhere. Something has to come first.

In 2001, I started working for the BBC in Cardiff. I worked alongside journalists and project managers for four years on all manner of web sites and applications; ranging from small niche content sites about surfing, through to redesigns of the homepage. All of these projects were approached Content First (but not this Content First), but not one of them had the content, first.

Having worked alongside news and media organisations for the past ten years, I've absorbed a lot about the editorial processes across three media: television, print and the web (and a bit of radio, too). I've rejoiced at the commonalities and grimaced with pain at the differences between how things are done; both in the organisations themselves, and the different output they produce. Some of those things we've taken straight to the web with some success. Others, we've tried and failed. Like trying to make websites like CD-Roms. Remember those?

The model that we took right at the birth of the web from print – the templated page and publishing system – is now under attack. It's under attack from the premise that you need to know your content before you can design it. For anyone who's worked in publishing, or had to design a highly scalable branding system, or a wayfinding system will know that is nonsense. You don't need Content First. You need Structure First. Then you need Content all of the time.

Let's be really clear about this. It is unrealistic to write your content – or ask your client to write the content – before you design it. Most of the time. Content needs to be structured and structuring alters your content, designing alters content. It's not 'content then design', or 'content or design'. It's 'content and design'.

Designing a magazine or newspaper system requires the designer to exercise rigorous restraint with a hugely variable melting pot of content. Working directly with an editorial team, you have to define what types of content you need to design for. News articles, opinion pieces, features – all of these require slightly different design treatment to communicate they are a different type of content to the reader. Design variance must be limited. Why? Well, time mostly. Newspapers and magazines run on incredibly tight timescales and content is literally pored into a mould – trimmed and teased a little, but the templates leave little room for movement. This is not bad practice. This is how content lives and breathes in a fast-moving editorial environment. It has to be fluid. It can't be locked down early. Content First would not work here.

Content as structure

There is an emerging fallacy in our industry recently. The idea that you cannot create good design without knowing your content. Even I said that a while ago. But, that's only half true. Newspapers, magazines and many other periodicals and publications in different media prove that assumption wrong every day.

You can create good experiences without knowing the content. What you can't do is create good experiences without knowing your content structure. What is your content made from, not what your content is. An important distinction.

So you have to start with the structure not the words. What exactly is an opinion piece. What are the variables? Can we even define them? Images? How many? (to which, the response is always: 'I don't know, it depends!'). We can design around fluidity, but it means letting go of control. Again. How do we do that, then? How do we design around the fluidity? Well, we define structure; of our content, and the templates that content inhabits. We define the rules of the system to display the content in different ways (if we can) to help the reader understand the content better. As Erik Spiekermann says: 'we give content form'.

Designers as Content Directors

Designers have always been involved with content. We're not just concerning ourselves with what is visual. So how can we help our clients understand that when we say:

'Content First!'

We don't really mean:

'I'm going to sit on my hands right here unless you give me my content. Finalised, proofed and signed off. Thank you very much.'

No, we don't mean that. What we mean is:

'We'd really like to understand the type and structure of the content for this project. Don't worry, you don't have to write anything yet, just help us understand.'

We can do this any number of ways, but recently I've found this broad process works for me:

1. Talking. And Post It notes. Get a room – preferably lock the door – and talk about the website or application. Not the content (yet). As you're talking, jot down words that resinate. Then after you've talked, stick all the words up on a wall and start to make connections between. Some probably some fancy UX term for this exercise, not sure what.

2. Messy Mess. You should end up with a pile of loosly related words (not content at this point) about some stuff. This stuff is the very DNA of the website. The feel, the tone, the brand, the message through to the nitty gritty of content types, taxonomies, tags and technology. Now you need to sort it all out.

3. Iterate. At some point in that sorting, you will need to start tightening up the structure. Again, I've found doing this iteratively and collaboratively the most fruitful.

4. Structure. Now you should have some structure. At some point in step three, there will come a point when you or your client will say: 'Yes, but what is this?' pointing at a post note with a word on it. At that point, you get into detail and you start fleshing out what it is. This is defining the structure of your content. And it doesn't stop here.

5. Page tables. A page table is basically a form for your content. Fill it in. Use this one from Relly, as it's brilliant. This tool can really help your client later in the 'oh my God, I've got so much content to write and I don't know where to start!' phase. It helps focus.

Structure First. Content Always.

Let's stop siloing content, shall we? We did it for a while when we were designing a largely brochureware, templated web. Now, we're trying to move that silo from one end of the process to the other. Let's focus on structure to begin with, and think about content all the time. There is a symbiotic relationship between content and design. One cannot thrive without the other.

Let's start with structure. Let's know what our content is made from. Not, necessarily, what it is.

2012 UX Bootcamps

I'm very excited to be running a Bootcamp again for UX Bootcamps in April next year. This year, it was great fun working alongside some talented UX-ers up their graphic design skills. And, considerable progress was made in just two days.

Alongside the Visual Design Bootcamp, there will be a Cognitive Psychology bootcamp in February with Joe Leech from CX Partners, and Information Architecture UX Bootcamp with Mags Hanley. Both of which, I'm sure, will be superb.

So, if you fancy any of them, tickets will be on sale from midday on 5th January 2012.

Design Compromise

My friend Andy Rutledge runs a weekly video podcast called The Design Pro Show in which he talks through his take -- as a 'Design Professional' (in quotes because it's a thing) -- on a number of subjects; from 'Process', to the latest show yesterday 'On Compromise'.

Yesterday Andy asked for thoughts over Twitter:

Where in your work have you found benefits in compromise?

As you'd expect, opinion was polarised. Andy Budd perhaps encapsulated how I feel:

If you compromise on nothing, you're a dictator. A lack of compromise weakens the chance of discovering that you could actually be wrong.

And Oliver Reichenstein today:

Web design is engineering. Engineering is all about making the right compromises. Case closed.

My thoughts are this: design is an exercise in considered compromise.

Firstly, let me define what I mean by compromise. I mean reaching a mutually agreeable decision based on subjective demands, conditions or variables otherwise unaccounted for.

The type of design I do is, ultimately, about people. Designing websites for people means you need to try and understand how they will behave on the website you're designing, and people are complicated things. Commercial design means doing work for money. Stakeholders are also people (yes, they are), and are subject to the same complicated thought processes as the rest of us with the added commercial complexity of generally knowing their business (and sometimes their audience) better than you do.

Throughout a design process a myriad of potential conditions may present data that results in a compromise; a point in time where you need to course-correct to take into account new information. My understanding is that a designer will take this information and steer the ship whilst still producing an optimum solution. This is through no fault of the designer or the process. New information can surface at any time throughout a process; for example, user interviewing or usability testing may bring to light information that fundamentally changes an approach. This has happened to me on numerous occasions.

If you're unable, or unwilling, to take on-board this new data -- to course-correct -- to compromise what you thought was the right thing, this is will result in a compromise to the design solution. Because you're ignoring critical information. Your desire to not compromise will actually compromise the end-result. Ironically.

Someone who knew a lot about uncompromising systems was Bruce Lee. As you may know, Bruce Lee was an martial artist film star in the 60s and 70s. He was also a philosophy major and had a deep interest in understanding the physiological and psychological effects of combat. He had a deep interest in challenging the traditional martial arts styles of the time: Shotokan Karate, Taekwondo, Judo etc. despite training in a traditional style himself: Wing Chun. His problem was they are not grounded in reality. They exist as a system devoid of adapting to external data. This, of course, can be particular damaging when faced with an opponent. You rely on the system to provide you with the right tools, rather than adapting and accepting the fluid dynamics of a combat situation.

Design is like this.

Adhering to an inflexible system, that is incapable of reacting to new external data, or the fluid dynamics of a complicated project, generally results in failure. This is why methodologies such as Agile exist: they are designed to effectively accommodate change.

My experience in design is that there's a lot of grey. Nothing is ever cut and dry. People are complicated. Perception and behaviour is difficult to account for, and using a design process that welcomes new data, can course-correct effectively, is a process every designer should be working to create.

5by5: Me on Grids

I had the pleasure of speaking with Jen Simmons (@jensimmons) on her show on 5by5: A Web Ahead..

For a whole 100 minutes (!) I harped on about responsive design, grids, design process, news, advertising and a few other things. Despite my dodgy sore throat, I had a great time discussing some of the nuances of adopting new and challenging approaches to design and build the web sites and services we do.

This post won't take long to read

Estimated reading time: 10 minutes.

What a presumptuous statement. How do you know how long it will take me? Do you know my first language isn't English? Do you know that have learning difficulties? Do you know I'm sitting in a public place and will likely be interrupted frequently? Do you know I've forgotten my glasses today?

I'm seeing this small bit of meta-data associated with more and more blog posts. Just next to the post title, designed to help me make a judgement as to whether to read it, not read it, or read it later on using Instapaper or something.

I've got a problem with them. They're trying to answer a question I don't have.

Time

The question they're trying to answer is: 'do I have time for this?'. In my experience, time is very rarely a deciding factor on reading an article. The deciding factor for me is generally the content itself: does it interest me? Is it well written? The only time that time is a factor is when I'm in the middle of something else. Is this always the case? Absolutely not.

Value

The other problem I have with these little nuggets of fallacy is that I feel they devalue the content. Being so prominently placed -- generally next to a title -- implies they are a major deciding factor, and therefore they are a value statement you place on your own content. In this busy, busy world, 'short = good'. 'Long = I don't have time for that, I'm too busy'

Legibility

The final thing is they assume too much. As I described at the start of this post, this UI device assumes an awful lot of the user. It also assumes a lot about the design and legibility of the presentation of the content.

How do we fix it?

What I'd like to see is this type of device being closely associated with 'read later' functionality. Don't have the time now? Read it later. In its current form and positioning, it leads me nowhere.

What we're really after here is trying to show length. How long is an article so I know if I want to read it. Many people on Twitter thought a scroll bar was fine. But as some pointed out, that's inaccurate as there could be a whole lot of page guff at the bottom of the page. Would word count suffice? I'm not sure.

Document length is an important data point. Decisions about reading are based on it. Sometimes based on time, but other times on context, ability, comprehension or language. How could we better measure 'length' on the web that makes sense for people?

So, how long did it take you to read this post?

Responsive Advertising

Recently at Mark Boulton Design, we’ve been working on a redesign of the global visual language for a large sports network. Like many web sites delivering news and editorial content, they rely on advertising for their revenue -- either through multiple ad slots on the page, or from video pre-rolls.

Early on in the project, we discussed Responsive Web Design at length. From an editorial and product perspective, it makes perfect sense. Who wouldn’t want their content adapting to a device their reading it on? Who wants to pinch-zoom again and again? From a business and product perspective, we’ve seen this from multiple clients who want to take advantage of certain interactions on certain devices -- swiping for example -- for users to better engage with the content in a more native way. All good. And then advertising comes along and things get challenging.

Here’s the problem as I see it:

  • A large number of sites rely on advertising for revenue. Many of those sites will benefit from a Responsive Web Design approach.
  • Web advertising is a whole other industry.
  • Ad units are fixed, standardised sizes.
  • They are commissioned, sold and created on the basis of their size and position on the page
  • Many ads are rich (including takeovers, video, pop-overs, flyouts and interactions)

Let me go through each one of these in turn:

A large number of sites rely on advertising for revenue. Many of those sites will benefit from a Responsive Web Design approach.

The content for free expectation on the web has been around since it started. Many websites -- where you pay for the content in other forms, such as newspapers -- had to adopt this model, but use advertising dollars to pay for it. With the absence of any other revenue stream on these sites, the only other alternative is paywalls/subscriptions, and we’re seeing a few of these start to come through in mainstream newspapers now -- The Times, for example.

As I mentioned earlier, many of these websites will benefit from a responsive web design approach. The consumption of this content has changed along with the plethora of devices and viewports. As I’ve talked about before, designing a ‘best fit page’ is becoming increasingly challenging if you acknowledge how usage has changed and will continue to change in the coming years.

Web advertising is a whole other industry.

There are sub-industries within web design as a whole that generally don’t talk to each other -- such as gaming, gambling, porn, seo. Web advertising is another. These sub-sets each produce technology advances that everyone else benefits from. They deeply understand their audiences and how they interact within those verticals. But they don’t talk. Generally. For an industry that is built upon open standards, sharing, communication then this can be damaging.

Ad units are fixed, standardised sizes.

Hurray for standards! Because of the inherent reuse of advertising colatoral, this stuff had to be standardised. The Internet Advertising Bureau has been documenting emerging standards in web advertising for years now.

This is all good, especially for creating grid systems. Khoi Vinh talked about deriving a grid from an ad unit (PDF slides) when I shared a stage with him in SXSW in 2007. They are a fixed content element -- unchangeable and standardised across a website. They’re knowable.

They are commissioned, sold and created on the basis of their size and position on the page.

This is perhaps the biggest issue for me. For example, a sales teams basically have a page ‘template’ with ad slots. Position A, B and C. In A, you can fit a Leaderboard. In B an MMU, and C a button. Also, if an advertiser pays lots of money, they can have a takeover. A takeover includes banners down either side of the page which join up to create a wrapper. Sometimes Leaderboards in position A can be pop-overs or flyouts. Sometimes, crazy stuff can happen where someone throws a ball from ad position B to A. Yes. Seriously.

The sales team then proceeds in selling the slots to advertisers who in turn provide the ‘creative’. This could be animation, video, graphics - increasingly a combination of all three - that are embedded in the page by a scheduling application. They’re sold based on the impressions rather than clicks.

That’s a lot of variables to account for. But, web advertising is becoming an increasingly aggressive industry. Advertisers and web sites are looking to innovate to engage users through marketing campaigns that align across multiple media. And web sites need to be accommodating.

Sales teams through many industries are also largely commission-based. As a sales person, you have a basic salary (or sometimes you don’t), and then you earn more depending on what you sell in the month. And here’s the thing. A sales team need a simple model in order to sell ads: a template with slots and a list of ads that can go in then. Now, let’s introduce Responsive Web Design into this.

Let’s say, you have the minimum amount of break-points: desktop, tablet and small screen. A sales team has a template with Slot A (the primary slot) that accommodates a Leaderboard for the desktop. But then that changes to a MMU for tablet. And changes again to a thin banner for small screen. A sales person has to understand they’re selling ONE slot for this. And an advertiser has to understand they’re paying for ONE slot for this. However, they’re supplying three times the amount of creative. And this is just a very simple use case. What happens with a takeover? Everyone wants as much bang for their buck as they can muster.

Many ads are rich (including takeovers, video, pop-overs, flyouts and interactions)

Increasingly, ad units are not confined by their pixel borders. Take-overs combine multiple ad units to give an overall effect of taking over the page. Flyouts show and hide a layer on hover. Pop-over do the same but in a different way. Video autoplays. Animation completely breaks out of the ad unit and can fly around the screen: how ever annoying that might be. My point is that the notion of advertising being confined by their pixels is also becoming increasingly grey. How would you accommodate a flyout for a small screen, for example? Another type of flyout for each breakpoint? So now the advertiser has to produce three times the amount of complex creative for the same, single ad slot? In order to make this commercially viable, they’d be looking for a deal then.

Those are some of the practical logistical things I can think of to challenge the notion that you can just ‘serve a different ad for each break point’. It’s just not that simple when millions of dollars are at stake.

So what can we do to improve this?

Well, some responsive sites are incorporating ad units now. But not many.

Boston Globe has incorporated an MMU ad unit. They’ve done this by fixing the width of that column and have the ad unit occupy that space as the viewport is reduced down to a single column.

Boston Globe screenshots on multiple devices

Boston Globe screenshots on multiple devices

The good news is, this is a problem a few in the industry are seeing as an opportunity. ADO published a press release just last week:

to deliver cross-media web innovation, user experience design and integrated advertising for brand, agency and publisher clients specifically around mobile full-service responsive web design.

Matthew Snyder, CEO of ADObjects adds:

We wanted to share our vision on 11.11.11 since we believe a critical part of the right digital strategy is to build a cross-media mobile strategy with complete 1-to-1 parity multi-screen design. With one recent client we were able to see 4x more traffic and 30% of the traffic to mobile via responsive design methods due to search and social link matching over conventional mobile web platforms

If these numbers are to be believed, then there is a considerable ROI for advertisers to work to adopt responsive design and an ad strategy that would match.

Now, let’s get down to brass tacks. How would approach building out a complex responsive web site that had multiple slots?

The Standard Model

The existing model is based on advertiser filling slots, as shown in this diagram. Each is sold to perfectly fit an available slot. If none are sold, the website defaults down to a stand-in.

The standard model of displaying and selling ads for the web

The standard model of displaying and selling ads for the web

A Responsive Model

Firstly, I’d sell slot ‘packages’ rather than single slots. This requires an ad sales team to clearly explain what those slots and sizes are, and they’d be served on that basis. For example, an advertiser would buy a package for slot A. The creative to deliver against that package would be a Leaderboard, an MMU and a small banner for small screen.

A proposed Responsive model of serving ads

A proposed Responsive model of serving ads

Then, of course, the templates need to be able to detect the various widths and serve the correct ad based on that width.

Complex ads such as flyouts and takeovers would require much more thought and change. How could you effectively engage with an audience across the various viewport sizes when there is rich interaction involved?

As I mentioned, of course all of this is with a caveat that the advertiser is buying a slot ‘package’, rather than a single ad to fill a single slot. And that a sales team would sell it as such. This is the crucial difference, and for me, the biggest barrier to this change - it’s cultural and not technical, that requires a lot of explaining, and they always take the longest to do.

The template > slot > ad mental model is engrained both in advertisers, planners and web sites. Providing space for ads needs to be broadened into multiple spaces for one ad concept. This requires closer collaboration between advertisers and web sites, designers and marketeers and sales teams.

Over the past six months I’ve been working on this problem: speaking to sales teams, product owners, designers and as @kerns mentioned on Twitter this morning, the one thing that is plainly lacking at the moment is demand. I’d go one step further and say that the thing that’s missing is benefit. If the benefit can be clearly shown to advertisers and websites -- in terms of an increase in penetration, reach, and ultimately, revenue, then we’ll start to see some movement.

I'd love to discuss this further on Twitter, or on Google +, you can reach me on either if you have any questions

What is Spec(ulative) Work, really?

We all know that Spec work is bad. I've written about it here before.

There are professional organisations that have official codes of conduct on the subject. Industry campaigns continue to educate ill-advised clients, yet the more I'm in the service industry, the more I realise the 'not doing speculative work at all' is not quite as cut and dry as these organisations would have us believe. And, taken to the extreme, could be damaging for the industry and your business.

First of all, let's get grips with what 'spec(ulative)' in this context means. The AIGA believes:

...that professional designers should be compensated fairly for their work and should negotiate the ownership or use rights of their intellectual and creative property through an engagement with clients. To that end, AIGA strongly encourages designers to enter into client projects with full engagement to show the value of their creative endeavor, and to be aware of all potential risks before entering into speculative work.

Quite right. But what they don't do is state what that work is. Presumably they mean design consultancy producing output, be it wireframes, user interface mockups, logos, advertising campaigns etc. What they're failing to very clearly state here is the speculative work that goes on in securing a client that is not design related.

Good client relations begin from the very first contact. At Mark Boulton Design, we probably have a similar approach to most small studios in engaging with potential clients: we spend time trying to understand them, their needs, the business and the project -- at least from a high-level perspective -- before committing to working with them. Sometimes this takes the form of a formal RFP from them and a subsequent proposal from us, but more often than not it takes place over many weeks over email, phone conversations and face to face meetings. This is before any contract has been signed. Like any relationship, we're seeing if we like each other before we commit. And just like other relationships this is speculative; you are speculating your time on a successful outcome.

You see, to my mind, some of the work we do is inherently speculative if you are charging your clients for time. Your time = your money. Every conversation you have with a perspective client spent during a project and client discovery is time you are spending.

So, when we talk about Spec Work in relation to web design, let's be specific: we're talking about speculative design work. Not all speculation is bad. In fact, some of it is unavoidable.

Five & Ten

Jason Santa Maria – the talented bastard – goes and redesigns his site and serves up a masterclass in understated elegance. The subtleties here are sublime. Look, absorb, learn.

Interestingly, Jason states one of the reasons he redesigned this way because he felt the weight of pressure that every post had to be a considered, designed, art-directed masterpiece.

Rethinking CSS Grids

Off the back of this article in Net Magazine last week, and the subsequent few tweets popping up in my stream, I've finally managed (in no small part from the help of Nathan and Alex) to pull together some of my thoughts and concerns regarding CSS grids and how they could (or, maybe, should) be created.

What's there at the moment?

Multi-Columns

CSS Multi-Column is really simple. Basically, you divide a element into columns. This is already well-supported in many modern browsers.

Flexible Box Layout

Flexible Box Layout is a module that automatically resizes elements within another element without having to do a lot of painful maths.

Grid Layout

Let's concentrate on Grid Layout, as this is potentially the most designer-friendly and should match existing mental models.

The issues with Grid Layout

How grids are constructed

The underpinning unit of measurement in a grid is The Module. From that starting point, Modules are combined to create columns and fields. Grid Layout doesn't acknowledge the existence, let alone use, of the Module. Instead it dives straight into columns and rows. Which brings me on to my second point:

Nomenclature

grids have been around for quite a while and there is established words for things like Columns, Fields, Modules and Gutters. It's my feeling that the CSS grid module should speak the same language as designers, not that of developers.

A proposal for change

1. Start with a module

The starting point for any grid system is defining your module size. The module has also been referred to as a unit. I'm using module for reasons that will become clear.

To summarise, a module is a repeated rectangle, with gutters in-between, that, when combined, form columns and fields. A module size should rarely be defined, but derived from a fixed, knowable constant to be designed with: image sizes, ad units, video sizes, to name a few examples.

Following the Grid module's syntax, firstly we define our container div to display as a grid:

div { display: grid; }

I then define my grid module with 'grid-module' as 50 pixels wide, and 30 pixels high:

Image showing creating a grid module

div { display: grid; grid-module: 50px 30px; }

This of course be defined in percentages, or Ems:

div { display: grid; grid-module: 8% 2%; }

A new unit of measurement, defined once.

This is why I'm not using the terminology of unit for the module: in a grid system, the module is a unit of measurement. You combine and align content based on modules.

Similar to the Em, the Module becomes a user defined unit of measurement. And I'm proposing that we use that new unit of measurement to build our columns and fields.

2. Define the gutters

The next thing we need to do when building a grid is defining the gutter widths and heights. Please note, there, that gutters are also the horizontal spaces between units as well as the vertical.

For this example, I'll stick to something simple, like 21px.

Image showing creating a grid gutters

div { display: grid; grid-module: 50px 30px; grid-gutter: 21px; }

There's a reason for the 1. Quite often, you may want to visually separate columns of content with a keyline; a line that runs vertically in the middle of a column. If your gutter is an odd number, with an even number of pixels either side of it, it means that 1px is available for the keyline. The syntax for this could be similar to border:

div { display: grid; grid-module: 50px 30px; grid-gutter: 21px; grid-gutter-keyline: 1px solid #333; }

Of course, this keyline would be on every, single module - both horizontal and vertical. We would, of course, have to add this to columns and fields.

3. Define your x count

A module is modular. Meaning it is repeated, both on the x-axis and the y-axis. We know that the y-axis is difficult to work with on the web due to content reflow. We just can't control that vertical height yet. But, we can, and do, define the x-axis.

We use 'grid-x-count' to define the width of the grid. And this is the first time we introduce our new unit of measurement; The Module, or 'md'. In this example, our grid is 10 modules wide, or '10md'

Image showing creating a grid x-count

div { display: grid; grid-module: 50px 30px; grid-gutter: 21px; grid-x-count: 10md; }

Now, all you need to do to see your grid is to add a background colour to the module:

div { display: grid; grid-module: 50px 30px #ccc; grid-gutter: 21px; grid-x-count: 10md; }

4. Define your columns

Next in the process of designing a grid is defining your columns. Now, you should have a pretty good idea of these from how your derived the Module. For this, I'm using the same syntax as the existing proposed Grid CSS3 module. But, for me, the exciting thing is, I can now use the new 'md' unit of measurement to define the width of my columns. So, let's say I want to create a column 2 modules wide on the left, 1 module wide on the right, and then a centre column of the rest. The 'fr' unit here is defined in the existing Grid Layout specification:

I add the 'grid-columns', with the first column as '3md'.

Image showing creating a first column

div { display: grid; grid-module: 50px 30px; grid-gutter: 21px; grid-x-count: 10md; grid-columns: 3md; }

The second column sees the introduction of a second proposed new unit: 'fr' - short for 'fraction', which is proposed in the existing Grid Layout proposal.

Image showing creating a second column

div { display: grid; grid-module: 50px 30px; grid-gutter: 21px; grid-x-count: 10md; grid-columns: 3md, 1fr; }

Finally, I add the last column of 2md wide:

Image showing creating a third column

div { display: grid; grid-module: 50px 30px; grid-gutter: 21px; grid-x-count: 10md; grid-columns: 3md, 1fr, 2md; }

That's my columns sorted. Now, I need to add the horizontal fields. How we might use these fields are for things like headers, content areas and footers.

5. Define your fields

We add the fields in the same was as the columns: using our new 'md' unit. Now, you may well ask: 'why can't I just use pixels for the height of my header?'. Well, you could, but then you'd have limited connectedness to the underpinning grid structure. As such, you header might not feel like it belonged to the other things on the grid. A grid, after all, is about creating unity.

Image showing creating a first column

div { display: grid; grid-module: 50px 30px; grid-gutter: 21px; grid-x-count: 10md; grid-columns: 3md, 1fr, 2md; grid-fields: 3md, auto, 1md; }

So now we have our grid. Three columns and three fields, but all built upon a new user-defined unit of measurement: The Module.

Some nice to haves

There are other things that I would find useful for a CSS grid module to provide. How cool would it be for CSS to be able to give you pain-free baseline grid?

1. Baselines (vertical rhythm)

A baseline grid provides vertical rhythm within your grid, so that type and images align across columns. It's possible at the moment, but fragile. Wouldn't be great if it were a simple declaration that magically applied a baseline grid so that all elements would vertically snap to it?

I'm thinking something like this:

Image showing creating a first column

div { display: grid; grid-baseline: 1em; }

2. Snap to grid

Speaking of snapping. Snap To Grid is a behaviour that many designers are familiar with. It's generally a toggle on/off in layout software. You create a grid with guide lines, and then you can toggle 'Snap to Grid' on so that elements that you position on the canvas, 'snap' to the grid you created instead of float nearby.

Now, this is fine for layout software - where the behaviour is drag and drop - it's a little different when we're positioning things in a document. To be honest, I've no idea how this could work, but the goal is that instead of positioning by pixel, we could 'snap' to our grid. Making the grid and the tools smart, so we don't have to do so much work manually.

3. Grid positioning

Now you have defined a new base unit of measurement, you can use it to position content relatively to the grid (instead of relatively to something arbitrary like pixels).

The benefits of a different approach:

As I discussed earlier, I feel the existing proposed Grid Module for CSS has a number of problems, and what this article aims to do is rectify those.

The process, and mental model of how a grid is constructed, is retained.

Grids are not made of columns and rows. Columns and fields are created by combining Modules. The first step in the process of creating a grid is not creating columns, but deriving and then defining your module size. Then everything else comes from that.

We have a new unit of measurement

By creating a new user-defined unit of measurement, we're able to continually bring the designers attention back to the grid. Not pixels, or Ems or %. Designers get this. It matches their mental model. But I think it goes beyond that. Having another unit of measurement that is specifically used for layout means that we can create a consistent, underpinning connectedness throughout our design. We can create padding and margins from the module. We can position elements relatively by the module size. Very useful, I'm sure you'll agree.

Nomenclature is retained.

Perhaps my biggest issue with the existing proposed Grid module is the words used for elements of a grid. Grid Lines, Tracks and Cells are not terms designers associate with grids.

For example, Gutters are a well understood term amongst designers for the space in between modules of a grid. They are replaced in the Grid proposal by the term Grid Lines. In my experience, the space in between a column is rarely thin enough to be called a line. In fact, quite often in layout, columns are separated by a visual keyline (as I mentioned before), with space either side.

One of the challenges for designers trying to get into web design, particularly trying to learn CSS, is the differences in terminology and also the mental models of how things are created. It's why tables were so popular early on. It's because the process of defining tables and rows for layout was familiar to designers. The terminology for designing grid systems has been around a long, long time. It's taught in design schools all over the world, and baked into design software. It works. And if it ain't broken, why fix it?

A way forward?

There are plenty of holes in this proposal. I'd love to take it forward into a proof of concept. Is this workable beyond simple three column layouts? How would this work for responsive designs? What about mobile?

But I think there's something in this. It just makes sense to me as a designer for the CSS Grid module to be using terminology I understand; for it to support the process and mental model of creating a grid; and provide me with a new unit of measurement -- the Module -- so I can use it to create connectedness across my design.

There are no comments on my blog anymore, but I'd like some debate and discussion around this, so ping me on Twitter and I'll provide an ongoing QA at the bottom of this post.

CERN

As of a couple of weeks ago, Mark Boulton Design -- together with Content Strategist, Relly Annett-Baker of Supernice Studios -- have been tasked with redesigning CERN's public-facing website, and the organisation's intranet. Most importantly, we're helping CERN tell the right story. We're helping the scientists and researchers at CERN (all thirty thousand of them) do their job better by providing better organisation of their internal online tools. We're also helping with a branding project to make sure the brand is represented cohesively across the many thousands of user websites.

It's a dream project. Seriously.

The European Organisation for Nuclear Research is based in a hap-hazard collection of buildings just outside of Geneva, Switzerland. In French, The European Organisation for Nuclear Research is known as Organisation Européenne pour la Recherche Nucléaire, or just simply CERN. Yes. That CERN.

Just after the second world war, several scientists from a bunch of countries (the so-called Founding Member States) got together to form an organisation to progress nuclear research. Over the years, many other countries joined the founding member states with a view to moving beyond study of the nucleus of an atom to that of high-energy particle physics.

The birth of the web

In 1989, Tim Berners-Lee was working at CERN and needed a simple way for sharing information between researchers. The very first website created using this system is still online. Incidently, have a look at the markup (semantically, it's as clean as a whistle). CERN is where the web was born. And I'm a web designer. And CERN is where it was born. Talk about geek-dream come true.

CERN's culture

CERN is a collaboration. A culture of sharing, debate, discussion. We need to work in and amongst that community. We need to get to know them, how they work, how they think, who has a loud voice, who is influential, who are the key drivers of change. And so the list goes on. As such, we'll be approaching this project openly. We'll be working with the community in CERN rather than providing them with something.

I'll be speaking at CERN in September about Designing for Community, and sharing some of my thoughts about designing for two very different open source communities. There will be tales of woe, intrigue, victory – but above all – a story of how, together, people make amazing things.

Our Job

It may just be likely that in the near future an announcement will come out of CERN that will fundamentally change our understanding of the universe. That's an important story to tell. Not only that, but it's an important story for CERN to tell to the right people, in the right way.

We're so excited to have the opportunity to work with some of the smartest people on the planet. To be working on a website that will communicate such rich and valuable stories from recent human scientific endeavours is both exhilarating and terrifying. And, to boot, we'll be working on the project openly within the CERN community of scientists and staff. As I mentioned, the culture of CERN is one that we simply couldn't do the 'designer locks themselves in a room for three months' type of project. We need their help every step of the way, and we'll be sharing our work as we go.

Like I said; terrifying. But, I keep telling myself, if you don't wake up and feel slightly scared about your life, it means you're in a rut. Feeling scared is about risk. And risk is what keeps us moving forward.

Out of the comfort-zone and around a 17 mile collider at nearly the speed of light.

Visual Design is not a thing

Recently, in our industry, I've noticed a disturbing increase of the term 'Visual Design'. It's often used to describe a job title, or a step in a UX design process; 'we've done the strategy, the product definition, the prototyping... now, let's make it pretty with some visual design. We need a Visual Designer to do that'. This confuses and bothers me. So, rather than have a weekly debate about it on Twitter, I thought I'd pen a few words here to make my point.

I understand that you can design things without concerning yourself with colour, type and layout. And, yes, in a UX design process the tasks of product definition, wireframing, interviewing and a whole bunch of other techniques and tasks are done before anyone thinks about typography. But, honestly, I don't know a single good designer who would call themselves a visual designer, or what they do as 'Visual Design'. There is simply so much more going on that making something pink or blue, bevelled or shiny.

Some people equate graphic design to visual design. You're dealing with the surface, with the look and the layout. Now, as a trained graphic designer, I don't think this could be further from the truth. The aesthetic aspects of graphic design are but one part of a whole bunch of necessary skills. To expand on that, here are somethings that I did whilst practicing as a graphic designer:

  • Created paper prototypes of an encyclopedia
  • Interviewed potential customers for a large retail organisation before working on the branding
  • Audited and observed wayfinding pathways in a museum
  • Worked alongside market research agencies

Those aren't the tasks of someone who just makes things pretty. And here's the thing: understanding, talking to and observing your audience is a fundamental part of graphic design research. In fact, it's the first thing they teach you about communication theory: what are you trying to say, and who are you trying to say it to.

So, you see, graphic design is not Visual Design. And given that the look of something –- in my mind at least -- can't be considered holistically without the feel of it, or the use of it, then how can Visual Design be separated as not only a step in a process, but as a job title? Good graphic designers concern themselves with the What, the Who, and the How. The message, the audience and the mechanics. Which is what we do on the web.

If you feel the need to call it something, can we call it what it's always been called? Let's just call it graphic design.

The difference between a Trend and a Shift

Back in 2003, when I first got wind of Web Standards, I was working at the BBC in Cardiff. I read Jeffrey's book and followed the excited writings of Doug, Dan and Dave. The web was electric with promise of a new direction. And all the while, I was working with some developers who questioned my excitement with new Web Standards pathway that was being laid before my eyes:

Why do you want to do that?
Table are better, because Tables WORK!
We can't change, this is the better way because we can be sure the website will behave in the same way on all browsers.
CSS isn't for layout, it's for changing the colour of things.
Web Standards is a trend.

And so it went. Week after week. Month after month. Until some big sites were launched that made people sit up and take notice. The Wired redesign, EPSN and the PGA site. yes, all the while, there were the naysays. The people who refused to accept that Web Standards was an acceptable way forward and, overall, a Good Thing. This is happening today with Responsive Web Design. Although, we're seeing it at a faster rate and, as a result, there's a lot of nuances that are perhaps not being addressed in the advocacy of this approach.

Let's start at the beginning...

Last year, Ethan wrote an important piece on A List Apart called Responsive Web Design. It detailed the combination of a few techniques he'd previously written about under one 'approach'. Then, in Seattle in March of last year at An Event Apart, that approach was combined in a 'Perfect Storm' of presentations from most of the speakers; a collective understanding that we need to move things along in a particular direction.

A few people have been advocating this approach over the past eighteen months, myself included. To me, Responsive Web Design is a set of techniques that serve to solve a bigger problem that I've been exploring for two years: Content Out not Canvas In. I'm excited about Responsive Web Design as an approach, as it helps me frame some of my thinking into practical implementation. Flexible grids, images and media queries give me some of the tools to let me create what's inside my head. But, that doesn't mean it's for everyone, or for every project.

Let's skip back to today...

This morning I got wind of a blog post from Luke Jones about his frustrations with the implementation of the collection of Responsive Web Design techniques. I share some of his frustration. But, just like with Web Standards before it, we need to go through this period of discovery. Pushing boundaries and breaking them is a vital piece of the design puzzle and we're very lucky, in this industry, to be able to do this type of experimentation (you know, without anyone dying or anything). However, the interesting part of this post is the ensuing comment discussion (95 and counting at publication of this post). it's clear to see that there is an awful lot of confused designers out there trying to work out if this thing is valuable and should we use it. Let me just cherry pick a couple of comments:

That's the thing, I'm not saying it looks bad I'm just saying what's the point? I haven't seen a valid reason for changes in browser widths affected how a website is displayed. Luke Jones
"That it changes at all is a red mark against usability, the user loads the page, the expectation as to the structure of that page is set. " Stuart Frisby
Users (me especially) do not want to see a site change when resizing the browser.Luke Jones

This final comment from Luke actually encapsulates the problems:

I think that's exactly it: there is overkill and inappropriate usage going on with the new technique. I honestly think the only people who notice a lot of the responsiveness are people like us, which makes it a waste of time.

I agree with this. But, that's ok. Responsive Web Design is REALLY NEW and NOBODY knows how to do it properly/right/appropriately yet! We're all just experimenting. And THAT'S FINE!

If the approach is deemed to be appropriate, then there is no reason why it can't be done. If people do it on their own blogs, because they want to experiment, then that's fine. It really is.

We're all just trying to work this out.

Like it or not, web design is maturing to a state of recognising the importance of content, presenting that content in different contexts that are appropriate for the users of those websites and applications. We're also challenging web design practice that has been around for 15 years or so, and graphic and typographic design practice that has been around for close to a 1000 years!

This will continue to hurt. And when Responsive Web Design matures, something else will come along that will challenge us again. And that's how we grow. That's how we move this thing forward.

Just as Web Standards was a shift in how we create websites, Responsive Web Design is part of another shift. It may be a little trendy at the moment, as people grapple with how to use it, but quickly – together with other things like Content Strategy, and the One Web, and Mobile First etc. - it will become another tool in this shift to a better, 'Content Out' web.

How Much Design Is Too Much Design?

Khoi echoes some of my own thoughts about the value of design in digital products: is it pixel-perfection, or 'good enough' iteration.

A Richer Canvas

In 1927, Jan Tschichold published his seminal manifesto: Die neue Typographie. As with all manifestos, it's a work of vision, new ways we should think; a work of unwavering principles on how we should design printed material. Abandonment of serif typefaces aside, one of the guiding principles was pointed out to me by my university lecturer regarding designing the perfect layout:

‘‘Though largely forgotten today, methods and rules upon which it is impossible to improve have been developed for centuries. To produce perfect books these rules have to be brought to life.’

The methods and rules Mr Tschichold is talking about are realised in Canons of Page Construction. Geometric systems that create beautiful text for books. Text that belongs. Text that feel connected to the physical form in a binding manner that should make it invisible. It's about comfort. Creating a comfortable, invisible reading experience.

Binding content to the book is what all good book designers do. To do this, they use Canons of Page Construction, or other principles to design grid systems that, when populated by content, create that connection. But with all paper-based design, they start with paper. Paper that has edges, ratios that can be repeated. A canvas. And here's the thing. Creating layouts on the web has to be different because there are no edges. There are no 'pages'. We've made them up.

A richer canvas

If we take that basic desire of creating layout systems: binding content for a comfortable (read: native) experience. On the web, we have to abandon this notion of a page. Let's look at this practically. To design a layout system for a website we now have to consider:

  1. Screen resolution ranging from 2560px wide and above, down to 300px wide and less and, quite literally, everything in between.
  2. Different devices all with potentially different pixel densities.
  3. Context and usage. We have mobile, tablet, laptop, desktop, TV, fridge, car... etc.

To my mind, it's becoming increasingly unrealistic to impose a best-fit 'page' when the variables are so far-reaching and are only getting more so. This isn't going to get any simpler anytime soon, folks. It's my belief that in order to embrace designing native layouts for the web – whatever the device – we need to shed the notion that we create layouts from a canvas in. We need to flip it on its head, and create layouts from the content out.

Content out

Grid system design should begin with a constraint. Something that is knowable and unchangeable. This constraint is used to build the modules of your grid. In book design, that constraint is defined by the page through subdivision. Book designers take the page, divide it up into a modular grid of spaces. These spaces (called modules) are then combined to create rows and columns. These are then filled with content (images and text). The text feels like it belongs because the columns are related to the physical object: the page.

How should we do it on the web? Remember the goal is connectedness and this feeling of belonging. We do that by defining the constraint from your content. The constraint could be derived from an advertising unit, or from a thumbnail image from tons of legacy content. Whatever it is, start there. Don't start from an imaginary page.

Think responsively

Ethan's superb article, talks and upcoming book have given us the tools to make this approach a reality. We can now design effective adaptive layouts that respond to their environment. If these layouts are based on a system that defines its ratios from the content, then there is connectedness on two levels: connectedness to the device, and connectedness to the content. The layout isn't just 12 columns because that's what my CSS framework gave me to use.

The time is now

The conditions are right.

With Responsive Design, CSS3 & browsers, we have the tools. Thanks to people like Kristina Halvorson and Relly Annett-Baker and all the other content strategists out there, we're taking content by the scruff of the neck and we're able to determine what is knowable much earlier in the design process. Above all, we have the desire and the ability to re-write the rules that have matured over literally centuries of graphic and book design practice.

Embrace the fluidity of the web. Design layouts and systems that can cope to whatever environment they may find themselves in. But the only way we can do any of this is to shed ways of thinking that have been shackles around our necks. They're holding us back.

Start designing from the content out, rather than the canvas in.

For those who may want a little bit more than this rather high-level blog post, I'll speaking about this very topic - with plenty of practical application - in my upcoming talk at An Event Apart in Boston in May, and my book which will be out this summer.

Oh, and incidently, the blog post is in response to Chris Shifleft's call for more blog posts. His Ideas of March post has already prompted many people to blog more than they could ever do through Twitter. I too pledge to blog more in 2011 than I did last year. Promise.

Explorations in Typography

A great looking book by Carolina de Bartolo and Erik Spiekermann out in April 2011:

Explorations in Typography: Mastering the Art of Fine Typesetting (A Visual Textbook for Intermediate to Advanced Typography) is a vast collection of beautiful typesetting examples. Page after page, a brief article by Erik Spiekermann has been set in hundreds of different ways in hundreds of different typefaces, creating an extended visual taxonomy of typesetting that allows you to “learn by looking."

Interestingly, the site has 'key features' of the book listed in the same way you would list features of an electronic product or web app.

24 ways: Extreme Design

Hannah Donovan talks about Extreme Design over at 24ways. It mirrors a lot of how we work at Mark Boulton Design. The traditional studio system is becoming increasingly irrelevant and incompatible with modern web/software methods.

Like extreme programming, extreme design requires us all to be equal partners in a collaborative team. I think this is especially worth noting for designers; our past is filled with the clear hierarchy of the traditional studio system which, however important for taste and style, seems less compatible with modern web/software development methods.

This approach takes lo-fi over high, stickies over documents, pairing over isolated working.

UXPin

Our UX Director, Alex Morris (@aexmo on Twitter) just showed me a nifty little paper prototyping kit called UX Pin.

UXPin Portable Kit was designed to let you easily document one web project. We provide you with basic user interface elements (buttons, combo-boxes, check-boxes etc. – 50 each), universal elements (to easily make menus, lists, boxes – 50 each) and 50 pages paper browser notepad. Everything is smartly packed in beautiful hard-cover, so you can pass your prototype to your teammates and don’t lose anything.

My only beef is it doesn't leave too much space for annotation or notes. The plus side is, it's got me thinking about grid sketch books.

Makedo

Makedo is:

A set of connectors for creating things from the stuff around you

As someone who is a bit partial to making robots and crocodiles from all manner of cardboard tubing and old cereal boxes – for my daughter, you understand – then it's a no-brainer for me: bought!

From Kickstarter: The Noun Project

The Noun Project aims to 'share, celebrate and enhance the world's visual language'. Their goal is to pull together all of the visual icon standards and give them away for free. Nice idea. I've pledged some money to get a tee. You should too.

Khoi Vinh writes a book

At last, we will have a grid book from Khoi. Out in December. Preorder it now from Amazon. In this blog post, however, Khoi tells us all about it and gives us a sneak preview of the front cover.

Designing from one end to the other

A little over a year ago, we published my first book with Five Simple Steps. A small ripple in the publishing industry, but a large splash for us. From that single tentative toe in the water, we've gone and dipped our whole leg in with the production of six upcoming titles - ranging from Andy Clarke's Hardboiled Web Design to Brian Suda's Designing with Data.

Today sees the shipping of Donna Spencer's 'A Practical Guide to Information Architecture', and its prompted me write a little bit about how the work we did a year ago is now starting to pay off.

Donna Spencer's 'A Practical Guide to Information Architecture'

Donna Spencer's 'A Practical Guide to Information Architecture'

Designing from one end to the other

I've said before one of the reasons I wanted to publish my own books was because of wanting to control the process; from editing through to design and production. As time has gone on I've realised that the thing I get a kick out of is being able to control - well, actually, have an influence over - is the entire customer experience; from the moment they look at the website to buy the book, right through until they receive it in the mail. Being able to make that journey consistently is incredibly challenging as elements within the production chain are always trying to take control away from you. Let me give you an example; packaging and fulfilment.

There are many packaging and fulfilment companies across the world. They exist to help large and small companies deal with shipping goods without the headache of having to store, process, package and mail out the stock. They do it all for you and you pay for the square footage of warehouse space you use, together with a per order fulfilled charge. All good. One thing is common amongst most large fulfilment companies, however. They generally like to use their own packaging. Using your own is more costly for them - so much so, some just won't entertain the thought.

The Five Simple Steps books come in a bespoke box designed to withstand a fair bit of knocking about. You see, due to the slightly heavier paper stock, these books weigh in at 1kg each. That's a fair weight to be dropped onto its corner. The packaging also had to look attractive. We wanted to create some kind of unboxing experience - receiving and opening these books should be another step along that experience journey. It's not the end of the line. This got us thinking a lot more about the customer journey with us.

Five Simple Steps packaging. At 1kg each, these books aren't light.

This is roughly the journey customers take:

Initial contact

How did the customer come into contact with the book? Was it a referral or reference. Word of mouth? Google? Twitter? You need to understand where they came from and why? How can you make that first impression a memorable one, because those first impressions count.

Evaluation

Is this produce for me. Will this book make me a better designer/developer/IA/project manager? How does this book relate to me and my life?

Decision

How much does it cost? Is it worth it?

Form filling

Nobody, nobody, nobody likes filling in forms. They're always difficult and riddled with potential errors. How can you make it not just easy, but pleasurable? Well, sometimes just being easy is pleasurable enough.

Fulfilment

Now I've parted with my cash, what happens? Do I receive an email? When? Are my books being shipped? When?

The waiting

How do I know what is going on? Is my order just sitting on a shelf somewhere?

Receiving and Unboxing

Receiving packages is always exciting. It's not the hardest thing in the world to make pleasurable. But, with some careful attention paid to packaging, labelling, language and materials and you can make opening a box more delightful than using the thing inside. Just look at Apple.

The digestion

The story doesn't end with receiving the book. Does it deliver on what you promised? If not, how does the customer go about changing that?

Of course, what I'm describing here is the process that's been around as long as mail order has. It's not rocket science, but it's so, so easy to get wrong. We've only just begun on this path and, to be frank, there hasn't been a week goes by that we haven't learnt something or screwed up in some way. But regardless of the pain and frustration a customer may experience, there are some things you can put in place to help them forget. Again, a sideways glance at Apple.

Spikes Of Joy

When I describe this to potential clients, I talk about 'Spikes of Joy' - those tiny moments that bring a smile to your face. If you're listening to music, it's the moments when you feel a wave of joy; when the right notes combine to create a physical reaction. The same approach can be applied to design of all sorts. It certainly applies to web design, but I'm not talking about web design here, but something more akin to Service Design. Throughout the Five Simple Steps customer journey, we want to create spikes of joy. Small moments of pleasure. Surprises. Care and attention. Love. And, you know what? It's really, really difficult.

Making something with care and attention is easy. That will always shine through in a product. Authenticity, truth and love is always easy to spot too. If product designers and manufacturers care - every step of the journey - you, as a customer, will be very satisfied at the end of that journey. BUT, it does not mean there will be moments of pleasure along the way. Sure, it may go without a hitch, but you could experience it with a complete straight face. What's hard is connecting the mundane purchasing journey with moments of human pleasure. That's difficult to do.

Books and Joy

I've always deeply loved books. I trained to be a book designer. I love their form, their smell and the knowledge they hold. Making books joyful things isn't too hard. Making purchasing books is. How do you make that process more than enjoyable? How do you create spikes of joy?

I'd love to know what ideas you may have.

Timeboxing Triage

For quite a while now, I've been struggling with how to cope with everything on my plate at work. I run a small business, starting a new publishing business, I'm an art director, project manager, sales director. And so the list goes on. And I know I'm not alone, we're all busy, right? We're all pulled in every which way.

Thing is, I have a couple of designers and developers here who need my help every day. They need to run things by me, get feedback on work, resolve issues. And so the list goes on. What I was struggling with was the interruption to my flow. It meant that, quite often, I'd end a day feeling I hadn't accomplished anything other than fight other people's fires. Of course this is the wrong way to think about things, and I was actually doing my job by doing all that. But I still needed to apply more structure to this activity, so that I could have available time to spend on designing and all the other stuff.

So, a couple of weeks ago, Emma introduced the idea of a bi-daily 30 minute triage. This is time for everyone to have a bunch of things they want to go through with me. At 10am and 2pm everyday, I keep that time free and available for whoever needs me. And, so far, it's working a treat.

There we have it: timeboxed triage. Give it a go.

On Designers writing HTML

Every once in a while, this little debate bubbles up the surface, then dies back down again, only to surface again with more vigour. Today was one of those days, and the debate was:

Should web designers be able to write HTML?

I'm being very specific about that. I'm not saying, 'should designers be able to code' - that's a completely different thing. I'm also not saying, 'should good designers write their own code'. Subtle, but important, distinctions. Regardless, today was one of those days. In may well have been sparked by Elliot's inflammatory tweet. The discussions carried on for a little while, and the blog posts have started arriving on the subject, this one included.

I dipped in and out of the discussions today. There's only so much you can say in 140 characters, and explaining the nuances of opinion is tricky to do on Twitter at the best of times, so I thought I'd pen my opinions here. You know, as it's my blog and everything.

I think the answer is: It depends.

What is web design, anyway?

There are well-articulated arguments on both sides of this. From Andy's and Meagan's musings on designing in the browser , to Mike's short, practical tips. Given these points of view, it's very difficult to disagree.

Of course, sometimes, it makes sense to design in the browser. You can't do that if you can't write HTML. Of course, it helps understand the very building blocks of the web (from a designer's perspective, anyway). It's saves you time and money. It can help you realise your designs the way you intended.

But, and here's the thing, we're talking about a tiny aspect of web design here. We talking about implementation. Making something work in a browser is only part of what web design is.

Understanding the medium

I hear this a lot when people talk about HTML. 'You need to be able to code to understand the medium'. Sorry, but that's bullshit. HTML is not the medium. At all.

Let's look, for a moment, at Television. TV is a mature broadcast medium. Good telly is not about pixels, or how the they get sent from one place to another. Good TV is about storytelling, engagement, audience, interaction and a whole lot more. The medium isn't defined by the practicalities of production - although of course, it is a part of it - it is defined by the people watching it. Why they need, what they look forward to, what they spend their valuable time engaging with.

The same is for Radio. Good radio makes the technology disappear (note: so does TV, but you just watch 3D TV fall on its arse later this year - it'll be like betamax all over again). Great radio is a wonderful thing. But it's not about radio waves, it's about people. The medium of radio is defined by the all of the things that defines TV. The differences being the technology, the mode of engagement and the audience. Not a whole lot more.

Perhaps it's because the web is a relatively new medium is why we're struggling with this as designers. The medium of the web, as far as I see it, is only partly defined by technology (HTML being a small part of that). It's defined by people, by stories, by products. There's just so much in there that by saying you have to be able write HTML to design for the medium is really undervaluing the other areas of the craft. A designer who is a fantastic writer, with a flair for typography - and an understanding of concepts such as semantics and document structure - is no less of a designer just because they can't write HTML.

Shades of grey

I guess the upshot to this is that I think that there are shades of grey. Modern web design covers so many areas of specialism - from HCI and IA through to Illustration and dabbling with Javascript. To deem it necessary to write HTML to be a good web designer is really quite disrespectful to experts in those subsets of web design who never go near any HTML, yet have equal value to bring to a design project.

So, for me, it's not a case of 'yes' or 'no'. More like 'it depends'. It depends on the project, the team, the individual. This upsets me, because I'm kind of a black and white kind of bloke. Never been a fan of grey, but honestly, that's all I'm seeing here.

Mike Rundle's Portfolio — Flyosity: Mac & iPhone Interface Design

Mike Rundle's great tutorial on interface design for the Mac and iPhone. Interesting to note how this aesthetic is now transcending the platform and becoming much more commonplace on the web. Mike also provides a free PSD template for us to use!

New Drop Caps

When I redesigned this blog a little while ago, the drop caps I used were always going to be a placeholder. Following an evening with my Sister-in-law--who happens to be a textile designer/illustrator by training--I commissioned her to produce a complete uppercase alphabet based on Georgia. I'm thrilled that two months later, they're live on the site. (if you're reading this on RSS, then pop on to the web to see what you're missing).

The brief was pretty simple. I wanted illustrative drop caps produced that were aligned to the inspiration for this design; namely Renaissance illustrations and carvings. They ended up being slightly broader in inspiration than that though. They're hand painted on thick, textured cartridge paper in black ink.

I planned on interviewing Helen (and I still plan on doing that), but I just couldn't sit on my hands until then. Here's a few letters that are particular favourites of mine. Interview coming soon...

Drop cap G

Drop cap S

Drop cap h

Drop cap o

Web Directions & Typographic Structure

Last week I presented at Web Directions South 09 here in Sydney, Australia on Font Embedding and Typography. It's a talk I gave at @media 09 in London over the summer. I enjoyed giving the presentation - despite AV problems which resulted in a ten minute reduction in time allowed and having to give the presentation without notes. But the show went on.

But despite that single hitch, Web Directions was quite possibly the best web conference I've been to. I was congratulating John and Maxine at a speakers BBQ on the Sunday following the conference, and it became evident it was down to their undying attention to every, single little detail, from the moment you register to the food you are served (which was excellent by the way). But the lasting memory for me was the buzz of the Australian web industry. It was very refreshing to visit a country not in recession and see an industry thriving on creativity rather than suffocating beneath a blanket of uncertainty.

But anyway, before this turns into a rant about politics, back to the presentation...

This was not a practical presentation full of hints and tips or a presentation about fonts. Or font embedding. Even though I touched on these two subjects briefly, this was a talk about typographic design and all of the aspects of the craft that I find important and how I relate to them in particular to this medium.

A core part of the presentation describes my understanding of typographic design and why font choice is only one of nine aspects that need to be considered when designing with type on the web. This is the third model of typographic design I've been working through now, and not only is it sticking, but as I'm beginning to explain it to other people, I'm not having to change it too much. It has almost passed the mother-in-law test. For me, it's working as a way to explain what I do and I'd like to share it to get your thoughts.

Typographic Structure

Typographic design, as I understand it, involves nine elements:

Language

Language is entwined with typography. Type can be defined as the display and arrangement of language. As designers, we should care about this.

Typesetting

Typesetting is the process of taking raw text and marking it up. Making headings, lists, emphasised text etc.

Grid

The typographic grid is a foundation upon which layouts can be built.

Hierarchy

Conceptually, content has levels of importance. Typographically, Hierarchy visualises this.

Font

The font used to display the content.

Rhythm

How the arrangement and layout of the type aids reading.

Layout

Combining type with other graphic elements such as photographs, illustrations, video or other UI elements.

Colour

Colour, when discussed in typographic terms, can mean two things: red, green, blue etc. or dark or light typographic colour. Dark typographic colour is dense type--tight leading or line height, tight whitespace. Light typographic colour is the opposite.

Content

One of the unfortunate things on the web is that, generally, we're designing not knowing what the content is. We have an idea of what the content might be, but when dealing with content management systems and the flow of data, it's very difficult to know. But content is an important part of typographic design and this connection is one of the casualties of the web standards mantra of separating content and presentation. When we do that, it's very difficult to tell stories with design.

Here's a diagram:

Typographic Structure

As you can see, your choice of font only plays a small part in the overall typographic considerations. Of course, on the web, we've had our choices here limited to the point of almost removing the element of choice. And don't forget that a number of these elements are also completely in the hands of the user to change at their will.

My point is this: font choice is only part of what makes good typographic design. The limitations that have been imposed on us--with only a hand full of fonts guaranteed on user's machines--have nurtured fairly good typographic craft on the web. Generally, we care about the content; we mark it up with the correct intended hierarchy; some us care about typesetting ampersands, or bulleted lists. I'm not sure that the same level of care and attention is employed by some of our print cousins (and I say this having spent quite a few years on that side of the fence). Why is this? Well, designers are like magpies; we get distracted by the shiny.

When I was in university, I sent off for every type specimen sheet I could get my hands on. I pestered everyone from Monotype to Emigré. Receiving the canvas bags stuffed with font supplements from T26 was certainly a highlight of my first year. Why? Well, firstly, type supplements are normally beautiful things. They didn't necessarily make me look at type any differently, but they made me want to collect type. I'm sure that mindset isn't that rare in anyone who cares about type, but it's a mindset that leads to a shallow understanding of the broader craft. You get distracted by the next beautiful typeface. You're constantly on the search for the typeface that is just right.

Font choice is not the most important decision you make when designing with type. On the web, currently, it is way down on the list because of the constraints of the medium. With commercial font embedding just around the corner, we stand on the edge of an incredibly exciting time for the typographic web. In eighteen months time, I think the web will be starting to look very different. And about time too, but let's not get distracted by the shiny.

A roundup of speaking

This year has been a pretty full-on year so far on the speaking front. What, with one thing another, I haven't been linking them up. My bad. So, if you'll indulge me, over the course of the next few days or so, I'll be writing about them, posting links to the presentations in Slideshare. At least from what I can remember.

This post will act as a kind of index for the speaking i've done this year, but I'll also link things up on my brand new 'speaking' page.

Designing for the Web: Paperback available 14th April

Just a quick note. The paperback of my book, Designing for the Web, is available on the 14th April at 12pm GMT. That’s tomorrow. I have 1500 copies all ready to go, and these will be available on a first come, first serve basis.

If I sell out, I may just get another print run done. We’ll see.

Drupal7UX: we need you NOW!

We plan to make the Drupal 7 User Experience something very special. The biggest risk to this project is community rejection/involvement too late in the project.

Please, get involved now.

Get out of the issue queues, quit bitching about your other CMS tools.

Please, get involved, so we can all succeed.

Get over here and help us make something amazing.

Thank you! (and even bigger thanks to those who are already involved)!

The Personal Cost of Designing on Spec

Yesterday, a rather heated debate raged over on Carsonified’s blog regarding a design competition they’re running to design a slide for the upcoming Future of Web Design conference in London. The debate was an old one, resurrected every now and then and fiercely debated on both sides. The debate was regarding speculative work. It’s a subject I feel very passionate about as I’ve seen the damage it causes – both personal and professional.

I’m a little tired of justifying my position and opinions on Twitter, so I thought I’d pen a few thoughts here and explain my personal viewpoint and hopefully spark some considered, intelligent debate (see my paragraph citing Matt Henderson for an example of this).

Defining Spec

I’m not going to spend a huge amount of time defining this here. I think most people understand what spec work is and why it’s damaging. Speculative work (or spec), can be defined by the AIGA as:


‘work done without compensation, for the client’s speculation’


Spec work, in my view, leads to a number of things:

  1. Sub-standard work.
  2. It undermines and devalues design.
  3. It harms the design industry.
  4. Exploitation.

Are Design Competitions Spec Work?

If you’re in the UK, you probably know of Blue Peter. Blue Peter is a long-running childrens TV series that has been going for, oh I don’t know, maybe 500 years on the BBC. Up until recently, Blue Peter ran many, many design competitions for children across the UK to enter. Kids would send in drawings of their wild and wonderful designs for all many of things. Now, is this spec work? Is it unethical? No, I don’t think so.

Children aren’t designers. It’s not their profession, and they’re not submitting professional work.

There was a great comment on the thread yesterday regarding Threadless. People submit designs to threadless, get paid if their design is picked, and get the glory of seeing it printed on t-shirts. Is this spec work? Even though Threadless are making money from this? No, I don’t think it is.

Designers and Illustrators want to be part of the Threadless brand. They have a lot of pull, so much so that professionals are willing to contribute to that brand. In the same way that if Apple were to do something similar, I’m sure many people (probably myself included) would contribute. Wanting to contribute to something you feel part of, or want to be part of, even if money is being made as a result is not spec work. It’s about wanting to belong.

Personally, I see a competition that targets a profession and solicits entries for a prize as exploitative and professionally unethical. For some, it may just be a bit of fun, but for me, it’s pretty reprehensible. I feel rather strongly about it.

The Personal Cost

I’ve worked in two industries where spec work is the norm: advertising and print design, and I’ve a close relationship with another: architecture.

I used to work for a reasonably sized design agency. We would spend maybe 30% of our time on unpaid, creative pitch work. We would also spend perhaps 10% of our time on design competitions, which I believe is spec work. That’s right, 40% of our time was spent working for the potential of winning one project that would pay for all of that speculative time. Now, if you’re starting out in business, or feeling the pinch as many companies are during these difficult times, your time, and the way you spend it, becomes critical. If 40% is spent doing stuff your not paid for that is potentially damaging.

The practice of spec work is the industry norm in architecture.

My father’s an architect. He runs a small practice and spends an extraordinary amount of time producing spec work. Unfortunately, the industry demands it. The spec work is conducted on the hope that one of the projects will be awarded to the practice and that will pay for the time lost on the other projects. Architecture is also an industry that is rife with design competitions. Some would argue that this is worse than spec work to a shortlisted field. Architects are invited to submit bids, proposals and designs for prestigious competitions. The winner gets the contract and the glory. The losers get nothing; the work is conducted speculatively.

I believe the practice of spec work harms business. It can be crippling, for both suppliers and consumers. Businesses fold, and consumers get sub-standard work.

A Free Market

In amongst the usual trolling on Ryan’s blog, I had a very interesting discussion with Matt Henderson regarding spec work. Matt is a guy I admire tremendously. I’ve worked with him in the past out of his Marbella office on some fascinating projects and he’s a smart bloke.

Matt’s take on spec work, if I understood this correctly, was that the market will dictate the practice. If both sides of the market – the supplier (the designers), and the consumer (the client) – find that speculative work is mutually beneficial, then the practice would become an industry norm. This view sidelines personal opinion, and presents spec work as a consequence of market conditions, which is fine, it is. But does that mean that the creative profession should shrug their shoulders and accept it as such despite ethical misgivings?

For The Record

For the record, Ryan is a good guy. My intention wasn’t to target Ryan personally, or to claim that Carsonified was unethical, they’re not. He doesn’t deserve the lambasting he receives on his blog for genuinely trying to do the right thing; for doing something he believes in. But all of those designers who commented on that growing thread were also doing that – commenting on an issue they believe in. The debate wasn’t personal, or unprofessional, it was a raw nerve.

I’m hoping this post sheds some more light beyond 140 characters on my own personal relationship with spec work and how I’ve seen first hand the damage it causes. I for one welcome an industry that debates these issues. An industry where you’re free to make a mistake, to openly question motivations and to do something you believe in. As Matt said, ‘let the market run its course’, but if you don’t agree with where it’s headed, push back and fight for what you believe in.

Drupal Voices 02: Colleen Carroll on SXSW CMS Showdown & Zen Theming | Lullabot

Interview with Colleen Carroll on building the theme for the #CMSshowdown panel in SXSW this year from my design. This is now being made available as a Drupal 6 typographic theme.

Audience Matrix: Our thoughts on the Drupal 7 audience

Leisa and I have spent a good deal of time looking at how we can define the audience for Drupal 7. A couple of weeks ago, we spent a day trying to come up with an effective model to use throughout the design process. Not just a model that we could use, but one that could be available to the whole Drupal community as we embark on the challenging task of looking at the user experience for Drupal 7.

The Flappy Paddle

Before I start to talk about this tool, it’s probably better if you just watch this video Leisa and I recorded a week or so ago.

This is the tool we’re using, but at this stage, it was pretty rough around the edges. So, we’ve spent a little more time defining the various tasks and definitions for each different user type, site type, and number of users. Combining this detail, in various different combinations, gives us a list of requirements for that type of user, using a particular type of site, with a certain amount of users.

Sweating the details

Yesterday, we spent some time fleshing out the various tasks and definitions for each ‘paddle’.

This is what we’ve come up with so far:

Roles

<

p>

  • Content Creator: a user who primarily creates, reviews, and edits content for a site. Key tasks: Add content, edit content, find existing content, view list of content creation/revision tasks.
  • Site Editor: a user who has authority to approve, edit or reject content and who may be able to manage some editorial workflow and user permissions. Key tasks: Add content, edit content, find existing content, view list of content creation/revision tasks, review content, reject/feedback on content to original author, schedule content
  • Site Admin: manage user permissions, manage site structure, adding new content types, create and review reports and manage some site settings (RSS Publishing, IP Address Blocking). Key tasks: Manage user permissions, Add / Edit / Delete Content Types, Manage Information Architecture (site sections, sub-sections, taxonomy (as in, vocabulary), Create a report, Review a report.
  • Site Builder: creates site from scratch by choosing, writing, customising modules and/or themes, manages setup and maintenance. Is a developer (for the purposes of audience definition, themers are considered developers). Key Tasks: Develop site functionality, implement site design.

Type of site

<

p>

  • Brochureware Site: hierarchical structure of relatively static content, often includes forms (eg. contact/feedback), may be multi-author
  • Blog: sequence of chronological posts that may be assigned to categories, may also include ‘fixed’ pages, often includes comments, trackbacks, RSS feed, most often single author
  • News: a categorical/hierarchical grouping of content usually ordered chronologically but often ‘curated’ by an editorial team, may also include comments, trackbacks, RSS feed, often multi-author, often requires multiple templates
  • Events: a combination of content supporting an event, including content about the event, a schedule/calendar of events, list of participants, online registration, may also require online submissions, social networking functionality, news, email update list
  • Social Site: comprises member profiles and communication between those member in the form of discussion forums, wikis, events, blogs, require member signup, subscription, RSS,

No. of users

<

p>

  • 1: no permissions, no workflow, that user does everything (one stop shop) BUT most like to have simple requirements (how manage giving access to all functionality when the mostly won’t need it). Likely to generate small amounts of content.
  • 2-5 : multiple authors, may require permissions, may require workflow (simple approval process), may require separation between content management tasks and site management tasks but usually not overly complicated requirements.
  • 6-15: multiple authors and editors, likely to require permissions, likely to require workflow, likely to require separation between content management tasks and site management tasks may have some complex requirements, will have significant amount of content generated.
  • 15+ : requires permission management (several permission profiles), probably requires workflow (content review/approval), likely to generate a lot of content to be managed and require content scheduling - it’s a complicated machine and it needs a whole section around managing the machine, let alone making the content to feed the machine. Involves a lot of content and likely complex taxonomy.

And also, as you saw in the video, we’ve looked at using this tool now as we begin sketching out some ideas and concepts for how the admin may work.

An evolving concept

The Audience Matrix is work in progress and it’s going to be an instrumental tool for us in the coming months as we start fleshing out some of the design concepts. As Leisa says on her blog:

Over the coming weeks we’re going to be inviting you to submit your ideas for revisions to the Drupal7 Admin interface and overall user experience. It will be very helpful for us all to use this document to help make sure that we’re designing for the 80% and not necessarily just for ourselves! And it is also a really great way to expose missing elements and possible flaws in our concepts. Using the document to test the example we show in the video above helped us to realise that we needed things like a close button on the dashboard (I know, d’uh!), a place to hold the user generated content from things like comment as well as contact forms, and got us thinking about a whole host of thorny permissions and workflow issues.

We need your help. We’ve produced a PDF for you to download so you can use it in some of the upcoming crowdsourcing activities we have planned. (like the one’s we did for the Drupal.org redesign project).

There will be more from me

It’s a fair cop. I’ve not been as active blogging about this stuff as I could have been. Both the Drupal.org redesign, and now the Drupal 7 UX work, are both breaking ground on a process thought to be difficult, if not impossible. So, as of today, I’m going to be talking about it all a hell of lot more because, well, what other projects can you talk about as you’re doing it? We’re in an incredibly fortunate position.

Drupal 7 Redesign

DrupalLast week, I flew to Boston, MA, to have a meeting with those fine folks at Acquia about a project they wanted my small design studio to look at. Today, Dries Buytaert, the founder of Drupal, announced that, together with Leisa Reichelt, we’re going to be working on improving the user experience of Drupal 7. Needless to say, we’re very, very excited to be part of this project.

From what we learned on the Drupal.org project, both in terms of process, but also some of the stumbling blocks that Drupal has, we’re confident we can make some changes that will make it easier to use for people who are new to Drupal, but also experienced users.

Leisa and I are going to be at DrupalCon DC in March. We’ll be kick-starting our research, presenting on the redesign of drupal.org, and doing a lot of listening. if you’re going please tap me on the shoulder and say hi.

Designing for the Web Book Review ~ Uncoverr

Lovely review for Five Simple Steps. Nice to see the breadth of the content is appealing to a broad audience. That was idea!

Win a copy of A Practical Guide to Designing for the Web : Boagworld web design podcast

Paul's running a competition to win a free copy of my book.

Designing and building an eBook delivery system

When I first looked into writing Five Simple Steps to Designing for the Web, I looked at a bunch of options for delivering the PDF over email. I thought about building something myself or hosting it with various web applications used for delivering digital products. The first option just wasn’t an option at all in the end - I’m no programmer. The second option, although perfectly viable, saw the potential profit of the book undermined by a monthly, or per unit, charge. I made the decision, quite some time ago now, to commission the software to be built by the super-talented Steven Teerlinck, using the Code Igniter PHP Framework.

Five Simple Steps publishing back end

This isn’t a particularly complex bit of software, but Steven’s done a fantastic job in simplifying it to a number of core user and system flows:

The Requirements

<

p> So, I wanted to sell a PDF. Ideally, I wanted the following functionality:

  • Have a discount coupon, so people could redeem them for, say, £3 off
  • A discount period. For example, over the Christmas period.
  • Multiple licenses. From single user, to ten.
  • The delivery of the PDF itself.

The user flow

<

p> The user flow through the system is this:

  • User selects book, and fills in license details - they enter a code here if they have one.
  • The user is directed to Paypal where they part with their hard-earned cash
  • Upon a successful transaction, the user is redirected to a ‘thanks very much’ page.
  • The user receives an email from Five Simple Steps whereby they can download their PDF for up to 72 hours.

The system flow

<

p> The system does this:

  • Upon receiving an ‘order’, the system checks to see if the Paypal purchase is valid.
  • The system to generate a unique code for that sale
  • This all sits in a queue that is set up on a CRON to send every 10 minutes
  • The code is emailed, along with a handy link, so the user can download the book
  • Upon clicking, the code is checked against the user, license, and to see if they sale is valid
  • The code triggers a PDF stamper to dynamically stamp the PDF on every page

A large majority of initial sales will come from the money-off coupon that has been running on the site for a while. The coupon system works thusly:

<

p>

  • I can create one-off coupons, or bulk import from a comma separated file
  • The coupons are queued up and processed every 10 minutes by a CRON job
  • A user is sent an email with a unique coupon code.
  • The user clicks a link which directs them to the purchase page and populates the coupon field.

That’s probably about it. The system is small, trim and effective for my needs. As time goes on, I’m hoping to add further functionality to support shipping physical books in addition to (possibly) more titles. We’ll see. Being involved in building a bespoke bit of software for the delivery of the book has been very interesting over the past six months or so. Not only has it shown what a flexible framework Code Igniter is, but also how important it is, as a (soon-to-be) publisher, to be in-touch with your distribution software and process.

Why Self Publish?

Two weeks today, I’ll be releasing the long-delayed self published book of mine, Five Simple Steps: Designing for the Web. Since I originally thought of writing my own book, producing it, and distributing it, I’ve been asked several times, ‘why not go with a traditional publisher?’

I’ve had several offers for this title, from big tech-book publishers, design publishers, through to smaller outfits and literary agents. I’ve turned them all down. Why? Well a few important reasons:

My Voice

Several of my good friends have written books, and I’ve design reviewed a couple, and written a a chapter in one. Not a massive amount of experience, granted, but enough to sour the taste of traditional publishing in my mouth. The biggest concern of mine was losing my ‘voice’. I want a book I’ve written to sound like me. Not some watered down, ‘internationally-toned’ amalgam of me, my editor, a proof-reader, and tech reviewers. I want it to sound like me, and I’m hoping, my readers do too.

The Process

Writing this book has been really difficult. Luckily, I’ve got a good team around me - a designer, a project manager, a proof-reader, and an editor to shape the book (that was particularly helpful early on). But, there’s just no way I could’ve written a book in the last two years if it hadn’t had been on my terms alone. My wife and I had a daughter, we built an extension on our house, and I’ve been building a business in challenging times. To fit a book around this has been tricky, and I needed to have the flexibility imposed by my own schedule, not someone elses.

The Design

Most web design books are terribly designed. I mean, really bad. If I was going to write a book, I was going to design it too. As it turned out, I’ve art directed the production of this book, rather than designed every single page and diagram. But, the point is, it will be a design I’m happy with. I know several designers who have written books who ended up doing the design for them for free!

Financially

Although not the motivation for the book, the financial potential of just one PDF book far outweighs the traditional process (if you have an audience that is). Most author royalties are miniscule compared to the profit the publisher makes. With a PDF distribution my only costs are the time taken to write the book, and the ongoing hosting and Paypal fees.

A Printed Book

Luckily we have the skills in-house at Mark Boulton Design to design, produce and distribute a hard copy book. Currently, we’re looking at producing a limited edition case bound (hard back), high-quality book. BUT, this will only be if the sales of the PDF can support the initial outlay in getting a print run done.

Of course, there are advantages for a more traditional approach. As much as the process of writing and editing is painful, you can be assured of a good product at the end of it – even if it doesn’t sound like you. You don’t have to design it, typeset, proof (again, and again), artwork, production, delivery, customer service. There’s a lot that goes into publishing and I’m learning the hard way. But, it’s fun. The book is coming along nicely, and two weeks today, will finally be released.

It may not be a work of beautifully crafted prose. But it will be me. Warts and all.

Feltron Eight

Required reading. The fourth Annual Report is available.

Persona Templates

Well-designed Indesign templates for your Personas.

The Book Cover Archive

Wonderful resource of book cover design.

An Event Apart: The Design Conference For People Who Make Web Sites

New An Event Apart site. Very tasty.

Erskine Design

New Erskine site.

Sparklines with Google Charting Tool

Rather nice, simple Sparkline generator from 13pt

CRW / Corporate Risk Watch

Simple effective design. Refreshing to see such companies go out on a limb design-wise.

Black Estate Vineyard

Beautiful typography, stunning photography and probably damn tasty wine.

24 ways: Art Directing with Looking Room

My article is up over at 24 ways. Use Looking Room to go some way to art directing the templated web.

Blog - Campaign Monitor

Great masthead design for the new CampaignMonitor blog

Fray: True Stories of People Taking Things Too Seriously

New issue of Fray with article on the awesome Windhammer.

The Grid System

Your one-stop shop for articles, blogs, books and tools for everything that is Grids.

The Design Manifesto, BusinessWeek

Interesting Manifesto On Design from the World Economic Forum.

Drupal.org, Design Iterations, and Designing in the open

It’s been a good while since I announced we’re working on the redesign of Drupal.org. Two months, a couple of presentations, and seven iterations of the prototype later, a glimmer is at the end of the tunnel.

On thing is for sure, in this instance, Design by Community works.

I said, when we embarked on the process of designing this site, that Design by Community is the only way we could approach it. Since those initial thoughts, Leisa and I have continued to push a process that many thought would fall flat on its face. I’m not sure if this would be specific to the Drupal community, but they couldn’t have been more wrong. This process is working, and really well.

Keep Listening, and Keep Learning

Asking how your users feel when using your website is important. We all know the value of usability testing; of involving the user right from the start, and as much as possible. What we didn’t know, with this project, was how to scale that out to a community of hundreds of thousands of people.

‘Traditional research’ tends to work like this: testing is usually done on a manageable sample of users indicative of the audience. The sample is generally carefully selected (by various means: interviews, phone interviews, questionnaires etc). This can take a while, and can cost a fair bit. It’s time and budget we just didn’t have for this project. So, how do we reach out to the audience?

We used a bunch of channels for this:

<

p>

  • Twitter. We set up a Twitter account and searched Twitter twice daily for mentions of Drupal. Our aim was to catch people when they were in the moment. We’d ask them a few questions, and we’d follow them to see how they got on.
  • Flickr. We set up a Flickr group and used it as a place for the community to post their thoughts, wireframes, sketches and designs.
  • Drupal Groups. We posted regularly to the Drupal redesign group. This helped us gather the feedback of the existing community.

The aim of the different channels is to keep them open and approachable. We want to listen.

Prototyping using Blueprint

Early on, we decided the best approach for this project would be rapidly built prototypes: html wireframes. In order to spend less time worrying about CSS and validity of markup, we decided to use the CSS framework, Blueprint, to build the sites out quickly. Together with Polypage, a rather nifty script from those clever chaps at New Bamboo, we were able to very quickly knock up html wireframes with some limited functionality. This process proved invaluable for both community feedback - in that they could actually interact with some code in their browser - and also for one on one interviews and usability testing conducted by Leisa.

Incidently, we’ve built a bunch of Blueprint plugins (kind of like the Yahoo! UI stencils) to support this process. We’re going to be building on those and releasing them shortly. We’re quite excited about it actually. They’ll be things like navigation, calendars, forms: all the little bits of standard UI gubbins all packaged up as simple CSS files.

You see, we would have used something like Yahoo!’s design pattern stuff for this, but it’s just too designed. We needed this prototype to not looked visually designed in any way so people could focus on the UX. Anyway, that will be forthcoming.

Weekly design and prototype iterations

The pace of this project is such that we have a weekly prototype release every Thursday in readiness for community feedback (via the various channels) over the weekend. And, the theory still stands: we look for trends in the feedback. Interestingly, trends have been more difficult to spot the further we get down the road and the more ‘real’ the site becomes.

<

p> Drupal.org Iteration 7 homepage

Drupal.org prototype iteration 7 homepage. This version represents a big step forward visually, brand-wise, and revised Information Architecture.

The latest iteration, version 7, is a bit of a departure from the previous ones. In Leisa’s words:

There were a couple of things that were really bugging us in the versions up to now.  In particular, the navigation in the header (there was so much of it and it looked kind of messy and confusing and in tests, we observed that people completely ignored it!). The Logged In version of the homepage was a good idea but the execution was coming up short as we learned that ‘hard core’ Drupallers thought it was a valuable addition to the site but just about everyone else wasn’t interested…

She goes on to say…

A behaviour which we have observed since the very early days on this project has the use of search - lots of people use search lots of the time, and a lot of the tasks that the site has to support are heavily search oriented (finding modules, finding help etc.). Drupal.org users have some of the most advanced Google skills I’ve ever observed! - and yet up until now, the redesign of the site didn’t really pay this much heed - it was still very much a hierarchical site made up of silos of content… forcing people to choose between this section or that to find the content they required.

This shift in direction has, so far, tested well and the overall comment we’re hearing is good. But, we there’s still a way to go.

Please let me know your thoughts as you delve in and have a look around.

Onwards and upwards

We’ve still got a month or so left on this first phase of the project and there’s a lot to do in a short space of time. One thing that is driving the clarity, in fact without, this project would be considerably more challenging, is the community feedback. Through the flaming, disagreements, and arguments are clear, actionable points, which we take forward to the next round.

At first, I thought design by community would be as bad as design by committee. Lots of people, all wanted their say, mixing black with white and ending with grey. Not so. This project, and I believe it’s breaking new ground in this approach, is proving it’s working and that’s not down to the team at Mark Boulton Design, me, or Leisa. It’s down to the community.

Design By Community

One of the interesting challenges of the redesign process for Drupal.org is managing the expectations of a community of over 200,000 registered users. Not only that, but a community of largely open source developers. I mention that specifically because of the culture that surrounds open source development. Leisa and I have been trying something that is, frankly, terrifying. We’re designing in the open.

When I graduated from university, I was asked to go before a panel of moderators and examiners three times to justify my work. For best part of an hour I argued, listened, seethed and nearly cried as my work was verbally torn apart by a committee of ‘learned’ professionals. On my way out of the room, utterly devastated by what just happened, my lecturer in typography took me to one side and said some words I’ll never forget: ‘Mark, a camel is a horse designed by committee.’ ‘Take what you can, and learn. But ultimately, stick to your guns and believe in yourself.’

He was of course implying that design by committee never works and nearly always results in a poor product. The egotistical designer in me agrees. However, the more pragmatic side of me disagrees. Maybe design by committee doesn’t work, but design by community could.

Asking the community for help

Leisa has been doing a fantastic job recently of opening up her process, thoughts and ideas with regards to the Drupal.org redesign. So far, we’ve had the following gems:

<

p>

By and large the community has responded well, offering valuable insight into some thorny issues. I thought this was something I could do with some of the branding work we’ve been doing.

<

p>

Now, it may be the subject matter, or my phrasing. Perhaps it was too early in a process. But as you can probably see by the comments, it didn’t go so well. Actually, saying that, I think it did go well up to the point where the comments took a personal turn for the worse. I was talking with Leisa this morning, and we both agreed that it would be interesting to analyse the differences, and the huge difference in the tone of the comments provided.

Brave, Stupid, or Inspired?

This comes back to one of the initial points I made. Design by committee does not work. Why is that? Personally, I think it’s due to the relatively small size of a ‘committee’. Say you have a client, and there are 15 stakeholders. All of them have strong opinions, there are big egos flying around. In fact, I had a client like this a short while ago, and it was a prime example of how working in this environment does not work.

Generally, in that group, there will be one or two loud voices. Maybe an Alpha Male or two. The important thing to note is that this is a small group. It will be difficult to reach common ground with a small amount of people.

Designing by community I feel is different. There are a lot of people in the Drupal community. Many hundreds with a strong voice. Providing very early releases--in fact, opening up the process completely--draws reaction. Within that reaction, if there is enough of it, we can identify trends. And I think trends in feedback is the key to Designing By Community.

Where next?

Leisa and I will continue to work as openly as we feel appropriate for the project. If it falls flat on its arse in the near future, well it will make a bloody good case study. 

Drupal.org

DrupalA day or so ago, the small design studio I run, Mark Boulton Design, was announced as the redesign partner for the redesign of drupal.org. Together with the outstandingly talented Leisa Reichelt and Carolyn Wood, the team at Mark Boulton Design are thrilled to part of this project. More details on the studio site.

Leisa and I will be out in Szeged, Hungary, for the biannual Drupalcon during the week of the 25th August, where we will be giving a keynote presentation on Thursday 28th. If you’re there, tap me on the shoulder and say hi.

Design isn’t about tools

The other day, 37Signals wrote about Why they skip Photoshop. Fine. I think that suits them and their workflow, considering they don’t do client work and have an established UI style on which to draw. Jeff does a much better job of summarising my thoughts on the subject that I could. As does Jon

So, yesterday, we see this post on SVN, presumably as a follow up. Is it an inflammatory post? Or, do they have a point?

Horses for courses

As Jeff pointed out, and many of the commenters on the first post, choosing to use Photoshop is really a workflow thing. If you find it doesn’t suit your workflow, and you have an established UI then feel free to ditch it. When I worked at the BBC, I did that for a while as well. It works very well for a lot of the modular, micro-design tasks needed within a design that is already agreed. However, when a new design was required, I often needed Photoshop to give me the holistic design view. As Jon points out in his post, it’s much quicker to do that in an image editor, than using HTML/CSS.

Now matter how hard I tried, HTML and CSS could not give me that overview that Photoshop could. The subtle interplay of typography, colour, texture and whitespace is difficult to evaluate with HTML when you throw browser quirks in the mix.

Do print designers need to know how to build a press?

I think David’s post on SVN holds true to some degree. Yes, if you’re designing for the web you need to know the tools of your craft. But that’s the thing, Design is not about tools. Photoshop is a tool, as are HTML and CSS. Design is about solving problems, not about software. Some people choose to do that with Photoshop, and some with HTML and CSS. Neither route is the correct way of doing it and it’s a mistake to presume it is.

You can also argue that knowing how to build things in HTML/CSS limits your creativity. You work within your own boundries. If you’ve always had a sticking point with flexible layouts, then chances are, if you have to build the thing, you’re preference would be to avoid them. This is one of the disadvantages of knowing your way around HTML/CSS as a designer - it’s hard to break free of those constraints.

Tools, tools, tools

I’ve always liked to abstract my design process from the tools I use. Photoshop, Fireworks, HTML/CSS, Pen and paper, HTML Wireframes using Blueprint, Omnigraffle—It doesn’t really matter. You use what’s best for your workflow at the time. These are all tools in the same way that a pencil is a tool.

They are implements to realise a solution to a problem.

You say tomato and I say toe-may-toe.

Where’s the D in D&AD?

A D&AD Yellow PencilOn the 15th May, the winners of this year’s D&AD awards were announced. This year, there were only two nominations for graphic design, neither of which won an award. There were many more website nominations, and one was even awarded a yellow pencil. Although, typically, it’s a flash-based, motion-based ‘microsite’ masquerading as a website. Now, that aside, why did the graphic design category not produce any winners this year?

That very question has got me thinking about industry awards in general and why graphic design, and its application to websites, no longer has a place in the D&AD.

When I was in university, the annual D&AD reference book was eagerly awaited by the entire year. True, it was more sought after by the students keen on Advertising and product design, but, for me, there was particular interest in the typographic and graphic design awards. The D&AD winners represented the pinnacle of our craft. If it was in The Annual, then, frankly, you’ve made it.

Of course, this was in a time when there was no web to speak of. Design companies could not self-publish their works. No, they had to pay an entry fee to the D&AD for work they deemed ‘good enough’. The D&AD then published those works. Aside from having the yellow (or even the black) pencil award, your work was distributed and packaged as the very best in the craft. That alone was worth the application fee. But now, I think things are different.

Live and die by awards

Awards are incredibly important for advertisers. They are the industry benchmark. Way back when, I was an intern at an ad agency. I was also an Art Director at a large web shop with a heavy advertising bias. Throughout my time there, it was obvious that many creatives saw winning an award (like the D&AD) was more important than solving the client’s problem. There was an unhealthy emphasis on industry navel-gazing. I’ve been in production meetings where the number one topic on the agenda was which awards was the agency chasing this year.

Just right

Thankfully, that mentality has largely escaped our industry. Yes, there are awards such as The Webbys, SXSW Web Awards, to name a couple. But, they certainly don’t have the industry weight as the D&AD awards.

I think it comes down to validation. Maybe, industry-wide, this year, graphic designers don’t feel the need to validate their work beyond it fulfilling the brief. Let’s not forget that design is a commercial practice. We do stuff, for clients, for money. And that’s where I think the web design industry has got it just right. Largely, we’re focussed on solving problems for our clients. Our business models are based on that, not on winning awards. And we certainly don’t need the D&AD, or anybody else, to tell us we’re doing a great job thank you very much.

Coolspotters. Where people and products meet

Coolspotters: Where people and products meetLast year, Mike D introduced me to a friend of his who had just started work on an exciting new project. Coolspotters, the first major project from Fanzter was built on the back of a simple concept: combine products and people and let the users create the connections.

Social Shopping

Of course, the idea of social shopping isn’t a new one. Just look at Amazon for example. The majority of my purchasing decisions on Amazon are based upon the reviews and recommendations of those products. But, Coolspotters does something new. It places the products in context to their useage with celebrities. For many aspirational brands, it’s this that defines them. Not the product itself, but who it’s being bought by, and who’s using it.

<

p> Coolspotters final UI

The Coolspotters launch UI. The revision includes a lot of work subsequently done by Fanzter based on our initial design concepts.

More than just another social app

The interesting potential for Coolspotters is that it becomes a repository for those transitory trends of fashion. So, in time, you could look back and see who were the early celebrity adopters of the iPhone, or which car was in vogue for last Autumn. All of this data could be mapped and charted to possibly show some interesting trends in how brands infiltrate and work through this highly-public, and influential, sector of society. That is something I’d love to see exploited.

My involvement

The challenge given to Mark Boulton Design was to craft the user experience and concept (together with branding) which could then be honed further by the talented Fanzter development team. We’ll have more about this shortly in a short case study on the studio site.

Coolspotters launches later today. You can read a little more about it on Techcrunch.

abcdefghijklmnopqrstuvwxyz

A few days ago, Keeran sent me a link to this video by Job & Roel Wouters. It’s such a beautifully simple piece. Watching Job draw the letterforms is mesmeric enough, but when his son (?) joins in, I found myself laughing as he tries to imitate his fathers work. This leads to some funny-looking characters (c and d are particular favourites of mine).

I’m particularly jealous of the assured free-hand script of Job. It really is a joy to watch.

‘abcdefghijklmnopqrstuvwxyz’

a video by Job & Roel Wouters
recorded in Amsterdam at studio Xelor early 2008

Hand 1: Gradus W. Wouters, Amsterdam, the Netherlands, 2003
Hand 2: Job Wouters, Leiden, the Netherlands, 1980

Director: Roel Wouters

Director of photography: Sal Kroonenberg
Music: Rik Elstgeest & Bo Koek
Production asst: Ton de Munck

<

p> notes from the director:

‘Job and Gradus are both ambitious concerning letters. Spontaneous jam sessions in our studio inspired us to make this film about the fun drawing letters’

From Poly to Pole

Every six months or so, my brother-in-law, Bruce Gordon, updates his website (which I designed a while ago) with his latest work. I’m generally not one to pimp sites, especially family, but Bruce’s work continues to amaze me. He’s a Head Sculptor for the film industry in the UK and his website is glimpse into the world we rarely see--set design and construction.

Fred Claus

His latest project (other than Wolf Man that he’s currently working on), is Fred Claus. He was the HOD (Head of Design) Sculptor for the project, which I think means he ran the crew whose responsibility was realising the art department maquettes. Now that just blows me away. Scaling up a clay model, that may only be a few inches across, into a life-size construction. Of course, the art department is concerned with the vision of the production, not if the thing can actually be built. That’s up to Bruce and his team to figure out.

Santa's house in Poly
Poly Building showing construction
The finished North Pole set

These images from Fred Claus show the scale of construction and attention to detail. From intricate wood sculpting, to ensuring layered snow on roof tops looks like it actually might drop off any minute. All of this work, and it’s an incredible amount, can only be on-screen for a few minutes. I guess that’s the price for trying to accurately portray another reality.

If you have a mo, browse around his site. There’s some stunning work on there from production such as Charlie and Chocolate Factory, Batman Begins, and Harry Potter and the Philosopher’s Stone

Ten Crimes Against Web Typography (and how to avoid them)

Cardiff is finally getting its act together. Tonight, I’ll be speaking at the second Cardiff Geek Night, along with Dan Zambonini. It’s a ‘microslot’ that will last about 15 minutes, leaving plenty of time for questions.

When I spoke in November last year at the Web 2.0 Expo in Berlin, the feedback I got from my Typography presentation was generally positive. It seemed that most of the people I spoke to preferred the last 10 minutes, on Micro-Typography, and all the quick tips that you could use every day. Tonight will be more of the same, with a slightly different slant. I’m going to highlighting my top ten crimes against web typography, and how you can put them right. Ten crimes (and subsequent tips on correcting them) in ten minutes. I’m told the talks will both be recorded, so I’ll post up a link to them (and slides), when they’re all done.

If you’re at a loose end tonight, and fancy a pint, then feel free to come along. We’ll be at Cafe Floyd from 7pm.

Start Your Own Business

This article was published in .Net magazine before Christmas last year. I was asked to write a small article on making the leap to working for yourself (as it was still fresh in my mind). It’s by no means a definitive guide (for example, there is no mention of the legal aspects of setting up and running a company). It’s also aimed at a UK market, but a lot of this will work no-matter what country you’re in. Most of it is actually just common sense.

It’s been eighteen months since I went freelance, and almost six months since starting my small design studio. I’m no expert. So, this article documents what I did, and when. It also features a little interview with our very own Colly.

[Article originally published in .Net magazine in November 2007]

So you want to work for yourself? And why not. You can dictate your own hours, have the freedom to take time off when you want it without getting into trouble from the boss; you can do what you want to do, when you want to do it. At least, that’s what I thought when I started working for myself a year ago. I couldn’t have been more wrong.

The freedom of being in control is terrifying. The pressure of knowing it really is down to you whether you succeed or fail can weight heavy.

Where I live, in Wales, almost 400 people a week start their own business. Everybody is different and end up giving it a go for a variety of reasons. However, most of these people share common ground. Things that they need to think about when planning to go it alone.

As I said, I’ve only been my own boss for a year now, so I wouldn’t call myself an expert on this. I can however tell you my story, and the mistakes I made along the way.

Why do it in the first place?

Starting a business is one of the most challenging, but rewarding, things you can do. The reason most people never end up doing it—although I’m sure many would love to—is because they think it takes luck, a clever idea or just knowing the right people. That’s not true. It’s about you.

Maybe you have a great idea that you just can’t keep a secret anymore. Maybe a colleague has approached you to setup business with them on the back of a contract they’ve just secured. Maybe you just hate your job and wish you were your own boss. The catalyst is different for everyone.

For many people, including myself, they’ve found their career take a certain path where self-employment is the next natural progression. I was working full-time at the BBC as a designer when my enquiries to do freelance work reached such a peak that I was doing two jobs. At that point, one of them had to go before my wife did!

Whatever the reason to set up business, it’s a personal one that only you can make.

Do you need a business plan?

A Business Plan is just that; a plan about your business. It’s used to look ahead, allocate resources, focus on key points, and prepare for problems and opportunities. It doesn’t need to be a scary document that you take months to write. However, some banks, investors, or other funding bodies will insist on a well-written, concise Business Plan on which to base their decisions, so in that sense, it’s a very important document.

A standard business plan will contain the following:

  1. Executive Summary:
  2. Write this last. It’s the summary of the document.
  3. Company Description:
  4. This details how and when the company was formed.
  5. Product or Service:
  6. Describe what you’re selling.
  7. Market Analysis:
  8. You need to know your market. Establish the need for your product and why people need it.
  9. Strategy and Implementation:
  10. Be specific. Investors love this stuff. They need to know you have a clear plan of attack.
  11. Management Team:
  12. Include backgrounds of key members of the team.
  13. Financial Plan:
  14. Include a profit and loss account, cash flow breakdown and a balance sheet.

Make no mistake, writing a business plan can be a daunting prospect, but it doesn’t have to be great the first time around. A business plan should be revised throughout the business’ lifetime - it’s not just for startup businesses. I’ve just gone through my third draft in my first year of business.

As usual, the web has some great resources to offer. The BBC has a good overview of ‘How to Write a Business Plan’ (http://news.bbc.co.uk/1/hi/business/2943252.stm).

Get help

This is perhaps the most important step in setting up your own business. You will realise you can’t do it on your own. You will need good advice from the following people:

  1. An accountant:
  2. Preferably a small business specialist.
  3. A bank manager:
  4. All new businesses should be allocated a small business specialist from their chosen bank.
  5. A financial advisor:
  6. You will need the advice of somebody who can assist in the financial direction of the company.
  7. The Government:
  8. Yes, the government can help.

Out of all of these, I’d advise you spend the most time trying to find a really, really good accountant. Many businesses owners will tell you that a good one is worth their weight in gold. In addition to the usual accounts stuff they can give you invaluable advice.

A great source of business advice for England and Wales is the Business Link website. (http://www.businesslink.gov.uk) Here, you can find information on starting up and funding options, to Health and Safety and employing people.

The different kinds of ‘company’

To register as self-employed in the UK, you have to register with the Inland Revenue as one of several company types:

Sole trader

Being a sole trader is the easiest way to run a business, and does not involve paying any registration fees. The downsides are you are personally liable for any debts that your business incures and, if you do well, you could be paying high income tax.

A Partnership

A partnership is like two or more Sole Traders working together. You share the profits, but also the debt.

A Limited liability partnership (LLP)

An LLP is similar to a Partnership. The only difference is the liability, or debt for example, is limited to investment in the company.

A Limited liability companies

Limited companies are separate legal entities. This means the company’s finances are separate from the personal finances of their owners.

Franchises

A franchise is like a license to an existing successful business.

Social enterprises

This one probably doesn’t apply to web development. According to Business Link, Social enterprises are ‘… businesses distinguished by their social aims. There are many different types of social enterprises, including community development trusts, housing associations, worker-owned co-operatives and leisure centres.’

This is something you must do in order to pay your taxes. Speak to your accountant about which will suit your needs better.

How to finance yourself

Before I made the leap into full-time self-employment, I read a lot of articles which said I’d need six months salary in the bank before I went out on my own. Although that is good advice, depending on your salary, that is quite a hefty chunk of cash that will be hard to save.

Like most people, I didn’t have that sort of money knocking about so I had to have a close look at cash flow over the first few months of business to ensure I could pay myself. This cash came from several sources.

  1. Money in the bank.
  2. I did have some money in the bank. Not a huge amount, but I had some.
  3. Contracts.
  4. I had a number of contracts signed and ready to go when I went on my own. These proved invaluable in kick-starting my cash flow.
  5. Funding.
  6. There are many funding options available. Grants, loans and private investment. All of them except grants require you to pay them back though, and for that you need a good business plan and an idea of how you’re going to pay them back. Grants (and small business loans) are available from local government bodies for example. I’d advise making an appointment with your local Business Link to discuss your options.
  7. The Bank.
  8. Get an overdraft facility. Mostly, even for limited companies, these will have to be personally guaranteed - which means if you default on paying it back then you’re personally liable - but they can provide a vital buffer for cash flow in those early days.
  9. Charge up-front.
  10. When you get a contract in, especially if it’s for fixed cost, then charge a percentage up-front. This will help with the cash flow. If you can’t charge up-front, then make sure you charge monthly. Again, it will keep the cash flow nice and happy.

Basic accounting

What is Cash Flow?

Cash Flow is the life blood of your new company. It’s the ebb and flow of cash coming in and going out. The aim is to have a positive cash flow, so there is more cash coming in than there is going out once you deduct all your overheads.

You will also need to forecast your cash flow. This is still one of the most sobering things I have to do regularly because is clear shows the current state of your business. Every month I review my cash flow and I forecast for three months, and for six. I make a list of all the invoices which need to be sent in those two time periods and make sure I’m hitting my monthly and quarterly cash flow targets. Like I say, it can be scary at times.

Tax

There are two types of tax: Income Tax and Corporation Tax. For Sole Traders, Partnerships and LLP’s, you will be charged income tax on your profits. That’s important, so I’ll say it again. You’ll only be taxed on your profits. Things like equipment costs, rent, phone and other office expenses are deducted from this.

Limited companies are charged Corporation Tax on their profits. The employees of that company are charged income tax on their income. As with a Sole Trader etc. Limited companies are only taxed on their profits.

VAT

If your business earns £64,000 or over in a financial year, you have to register for VAT. If you think you might hit that target during the year, you can voluntarily register before hand.

Being VAT registered means you have to charge your customers for VAT on top of your services. Currently in the UK, VAT is 17.5%. You’re in effect collecting taxes for your government. Nice aren’t you? One of the advantages of being VAT registered is that you can claim VAT back of purchases for your business. Say you bought a new computer, you could claim the VAT back from that purchase.

All this VAT gets added up and you have to pay the government every quarter.

For more information of your obligations as a business to pay your taxes, go to the Inland Revenue website. There are some great tools on here to help you - you can even file your taxe return online.

Establishing a customer base

Prior to starting my own business, I worked full time. As a designer, or developer, you will probably get enquiries to do freelance work in your spare time. This is the time to start building up your customer base whilst you still have the security of a full-time job. Sure, it means burning the candle at both ends, but it does ensure a smoother transition from employed to self-employed.

Schmoozing

A good way to drum up business is to network. This can be done traditionally, such as Business Club lunches and events organised by your local authority. One of the most effective ways of getting your face known is by attending the many web conferences, workshops and meetups going on throughout the country. From Pub Standards and the Oxford Geek Nightsto the larger conferences such as @Media and dConstruct. They all provide a great platform to meet people in the industry who may require your services.

Contribute and Interact with your market

If you’re a design studio who designs websites but has a strong focus on User Experience design, then write a company blog about that subject. If you write interesting content, and give it away free, then traffic to the site will increase as will your page rank in Google. This means that if a potential client searches for User Experience, they will get your site in their search results and there is a clear path into your site from some quality content.

Giving a little quality content away for nothing may make the difference in landing that big next project.

Making the switch from being employed to self-employed

The power of the Day Job

If you’re employed, but planning to go freelance, then keep your day job for a while. Get work in to work in your spare time, but use the cash that generates as a buffer for when you do go it alone. Make sure the two worlds don’t collide though. Keep your boss happy in work, but now is the time to be a bit of a jobsworth. Get in on time, leave on time, take an hour for lunch - do everything you can to maximise the time you have available to work on the freelance projects.

A smooth transition

Working two jobs is hard, and you won’t be able to keep it up for long. This stage in starting up your business is perhaps one of the most difficult. The aim is to ensure a smooth transition from being employed to self-employed. You will need some cash in the bank, a few contracts for your first couple of months of being on your own. The hard thing is keeping you current boss happy in the process. It’s not easy.

There are a number of great job boards which advertise design and development projects regularly. The two I’ve used successfully in the past to drum up some business are the 37Signals Job Board, and Cameron Moll’s Authentic Jobs.

How to achieve long term success

Keep one eye on the future

Forcasting business can be quite difficult. How does cash flow look in three months time? Are you saving enough money for the end of year tax bill? To succeed in business I think you need one eye on the present and one eye fixed firmly in the future. The short-term future. Whilst it’s great to have dreams and aspirations for your new business, that shouldn’t be at the expense of ensuring you have enough work coming in over the next six months.

Customer service

Remember if you’re a designer or developer, you’re providing a service. We’re in a service industry and with that comes Customer Service. I know it may sound a bit trite, but treat clients as you would like to be treated. Treat them with respect and never lose sight of that fact that they are paying the bills.

Wrapping up

Making a leap of faith is the first step to starting a business. However, for your business to grow and flourish, you will need much more than faith. First off, you must have upmost confidence in your ability to make it work. You need to be aware of the risks, but not scared to death by them. You’ll need to have good organisational skills, flexibility and a high degree of commitment. Most of all, you need to have fun and love what you do.

Interview: Simon Collison

[The following is an interview conducted in Nov 2007]

Q. Why did you end up working for yourself?

After four happy and successful years with another great agency, I did start to dream about being in control. I’d sometimes receive offers to work for other people, but nothing ever grabbed me. I’d get a few people emailing me every week with requests for websites, and I grew in confidence, realising that I could actually earn enough money to survive. Generally, I just wanted to nitpick clients and decide who to work with on projects.

Q. What do you love about working for yourself now?

The autonomy. I love making my own decisions and being in total control of the direction in which we are heading, the clients we choose to work with, and being able to handpick colleagues!

Q. What don’t you like about it?

Hmm, lots. The hours (I did over 100 hours last week). In general, it can take over your life if you want to produce quality work with no cutting of corners. Sacrifices are inevitable – everything from working the majority of evenings and weekends to missing your best friend’s birthday. If there is an immovable deadline and the work needs doing, the buck stops with you, and no excuses are good enough.

Perhaps the biggest shock to the system is the unavoidable responsibility for ensuring that cash flow is steady and that we have enough money coming in to pay the wages, cover office rent and general overheads.

Q. If there where three key pieces of advice you could give to someone who was thinking of going into business for themselves, what would they be?

Just three? OK. One. Achieve a work/life balance and stick to it as best you can. Ultimately though, except for crisis stuff, you’ll end up putting work first, so be prepared for that.

Two. Trust yourself. You will make mistakes, but generally the decision to work for yourself won’t be one of them. Have the courage of your own convictions and just go for it! You will know when you are ready and have enough work or contacts to ensure you break even and can pay yourself.

Three. Realise that you are not an expert at everything, so get people to help you. Get business advice, get to know your bank manager, and use an accountant. When you are seriously busy, the last thing you’ll want to be doing is invoicing, or doing anything at all in Excel.

Q. What’s the biggest mistake you’ve made since you started up?

Under-charging in the first few months. The temptation from day one is to bring the work in and build up a client list. This kind of thing will not wreck your business, as you’ll simply put the extra hours in, but it is seriously detrimental to your health and lifestyle, and even the quality of the work you produce.

Q. Where do you see your business in two years time?

Thriving – you gotta be confident, right? We’re lucky in that word of mouth and recommendations bring the work to us. We don’t take this for granted and never will, but the hard work in our first year is paying off, and we now have a solid foundation to build upon.

I never dreamed there’d be five of us within a year, and we hope to grow to about ten soldiers in the next 24 months. When you work this hard, you have to remember to be proud and enjoy what you do.

[Finally, rounding off with a couple of boxouts from the article]

TIMELINE: Six months to making the plunge

6 Months to go—Start building a customer base. Trawl the freelance websites (job boards - authentic jobs etc) and get yourself a few freelance gigs. Register your business with the Inland Revenue. (see section on deciding what business you should be). I’m afraid for the next six months, you’ll be working two jobs. If you can get funding for your venture, start researching what you can get and when.

5 Months to go—Continue to get those freelance gigs in. Begin to research a good local accountant. Book an appointment with several banks - you’ll need to get a business bank account - but it’s worth shopping around. Have meetings to discuss funding opportunities.

4 Months to go—Found a good accountant? Right, you need to have a meeting with him/her regarding your new venture. Finalise your bank account with your chosen bank. Continue to build up your customer base. Now is the time to speak with some local companies to see if they need freelance help. Are you going to be working from home? If not, you need to start looking for somewhere to work from.

3 Months to go—You should be getting some money in from your freelance gigs by now. Save it—you might need it in a few months.

2 Months to go—You should be working like a dog now and really looking forward to working for yourself. At this stage, everything should pretty much be in place for you to make that smooth transition from employed to self-employed.

1 Month to go—Hand in your resignation. If possible, try and get some work booked in for the first three months of being on your own. Make sure you also get paid by these clients monthly so cashflow isn’t an issue.

Ten things I wish I’d known

10. Wearing many hats

Before I set up business, I’d read a fair few ‘how to’ books and a number of blogs that talked about the many roles you would have to adopt whilst running your new business. I still struggle with it. On a typical day I am a designer, a project manager, a salesman and a book-keeper. Each role requires a different mindset and it can be very difficult to switch between them.

9. Home is for home things

Keep work and home separate. When you work at home, this can be difficult. When I had my workplace in my house, I made sure it was a completely different room which was furnished like an office—not just your spare room with a desk in it. One tip which worked for me: wear your shoes during the day, when you’re working, and at night, take them off. It’s a silly little thing, but you will soon associate shoes with work. So, when you take them off, that’s home time.

8. What goes around comes around

Be nice to people. Business doesn’t have to be unpleasant. Treat people how you expect to be treated. Be fair, professional and above all, polite.

7. Don’t take on too much

This one is a killer. I still do it and probably will for many years to come. When you don’t have any work booked in in three months time, the tendency is to get more work in now with the hope that, financial, you’ll be more stable in the months you don’t have work. It makes sense, but you end up working too hard. As a result, quality dips, customers get a bad service and, over time, your business will dry up.

6. Hire somebody before you need to

I’ve recently had this problem. I’ve been so busy recently that I needed help. After hiring someone, I realised I’d been in this position for too long. I needed help about three months before I thought I did.

5. Don’t under-charge

Work out your costs on an hourly, or daily, basis and then add 30%. It covers costs and, until you get the hang of it, you’re probably under-charging anyway. I was.

4. Confidence

Remember, you’re the expert. You’re not doing this job because you’re average at it. If a customer wants to buy your product, or hire you, it’s because you’re good at what you do.

3. Customer Service

If you’re a web designer or developer, unless you’re producing and selling a product, you will be providing a service. With a service comes Customer Service and, yes, customers are always right.

2. Accounting Software

I was using a homemade system coupled with an Excel spreadsheet for my accounting needs. As the business grew, I needed something a little robust. I wish I’d learnt Sage or something sooner because now I don’t really have the time.

1. Plan for tomorrow

I have three to-do lists. A Month list, a Three Month and a Six Month. Each list has a bunch of things I need to do for that time period. This allows me to have short, mid and long term goals. I class Six Month as long term here as, in this industry, I believe you need to be adaptable and can’t really plan for more than six months in advance.

Just the way I like it

As I said, this is just the way I set things up, and some of the many thoughts and conclusions that I came to over the past couple of years of running my own business. Hope it may help some of you thinking of taking the plunge.

Coolspotters and Garcia Media

It’s been a good while since I’ve talked about any work Mark Boulton Design has been up to. That’s mostly because the projects we’ve been working on have been under wraps. Until now that is. One project is now live, the other coming very, very soon.

Coolspotters: If it’s cool, they’ve seen it

Fanzter, Inc hired Mark Boulton Design last year to design their new web application, Coolspotters. Coolspotters is a consumer-focussed site that offers an experience that could shift the way people discover great products.

Coolspotters Logo: Designed by Mark Boulton Design Ltd.

The design challenge was considerable—from the branding to designing the UX. We worked closely with Fanzter, drawing on our experience with working client-side, to hone the product over many iterations. I don’t mind saying, the result of this close collaboration is fantastic. But, you may have to wait a few weeks before getting to grips with the site as Fanzter are opening it up for beta applications now, before launching proper shortly.

Garcia Media

Garcia Media is one of the world’s leading news design studios. Designing publications such as The Wall Street Journal, The Miami Herald, Die Zeit and small community papers, they have unparalleled experience and an industry reputation to boot.

Redesigned Garcia Media website

I had the pleasure of working with Dan and Alex Rubin on the design, as well as the in-house team at Garcia Media. Mario Garcia, Jr. has penned a blog post on the site that explains the background, design and implementation much better than I ever could.

Coming up…

We’re thrilled to be working on some incredibly exciting projects at the moment—from FTSE 100 corporate redesigns and web applications for TV networks. Through to small, simple websites for companies with a great idea. In addition to the web work, there are a few exciting things happening behind the scenes at Mark Boulton Design that hopefully I’ll be able to talk about really soon.

Share and Share alike

So, I’ve talked about my work. How about you talk about yours? What have you been up to? I’d love to hear. Feel free to link it up (although not too many as EE will spit your comment back at you!)

BBC redesign tellys have rounded corners, right?

The BBC have redesigned their homepage.

BBC Logo Beta thumbnailI used to work for the BBC. So, I have a good understanding how difficult it is to work there and get anything complete and out of the door to a high, exacting design standard. So, today, when I was told the BBC has opened up the new homepage beta for feedback, and also prompted by Jeremy’s post on the subject, I wanted shove my oar in.

Web 2.0 design nonsense

This is a shame. The BBC, in design terms, used to be a leader in the field. In one fell-swoop, they’ve turned follower. The trends, from a few years ago, are all over this thing. From the ‘Beta’ label and the rounded corners, to the gradients. Why? I honestly can’t think of a sensible response as to why they’ve gone down this route. Hasn’t Facebook proved you don’t need to have reflections or curved corners to be ‘Web 2.0’?

Now, I’m well aware I’m judging this on face value. I’ve not been privy to any discussions that may or may not have taken place.

However, Richard Titus—The acting head of User Experience at the BBC—has kindly written a blog post describing some of the specifications and requirements.

High on this agenda was ‘widgetization’ (oh, I hate that word) of the content. Dynamically generated and syndicated content has been high on the content priorities for the BBC for many years. What puzzles me is why jump on a visualisation bandwagon? Recent newspaper designs, such as The Times, or The Guardian, deal with top-level content in a similar way. To all intents and purposes, the modules on their homepages are ‘widgets’. Perhaps it is that word that makes designers want to recreate netvibes.

Innovation over information?

I’m sure there are plenty of clever things going on under the hood on this homepage. From Ajax, and a move towards PHP, through to localised content and user customisation. My gut feeling on this, and this is a personal view of course, is that all this visual guff gets in the way of the information. The design aesthetic is not ‘simple, and beautiful’. It’s obtrusive and dated.

My lecturer in university instilled a mantra into me: ‘don’t let the type get in the way of the words’. It can be applied to any design. Don’t let the design get in the way of the information, or the problem you are trying to solve. Sure, enrich the user experience by delivering the information in a fulfilling environment, but make the clever stuff invisible.

An example of this is when you click on the four coloured tabs running underneath the main promo. Now, how does that make you feel? Confused? Surprised? Sick?

New colourways on click. Pointless. They also gave me quite a shock.

Why did they do this? Really, what is the value here? To showcase the power of CSS? I’m totally baffled.

The last of the weather icons

The weather icons also breath their last with this redesign. I’m sad about that. Not because they look worse, but they are an inferior solution.

New and old weather icons

On TV, the richer weather graphics are far more useful in actually illustrating weather forecasts, but on the web, when there is no animation, we’re left with icons that mean nothing without the words to describe them. Of course there is an accessibility reason for having the text. However, the text shouldn’t be there to prop up bad icons. I mean, is that one in the middle cloud, or fog?

Anything good to say?

There are some nice things about it though. The buttons work well. I think the on/off state is very tactile. And, like Jeremy, I love the analogue clock in the top right.

Dinosaurs designing websites

What strikes me most plainly about this design is how the effect of a big, lumbering organisation can impact on a redesign. A good few months ago, or maybe years, when this proposal was first taking shape, it was probably the time when curved gradients, reflections and like were at the forefront of the ‘web 2.0 aesthetic’. Thing is, it takes any large organisation ages to get their shit together. Which is why designing to visual trends such as this is so risky. If your organisation can’t react quickly enough to keep up, then go the classic design route every time. If you don’t, your design will look dated within months. Or, in this case, even before it’s launched.

I’m led to believe this project took three months to complete. And I go back to my initial comment, it’s a huge result that the team responsible for this managed to get this project to this state in that time. In fact, it’s pretty miraculous. We’ll see how things pan out over the next few months. But, like some other websites that the BBC produces, they seem hell-bent on trying to make the web like telly.

But tellys have rounded corners, right?

Typesetting Tables at 24ways

I was thrilled to be asked by Drew a few weeks ago to pen something for this years 24ways. I’ve mentioned typesetting tables in a couple of presentations recently, notably, @media and the Web 2.0 Expo in Berlin. However, due to time constraints and the breadth of material I intended to cover, it hasn’t been possible to cover typesetting tables in the depth I wanted to. Until now.

As I say in the article, typesetting tables is often overlooked for a number of reasons, although it’s mostly because it can be tedious, time-consuming and, therefore, dull. But the devil really is in the details, especially for information and data in tables. Tables are not read like sentences. They’re scanned horizontally and vertically and have to be designed to help the reader do this. It’s not a time for eye candy. I tried to explain some simple rules that I apply when designing tables. I’m not saying this is the only way to do it, it’s just my way.

Anyway, hope you enjoy the article.

Type in Berlin

Since Sunday evening, I’ve been in Berlin attending—and speaking at—the Web 2.0 Expo. I presented earlier today on the very ‘un-web 2.0’ topic of Typography. I think it may have surprised a few people as to how relevant typography is to designing UI—even to applications. As usual, I talked about type as being more than just choosing typefaces, which is where most designers, unfortunately, see typography begin and end.

On closing, I gave a URL which would link to a section of this site with the slides, notes etc. You can download the slides here.

Apologies for the delay, but the up-speed of the conference wifi was incredibly poor, so I’ve only just got around to doing it.

I’ve also decided to embed the slides here from Slideshare. I don’t normally do this, so apologies if Slideshare clogs things up, but I thought it might be nice to have the slides here whilst I break-down the topics I presented.

The slides

What was said

I’ll give you a quick run-down of some of the main points of the talk.

I started off with a quick introduction of placing typography within Web 2.0. Where does typographic design as a practice fit with designing applications and platforms for the ‘web of data’. The rest of the talk was then split into four main section: Structure, Process, Macro typography and Micro typography.

I presented the following points:

Structure

<

p>

  • Typography is presenting information.
  • Information is language and language has structure.
  • Documents have a conceptual model and these need to be matched to the reader’s conceptual model of the content.
  • It’s the designer’s job to bridge this gap and present the content which fits both models. Incidentally, I feel this is one of the problems facing designers who want to art direct on the web.
  • Content and presentation.

Process

<

p>

  • Jesse James Garrett’s ‘Elements of User Experience’.
  • Wrongly interpreted as a linear process.
  • A process like this relegates design, and specifically typography, to the surface plane.
  • Greybox Wireframes.
  • Involving typographic design much earlier in the process.

Macro typography

<

p>

  • The Big Stuff.
  • Creating spacial relationships.
  • The Golden Section.
  • The Golden Section as applied to the web.
  • The Rule of Thirds.
  • Grids and consistency of design across page types.

Micro typography

<

p>

  • Hyphens are not dashes.
  • Letterspacing: negatively and positively.
  • Italic ampersands in headings.
  • Framing navigation items and lists.
  • Framing tables rows and columns

Those were the main points. It seemed to go down well, although, I still had the feeling the presentation stuck out like a sore thumb in a conference discussing some of the loftier aspects of designing for the web.

The rest of the time was spent in the pleasant company of friends old and new. Jeremy and Jessica, Simon and Nat were wonderful in arranging a variety of evening Berlin eating establishments. In truth, I met them in the lobby and we wandered around until we found a restaurant that could accommodate 13 people.

I ate some strange German food, and drunk some even stranger red beer. I said strange, not bad. I enjoyed sitting next to Jesse for two meals and discussing everything from washing machines and remote controls, to the waiter with the incredible memory (yes, he took a complete order—starters and main courses— without writing a single thing down! Impressive or what? I need to write a list if I need more than two things at the supermarket).

So, all in all, it’s been fun. But, it’s been tough trying to manage a conference, preparing a talk and running a small business that is ticking over at home. That has been challenging. I missed The Wife and am dying to see progress on my house extension.

I will say this for Berlin though, it’s a great place to come as a designer. I even found a design manual in a bookshop today on how to design forms, timetables and transportation tickets. How cool is that?

CSS Eleven

CSS Eleven
Last week, Andy Clarke announced a new CSS group I’m thrilled to be part of: CSS Eleven.

I’m going to leave the detailed explanation to Andy, but in a nutshell, the group is going to help the ‘W3C’s CSS Working Group to better deliver the tools needed for tomorrow’s web’. I’m particularly interested in having the opportunity to be involved in the several layout modules which have thus far been proposed.

Andy’s rounded up a fantastic bunch of designers and developers here. Hopefully we’ll have the collective clout to influence things in a positive way in the months to come.

Be A Beautiful Designer

Michael Bierut has written perhaps one of the most insightful pieces I’ve read all year over at Design Observer. He manages to encapsulate all of my insecurities as a designer, points a finger at designer industry at large and provides us with a big, fat ‘Get Out Of Jail Free’ card, all in one concise post. 

What got you started?

If you’re a designer, what got you started on this path? I’ll wager, for most of you, it wasn’t anything to do with business, academia, or writing. For most of you it will be because you wanted to create beautiful things for a living. I did. I started out wanting to be an artist, then an illustrator and then found myself interested in type, before working on the web. As time has passed, I’ve been doing less of the very thing I wanted to do. The important thing to consider here though - this has been a choice.

Take Me Seriously

So what has been taking up my time if I’ve not been busy creating stuff? Well, the list is endless from trying to run a startup design studio through to writing specifications etc. All of that stuff is, at the moment, necessary for me to do my job. But, I’d rather just be creating something beautiful you know? Design, especially on the web, is so wrapped up in process (and most of the time, rightfully so) that the very thing we love doing, gets left to the end and is only a minority part of the process. The craft of designing something beautiful.

Personally, the bit of the job that I get a kick out of gets left to the end. I like solving problems, I like producing a solid, well-crafted solution to a client. But the bit I really get a kick out of is when I’m ‘in the zone’ creating something beautiful. That is why I’m a designer.

But that’s not good enough. As designers we’re supposed to be problem solvers - not artists, right? This horrible duality fuels insecurities and Michael has summed this up way better than I ever could:

No, what designers wanted then and want now, more than anything else, is respect. Respect from clients. Respect from the general public. Respect from — let’s go right to the cliché — our moms. We want to be seen as more than mere stylists, we want to set the agenda, to be involved earlier in the strategic process, to be granted a place at the table. In short, just like the Chaste Clarissa, we want to be taken seriously.

Does that ring a bell? It did for me.

Problem Definition Escalation

This is just brilliant. Michael explains the term thusly:

The client asks you to design a business card. You respond that the problem is really the client’s logo. The client asks you to design a logo. You say the problem is the entire identity system. The client asks you to design the identity. You say that the problem is the client’s business plan. And so forth.

As you can see, design is not just about making things pretty, it’s about business plans. Right?

This really made me chuckle. I’m sure a lot of designers have been guilty of this - I know I have. The funny thing is, as Michael points out, it’s a direct result of our insecurities as designers. We want people to think we’re clever problem solvers who can help in every step of their business. Really? I don’t know about you, but I got into design to make beautiful things and I intend to stay that way.

I’ll leave you with a closing quote from Mr. Bierut:

Designers, you don’t have to be dumb. Just don’t be so afraid of being beautiful.

‘Nuff said.

The Death of Print. Again?

Yesterday saw the launch of Khoi’s and Liz’s fantastic joint venture in providing a platform for short, concise design writing: A Brief Message.

The opening piece is by none other than Stevan Heller. It’s a thought-provoking piece, concisely written in under 200 words, and asks the question ‘Is print dying’? Again. It’s a question that has been asked many, many more times than ‘Which is best—fixed or fluid?’

As Greg points out on his blog, this statement of impending doom has been around for ages now. Whilst we are seeing a shifting in consumption of certain media, such as news, away from the printed version and onto our screens, I think it’s a stretch to proclaim that print is breathing a dying breath. Take magazines in the UK for example. In some sectors of the industry, there has been a massive increase in production to fuel things like the blossoming celebrity culture.

Fit For Purpose

Okay, so maybe you prefer to read your news online. That’s fine and Steven’s point is a valid one. The consumption of news is changing and this presents a challenge to the industry as there is a shift from the delivery of that news from one medium to another. However, not all print is news. Personally, I love to sit down with a good book or to read through some quality articles in a magazine. I just don’t do that on the web—the method of engagement is completely different.

Print isn’t dying anytime soon. It will change, and our consumption of certain media will change as a result, but I seriously can’t see a whole lot changing in the next twenty years or so. We’ll see.

An Approachable Platform for Debate

I love the idea of A Brief Message. Love it. As Khoi writes on his blog, there’s a place for in-depth design writing—such as Design Observer and AIGA—but quite often, the longer and more in-depth these pieces get, the more academic and less approachable they become. It’s about time there was a platform for short, approachable design commentary. Hats off guys, you’ve done a great job.

Links That Deserve More Than The Sidebar

Over the past couple of weeks there have been a few things going around that deserve more of a mention than my lowly ‘Of Interest’ sidebar. So, here they are:

Mobile Web Design

First off, Cameron has beaten me to it and has announced the release of his book, Mobile Web Design, which is due for release on August 28.

This Way to the Web!

As usual, Khoi has been churning out the great posts. This Way to the Web, Print Designers! is a post on a topic dear to my heart. As an aside, this post is a perfect example of how a conversation in the comments can enrich the original post. Here, none other than Jonathan Hoefler made some excellent remarks about the perceived generalisation of print designers.

The Rise of the Graphic Designer

I was pointed to this post about Interaction Design by Greg. It made me cross. The post by Chris highlights some of the differences between visual design (whatever that is!), and interaction design. To be honest, I’m really getting pissed off with the notion of a ‘Visual’ designer being any different to an ‘Interaction’ designer, being any different to a ‘User Experience’ designer. A splintering of an industry into specialisms is fine (see Jonathan’s comments on Khoi’s previously mentioned post), but what’s wrong with being called a ‘Graphic’ designer?

I think it was Chris and I discussed this at SXSW this year. Why is ‘Graphic Designer’ such a dirty job title? And ‘Art Director’ is pretty much missing from the web industry—okay, correction, Art Direction is pretty much missing. It bothers me, it really does. When somebody asks me what I do for a living, I’m proud to say I’m a Graphic Designer. To me, Graphic Designer encompasses all aspects of the process of design in a 2d environment. Simple as that. From the planning and mechanics of production, to the art direction, visuals and copywriting.

As far as I can see, one of the only differences is that of the designer’s mindset; on the web, you lose the control you have in other media. Incidently, Khoi has a panel proposal in for SXSW this year for that very topic. Which neatly brings me on to the next bit of news.

Pick a Panel

SXSW is already picking up pace and it’s months away. The Panel Picker launched this week. I’m down for speaking twice. If picked. Rich and I might be doing a follow up to last years Web Typography Sucks called Web Typography Still Sucks (you see what we did there?). I also might be presenting with the super-talented Veerle (she who needs no surname) on the terribly tricky, subjective topic of Colour, called Using Color: From Black to White and Everything in Between.

I do hope the panel selection process was better than last year. There are six-hundred-and-eighty-three proposals this year, and once again, they’re being picked by the masses. According to Hugh Forrest, who posted on Airbag, the organisers will be more heavily involved in vetting this years entries. Glad to hear it.

Web Trend Map

I received my Web Trend Map in the post yesterday from those talented chaps at iA. If you look close, I’m in the bottom left corner. Which is nice.

Got myself an Employee

I’ve finally gone and hired someone to work alongside me at the Studio which is well overdue. Benn starts at the end of September and I can’t wait!

Mark Boulton Design launches

If anyone has done any work for themselves—painted a painting; made a model; built a shed— you will know how difficult it is to finally stop. It’s about the love you see. The craft. Anything done for yourself has to be just right.

In April of this year, I became the Director of my new design consultancy, Mark Boulton Design Ltd. Since then, I’ve been beavering away to get a website up to let the world know what it is we do and who we’ve done it for (so far). Today Mark Boulton Design launches.

It started with a story

The Mark Boulton Design website had to tell the right story. What are we? What do we do? For who? This is all pretty basic marketing and, as designers, we go through these sorts of questions regularly. From those answers, we have to derive a brand. That was a very difficult nut to crack for this website.

If you’re aware of my work—both my writing and my design work—then you’ll know I’m all about the simple things. Simple really doesn’t come easy though; like good tea, it has to be stewed for a while. The design for this site was stewing away for about six months. Most of that was getting the brand right—the tone of voice, the typography, the colour. All of it took bloody ages.

Not just a website

The branding for this project has been applied to a number of things. First off, there is the site. Secondly, there’s the One Page Brochure (available on all pages in the four column footer); a one-page printable PDF document to leave on peoples desks. Then, there’s the RFP project sheet. On top of all of that, I’ve designed new business stationery (and had a ball looking at literally hundreds of paper samples). Quite a lot really.

It’s never finished

When I was in secondary school (about 14 years old), my art teacher would always tell me that I still had work to do on a drawing or painting. It drove me nuts. Every time I thought I’d finish, he’d tell me to go away and work on it for another week. Designing for the web is no different. In fact, this is one of the great things that differenciates the web from other media such as TV or print; it’s a canvas to be worked on again and again.

There’s a load of work still to do on the typography. I want to get the vertical rhythm nailed. I want to get some print style sheets done. I decided today that all of that will have to wait.

Anyway. It’s done. Although my art teacher would probably have asked me to keep going. (note. this is my little ‘it’s not finished quite yet’ disclaimer)

Incremental leading

There has been a lot said recently about Vertical Rhythm. Richard Rutter began the work on 24ways last year with the piece ‘Compose to a Vertical Rhythm’. This was built upon by Wilson Minor on A List Apart recently with his article on Baseline Grids. All sound typographic advice. If you haven’t read both of them, I’d urge you to do so now otherwise you know what I’m on about it in this post.

At @media this year, I presented ‘Five Simple Steps to Better Typography’. Step two in my presentation was was Vertical Rhythm where I reiterated some of the excellent points Richard made in his article and also the presentation we both gave in at SXSW in March. I also added something of my own: Incremental leading, or Incremental line-height.

Too much leading in the sidenote

Working through both Richard’s and Wilson’s articles, they both treat the sidenote in the same way. They align it directly to the vertical rhythm unit. This is correct of course. But, to my eye, the line-height in those sidenotes, as it’s a smaller type-size, is too large. 10px on 18px leading is stretching it. So, how do we reduce that line-height whilst still adhering to the vertical rhythm we’ve established. Once again, we look to print design for that answer.

In editorial design, there is a technique used for sidenotes and boxouts that aligns to the baseline grid, or vertical rhythm. It’s called incremental leading.

Incremental leading

Here we have a simple page of text based upon Richard’s example. There is an H1, some text, a sidenote and a footer. They all align to an 18px vertical rhythm shown in red.

<

p> A simple document set to an 18px vertical rhythm

A simple document set to an 18px vertical rhythm

To my eyes, there is too much line-height to the sidenote. So, how can we reduce this line-height, but adhere to the 18px rhythm?

Instead of aligning every line in the sidenote with the vertical rhythm, when you use incremental leading, you align, say, one in every four or one in every five.

Here’s an example with incremental leading set to align every fifth line of the sidenote to every fourth line in the main content.

<

p> Sidenote set to vertical rhythm using an incremental ratio of 5:4

Sidenote set to vertical rhythm using an incremental ratio of 5:4

Adding in the vertical rhythm grid once more we can see the line alignment.

<

p> Here you can see the ratio of 5:4 incremental leading

Here you can see the ratio of 5:4 incremental leading

But how do I do this in CSS?

Firsty, make sure you read Richard’s article and apply the rules to body of text. Once you’ve got the 18px rhythm set up and everything’s aligning as it should, then you can look at the sidenote.

As we’ve decided we want to align 4 rows of the main content to 5 rows of the sidenote, we begin by finding the value, in pixels, of 4 rows combined.

<

p> Four lines of the main content.
18px x 4 = 72px

<

p> Then we find the value for 5 lines of the sidenote.
72px ÷ 5 = 14.4px

<

p>

To calculate what 14.4px is in ems (in relation to the body, and the type size for the sidenote)
14.4px ÷ 10px = 1.44em

<

p> We then add the values to the CSS for the sidenote.
.sidenote {
text-indent:-0.7em;
width:12em;

margin-right:0;
margin-top: 0.28em;
font-size:0.8333em;
line-height:1.44em;
position:absolute;
top:0;


left:42.6em;
}

You can see this working in this example.

However, note the top margin. I really had to fiddle around with this manually to make sure the alignment was correct. I did try and work out the maths for it, but it proved to be very difficult as really I needed to find the cap-height value of the typeface in order to provide a margin.

Martyn, a bloke I now share an office with (who is also a Mathematics graduate), provided me with this diagram to illustrate my problems.

<

p> Diagram showing relationship between baselines, vertical rhythm and how line-height is applied in CSS

Diagram showing relationship between baselines, vertical rhythm and how line-height is applied in CSS

As you can see, the problem is I needed to find the value of ‘x’. In order to do that, I’d need to know the value of ‘b’. The difficulty arises from trying to align the baselines and the only way of doing it was aligning it by eye. But, if you can fathom it out, then I’d be grateful.

Now, all I need to do is find the time to apply to this site and the new business site. 

A small dig at web process and smelling paper

For the past week, I’ve been designing the printed material for a certain conference. I often forget the mixed emotions that come with switching medium and designing for print again. On one hand, it’s great not to have to think about IA, usability and CSS bugs and to focus on just creating something nice and smelling paper (we’ll get on to that). On the other hand though, especially when designing to a specific deadline which can’t shift, the feeling of finality that comes with print still scares the shit out of me. If it’s wrong, that’s it.

A small dig at web process

Maybe it’s me, but when I’m designing for print—especially when I’m preparing artwork—I take immense care to not screw things up. Because once it’s at the printers, then there’s no going back. With the web, the act of finalising work before completion is actually only imposed by process and not by the physical act of uploading something. If you upload something and it’s not right, you redo it and upload again. Can’t do that with a 20k run of annual reports.

This bothers me.

So, note to self, get in the same mental space for the final production work for web design as you do for print. Probably easier said than done.

Feeling and smelling paper

I like this bit of print design. My wife still laughs at me whenever we’re out and I go fondling and smelling paper stock in Waterstones. This week, I’ve had a great time speaking with my printer and sourcing a really great stock for the conference material. This involves looking, feeling and smelling. Choosing the right stock is such a sensual experience (note. I’m using that word in its correct context there. Choosing paper is definitely not sexual. Well, for me anyway.) Also, having just gone into business myself, I don’t have the stash of paper samples I’ve had access to in the past when I worked in agencies. So, I’ve been on a dreadful looking site paperandprint.com, who have an incredibly useful list of mills, brands and products. I began the task of compiling my own paper collection.

I was amazed at how varied the industries websites were. What was surprising was that all of them, except one, made ordering swatches and samples incredibly frustrating. After about an hour, I gave up on most and picked the phone up. I don’t get it, how is this difficult? Like I said, there was one site that really stood out as a visual, interesting way of ordering samples. That was Zanders Samples.

Zanders, a joy to order

First off, before I go on about how great this was, ignore the fact the code is shonky. Okay? Good.

Most of the online sample ordering services I came across were simple shopping cart type functionality. For the most part, they worked well, but considering the breadth of most product ranges (in terms of size, colour, weight etc.), and the choices I had to make before ordering, the simple shopping cart soon became a monstrous list of links. Then I stumbled across the Zanders UK samples site.

<

p>

Very simple, task driven presentation. Do you want samples? Or other stuff?

The homepage is so simple; do you want samples (tailored to order of course), or generic product swatches and promotional material.

On clicking samples, you are treated to some wonderfully simple illustrations to guide you through the process.

<

p>

1. Choose what type of sample you want. 2. Pick a product. 3. Pick a product type and 4. Here’s what you ordered.

A really fresh take on a labourious process.

Know where I can get more swatches?

Years ago, when I was a full-time print designer, swatches and paper samples seemed to be easier to come by. Bigger mills, such as Modo, where pretty much throwing bulky swatches at any newly graduated designer. Oh how times of change. I really couldn’t believe how difficult it was to track these down this week. Anyway, I’m getting there, slowly. On that note, does anyone know of any good mills or distributors who’d be happy to send me a decent range of paper swatches?

One Principle to Design By

I’ve just been pointed to a post by Andy , called Five Principles to Design By by Joshua Porter. It’s a very good post, but point 2 has set some alarm bells off in my head once again.

Design is not art. That old chestnut.

This keeps coming up recently. Why? I’ve no idea but it’s beginning to bug me. Here’s my take on it all.

Design is not art.

That is, design is not art if you define the simple motivations. An artist is self-motivated, a designer is motivated by a client. True, artists could be commissioned etc, but I don’t want to quibble about semantics here. You get my drift.

How do I define design? Design solves a problem.

Now, that problem could be communicating a message, telling a brand story or inventing a new type of dishwasher; it doesn’t matter. So, that is my One Principle to Design By. Solve the problem

Ah, but.

That’s not the whole story.

The grey area of Art and Design is the practice of the craft of design. It’s the difference between a design being usable and a design being usable and special.

Take the Dyson vacuum for example. This vacuum works slightly differently than the others. It still does the same job, but has been designed to differenciate itself from its competitors. The designers solved the same problem in a different way. Ok, all good. Now we get down to how the thing looks. There is love in this product. There is craft in this product.

Of course, no discussion on this would be complete without mentioning Apple. Apple make beautiful products. But they didn’t always do that, and they nearly went bust because of it. For a long time, Apple made pretty good computers. In 1998, they made the first iMac. The distinguishing features of this new machine were crafted and mostly aesthetic. They are examples of beautiful product design. As a result, they sold a bomb and the rest is history.

Those are product design, but the same applies to graphic design. I’d argue that a well crafted, beautiful piece of design that solves the problem, will always do it better than one that just solves the problem. There is an important place within design for beauty and craft and it bothers me that experienced designers* in this medium don’t recognise this and are blindly advocating successful design as a practice without craft. It’s not the case.

Ok. Rant over.

* I’m not having a dig at Joshua here, or anybody in particular, it’s just a vibe I’ve been getting for the past year. 

What is up with Flow?

I’ve had a few people over the past months contact me and ask what has been happening with Flow Well, we’re still working on it, but as one of the developers, Keeran, states on his blog:

While it is achievable to ship new products in a short amount of time, as we have seen with companies like 37Signals and Carson Systems, there are always going to be times, certainly in the early stages, where Real Paid Work must take priority.

Damn right, especially for a business which is only six months old.

Since returning from snowboarding a month ago, I’ve been consumed with Real Work and everything else, including the book, has been put to one side. Such is life and, as I’m learning, business.

That said, Flow is coming along and as I’m writing this, I’m working on the templates whilst a couple of guys at Beanlogic are working on the backend. It’s coming along. Slowly but surely.

Five Simple Steps to designing with colour part 3: Colour combinations

Colours chosen from different spokes on the Colour Wheel will provide a variety of colour combinations. Deciding upon and selecting a colour combination that works for you will very much depend upon the job at hand.

Will it communicate what you want it to? Or are you just choosing them because you, or the client, like them? These are very difficult questions to answer because any designer or client will let their personal style and preference interfere with their decision-making. Colour combinations tend to evoke certain reactions either by cultural, or personal experience. Understanding these experiences will help you create colour combinations that tell a story. That is what good colour theory can give you; designs that tell a story.

I’m going to go over a few combinations here to demonstrate my thinking. But before I get onto that, it’s worth noting how palettes can be presented to potential clients or in design documentation.

I’ve always presented palettes in two different ways depending on the amount of colours. In a broad palette, with many colours, I display these left to right with dominance and usage being denoted by the size of the square, or block, of colour. For smaller palettes and combinations, I use the rectangle containing a line and a square. I was taught this simple device in university but it is similar to many other examples I’ve seen. You can use circles, blobs, lines, squares. It’s up to you. The important thing is to indicate the relative weight of colour.

{title}

Colour palette showing range of colours and relative weight.

The colours within this combination (I was tempted there to call this a Triad. However, if you think back to the Colour Wheel, this is not the case. Just because there are three colours does not make this a Triad combination) are given the following names:

  1. Subordinate, or Base colour. This is a visually weak, or subordinate, colour. It should contrast or compliment the dominant colour.

  2. Dominant. The main colour. It is this colour which defines the communicative values of the combination.

  3. Accent, or Highlight colour. The Accent colour can be two things: either sympathetic to the Subordinate or Dominant colour, or it can be visually strong and striking, therefore appear to be competing with the dominant colour. This can provide tension within a combination

{title}

Colour combination showing Subordinate, Dominant and Accent colours

Examples of colour combinations

Active / Vibrant

{title}

Active combinations are intense. They feature bright, often complimentary, colours on the colour wheel and are combinations of primary, secondary and tertiary colours. To many people, colour combinations such as this evoke feelings of noise, flamboyance and energy. It’s a young combination, although there will be cultural differences, aimed at young adults. Many of the hues are not really ‘natural’ colours, but they are more intense tones of the same colours, therefore they could be used for ‘natural’ applications such as the travel industry.

Muted / Calm

{title}

Muted palettes have a lot of white in the hues. This example uses blues and introduces lavender as the dominant colour. The resultant colourway is balanced and calming. Hues in the blue, green and violet areas of the Colour Wheel convey a visual quietness. The Accent is almost always used as sympathetic to the Dominant. Often used in the cosmetics industry, the visual softness of the colours often portrays a feminine quality.

Pastel

{title}

A pastel combination is similar to the Muted combination in that is often based on colours containing a lot of white (or lack of white depending on your colour model right?). Where they differ is that Pastel combinations combine warm and cool tones readily. This combination can portray youth and innocence (babies!) and has a warmth that the Muted combination fails to deliver.

Natural

{title}

Natural combinations are those colour which are borrowed from the great outdoors. Rusty reds, browns, sky blues and warm pinks are the order of the day. I find the easiest way to create these combinations is to go outside, take a photograph and then choose some colours from that, you really can create some stunning combinations. When you need to communicate rustic charm or the feeling of walking through autumn leaves, then this is the type of combination you’re after.

Rich

{title}

This is a good one. Hues of royalty, tradition, often religious and above all; wealth. Rich colour combinations are perhaps the combinations which are so engrained in culture. True, the actual colours used may differ, but the overall effect is seen throughout the world. Maroon is often mixed with gold and full shades of green. They can be combined with Natural combinations for a fuller palette.

Part of the design solution

I hope I’ve indicated how important colour is in communicating part of the design solution. By selecting the best combination of colours you can go a long way to ensuring the success of your design. We’ve looked at some colour combinations here but what about the individual colours? They also have meanings and go a long way on their own to set the mood and tone of a given design. Next, I’ll move onto discussing colour and mood. What do different colours mean?

Five Simple Steps: Designing for the Web

This article is an extract from the upcoming book; Five Simple Steps: Designing for the Web. Available later this month.

Yes, we know the web is not print

I’ve just been directed to a article on About.com stating that Web Design is not Print Design. Just to forewarn you, this may turn into a little rant, but I’m hoping there will be some interesting points raised.

The article starts off well with the standfirst; ‘Learn to relax your design requirements’. One of the hardest things for designers who straddle the two media to do is to relinquish control. This should not be misunderstood or scoffed at (as it so often is by web designers). Print designers are taught to solve visual problems based on a wealth of history of the practice. A lot of that problem solving is accomplished in a media where there are established conventions and parameters; from the methods of production to delivery of the content.

It’s a top-down process. The designer designs for the audience and has control over their solution. This is the way they are trained and it is a tough job to relinquish it.

Some of us have made the transition but are still very much learning. Others (and I’m talking about high profile designers here) have simply given up on the web until it has ‘grown up’. It’s a damn shame, but when the division between the two facets continues to grow, articles like this only serve as rubbing salt in the wound.

So, what, on New Years Day, got me so wound up?

There are a few things all wrapped up in this statement:

As you’re a designer, you’ll need to work with customers. You will be doing them and yourself a disservice if you don’t explain the difference between print and the Web. Especially if you bring your portfolio as print outs. This is a common problem, where the customer expects the printout to represent exactly what the page will look like… but remember that the Web is not print, and bringing a print out is not a strong representation of your Web site design skills.

I think this is just plain rubbish. If a client thinks the website will be exactly as the printouts, then that is your failing as a designer by not conducting the presentation correctly. This is often the result of misunderstanding, not the result of paper. I find presenting on paper, especially early on in the process, as a very conducive method for client engagement. They can engage with paper, scribble all over or tear up and throw in the bin. You cannot do that with a screen. Paper is more immediate and less precious.

So, I guess there are a couple of things which are happening within graphic design. Web design has been for a long time now separating itself from its print based brother. Now I know there are fundamental differences in the medium of delivery and, in many cases, the nature of the design. However, I believe this is a bad thing. If you have a background in print design, don’t forget it. If you don’t, I think you should do some reading.

You could totally disagree of course, or you may be bored to tears with the whole thing, but the old ‘print verses web design’ argument never fails to spark an interesting discussion.

SXSW panels: Take two

In March I’ll be heading over to Austin for the third time for the SXSW Interactive conference. This time I’ll be on one panel: ‘Web Typography Sucks’ with the guy behind The Elements of Typographic Style Applied to the Web and fellow Britpacker, Richard Rutter of Clearleft. The second panel isn’t really a panel at all, but a ‘’Power Session’: “Grids Are Good, and How to Design with Them’ with my good friend, Khoi Vinh.

Got my work cut out

So, things are pretty busy at the moment; book to finish, new work piling up for the business (which is great—musn’t knock it), a couple of articles to write and now two panels at SXSW. I’m not going to give too much away with regards to the panels just yet, but I’m hoping they will be light and fairly entertaining yet informative. I’m pretty sure both will be practical and, if you attend (which I hope you will), you’ll come away having learnt something that you can apply day-to-day. Not sure what time we’ll be on, but hopefully it’ll be soon on in the conference so I can kick back and get over the jetlag slowly.

Oh, and if you’re coming I’ll reiterate what a lot of people are saying at the moment: book your hotel now!. Seriously, if you haven’t, you’ll be staying out near the airport. It’s getting pretty full already.

Small is beautiful

{title}When I left the BBC a few months ago, they were kind enough to give me an Amazon voucher with which I bought a new Apple iPod Shuffle.

Well, Amazon took two months to actually get the stock in from Apple (don’t know whose fault that was, but the delivery date kept on going back and back with no word from either party.) But all that aside, I received it yesterday and it’s a little thing of beauty.

The Unpackaging Experience

I’m sure Apple have dedicated a lot of time, energy and money into this aspect of buying an Apple product. It’s a really important one. I was talking to the Wife about it ages ago and she was saying it’s similar to buying really nicely packaged clothes or cosmetics. I guess what I’m saying is, the retail experience doesn’t stop when you leave the store.

I decided to document my unpackaging experience (the limited photos are over on Flickr). It was good but there was one slight glitch. It took me longer than I thought to work out how to open the plastic container. I then noticed this little sticky out sticker bit. All was good. I could get at my Shuffle.

Partial to green

Now, you know I like green. The previous Shuffle used a lime green in the branding and on the product. This has been carried through again to the packaging, branding and product of the new Shuffle. It’s all black, white and green (except for the silver of the Shuffle itself).

The proof is in the pudding

The new Shuffle itself is great. Really tiny and sits well in its little dock. The new earphones are great with much better sound and comfort than the previous models. So, all in all, as you’d expect from Apple. However, I’ve got one gripe. The controls are 90 degrees the wrong way.

If you clip the Shuffle to your trousers, all the controls are facing the wrong way. Also, the interface assumes you are going to clip it to your body on your right hand side (on the edge of a jacket or pocket for example), so all the controls are the right way up and you can get at the on/off switch etc. But doesn’t this mean you’d use your left hand to clip pit there? The natural place for my iPod is in the inside left pocket of my coat. Maybe I’m being a touch picky.

Well, tomorrow will be the proof. I’m heading off to Spain for the day for a client meeting and I’m just going to take the Shuffle for company. We’ll see after two flights and two bus journeys if the Shuffle still holds up.

Back to Green (for now)

Following my month of supporting breast cancer, this site is now green again. If you’re reading this in an RSS reader, then you probably don’t give two hoots. However, if you’re reading this in a browser, then kindly dump your cache and refresh otherwise things may look a little odd.

It’s been nice being pink for the month I must admit. So much so that I’m considering a slight colour change more often. I may even put you, my readers, in charge via a little stylesheet switcher (user preferences? heaven forbid). Although I’ll probably end up tossing this thought on my steaming pile of unfinished, festering ‘things to do’. Like I haven’t got enough to do with a new business, a book to finish, a web-app to finish…

Five Simple Steps to designing with colour

{title}It’s been ages since I’ve had a stab at a Simple Steps series. So far we’ve had Better Typography, Designing Grid Systems and Typesetting. This one has been kicking around for a while so I thought I’d just publish the first couple and see where we go from there (of course there will be five, I just haven’t written the last couple yet).

Designing with colour is perhaps the element of graphic design which is the most difficult to get right. Why? Well, because it is the most subjective. For some, a palette of dark grey with splashes of bright pink will be just great; to others it would just be all wrong. Too many designers, whether schooled in colour-theory or not, end up making subjective decisions about colour and then when it comes to explaining those decisions to a client, things begin to unravel.

This first post in the series will be dealing with looking at tone and the value of limiting your palette.

Lowering the tone

Years ago now (ooo, about fifteen or so), I was in my first year on a Foundation Art and Design course here in Stockport in the UK. I wanted to be a painter (well, an illustrator to be precise). In the first week of this course we were all told to get rid of our nice new paint-brushes we’d bought for the course. We were told to leave all our new kit at home and to go outside and find some nice twigs and get some black ink from somewhere. I was not chuffed. How was an artist meant to create with these primitive tools?

The lecturers had us painting with twigs, our feet, blindfolded; the works. At the time I hated it; couldn’t see the point. Now, I look back and really see the value of this horrific couple of weeks. They were teaching us how to look and produce marks which weren’t dictated to by our tools. In other words, because we had colourful paints and lovely sable brushes, the temptation is to use them. Without the brushes, and the colourful paint, we were forced into trying to communicate colour with tone alone.

This is what I’d like to focus on to begin with.

Removing colour

One of the things I like about editorial design, specifically typographic design, is how there is an emphasis on black and white. True, colour is a very important part of any typographic exercise, but primarily I begin by looking at tone and form. I think there’s a lot of value in removing colour from the equation entirely and focusing on the tonal aspects of a design before applying the colour.

There are a few notable examples of how designing with just black make for a unique and attractive design:

Of course, no discussion about designing with black and white on the web would be complete without mentioning Khoi Vinh’s site, Subtraction.com. Khoi works with black and orange to harmonise with the Swiss undertones of the design.

<

p> Khoi Vinh's Subtraction.com

<

p class="caption">Khoi Vinh’s Subtraction.com

Form, a German design magazine, uses black and white typography (and a strong grid), to convey it’s brand to the users of the site. The effect of having a site like this in black and white, is the work that is showcased here, being in full colour, really stands out against the black and white framework.

<

p> German design magazine, Form

<

p class="caption">German design magazine, Form

Begin with Grey

Next time you start a design, try this. As simple as the heading says, start your design in grey and tones thereof. Don’t introduce any colour until the design is working in black and white. Chances are, your decisions on palette and colour will be made a lot easier because the design, or elements of the design, aren’t relying on colour for their function. This of course is very useful for designing with accessibility in mind. I’m not addressing any accessibility issues within these articles, as I’d like to focus on the graphic design, but it’s an important consideration that shouldn’t be overlooked. Designing with black and white first will ensure that the solution doesn’t rely on colour to work.

I often use colour to highlight specific elements of the design, but generally those elements have a function within the design solution, such as the horizontal lines on this site. Another example might be highlighting a search button, or elements of a navigation bar. Using colour to pick out key functional elements in the interface.

<

p> {title}

Solving tonal problems before applying any colour

The benefit of working this way, like other tools at the disposal of designers such as grid systems, is that it solves a certain amount of problems for the designer. I find it focuses my attention to tone and composition without worrying if this colour matches that. Focus on the composition tone, once that’s sorted, move on to the colour.

Moving onto mono and duo tonal palettes

In the next post, I’m going to focus on taking the grey a step further.

You know, us web designers have it quite lucky. We can use any colour we like (within reason). Print designers have had to deal with colour limitations since the press was built. This has made print designers very sensitive to designing with colour. There’s nothing quite like designing a one or two colour job, but over a wide range of material, to really get you thinking about how colour is used. I’d like to bring some of that kind of thinking (and restraint) to the next post.

Professional body for the web design industry?

I was listening to the @media ‘Hot Topics’ podcast the other day, which unfortunately I had to miss. The section of it which I found really interesting was the discussion on a professional body (which is about two thirds of the way through). Although the panel agreed that a professional body for our industry is overall a bad idea, I actually think they were talking about several different things.

Accreditation and Certification

If you listen to the podcast there are some points in there about Accreditation and Certification for web design. The general consensus from the panelists was it is a bad idea for several reasons.

Outdated teaching and therefore outdated qualifications

Eric Meyer pointed out that web design courses are teaching applications and methodologies that are simply out of date. If that’s the case, which I’m sure it is, then the graduates are going into industry with the wrong tools. So, why is this happening? This brings me onto the next point the panel raised:

Industry moving too fast

It’s all going to fast for education or accreditation to keep up. Agreed. I know quite a few people who work in the education sector and the hoops they would have to go through to just teach this stuff is mind-blowing. Generally It’s not the lecturers fault here, let me make that absolutely clear. It’s the system. If a teacher wants to teach web standards, they have to do it within an agreed framework. This framework has to be agreed and signed off by their superiors and if it requires new software, this also has to be agreed, sign-off, bought, installed etc. That can all take a year of more. Seriously. By the time it’s all been considered, because of the speed of our industry, the focus might be on something else right? It’s an unworkable situation.

Technical certification

This works where the certification is for proprietary software. Take Microsoft for example. They do a bunch of certification programmes which are incredibly valuable for employers and employees alike. This kind of certification falls to pieces when you start applying it to something conceptual or open source. It just doesn’t work. Molly mentioned a WaSP seal of approval had been discussed and rejected several times. I can see why. Like the education example, I think it’s an unworkable idea to give accreditation.

However, taking the example of the iSTD, and other similar organisations, I think membership or awards to some kind of professional body (by way of peer review) could work.

We are talking about modern web design here in it’s broadest sense though. Some of that is difficult to give accreditation to, such as the development aspect of web design, web standards etc. etc. It does all beg the question; what’s the point of professional bodies anyway? Who benefits?

Best design practice

Jon pointed out within the discussion that I am a member of the iSTD and as such (in the context of the discussion), it sets me, and members of similar organisations, apart from the ‘Front Page designers’. True. But, sets me apart to whom? My peers or my clients? But before I go on about that, I’m just going to give a bit of background about the iSTD, how I joined and why I did.

The International Society of Typographic Designers

The International Society of Typographic Designers, or iSTD, is a professional body run by and for graphic designers, typographers and educators. Part of it’s mission statement is to:


… maintain typographic standards within the professional design and education communities through the forum of debate and design practice.


Sounds great doesn’t it? There’s a key word in there as well; within. Although the iSTD does reach out to clients, it does it by mainting standards of it’s existing, and new, members.

This is also a society about the craft. The practice of typographic design. The iSTD was formed in 1928 as the British Typographers Guild and has had many notable members. It’s current board members include David Jury and Erik Spiekermann.

Like many forms of design (web design included), there are shades of grey as to what is deemed ‘good design’. The polar opposites of this spectrum are what defines the entry requirements into a society like the iSTD. The Society is open to all practicing designers in the fields of graphic design, typography and visual communication design who show evidence of their competence and active involvement.

So how did I get involved? Well, the iSTD have run, for many years now, a student membership scheme with many universities and design colleges throughout the world. Once a year, the society issues a brief and if you pass the requirements, you are awarded membership. What do you get for your membership? Well, in addition to the opportunity to part of a historic Society with some incredible members, you get a great magazine every quarter and you get to put MISTD after your name. ‘Where do I sign?’

The brief was to design sample spreads and cover for an Encyclopedia of Molecular Biology. It was tough. It took nearly three months to complete and taught me a great deal about grid system design, typographic design and access structure which I still use today. So, I passed and was accepted.

Setting you apart from the rest

I don’t think it does. Well, not for your clients anyway. For your peers, it may appear that I’m a member of a club or something. Somewhere where I occasionally go to talk about type and listen to people talk about type and then I go back to the real world. I’m sensitive to the fact that being part of the iSTD, because you have to be accepted, can appear to be elitist to the rest of the design industry. However, the simple fact is, without a peer review to see if your work is of an acceptable quality, the whole model falls apart. If there is to be a body of professional web designers, it has to work on this model, no question.

Best business practice

Another area, and perhaps the most useful, where professional bodies can help is in the business and practice of design.

The Chartered Society of Designers, of which I’m not a member, focuses on this find of help and support for the design community in the UK. It also has a remit similar to that of the iSTD, but there seems to be less of a focus on craft. The Society seems to have a much wider remit and by all accounts serves the UK design industry very well. I’ve heard great things about the help it offers on Copyright and IP for example.

The web design industry is crying out for something like this. Sure, grass-roots works to a certain extent, but when you’re talking about IP and copyright, I will pay for the correct information. I’m not sure I trust free content where things like that are concerned.

So, what’s the answer?

I think this industry needs a professional body who has a narrow remit. I don’t think certification, especially web standards, is workable. I’d like to see best design, development and business practice addressed. Although maybe all three of those would be too much to bite off. I’d like to see it as membership by peer review and I wouldn’t mind paying for it annually.

What do you think? Should there be a web design professional body? What should that body do? Is something like the iSTD model workable for web design?

The advantage of working client side

You may guess from the complete lack of updates here that I’ve been rather busy since returning from holiday. Getting into the swing of things after a holiday is bad enough, but getting back into the swing of being a commercial designer again after four years at a public service broadcaster is a challenge. I’d like to think I’m up for it though. That said, working client side is an incredible challenge and, if presented with the opportunity, I think every designer should jump at the chance.

What do you mean client side?

I mean working for an organisation for their output rather than clients. So, if you work for AOL, or the BBC, or Yahoo! or Google, then you’re working client side.

As you may know I worked for the BBC for four years, which overall were incredibly rewarding for a me. It did require a complete change in the way I thought about design though which I guess is the reason for this post.

What’s the difference?

Client side designing (and I guess it’s the same for development) is a little bit like painting a bridge. You never finish. Once it’s done, you go back to the other side and you start again. It’s about continual, iterative improvement. Little by little the product is improved. The benefit of this for a designer is you get very unique view of the process compared to an agency/client relationship. In a way, you are the client. The sense of ownership is far greater than in an agency. However, it does have a downside or two.

As I said, you never seem to finish. There’s rarely a sense of closure because there’s always something else to do. This can kill morale and, I think, it’s the factor in determining good management of any internal design resource. Projects need clear edges. Start, middle and end. Go for a drink and start the next project next week.

Of course I do have the benefit of hindsight here. And let me just say this isn’t a dig at the BBC by any means, I’m just, well, rambling on about things I’ve been thinking about for a while and now I’m freelance some things have become very clear. I’ve also spoken to a few people about working client side and we all seem to share the same issues and problems, but also the same advantages.

The benefits of designing client side and then agency side

First of all, there’s the audience.

Working for a public broadcaster in the UK, as is probably the case for any publicly-funded media organisation, the audience is pretty much the organisation’s bottom line (mostly). Audience approval and traffic is the measure of a site’s success. Not advertising or subscriptions but what the audience thinks and the traffic the site gets.

Being a designer within that audience-focused environment is fantastic. It’s all about the end user. There is a flip-side though and I’m sure this is the case for any designer working in this industry today. That environment isn’t always conducive for producing creatively challenging projects, let alone solutions.

Then of course there’s time.

Things on the client side of the fence, particularly where the bottom line is a little blurred, run a little bit more slowly. Thankfully, I worked in agencies for a good few years before the BBC and that part of me remembers I need to work quickly, efficiently and to budget in order to make a profit. Oh, and it’s certainly helping for the development of Flow.

Do you work agency or client side?

It’d be really interesting to hear your views on working client or agency side. Love it? Hate it? What challenges do you face every day? What are the real hurdles you’ve had to face and overcome? Who knows, maybe I can help.

OS X theme for a Sony Ericsson k800i

{title}Yesterday I finally received my new mobile phone, a Sony Ericsson k800i, and it’s a little beauty. There were a few problems though.

Firstly, it’s a little larger than I expected. Not in physical size though - it’s a bit of an illusion. Because the sides don’t taper, like my Nokia 6230, the k800 just seems larger. The fact is, it’s only a couple of mm taller and about 3mm either side wider. I can live with it. Secondly, Vodafone ships the phone with it’s own ‘branded’ os and by God has it been beaten with an ugly stick. So, I took it upon myself to reflash the OS and install my own OSX theme.

Flashing the OS

The prospect of this scared me to death. It was a risk. As I was reading on a few forums the phone could just stop working and I’d need to return it to Vodofone claiming it was dead on arrival. Part of me really couldn’t be bothered with the potential agro. The other part of me however, the part that would open a door it shouldn’t and the part that really couldn’t live with the Vodfone icons, just had to do it.

I paid a few Euros for a reflashing account on Wotanserver, and made sure I followed the instructions to the letter. In fact, following a bit of research and cobbling together their own instructions, I got together my own list.

  1. Turn phone off and do proper charge and not optimised charge until it says fully charged.
  2. Turn on phone, clear out all data from your memory and contacts etc.. back them up to wherever, like Outlook
  3. Remove all non-standard themes - leave only the ones that came with the phone and activate the default.
  4. Do a master reset, ie. leave the phone as you first got it from your network provider, this can sometimes activate the earlier point of removing themes and therefore point 3 may not be nexcessary.
  5. TAKE OUT YOUR BATTERY FOR 30 SECONDS AND REMOVE YOUR SIM!
  6. Do a final charge check before hooking up to your PC.

Then connect to your PC. I used XP running under Bootcamp on an Intel iMac and everything worked out fine. So, onto the reflashing. These are the instructions from the Wotanserver site:

  1. Please first be sure, that you have DCU-60 USB Flash Driver installed and your phone battery is charged 100%!
  2. Download & run WotanClient and wait few seconds until data are updated from server.
  3. Have DCU-60 Cable connected to computer, push “Start” and and connect off phone while have C keep pressed
  4. Now check if phone model detected correctly, choose desired firmware (latest one is selected automaticaly), choose desired CDA and check “Finalize” option (this is required to have working phone after flashing - if you not check then you get “Configuration error!” message after flash). Push “Continue” button.
  5. Wait until all required files are downloaded. Your phone flashing will start automaticaly. When finished you will see “==FINISHED OK==” message.

It took about 8 minutes to complete the reflash, then to be super-cautious, is what I did:

  1. Took out battery for 30 seconds
  2. Put in battery, but before booting the phone I checked the charge and all was well.
  3. DO NOT PUT IN SIM!
  4. Start phone and fingers corssed your phone will go through the PLease Wait loader
  5. It will then present you with the normal phone or flight mode
  6. Work through the steps making sure everything is in order then turn off yor phone.
  7. Insert sim and reboot phone and go through instructions.
  8. Load your contacts
  9. Job done

After all I that, I ended up with a debranded phone with the newest OS on there, which is great. The Sony Ericsson icons are just soooo much nicer than the horrible isometric yellow and red icons from Vodafone. The next thing to do was to install my new OS X theme.

Tiger theme for k800i

I used the fantastic Sony Ericsson theme builder to cobble together an acceptable Tiger theme for this phone. It’s a ‘blue’ theme at the moment, but i’m tempted to do a grey one soon as I think it will suit the phone a bit better. You can download the theme here (149kb), along with Apple spinny screen saver I knocked up. Here’s a picture of it in the wild:

{title}

Syncing

The k800i currently isn’t supported by iSync, but for a couple of quid, you can get the iSync 2.3 plugin from here. Works like a charm.

What about the camera?

Well, it’s good. Really good for a phone. I’ve actually not taken that many pics I’ve saved yet, but I imagine this will be my digital camera’s downfall. The quality of this camera phone is just excellent. I’ll post some shots up when I get some good ones.

Sorting my workflow out, part two

Printed estimateLast week, I mentioned I was slowly drowning in a thickening quagmire of paperwork—estimates, invoices, contracts and things. I took it upon myself to design and build a system which would help sort me out, thanks to a bit of inspiration from Stan and the boys at 37signals. A week later and this little application is working rather well, even if I do say so myself. 

Filling in the gaps

When I posted last week, I’d got together the basic requirements and workflow. Just to recap:

<

p>

  • List all current and closed jobs
  • Each job must have a job number, client, associated estimates and invoices
  • Create, edit and store all estimates. Give them a status of Pending, Approved and Rejected.
  • Ability to print estimates and invoices using a well designed print stylesheet
  • Saving off PDF?s using the same print stylesheet
  • Create, edit and store all invoices. Give them a status of Paid, Part-paid and Unpaid

By Tuesday I’d pretty much got together the bare-bones. Then with a little help from Expression Engine I applied some edit forms, so now I can add and edit Estimates, Invoices and Jobs, all from within the browser rather than having to go to the Expression Engine control panel. All good.

Here’s a few grabs of where I’m up to at the moment:

<

p>

  • Dashboard
  • Jobs
  • All invoices
  • New invoice
  • Invoice detail
  • Edit estimate
  • Estimate detail
  • Printed estimate


Designing with Print Styles

The detail page for displaying the Estimates and Invoices proved to be a little tricky. First off, I wanted to emulate my design for paper Invoices and Estimates, secondly, as I wanted to save these invoices as a PDF for emailing to clients and also printing, the print stylesheets for this template had to essentially create the layout for the PDF.

In April, I wrote about applying print styles to a web page and touched on using CSS to design for print. Then, it was a fairly simple prospect; designing a newspaper layout to run on A4. One column. No fuss. My Estimate/Invoice layout is a different kettle of fish altogether.

For starters, there’s a four column grid. Secondly, there’s a extensive use of white space and Rules of varying thickness. Also, there’s a subtle, but important typographic hiearchy going on. I set myself the challenge of recreating this design, which is essentially an Indesign layout for A4, using the existing markup for the template and CSS. This is the first time I’ve done this in anger. Using CSS to layout a design for print.

Bodging with absolute positioning

The web-based template display of the detail Estimate/Invoice page uses floats to produce the layout. This proved to be pretty tricky for reproducing this design for print. The solution took a little of getting my head around.

What I did was to start thinking about the elements of content as square boxes in Indesign. Start thinking about print stylesheets as print design. I had to forget about certain browser quirks of CSS (yes, I was designing this just for me, on a browser of my own choice.).

I used position: absolute; on most elements, giving them the width, height and position as I would a box in Indesign. Using margins and padding defined in mm, coupled with this allowed me to, with a lot of trial and error, position the elements and pretty much exactly reproduce my letterhead and Estimate design.

Granted, it’s a bit of a bodge, but it works and fits my needs.

Room for development

It was incredibly time-consuming but the implications of designing a system this way, for me, are pretty fantastic. I now have an database with all my jobs in there. It produces a web based system for to keep track of stuff, but more importantly, it produces Estimates and Invoices which mirror the print design I spent a lot of time initially producing. You can probably sense I’m quite excited about this. Designing for print using CSS is something that has possible for ages, but it’s something that is just not given enough attention.

I’d like to see this kind of technique applied to corporate intranets for example. When printing an a page, there’s no reason why the corporate design guidelines couldn’t be applied to the content to the same level of sophistication as a DTP package.

More for the App

There’s a bit more to do with this little application. It’d be great to have an emailing facility in there to email the invoices/estimates directly to the client. Currently, I have to save off the PDF and manually attach it to an email. To be able to track which client had been emailed and what was said would be a good thing I think. Also, the print styles need to be applied to all the other templates. Jason mentioned in the comments on my last post that he used his system to work out tax. It might be good if this system could also do this for.

I could go on. But I won’t. I’ve got enough to do.

Sorting my workflow out

Screenshot of estimates dashboardA while ago now, like Jason, I realised I needed better organisation in my life, from both a personal and business perspective. I don’t consider myself a really busy person, although one thing has made me realise I need to be much more organised: I’ve got a lot on!(detect the slight edgy panic in my voice?).

I guess it all started last September when Khoi and I were discussing our panel for SXSW and he got me started with Backpack.

Putting Basecamp and Google Calendar in your Backpack

First let me say, and I’m not the first to do this, that Backpack it great. Really great.

I had my doubts when it was first launched—how many people thought, ‘well, I’ve got a diary, why do I need this?’—but after using it, first on the SXSW panel organisation, and every day since then, it has saved my bacon on a number of occasions. Couple Backpack with Google calendar for, you know, calendar stuff and Basecamp for those projects which are larger and require a little more client interaction and I have 75% of my organisational infrastructure solved. However, there’s one thing which is missing for me: Invoice and Estimate workflow management.

Keeping track of the business side

I’m sure I’m not alone on this. I’ve had a problem over the last year, which seems to be getting more complicated, of managing the jobs coming in and going out, the estimates and invoices, what’s been paid, part-paid or hasn’t been paid at all, what’s overdue, what’s not. See? The list goes on.

I’ve tried several products, such as iBiz and Studiometry, but they all suffer from the same old problem. Too much functionality and the UI and workflow, to be used on a daily basis, are just too complicated.

Of course, there’s Blinksale for invoice management, which does a great job but is only part of the equation.

Following reading Jason’s post, I was really inspired to just solve this problem myself. I may not be building a web app here, but I can give something a go to solve my problems.

Getting the requirements together

<

p> The first thing to establish were the problems. What did I need the software to do? So, I got together this list:


  • List all current and closed jobs
  • Each job must have a job number, client, associated estimates and invoices
  • Create, edit and store all estimates. Give them a status of Pending, Approved and Rejected.
  • Ability to print estimates and invoices using a well designed print stylesheet
  • Saving off PDF’s using the same print stylesheet
  • Create, edit and store all invoices. Give them a status of Paid, Part-paid and Unpaid

The list could go on, but I stopped there.

Understanding the workflow

<

p> The next step was understanding my workflow. How do requests come in? What is the process following that request? Again, I went through the same process:

  1. Request comes in (usually by email)
  2. Set up client details
  3. Set up Job and Job number and assign to client
  4. Create estimate and assign to job number
  5. Send estimate to client and change estimate status to ‘Pending’

Then, following my appointment and competion of the work.

  1. Set up invoice and assign to Job
  2. Email to client

Building the thing

So, I started building the thing using Expression Engine which has a couple of drawbacks. The big drawback is the application has two parts: a web interface and a control panel. So, not everything is done on the same screen such as adding estimates and invoices etc. This could be done using EE’s stand-alone edit form, but you would only able to add stuff and not edit and delete (I think). I may look at this in the future and see how I could use it.

Once it’s complete, I plan on doing a more detailed write-up of how I built it using EE. It’s quite an interesting project trying to build an application like this, rather than a website using EE. It’s liberally using the ‘relationship’ fields to save on data input and duplication and has a bunch of custom php in there to work out if invoices are past their 30 days terms.

Here’s a quick grab of where things are at so far:

Screenshot of the dashboard showing pending estimates

Yes, the design looks like Basecamp and a hundred other applications like it. However, there is a reason for this. All of my 37Signals apps, and EE’s control panel all look the same. I use the same tabs, colour ways, links and everything on all of them. I use half a dozen apps to manage my life and business so I’m much more comfortable if they all look the same. There’s nothing more jarring, for me anyway, to switch between apps and have the core design and colourways change.

Your thoughts?

I’d be really interested in your thoughts on this. What systems and workflow do you currently use? Is it more traditionally paper based? Where do you think I could improve on what I’ve got going on here?

Kitdesigner Beta goes live

Football Kit Designer logo

A while ago now, Communis, Bath based accessibility company, approached me for the branding and graphic design of a website which would sell customised football team kits and leisureware. Now, four months or so down the line, the Beta for FootballKitDesigner has gone live.

Rugby Kit Designer screen showing the Designer applicationThere are a number of items which are yet to go live, such as online ordering and personalisation. In addition, there are a load of articles about sports kit to go on there. There’s also a load of tweaking to be done during this Beta period.

The templates were built by Communis to work on an impressive array of browsers and devices. The site also dynamically loads in different stylesheets depending on the browser width.

In addition to FootballKitDesigner, its sister site is due to go into Beta soon, where (I’m told) there will be 150 billion combinations of rugby shirts available. So, if you play rugby for a team and need a unique shirt be sure to check back for RugbyKitDesigner.

@media 2006 is just around the corner

@media 2006 logoI’m getting pretty excited abut @media which kicks off in a couple of days.

Over the past few months I’ve been working with the guys at Vivabit to produce the printed material for the conference. It’s been great to get my teeth stuck into some print again, but I’ve forgotten how stressful print deadlines can be. I think printers are like builders, and to be perfectly honest I’ve no idea how some of them remain in business. But if you find a good one, it’s a totally different story.

There were problems with finishers (not being booked in to do the stitching), to name badges having to be printed again (bloody printer cropped them landscape instead of portrait), but we got there in the end, the client’s happy and I’m looking forward to seeing them in situ.

That brings me neatly onto the conference itself. It looks a belter this year. Not only the panels, but I’m in the position of knowing a lot more people so the social side of it will be more enjoyable. On another positive note, I’ll also be enjoying @media 2006 illness free. Last year—about two weeks after @media—I was in hospital, I’d lost a stone in weight and was diagnosed with Ulcerative Colitis. At SXSW, I had a flare up (probably due to the stress of preparing for a panel!). However, currently (touch wood), I’m symptom free and feeling good. I’m just so looking forward to meeting up with friends and making new ones.

So, if you see me, say hi.

Web designer’s guide to print design

Recently, I’ve been producing some conference materials for a certain conference in the UK. It’s been a while since I’ve done any print design in anger—in fact, it was two years ago when I produced a bunch of things for our wedding—but I’ve really enjoyed the process again and it’s pretty liberating to be designing for a media with so many conventions in place, both production and design.

I’m sure a lot of web designers are asked if they ‘do’ print. I’m positive a lot are put off because of the production. Printers can be scary, as can the whole production process, particularly for large scale projects. So, I thought it might be useful to explain a few things. 

I’ve a feeling this may extend to several parts to really do it justice and provide something useful, but here goes anyway.

The right package for the job

Indesign butterflysThere was a time when there was just one software package you had to use to produce print work: Quark XPress. I look fondly on those early days of using XPress. Yes it crashed all the time, was buggy as hell but wasn’t it just the perfect tool for the job? It was trim and had an intuitive interface. The problem was, that was all you could use. Not because of alteratives in the market, such as Aldus Pagemaker, but because the production side of the industry—repro houses and printers—used them, and only them. And at over a thousand pounds a licence, it wasn’t cheap to be a print designer. Thankfully, those days are long gone.

Adobe introduced Indesign, labelling it the ‘Quark Killer’. A few industry pundits were skeptical. There’s no chance a bloated piece of software, such as Indesign, could compete. Well, it could (mostly due to the failings of Quark’s latest XPress versions) and did and now thanks to the rise in PDF as a standard format, we’re seeing Quark struggle to justify its ridiculous price tag.

So, those are two industry standard pieces of software for page layout: Quark XPress and Adobe Indesign. You can of course use other software packages such as Adobe Illustrator and Photoshop for other design elements, but for creating multi-page documents, those are just the ticket.

Types of printing

The first hurdle, is deciding on your printing process. What is going to be most effective for the piece you are designing? What is going to be the most cost effective?

There are many different methods of printing. Two are more commonly used when designing for brochures, letetrheads etc, so I’m just going to deal with them here. Digital printing and Offset Lithography.

Digital printing

In my experience, digital printing has always been ignored by production managers I’ve worked with. This was always due to poor quality, both colour and finished surface. Digital printing didn’t, and still doesn’t, have the same quality as Litho or Flexography. But the differences are becoming less and less obvious as technology in the field increases. So, when would you use Digital?

<

p>

  • For short full colour print runs
  • For quick turn around

Advantages

<

p>

  • Generally cheaper
  • No plates or films to be produced, therefore costs are limited
  • Quick turnaround
  • Large format printing

Disadvantages

<

p>

  • Colour recognition can be poor
  • Digital printing can often produce banding on flat colour (the same as inkjet printers)
  • Expensive for large qualities
  • Same price for full colour as it is for spot colour
  • Limitations on printing to certain paper types/weights

How does it work?

In basic terms, digital printing is like your desktop printer, just on a bigger, more expensive scale. An operator can load up some PDF artwork, press print and away you go. You can see how turn-around can be so much quicker, the whole production process is so much quicker than traditional methods.

Offset lithography

Offset Lithography, or just ‘litho’ as it’s often referred, is perhaps the most common method of printing onto paper. Both CMYK and Spot colour can be used. CMYK is full colour printing, whereas Spot colour uses specific Pantone colours, I’ll get onto to talking more about that though. The process for litho can be daunting and drawn out, it involves many steps, which each have their own dependancies and can be expensive if screwed up. First of all, there’s the planning up, or pagination.

Printing presses use large plates to transfer the image to paper, the most common in the UK is B2 size, which is slightly larger than A2. In order to make maximum usage of the paper and plate, several items can be ‘planned up’ on one plate. This can be incredibly complex for a designer to get his/her head around, let alone do it. Luckily, most printers do this for you. When they’re doing though, just a tip - check to see if there’s extra room. Sometimes you can get freebies produced on the back of client work, such as business cards or promotional flyers.

Next up is the films. In litho printing, film is produced from your pdf or Indesign file on an imagesetter and then a metal printing plate is made from that. There needs to be a different plate produced for every colour used. So, in a CMYK job, that’s 4 plates for every full colour page. You can see how things can become expensive if there’s a typo?

Then we have proofs. Once the films are made, proofs are produced by the printers to give to the designers to check and sign-off so the plates can be produced. These proofs (cromalins or colourmatch), are colour accurate, but can be expensive. Many production managers and designers still want to see proofs made with films despite the rise of technology such as ‘Direct to Press’ printing which cuts out the production of films and goes straight to plates.

One the proofs are signed off, the plates are made and the printing begins.

When would you use Offset Lithography?

Well, I’ve used it most of the time. It’s only recently, now that digital is really starting to improve, have I started to use alternatives.

Advantages

<

p>

  • Superior quality
  • Availibility
  • Cost effective for large print runs
  • Wide variety of paper stocks to print on

Disadvantages

<

p>

  • Can be expensive
  • Lead time and turn around
  • Expensive to rectify mistakes

How does it work?

Offset Lithography is a bit weird. It uses the repulsion of oil and water to transfer the image to the paper. The plates are chemically treated to accept oil based inks, and repel water, on the image areas and the opposite happens with non image areas.

A plate first contacts rollers of a clean solution or water and then is inked by other rollers. The oil-based ink ‘sticks’ to the image area. The image is then transferred from the plate to a rubber blanket. The rubber blanket then transfers the image onto the paper’s surface. This is why it’s called ‘offset’, because the plate never actually touches the paper.

A part two

It looks like this could be longer than I anticipated. Damn. So, when I get round to it, I’ll do another part. (and probably another and another - in fact it probably should be a simple step series, but we’ll see how I go, could end up more than five steps.)

In the meantime, it might be helpful if you could tell me where you’ve had difficulty in the past, what do you know and what don’t you know about designing for print?

Podcasts and an article

This is a bit of self publicity, but what the hell.

Firstly, I’ve written an article for those lovely Carsons over at Vitamin.

It’s a piece I originally started thinking around here in my Journal, but have expanded upon for Vitamin (and there’s probably more to come on the subject). It’s about the way designers think and semantics.

Secondly, Podcasts are available for the panel I sat on at SXSW in March called Traditional Design and New Technology. And also for a presentation I gave at Ideas3, an event held by Port80 in Perth, Australia last month, where I talked about typography and craft on the web.

When less is more

Less is more. We’ve all heard that saying a thousand times. What does it mean though? For me it’s the result of a particular way of working.

In October last year, Jason Fried of 37Signals gave a 10 minute talk at the Web 2.0 show about, well, ‘lessness’. In an interesting talk, Jason described five things which you need less of (which you think you actually need more of). A lot of what he said made absolute sense from a business perspective. I’d like to add to that some thoughts on what you need less of in graphic design.

The Spark

What triggered my thoughts on this, in addition to the recent debate about graphic design on the web (and yesterday’s post on SvN regarding Don Norman’s thoughts), was Malcolm Gladwell’s fantastic book, Blink.

In the book, Gladwell describes how a doctor called Brendan Reilly developed an algorithm for making the diagnosis of heart attacks easier for doctors. The algorithm, based on months of statistical research, was based on three factors which Reilly would propose doctors use to diagnose chest pain. Reilly proposed that factors such as extensive patient history shouldn’t play a part in diagnosing acute chest pain. Of course, the other doctors have a difficult time accepting this as a way of working.

The idea behind this conclusion is about removing distraction. It’s not about making things simple, or reducing complexity, but increasing focus on the immediate problem.

It really got me thinking.

As I mentioned, there’s been an ongoing discussion about the effectiveness of Google. I’m not going to dwell on this too long (as a lot of it has already been said), but I think the same concept applies here. Google works because of a lack of distraction, not because it’s simple. A search engine like Google is complex, as it’s other services. Where Google succeeds is by removing obstacles in the user’s path. They want to search, they’re shown a search box and results. No distractions.

The same can be applied in graphic design.

Five things

So, following on from Jason’s idea of doing more with less, here’s my five things you can do more with less in graphic design.

Less Noise

There’s too much visual noise. Whatever you’re designing, if it’s a magazine cover, the latest web app, or a orange juice label, how do you stand out in the crowd? How do you compete visually? This is a tough job, as any designer will tell you, and the natural reaction is to add more noise. More colour, more type, more expensive production and ultimately, more money.

I’m not really talking about minimalism. More like restraint. When you feel this coming on—and I’m sure we all do—try and focus on the problem and the visual steps you need to take to solve it. This usually sorts me out and gets me on track again.

Less Distraction

This is as much about interaction design as it is about graphic design. Is the solution (the design), fit for purpose? Does it answer the brief? What could you remove that just isn’t needed? I ask myself these questions, especially the last one, a lot. What could the client do without? It’s always a natural reaction to add. Complexity, visual noise, colour etc. They all increase distraction.

Fewer Typefaces

Erik Spiekermann once said ‘You need as many typefaces as you need ties’. True, but not all on the same page/screen. It’s a great idea to increase your typeface vocabulary - emmerse yourself in the various type foundries books (Linotype has a great book available). At some point though, find a few typefaces you really like (more often than not, this will happen by accident as you find yourself using them all the time), and really get to know them. Get to know the quirks of that particular cut, such as the kerning and the fact that the ‘fi’ ligature doesn’t look quite right. Soon after, you’ll find yourself using less typefaces, but being very familiar with the ones you do use.

Fewer Trends

Trends are fashionable. Sometimes they are a solution to a brief, but not always. Like bad furniture, they have their place, but the trick is knowing where.

The web has a fashion turnaround similar to the fashion industry I guess. It’s a fast paced environment and industry leaders set the trends. But I guess, like fashion, this can be exhausting for a designer (and a client). A classic, timeless design is almost always a more successful solution to one which has all the latest bells and whistles.

Less looking in the future and more in the past

A lot of designers are well versed in graphic design history. A lot aren’t. I guess it’s all about building up a visual vocabulary from past experience. Thing is, if all your experience of graphic design is from what’s around you now, you have much less to draw on in terms of inspiration. Read some books, visit exhibitions, maybe even start a weird hobby like collecting old Penguin books!

When less is more

Less is more isn’t always about minimalism. It isn’t always about simplicity either. For me, less is more is about clarity—whether that’s a search engine, a teapot or a really great plate of food. Clarity is vital in graphic design and without it, well, it may as well just be art. But that’s a whole other blog post.

Penguins in Perth

When Emma and I were in Perth, more specifically Fremantle, on a ‘find a pair of decent flip-flops’ mission, we happened upon a small second-hand book store. Normally, I tend to walk past second hand book shops (as they’re usually crammed full of Mills and Boon’s), but something caught my eye with this one. Shelves and shelves of second hand Penguin books dating back to the 1940’s. I couldn’t resist.

For those who attended the panel I was on at South By South West this year, Traditional Design and New Technology, you may recall me mentioning a book on the history of Penguin Book cover design, called Penguin By Design by Phil Baines. It’s a wonderful book, and currently selling for a little over a tenner, I’d say it’s a must for any graphic designer. Anyway, back to the book store…

Emma was very patient (as usual!), as I cooed over the various designs and then decided on my three purchases. I could have bought a lot more, but as it was we were both over weight with our baggage and British Airways are harsh when it comes to overweight bags.

In the end, I settled on three books to begin my collection:

The horizontal grid

The first book sports the classic Penguin cover design which first appeared in 1935. The design was created by Edward Young, who became the company’s first Production Manager. Young devised a system of colours to indicate subject matter - orange for fiction, green for crime, dark blue for biography, pink for travel and adventure and red for plays. These aspects of the design, as Baines points out, far outlasted this design.

<

p> Horizontal grid designed by Edward Young

Horizontal grid designed by Edward Young in 1935. A design classic.

I’m sure you’ll agree, the typography is indicative of the period and the use of Gill Sans, as I wrote a while ago, gives the Penguin books a quintasentially British feel.

It was a bonus that the shop happened to have a copy of ‘Of Mice and Men’, one of my favourite short stories.

Redesigned Pelicans

This book belonged, I think, to my wife’s grandfather (although it may be my mother-in-law’s), but in any case it’s a classic. Not only the subject, which if you live in Wales like myself, even today is a good start into understanding the rich culture of this nation, but the design is a classic.

<

p> Redesigned Pelicans, redesigned in 1949 by Jan Tschichold

Redesigned Pelican cover. Designed in 1949 by Jan Tschichold.

Begun in 1949 by Jan Tschichold, the cover design was a departure from the horizontal grid. As shown here the central panel was normally purely typographic, but sometimes there would be the odd woodcut illustration. For me, what defines these early Pelican books is the colour. The Teal, white and black colourway (although working under huge budget and technical constraints), work incredibly well and stand the test of time.

The Marber Grid, 1962

These are beautiful book covers, and apparently quite rare when compared to the other books. Maybe it’s something about Perth’s isolation which meant that these books were kept out of the hands of collectors, but I was lucky enough to pick a couple up (there were only about half a dozen of each in the shop compared to hundreds of the other designs).

<

p> Marber grid, designed by Romek Marber in 1962

I really couldn’t resist these. Beautiful grid design, typography and illustration. (Apologies for the flash)

The Marber grid was designed in 1962 by Romek Marber after being commissioned by Penguin. He went on to design over seventy covers.

The colourways devised by Young in the 40’s were retained by Marber (although slightly tweaked). Shown here is a green crime book and a blue biography.

The typography and grid are perhaps the most striking of these designs. Marber used Intertype Standard (a version of Akzidenz Grotesk) for all the typography as it offered more flexibility in terms of weights compared to typefaces such as Helvetica. The Swiss influence in the design in interesting. I feel, although they are beautiful covers, that the Penguin books of this time lost their ‘Britishness’. A move over to a more European design aesthetic would obviously help sales into the Eurpoean market. However, I can’t help feeling that some of the Penguin brand was lost in the translation.

The beginning of a rather sad hobby?

It would be very tempting to get more of these books. The design is simply stunning in most Penguin books from the early 40’s right through until the 70’s. I’d like more, but to be honest I just don’t have the room. Maybe I should clear out the shed.

Wikipedia and Bowing to the Brand

Wikipedia are having a design competition.

Whilst it doesn’t come as a complete shock that a site which offers free content is after free work, I’m still reeling from the opportunity that this presents to some designers, and recoiling from the effect this type of project has on the industry.

A while ago, I did some work for a Music TeleVision network. I’ve also done some work for some other pretty big brands in my time as a designer. The one thing that is pretty much constant with all of these big brands is an element of brand worship. You are expected to, as a supplier, bend over backwards in order to pander to their needs (because they’re big, right? And you need them much more than they need you). Now, a lot of you would say that’s the way we should all be for our clients right? Well, yes and no. For me, it comes down to respect.

A client should respect their supplier. In my day job, we commission design sometimes. Simply put, I wouldn’t commission an agency or individual who I didn’t respect and trust to get the job done. Common sense right? Well, yes, but in larger organisations, who might not have a designer on hand to assist in the commissioning process, this is where things start to break down and the cycle of miscommunication begins—usually ending the supplier being screwed down on price because half of the budget has been spent internally. Anyway, I digress.

Wikipedia, in my opinion, are doing a bad thing by holding a design competition.

Why? Well, Andy Standfield makes exactly the right point in the ‘discuss’ page for the Wikipedia competition. He says:

This is not, in fact, a “good idea.” Regardless of whether or not there is any prize or payment for such a “contest,” this is still spec work, and Wikimedia should not practice this kind of bad business. By running such a contest, you are devaluing the work professional designers do, and you are doing a disservice to yourself in that any proposal which comes from this kind of contest has no market or technical research behind it.

I would propose that, instead, Wikimedia ask designers to submit queries of interest. No actual designs or proposals should be submitted. Rather designers should be allowed to invite Wikimedia to view their portfolios and prices (or lack thereof).

In all actuality, what would really be best is for Wikimedia to simply go and look at designers’ portfolios and when they find someone they believe could do the deal, they should query them as to whether or not they’d be willing to do the work pro bono. You’d be surprised at how many professional designers would love to be able to work with you for free.

Please see the No!Spec website for more information on how this could possibly hurt Wikimedia and furthers damage to the design industry.

I totally agree. Yet, I feel drawn by the possibility of being involved in such a project. Back on goes my design ethics and business head and I agree again. I’m sure I’m not alone in feeling this way. Part of you wants to (usually your heart), part of you doesn’t (usually your head).

Kim Bruning replies:

Hmmm, Wikipedia is Open Content, so the “rules of the game” might be somewhat different from what you’re accustomed to. Would you care to comment on that?

Andy did comment:

I can’t really comment on it since I don’t really see how it pertains the subject. It’s spec no matter what the content or organizational structure is. It doesn’t matter if it’s a multimillion dollar international corporation, a two-person small business, or NPO (like the Wikimedia Foundation). The “rules of the game” are the same. Seriously, read through that No!Spec.com site. You might find it really interesting and enlightening.

Based on Kim’s answer, I’m very much inclined to agree with Andy. Open Content, I feel, is not a concept you can apply to design. Design is a process, not an end result. It’s not a ‘skin’, or a ‘theme’ or a pretty little logo made out of puzzle pieces.

Let’s say, for one moment, I submitted a couple of photoshop comps complete with logos, grids, colourways and typographic design. What is involved in just one visual.

<

p>

  • Thinking
  • Sketching
  • More thinking
  • More sketching
  • Working up logo ideas
  • Finalising and working up final logo
  • Applying logotype, with overall brand development, to a brand styleguide
  • Sketching up ideas for proposed screen
  • Applying brand guidelines
  • Many hours of tweaking (so, it’s just right)
  • etc.
  • etc.

Until you get to a design visual. Can you see what happened there? The design is not the end result, the design is process one took to arrive at a solution to the problems. There’s just so much in there to give away for nothing. Yeah, you may get your name up in lights, but at what cost?

Make no mistake, this project is a high profile big deal. But it’s also going to take ages.

But Wikipedia want a design, a free one, and they’ll get it because they are Wikipedia and you will bow to the brand and this will keep happening until designers, real ones, say NO to free work.

I still want a crack at it though. You see, there goes my heart again.

A bit of a realign

Maybe it’s something about spring or maybe it’s the 48 hours I spent on a plane recently, but I thought it was about time I spruced this site up. Actually, the main reason goes back to @media last year when Jeremy included in his presentation a javascript image gallery. It kind of spiralled, totally out of control, from there really.

There’s quite a few changes. I’ve gone for a wider, more flexible four column grid, which I use in more configurations than the previous site. Typography wise, I’ve ditched Helvetica in favour of a serif, in this case Georgia. There’s also a logotype. I hope you agree, more of an evolution from the previous design.

One thing I am excited about in this new design is actually the new piece in my portfolio: The International Baccalaureate Organization’s Online Curriculum Centre and Workshop Resource Centre. Bit of a mouthful, but this was a fantastic project to work on. From April to January last year, I worked with the IBO to produce web standards based templates for these great applications.

Anyway, after a couple of weeks being unable to post due to replication issues, it’s nice to be back!

Pimping my brother’s site

Just a quick post, now that he has more content up there, to pimp my younger brother’s site.

About six months ago, my younger brother Jon, left his job of six years with Norwich Union with a big fat pay off. So, he’s spending it travelling the world over the next twelve months. He asked me to get a little site together for him, mainly so he can chuck some photos up there and blog about his travels so all his mates can keep up.

It’s built in Expression Engine of course over the course of a couple of days and, yes, it’s black and white. Why? Well, why not - he seems to like it!

So, if you fancy, go and have a look. If you say hi, tell him I sent you!

Five Simple Steps to Typesetting on the web: Printing the web

The screen is just one of the media types for which we have to design for. Another media type, which I feel is often neglected as part of the design process for a web site, is print.

There are times when a web designer has to know about print design. Not just the values and aesthetics of designing for print, but the terminology, measurements and production values that are important in print design—including typesetting. I’ll be addressing these, along with a working examples over the course of the next three installments of this ‘Simple Steps’ series.

Print alternatives to web pages have been around for a while, we've all seen them, in one form or another. Usually, they are associated with a 'print version' button which upon clicking renders the page without any navigation and, if you're lucky, increases the font size. This is generally about it. Many sites offer this as functionality but I have to question whether users click this due to time constraints, or like me, they just print straight from their browser on the page they're on.

In which case they will get something like this (prints from Guardian Unlimited and The Times).

{title}{title}

There is a way, other than 'print only' versions, of rendering this content for a printer. Print stylesheets. Or more specifically, a CSS file, which has been authored for print media and declared as 'print' in the 'media' attribute of the link tag.

The last to be thought about

It's been my experience, over the past few years, that despite being a very clear need for users to print out web pages, very rarely are those needs addressed by designers. Why is that? Do we think that print is important in a screen based environment? Jason Santa Maria, Graphic Designer, had this to say when I asked about this recently:

Many people still see the web as a temporary medium, one that is always changing and where content is potentially irretrievable. I know many people who love to print things they find on sites, from articles to recipes to photos, to view when they are away from the computer or or for their own personal archive. There's no reason that information shouldn't either support your brand or be designed with the same care as your site.

Khoi Vinh, Design Director of the NYTimes, agreed with Jason:

Having developed Web solutions for many text-heavy publications in my career, at least one user scenario remains: people like to print long passages of screen-based text for reading offline.

This then begs the question, if printing from the web is so important for users, then why do we see print based templates either being left to the last minute, or being developed by technical teams, rather than designers? In addition to implementation though, what else influences the decision for ofefring a print alternative?

Khoi makes some valid points about revenue generation, through advertising, in the print versions:

Designers are focused on the immediate, knowable and sharable result of what gets rendered on the screen, so it's natural to consider print media stylesheets an afterthought. But other factors contribute to this too, notably the monetization of 'printer friendly' versions of articles at many publication sites.

That is, rather than offer a print-based set of CSS rules, many sites will offer an alternative screen rendering of the same article, slimmed down to just the primary text -- we've all seen this. Very often, those print-friendly views are sold to advertisers for sponsorship, so in those cases at least, there's a financial reason *not* to create a print media style sheet.

This is something that I hadn't really considered when researching this article. When Khoi mentioned this, it did get me thinking about how advertising would fit in with print CSS. I'll discuss this later on the series though.

Jason also raised some interesting points about the medium:

Because print stylesheets are perceived as somewhat non-essential to most site creators. Their main focus is their website and the appearance of it in various browsers. I think many people see print as a secondary medium, like mobile phones, that is optional. And I suppose it is a secondary medium, as far as the web is concerned, but there is very little preparation involved in producing some simple styles for print.

Perhaps there is an assumption that print styles can be added at a later date as they are deemed 'secondary'. This can be true, but on developing the example for this series I found that in developing a print style there was the need to revisit the code in the template to make sure the content flow was correct and additional design elements could be added. So, in that sense, I'm not sure that assumption is true.

So, that was a bit of context. Next, I'll get into the design of the printed page.

The Example

I wanted to frame this remaining set of articles with an example. A text-heavy site, with a strong on and off-line brand which could benefit from print styles. I chose the British newspaper, the Guardian.

Why? Well, The Guardian has an established website. The paper version was recently redesigned and now there is somewhat of a gap, visually, between the website and printed material. The first task was to design what the printed page from the website would look like.

Design the printed page

I feel the process of designing the printed content of a website is as important as designing for other media; screen readers, mobile and small screen. The design process is the same as designing for any other media. You have to understand the context, the production and the delivery.

Luckily I chose an example with a very strong offline design on which to draw inspiration. I began by researching The Guardian's redesign and analysing the components which make it up; the grid, typography, colour and composition.

{title}

I chose a typical page layout, which included running heads, article headline, date, author etc. All the content which would go into the online version.

It was clear from this example which areas of the design I would need to replicate to ensure a quality reproduction for the print styles. I then began to shape up the design.

Shaping the page

I begin most design tasks by drawing thumbnails. This one was no different.

{title}

As you can see, I there were some important considerations I wanted to address even at this early stage. Width of the Measure is an important consideration for printing on an average desktop printer. I opted for a full width measure. Although this may hinder legibility due to the long line length, I feel this is acceptable considering the potential savings on paper and toner if the measure was narrower.

From this quick sketch, I worked up a larger, full-size, sketch to get an idea of proportion of type areas, rules and white space.

{title}

Working at this full size, in pen and paper, gives an immediate idea of the scale of the elements on the page. I really would recommend this for when you design print alternatives for your web sites. Draw it out on paper first. It's quick and will save you a lot of time in the long run.

Digitising and colour

I then took the sketch and worked it up in Photoshop (you could use InDesign or Illustrator if you like) to use the typeface I wanted and add colour.

{title}

Working at this full size, and then printing it out, gave me a template on which to base my CSS measurements. Remember, with the printed page we are dealing with absolutes again. You can define type size, leading and measurements which all exist in a finite space: a piece of paper.

I found that completing this stage of the process really helped in pulling the styles together later on.

The finished article

I'll skip ahead a bit and show you the finished article.

{title}

This shows the finished printed article page shown next to a open spread of the paper. As you can see, it shows a continuation of the brand and the content is presented clearly and legibly.

The Example

In the next two parts of this series I will be discussing the typography and colour, and creating the print media css files. For those of you who can't wait until then to see the example, here it is.

SXSW: Traditional Design and New Technology

{title}Three weeks today, I'll be landing in Austin, Texas for SXSW. I cannot tell you how excited I am about going to this event again.

Two years ago, A collegue and I attended to what I thought was just going to be another industry do. How wrong I was. The inspiration fuelled my creativity and design direction for about six months. Little did I know then that in two years time I would be sitting on one of the panels. Nervous? Me?

A star-studded panel

I'll be sharing the big, long table at the front with some very distinguished designers:

As you can see, quite a list. I'm utterly in awe of some of the work these guys produce so it's going to be fantastic to sit up there and have a discussion with them on a topic I hold so dearly. It will be passionate for sure.

So, what are we going to be talking about?

Traditional Design and New Technology

{title}I'm not going to give much away (or what would be the point coming?). I will say that I believe it will be quite a different panel in terms of the content matter; not the usual SXSW material. It's going to appeal to designers and developers alike and If you're a project manager, then no worries, I'm sure you'll enjoy it too.

Get there early

Now here's the thing, and partly the reason for this post, get there early.

Our panel starts at 10am on Saturday. That's right, we're pretty much first up. So, no excuses. Jetlag, hangovers, no sleep, too much dodgy mexican food the previous night; they're all weak excuses.

Once you finished with our panel, at 11.30am is our very own (I'm talking in terms of the Britpack and the UK here) Andy Budd and Andy Clark with their, bound to be superb, panel; How to Be A Web Design Superhero.

Five Simple Steps to Typesetting on the web: Dashes

{title}In this installment I'll be talking about three dashes which are often used, but frequently misused. The Hyphen, the En Dash and the Em Dash.

The Hyphen

{title}The Hyphen, or the 'hyphen-minus', is what you get when you press the key next to zero (standard qwerty keyboard, well mine anyway, for all those pedants out there). It's the shortest of the three and is often used incorrectly, I'll look at the most common correct uses of the hyphen first before moving on to the dashes it is often used, incorrectly, to replace.

There are two types of Hyphen: The 'soft' hyphen and the 'hard' hyphen. Sometimes they are different lengths, but this depends on the typeface.

Hard hyphen.

The hard hyphen joins two words together anywhere they are positioned on the same line. For example, 'run-of-the-mill'. It's set closed up (which means no space either side).

Soft hyphen.

The soft hyphen indicates where a word has been split at the end of a line. Arguably, there's very little use for the soft hyphen on the web when the user has so much control over the presentation of the type.

There are many grammatical rules associated with hyphens, which differ greatly from language to language. For British typesetting, and the English Language, I'd recommend getting yourself a copy of the Oxford Guide to Style (the old Hart's Rules).

The En Dash or En Rule

{title}The en dash is one en in length. It's slightly longer than a hyphen and half the width of an em dash. Em and en are typographic measures based on point size. An em is a equal to the size of the set type (eg. 12pt) and an en is half that.

  1. An en dash is used closed up in-between elements that show a range. Eg. Monday–Sunday, 1985–2005. It is also used when the end element is not known: Joe Bloggs (1984–)*.
  2. The en dash can be used to show the meaning of to and from. Eg. on–off switch.
  3. The en dash can also be used to join compound adjectives which include multiple words or hyphens already. In this case the en dash clarifies what is grouped with what. Eg. high–priority–high–pressure tasks.
  4. In Unicode, the en dash is U+2013 (decimal 8211). In HTML, the numeric forms are – and –. The HTML entity is –

The Em Dash or Em Rule

{title}The em dash, as it's name suggests, is one em in width. The em dash is perhaps the character that has suffered most over recent years. Frequently replaced by the hyphen, or the that relic from typewriter days, the double hyphen ( -- )**, I think it's about time we give this little fella the time of day.

Once again, there are differing grammatical usages depending on language. In British and North American typesetting there are a few simple rules:

  1. Use the em dash closed up in written dialogue to indicate an interruption. Eg. 'What a load of—', but his words were lost on her.
  2. It can also be used either side of an interruption—like this one—and is set closed up.
  3. In Unicode, the em dash is U+2014 (decimal 8212). In HTML, the numeric forms are — and —. The HTML entity is —.

It's worth noting that em dash usage is inconsistent, not only across languages, but also across house styles. The most common replacements are an en dash and the hyphen, both set with a space (or a hair space) either side.

* It's common practice in North American typesetting to use an em dash for this purpose.

** The usage of this is of course valid on a typewriter where, as with most monospaced fonts, the hyphens, em and en dashes all are similar length.

I want to thank Phil Wright for his help on this article. The man knows his type.

The next steps

When does print design matter on the web? When you use a print stylesheet of course. The next three articles will document production of a print stylesheet from a print design perspective.

Grid, measure, type size and leading, orphans and widows. The lot.

What makes a good business card?

I've just been asked this question by a client and I'm not so sure my answer was right.

I said, 'A good business card identifies a person with a product, brand (and/or) company and gives the contact details for that person.' I didn't mention creativity or design. Should I have done?

I know it completely depends on the person and the context of the job, however, I started thinking about business cards and where they fit in the scheme of Corporate Identity design and they are difficult things to design if you want to challenge the conventions. But, should you challenge the conventions?

I dunno, what do you think? Any examples of what you think is a good card?

Typeface of the month: Gill Sans

Gill Sans lower case g'Gill Sans, is he mad?', I hear you cry.

Well, Gill Sans - as well as Helvetica - are perhaps the two typefaces I use the most. I have a love / hate relationship with them both, or rather with particular weights of both, but they are two typefaces which continue to surprise me with their beauty and versatility.

As we're all probably aware Gill Sans is a pretty standard font these days, used and abused as a result of being part of a default font installation on certain operating systems. Like Times New Roman, a lot of people have become tired of its expressive curves (yes, that's right, I did say 'expressive'). I'm hoping after reading this, at the very least, you'll look upon Gill Sans with fresh eyes.

A bit of history

Image showing Monotype's orginal poster for Gill SansGill Sans was designed by Eric Gill in the 1920's and issued by Monotype in 1928 to 1930. Eric Gill studied under the calligrapher and stonemason, Edward Johnston, at the Central School in London so therefore it comes as no surprise that Gill Sans is based on his teachers typeface for London Underground, Johnston Underground.

Due to it's legibility and its 'Britishness', Gill Sans has been adopted by many companies and organisations as their corporate typeface. Notable mentions are:

  • BBC
  • Royal Society of Arts
  • The Church of England
  • Network Rail

Not to mention the number of companies who have had typefaces designed which have been heavily influenced by Gill Sans.

The typeface itself and that horrible 'a'

Gill Sans is a beautifully designed typeface which, unfortunately, has suffered at the hands of software, and to a certain extent, its own popularity.

Image showing Gill Sans' basic alphabet

Gill Sans lower case aThe characters are hard, sculptured forms which clearly show Gill's education and artistic roots. There's the legibility of a serif face, balanced with the authority of a sans-serif. Gill Sans can seem friendly in its lighter weights, making it perfect for body text, and with its rounded letter forms and limited adornments, it's highly legible. The bolder weights are perfect for display or signage purposes, but then there's that 'a'.

If there's one thing about Gill Sans that puts me off is the lower case 'a'. Just look at it. Top heavy, unbalanced and well, just weird looking.

Live with Gill Sans for one year

Early on in my college days, when I knew nowt, one of my typography lecturers was having a bit of a rant about typefaces. His main gripe was that with so many fonts at our disposal, designers and especially students, are like kids in a candy store and generally, he said, it was to the detriment to the design.

'Learn to live with a typeface for one or two years, try to use nothing else but that face'. You can imagine the looks on our faces. However, due to corporate branding guidelines for the past three years I've been in that position in my day job. It was pretty tough to begin with, coming from a commerical company who specialised in branding with a 'new brand, different typeface this time' approach. Now, however, I sometimes struggle to use different typefaces when faces like Gill Sans and Helvetica answer the design problems so elegantly.

To wrap up. Classic typeface - overused and misunderstood - but next time you need to design a form, signage, or need to communicate something which is quintasentially British, then spare a thought for Gill Sans. 7 out of 10. (it would be 8, but that 'a'...)

Semantic Typography: Bridging the XHTML gap

In the Web Standards community we hear the words 'Semantic Markup' thrown around a lot as a concept—the right thing to do— but I know a lot of designers who are trying to learn this stuff are being confused by the whole 'semantic thing'.

It's a difficult task for a designer, who primarily thinks very visually, to relate to a concept like semantics in a document when all they want to do is create something.

After doing a ton of research over the past couple of weeks I've begun to notice links and patterns between typographic theory and Web Standards.

I'm going to keep this quite brief and hopefully practical from a design and development point of view.

First of all, I'll explain some of my thinking.

Typographic structure

In most documents there is a typographic structure and a hiearchy of elements, from letters up to chapters. Here's a list, which is by no means complete, that explains what I'm on about:

  • Words → Sentences
  • Sentences → Paragraphs
  • Paragraphs → Sections
  • Sections → Chapters
  • Chapters → Document

You could of course go more granular than this, but I think it illustrates the point.

From this you can see how, by looking closely at the content, that the language can be broken up into chunks, into bits of semantically functional elements. So, you could argue that:

  1. Documents have a conceptual structure
  2. Graphic structures can be made that reflect conceptual structures

This perhaps the key to successful typographic design. Making sure the graphical representation of the content matches the mental model of the reader, or conceptual structure stipulated by the author (or preferably both).

Bridging the XHTML gap

As I mentioned earlier, designers often struggle (in all the Web Standards malarkey) to make the connection between their design, the content and then the code. The code bit seems very abstract initially. Hopefully this next stage will help explain how the gap can be bridged painlessly.

We have our model for matching the semantics, or meaning, of our document to the design we create:

  1. Documents have a conceptual structure
  2. Graphic structures can be made that reflect conceptual structures

Now, add to that our step for XHTML:

  1. Documents have a conceptual structure
  2. Graphic structures can be made that reflect conceptual structures
  3. XHTML structures can be made that reflect conceptual structures

So:

The graphic and XHTML structure of a document should reflect its conceptual structure.

Therefore our finished web page will:

  1. Be presented, typographically, to match the document's conceptual model
  2. The XHTML underlying the web page will also match the conceptual model
  3. The meaning, or semantics, of the web page will match that intended by the original document.

For the visually oriented amongst us...

I'm going to put this into pictures to help explain what I'm on about. If anything it might help me firm up this theory a bit.

So, let's put this in the realms of reality. Let's say you have a brief from a client, who happens to be an estate agent, to build a web site for him. Most of the content for that site will be house details. Currently he produces single sided documents with the house specs on and he wants you to build the bulk of the website using this information.

So, here's the house details:

{title}

As you can see, there's very little visual design been done to this document. The first task then is to establish the document's conceptual structure, its semantic elements, from there we can identify our typographic structure.

{title}

Once that is done, forgetting the design for the moment, we can (again, using the documents conceptual structure), label those elements with their corresponding XHTML tags.

{title}

The document conceptual structure is retained, we now have our XHTML structure (our semantic markup). Focussing then on the design we can make the typographic structure match the conceptual structure (still retaining our XHTML structure)

{title}

And there we have it. A typographic design, which has been tagged up with semantic XHTML, which retains the author's conceptual structure.

The benefits

The benefits of going through the process in this manner is that it's from a designer's perspective, there's less of a leap conceptually into the land of code where document structures are common place (OOP etc.) I've been following this model for a couple of weeks now and it works pretty well. It streamlines the process of assigning heading tags for example which have always been quite arbitrary in the past.

For those designers who are coming from a multi-disciplinary, or print, background and have trouble with this whole 'semantic markup' thing, please give this a go and let me know what you think. In fact designers who have been doing Web Standards for a while please give this a go and let me know how you get on with it. I'd be interested in knowing your thoughts.

Carson Workshops - CSS for Designers

Here I am, sat on a train, stuffed full of Sushi awaiting the train to finally pull away so I can start my long trip home (about four hours depending on which signal's decide to fail). After buying my 12inch iBook in July, this is the first time I've used it in a truly mobile capacity and so far it's going well. Anyway, I'm not going to go about sushi, trains or laptops in this post. Today, I had the great pleasure of attending the 'CSS for Designers' workshop hosted by Carson Workshops in London. What a day it was.

I've sat here for a good ten minutes now thinking where to start on describing today, so I'll just start at the beginning.

Carson workshops

Carson Workshops is a UK based company doing really great things. Ryan and Gillian's combined talents are managing to get the most talented and inspirational speakers from around the world over to the UK, as well as events in the States, to give day long workshops to the industry.

Like a lot of web professionals (do I fall within the bracket Andy? Molly? I'd like to think so :)), I try to attend as many conferences as I can in the web industry, such as @media, SXSW, unfortunately I couldn't make it to dConstruct, but I was there in spirit. These conferences are generally very good. The wide variety of speakers give informed presentations on a plethora of material. However, these panels and presentations rarely last more than an hour, and from my experience, there's only so much you can gain from them. Workshops, such as the one attended today, are a very different beast all together.

The Workshop

Today's workshop - CSS for Designers - had Molly Holzschlag and and our very own Andy Clarke at the helm.

I've met Andy before in person, very briefly, at @media in London in June and found his presentation very inspirational from a designer's perspective. Andy talks the same language as me. Japanese. No, seriously, Andy's design talents are but the tip of a Web Standards trifle. I mean, Iceburg. The guy just really, really knows his stuff. Not only all the creative design stuff, but also how to implement it using web standards. The most important thing, however, is Andy can explain this stuff in a language designers can understand. No mean feat. The same can be said about his co-presenter, Molly.

It was great to finally meet Molly. If there's one person in the web industry who embodies the passion that first got me interested in this medium, then that's Molly. The thing that got me about Molly, as she was presenting throughout the day, was the incredible depth of her knowledge. Like Andy, she really, really knows her stuff but in a slightly different way, from a different background. The two of them working together throughout a whole day worked very well indeed. A great double act. Not quite Morecombe and Wise though, more like Cannon and Ball :)

Ok, that's enough back-slapping (the troll's will be queueing up otherwise). What I'm getting at is, if you get the change to go to a workshop like this or listen to either of these guys speak, then do it.

As I was saying earlier, a workshop format is very different from a conference. In a conference format you only get a snapshot of the presenter's work, on a subject they choose, in a format and structure which may not be totally up to them. How much can you really gain from this format in practical terms? Yes, they're great for inspiration, for steering you in the right direction, but generally they lack specific detail and the opportunity to ask very specific questions in the context of a project you may be working on. The workshop format changes all of this.

This was a full day workshop, from 9am until 6pm with reasonable breaks for lunch and coffee. So, it was a long day to sit in front of a projector and listen to two people talk about the same subject. Or so you may think. In reality, it wasn't like this at all. With some nicely designed slides, a user-friendly agenda (meaning it wasn't all design in the morning and theory in the afternoon) and regular swapping over by Molly and Andy it made the day go really quickly.

When I first arrived, Molly and Andy both expressed a concern to me that I'd know a lot of stuff that they'd go through throughout the day. This was not the case at all. Regardless of your experience level, you should consider attending one of this workshops. I learnt tons of stuff that I'd either skimmed over, couldn't be bothered learning fully, or got by by other means. One of these examples was Molly's examples of Relative and Absolute positioning. I'd sort of understood them for a while, but never used them because I'd always used floats. During the presentation a little light bulb went on in my head. 'Hello there', I said, 'Now I get it. This looks really cool!'. In fact, that happened quite a few times throughout the day.

The personal highlight for me was when Andy was presenting a section and grid design and a slide of my site appeared. Well, if he hadn't of forwarned me, you could've knocked me down with a feather. He even made me stand up, which was nice. I like to think I took this five minutes of fame in my stride to a rather bemused audience who, not surprisingly, had never heard of me.

A fun day had by all

If there's one thing to be said about today's workshop is that it was enlightening, both in terms of day's presentations, but also in the pub afterwards (which is where most of the really useful stuff is normall discussed). Thank you to Ryan and Gillian for hosting a fantastic day. It was great to meet some new people, finally meet Molly and have more than five minutes to talk with Andy. Interesting to note how many people from the BBC were there also. Are we to expect big CSS things from the BBC designers in the future? Well, just maybe.

Well, that's killed an hour. Right I'm off to the buffet car. Stella anyone?

Gerry McGovern’s clear lack of understanding

Just spotted this via my feeds — Graphic design plays a minor role on the Web.

Red rag to a bull mate.

As much as I'd like to let this one go, I just can't.

Gerry McGovern is apparently:

widely regarded as the number one worldwide authority on managing web content as a business asset.

Ok. Shame that someone with this amount of apparent industry clout embarrasses himself with a truly naive observation. I honestly don't know where to start.

Most of Gerry's post sems to be slagging off the Communication Arts Magazine awards, which has to be said, don't really feature a lot of good graphic design for the web. They feature a lot of good graphic design, which doesn't work well on the web, which is what I think Gerry is trying to say.

This is just priceless:

..Nobody would ever be allowed design road sign navigation that moved. However, when you design moving web navigation you win design awards. Why are so many graphic design experts still clueless about the Web after all these years?

He follows it up with this:

... If the Communication Arts Magazine awards were a parody, they would definitely be deserving of some sort of prize or award. But they?re not, and they do a huge disservice to a discipline they purport to promote.

There are young web designers out there being sent absolutely the wrong message. The Web is, at heart, a task-focused, functional place. If you want cutting edge web design, look at Google, Skype, EBay, Amazon. These websites make money by meeting real needs.

Your website must be useful. It must be fast and convenient, with a navigation that is familiar and simple. The Web is not a brochure, an annual report, or a TV ad. It?s the Web.

I'd like to pull Gerry up on a few things there though. Firstly, 'The Web is, at heart, a task-focused, functional place.'. True. However, promoting functionality at the expense of aesthetics and user experience is just plain silly. The two are linked Gerry, whether you like it or not. User experience is vitaly important to companies such as Nike. Without their brand, Nike are pretty much dead in the water, like most companies in a highly competitive market it's what defines them. Now, I'm not excusing Nike's website and it's lack of usability, but this kind of website can be achieved — accessible, usable, functional — and still deliver the user and brand experience.

Please Gerry, don't assume all Graphic Designers are exclusively concerned with the aesthetic. We're not. Some of us understand what design really is.

Emigr? calls it a day

{title}This morning I received some sad news in my Inbox. After 21 years of being published, Emigr? magazine is finally calling it a day.

I don't really know where to begin when describing the effect Emigr? has on my path to become a designer. I'm sure I speak for a lot of designers when I say Emigr? deeply influenced my work throughout university - Not just in terms of how the magazine was designed, and the beautiful typography, but by the articles themselves.

Emigr? has attracted, over the years, some influential and intelligent contributors. It is these people, through this medium, that are challenging design at a fundamental level. Now that's gone, what's left?

Well, there's Eye, which is ok, although I've always felt that Emigr? had a broader editorial remit and therefore actually made it less of an industry journal and more of, well, a good read. Being a member, I also recieve the International Society of Typographic Designers journal, TypoGraphic, every quarter or so. Typographic is a bloody good read, especially focussing on the craft side of typographic design. It can be a little old skool at times, but if you get the chance, pick a copy up and judge for yourself.

So, there we have it, damn shame if you ask me. Better snap up those back issues quick. Where's my credit card....

Icons, Symbols and a Semiotic Web

{title}Semiotics, loosly speaking, is the study of signs. Simple enough. What becomes difficult is defining what a 'sign' actually is.

When we think of signs we think of the things on the left there don't we? We think of something visual like a signpost. But, 'signs' are made up of many different components - words, sounds, body language and context - all of which combine to create a visual language which help us understand something, be that the way to the beach, or if somebody doesn't really like us the first time we meet them.

What this article isn't about

This article is not about semiotics. I'm not going to go into great depth about it as it is such an indepth field I've barely scratched the surface over the past few months. What I am going to talk about is the usage of semiotics in Information Architecture, Wayfinding and Icon design for the web. It's a big subject so this will probably be an introduction to something I will cover in more depth in a chapter of a book I'm currently writing (more about that another later).

Starting at the beginning

We've established that semiotics is the study of signs, and signs can be made up of all sorts of stuff like language, pictures, body language etc. but what does all this mean in a practical sense? Well, it might help to give you a brief overview of the field of semiotics, then go into some of the theories that help make up it's core.

Modern day Semioticians, not only study 'signs' - it goes much deeper than that - they study how meaning is formed. They study how people first of all interprate a sign, how they then draw on cultural or personal experience to understand a sign. In that sense semiotics is about communication (see the parallels with design?).

There are three main areas of semiotics; the signs themselves, the way they are organised into systems and the context in which they appear.

We'll have a look at the first of these in this article.

The Signs themselves

Charles Sanders Peirce is an American philosopher recognised as the founder of modern semiotics. Peirce was interested in how we make sense of the world around us and in this sense was less concerned with the linguistic aspect of semiotics pioneered in the early 1900's by the Swiss professor of linguistics, Ferdinand de Saussure.

Peirce proposed that signs could be defined as three categories; Icon, Index and Symbol.

  1. {title}Icon - An Icon sign is a sign that resembles something, such as photographs of people. An icon can also be illustrative or diagrammatic, for example a 'no-smoking' sign.
  2. {title}Index - An Index signs is a sign where there is a direct link between the sign and the object. The majority of traffic signs are Index signs as they represent information which relates to a location (eg, a 'slippery road surface' sign placed on a road which is prone to flooding)
  3. {title}Symbols -
  4. A symbol has no logical meaning between it and the object. Unfortunately the web is littered with bad examples of this type of sign, but there are good one's - a homepage icon which is a house for example. Other off screen symbols which may help explain the difference are flags. Flags are symbols which represent countries or organisations. Again, the crossover to design and branding is very evident in these signs.

Saussure however proposed a simpler structure of what a sign is:

  1. a 'signifier' (signifiant) - the form which the sign takes; and
  2. the 'signified' (signifi?) - the concept it represents.

For Saussure, a sign is the combination of the two. But, what does this all mean in terms of the web?

Semiotics and the web

The web is full of signs. Think about it.

Most users want to accomblish a task on a website, in order to do that they have to navigate to the right place. In order to do that, they have to follow signs. See?

Not only visual signs either. Let's consider Information Architecture for a moment.

IA is a field of web development concerned with the organisation of information. I once had a good IA friend of mine describe to me what got her excited about her job. 'I make lists', she said with a big smile. 'Then', she continued, 'I make lists within lists'. Sounds thrilling doesn't it? We went on to discuss words and how they effect what she does.

'Words matter', she said. 'Probably more than anything. You can have a bad design, but if the words are right and in the right place, the user will generally find what they need.'

The conclusion from this conversation was that words are also signs on the web. The right word in the right place - isn't that what navigation is all about? Context. Let's move now into something a little more visual.

Let's take the example of designing an icon system for an online application. The parallels to software design are obvious - well designed GUI's have pretty good icons, or should I say signs. So what should you do to make these icons understood by the user?

Here's my top three:

  1. Be conspicuous - Be bold.
  2. Leave 'creativity' to the bad designers - This is not the place to do something different. If a convention exists, use it.
  3. Location, location - Be in the right place.

There are more, but that's my top three to creating successful signage (don't forget that icons on the web are signage and when designing them you are designing a signage system, like it or not.

So, what about signage systems?

Well, I'm not going to get into that for this article (you'll have to wait for the book for that one). Signage systems are as important as the individual signs. Collective meaning and overall association are the elements that make signage systems work (next time you're in an airport, have a look at the signage system!)

One last thing...

Be sure to check back over the next couple of months for updates on the book, which will include a chapter on semiotics and icon design. It'll probably be self-published initially (with a pdf download and options to buy a bound full-colour book) and be available here for a modest sum. Oh, and it's a got a working title of 'Five Simple Steps on Design'. That should give you an idea of what it's about :)

Turning the corner: Designing for Web 2.0

I've been thinking about this for a while now. What will it mean to design in this industry in the coming years, and how will we, as designers, have to adapt in order to get the most out of it?

But before I talk about that, I'd like to talk about design. What is it? More importantly what has it become? And how will it be in the future?

So, What is it? A brief history.

For many years now, design has been viewed as being aesthetic. Design equals How Something Looks. You see this attitude to design in every part of society - clothing design to interior design, less so in product design, and yes, in web design.

Years ago, when I was a lad.... No, seriously. Years ago, when the web first went mainstream we saw designers move to it from a number of industries - architecture, print design and multimedia (cd-rom and kiosk) design. They all brought with them a way of working which was almost exclusively associated with the aesthetic. Designing nice looking stuff for the web.

Then along came the people from HCI backgrounds and the social sciences and said 'Hang on a minute, whilst these website's look nice, they aren't very usable', and so was born the whole usability thing.

At about the same time, businesses realised that their sites were becoming a bit of a mess. So, they asked some people from library sciences to come along and join the party and Information Architecture was born.

So, we had Designers making things look nice, Usability experts arguing with the Designers about links must be blue and Information Architects sitting quietly making lists.

Thankfully that is, mostly, in the past.

What has it become?

After that splintering of the design profession (I'll come back to this), we ended up with a faceted industry. By that I mean, lot's of highly specialised fields. At the time of the big crash, the industry could not sustain so many experts and we had to multi-task. all of a sudden if you wanted to get by the web you had to know PHP, Javascipt, IA, Flash, be a cracking designer as well as a first rate Information Architect. Oh, and you had to be pretty good at making tea too.

That was still the case up until a few months ago. And I guess this is the whole point to this post. We are on the cusp of something here. I can smell it.

How will it be in the future?

Web 2.0 is all the thing at the moment. Silly, silly name if you ask me. And no, I'm not going to explain it because I don't really know myself. I think Web 2.0 represents a change, that's all. Not only a change in the way the internet works, and is driven, and interacted with, but a change in the industry itself.

I believe there will be a return to design no longer being associated with just the asthetic. If you've read this site before, you probably know what I think about design. I think design covers so much more than the aesthetic. Design is fundamentally more. Design is usability. It is Information Architecture. It is Accessibility. This is all design.

A few years ago, when there were silly job titles around, designer's also fell into that trap of trying to differenciate themselves from 'those designers who just make things look nice'. We had 'User Experience Designer', 'Usability Designer', 'VP of UI' - you know, silly things like that. Now, I call myself a 'Designer '- plain and simple - and thankfully I'm beginning to think the industry, clients included, are beginning to understand what I'm talking about.

Designers in the coming years, I feel, will have to embrace aspects of design that have long been pushed aside by the, rather bullish, aesthetic. We need to embrace problem solving, not just visual problems either. We need to embrace the history of design - the craft of design - in order to understand the rules behind the aesthtic stuff we've been doing all these years. When we do, we'll find that these rules have been based on solving problems - not on how things look, but how they work.

Designing for Web 2.0 will not be about technology for designers. No? No, it will be about people. It will be about designing stuff that people use and all that goes along with it. It will be simpler, better and more rewarding for designers but only if we let go of the aesthetic and grab hold of the other stuff.

Ok. Don't say I didn't warn you ...

Five simple steps to designing grid systems - Part 5

It's been a while, but this is the final part in my series 'Five Simple Steps to designing Grid Systems'.

Flexible vs Fixed. Which one to choose? Why choose one over the other? Well you won't find the answers to those questions here. What I'm aiming to do with this article is to investigate how the theory of grid design can be applied to a flexible web page.

Lets's start by briefly examining Fixed and Flexible, or Fluid designs.

They both have their merits.

Fixed width designs are, well, just easier to produce. The designer has control over the measure, and therefore the legibility (until the user increases or decreases the font size that is).

Flexible width designs scale to the user's resolution, and therefore the browser window. There is less empty space, typically at the side of fixed width designs.

However, they both also have the down sides such as fixed layouts generally scale badly and flexible layouts tend to look very wide and short. But, this article is not about the good and the bad and it's not really the place for that type of discussion, that argument is going on elsewhere and will continue to do so for quite some time.

Flexible grids

As discussed the first few parts of this series, grid system design deals in fixed measurements - the media size, the type size and ultimately the grid size. They are all fixed. So, along comes the Web and challenges theory which has been around for generations. All of a sudden the reader can resize the media, they can change the font size, they can do all this stuff that designers didn't have to think about before. Designers have had to adapt, both to the technology and to the opportunities that media offers.

I've been giving flexible width a lot of thought over the past few weeks in preparation for writing this article. I can see the merits in both, but I've been trying to base my recent thought within the realms of purest grid theory. How does that theory translate to flexible grid design? and I think the answer is, quite well actually.

Adaptive Grid Systems

Ideally grid systems should be designed around the type size. Column widths, and therefore the Measure, should be constructed in such a way to maximise legibility based on the number of characters (you can read more about that in my Five Simple Steps to Better Typography). This is all fine if the units of measurements are fixed, but what if they can change? But what does that mean?

  1. The user can change the font size
  2. The user can resize the browser window
  3. The user can change their resolution

The user can of course do this with all design, fixed or flexible, but the key to flexible grid systems is the grid must adapt to those changes. After a bit of thought I think the key components of an adaptive grid are:

  1. The grid elements adapt to the user's changes, and
  2. The grid must retain it's orginal proportions

I've never been comfortable with the desciptions of flexible grids - flexible, elastic etc. What I'm trying to convey with Adaptive Grid Systems or Adaptive Layouts is the thought process behind the grid design which reacts to the user's choices. I think it appeals to the purist in me! ;)

It's a question of ratios. Again.

In the first two parts of this series, I talked about ratios, both rational and irrational, in the construction of grid system design. But, for those who haven't read them, or have forgotten, here's a quick overview.

Grid systems can be constructed from ratios. Simple ratios such as 1:3, or 2:1 are called rational ratios. More complex ratios, such as those based on the Golden Section (1: 1.618) , are called irrational ratios.

Ratios are just the job for constructing adaptive grid systems because they are independent of any unit of measurement. They are just a ratio to the whole, whatever the whole may be. This whole, be a browser window or whatever, can change and therefore so does the ratio or the grid.

Let me put this into practice now with a working grid.

Divine measurements

If you've been following these articles, you should know by now that I like to start simple. Following on from several articles I've written about the golden section, I'll continue with that and construct this adaptive grid using the Golden Section which is an irrational ratio - 1:1.618.

So first off we construct a simple two column grid system with the content areas being defined by the Golden Section ratio.

{title}

Getting the right units

In order for a grid to be adaptive, we have to use scalable units of measurement such as 100% or Ems. Just a reminder: An Em (pronounced 'm' NOT 'e, m') is a typographic measurement equal to the point size of the typeface you are using. We also use percentages.

To give us our column width I convert the ratio's to percentages, which gives us 61.8% for the main column and 38.2% for the right column.

{title}

That's our grid as determined by percentages. Pretty easy really. Now, on to the implementation.

Constructing the grid in CSS

Before I move headlong into implementing this using CSS, I just wanted to point out that this tutorial is about grid design and not about web standards. XHTML and CSS just happens to be the tools I use to realise this design. You can of course use tables if you want (but you'd be wrong!). Oh, and I'm just not clever enough to stuff this example full of hacks for IE this, Mac that, weird linux browser version 0.6.1 etc. etc. This example is a Best Case Scenario example. If you want to add all that stuff to it, let me know and I'll add it. Like I said, it's the grid that interests me. Disclaimer over.

Oh, and there's a small change to the percentages of the columns to get round some browser bug or another, it's basically a couple of percentage smaller so the floats work correctly.

For those who can't be bothered going through this code, here's the example.

Here's the CSS, including all the global stuff such as links, typographic stuff and general body stuff which is applied to a pretty basic XHTML structure.

body {
margin: 0 auto;
padding: 0;
font-family: "Lucida Grande", verdana, arial,
helvetica, sans-serif;
font-size: 62.5%;
color: #333;
background-color: #f0f0f0;
text-align: center;
}

* {
padding: 0;
margin: 0;
}

/* Make sure the table cells show the right font */
td { font-family: "Lucida Grande", verdana, arial,
helvetica, sans-serif; }

/*--------------------------------------
GLOBALS & GENERAL CASES
---------------------------------------*/

a {text-decoration: underline; padding: 1px; }
a:link { color: #03c; }
a:visited { color: #03c; }
a:hover { color: #fff; background-color: #30c;
text-decoration: none; }


/*--------------------------------------
TYPOGRAPHY
---------------------------------------*/
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, arial, verdana, sans-serif;
font-weight: normal;
}

/* approx 21px*/
h1 {
font-size: 2.1em;
margin-top: 2em;
}

/* approx 16px*/
h2 {
font-size: 1.6em;
margin-bottom: 1em;
}

/* approx 14px*/
h3 {
font-size: 1.4em;
}

/* approx 12px*/
h4 {
font-size: 1.2em;
}

/* approx 11/14 */
p {
font-size: 1.1em;
line-height: 1.4em;
padding: 0;
margin-bottom: 1em;
}

I then add the page structure css.

The columns are wrapped with a container div (called 'container'), this is defined as being 90% wide, with a minimum width of 84 em. What's that about? Well I got that number by doing this.

As mentioned earlier, our ideal minimum width for the measure is 52 em. This is the width of our main column and as determined by the Golden Section, the overall column widths combined is 1.62 multiplied by 52 em, which is 84 em. The right column is therefore 84 em minus 52 em, which is 32 em. Converting these to percentages gives us 62% and 38%, which is what you use in the CSS for each column.

There is also a minimum width of 84 em applied to the overall container, which when the user resizes the text, maintains the ratios.

Here's the CSS for the columns:

#container {
width:90%;
margin:0 auto;
text-align: left;
min-width: 84em;
}

#contentframe {
margin: 2em 0 0 0;
padding: 2em 0;
width: 100%;
text-align: left;
float: left;
border: 1px solid #ccc;
background-color: #fff;
}

/* 2 column layout c1-c1-c2 */
.c1-c2 #c2 {
float: right;
width: 36.2%;
padding: 0 0 0 1em;
margin: 0;
}

.c1-c2 #c1 {
float: left;
width: 61.8%;
padding: 0 0 0 1em;
margin: 0;
}

So, there we have it. An Adaptive Grid System based on the Golden Section.

Please feel free to abuse the hell out of this layout. Push it, stretch it, batter it into submission. Please let me know though what your findings are. Are Adaptive Layouts the way forward in flexible grid design for the web. Like I said, I'm interested in the grid, not necessarily in the implementation.

That wraps up another series

Well, there we are. Another series finished with. Hope you liked it, and thanks for all the comments and feedback. I've got a feeling this one's going to be interesting...

This is the fifth, and final, installment of this "Simple Steps..." series.

  1. Subdividing ratios
  2. Ratios and complex grid systems
  3. Grid systems for web design: Part 1
  4. Grid systems for web design: Part 2 Fixed
  5. Grid systems for web design: Part 3 Fluid

Guidelines

Have you ever worked on producing branding guidelines?

I've always felt branding guidelines are too formulaic. Dont do this with the logo, use these colours and this typography. This isn't really branding, it's implementation guidelines for elements of the brand, not the brand itself.

A brand is so much more than just a logo and colours. It's tone of voice, photographic treatment, the ethos behnd the brand. The message. The story.

Anyway, I've been doing some research into what I'd call 'good' brand guidelines available on the web, and quickly realised that it's all a bit of a mess. It's very difficult to find guidelines that are available, let alone in the right format. But because of the nature of where these things are kept, Google doesn't do a great job of indexing them.

So, I had an idea. What I need, is a resource (a website) where I can download current excellent examples of brand guidelines. I couldn't find one and don't know of any in existance. Do you?

Anyhow, I'd like to begin the trawl for guidelines and get together some sort of website to put them all - who knows, this could then grow into something larger (i've a few ideas spinning round my head). But I need your help to get the ball rolling.

Do you know of any good branding guidelines that available online?

New look Guardian

<

p>{title}Today sees the launch of the new Guardian newspaper here in the UK. I'm pleasantly surprised by the amount of column inches and airtime a redesign of a national is getting. Not only do we see a change to full colour, but an entirely new format for British Newspapers and a entirely new grid system design and typeface. Pretty much everything then.

<

p>There are several things which will upset people straight off with this new design. First of all is the Masthead.

The Masthead

The original Guardian Masthead, designed by David Hillman in the 80's, clearly communicated the paper's 'brand'. Elegant Garamond mixed with with a hard, emotionless Helvetica. Traditional broadsheet values with left-wing modern thought. You knew what you were getting yourself into (which is why I don't generally read the Guardian).

{title}

The new Masthead still retains the visual seperation of the 'the', although only in tone this time. It's set in the new Guardian typeface, the rather unimaginitive named 'Guardian Egyptian', which I feel brands the paper as more middle of the road. There certainly is less distinction now with other mastheads such as the Independent or The Times.

The Colour

Not much to say on this really. The paper is now full colour, which is great and will hopefully see an improvement in the photography as a result. In fact, in the centre spread of this mornings edition, there is a full colour spread of just one photograph which does look fantastic.

The Typeface

{title}Up until yesterday The Guardian used a mix of three typefaces - Helvetica, Garamond and Miller. Today, the paper uses just one - the newly designed Guardian Egyptian.

I think I'm a bit sad to see Hillman's inspirational typographic design go. I'm not the biggest fan of the paper in terms of content, but the design was always fantatsic. Really great typographic design. The new typeface is ok, although some of the letterforms in the lighter weights bug me, such as the lowercase c (there's a strange bulging going on). The heavier weights however look really good. Clearly legible at very small size and obviously designed to take into account the poop paper quality and a certain amount of bleed from the ink. A sharp looking serif, modern and very legible.

Overall, I like it.

The Size

Now this is the thing which is causing the biggest upset. For many years The Guardian was a broadsheet. Now if you talk to a broadsheet paper journalsit they often get a strange look in their eyes when discussing this paper format. The Broadsheet is steeped in history, and I for one hope it doesn't go away entirely. But. Broadsheet papers are a pain to read, wherever you are. Even on the couch.

Over the past few years a few of the broadsheets in the UK, most famously The Times, have moved to a tabloid format for the daily (the Sunday paper is still Broadsheet) and as a result has seen their circulations rise whilst the Broadsheet papers (The Telegraph and The Guardian) has seen their circulation fall.

So, the Guardian has decided to go smaller, but not Tabloid. They've decided to use the Berliner, or Midi, format. The format is about as wide as a Tabloid, but taller. I think one of the major reasons for this was to set The Guardian apart from the competition, to give it a different feel (possibly to distract from the watered down redesign). Also, I feel this gives The Guardian a more European feel as there are a few papers on the continent which use this format (Le Monde in France and La Repubblica in Italy).

The Grid

With a new size, comes a new grid. The Guardian sports a clear 5 column grid which is certainly a lot clearer than the old broadsheet grid. The column measure is slightly wider, which lets the new typeface breath a little. I feel the majority of broadsheet column measures are just too thin, this new design seems just about right.

Overall Impressions

A little watered down design wise, certainly not as distinctive as before. Great to see full colur. Like the new size although it's a shame that we see another broadsheet disappear.

You can read all about the redesign on The Guardian website

Five simple steps to designing grid systems - Part 4

Layout seems to be a hot topic at the moment, mostly prompted by the ALA redesign and the numerous discussions of the choice by Jason and the ALA team to go 1024 for a fixed width. I'm not going to go into my thoughts on ALA in too much depth here, there's been a lot of that already, but it seems like the right time to get this article out.

So, fixed width grid design for the web. What is it, how do we do it and how do we implement it?

For the purposes of this article, I'm going to be focussing on the theory of creating the grid rather than the implementation. I did mention in the last series that I would cover implementation using CSS, well I'm not going to. There are just so many resources and books available telling you how to create the CSS layouts you need—I'll touch on it, but I won't be going into too much detail.

The Measurements

A fixed grid for designing for the web is as close a translation from traditional grid design as there is. The designer is using fixed measurements, pixels mostly, to construct the grid and to position elements within the grid structure and a canvas which is based on a fixed size. See, everything is fixed.

The Canvas

Now things start to get a little less concrete. The canvas size for print design is determined by the media size - paper, signage, envelope, whatever. The canvas size for fixed grid design on the web is normally determined by the browser window size, which is in turn determined by the user's screen resolution. These are not fixed. Therefore a designer should design to the minimum requirement, which is normally the average screen resolution for the majority of users.

I'm not going to quote figures here, because I'll probably be wrong, but I don't think I'm wrong in saying that 800x600 pixel screen resolution has, for quite a few years now, been the screen resolution to design to.

As I mentioned, with the relaunch of ALA, and sites like Stylegala, there has been a renewed discussion about fixed width grids for 1024. So, what's my opinion on this? Well, in terms of the actual grid design it really doesn't matter what size the canvas is. What should be determining the decision to go 1024 is research into user's screen resolutions. If the user base of a certain site is shown to be using resolutions of that size and above, then a decision to use that size to design to is a valid one.

However, as some people have noted, even if you do run at a higher resolution than 800x600 does that mean your browser window occupies the entire screen? The answer to this is, generally we don't know. I personally think that not only is it platform specific, but it's also down to the individual and their experience level. Maybe more experienced users on a PC don't use their browser's at full screen. From my experience running user tests with a wide range of people, is that more novice users, particularly on a PC, run a browser at full screen because that is the default, whereas on a Mac the default isn't full screen.

What I haven't touched on yet is the device you are using. This of course could be a PDA, a mobile phone or a computer. Grid designs should be looked at for each of these devices.

That is all I'm going to say on the matter for now though. Once the final part in this series is up, fluid grid design, there can be a more informed discussion I think.

Nice, easy dimensions and thinking modular

Without further a do, let's get into this grid design.

As discussed in the rest of this series (part 1, 2 and 3), we will begin our grid design by 'shaping the page.

For the purposes of this simple (I am trying to keep it simple) article, I'll be using 800 x 600 as my default resolution to design to. For many years I've designed to a base minimum (based on 800 x 600) of 760px x 410px (410px being the fold). Don't ask me where I got these figures from, but it just stuck and seems to be ok for most platforms and browsers. Oh, you can of course go smaller than this and don't pay too much attention to the fold, in my experience most users don't have a problem with scrolling.

We begin by applying ratios to this canvas, in the same way we've done with designing grid system for print. The example I'm using for this tutorial is my own site, which uses a fixed grid and sits happily below 760px wide.

{title}

The design for my site is built around around a very simple grid system. Once I had my grid, I used photoshop to comp together the designs positioning any elements exactly on the grid lines. The grid was designed intially for a content and navigation area based on the Rule of Thirds (which is roughly approximated around the Golden Section), the dimensions of which are 250px and 500px respectively. The content area is then subdivided into two 250px columns.

See, nice easy dimensions. However, this only deals with horizontal measurement. As discussed in the other grid articles, vertical measurement is also important, but this is where we can run into problems with designing even fixed grid systems on the web.

When user's change the type size, elements move vertically (if we've fixed the horizontal widths). The vertical measurements that we've crafted suddenly disappear. Now, in the purist's eye, this is a real problem but it is something we have to design to. We really can't do anything about it when designing with fixed units such as pixels which can't be resized by the user.

Just a word about Gutters

Gutters are the gaps in between columns. They are there so text, or image, from different columns don't run into each other. In grid system design sometimes, depending on what theory you read, gutters are seperate to the columns. This creates practical problems for us when designing grid systems on the web because of the way we create the columns.

Generally the columns we create, using Web Standards, are 'divs' which are given widths and positioned and styled using CSS. So, ideally, if we're creating these columns, we don't want to be creating seperate ones for the gutters. We therefore deal with gutters as part of columns and they are implemented using padding, or creating margins, on elements positioned within them, or sometimes the column divs themselves.

{title}

Creating the design

The thing about designing to grids is that in order for the grid to work you must consistently align items on the grid lines. I know that sounds totally obvious but designing to strong grids means you have to take a step back from what you think the design should look like (and then adding things to the grid to suit), and instead concentrate on creating a harmonious design within the framework you've created.

{title}

The bulk of the design work, if you exclude sketching with a pencil, is done in Photoshop. First of all I take great care in drawing the grid accurately, to the pixel, and then I overlay content elements ensuring the alignment is precise.

From Photoshop to the browser

As I stated at the beginning of this article, I'm not going to concentrate too much on how you actually build a multi-column CSS layout, there are just so many other great resources on that topic.

One of the most useful 'tools' for creating pixel-perfect grid systems for the web is Khoi's superb idea of using a grid as a background-image element on the body tag. To summarise: Using the grid I designed in photoshop, I save it out as a gif and then apply that to the background of the body tag. This provides me, throughout the build of the site, the grid so I can align all the content elements accordingly.

{title}

As you can see from the diagram, this makes production of the design incredibly easy when you have a visual reference rather than having to remember your grid or interpret a sketch.

Implementation using Web Standards

This really could be a series all on it's own. Implementation of a multi-column grid using CSS is pretty standard practice nowadays, but there are some very useful resources out there which I have used for the past 18 months or so.

Doug Bowman at Stopdesign has pioneered a technique for producing flexible column layouts using CSS and controlling them by giving a class to the body tag. This is the techique I've used throughout this site. This means if I create a new section of the site or simply decide one day that I'd rather have my navigation on the right, all I have to do is change the class on the body element and everything switches over. Using this technique, along with Khoi's technique for sense checking the design against the grid, has been an excellent way to produce tight, grid layouts for me, give it a go and let me know what you think.

Up next: Fluid grid systems for the web.

Timely? Yes. Complicated? Yes, but they don't have to be. Fluid, or flexible, grid systems have a rightful place in grid system design for the web but they come with their own particular set of challenges. In the next installment I'll be having a look at flexible grids using relational measurements and also tying the grid design closer to the typography rather than the browser - flexible from a type perspective, rather than a browser perspective. Stay tuned.

The series

This is the fourth installment of this "Simple Steps..." series.

  1. Subdividing ratios
  2. Ratios and complex grid systems
  3. Grid systems for web design: Part 1
  4. Grid systems for web design: Part 2 Fixed
  5. Grid systems for web design: Part 3 Fluid

Five simple steps to designing grid systems - Part 3

The third installment to this series is going to be a little different. The previous installments have been talking through some of the basics of grid construction using ratios as the primary device. They've also dealt with grid construction for print media. Unfortunately, as designers for web media, we don't have some of the luxuries as our print designer collegues.

Rather than go through tutorials (I'll be covering these in the last two installments), I'll be using this installment as a platform to discuss some of the challenges and rewards of designing grid systems for the web.

A whole load of considerations

Designing grid systems for print is considerably more straight forward than designing grid systems for the web. First off,in print, the designer has a fixed media size - the paper size (or packaging, poster, whatever). Let's say a print designer has designed a magazine. The reader of this magazine can't suddenly increase the font size if they find it difficult to read - well they just move it closer to their eyes I guess. This is just one consideration, there are more but I'm sure you get the point.

So, that's media size. On the web you have other considerations such as the browser, the OS platform, the screen size and the actual devices that web sites can be viewed on, from PDA's and Mobile's to assistive technologies such as screen readers. How do you design a grid for all of this? It's a really good question and I'm not claiming I have the answer.

In an ideal world

We all know about the problems with websites rendering differently across different browsers, platforms, devices etc. But, just for a moment, let's forget about that.

Designing a grid for the web should not be difficult, in fact, it shouldn't be any different from designing a grid for an media. As discussed in the previous parts of the series, you can construct a grid in the same manner for screen as you do for print. Base it on ratios, experiment with form and white space etc. Use pixels as your base measurement and go from there in the knowledge that your design will look exactly the same in every browser. After all, you, the designer, knows best for your reader right? You know they want light grey, 10px verdana with a measure of 600 pixels.

In the real world

Good designers for the web know that the users who use their sites may want different, and know, with the web, they have the power to change things. The designer has lost, to a degree, the ability to control. For a lot of designers (including me), this has been a tough transition. We're taught for years to create the delicate balances of white space, the manicured typography and delicate colour palettes, all designed to create harmonious designs which do their job very well.

Then some short sighted user comes along and increases the text size... and... and... totally breaks your design.

I think you get the idea. We can't be upset when the user wants to change something like the text size. What we can do is design grid systems to adapt to those changes.

Not just columns

Over the past couple of years, coupled with the increase in CSS based sites, we've seen a rise in certain grid configurations which are all based on the amount of columns. 2, 3, 4 column layouts - float this, position that etc. Why, even this site falls into the '750 px, 3 column' category. These grids have quickly become a convention, and for good reason too. They are quick to create, fairly stable across many platforms and don't degrade to the same degree as table based layouts. This is all good. What isn't so good though is the general lack of understanding of grid systems when perhaps the question on most designers lips when they sit down to begin a design is, 'how many columns should I have'. This is not grid system design.

Grid systems for the web

The next two installments of this series will go through details of creating considered grid systems for the web and the implementation using CSS. I thought it would be useful to just go through some of the considerations before hand.

The series

This is the third installment of this "Simple Steps..." series.

  1. Subdividing ratios
  2. Ratios and complex grid systems
  3. Grid systems for web design: Part 1
  4. Grid systems for web design: Part 2 Fixed
  5. Grid systems for web design: Part 3 Fluid

Professional CSS: A first look

{title}I've just received my copy of Professional CSS - Cascading Style Sheets for Web Design so I'd thought I'd share my first thoughts after flicking through the book.

<

p>First off, this book looks like a technical book written for people who already have a good understanding of CSS and what that involves, this is not a beginners book.

<

p>There's a foreword by Zeldman. I was quite looking forward to what Jeffrey would say about the book and the subject matter, but I guess he's already said it all as the foreword is a little uninspiring (sorry Jeffrey). The first chapter deals with planning to design and build a website and touches on subjects such as Information Architecture, Scope and it's really nice to see a good couple of pages on Personas and User Centred Design.

The second chapter outlines best practices in XHTML and CSS, giving a brief overview to semantic markup, box model, cascade and inheritance, etc. Again, if you've read a few CSS books before this one, a lot of this won't come as a surprise.

Then comes the bulk of books content, chapter after chapter of case studies with interviews from the designers and the techniques used to build the sites. They are:

  1. Blogger Rollovers and Design Improvements - Written by Dunstan Orchard, interviews with designer Douglas Bowman
  2. The PGA Championship - Todd Dominey
  3. The University of Florida - Mark Trammell
  4. ESPN.com - Written by Dunstan Orchard, interviews with Mike Davidson
  5. FastCompany.com: Building a flexible three column layout - Written by Ethan Marcotte, interview with Dan Cederholm
  6. Stuff and Nonsense: Strategies for CSS switching - Written by Ethan Marcotte, interviews with Andy Clark
  7. Bringing it all together - written by Christopher Schmitt

I'm sure they'll be some really good stuff in all of these chapters.

Anyhow, the upshot is, on first glance, it looks good. It's good to see a book aimed at the professional whose been using CSS for a while and understands the benefits etc, but needs a book to explain some more of the detail. Like I say, I haven't read it yet, just thumbed through it, but from what I can see it's certainly worth the money.

Who knows maybe next Geekend I can get Dunstan to autograph it for me. What do you reckon I could get for that on ebay?

Tags and Folksonomy - I need your help

I've got some projects on at the moment which are requiring me to think long and hard about tags, metadata and 'folksonomies' (of the Del.icio.us and Flickr kind). I'm getting nowhere fast in terms of user requirements for tags and was wondering if you could help me out.

For those who are unfamiliar with what I'm talking about here's a brief description from wikipedia:

Folksonomy is a neologism for a practice of collaborative categorization using freely chosen keywords. More colloquially, this refers to a group of people cooperating spontaneously to organize information into categories. In contrast to formal classification methods, this phenomenon typically only arises in non-hierarchical communities, such as public websites, as opposed to multi-level teams. Since the organizers of the information are usually its primary users, advocates of folksonomy believe it produces results that reflect more accurately the population's conceptual model of the information...

I like tags, but that's not to say eveyone does, and I can see tagging content is useful from a content management point of view, but is it really useful from a user's perspective?

From what I can see, from the likes of Flickr, is that content is organised by the user, by keywords. The information structure is then 'created' by this tagging which all very nice. What i'm really struggling with is, does the user then use this structure to navigate? and I'm coming round to the answer being 'no'. Let me explain.

User tagging content is a submission process - If the user's can be bothered or if they have to. User tagging content will of course have problems with users having to choose the same descriptive words for things (maybe the UI could benefit with contextual suggestions here from previously submitted content). So, I've got a few questions and I'm not sure where to get informed answers (what I mean by this is based on research) Here's some questions:

  1. Do users navigate by these keywords?
  2. Does folksonomy tagging facilitate task based navigation?
  3. How does the UI affect this navigation.

I guess the beauty of tagging in this way (and presenting it in a good UI, like a 'tag-cloud') is that it helps facilitate browsing rather than finding, two very different types of navigation. Anyway, I'm really rambling now.

What I'm after is usability reports and the like on metadata and user generated tagging. If you know of any can you point me the right direction? Thanks.

So, what do you think? Are user generated tags good? How can the UI be changed in user generated tags to help facilitate task, rather than browse, based navigation?

Five simple steps to designing grid systems - Part 2

In part one of this Simple Steps series I talked about how to use a simple ratio, that of the paper size you are using, to create a symmetrical grid on which to create your designs. This, the second part in the series, will deal with other ratios and how they can be combined to create more complex grid systems.

Relating to grid systems

I've talked a few times about using the Golden, or 'Divine', Section in the grid systems you design. So, before you continue I suggest you read the background in this article and my article in Design in Flight. For those who don't want fork out your hard earned cash on the DiF article, I'll summarise:

The Golden Section is a ratio which is evident throughout the universe as the number Phi. You can use this ratio to good effect in design by making sure that elements of your grid conform to this ratio. Using the Golden Section can ensure a natural sense of correct composition, even though it is based in mathematics it will 'feel' right.

This is an important point and has been argued and debated for ages. Aesthetics can be measured and more importantly can be constructed. If you want something to be aesthetically pleasing there are steps you can take to make sure it is going in the right direction. Now I'm not saying that 'follow these rules and you will create something beautiful'. What I am saying is that by following a few of these guidelines can go some way into creating something compositionally balanced, which will inherently be more aesthetically pleasing.

Composition can make things more usable

This is a theory that exists called the 'Aesthetic Usability Effect'. I have written about this as well in the past, I find it a really interesting theory. This theory suggests that things which are designed to be beautiful are inherently more usable as a result. It is an interesting theory and can certainly challenge the usability field, which is often tarnished with the 'ugly brush'.

Composing grids using theory and balanced ratios (such as the Golden Section), which in turn enable the creation of beautiful, balanced designs. These designs then have a quality which will make them more usable, according to the theory. Perhaps I'm labouring the point here, but in short:

Well designed grid systems can make your designs not only more beautiful and legible, but more usable.

Putting it into practice

As in the first article I'm going to be desiging this grid in context. For those of you who are primarily web based I'm afraid this is going to be another print example, but that doesn't mean this theory can't applied to web. It can of course be applied to lots of different medium, from architecture and interior design to product design and art, you just have to apply it to a different 'canvas'.

So, as in the DiF article the brief is to design a book. Unlike the first article in this series, I'm going to be applying the grid to a double page spread rather than a single page, this is called an asymmetrical grid as opposed to the symmetrical grid I designed in the last article.

Shaping the page

For this grid, we're going to use the ratio of the page to define the main text, or content, area of the pages. There's a very simple way of reducing this page size down to make sure the ratio is correctly placed and balanced. See diagram.

{title}

We now have an area, shown in red, in which to construct the grid.

Applying the Golden Section

Now you've read the other articles you will see that applying the ratio to this area is pretty straight forward. The area is divided using Phi which gives us two columns, A and B.

{title}

Creating the system

So, we've got the columns, we now need to flesh out the grid to be able to cope with the different content and page types. First off, we extend the lines of the content area and the columns.

{title}

We then apply a horizontal rule cutting across content area creation lines. I call these 'hanging lines', not too sure what the correct terminology is. But anyway, the content 'hangs' from these lines giving us consistency throughout the book. It gives the reader a line, in the same place, to rest their eyes on page after page.

{title}

Using the extended lines we can then add areas for the access structure of the book—folios etc. These typically sit outside of the content area, usually with plenty of white space around them, as to show that they are different 'types' of content.

{title}

We can then add various designs to this grid comfortable in knowing that the individual elements of the design—text, images, access structure elements—will all have a relationship to each other and to the book size.

Relating to grid systems

Creating grid systems in this way—using ratios to create related lines on which to construct composition—ensures a balanced grid.

I'm afraid it isn't an exact science though. A lot of grid design is experimentation with ratios, it's experimentation with using white space and elements of content such as photographs and text. It's also about conventions. Don't reinvent the wheel needlessly, study the conventions used in magazines from all sectors—from architecture to nursing (seriously, some magazines from unexpected professional sectors have fantastic grid designs).

What I'm saying is, have a play with grid design. Just because I'm talking about ratios, subdivisions and modularisation, doesn't mean designing grids should be dull. Have a mind on the end product, but not at the expense of the process of designing your grid.

The series

This is the second installment of this "Simple Steps..." series.

  1. Subdividing ratios
  2. Ratios and complex grid systems
  3. Grid systems for web design: Part 1
  4. Grid systems for web design: Part 2 Fixed
  5. Grid systems for web design: Part 3 Fluid

Five simple steps to designing grid systems - Part 1

The first part of this Five Simple Steps series is taking some of the points discussed in the preface and putting it to practice.

Ratios are at the core of any well designed grid system. Sometimes those ratios are rational, such as 1:2 or 2:3, others are irrational such as the 1:1.414 (the proportion of A4). This first part is about how to combine those ratios to create simple, balanced grids which in turn will help you create harmonious compositions.

Starting with a blank canvas

It's always easier in these kinds of tutorials to put the example in context, in some kind of real world scenario. So, this is it. You've got to design a programme for a gallery exhibition. You know you want the size to be A4. You also know that there are going to be photographs and text, and the photographs will be of varying size. There you have it - your blank canvas.

Subdividing ratios

The grid system we are going to design is a simple symmetrical grid based on a continuous division of the paper size in the ratio 1:1414. Using the paper size as a guide we can retain the proportion throughout the grid, this will give our elements within the design a relationship to one another, the grid and the paper size.

This is one of the easiest ways to create a balanced grid. By using the size of the paper as a guide we can divide using that ratio to begin creating the grid. You can see this through diagrams 1 - 6 that we begin by simply layering division upon division to slowly build up the grid.

{title}

{title}

Diagrams kindly updated by Michael Spence

Getting creative

Many have said grid systems can stifle creativity, but I disagree. Grid systems can facilitate creativity by providing a framework and already answer some designers questions such as 'where should the folios go', 'how wide should the measure be?' etc. A well designed grid system will go some way to answer these questions and more.

So, we have our grid. We can now begin to experiment with type areas, shapes and composition. We can explore how type and image will work together on the various types of pages our publication will have.

{title}

Diagram 7 shows the text area with the first elements of the access structure - running heads and folios. Diagrams 8 and 9 show how adaptable the grid is to various design options.

Short but sweet

A simple step to begin with. Next we'll go onto to more complex ratios, such as the Golden Section, and combining multiple ratios across spreads instead of single pages.

The series

This is the first installment of this "Simple Steps..." series.

  1. Subdividing ratios
  2. Ratios and complex grid systems
  3. Grid systems for web design: Part 1
  4. Grid systems for web design: Part 2 Fixed
  5. Grid systems for web design: Part 3 Fluid

Five simple steps to designing grid systems - Preface

Following my article in Design in Flight I've received countless emails to elaborate, in some way, on how to correctly design grid systems. It's quite a complicated field and so distilling it into 'Five Simple Steps' has proven to be quite tricky, so much so that I thought I needed to write some sort of preface before we get on to the first part.

What is a grid?

Before we even begin to tackle designing grid systems we need to have a basic understanding of what they are, why we use them and where they came from.

In the context of graphic design, a grid is an instrument for ordering graphical elements of text and images. The grid is a child of Constructivist art and came into being through the same thought processes that gave rise to that art movement. Clear links can also be drawn between the Concrete-Geometrical art of the Zurich school in the 1930's and several notable artists of this movement made important contributions to typography through their fine art.

It was around this period that the grid system moved from the domain of art and into one of typography and commercial design.

It's about mathematics... mostly

First of all when talking about grid systems we have to mentally separate form and function. We have to think about aesthetics and proportions as a result of considered construction. This can be quite tricky for designers who have been schooled in the 'you'll know it's right when it feels right' school of composition. But as I've written about before, feel is an emotional reaction to construction, to mathematics.

Ratios and equations are everywhere in grid system design. Relational measurements are what defines most systems, from simple leaflet design to the complex of newspaper grids. To design a successful grid system you have to become familiar with these ratios and proportions, from rational, whole-number ratios such as 1:2, 2:3, 3:4 and those irrational proportions based on the construction of circles, such as the Golden Section 1:1.618 or the standard DIN sizes 1:1.4146.

These ratios are ubiquitous in modern society, from the buildings around us to patterns in nature. Using these ratios successfully in a grid system can be the deciding factor in whether or not a design, not only functions, but has aesthetic appeal too.

What is a grid system?

A grid system is a grid design which has been designed in such a way that it can be applied to several different uses without altering it's form. An example of this would be a grid system for a book whereby you have many different page types - part-opening, title, half-title etc. - and would need only one grid to use on all the page types.

The danger with designing a system to cope with many different varients is complexity. When you add complexity, you decrease usability and there is a danger the grid would become so complex the designer can't use it. This thought should always be running through your head when designing a grid system - keep it simple, but comprehensive.

Why design a grid system?

It is often said of grid systems that they limit the scope for creativity or leave no freedom. Karl Gerstner, one of Switzerland's preeminent graphic designers, was aware of this conflict with the designers adoption of grid systems.

The typographic grid is a proportional regulator for type-matter, tables, pictures and so on. It is a priori programme for a content as yet unknown. The difficulty lies in finding the balance between maximum formality and maximum freedom, or in other words, the greatest number of constant factors combined with the greatest possible variability.

The grid is a regulatory system which pre-empts the basic formal decisions in the design process. it's preconditions help in the structuring, division and ordering or content. I'm not saying a well designed grid will solve all of your compositional problems, far from it, but it goes some way in creating a coherent structure in design which in turn creates the aesthetic values all of us are after in our designs.

The Five Simple Steps

You should now have a clearer understanding of what grid systems are, where they came from and what they should do, if designed well. Within the next Five Simple Steps, I'll go through the elements which make a successful grid system and how these elements can be brought together to create simple and complex systems which can be applied to a number of media outputs.

The first in the series will be 'Combining Ratios'

  1. Subdividing ratios
  2. Ratios and complex grid systems
  3. Grid systems for web design: Part 1
  4. Grid systems for web design: Part 2 Fixed
  5. Grid systems for web design: Part 3 Fluid

Modularised stuff - where to draw the line?

I’ve got a several large projects ahead of me at the moment and it’s at that stage where you are mentally planning out how to go about certain things with the end result in mind.

There’s a fair bit of talk about modularisation at the moment, not only for content, but for the HTML and CSS, and this is the way I’m currently going for the projects. This is partly based on past experience, but also I believe it’s the right thing to do, especially on large projects.

This is how I'm going about it...

Getting your head round the content

So, without going into too much detail, the projects involve multiple content types from uploaded images to forums, but it's mostly different types of text content - lists, tables, captions, not too many large blocks of copy (which is good I suppose).

The first thing is to audit the content and break it into common chunks, groups of data type which can then be addressed as if they were one entity.

Secondly, decide how granular you go with the content. Is it down to field? or just to the 'paragraph of text' level.

Thirdly, once you've got your chunks of content, or content objects, spec and wireframe them as detailed as you can.

The build

I've begun by defining an html framework in which these objects will fit. This is basically a client-side solution in which I define different layout types, based on columns, and the content objects then sit within these columns.

I like the idea of seperating the framework from the content, simply because it also allows me to focus on objects individually knowing that the overall 'layout' configurations are taken care of.

This is how it splits down do far:

  1. Framework
  2. Content objects (defined in content audit)
  3. CSS
  4. Javascript (for control of UI elements)

The CSS

Number 3 is the one where things could get tricky. How far do you go with CSS modularisation? Do you have different stylesheets for colours, structural layout etc. Or do you just have one, which is flagged (as in Doug's interesting article).

The problem I've got is all these content objects, each with it's own bit of CSS, could make modularising CSS extremely difficult to maintain - you could end up with over 30 stylesheets being imported. Not very practical.

Your thoughts?

How would you go about something like this? Would you modularise to that level or would you just bung everything in one CSS and use flags to navigate?

Some thoughts about signs

{title}For a few years now I’ve had a bit of an interest in signage. Recently I was the only person to get a bit excited about a road transport exhibition in the Design Museum in London. Why? Well, signs are really interesting when you start thinking about them. So, here’s some thoughts about signs and how we, as designers, can look at them differently and incorporate some the ideas behind signage into what we do.

Signage does a number of things - it helps us get to where we want to go, it informs us, warns us and the list goes on. Let's deal with the first one... (or if you're not bothered, skip straight to the confab)

From A to B

Getting to where we want to be. It's a big deal, and signage helps us do that. The professional service dedicated to just this is called Wayfinding, and it does just that, helps us find our way. Wayfinding signage is found in almost every city, building and civilised environment on the globe, from official road signs to hand painted 'toilet' signs in local cafe's.

Having been involved in a couple of wayfinding projects I found the research and development fascinating. It usually involved developing a signage system, mocking it up in black and white prints and building wooden stands, then positioning them in a space and watching how people follow them. As they were temporary we could audit the people flow and make the required changes so that people could find what they want.

Designing a signage system is a little like trying to guess what people want to do in a space. For public buildings, like libraries and museums, they have to inform in addition to pointing people in the right direction. Museums are particularly interesting and, you've guessed where I'm heading with this, the similarities between museum signage and web site architecture are plenty.

Where's the f**king toilet

When somebody enteres a building, especially if they've had a long journey or they had too much orange juice in the morning, they will want to know one thing - 'where is the toilet', they will be single minded in that task as well. They will look for one of two things, a sign with the word, or if it's in another language an icon of a man or a woman. That's it. They shouldn't have to learn a new signage system, or try and work out a designer's 'creative' impression of what a toilet sign should be.

My point is this. Universal signage systems have been developed to overcome language so that manufacturers don't have to produce several products for different markets. This system works well until somebody does it differently and your daughter pees her pants because you couldn't find the toilets because they client wanted to be 'different'!

The same goes for web sites.

Provide clear signage

A user will come to a web site with a specific task in mind. Not going to the toilet, but more like they want to complain about something or they need to buy their daughter some new pants.

I may be preaching to the converted but putting the user first, understanding their goals and designing to them is the best way to deliver on the sites goals.

I know I'm opening up a big can of worms here with possible discussion about iconography, semiotics, usability, Information architecture, UCD etc. But understanding how signage works can go a long way to understanding how people navigate on a web site.

I've been doing a little reading on the subject and it's a bit like opening Pandora's Box. There is a lot out there, specifically on semiotics, but dipping into linguistics and psychology. It's quite difficult to filter some of the information and make it useful for you in a practical sense and you can't read everything right?

So, here's what I've found out so far...

Let's start with Semiotics

Semiotics is the study of signs and symbols and their use or interpretation. There are three main areas:

  • The signs themselves
  • The way they are organised into systems
  • The context in which they appear

Extracting meaning from the signs is then possible once we understand the structure of the signs. They can be categorised like this:

<

dl>

Icon
This resembles the sign. A photograph, a diagram, even a sound like 'bang'.
Index
This represents a link between the sign and it's meaning. Smoke and fire for example, traffic light colours.
Symbol
These signs have no logical meaning between the sign. An example of this would be where a symbol has become linked with an organisation or product, the red cross for example. Symbols are commonly used for logotypes.

How is this useful in designing for the web? Well, extremely and not just web design either but designing for any medium.

A person has to establish meaning from a sign or symbol. They then use this meaning to do many things, one of which could be to accomplish a task. The closer the design of the sign is to the task, the quicker meaning is understood and the task is completed.

{title}

There is of course the Usability / Aesthetic effect to take into account too. With this in mind applying it to web site design is actually quite straight forward.

A few things to consider

  1. When designing icons for web sites or applications draw on real world signage standards if you can. If you can't, try drawing on metaphor. Arbitrary shapes for icons will not work.
  2. When thinking about labels for your navigation, think clearly. Simple words for content will go a long way in shortening the gap between sign and task completion.
  3. Use colour carefully. Point users in the right direction with high contrast signs, or buttons. Just as you may speed down the road at 70 mile an hour and read a sign in less than 2 seconds, a user speeds through a website and may not give you more than two seconds. Be conspicious with your signs.
  4. Be consistent with your signage. Be it words or icons, be consistent in design and tone of voice. Let your users know what to expect.

There's just a few things I've picked up over the past few years. Once I get some more stuff worked out, I'll let you know. In the meantime I thought it may be fun to have a bit of a signage confab.

How about a signage confab?

Every designer likes icons or signs right? What's your favourite? This could be a photograph of one, one you've designed, sky's the limit. Usual confab stuff applies:

  1. Host the image on your server and link it in here.
  2. Simple HTML is fine.
  3. Keep it below 400px wide please or you'll bust me layout.

Oh, and here's mine...

{title}

Five simple steps to better typography - Part 3

{title}I'm pleased this series is turning out to be so popular and it's somewhat confirmed what I suspected. A bit of a thirst for simple typographic design theory.

As I've been writing this series i've deluged by email and comments from people agreeing, disagreeing, asking for more information etc. What's great is designers are thinking and talking about typography again. Designers are questioning typography and not just letting the font and the software do the work. It's nice to hear. But enough back-slapping Mark, on with the next in the series...

The third installment of this series is dedicated to just one typographic element - Ligatures.

Ligatures are combinations of letters - some of them are functional, some are decorative. They are more commonly seen in serif faces, although ligatures in sans-serif faces such as Gill Sans and Scala Sans are important to the typeface and should be used.

They are generally comprised of certain characters which are created to stop collision of elements of letterforms. Take the letter f of a serif typeface. In lower case, especially italic, the top and tail of the f move into the character space next to it. These overlaps are what typographers call kerns.

{title}

It's when these overlaps collide with letters next to them that we have problems. Take lower case f and lower case i, probably the most widely used ligature. When set in Roman (A, above), the ascender of the f collides with the dot of the i, the effect is much worse when set in italic (B, above). Type designers therefore combined the character into the fi ligature. As you can see, the dot from the i is simply removed.

{title}

Ligatures and language have been closely tied throughout typographic history. Typographers in the sixteenth century devised ligatures to cope with common occurrances of letters in latin - fi, ffi, fl, ffl, ff (shown above). You will find at least a couple of these in most fonts. But, as langage has changed to encorporate different words, especially english, the need for more obscure ligatures has grown.

Take the word fjord for example. The ascender of the f will collide with the dot of the lower case j. This is resolved the same way as the fi ligature in that the dot is removed from the j. The trouble with less common ligatures like this is that they generally aren't in the standard character set of a font, so we kind of have to make do or if setting type in a program like Adobe Illustrator, make them by hand. And this brings me neatly onto practical usage of ligatures.

Usage in print

I tend to use ligatures specifically for headlines. Occasionally, if the job demands it, I will use ligatures for body copy as well but this does tend to make typesetting a little time consuming.

If for example I'm creating a logotype for a coffee shop called "Flow's fine beans" (a convenient amount of ligatures present there!). The name could simply be set in a font which does not require ligatures, but this could make the logotype quite plain. The font chosen could be serif, but special care must be given to the kerning and overall appearance when setting logotypes that use ligatures.

{title}

This logotype, shown above, is simply typed using Mrs Eaves. See how the ligatures appear too close to each other creating dense areas of type. The gaps between certain letterforms are also unsettling to the eye. This needs to be manually kerned.

{title}

If the type is set carefully the ligatures add typographic interest to the words. They add character and begin to tell a story about Flow's shop - it's a classy place, nice coffee too!

So, careful attention to detail at this stage can help define a logotype and go a long way to help define brand message - all through the simple use of ligatures.

But what about on the web?

Usage on the web

Ligature usage on the web is a bit tricky. Functionally there are special characters for the following ligatures - these are needed for linguistic reasons.

ÆÆCapital AE
ææLower-case ae
ŒŒCapital OE
œœLower-case oe
ÐÐIcelandic upper-case eth
ððIcelandic lower-case eth
ßßGerman double-s
ÞÞIcelandic upper-case thorn
þþIcelandic lower-case thorn

They should be present in body copy and headline copy for those languages that require them. What HTML doesn't cater for is the use of the five main ligatures - fi, ffi, fl, ffl, ff within the special character codes. The fonts generally do have these ligatures present but it's debatable whether they needed to be used on screen or not.

I tend to only use ligatures for on screen use if I'm creating logotypes, or graphical headers or elements that require them. In this instance all use of ligatures is fine. There are many people who disagree, stating that ligatures are a relic of by-gone age. I disagree. The use of ligatures in your typesetting, for print or on screen, shows a typographic maturity and an understanding of the craft.

The series

This is the third installment of this "Simple Steps..." series. Next up we have Typographic Hierarchy

  1. Measure the measure
  2. Hanging punctuation
  3. Ligatures
  4. Typographic Hierarchy - size
  5. Typographic Hierarchy - weight

Five simple steps to better typography - Part 2

Hanging punctuation is an area of typographic design which has suffered at the hands of certain software products. It's a term which refers to glyph positioning to create the illusion of a uniform edge of text.

It's most commonly used for pull-quotes, but I feel the most neglected is that of bulleted lists.

With the advent of desktop publishing it became suddenly very easy and cost-effective to produce bodies of text. The problem was these bodies of text work within a box. Every character in this box had to be within the box, Hanging Punctuation requires characters to be out of the box. This was a problem for the software and as a result was ignored. An important aspect of typesetting just swept under the carpet like that. It's a great shame.

Things are now getting better with Adobe Indesign offering support for Hanging Punctuation, I think the latest version of Quark may do it as well. Not sure about Word - probably not.

Well enough of the talk, let's get down to some examples.

Examples of Hanging Punctuation

Lists

Without Hanging bullets

{title}

A ranged left body of type is pretty much destroyed, aesthetically, when punctuation isn't hung. The eye looks for straight lines everywhere, when type is indented in this way, it destroys the flow of text.

With Hanging bullets

{title}

With hanging punctuation the flow of text on the left hand side is uninterrupted. The bullets, glyphs or numbers sit in the gutter to highlight the list. This representation of a list is more sophisticated visually and more legible.

Pull-quotes

Without Hanging Punctuation

{title}

Nothing is more irritating than badly typeset quotes. The interruption to flow is considerable and the overall effect is pretty unsightly

With Hanging Punctuation

{title}

Quotation marks should be 'hung' - See diagram below. In this example the quotation marks are hung either side of the quote. Once again this allows uninterrupted reading for the audience.

Hang it!

So, in short. Hang lists and hang quotation marks, when using pull quotes and quotes within a body of text.

And before you say "Mark, you don't hang your lists on this site", I will be, soon. The comments list is hung, I just need time to hang the bulleted lists... I get to it ok?

The series

This is the second installment of this "Simple Steps..." series. Next up we have Ligatures

  1. Measure the measure
  2. Hanging punctuation
  3. Ligatures
  4. Typographic Hierarchy - size
  5. Typographic Hierarchy - weight

Five simple steps to better typography

{title}

Typography, I find, is still a bit of mystery to a lot of designers. The kind of typography I'm talking about is not your typical "What font should I use" typography but rather your "knowing your hanging punctuation from your em-dash" typography. Call me a little bit purist but this bothers me.

So, in an attempt to spread the word here's the first of five simple steps to better typography. To kick it off, part one is about the Measure.

Measure the Measure.

{title}

The Measure is the name given to the width of a body of type. There are several units of measurement used for defining the Measure's width. The three basic units are:

  • One point = 1/72 of an inch
  • One pica = 12 points
  • One em = The distance horizontally equal to the type size, in points, you are using. Eg. 1em of 12pt type is 12pt. (Thanks to Joe for correcting me on this.)

But, with the advent of DTP packages and the website design the following are also now used:

  • Millimetres
  • Pixels

There is an optimum width for a Measure and that is defined by the amount of characters are in the line. A general good rule of thumb is 2-3 alphabets in length, or 52-78 characters (including spaces). This is for legibility purposes. Keep your Measure within these guidelines and you should have no problem with legibility. Please note that this figure will vary widely with research, this is just the figure I use and it seems to work well as a generally rule of thumb.

CSS and fluid?

What is interesting here is fluid designs on the web. How can a Measure react to an increase and decrease in size. The entire grid would have to adapt to that change. An interesting discussion point and challenge.

The Measure and leading.

A simple rule is your leading should be wider than your word spacing. This is because when the balance is correct, your eye will move along the line instead of down the lines.

If your measure is wider than the guidelines for optimum legibility then increase the leading, or line-height as it's sometimes wrongly called. This will have the effect of increasing legibility. Your leading should increase proportionally to your Measure. Small Measure, less leading. Wide Measure, more leading. It's a simple but effective rule.

Reversing out?

{title}

When reversing colour out, eg white text on black, make sure you increase the leading, tracking and decrease your font-weight. This applies to all widths of Measure. White text on a black background is a higher contrast to the opposite, so the letterforms need to be wider apart, lighter in weight and have more space between the lines.

Tracking

{title}

The general rule of thumb in tracking your words (not the characters) is that the shorter the line length the tighter the tracking, the opposite is also true.

Your responsibility

Following these simple rules will ensure your bodies of text will be as legible as they can be. These rules come from a typographic craft background which unfortunately, for our industry in particular, aren't being taught as much as they should be in the art schools around the world. As a result they aren't being practiced and correct, well-considered typography is taking a nose-dive.

It's our responsibility, as designers, to embrace the rules which are born of a craft which goes back hundreds of years.

Hopefully, this series of quick, sure-fire ways of improving your typographic craft will help in some way make sure computers and DTP doesn't kill it off. That would be a great shame.

The series

This is the first installment of this "Simple Steps..." series. Next up we have Hanging punctuation

  1. Measure the measure
  2. Hanging punctuation
  3. Ligatures
  4. Typographic Hierarchy - size
  5. Typographic Hierarchy - weight

Design In Flight - Issue 4

{title}Well, here it is. After a few weeks in February, several late nights and a lot of help from my wife and the Design in Flight's Editor Andy, my article "Feeling your way around grids: Making sense of the Golden Section when designing grid systems." has been published in the latest edition of Design In Flight.

Design in Flight is a fantastic PDF magazine and a bargain at just $3 an issue, which is about ?2. There are some superb articles in this issue from the likes of Khoi Vinh, Suw Charman,

Veerle Pieters and Molly E. Holzschlag.

It all started with a post I wrote on Design and the Divine Proportion a few months ago. The post sparked quite a lot of debate and is still amongst the most popular on this site. In the post I touch on the Divine Proportion, or Golden Section, and how it affects design.

In the new article I take that a step further and show how grid systems can be designed based on the Golden Section and how that not only aides the designers process but also increases legibility and usability.

Hope you enjoy it.

Centred or Informed?

This has been rattling around my head for a good 9 months now and I think it's high time I went into labour so to speak.

About 18 months I got into the whole User Centred Design approach. I championed the use and creation of Personas on particular projects, got into user flows and scenarios, conducted user interviews and performed other research. This was all before any design was done. This really got me thinking and Jeff Veen's latest post sparked me into action.

Is UCD too dogmatic?

User Centred Design is just that, a design process with the user at the centre. It's a widely used process, and works very well in producing a product that the user can use.

The thing is, and what Jeff hints at in his post, is that things aren't always that cut and dry.

UCD is quite a rigid methodology, some would say dogmatic. It requires resources - money and people, but most importantly it normally requires a culture shift either within an organisation or on the part of a client. Here lies the problem.

Culture shifts

Culture shifts are time consuming, expensive and don't always work. Key stake holders have to buy into the shift very early on and drive that change from the top. Even less 'top down' organisations have to have a key figure motivating that change across the divisions that need it. But UCD process is fundamentally a company wide shift in approach and culture. Let me give you an example.

A print design company, established over 15 years ago, offers a full service to it's clients from Branding and Signage to Websites. It's website offering has grown from brochure ware sites, to complex applications. It's team has therefore grown to include more web specialists rather than print designers. The creative director is the linch-pin of this company - what he says goes - and he's steered the company's creative direction for 15 years.

So, you've got this company whose creative director is used to working in a particular way which has served the company and industry well. I like to call it the "Designer Knows Best" model (hmmm, DKB methodology, got a ring to it don't you think?). All of a sudden a shift of culture is required by the company to meet market demand. UCD rears it's head. And all of a sudden, it's not about methodologies, it's not about users, it's about designers and their egos - end of story.

Maybe this example is a little cut and dry, but the fact of the matter is designers are taught to be problem solvers from a very early age (in career terms). Especially in print/branding circles it is the designers who deliver solutions (true, research generally informes these solutions) but rarely does the dogma of a UCD process enter into it.

User Informed Design methodology

What i'm talking about here is user research informing the design process. In UCD, this is formalised. You conduct tests, you design, you test again - iterate, iterate. Don't get me wrong it's a good model, but in a competitive market, where budgets are tight, there is simply not the resources, or impetus to change culture for a UCD process to be followed.

What i'd like to talk about is instead of User Centred Design methodology, many of us have already adopted a User Informed Design methodology.

The key differences between the two are:

  • Past experience. Use past experience rather than repeat user research
  • Get down and dirty. Adopt a similar working model to SCRUM. Get in there and start prototyping and designing straight way. Test informally as you go along.
  • Graphic designers do graphic design. Use research to guide functionality and UI - not graphic design. (I'm sure many graphic designers feel disenfranchised by Information Architects and Usability Designs solving a lot of the problems and leaving it up to the designs to "do the pretty stuff")
  • Boost ego. If your Creative Director is a bit a dictator, work with him to get at least some testing done but try not to prove him wrong - he won't like that. Try and prove him right, that way next time you propose more testing he'll probably say yes.
  • Forget science. Scientifically gathered samples and the subsequent agency fees for recruiting are expensive. Unless you want to adopt a strict UCD approach and have the budget and will to do it, forget the scientifically gathered sample.

In conclusion...

So some of this may not come as a surprise. To conclude, it's really all about being more flexible, relying on internal resources and your own experience with working with users before. It's about getting down and dirty with prototypes early and let the user research inform the design rather than dictate it.

Digital Futures

{title}Yesterday I attended a BBC run design event called Digital Futures, for internal designers and invited guests, on the future of design in a digital society. There was a eclectic mix of speakers planned for a packed day.

So, quite a distinquished list and it promised to be a interesting mix of presentations.

The event began with me nursing a hangover outside in the fresh air (you know the feeling, dizzy, too hot, too cold), thankfully after a good cup of tea and a few deep breaths I seemed to knock it into touch. Although I was pretty tired from putting up with a hotel room which was as hot as the sun.

After the usual pre-conference milling around, meeting new people and catching up with collegues from around the country, we all filed into the National Film Theatre on London’s South Bank. What a fantastic theatre and quite possibly the most comfortable seats in the world, and it was dark, I was at the back, and tired. Could be dangerous. These speakers had better be good.

First up… Brian Collin

First up was Brian Collin from Ogilvy and Mather in New York. I really didn’t know what to expect but it turned into perhaps one of the most memorable presentations I’ve attended. I can’t go into too many details because of copyright, but what he had to say was pretty inspiring. There was chocolate, soap and pirates along with every presenation technique in the book, all delivered like a seasoned stand up comedian.

He challenged my expectations of not brand and advertising but of process and handling clients. The overall idea was to challenge, not only your own expectations, but the publics and the clients. Break everything down to the most basic elements, then build it back up and see what you get.

Next… Neville Brody

I was really looking forward to this one. I’d written essays about this bloke in college, I know his work very well but had never met him or heard him speak.

He started off by going through some client work and took about twenty minutes to get warmed up to a very rushed, but incredibly interesting, final ten minutes.

Mr. Brody seems concerned. Not only with the direction of design but by the way it’s led by technology. As designers we seem to have lost our way, unaware of our roots and as a result produce meaningless work. Is this ok? yeah, probably (I think that was the general feeling).

It wasn’t until the panels that Neville said some truly profound things, at least for me, which really struck a cord. He told a story of a friend of his in New York, a designer in his 50’s, who’s lived by the mantra - “Form follows Function”. We’ve all heard it right? Some of us, me included, are beginning to understand it. At least that’s what I thought before he started talking about it. He said that his friend began to feel guilty because he liked certain things - designs, products, whatever - that were beautiful, but also quite rubbish, but he still liked them. Neville went on to say that beauty, entertainment, aesthetic appeal is all part of the function of a design and it’s ok to like things where funtion follows form, because form maybe part of the function anyway.

Inspiring.

Lisa Strausfeld

Lisa is an Information Architect working for Pentagram mostly on exterior information spaces. She gave an interesting presentation on the use of information in a virtual, and real, 3d environments.

I’m quite into information design and specifically the process of breaking down complex, rich, multi-layered information into an easy to understand, navigable space.

She began by showing examples from her work at MIT and then on to some commisioned work for railway stations in New York. Most of this work comprised of information environments to real space and comprised of Media Walls and Signage. Some really great work was on show and i’m sure you can look at some of it on the Pentagram web site.

Paul Mijksenaar

Most people, designers included, don’t notice signage. Or at least don’t notice good signage, when it’s doing it’s job well.

In the UK, we have great road signage, we have a world famous, wonderful Tube Map in London. It’s such a shame our airport signage is generally rubbish. This is where Paul Mijksenaar comes in.

Paul began a hurried presentation by going through his theories on wayfinding and the process of people getting from point A to point B and most of the cognitive patterns in that process. Really interesting stuff. He talked about colour coding and maximising colour combinations for legibility and highest contrast. All of this stuff about signage, as i’ve said before, is incredibly relevant for designing web sites. We need to be looking at traditional wayfinding and signage and moving the model into designing for the web.

Interestingly Paul talked about the death of pictograms in a future where wayfinding will be done on a mobile device. I’d never really thought about it before but it makes sense. Pictograms exist so manufacturers don;t have to create signs in many different languages. Once a user can choose their language, pictograms become useless, or rather they become secondary to the words. Or is it that pictograms are more rapidly understood than words? Certainly made me think.

Marco Susani

Marcos presentation was all about convergence of broadcasting onto several platforms, predominantly mobile, and how those devices integrate with other devices in your life - TV’s, phones, computers, video recorders etc.

An interesting presentation which was very focussed on technology but to be honest i’m getting a little tired of technology presented in this manner. there’s simply too much of it going on. Call me a little jaded, but I know there are going to be devices which integrate with telly, I know you’ll be able to watch movies on your devices on the train. I know all this stuff, but still question the motives to promoting the technology. Yes, companies want to sell products and yes they need to educate the public to do it. But it’s all too much. Too much technology, too many gadgets and too many companies telling us we need to keep up. By this point I was getting tired.

Bill Drummond

Bills presentation was a breath of fresh air. I won’t go into the details of the content as I got the sense that he didn’t want exposure for what he was doing but what I will say is it involved making soup and God. Let’s just say it made me re-evaluate my motivations for not only design, but for life in general. Deep eh?

Thank you Bill, you certainly woke me up.

Time for a pint

After the event we all walked over the bridge to get on a boat on the Thames and enjoy a drink or two before rushing to catch the train back to to Cardiff. Sometimes it’s great to listen to people who not only understand you, but inspire you also. Top notch, looking forward to June now for @media 2005.

Disclaimer: This article represents my views of the days proceedings and does not represent the views of the BBC or the attending speakers.

Aesthetic-Usability Effect

The Aesthetic-Usability Effect is a condition whereby users perceive more aesthetically pleasing designs to be easier to use than less aesthetically pleasing designs.

Now that the design industry, particularly for the web, is beginning to understand - and be more focussed towards the user, usability is becoming somewhat of a ‘given’. I think, in part, we’ve got the likes of Jacob Nielson to thank for this. Pioneers of Usability have raised it’s profile over the last ten years to the point that now even the clients seem to know more than you do. However, in my opinion this has been to the detriment of design. 

As the web industry has matured we’ve seen Usability move from the labs of HCI universities into mainstream development process. An unprecedented move in any industry, given the time it did it in. Usability gave the industry quantifiable evidence as to whether or not a website was doing it’s job. This is exactly what the clients wanted. Sure, they want their logo in the right place, the marketing department want to make sure the companies branding is correct, but the MD has read “Designing Web Usability” and wants to make sure the site does what it should, often at the expense of eveything else including design. Thankfully, those days seem to be behind us.

Usable conventions

At the moment I think the industry is deep in a period of consolidation. We’re seeing a period of reflection on the mistakes we’ve made, a maturity on the part of clients and agencies to take into account the users needs as well as the clients. Everyone is beginning to work to standards - both design conventions and technical standards (css, xhtml etc). Are we in danger therefore of diluting the design of the web into “usable conventions?”

This period of time is an exciting one for designers. It’s a period when design is the thing that defines, and differentiates, a product.

Audi or Skoda?

Let’s just shift to Car Design for a moment.

Cars have been around for ages - since Ford’s little black number. They all pretty much do the same thing and look similar. Four wheels, seats, they go from point A to B. Why do people buy one over the other? One word. Design.

Aesthetics and Car Design have been fused for many years. It’s what defines a car, it’s what gives a car it’s personality and importantly for the manufacturers, it’s what gives the car it’s competitive edge in the market place.

Let me give you an example.

{title}

What car would you rather have - a Skoda Octavia Estate, or an Audi A4 Avant? I’d rather have the Audi actually even though it’s much more expensive. Don’t get me wrong, the Skoda is a nice looking car but the company has never really shifted the stigma attached to the brand, which was brought about by bad, cheap design. Why did I pick those two cars? Well, they’re both the same really. Same chassis and parts, they both have four wheels, good fuel economy and safety, it’s only the design and brand which sets them apart.

The Aesthetics of the Audi make it a more desirable product and i’m sure if you did a survey you would find people thought they could use it better than the Skoda.

Look after the design and the usability will look after itself

I hope that illustrates my point. Good usability is inherent in good design because people think well designed things work better, whether they do or not. Focus on good design and you will make the product more usable by default, you will also give it a competitive edge. The MD will thank you… eventually!

Design tip: Just say YES to Lorem Ipsum

Prompted by a post at 37signals regarding the “unfortunate” usage of Lorem Ipsum in design comps. Interesting post, put I feel I have to put forward the other side of the arguement.

The basis of the 37signals post is, I think, they regard Lorem Ipsum text as abstracting the content from the interface. By using dummmy copy, you’re presenting a dummy interface. To a point I agree, but, lets face it, it’s a bit idealistic thinking that way.

How many times has a client asked you for visuals before they’ve commited to giving you copy? And what about pitching for work? Do you commit extra resources to write real copy? For a pitch??

There is a time and a place for Lorem Ipsum. I’d agree with 37signals and not use it at a wireframe stage, or final visual stage, for website presentation. But for print, Lorem Ipsum has it’s place and will continue to be used for years i’m sure.

When designing books for example, Lorem Ipsum is invaluable for creating typographic relationships and grid design (see my upcoming article for DIF) where copy does not exist, or is not finalised yet. It’s cost effective to spend time developing the grid with dummy copy before you have final text rather than sitting around waiting for the manuscript. Typographic designers have used Lorem Ipsum for generations, with the lack of final copy, for developing form and a balance between typographic elements but more importantly for a quick representation of the final product for the client to buy into. Now for web design and specifically for applications, that’s a different story.

Accessibility and Design are the same thing

Prompted by a letter by Nigel Gill, accound director of Sigmer technologies, in this week’s New Media Age (page 17) I just had to get pen to paper so to speak.

Nigel states in his letter that “general design opinion seems to be that accessibility is diametrically opposed to great design”. What? Is this true? He’s obviously not talked to any good designers. He goes on to talk about how you define design, information architecture and usability etc. Which is all really valid, but I can’t quite get past his opening sentence.

Now, Mr Gill may not have worked with good designers before. He may have worked with print designers who are new to the medium or simply designers who don’t see accessibility as part of their remit, or probably designers who see accessibility as a constraint rather than part of the medium. Accessibility doesn’t mean dumbing down. It doesn’t equal bad design. Is really should equal great design. Take architecture for example.

My father is an architect. He’s designed all sorts of building types for the past thirty five years. A couple of years ago the DDA act in the UK made it UK law that all buildings had to be accessible. This doesn’t just mean sticking a ramp at the front, it is a lot more complicated than that. Public buildings, such as libraries, for example should have accessiblity requirements built in to the fabric of the building - ramps, braile signage, hearing aid loops, attendents who can sign etc. It shouldn’t be dealt with as a bolt-on extra.

I asked my father about this a while ago. What difference did DDA have on his work and the buildings he designed. His reply was “it makes them better”. He went on to explain the DDA is a set of guidelines which good architects took into account anyway and bad one’s now need to follow. The same can really be said about designers.

Accessibility is Design. It’s part of the problem and therefore should be part of the solution. The two are intertwined and accessibility shouldn’t be seen as this black cloud on your design radar.

Expression Engine - Designers Questions Part 2

Following several more emails from designers, I thought i’d compile some of the questions in a follow up to Expression Engine - Designers Questions.

Many of the questions have been related specifically to the reason why I bought EE in the first place - my portfolio. You may recall some of my reasons for changing to EE, one of those reasons was the ability to add custom fields, this makes EE invaluable for both clients sites and designers portfolios.

Some more questions

Why should I spend money on EE when there are free systems which offer more functionality, eg forums, threaded comments etc.

Well, for me it’s not so much a question of out-of-the-box functionality but more that EE fits very well for me as a designer. It allows me to customise the data sets and importantly seperates templates from the tags, that way I can produce valid XHTML code and use CSS for the styling. This is something other CMS’s don’t do, such as Mambo. Although Mambo is a pretty nifty system a lot of the built in modules and plugins produce invalid code which, unless you’re very familiar with php, you have to use.

I’m not picking on Mambo specifically here, a lot of CMS’s, blogging software and CMS frameworks do the same thing.

How do you move from a weblog idea to create sections in a commercial site

This involves thinking slightly differently to EE’s documentation. Where it says ‘weblog’ think ‘section’, where it says ‘entries’ think ‘pages’ and so on. This site is created by several ‘weblogs’, in each one there are categories and then ‘entries’ for the pages of content. They also all have custom fields for their content.

How do you handle global includes such as navigation and footers?

In the past i’ve used php to include files, such as navigation and footers, on my server. You can still do this in EE by turning on php parsing in the template preferences. My preferred method however is to create a seperate template group called ‘includes’ then each template within this group is a template I can include throughout my site using the embed tag. This downside to this is it’s another query for the server, but this is a minor point when you consider all of your content is now accessible and editable from within EE.

Can I use my old design from pMachine?

I’m not that familiar with pMachine, but as far as the html and css goes I can’t see this being a problem. Simply take the html into your favourite html editor, take out the pMachine tags and replace them with the EE tags. it should work ok.

Can I have flash in a post?

Yes you can. There is a plugin available and you have make sure .swf is an acceptable upload file format. You can do this in your weblog settings. You can also have Quicktime embedded as well with a similar plugin.

How did you build your portfolio in EE?

I’ve had so many emails asking this question. I could’ve saved myself a load of typing and posted this weeks ago. Never mind. here’s the run down.

Decide what your content will be

<

p> Firstly decide what content is going to be in your portfolio. Is it going to be just images? Images and captions? Detailed text? etc. These are the different requirements I had for my portfolio.

  • Title
  • Client
  • Small promo image
  • Small promo text
  • Introduction text
  • Extended text
  • Screenshot 1 title
  • Screenshot 1 image
  • Screenshot 1 caption
  • Screenshot 2 title
  • Screenshot 2 image
  • Screenshot 2 caption
  • Screenshot 3 title
  • Screenshot 3 image
  • Screenshot 3 caption
  • Screenshot 4 title
  • Screenshot 4 image
  • Screenshot 4 caption
  • Screenshot 5 title
  • Screenshot 5 image
  • Screenshot 5 caption
  • Related links

<

p> I also needed categories with which to categorise the portfolio entries.

  • Digital
    • Websites
    • Applications
    • User research and strategy
  • Print
    • Branding and identity
    • Print communications
  • Archive

Now I have a basic idea of the content and the categories with which to label the content I can set up the weblog, or section, of my site.

Set up EE

Firstly, create a new weblog called ‘Portfolio’:

{title}

Then set up the categories:

{title}

Next, set up a new Custom Field Group and call it Portfolio.

{title}

Then, add your content headings choosing the correct field types.

{title}

{title}

Now you have your Custom Field Set. Go into your weblog management and select your new Portfolio weblog. Click Edit Groups, then choose your new portfolio field group from the dropdown menu. Now, when you publish a new entry you should see your new field group being used.

That’s the data side of things covered. After inputting all of your new portfolio information into your new field group you should have all the content ready to start building the templates.

<

p> My portfolio templates have basic EE tags controlling all of the dynamic stuff going on and it has many similarities to weblogs. I have four templates.

  • Index
  • Category
  • Detail
  • Screenshots

The index page is a bunch of queries to the different categories. The portfolio entries which are pulled out as promos (the one’s with the images across the middle) are simply made ‘sticky’ which brings them to the most recent entry within their category. The index page then queries the database and the category and pulls out the most recent, which is the one i’ve defined as being sticky. this allows me to rotate the promoted portfolio entries very easily.

The other templates are self explanatory. The category templates displays the parent category entries. The detail template shows the extended text and the Screenshot template shows the various screenshots controlled by a simple javascript gallery. I’d like to combine the Detail and Screenshot templates and use simple logic to display the content depending on what you click on the page. I think this can be done with the segment tag, but i’m not quite sure how to do it at this stage.

So basically, that’s about it. You can have whatever you like in your portfolio - flash, quicktime, images, text. The only real limitation is your imagination.

The do’s and dont’s of Guide Book design

{title}I thought it would be good to conduct a bit of research for an upcoming article i’m writing.  Guidebooks are a kind of book I just can’t do without when going to a different country or, especially, on a city break.

On a city break, if you’re doing the whole cultural thing, you generally need overviews on what’s available, but then more information if you want it. You also need maps, and good ones.

For someone who had relied on Guide Books pretty heavily travelling throughout South East Asia, Europe and Australasia i’ve become very attuned to the design of guide books and specifically how a badly designed book can have a seriously detrimental effect on your travel experience. Like I said, I was thinking about this the other day whilst researching this article i’m writing and was thinking about a couple of things - 1. The design, 2. The access structure and 3. The information architure.

Sound familiar? A lot of the user/reader requirements mirror website requirements. A guide book, like most reference material, is constructed in a non linear fashion, categorised by location and meets the users task.

An author who understood this is Richard Saul Wurman, the father of Information Architecture, and his Access guidebook series.

{title}

I’ve seen a few of these books, but have yet to own or use one in the way it was intended (note to self, buy Access guides). I know the design and access structure of these books is by and large incredibly well considered, from maps and clever ways of orienting yourself, to well structured typography.

If like me you’ve had the unfortunate experience of going to a city with a bad guide book, you’ll relate to what i’m about to say.

A few years ago I took my girlfriend (now wife) to Barcelona for a surprise birthday trip. I borrowed a Time Out guide to Barcelona to make sure we made the best time of the couple of days we had there. As my father is an Architect I should have known all about Gaudi and his beautiful buildings. However, if you’ve grown up with a father as an architect you learn not to listen at an early age when he rambles on about crumbling buildings all over the world. Therefore I didn’t know anything about Gaudi. The guide book should have informed though. It didn’t, and we missed it.

I think the Time Out guides are great if you plan to spend more than a few days in a place, or you live there, but for a trip of a day or so I really don’t think they cut it.

So, back to the reason for this now rambling post.

What do you look for in a guide book? Does design inform your decision? Are loyal to a particular brand of book, eg Lonely Planet?

It’d be interesting to see some of your thoughts.

Top five design books

{title}After my trip to London, and the Design Museum, over the weekend I thought i’d share a purchase of mine.

I was led to believe the Design Museum had a great bookshop, which turned out to be almost the case. Yes there were some good books, but they were the usual coffee table type (you know - big, pretty pictures, the latest hip designers from the planets hip studios). All a bit dull really. That was until I noticed a stack of blue books in the corner, covered with a thin layer of dust…

There, nestled next to the “A 1000 signs” and “Multimedia design” was a book which grabbed my attention.

Universal Principles of Design by Jill Butler, Kritina Holden, Will Lidwell looks like a boring school textbook. The book looks pretty uninspiring, blue and white with thin Helvetica adorning it’s cover. But this was just the thing I was looking for.

<

p> The synopsis is as follows (from Amazon)

Whether a marketing campaign or a museum exhibit, a video game or a complex control system, the design we see is the culmination of many concepts and practices brought together from a variety of disciplines. Because no one can be an expert on everything, designers have always had to scramble to find the information and know-how required to make a design work - until now.

This comprehensive, cross-disciplinary encyclopaedia of design pairs clear explanations of every design concept with visual examples of the concepts applied in practice. From the “80/20” rule to chunking, from baby-face bias to Occam’s razor and from self-similarity to storytelling, every major design concept is defined and illustrated for readers to expand their knowledge.

A rather long-winded way of saying that this book lists many design theories used throughout the design industry as whole - from product design, to fashion design.

It easily explains the Golden Mean, the Rule of Thirds and many other important theories we, as designers, can all learn from. Actually, many of these theories are not taught anymore in design school, which is a crime. Students are graduating purely operating on instinct where their designs are concerned, no theoretical decision making has entered the process. Although saying that how many designers have you worked with who exhibit working knowledge of these theories? I haven’t worked with many.

Anyway, back to the point.

<

p> This book is very interesting and well worth getting hold of. It did get me thinking of my top five design books. So here they are (in no particular order):

  1. Universal Principles of Design
  2. The Elements of Typographic Style
  3. Grid Systems in Graphic Design
  4. Typograpie: A Manual of Design
  5. Designing books (out of print now)

If you’re serious about extending your knowledge of design theory, especially typographic design theory, then these are the books to read in my opinion.

So, in true “top 5” tradition. What are yours?

Are users blind?

There’s currently a lot of talk about whether users are blind to this, blind to that, don’t look at this, ignore that. So I ask you, what do they look at?

A while ago I also commented that users generally don’t read and use visuals clues to access the content they are looking for. Usability designers go blue in the face preaching this very theory but typographer’s have been doing this for centuries. It really is nothing new. So, what’s my point?

Well, i’m currently at the starting points for my article for Design In Flight. One of the sections in this article is going to be about Access Structure, from a typographic angle. I won’t give too much away as i’m sure Andy will want you to buy the magazine ;-).

Basically Access Structure is just that - how people access content. In book design access structure is made up of several page components - folios, running heads, content pages, index etc - in addition to typographic heirachy. A lot of these conventions have been around for hundreds of years in one form or another. They are conventions that people, and let’s remember that users are people, have been used to looking at for that duration. (more detail on this in the upcoming article)

I think we, an industry, can work a lot harder so that our readers/users can access the content they want quickly and effectively.

Instead of looking towards usability gurus and modern web accessibility practice, what can we get from the past?

What can we learn from book designers, typographers, signage and information designers that we can then apply to modern website and application design so that our users are not blind to the content, but use it? My guess is, a lot.

What’s missing from DIF?

Finally after months of wondering if it was worth it (yes, yes, I know it’s only ten bucks) i’ve finally subscribed to four issues of DIF. I’ve got to say, so far i’m very impressed.

The content is good and very well positioned to appeal to seasoned industry veterans and novices alike. But, yes there is a but…

I found the content didn’t address some of the core fundamentals of design theory - eg, colour, balance, typography, grids etc. Now maybe DIF isn’t the place for this. But I feel that some solid theoritical articles, especially surrounding a dying practice of correct typography and grid design, were missing from the issues I have.

I’ve been thinking of a number of articles that I might write for submission, and if they’re not accepted then i’ll just leave them posted up here.

So, what do you think should be in DIF? 

Design and the Divine Proportion

Many designers, whether traditionally schooled or not, have trouble with composition. I’ve sat with plenty of designers who simply moves things around until they feel ‘right’.

Design is, in essence, communication (I know, I know, I rant about this enough, but this isn’t one of them) but the vehicle for communication is the design. One of the key components in the vehicle of communication is composition, and in design schooling it is something that is taught as something you should feel rather than create logically. This has always bothered me.

The feeling

When creating a design, or composing a photograph, we reach a point when we say ‘that’s right’ (or ‘that’ll do’ depending on the deadline and budget). How many of you create compositions based on feeling rather than logical thought? (come on, hands up). Well I do, but i’m beginning to think more about what underpins that feeling.

The Divine Proportion

Remember back to your art school? (If you went that is). Who remembers the Golden Section? Ok, so who understood it? Or more importantly, how to use it? Well I answered yes to all of those except the last one. I seem to recall the lecturers not fully understanding it either. Well, i’ll do my best to shed some light on it.

The Golden Section, or the Divine Proportion is a visual representation of a number called Phi (pronouned fi). Oh, and before I go on, yes I have read the Da Vinci Code! Anyway, Phi is a number produced by bisecting a line at a particular point (see diagram below.) Phi is 1.618033988749895, or by the numerical sequence called the Fibonacci sequence.

So, what has this got to do with design?

Well, in short, a lot.

The Phi is evident everywhere in universe - Nature, Space, Physics, Mathematics, Physics, Art and Design. Phi creates the Divine Proportion (so called by the renaissance artists because of it’s abundance in the known universe, they thought it was created by God), the Divine Proportion is used by artists and designers.

So, here’s the thing. Using the Divine Proportion as a guide to your compositions can improve the communication of your design.

How? By creating a natural language your brain understands. If the unique ration Phi creates is all around us, it stands to reason that designs created this way are more comfortable to us and therefore do their job quicker and more effectively.

Using Phi in your designs

It’s all very well talking compositional theory, but putting it into practice is another thing entirely. Hopefully I can shed some light on it.

Let say for example you have to create a poster design. You start by deciding the size and dimensions of your paper. I start by deciding the height and the I want this to be a landscape poster. The height is going to be 64cm. So, I take that height and create a 64x64cm square from it. I then take 64cm and multiply it by 1.62 (you can use the whole sequence by rounding it up at the point is ok.) Which gives you 104cm. This is the full width of your poster. This is shown in the diagram below:

poster size showing Divine Proportion

So, subtracting your initial height (64cm) from your new full width gives you the all important Divine Proportion line.

This is a very important compositional line and feels right. The poster can then be designed around this to create a balanced image. Here’s an example:

Final poster designed using the Divine Proportion

Conclusions

There’s nothing new in what i’ve said, in fact Da Vince was doing it all yonks ago. But this practical theory seems to have been lost in the design education system, being taught by design lecturers who themselves don’t understand the nuances of composition theory. Hopefully here i’m giving some understandable, but more importantly, practically information on how to compose designs based on logical thought and simple rules, rather than just ‘a feeling’.

If this has been helpful to you? Also if you have any other nuggets of design theory that could be added to this post let me know.

Site relaunch

So, here we have it. Version 5.5 of this site. More of a Reversion than a Redesign. As I mentioned a few weeks ago, MovableType was beginning to be difficult to use because of the Spam problems (which they seem to have now fixed) and the increasing problem of stretching the intended useage of MT - ie. to run a portfolio (I know this is possible, as I did it before, it’s just not as easy as i’d like). I moved to using Expression Engine as the software to power the site.

Read on for more about the design ethos behind this site. Why do a redesign and what I discovered about web standards, css, expression engine and mac IE 5.5 on the way.

The design

Why do a redesign? Well, I’d already redesigned a few months ago but already the design was beginning to get on my nerves (as a designer, this tends to happen with your own work.). It seemed to heavy, a bit to ‘state-side’ for my liking.

I wanted the design to really reflect what i’m about as a designer with a typographic background. I set myself a bunch of typographic goals, such as:

  1. Correct usage of heading sizes
  2. Relationships between all typographic elements
  3. A balance between the grid and the typography
  4. An timeless feel, stripped of meaningless decoration
  5. Sympathetic use of colour

The list does go on, but i’ll stop there for now.

I’ve approached the design of this site as I would the design of a good book. You don’t notice the design, if you do, the design is bad. You shouldn’t notice good design. (as one of my lecturers at University used to tell me. At the time I thought he was mad, but i’m beginning to see his point.)

I will talk a little bit more about this design shortly.

Web Standards

I didn’t learn too much more about Web Standards redesigning this site. I trimmed the markup, went Strict with the XHTML and separated the colour into a different stylesheet.

Expression Engine

Expression Engine surpassed my expectations in almost every way. It’s an extremely quick platform on which to develop and it’s ‘out-of-the-box’ functionality is second-to-none. Not really the time to delve into this at the mo, but I will shortly.

So, in summary i’m very pleased with the reversioning of this site, pleased with the overall design. What’s most important is it’s a solid base on which to build. I’m sure over the coming months there will be plenty for me to add, so expect a certain amount of spit and polish being applied!

If you do spot any errors (most likely caused by the migration from MT), please let me know. Cheers.

A few things of interest this morning…

Apple iPhone prediction confirmed.

I didn’t think it would be long before this was confirmed. Personally i’m sold already and I haven’t even seen it! I’m such an Apple whore.

Targeting Small Screens - Stopdesign

Doug’s back with a great writeup on targeting small screens for your designs.

WDW2004 keynotes available as video

Speakers include: Jeffrey Zeldman, Jason Fried, Ethan Marcotte & Molly Holzschlag

On another note. The migration to Expression Engine is going well although still quite a lot to do with the design. Some of the portfolio may have to be redesigned again due to EE not being able to do some of the conditional logic I want it to. Never mind, there’s always a different approach.

BBC Wales music site launched

Following a few months of work the BBC Wales music site has been relaunched with a more advanced technical backend, partial CSS and much tighter information architecture.

Designed Christmas Cards

Christmas card design for this year

Last year we spent a fortune on generally crappy cards. So this year I thought i’d do them myself and after a very reasonable quote from a printer I realised we’d actually be saving ourselves quite a bit of cash. Following on from Andy Budd’s idea, it’d be nice to see any designery Christmas Cards you may be producing. Post the url to the image on your server in the comments.

Typography rant

Sometimes, ‘designers’ just p**s me right off.

Let me explain.

I’m a regular reader on Stylegala, a website dedicated to css / web standards and design. It’s a great site. In fact my site was featured on it in August. On every entry on Stylegala you can comment on the sites featured. I had a quick look today and came across a comment thread which annoyed me so much I had to write about it here! The thread in question is the one about the site Epocrates. David at Stylegala gives it a pretty good writeup, but he is disagreed with, quite strongly, in the thread of comments. Have a read of them.

It got me worked up again about the state of the industry’s general understanding, and working knowledge of, correct typography. Occasionally I have a rant about this sort of thing, and today’s rant is not really any different from the others. It all began with a comment by some bloke called ‘beavis’ ...

OK maybe I should have added more. I have seen hundreds of sites like this. I cant see what makes this special. Its anything but original. Why say it’s good typography when it is absolutely awful typography? Please go to sites like misprinted type for excellent typography and look up the definition of the term.

I took his advice and had a look at misprintedtype. It’s ok, although nothing new. The typography is really quite dated - I remember all of Ed Fella’s work from ten years ago, this stuff hasn’t progressed much from that. So, in short I really disagree with his comments. It shows a real lack of understanding of typography, and more importantly of the tradition from which it was born. How can designers like this have so little respect for this? I just don’t get it.

Apple green is *so* the new black

I am just a sucker for Apple green at the moment. In case you hadn’t noticed, it is everywhere! So, on the weekend I bought an apple green t-shirt and here’s a nice apple green website for company called Forty Media, nice design, nice christmassy look about it at the moment. The tone of voice is just right as well.

Cardiff Screen Festival - Focus on Interactive zzzz

Having just attended the morning sessions at this annual event (my first time btw) I just had to get something down here before I forget.

The thing about these kind of events is that most people want to get at least something out of it, personally as well as professionally. You might want to find out, as a designer, what is happening in Wales at the moment in terms of New Media. You might, as a client, want to see what the possibilities are for your product or service. Invariably events like this fail to deliver on these simple wants and needs.

I went to SXSW in Austin, TX in March of this year and was expecting the same old boring excuses to plug a book, a service, a product of some kind. but I was pleased to see that it only happened a couple of times. SXSW speakers (generally) were superb, eloquent, passionate professionals who inspired the audience.

Now, surely i’m not expecting Cardiff Screen Festival to be the same? Well, why the hell not? Why do all these events in this country, Wales especially, degrade into political rants about public service organisations or just simply bore the audience to tears with manicured, predictable presentations delivered as if you’re presenting to your grandmother? (you get the impression I wasn’t too impressed?)

Now, there were some interesting points that were made, some interesting products (although don’t get me started on the usability of a pda as a broadband wireless exhibition/location guide - that really is stretching the technology model.) but the emphasis was on products or services being sold in the guise of a ‘case study’. There was no honest debate, up to point when I left. There was no discussion on ROI, no discussion on market, in fact no discussion. It was all one way.

It was very difficult to sit through. Let’s hope they get it better next year.

Rather nice site

Having featured on Stylegala when this site was launched I regularly look at the gallery and say the odd thing in the forums. Occasionally a site featured on the gallery jumps out at me as being something rather special - today was one of those days.

Simmons College website is very refreshing, not only in terms of CSS, but also in terms of design. The palette is spot on, in design trend terms - earthy, pastels, calming colours. The inspiration is from the illustrations used on the site (and it’s nice to see illustrations being used). The typography is also very tasteful. Clean serifs and san serifs throughout, although sometimes they don’t quite work and look a bit cluttered.

Very nice site though and well worth ten minutes of your time looking round it.

New article

Just posted the first the series of the Grid Articles. The first in the series - Why use a grid? - explains just that. The rest of the grid series:

  1. Why use a grid?
  2. A grid for the printed page
  3. A website grid
  4. A purists view on website grids
  5. Where next?

Any comments about the latest, and upcoming, articles can be posted here.

Where am I?

Had an interesting discussion today at work, mostly based on branding, but it made me think about some interesting things about user orientation. How many times have you asked yourself “Does this navigation work?”, or how many times has a project manager/client/boss asked “how does the user know where they are?”. My guess is quite a few.

A lot of these question focus totally on UI and design and not on what the user wants. Really when these people are asking these questions they really mean “i don’t understand this design” or “I don’t know where I am”. They are thinking of the user, but they’re thinking of them as being like them.

Here’s where I go out on a limb. I’m suggesting users don’t actually care where they are, they care what they are doing. This might seem obvious to some, and to me, but then I really started thinking about it.

If a person is reading about, say family history, on the ITV website. They then follow a link to another website about family history, do they know they are in another website? Probably. Do they care about brand affinity when they are in a different website? Are they aware of a different brand? probably not. Because they are reading about history.

Location isn’t an issue. The task is.

It’s similar in a car park. When you drive into a car park, you are focussed on finding a space nearest to your destination, this is your goal. Do you care about the design of the car park? No. You only care about it when it goes wrong and you’re directed up the wrong way or you can’t find the exit. It’s exactly the same with websites.

Brand and navigation should be designed to be invisible. What I mean by that is they shouldn’t get in the way of the users tasks, they should support them and help them when they feel they need it.

I know i’m rambling but I wanted to get this down on paper so to speak so I don’t forget it. Feel free to argue…

MovableType 3.1 is a beaut

markboulton.co.uk finally goes 3.1 after beig involved in the beta test.

MovableType 3.1 was released today. I’ve been involved in the beta test, and as such was not allowed to install it on any production websites, but as of five minutes ago this site is fully 3.1 and so far working without a hitch.

True, i’ve not yet included any of the functionality that comes with it, but that will hopefully come over the next few weeks - i’m looking forward to seeing how dynamic templates will work with the complexity of some of the templates I have on this site.

I’ve also installed some of the plugin pack - BlackList & MultiBlog. The others looked ok, but not very useful for me. Once this site gets a little more bloated I guess i’ll have a look at either of the search engine plugins.

New site on Stylegala

This site has been put up on Stylegala and is currently number 4 in the voting. Nice one.

Not the best write up i’ve ever had, but the comments back are good and has made me think about altering a couple of things.

  • The write up is right in that the menu is a little old-hat. I think this needs to change. Maybe into tabs. Not sure yet.
  • The design needs some finesse. Some spit and polish. But i’ve got a solid base now on which to add that - I know I won’t be polishing a turd.
  • There are some issues, as highlighted, with navigating within the portfolio section. This section has a linear navigational model rather than multi-level, like the rest of the site. Needs some work to make it more usable I guess. I’ll have a think about that.

The Relaunch

Update: Slight changes to the design, some problems with the old design. Mac Ie stylesheet deleted until I can get it to work properly.

Here it is, my new site.

As you can see a lot of changes have happened. In fact a (near) complete redesign has taken place. Only the journal remains pretty much intact (data wise). Everything else you see is brand spanking new. In fact I can’t quite believe it myself.

A year in the planning and designing and two months in the making. It’s been a great learning experience, even if it’s one I wont be repeating the near future.

I still have tons to do, such as populating the portfolio with old and new work. In the meantime you can still look at the old portfolio here .

A more detailed post will follow this shortly regarding the redesign. Until then, feel free to have a look around.

Some recent launches

Whilst I was away on honeymoon there have been a number of launches at BBC Wales on the “Slash Wales” service (as it’s being marketed - no comment). Anyhow a number of these sites have been in development for nearly 12 months.

They’ve seen a considerable amount of work on the backend and represent re-engineered content management system and a shift in production methodologies - with an emphasis on User Centered Design, Web Standards and an Object Oriented Approach to the content management, with extensive look at cross promotion and meta data.

In Pictures
in pictures
In Pictures pulls together a lot of content from across the BBC Wales service relating to images and puts it into one place. This was a first go at creating a generic style for all functional portals using CSS to render as much of the presentational information as possible.

Development / IA / Design / CSS

Surfing
surfing
This site represents the most work. A complete reworking of the Information Architecture, User Interface and a lot of time spent on the graphic design integration with the new content management structure. I’ll be giving a more detailed breakdown of these sites once I get my portfolio redesigned.

Development / IA / Design / CSS Implementation

Weather
weather
This is phase one of the weather portal. It’s not quite right yet. The weather app needs some work from a usability point of view and the overall green/blue feel has been lost with the introduction of the garish purple. Hopefully this will be addressed in the next phase.

Development / IA / Design

Blogger has been “Bowmaned” (and Adaptive Pathed)

Yesterday saw the relaunch of Blogger. All the “Web Standards” blogs out there were thick with praise for this redesign (I guess most of them don’t actually see beyond Doug’s great design and the Standards implementation). Doug has documented the process which has some great insights into this new launch.

I think the real success here is the Usability work done (and Dougs interpretation of the required “Ease-of-use"). The work Adaptive Path have done is fantastically elegant.

Good design shouldn’t be noticed. A very well design book, or newspaper, just works. The design doesn;t get in the way of the message. The new Blogger site is a wonderful example of this. Ease of use was of upmost importance, Jeff Veen points out that the Blogger wanted to be able to set up a blog, in three steps, in less than five minutes. Quite an undertaking.

The registration process is superb, one of the best i’ve used. Ever. It’s so simple even my mother could use it (and that’s saying something). Here’s some grabs of the process. What’s nice to see is contextual help links next to items that you may want help with.

blogger registration panelblogger registration panel 2blogger registration done screen

The new Blogger logo is a good step on from the previous version and it ties in very well to the overall “curved” look of the site. I’m not over familiar with the original version of the logo, but I do know it was square, orange and blue. It’s a great logotype though. It carries a lot of the brand values - ease of use, approachable etc.

blogger template selection screen

There are plenty of new templates available with the new Blogger, and all of them configurable from within the Blogger web-based interface.

The templates can be seen in full here. Some great designs from Zeldman, Bowman and Dan Cederhome (although there are a couple of lemons in there too, but maybe that’s just me).All of the templates are XHTML, with CSS driven presentation (as you’d expect from authors like this).

Some interesting sites

Some good stuff on these sites:

www.informationdesign.org
This sites got a LOT of resources. From Accessibility to Personas, Metadata to Writing. It’s got it all.

www.cssvault.com
Some really nice examples of CSS driven sites. Some good archive stuff, as well as some examples of what not to do!

Some useful sites

Got these links from my new “Recent Links” sidebar (which has been good, I check it most mornings)

ColorMatch
EditCSS extension for Firefox
This thing is great for on the fly changes. It loads the current stylesheet for the page you’re viewing and you can make changes. Then you can save it. Very useful.

April the 1st funny-ness

I got into work this morning, promptly fired up safari and checked over at Stopdesign (as I usually do every couple of days). He’s changed the design slightly…

Icons, Wayfinding and Semiotics

Users don’t read. I’m not just talking about web users either. Ever spent more than 1 second reading a road sign? Ever spent more than 1 second reading a direction sign in a public building? Ever spent more than 1 second trying to use a websites navigation? That’s my point.

Designers for the web need to look more at systems design, semiotics and wayfinding for cues for their interfaces.

Take iconography for example. Iconography, especially in computing, has arrisin with the advent of more complex GUI’s, BUT it has risen primarily because of a series of common tasks which need to be illustrated in some ‘real world’ way.

IconsThis Image shows a number of icons displayed which show a number of common tasks. As you can see the design of these icons vary, but only subtly. There are some in each set which ‘feel’ right however, these are the successful icons which tap into the unconsious cues associated with semiotics. I question icon design and it’s validity within design. My experience of ‘icon’ design (and i’m not talking branding or logotypes here, just icons) is thay are a) Are not thought about in enough detail b) They are almost always decorational, therefore their function is often secondary to how they look. c) Most icons are so badly designed they need words with them in order to decifer their meaning. Not good.

Here’s a good essay on iconography and semiotics. Have a read, it makes a lot of sense.

Talking of system icon design, this is a great resource for comparing operating systems and their iconography.

Probably more on this later, when i’ve thought a bit more about it.

For the latest and greatest in Web Standards design

Have a look at the Web Standards Awards. Nice looking site in itself but previews some really good standards compliant sites globally.

Elsewhere