On November 27th, I attended Mark Boulton’s workshop about designing grid systems. It took place in Cardiff, UK, on the day before Handheld conference.

In the first half of the workshop, Mark taught us the basics of grid design theory. In the second half, we were put to work and made our own grid-based design.

Mark emphasised that the design of (the grid of) a website should be a system. He said humans are pattern-recognisable machines, that humans recognise order. Grid systems can help create such order. Hence the workshop name: it was about grid systems.

First of, Mark went through some history of grid design and type design in general. Grids have existed long before the web. Very long ago, the decorative type in books had already some kind of system, but things really started with the Swiss graphic design in the 1960s.

Odd columns can create tension and balance.

Grid systems, Mark said, are most obvious in long form editorials, such as newspapers or magazines. In those places they make the content easier to read. In a lot of print work, odd columns prevail. Print designers do this to create tension and balance. It can ‘unsettle the eye’. In web design, even columns are often used.

One grid does not fit all, in contrary. If a grid doesn’t work for your content then you need to change the grid, that’s ok. Creating a good grid takes a lot playing around with the content you have available. This is why Mark feels grid frameworks that you have just downloaded from the web (like Bootstrap or the older 960 grid solutins) often don’t work.

Types of grids

Mark explained different types of grids: columnar, hierarchical, modular, baseline and compound grids.

• columnar grids can be subdivided into regular and irregular grids. UX designers use the term ‘swim lanes’ for groups of grid columns that form one big column. There can be different ratios in between the columns
• modular grids are hard to do on the web as height in browsers and devices is difficult to work with (and perhaps not desirable)
• baseline grids are most often used to prevent ghosting (the effect that happens in books if the text on the page behind the page you’re reading does not have the same baseline). On the web, there is no ghosting, and using a baseline grid can start to dictate undesirable line-heights. See Mark’s “Incremental Leading“ about this.

Avoid too many columns, it makes the grid less powerful.

The main point of grids is that it can make different pages that use it feel like ‘one system’. The more columns a grid has, the less power it has to come across as one system. Mark recommended to avoid too many columns.

Terminology

Mark also explained some of the basic terminoloy in grid design. A grid designer needs to know what margins, gutters, modules (or ‘units’), columns, hanging lines, offsetting and fields are.

On hanging lines

Good typesetting, Mark mentioned, is like good conversations, or if you like, a good talk. A good talk makes use of pauses, inflections, etc. Something like a pause in a talk is very fragile, it is hard to say when it is ‘just right’. Hanging lines can make typography better like pauses can make talks better, Mark argued.

On gutters

If your gutter is small, you can add a line to it. Newspapers sometimes do this. On the web, if you put a 1px line in your gutter, it can be useful to have a gutter with an odd width (so that the line plus surrounding whitespace are an even number). Sometimes gutters are defined by the padding within the module. Mark mentioned that this approach can require more mark-up, I have not yet done the comparison myself.

On DNA of grids

For years, web designers and web developers have come up with solutions to create grids on the web, a famous one being 960. According to Mark, grid systems like 960 are too limiting. Also, they have their own “DNA”. If many sites use the grid system, all of those sites end up having the same DNA. That threatens original web design.

Designing a grid system

In a lot of graphic design, the design is tied to the page size, Mark called this ‘knowable space’. On the web, there are no book-like pages and thus no page size, no dimensions that you can be sure of. Yes, grid systems for the web are hard.

We should design content out, not canvas in.

For that reason, Mark argues we should design content out, not canvas in. See also his “A Richer Canvas” article from 2011. This means you use your content to derive a canvas from, rather than start with a canvas and lay-out your content on it.

During the workshop, Mark explained three steps to designing content out:

1. Find the knowable, fixed content sizes
2. If there aren’t any, make some up
3. Use them to design your grid

Grids are a system, as Mark said in the beginning. He mentioned three ways to ensure this basic principle:

