On being responsively creative
Posted on 28th June 2014
Yesterday I returned to Brighton for the sequel—Responsive Day Out 2: The Squishening. Bad weather was forecast—heavy showers and possible thunder storms—but in fact, the day turned out to be warm and sunny.
Responsive Day Out is a gathering of around 300 (I would guess) web designers and developers, who come together for a day of talks about Responsive Web Design. The event is organised by Clearleft‘s Jeremy Keith.
After last year’s event, I approached the Brighton Dome wondering whether we’d be treated to more tales of woe but as it turned out, the sequel was a rather more positive, productive and inspirational event than the original and just like the weather, my expectations were exceeded.
Don’t get me wrong, I really enjoyed the original Responsive Day Out and it was probably the most important conference I attended last year but there was an air of catharsis about it and I came away feeling that I’d just attended a rather select self-help group for those who were trying (and in many cases failing) to come to terms with responsive web design and the changes to workflow that it required. Many of the takeaways from that day were encapsulated in Sarah Parmenter’s admission that she didn’t know what she was doing when it came to responsive web design. During her talk there was a collective sigh of relief and the audience visibly relaxed—thank goodness someone has had the guts to come out and say it how it is.
But that was 16 months ago and our self-help group have moved on. There was no wringing of hands at yesterday’s event and no catharsis necessary because it looks to me as though our industry has discovered that just like all major design challenges, responsive web design gives us the opportunity to rethink not only the way we work but the designs we create. Web design now and in the future will be different, not because RWD has forced us to change the way we work but because it has given us license to think more creatively about the things we make and that will be its most important legacy.
What evidence do I have to support this claim? Well, let’s start with Stephen Hay’s approach to design, which he calls “Sculpting Text” (design the text first and then the container—to put it very simply) and then there’s Dan Donald’s quest for the “Element Query” (not Media Query) because the viewport/page is no longer the key design objective. Also note Oliver Reichenstein’s (outrageous) Container Model, declaring that the column is dead and Stephanie Reiger’s serious questioning of the rationale behind many of the CSS Level 4 media query proposals. Ethan Marcotte implored us to “use @media to defend the integrity of the content”, not to adapt to different screen sizes. These were just 5 of the 10 speakers who provided a vision of what the web could be if we were to think the unthinkable.
As usual, Jeremy Keith’s curation of the talks was excellent and the format (three talks back-to-back and then a discussion in each session) worked really well. Below are my notes from those talks.
As soon as you hear Stephen Hay talk about design, you know he is right. There’s an inescapable logic to his approach—it just makes sense—so let’s all work this way. He begins by telling us that HTML is the most portable and universal format we have and that HTML without any styling already forms a single column, flexible grid that works everywhere—it’s naturally responsive and device agnostic.
Sculpt the text in the browser window. Start small and work up.
We should begin with the textual content and design it typographically as the first step of visual design, using only as much CSS as is necessary. Then, expand the browser window until this fundamental design breaks—that’s your breakpoint, it has nothing to do with screen sizes.
As designers, we have tended to start at the wrong point in the Design Funnel. We begin with “create” (visual comps etc.) whereas we ought to start by defining our values and goals.
Stephen’s approach seems natural and I like the simple, organic nature of the workflow. The problem, I guess, is that although this makes sense for the designer where every design becomes a journey of surprise, selling that to a client may be tricky.
This talk was a reminder to all of us that responsive design is not just about screen size, it’s about all those situations where a design change may be desirable in order to improve the user experience. An example of this is the varying light levels that a user may experience that make it either harder or easier to read a screen. Sally used the example of meteorosensitive buildings in architectural design to emphasise the point that responsiveness is not unique to web design but that the common goal across all disciplines where such adaptations are used is to improve the user experience.
To be a good designer means not being bound by our own preferences and recognising that we have responsibilities and that our decisions are not made in isolation. Be responsible and use technology to improve experience and not to impress our friends.
The Core Model
Ida Aalen is a UX designer who began her talk by echoing Stephen Hay’s stance on design; “Don’t do anything without knowing your objectives and goals”. She further challenged our usual approach to web design by telling us that “the homepage isn’t the best place to start because people don’t come to look at the homepage, they come for content”.
The Core Model approach begins by identifying the core content and the core content is that which falls in the overlapping part of the Venn diagram between business goals and user tasks. Once we know our core content, we should plan the inbound path and the forward path to and from that content.
When we understand all of the above, we can begin to order the core content so that it makes sense on a small screen device. From that point, we can move up and consider how the content will work with other viewport sizes. Finally, we can consider visual design.
This was an excellent talk, demonstrating the importance of mobile and of content-centred design with some very convincing feedback data from a cancer research site Ida has recently worked on.
Discussion 1 summary
In the past we designed containers and then filled them with content but we should design content first and then design the container(s). Containers may vary in size (height and width) but core content is a constant.
We can’t make assumptions about how people use websites. Will they fill in long forms on smartphones? Statistics show that they will.
Web components are exciting and scary. Exciting because they give developers a great deal of power. Scary because they give developers a great deal of power.
Tools like Macaw are good for designers for prototyping but not for production-ready code.
CSS Grid Layout
Rachel Andrew is very excited about the CSS Grid Layout module principally because it resolves the problem of content order. She says: “The brilliant thing is that content order is no longer a problem, it can be defined in CSS and can therefore be changed with media queries… The specification allows for named areas which makes it easy to define what content goes where.”
Rachel didn’t just talk theory, she whizzed through a 16 column grid example and everyone in the audience tried (and I failed) to keep up. Her examples can be found on Codepen, this and other useful links are available on her summary of the talk.
CSS Grid Layout is much better for the layout of pages than CSS Flexbox because Flexbox has performance issues with complex layouts but it is well suited to smaller content components.
The rallying cry of this talk is that web designers should be creating ecosystems of content and not pages. Dan Donald’s talk pin-pointed a concept that many of the other talks only hinted at—that the “page” is no longer a valid design objective, rather it is just a container for designed content modules and that it is these modules (not the page/viewport) that ought to be the focus of our responsive design efforts. Take a look at Pattern Lab for a model of design that we could apply to our workflow.
In order to effectively implement such an approach, we need CSS queries that report on the size of HTML elements as well as the viewport. Dan demonstrated some experiments with PHP that went part-way towards this goal.
Realistic Responsive Transition
Inayaili de León Persson
Inayaili explained the process of transitioning the Ubuntu site from static to responsive. The process was an evolutionary one, there was not the “luxury” of starting from scratch, the visual design and content was to remain the same.
So, how did they go about it? Well, they began with an interface audit, looking for similar design patterns within the site and then developed a style guide based on a rationalisation of the components they found. It’s a really interesting and thoroughly logical approach, which once again emphasised the importance of the designed component over the designed page. A review of the process can be found at design.canonical.com.
Discussion 2 summary
Element queries must be the way forward because we now design with components that need to react as their width and height changes.
Interface audits are a good way to rationalise the variability of components on a site, it simplifies the design process and makes for a more consistent interface and therefore a better user experience.
CSS Grid is brilliant for content management systems because the serving of content and the display order of that content can be separate.
Modularity and the design of content modules (not pages) is the key concept that we need to focus on when designing websites.
The Container Model
Oliver Reichenstein knows how to press the buttons, his talk was amusing and controversial, to the point where Jeremy Keith began Discussion 3 by asking, “You’re just trolling us, right?” Except, I don’t think he was. It was also the only talk of the day not to be accompanied by any visuals and I think it benefited from that—the audience focused on the speaker, not the screen.
The talk began with Oliver stating the case that we have developed techniques that allow for the visual design of sites to respond to different contexts but that information architecture is still static.
Often, we trust Google more than we trust site search to find us the information we need—this is tragic.
Less navigation is more (to qualify Mies van der Rohe’s famous motto).
And now the controversial bit.
“It’s over with the column. We had columns, we tried it and it doesn’t work!”
Oliver believes that multi-column layouts don’t work because they don’t effectively prioritise information. The user is presented with different bits of content at the same time/page level that have differing priorities and this is confusing for the user. He proposes chopping the static IA tree and making content layout entirely linear.
He further proposes a system he calls the Container Model, which identifies logical content elements that can be placed in whatever order is appropriate for the context. This approach has been adopted at the Guardian newspaper and is detailed in a recent blog post.
The scary thing (for me) is that this all makes perfect sense but it’s just not the way we have thought about site design before. Then again, many of the talks at RDO2 challenge today’s accepted norms, not with dogmatic fervour but with simple, cold logic. OMG, they’re right. This RWD thing is much further-reaching than any of us originally thought.
A Question of Deliverables
While our heads were still spinning, Kirsty Burgoine took to the stage with a more down-to-Earth talk, which calmed our nerves. She talked about her personal journey as a freelancer adapting her workflow and her client relationships to incorporate RWD into her projects.
Kirsty detailed the various approaches she has tried:
- Tell the client nothing. Just deliver a responsive site anyway.
- Tell the client they’ll get a responsive site but don’t promise anything specific.
- Engage in an ongoing discussion with the client while working directly with code.
Each of the above approaches has pitfalls, which Kirsty described and she has come to the conclusion that a more practical approach is to vary the workflow depending on the client and the nature of the project—there isn’t an optimal RWD workflow.
The takeaway message is that trust between designer and client is more important now because intermediate deliverables are problematic, the design process is more organic so it’s less easy to identify specific stages and specific outcomes.
The Future of Media Queries?
Notice the question mark in the title of Stephanie’s talk? Is she asking whether media queries even have a future?
The basis for this talk is the recent draft 3 (June 2014) of the CSS media queries level 4 module. Stephanie worked through many of the new proposals and critically analysed the use cases for each. Unfortunately, the W3C didn’t score too well under Ms Reiger’s close examination.
@media (light-level) to sense the ambient light (assuming the user client can do so). Why add yet another light-level variable to the mix? User clients that can sense light-levels are usually self-adjusting. How would our designs interact with that? At best, it could be used to provide the user with a choice: “Would you like to use the dark theme?”
@media (pointer) to test whether the user pointer is coarse (a finger) or fine (a mouse). There is too much diversity for this to be useful. Will we modify designs based on pointer type? Make buttons bigger for coarse pointers? Why not just design sensibly for all pointer types because there are devices that have both coarse and fine pointers.
@media (hover) to test whether the user client can sense hover events or not. As with pointer, this is problematic because many clients have both.
The list continued with update-frequency, overflow-block and overflow-inline where some of the use cases included paper as in, CSS animation is probably not a good idea on paper because the update-frequency is too slow.
Stephanie concluded that we do need more media queries but that these may not be the right ones. She cited the Android qualifiers as being a good model to follow with qualifiers such as language because the same content in English can be conveyed in Mandarin with far fewer characters and therefore requires much less space.
Stephanie’s parting shot was to question our approach to design and our use of media queries to sense client functions and context. The variety of clients is increasing with Glass and smart watches recently joining the list. Maybe the device should decide on the most appropriate component design for our content rather than us trying to sense the client using media queries and then designing something to suit each option. We’re in a similar situation to the one where we adapted our pages for different screen sizes—that didn’t work because the number of variables increased faster than we could design. Maybe the same is true of device types? Let’s design for the content and allow the client to decide how it should be presented.
Discussion 3 summary
The W3C specifications are reactive and the things we get now are the things we thought we might need 4 or 5 years ago.
The Container Model means people stop thinking “how do I fill this box” and start thinking “how do I write great content” because they are in competition with other content writers. The best content gets highest priority and ends up at the top of the homepage.
If we take the “no columns”, container model approach, we don’t need element queries because the viewport is the container.
Laziness in the time of Responsive Design
Ethan Marcotte looked relaxed, he didn’t look like he was carrying the weight of Responsive Web Design on his shoulders and why should he? This is just the way it is, it’s how we should be designing. He was quick to downplay his place in many people’s minds as a web design visionary by describing the List Apart article as “just hitting a deadline”. And then, stuff happened…
Naturally, Ethan was given more time than earlier speakers and his talk ranged across a number of related topics but the main theme of the talk was to keep things simple—be lazy and achieve your design goals with the minimum of effort, don’t over-complicate things. Let’s make “lazy” a good thing in design, maybe we need to let go rather than always trying to control everything.
He talked about how Frank Thomas and Ollie Johnston developed the 12 Principles of Animation at Disney Studios in the 1930’s as a way of being able to discuss their work and that maybe web design needs a similar framework. He spoke of Karl Gerstner and how design frameworks had helped create a logical approach to graphic design that allowed for early prototypes of design proposals. Again, something we (as a new design discipline) could learn from.
Ethan noted that web designers were still struggling with navigation in responsive designs and wondered, “does our industry have a ‘hamburger’ problem” (referring to the 3-bar icon commonly used to indicate a hidden menu) and further noting that off-canvass patterns are becoming more popular but that off-canvass menus are often used as a repository for “everything we didn’t know where to put”.
But good things are happening too. Ethan likes Frank Chimero’s approach to navigation. His site uses a beautiful, simple menu, using CSS Flexbox to control the layout. Should we hide navigation? Maybe we should just be designing better navigation.
The talk finished with Ethan recommending that we “design the transaction, not the interface” and reminding us that “progressive enhancement is at the heart of successful responsive design”. Progressive enhancement allows designers to let go because it enables us to design a broad experience rather than being device specific. Lazy but ultimately effective.
Discussion 4 summary
Let’s not feel guilty about not having time to keep up with all the latest tools and techniques.
We tend to talk about “screens” but content can also be conveyed via audio (e.g. turn-by-turn navigation) and so our content should be capable of being conveyed in non-visual ways, which is why text is the best place to begin.
What did we learn at Responsive Day Out 2?
The 10 speakers at this event covered a lot of ground but there were a number of common themes that emerged as the day progressed that I will have to summarise in a future post because I’m still digesting much of what I heard and if you’ve read all of the above, you’re due a break in any case.
One thing is for sure though, Responsive Day Out 2 was a very important event, at least as important as the first and I think that with hindsight, it may well turn out to be much more important. I have a feeling that it might turn out to be one of those watershed events (at least to me if not the industry as a whole) when our entire view of web design is challenged. Before this event we designed pages and after this event we designed content modules that could be used in various ways in various contexts to provide a broad experience. Responsive Web Design was just the start of the revolution.
I have a few other conferences lined up in 2014 but they’re going to have to be amazingly good to best this one.∗
Links to other write-ups and images of this event can be found at Jeremy Keith’s journal.