Responsive Day Out 2 - the squishening

Last year I experienced Responsive Day Out through its audio podcast (RSS), this year I decided to buy a ticket and travel from Bristol to Brighton for the real thing. It was a varied day, with room for aspects like design, business, information architecture and even CSS specs.

The day was structured in three blocks of three speakers talking for 20 minutes, plus one block of Ethan Marcotte, who came up with the term ‘responsive web design’. The event’s Twitter hash tag, #beepcheeks, was named after him.

Part 1: Stephen Hay, Sally Jenkinson and Ida Aalen

In the first session, Stephen Hay introduced us to the method of ’sculpting text’, Sally Jenkinson discussed aspects of responsive web design beyond just designing for different screen widths and Ida Aalen shared her experience working on a large responsive project for the Norwegian cancer association.

Sculpting text

Stephen Hay explained that text is what underlies the web. Structured text, to be more precise. Structured text is portable, it can stay the same regardless of which device you use to access a web page. It exposes inappropriate and irrelevant content more easily than a full fledged web design comp would. Web designers have been designing containers to fill with text for ages, so that text would be the last step in their project work flows. But if text is the most portable, shouldn’t we really start with text first? Stephen argued we should.

Increase screen size, until you feel the layout breaks, at which point you add a breakpoint

The method of sculpting text, Stephen explained, consists in adding layers of CSS rules to structured text. It can start with styling text on a small width, a ‘single column grid’ if you will. Start simple. To structured text on a narrow screen you can do things like colour, typography, spacing, et cetera first. Then you increase screen size, until you feel the layout breaks, at which point you can add a breakpoint. You can then introduce things like columns. Sketching is helpful when trying to come up with solutions for larger screen widths.

Sculpting text first and coming up with a canvas later in the process, rather than designing a canvas to put content in afterwards, will help designers understand what they are designing. As a methodology, it helps us cope with the multi device world they design for, Stephen argued.

A more in-depth discussion of responsive design workflow, can be found in Stephen’s book with the same name, which I recommend reading, or have a look at his slides.

Responsive planning

Sally Jenkinson emphasised that responsive design is not only about designing for multiple screen widths, it is also about being very good at planning, not being afraid to experiment and making the right choices.

Our choices have great impact

The choices web designers and developers face, Sally argued, can have large philosophical and ethical impact. A developer often makes choices that impact what a user experiences. This can include ‘invisible requirements’, like progressive enhancement. The decision to make a website ask for a user’s location, may feel awkward or unnecessarily invade their privacy, especially if the app does not evidently require location.

Sometimes we should make choices or do things that aren’t part of our job descriptions. Planners can try out new technologies, rather than solving problems with solutions that we happen to be used to. Choices should not be about what is beneficial to us as designers, developers or businesses, they should be made with the bigger picture in mind. It is about end users ultimately, we should avoid ‘narcissistic web design’, Sally advocated. And we should avoid making choices that invade our users’ privacy.

The core model

Ida Aalen described the ‘core model’ for information architecture, and spelled out how it benefited her team when working on the website for the Norwegian Cancer Society (lang=no). (Slides)

In information architecture, which is a lot about users navigating, it is important to note users will often not (want to) navigate your site. They often just look at one page, coming in following a Google search or a link on Facebook.

Core pages serve both business and user needs

Ida talked about the overlap between business needs and user needs. Some pages only serve one of the two, some serve both. Those are core content pages. An example she discussed is a page about lung cancer: it serves business goals (informing people, sharing knowledge) as well as user needs (getting to know more about symptoms, prevention and treatments). From core content pages, one can think about pages that precede it, and those that can lead a user to elsewhere. The core content is the same on all pages, regardless of device used.

For the Cancer Society, a lot of time was spent on mobile. Ida shared some data on usage. Users visiting with small screens spent roughly the same amount of time on the site as those with large screens. Conversion rates did not differ much between screen sizes used, so it was worthwhile to spend time on designing for all screens.

Part 2: Rachel Andrew, Dan Donald and Inayaili de León Persson

In the second session, Rachel Andrew talked about the CSS Grid Layout Spec, Dan Donald considered the flexible web and Inayaili de León Persson shared her experience of making ubuntu.com responsive.

CSS Grid Layout

Rachel Andrew discussed the new CSS Grid Layout spec. Since it was originally proposed by Microsoft and used in IE10, it evolved a lot.

Rachel discussed different ways of defining grids in CSS, using Grid Layout. There is line based positioning, and the use of grid area names, also known as ‘defining grids in ascii art’. For components you specify in which areas they should be displayed. Then, on the wrapper they are in, you define where those areas are. To see how it works, have a look at her code examples or her blogpost about the subject.

She also explained how grid layout differs from flexbox: whereas the former is most suitable for full page layout, the latter works best for smaller UI components.

The flexible web and element queries

Dan Donald talked about building for a flexible web. In particular, he talked about flexible components using element queries.

Element queries are media queries that respond not on a document level, but on a component or element level.

Element queries are media queries that respond not on a document level, but on a component or element level. Currently, they exist mostly as a concept, i.e. there is no standard with browser support. Nevertheless, it is possible to use the concept in web pages today. Dan explained how he did so in a project for BBC, using data attributes to specify queries, a bit of JavaScript to make them more flexible and, of course, CSS to define what to do at breakpoints.

Realistic responsive design

Inayaili de Léon Persson showed us what she learned when working on the responsive version of Ubuntu.com. At the time, the team did not have the luxuries of starting from scratch, or working on it full time. The mark-up and content had to stay the same, and the team had to squeeze the project in between their other duties.