• Relate everything back to the module
• Use repeated ratios
• Bind the content to the grid

Putting it into practice

The second part of the workshop day, we were put to work. We were given the choice between four projects, or could work on our own side project. The goal was to create a grid system. Mark gave us individual feedback and reviewed some of the projects in front of the class. This was of great help to those who had worked on them, but not much less for the rest of the group.

Mark Boulton’s workshop was very useful, and had a perfect mix of theory and practice.

---

Originally posted as Mark Boulton's grid system design workshop on Hidde's blog.

Reply via email

Last week, the World Usability Day Bristol was hosted in MShed, a building that is home to Bristol’s city museum with the same name.

The view from MShed

World Usability Day 2013 happened in lots of cities all over the world. This local edition was organised by Nomensa, a digital agency based in Bristol. The conference featured speakers discussing a variety of subjects, including interaction design, accessibility, dark patterns and the possible future of the web. It was well organised: the venue had a great view of Bristol, lunch, scones and tea were all taken care of and all of tickets were very affordable.

My focus here will be on three talks that I particularly liked, about practical abstraction, the BBC’s super accessible olympics website, creating cross channel user experiences.

Dan Klyn: practical abstraction

In his talk, Dan Klyn focused on architecture, rather than design or usability. He tried to connect ancient Roman architecture principles to modern information architecture principles.

In Roman architecture the triad of firmitatis, utilitatis and venustatis were considered the main principles of architecture. Roughly translated, they correspond to strength (or firmness), commodity (or utility) and beauty, respectively.

In Roman architecture the triad of firmitatis, utilitatis and venustatis were considered the main principles of architecture.

Different architects in history can be said to adhere to different equations of those three principles. Buildings that were designed by the American architect Frank Lloyd Wright often had leaking roofs, they lacked firmitatis, but they were both useful and beautiful. A software example: Apple’s first release of Apple Maps for iOS tended to show people plainly wrong directions, but its use could easily be seen and it looked beautiful.

There are also examples of two properties giving rise to a third. The architect Johnson was famous for designing buildings that were strong and beautiful buildings, and therefore functional. One could say their utility derived from those former two properties. The German architect Gropius, the founder of Bauhaus, designed buildings that were strong as well as useful, and therefore beautiful. One could say its beauty derived from those former two properties. An example of this from software design is Craiglist: its beauty is in the combination of its strength and utility. Rather than having one property derive from the combination of the others, one could also ‘add’ one of the properties to a combination of the others. Gumtree is an example of this: it is strong and useful, and a visual design layer has been added to that, as a third property.

Other principles from architecture that we might want to apply to web design: order, arrangement, proportion, symmetry, appropriateness and budget-friendliness.

Alistair Duggin: the BBC’s accessible olympics website

Accessibility was a high priority in building BBC’s website for the London 2012 olympics. Front-end developer Alistair Duggin shared some of his experiences working on this huge website.

The BBC aimed to deliver content about the Olympics to as many channels as possible, such as tv, radio and internet. On the internet, the BBC aims for a high degree of accessibility. “The BBC is paid for by everyone and therefore must be accessible to everyone, otherwise the BBC is not the BBC.”, said Michael Grade, Director General BBC 2004-6.

The BBC is paid for by everyone and therefore must be accessible to everyone, otherwise the BBC is not the BBC.

The website was built around a sports ontology: athletes connected to countries and events, events connected to a ventue and sport. All of these ontology items had their own pages, so there were pages for all of the 10000 athletes, 205 countries, 36 sports, 304 medal winning events and 30 venues, and they were all interconnected.

Making something accessible is not as easy as it sounds. An extra complication was that all the templates had to be right when the site was put in use, which was when the Olympics started. During the Olympics itself, there was a code freeze (except for very urgent bug fixes).

The website was a great succes: it was viewed by 37 million UK browsers (57 globally). Many have viewed it on mobile (9.2 million mobile browsers, 12 million requests for video from mobile devices, 34% of all daily browsing by mobile).

