Recently at Cooper, we updated our website with a focus on responsive web design. Working with Cooper’s other great developer, Elisha Cook, I learned a lot in the project, though at times it seemed my head would explode trying to figure out solutions to various problems presented by responsive web design, so when I heard that CascadeSF was hosting a presentation on this very topic, I was eager to attend and see what I could learn.
CascadeSF is a collective of San Francisco-based web designers and developers who meet periodically to keep up-to-date on design trends, standards, and techniques. On July 24th, the presenter was Pauly Ting, a Lead UX Designer at Tigerspike SF, founder of Feedia, and co-founder of TwoCents. The MeetUp was hosted in the offices of the residential real estate site, Trulia, just a block away from the Cooper studio.
Digital Evolution: From Fixed to Responsive Layouts
The focus of Pauly’s presentation was on planning content for responsive layouts. Responsive layouts present new challenges for organization and delivery of content. We are accustomed to the page-based approach to organizing content, largely because that is how content has always been organized and delivered. For example, the printing press has a fixed width and height based on the page size. The Gutenberg Press revolutionized content delivery in the 15th century by organizing content as hand-set letters and graphics arranged in rigidly determined rows that could then be mass produced. It was a new paradigm, taking book production from the hands of scribes locked up in monasteries, and distributing books more widely, making education of the masses possible for the first time, which of course changed the world.
Though modern presses and digital output have transformed the print industry over the past 25 years, not much has changed in terms of organizing content for delivery in the traditional page layout. Modern formats such as word processing software and CMS on the web adopted the page-based approach, which worked well for a time. However, this is now seriously challenged by the emergence of devices with varied screen sizes, which renders a fixed grid insufficient. At the CascadeSF event, Pauly offered the hilarious example of Fabric Land as evidence.
So, with the problem established, the focus of Pauly’s presentation turned to how to best serve today’s digital content in the new wild west of responsive environments.
Planning for a New Type of Content
Over the past decade or so, two major approaches to mobile web design have emerged: adaptive and responsive.
- Adaptive design means thinking about different devices of fixed dimensions. This worked well for widely adapted devices, but it is still limited to real estate size rather than working in all devices.
- Responsive design acknowledges that today we are designing for everything from smart phones to TVs to appliances to computers to vehicle displays and even watches.
The three fundamentals of responsive web design are: media queries, fluid grids and flexible media. The focus of Pauly’s presentation was fluid grids and flexible media.
Grid systems have been in use as long as writing has existed, and they are not new to design. In 1977, Massimo Vignelli designed the Unigrid for the National Park Service, allowing a consistent, recognizable structure across all NPS brochures, maps, and other materials.
On the Web, there is a large selection of open source grid choices. Bootstrap and 960 Grid System are two popular examples. 960 is a fixed-width grid based on a maximum width of 960 pixels. Bootstrap is a relative-width grid that is set according to the width of the browser window. Each brought the idea of fluid, flexible widths that are generally adaptable to changes in browser width, and have been very successful handling mobile devices such as phones and tablets. The main problem with responsive grid systems is they often lead to undesired content flow.
To their credit, Starbucks was one of the first big companies to try responsive design. Starting on slide 30, Pauly demonstrates how the content flow from the desktop site changes such that the call to action “Buy” button positioned above the fold in the desktop layout ends up under the user comment section in the narrower tablet layout, forcing the user to literally scroll and scroll and then scroll some more to make a purchase. Pauly observed that somewhere in the Starbucks marketing department somebody must be trying to figure out why conversion rates are less than expected in the responsive presentation of the site.
The sidebar moving under the main content is a common problem in responsive design, which makes sense, since the sidebar is intended for tangential content. However, in the Starbucks example, this moved the important call-to-action below the less important (from a sales-oriented pperspective) comments section. It calls into question the process used in planning the flow of content across devices. As Pauly sees it, and the Starbucks example demonstrates, these are three lessons to learn:
- Fluidity (although not pixel perfection) still needs a vigilant and thoughtful eye
- Mobile use-case doesn’t mean being deprived; rather being accessible
- Content priority and order is important
Structuring your content
For Pauly, the place to start is properly structuring your content. Consider your content types: product pages, articles, recipes, testimonials, events, forms, surveys, reviews, etc., and break each down into its elements. These elements may include copy, summary, images, video, buttons, icons, pull quotes, meta-data, typefaces, type styles, colors and other presentational aspects. Your design will be based on the elements you choose to use, but you should establish rules and relationships to maintain in order to keep content accessible in varying use cases.
This was an important consideration in the first iteration of the new Cooper website. For example, we hold a lot of events here. Between Cooper U, Cooper Parlor, Cooper Pub, and one-off events such as our recent Design Week Open House, non-technical members of the Cooper team needed the ability to input content about courses and events into the database. We flexed the strength of our content management system, building custom post types to properly capture the elements needed to communicate certain kinds of information. The site then properly displays the content on the web site using various templates. This took advance planning, understanding the types of content, the elements used for each in various contexts, and the creation of rules and relationships for surfacing this content wherever it was needed.
Prioritize your content
The next thing to consider is how to prioritize content, and we can’t just rely on our fancy responsive grid system to do this for us. Understanding the user context is key to delivering properly prioritized content for the use format.
Three important things to think about in prioritizing content are:
- Meaning - What is gained/lost by keeping/losing this?
- Priority - Does it have context or exist for a key task?
- Relationship - What is affected if this disappears?
This is where we run into a debate in the community between Graceful Degradation vs. Progressive Enhancement. The concept of graceful degradation sets out to satisfy the needs of mobile users without interrupting the desktop experience. In graceful degradation, some content or features are hidden in order to make the site more digestible in the mobile context. Progressive enhancement, or Mobile First, as it is called in Luke Wroblewski’s recent book, Mobile First, means starting with an amazing mobile experience and adding enhancements as screen size increases. A lot that can be said about each approach. This recent post by Joshua Johnson at Design Shack, Mobile First Design: Why It’s Great and Why It Sucks, does a great job explaining the nuance, presents the pros and cons of each, and comes down on the side of progressive enhancement, or “Mobile First.”
Again, in the recent experience rebuilding the Cooper website, we found the answer wasn’t so clear cut. In the design process we went back and forth about what content to display in desktop vs. mobile. As an example, the map link in our address seemed superfluous in the desktop context, but crucial in the mobile context where a client or Cooper U student may be trying to find our office. It didn’t seem necessary in the desktop site because the same information could be found contextually in other parts of the site, such as the Contact page or the Journal sidebar. In the end, we decided to display the full content in each context because nothing was lost in displaying the information to the desktop user, but the need of the mobile user was always met. This was a mobile first decision.
However, in other contexts, we decided to degrade content on some pages because we simply could not see any reason a mobile user would want to see the full content of the page. The example in this case is our About page. As wonderful as it is (at least for us) to see the name and image of each Cooperista and information about our Goal-Directed Design approach, we could not imagine any reason to subject our mobile user to endlessly scroll through 33 Cooperistas, plus the cursory information about our design philosophy. The important sections on this page are the introduction, the book section, and the careers section, so we surfaced this content for the mobile user, sparing them a tremendous amount of scrolling. The desktop user experience is enhanced via this intentional degradation, and this is a middle path we found worked great for the first iteration of the new Cooper site.
It seemed like Pauly came down in the middle, too. In follow-up questions from the audience, it seemed like people were looking for him to come down on one side or another. He pointed out that even though Mobile First is probably the right solution most of the time, there are real life scenarios that have to be considered in each project, including deadlines, which sometimes determine what is possible more than anything else. There are also some projects where there is no desire for a mobile experience. (Gasp!) He discussed a recent project, and how ultimately the ability to eventually transition to mobile was very much a consideration in design and development even though it was not an apparent part of the deliverable. This seems to me like a smart way to build projects.
Finally, after we have properly structured and prioritized our content, there are technical solutions available to assist in building the project and delivering a great user experience. It’s important to note this is the last consideration. It reminds us that, as in any design project, execution comes after a tremendous amount of preparation. We ought not skim past the important early steps and expect technology to make everything work properly. That will ultimately lead to undesirable results, such as the calls to action disappearing far down the page after reader comments in the Starbucks example. Nevertheless, technology is important in responsive web design. Pauly offers some links to some great solutions on slide 39 that I encourage you to check out.
The main area of discussion in this part of Pauly’s presentation was flexible media. He showed an example of a product image being used in the desktop, photographed in a nicely designed room to give the user an understanding of how the product might appear in their room. It’s a common technique we see all the time. The problem in this case is that the same image in the mobile view essentially made the product difficult to see at all. There were a couple of solutions offered for this. One solution is to provide a second close-up image in the mobile context that the user can swipe to in order to see the product closer. Another solution is to actually serve different images based on screen size. This is the approach we took at Cooper. Most of our images have a desktop-optimized image that serves as default, with a small image served to smaller screen-sized devices. When we added in consideration of high-pixel density devices, the number of images we needed to produce increased, but properly cropped and scaled images are a critical part of the user experience, so this step is essential. Furthermore, delivering an image optimized for the device prevented us from serving desktop-sized images to a mobile devices in most cases, unnecessarily slowing down site performance on devices that really work best with mobile-optimized images. Pauly offered links to some great flexible media solutions on slide 45.
Pauly’s 6 Quick Takeaways
- We’re not designing pages anymore
- Think in percentages, not pixels
- Fluid layouts need strategic planning
- Assess your content semantically
- Create content rules based on use cases
- Flexible media also means offering an alternative
In follow-up, there has been some discussion about where to take the discussion next, at least in the context of future CascadeSF events. One thing I was interested in wrapping my head around a little better was scaling images outside of the grid. This came up a few times in the Cooper site build, and really threw me for a loop. The solution in each case was somewhat different than any other case, and a lot of time was spent working these out. There was also a desire to do some deep dives into particular aspects of responsive web design, including methodology for strategically planning responsive content layouts. I agreed with this idea, adding it would be good to start with some predetermined personas and scenarios in order to keep the “how to” focused without diverging into hypothetical situations.
There are thousands of avenues to explore, really, and this is what makes responsive web design so exciting. We are actually creating new paradigms for the organization and delivery of content as responsive design presents us with new opportunities for creative problem solving that haven’t existed before. I’m looking forward to seeing where we go with responsive web design in the years to come—a big thank you to CascadeSF for bringing our web design and development community together to talk about these important concepts.
This article is also posted on Kenny’s site.