Inayaili explained that when making a site responsive, it is often not only about just that, there are many priorities, goals and needs. The team behind Ubuntu.com benefited from buying some of the most used devices, using Basecamp to document as much as they could and making clever use of stuff others had done, inside and outside the organisation.

An interesting step in the process that Inayaili described was the writing of ‘responsive rules’, like ‘Content that is divided in half or thirds should convert into single column when it becomes too narrow’. See also Setting the rules in the series Making Ubuntu responsive on the Ubuntu site.

Part 3: Oliver Reichenstein, Kirsty Burgoine and Stephanie Rieger

In the third session, Oliver Reichenstein proposed a better way of structuring websites, which his company recently employed for The Guardian, Kirsty Burgoine shared how her responsive web design process developed and Stephanie Rieger dived into new media queries.

The container model

Oliver Reichenstein explained that making information easy to find for users is hard. Most information architecture starts from the homepage down, with lots of diverging branches. These kind of trees can be very sturdy. Home pages and sidebars are often full of stuff, because of politics.

The alternative [to sturdy information architecture] is the container model

Oliver Reichenstein explains the container model (photo by Marc Thiele)

The alternative is the container model: have containers with specific content and decide where to put them. Containers are full width and horizontal, pages can have a series of containers stacked up.¹ Containers are self sufficient and can appear anywhere. On a news site, a container can be a world cup section, or a top news section. The article is a container, the comment section is a container. Container based design is without columns, but you can put content next to each other, if the content is comparable, for example a top sport section next to top politics.

The container model is to avoid pages where lots of unrelated bits of information are placed next to each other, just because there is a sidebar that can be filled with content. Responsive design or mobile first forces us to have priorities. We should stick to those priorities when working up to larger screens. If you work up from mobile to larger screen, you should still not put lots of random content to fill up space.

Oliver’s company Information Architects helped newspaper The Guardian implementing the container system on their new site, which is currently in beta. But the model is not only useful on news sites, it works for e-commerce and corporate sites, too, Oliver stressed.

¹ Blogpost about the container model at The Guardian

Responsive deliverables

Kirsty Burgoine shared various approaches her business tried when making responsive websites. She also discussed the importance of trust.

All approaches shared that the website was going to be responsive. The first approach was not telling the client, and surprising them with the fact that the website worked on mobile. It resulted in happy clients, but it had a steep learning curve and caused unbilled time. The second approach was to tell them about responsive design, but not to promise anything. The good thing was that her workflow could stay roughly the same. The downside, that it required a lot of trust from clients. The third approach was to dive straight into code, and do HTML early. It made Kirsty happy as a developer, but clients would have hardly any deliverables. The client would have to have trust, without seeing what was being done.

The fourth and final approach was a very practical one. It embraced the chaos that making responsive websites can be. There were lots of different deliverables, or in lieu of them, sharing of ideas. Regular meetings were held to make sure the client was still on board.

The future of CSS media queries

Stephanie Rieger went into some of the new media queries that are being discussed.

There are proposals and drafts for media queries based on user’s JavaScript support, light level, the kind or lack of pointer, ability to hover, screen’s update frequency and overflowing capabilities.

Stephanie also discussed additional media queries that she thought could be useful, including one to see what language a device can use (Chinese interfaces need less space for words then Western ones, as less characters are needed).

Another interesting thought Stephanie shared was that of a browser built-in navigation system, that would just expose the page’s nav items via a control that is best for the device. For example, a phone could have a built-in hamburger icon to open it, a Google Glass could have a speech command to request it.

Part 4: @beep

The last talk of the day was delivered by Ethan Marcotte, who gave the idea of designing flexible web pages its thoughtful name. His talk, which I was lucky enough to see him do at CSS Day earlier this month, was about being lazy. Or, as I would rephrase it: keeping things simple. According to Ethan, being lazy is the only response to the increasingly complex web we work on, with its multitude of devices, connection speeds and interaction models.

He showed some ideas for being lazy about lay-out: the padding trick and nth-child for infinite grids with relatively simple CSS. He also discussed frameworks. On the web they are often too descriptive, too ‘heavy’. In a broader sense, there are examples of great ‘frameworks’: Disney’s 12 principles of animation (video), the Whitney museum with its logo that can have infinite variants, all based on one simple rule, and Karl Gernsters idea of set of solutions rather than just solutions.

Ethans talk made a lot of sense to me. The multitude of devices, connection speeds and interaction models is a fact. There are roughly two ways of dealing with this fact: designing a solution for each of them, or designing a few simple rules that automatically deal with all of them. The latter works for Disney or the Whitney museum, and it is sensible to say it will work best for us, working on responsive web design.

Round-up

Throughout the talks it became clear that responsive web design is now just web design. The great variety in devices people view the web with has influenced web design a lot. In a good way. It has lead many of us to do away with assumptions, and begin to build more solid websites. The idea of separating structure, style and behaviour is definitely not new, but seems to have become inevitable at last. It is key to a great responsive workflow. This starts with structured text, as Stephen explained. Responsive web design also lead us to radically change workflow and planning, as Kirsty, Sally and Inayaili discussed. The surge of small devices with browsers forced web makers to think about priorities in content and navigation, as Ida and Oliver discussed. New standards and ideas, like those discussed by Rachel, Dan and Stephanie, will help us cater even better for a multitude of devices, but we should not just use new technologies for the sake of it, like Sally emphasised.

Responsive Day Out 2 was one of my favourite events this year. It was simple: no lunch, no WiFi, no coffee, no after parties, but also: a low price. And admittedly, good coffee or food is never really far away in Brighton anyway. The format, 20-minute talks, worked well. It resulted in a great variety of subjects. There was a good balance of theoretical/conceptual talks and practical case-study like talks.