These things helped making the BBC’s London 2012 site more accessible:

• usage of a front-end style guide, to keep code consistent (more consistency is better for users)
• front-end was built component-based; a component could generally drop in most parts of most pages
• progressive enhancement was used: pages were built in ‘layers’, so that the basic content was accessible to anyone
• content was added in logical order, alt text added to images that needed it, tables had captions, abbreviations had their full text in the code
• in the HTML the team used: the HTML5 doctype, lang-attribute, skip-links, a unique <title> and <h1> and WAI-ARIA landmark roles, hierarchical heading structure, no duplicate links, alt text if they would not duplicate, links that were sensible outside their context, correctly coded forms and tables
• in CSS, the team was careful not to implement barriers with CSS; display:none was only used when strictly needed, focus-styles were defined, outline:0 and !important were avoided, colour contrast was checked and the lay-outs were checked without JS and images
• *in JavaScript, the team used feature detection, generated only valid HTML, updated state labels such as ‘open’ and ‘close’ appropriately, made all content accessible via keyboard and took care not to add keyboard traps
• WAI-ARIA was used as an enhancement for those users with devices that support it, for example to keep users informed, manage focus, implement keyboard controls and provide hidden instructions

Andrea Resmini: cross channel experiences

Andrea Resmini talked about how websites have gotten more deeply integrated in our world, and cross channel services.

The difference between multi channel services and cross channel services is that the former serves A, serves B and serves C, whilst the latter includes A, B and C.

Computing used to be bound to a very specific time and place, e.g. a computer would not follow you. Today, cyberspace is very deeply integrated into the world around us. It has become much like a layer.

In a city we are said to ‘know’, we have a mental map of that city. In the first few days in a new city, we are able to create such a mental map. Now with digital products, this is not much different. A digital product like Facebook is much like a city that we have a mental map of. Their app on our phone is part of this, and so are the friends we know to be online in its chat service.

The architecture of information spaces comes down to the information architecture of places.

We ‘know’ a place, because we know specific characteristics of it. Those characteristics make up our memory of the place. If we want to create a cross channel experience that is easy to navigate, we should concentrate on creating characteristics. The architecture of information spaces comes down to the information architecture of places.

Recommended reading: Manovich, The language of new media

---

Originally posted as World Usability Day in Bristol on Hidde's blog.

Reply via email

I just read Anna Debenham’s pocket guide to front-end styleguides. With only 69 pages, it is a concise guide to what (front-end) style guides are and how to use them.

It explains what style guides are (used) for, goes into different kinds of style guides used specifically on the web, describes what elements a web style guide can consist of, considers some of the main benefits of style guides on the web, gives some examples of good web style guides and finally looks into what the future for style guides might be.

Anna describes many different types of style guides for the web, such as style tiles, pattern portfolio’s and pattern primers. The main idea with all of those is that they come into being before page lay-out. They describe visual styles of page components, from which full pages can be construed later on in the design process.

The cover of Anna’s Pocket Guide

Style guides for better front-ends

Style guides can be very helpful for those pursuing to build better front-ends (and who isn’t?).

• You don’t know which HTML the CMS or future versions of the CMS will spit out, and even if you do, the designer might not have styled them. If you include all generally used HTML in your style guide, you can make sure all of those are properly styled and tested across different platforms and devices.
• Creating a front-end style guide will help find inconsistencies between components’ designs, and therefore help avoid inconsistencies in the underlying CSS.
• Making a front-end style guide helps thinking even more component-like, which according to some is good. Components are not tied to a specific space in a page layout. That is helpful as much of today’s web design is for multiple screens.
• The style guide can be used to show all involved in the project what kinds of content (can) exist in their website.

I have used simple style guide and pattern primers in projects before, and plan to do even more so after reading Anna’s short book.

,

---

Originally posted as Styleguides for better front-ends on Hidde's blog.

Reply via email