Food Combinations


If anyone tries this on you, the best reply is a deadpan "Oh yeah, that's a common potato chip flavor in Canada."


 ∗ A List Apart: The Full Feed

A note from the editors: We’re pleased to share an excerpt from Chapter 5 of Ethan Marcotte’s new book, Responsive Design: Patterns & Principles, available now from A Book Apart.

Over the past few years, we’ve been learning how to adapt our layouts to the infinite canvas of the web. Our sites can be viewed on any size screen, at any time, and responsive design is one approach that lets us accommodate the web’s variable shape. But with all of the challenges we’re facing and those yet to come, we need to begin building not just patterns, but principles for responsive design—principles that will allow us to focus not just on layout, but on the quality of our work.

If each part of your responsive interface is more or less self-contained—with its own layout rules, content needs, and breakpoints—then the code behind each element’s design is far less important than thinking carefully about how and why an element should adapt. In other words, how do we move beyond thinking in terms of columns and rows, and start talking about the quality of our responsive designs? And what would frameworks to support that look like?

Finding the words

Honestly, there’s no perfect answer to that question. But recently, a number of designers and organizations have started sharing the vocabulary they use to decide how and when their responsive designs should adapt. Vox Media, for example, thinks of their content as existing within a river—and in keeping with the metaphor, the flow of that content can be interrupted at certain points. Here’s how they describe the front pages of

Content flows around “rocks” and “breakers,” which are modules such as a “Most Commented” list or a row of “Popular Videos.” Many of these behaviors remain in the new layout system, but the key difference is an added contextual layer. Elements in the river are laid out to better highlight the diversity of content on Vox—articles, features, videos, editorial apps, card stacks, to name a few. Each one displays differently depending on its type and neighboring entries.

Note that the language they use to talk about the quality of their layouts doesn’t revolve around columns or rows. There’s nary a mention of grids. For Vox, the design process begins with content priority and evolves into a layout. By understanding the weight and importance of each piece of content that flows through the river, the Vox team can algorithmically generate a responsive layout that best reflects the importance of the information within it.

Starting with an abstract system of columns and rows would be wrong for them—and, I’d argue, for every web designer. After all, according to Mark Boulton, there are three fundamental benefits of a grid system:

As Boulton notes, we historically created grid systems by adopting a “canvas in” method. Working from the edges of a printed page, designers would subdivide a page into a system of columns and rows, and place images and text upon that grid in pleasing, rational arrangements. But the web doesn’t have any such boundary—after all, it’s the first truly fluid design medium. As a result, Boulton argues we should instead adopt a “content out” approach to designing our grids: to build more complex layout systems out from a foundation of small, modular pieces of content. And to do so, Boulton proposes three guiding principles:

By understanding the shape of our content, we can create flexible layouts that support connectedness—not just between related pieces of information, but between our layouts and the device. We can make responsive grid systems that don’t just fit on an ever-increasing number of screens—they’ll feel at home, wherever they’re viewed.

Finding the seams

Principles are wonderful, of course, but we still have to find a means of implementing them: of translating those ideals into practical responsive patterns and layouts. For me, that “content out” process begins by looking at the smallest version of a piece of content, then expanding that element until its seams begin to show and it starts to lose its shape. Once that happens, that’s an opportunity to make a change—to introduce a breakpoint that reshapes the element and preserves its integrity.

But first, we need a method of finding an element’s seams, and understanding how it loses its shape. For me, that process begins by looking at four characteristics: width, hierarchy, interaction, and density.


Width might be a little self-evident. As the width of a viewport changes, so does the width of a responsive design. But as the design gets wider or narrower, so will the elements within it, and as those modules expand or contract, there may be opportunities to add a breakpoint.

Images from Meagan Fisher’s responsive portfolio showing how different screen widths affect the typography.
On her stunning responsive portfolio, Meagan Fisher adjusts the typography of certain elements—not just their layout—as their width expands and contracts.


Width is, I’m sure you’ll agree, the most common characteristic of a responsive design—but it’s not the only one. As the shape of an element changes, the hierarchy of elements may need to change as well.

Let’s take a quick look at a product page on Tattly’s responsive ecommerce site. When viewed on wider screens, the primary content area has two key pieces of information: a photo carousel of the product on the left, and a call to action to purchase the product on the right.

Screenshot from Tattly’s responsive ecommerce site, showing a two-column grid on wider screens.
On Tattly’s responsive ecommerce site, the product content is laid out in a pleasing two-column grid on wider screens.

But that’s just one view of this particular part of the design, because as screens get narrower, we lose the ability to place multiple columns side by side. That’s where a question of hierarchy arises: in a single-column layout, which piece of content should appear first? Tattly opted, quite rightly, to lead with photos of the product—but you may answer hierarchy questions differently on your site.

Screenshot from Tattly’s responsive ecommerce site, showing how the product information shifts from two columns to one on narrower viewports.
On narrower viewports, the hierarchy of product information shifts from two columns to one.

Hierarchy is generally a reminder to be more vertically aware in our designs. After all, we have min-width and max-width media queries, but can also avail ourselves of min-height and max-height queries more often. I think the navigation menu for the Field Museum beautifully balances vertical and horizontal layouts.

Screenshot of the Field Museum’s responsive navigation in narrow and wide widths.
The Field Museum’s responsive navigation, which occupies the height of the design. Below a certain width, the navigation moves to the top of the screen to avoid cropping.

On wider screens, the navigation is anchored to the left edge of the design, and spans the full height of the viewport. You may notice that they’re using the flexible box model, or flexbox, an advanced CSS layout method we’ll look at later in this chapter. But since flexbox allows elements to automatically fill the space available to them, as the menu gets taller or shorter, the navigation elements resize vertically—but below a certain width or height, the menu is placed at the top of the page.

By minding the navigation’s vertical edges, the Field Museum was able to introduce alternate layouts to ensure the content inside their navigation menu was never concealed, obscured, or clipped. In other words, the breakpoints we introduce to our responsive designs aren’t tied to the shape of a device’s screen. Instead, our media queries defend the integrity of the content we’re designing.


The way we interact with an element may change along with the design. Responsive navigation systems are probably the most obvious example of this. As we saw in Chapter 2, menus are often displayed in full at wider breakpoints but concealed at smaller ones, perhaps hidden behind expandable icons or links when space is at a premium.

Screenshots of Karen McGrane’s company site, showing a traditional navigation on wider screens and a toggled display at narrower widths.
Karen McGrane’s company site has a traditional-looking navigation at wider breakpoints, but on smaller viewports the user toggles the visibility of the menu. Same links, but a new interaction model.

But navigation isn’t the only kind of content that might require interaction changes. For example, take the responsive sports brackets designed by SB Nation. While they appear as complex-looking charts at wider breakpoints, a simpler, more linear view of the brackets is shown on smaller screens.

Screenshots showing SB Nation’s brackets: fully visible on wide screens, per-section carousels on narrower screens.
I don’t know from sports, but I know I like SB Nation’s responsive brackets: complex charts on wide screens, but a carousel of match-ups on smaller viewports. Same information, different interaction.

Along with the simplified layout, the brackets are presented as carousels in the smaller view, where real estate is more dear. Each of the four regions for the bracket are a single slide in the carousel, allowing the user to cycle through for details. The information in both visual states is the same, but the interaction model changes.


Finally, the amount of information you’re showing in an element might need to vary over time—in other words, the density of information can change. The Guardian’s feature on the 2015 Oscars is full of examples of this, with responsively designed timelines displaying a significant amount of movie data. Above a certain width, thumbnail images are loaded in, slightly increasing the visual (and informational) density of the timeline.

Screenshots of the Guardian’s responsive cinematic timelines, displaying an extra image on wider views.
The Guardian’s responsive cinematic timelines gradually increase in density, displaying an extra image above a certain width.

Density is, as you might have guessed, an area where you should tread very carefully. As we’ve discussed before, removing or hiding information because it doesn’t fit can be problematic.

Screenshot of Tattly's navigation, hiding submenus on smaller screens.
Tattly hides its submenu entirely, reducing its navigation to a list of primary sections on smaller screens.

Personally, I think the Guardian’s timelines work so well because the images shown at wider breakpoints are enhancements: they’re not critical to understanding the information around them. Could they have designed alternate versions of the timelines to show images at all breakpoints? Possibly. But I think this is a wonderful example of density used to lighten the visual impact of a design, removing extraneous information without impeding access to the content.

Rolling Out Responsive

 ∗ A List Apart: The Full Feed

A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Karen McGrane’s new book, Going Responsive, available now from A Book Apart.

I wish I could tell you there was one true path to rolling out a responsive redesign successfully. But from talking to dozens of organizations, it’s clear that the process by which large organizations go responsive varies widely. Many different approaches will work—but you need to understand the benefits and risks of each approach.

Can you redesign the entire site at once or do you need to stage the rollout over time? Are you going to retrofit the existing desktop site or start from scratch? Will you release a beta version of the site or do a “big reveal”? To find the right option for your organization, ask yourself these questions:

Once you know the answers to these questions, consider your options for going responsive.


Doing a responsive retrofit means recoding the front end of the website with little or no change to the existing content and design.

I must confess: before I started talking to companies that launched a successful responsive retrofit, I was convinced this was the worst of all possible options, doomed to deliver a subpar experience to everyone involved. My philosophical beliefs about the “right way” to manage web processes don’t always survive their encounters with the real world: I concede that a retrofit works well in some scenarios.

In general, retrofits work best when at least one of the following statements is true:

  1. The content isn’t going to change (much).
  2. Complex web applications don’t need to be redesigned.
  3. A componentized framework is already in place.

Companies like Capital One, Marriott, and Nationwide Insurance have implemented responsive retrofits successfully. Doing a retrofit forced them to focus on the responsive aspects of the project without getting sidetracked by larger questions of redesigning the site, editing the content, or replatforming the CMS. For many websites, a retrofit also helps mitigate political concerns around changing or damaging the desktop experience, since it doesn’t change much.

Here’s how you roll out a retrofit right:

Beta release

In recent years, popular web applications like Gmail, Flickr, and Delicious launched in beta—and stayed in beta. This “perpetual beta” approach was a precursor to the continuous deployment practices used by many applications today to support ongoing development and testing.

Today, when teams say they’re launching in beta, they often mean that users can opt out of the new site at any time and return to the “classic” version of the website. This “parallel beta” approach requires significantly more time and effort to develop and review, but in return delivers the ability to roll out the redesign slowly, gathering user feedback and analytics data along the way.

Companies like Fidelity, Beatport, and the Guardian have invested in parallel beta releases, which gave them a way to test and learn from the responsive design over time. Stephen Turbek, SVP, User Experience Design at Fidelity, said their decision to launch in beta was crucial to their success:

One of our first steps was to build a beta site that people could opt-in to, try out for a while, and return to the current site. The beta site was significant additional work, but iterating live on a site with millions of passionate customers would not have been the right approach. This enabled us to make changes faster and get lots and lots of user feedback.

Here’s what needs to happen to launch a successful beta:

Mobile-only responsive

Another rollout strategy—often but not always implemented in the context of a beta release—is to develop a responsive website that covers all sizes of smartphones and tablets, preserving the current fixed-width site for desktop users only. In a sense, this approach is a “responsive m-dot site,” but that word puzzle twists my brain into a knot, so let’s not call it that. We’ll call it a mobile-only responsive site.

A mobile-only responsive site buys an organization time to focus on larger, more complex issues. Companies know they need a site that serves mobile users, but they’re afraid to hurt existing desktop traffic. But they also know the site needs a complete redesign or major backend infrastructure improvements, so they don’t want to do a retrofit. In that sense, a mobile-only responsive design offers the best of both worlds. Teams can focus on getting the responsive design right, without dealing with the stakeholder politics and operational risks inherent in changing the desktop mothership.

But this approach is also the worst of both worlds—it allows stakeholders to keep believing that the desktop website is the “real” website, downplaying the large and growing population of mobile users. It also means, as with all m-dot sites, that smartphone and desktop users will suffer from the same performance hit due to server redirects.

Here’s what can you do to launch a successful mobile-only responsive site:

Section by section

Other organizations choose to start with a specific section—even one particular page or template type. Rather than doing the entire site at once, they choose to sandbox their efforts and give teams time to practice.

Which section should you start with? The answer to that question varies as widely as any other rollout approach. Some organizations report that they picked a section they knew they wanted to redesign. Celebrity Cruises started with their Destinations section, making it responsive as part of a larger effort to rewrite content and replatform the CMS. Other companies start with a less popular section, a section run by stakeholders who are excited about the process, or one that gets a disproportionate amount of mobile traffic.

And then there’s Microsoft, which started with their homepage. This Potemkin village approach to a responsive redesign can frustrate users—promising them a website that works well on mobile devices, only to betray those expectations on the first tap. But Chris Balt, Senior Web Product Manager at Microsoft, reported that it helped them get organizational buy-in on going responsive:

Other sites have taken different approaches, starting from the bottom up or with some out-of-the-way corner of the site. Our attempt to do it first with the homepage—and beautifully so, if I say so myself—was a good choice. It led to significant visibility that I don’t think we would have gotten if we had started with some second-level support site or something like that. So even though the experience for a user may have suffered—they are one click away from a non-responsive experience—the visibility that it obtained us politically, organizationally, both inside and outside the company, made it a great choice. I am very glad that we did it that way.

Here’s how you might go about rolling out a responsive redesign by section:

Ask Dr. Web with Jeffrey Zeldman: Looking for Love: Standing Out from the Crowd of Web Job Seekers

 ∗ A List Apart: The Full Feed

A note from the editors: During the 1990s, “Ask Dr. Web” was a regular part of—and now Dr. Web is back to answer your career and industry questions. Read on for his advice, learn the story behind the column, submit a question of your own, and join Dr. Web along with Sarah Parmenter for a live career consultation on Wednesday, December 02, 2015, from 1–2 p.m. EST.

In our last installment, we talked about when, why, and how to quit your job.

This time out, we’ll discuss what to do when you have a lot to offer but can’t seem to connect with the right job.

I was hoping you could give me some direction on how to find a design mentor. I was laid off from my product design job about three months ago. I’ve been working as a designer and developer for almost 15 years, so I feel like I have a decent understanding of the industry.

I’ve found myself stuck in a position where I’m seeing little to no traction finding a job or even getting interviews. I don’t know if it’s because I’m currently unemployed, my portfolio is weak, or if I appear too senior on paper, or what. I’ve sought feedback from peers, but the only thing anyone wants to tell me is “you’re a good designer and your work is solid.” I can’t seem to find a source of objective feedback. I don’t know how to grow in order to get out of this slump. Do you have any advice for someone in my position?

Slumpy in Seattle

Dear Slumpy:

Judging from your website, your design work is excellent. Solid, yes—with a light, warm, human touch. Understated craftsmanship that conveys a sense of brand and place, using ordinary typefaces, colors, and interface conventions. I know how hard it is to achieve that level of elegance and grace. You are clearly a mature and seasoned designer.

Perhaps you’re looking for the wrong jobs. You may not be presenting a focused enough persona for the jobs you’ve applied for. A skilled and seasoned generalist designer can always find good work, but won’t get hired at, say, an overfunded and under-directed startup that is looking for cheap designers.

For that matter, a seasoned product designer with a general background won’t get hired by a startup—they’re not only looking for product specialists, they’re looking for product specialists who have a track record at companies just like theirs. They might not hire an excellent designer with a deep understanding of product who hasn’t worked at places like that. Slack, for example, might hire you as a product designer only if you’d already worked as a product designer at Twitter or Facebook. (I’m using Slack simply as an example. Their hiring practices may be entirely different from what I’ve described. But most startups hire people who’ve already worked at startups.)

In other words, people may be providing bland or vague feedback not because there’s anything wrong with your work, but simply because you’re not in the hiring track from which they draw candidates. I had a similar experience during my advertising career, when I was told I could never be hired at a hot boutique agency because I hadn’t started my career at one. (I ended up working at a hot boutique agency anyway, but only after years of wandering in the desert, and then only for peanuts.)

Given that your work is good but people aren’t responding so far, maybe the particular niche you’re seeking work in isn’t hiring people with your background, or maybe that niche is simply overstuffed with good candidates, making it harder to rise above the crowd and get noticed.

If that’s the case, maybe you need to freelance. Maybe you need to start a small independent studio or company with a like-minded peer or two. That’s what worked for me. My career was absolutely going nowhere until I started Happy Cog, originally as a design studio with only one employee—me. Today it’s a boutique studio with offices in two cities. (The kind of boutique studio that might not have hired my younger self.)

What worked for me won’t necessarily work for you, but it might. When you start your own business, you can stop worrying about other people’s limited judgements and their rules about who they want to hire, and start shaping your own destiny. Just an idea.

Not cut out for the rich-today-poor-tomorrow freelance life? Try seeking work outside the obvious circles. If you’ve been an agency person all your career, look in-house. Good web design isn’t limited to digital companies. Traditional businesses need great web designers, too. They may need them more than digital businesses do. Look for a gig at a place that desperately needs design help and acknowledges it in an interview. (You don’t want a job at a place that needs design help but doesn’t know it and won’t understand or value it. You want a place that’s ready to change and looking for the right designer to lead the charge. That’s you.)

Meantime, you’ve been stuck in your cubicle too long. Get yourself out there. (If your current peers aren’t providing feedback that gets you out of your comfort zone, take solace in their assessment that your work is very good—I agree!—then seek out new peers who can push you harder.)

Look for a mentor like you’d look for a mate. Attend meetups (they’re plentiful and free) and lectures (there are plenty of good ones that are free or affordable). If you like what someone says during the Q&A, go up to her or him after the Q&A and start a conversation. If the conversation goes well, exchange numbers. Invite your new friend to coffee. You may have met your mentor. And even if you haven’t, you’ve met a colleague who can help you gain the perspective you seek. Not all mentorship comes from folks in positions of seniority and authority. Sometimes you learn the most from someone else at your own level. Hope this helps!

How We Hold Our Gadgets

 ∗ A List Apart: The Full Feed

A note from the editors: We’re pleased to share an excerpt from Chapter 1 of Josh Clark's new book, Designing for Touch, available now from A Book Apart.

Where do hands and fingers fall on the device? This question is the linchpin for every form factor this book examines, and the answer tells you how to design your layout for comfort and efficiency. Since we hold phones, phablets, tablets, and laptops very differently, it’s no surprise that each of these touchscreen variations has its own UI needs.

Yet these devices also share many consistencies, especially in the crucial role of thumbs. Whether we’re tapping away at tiny phones or jumbo tablets, our thumbs do most of the walking. That fact helps us establish sturdy cross-device guidelines. This chapter looks at why the thumb is so important, and reveals fundamental “rules of thumb” based on how we grab screens of all sizes.

The smartphone is of course the device that we hold most. We stare at it for more than 20% of our waking hours, consulting it 221 times per day on average. Let’s start with that most familiar of gadgets.

Hold the phone

In 2013, researcher Steven Hoober took to the streets to observe over 1,300 people tapping away at their phones. He found that in nearly every case, they held their phones in one of three basic grips. At 49%, the one-handed grip was most popular; 36% cradled the phone in one hand and jabbed with the finger or thumb of the other; and the remaining 15% adopted the two-handed BlackBerry-prayer posture, tapping away with both thumbs.

Drawings showing three different ways of holding smartphones.

Smartphone use is defined by three basic handholds, and we often shift among them.

The study also confirmed what many of us know from our own phone habits: we change grips frequently, depending on convenience and context. We switch between one hand and two, or swap between left and right; sometimes we tap absent-mindedly while doing something else; and other times we stop and give the screen our full attention. Plus: we are nimbly ambidextrous. Hoober found that two-thirds of one-handed grips are in the right hand—a majority, but smaller than the 90% who are right handed. That means many of us favor our non-dominant hand, while using the other to write, drink coffee, hold a baby, or read a book about designing for touch.

So while few of us stick with the same grip, we show a distinct preference for one-handed use. And this is where we get to thumbs. When we hold our phones with one hand, the thumb is the only finger comfortably available for tapping. Even when we use both hands, many of us prefer mashing away with our thumb then, too. Of those who cradle their phone in one hand and tap with the other, Hoober discovered that most use their thumb on the screen. Combine all those folks, and it’s thumbs up: thumbs drive 75% of all phone interactions.

Drawings showing that the most common smartphone grips are thumb-driven.

Though we often refer to “finger-friendly” designs, the thumb does most of the work.

The phone’s thumb zone

While a thumb can sweep most of the screen on all but the most oversized phones, only a third of the screen is truly effortless territory: at the bottom, on the side opposite the thumb. For example, if you hold a phone in the right hand, your thumb falls naturally in an arc at the bottom left corner of the screen—no stretching your thumb or shifting the phone required. The same arc shape applies to the two-handed cradle grip, but the arc is larger because the thumb has greater range of motion.

Comfort and accuracy don’t perfectly align, however. Within this comfort zone, a separate, fan-shaped arc draws out the most accurate targets for thumb tapping, as uncovered in a study by Qian Fei of Alibaba (subscription required). She also found that, for right-handed users, the bottom and top-right corners were the least accurate thumb zones.

Zones showing the easiest access points for thumbs on a smartphone screen.

The green thumb zone is the most comfortable and accurate region of phone screens for one-handed users. Avoid the red-zone reach, or at least compensate with larger-than-usual touch targets.

What about lefties? The thumb zone flips from left to right. But this left-versus-right distinction isn’t especially crucial, since most of us switch hands easily (and frequently) depending on context. Even so, optimizing for one hand penalizes the other: the best solutions put core features at screen middle, where left and right thumb zones overlap. In the end, top versus bottom is more important than left versus right. No matter which hand you use, screen bottom is most comfortable, while the top demands a stretch. That rule holds true for all phone screens, large or small, but as phones grow to jumbo dimensions, that top-screen stretch becomes a strain.

The phabulous phablet

The first generation of post-iPhone devices consistently featured screens under four inches (as measured across the diagonal), an easy size for one-handed use. By mid-2014, however, a third of mobile web-browsing took place on larger screens as bigger phones shouldered into the marketplace. These super-sized devices fill the spectrum between phone and tablet, a category with the dubious nickname phablet, with screens as large as seven inches. My, how our phones have grown up. And down. And sideways.

Photograph showing three people operating phablets.

Samsung’s 7” Galaxy W and similar jumbo devices blur the line between phone and tablet. Photograph courtesy Samsung.

Despite phablets’ gargantuan proportions, people typically handle them like phones, and the three basic grips still apply. Unlike with smaller phones, however, phablet users switch among grips much more often to work the entire screen, and two hands are almost always required. In another study, Hoober and Patti Shank observed that phablet owners use both hands 70% of the time across holds (subscription required). The most popular of these grips, used 35% of the time, is holding a phablet in one hand while tapping with the index finger of the other. But the thumb remains the pointer in charge: 60% of the time, phablet owners tap away with either one thumb or both.

Drawings showing different phablet grips.

Although none of the thumb-driven grips are as common as tapping a phablet with the index finger, they cumulatively account for much more activity.

The phablet’s thumb zone

With so much thumb use, the thumb zone is as important for 4”–7” screens as for smaller ones—with a caveat. Phablet folk use two thumbs more often, which creates a pair of mirrored, overlapping thumb zones at the screen’s bottom, with a swath of tough-to-reach space at the top. Despite its popularity, the double-thumb zone isn’t the one to optimize. Although we hold phablets with one hand only 25% of the time, the single-thumb grip takes on disproportionate importance for designers, because it has the least range.

This brings us to our first rule of thumb for all form factors: always accommodate the most constrained grip, so people can use your interface no matter how they choose to hold their device. On phablets, that means designers should target the single-thumb grip.

Here’s a tricky surprise: the one-handed thumb zone is smaller for phablets than for phones. As phone size increases, the thumb zone remains roughly the same shape and position—anchored to screen bottom—until the size hits a tipping point, where the grip shifts to stabilize the phablet. In that handhold, most people slide their pinky finger under the phone to keep it in place, reducing the thumb’s range.

Zones showing the easiest access points for thumbs on multiple screen sizes.

The size and shape of the thumb zone shifts when the phone’s dimensions require support from the little finger.

Even as swaths of the screen become unreachable by thumb alone, some thumb diehards stick with one-handed use, opting to “choke up” on the phone—sliding their hand higher to extend their thumb’s reach. On phablets, this grip gives people more thumb range overall than the traditional phone grip at screen bottom. We’ll look at the implications of this later in this chapter.

Zones showing thumb access for higher grips on phablets.

A higher one-handed grip on a phablet nets a bigger thumb zone, but the bottom half of the screen goes out of reach.

Tablets: more screen means more handholds

While phones and phablets stay true to three basic grips, there’s no such luck with tablets. More screen means more ways to hold, making things unpredictable. The rule of thumb still applies, but with a special headache: the thumb zone isn’t consistent even for individual devices; it varies depending on stance and posture.

Standing, we typically use two hands to manage a large tablet like the iPad, holding it halfway up the sides for leverage (hold it too close to the bottom, and the thing keels over). Some wrap an arm around it like a clipboard and tap with the other hand. More likely, though, we’re sitting; Hoober and Shank found that 88% of tablet use happens while seated, compared to 19% of phone use. Sitting at a table, we tend to prop up a tablet with one hand at the lower third and, again, tap with the other. Leaning back on the couch, we tend to rest the thing on the belly or nestle it in a blanket, tapping away with one hand. On top of these shifts in grip, each stance also affects how far away we hold the device: we tend to hold tablets closest while standing, and farthest while reclining. Portrait versus landscape is a mixed bag too, with a 60–40 split in favor of a vertical, or portrait, orientation.

As screens get bigger, they also get heavier, and we often lay them down altogether. Hoober and Shank observed that people put large tablets down in nearly two out of three sessions. We rest them flat on a surface (whether table or lap) 40% of the time and upright in a stand 22%. (Smaller 7”–8” tablets are far easier to handle, and 69% of small-tablet use is handheld.) Those surface and stand positions suggest we use large tablets more like traditional monitor screens—or, closer to keyboard-touchscreen hybrids, which we’ll get to in a moment—than handheld devices.

The tablet’s thumb zone

When we do lift up our tablets, they prove too big to be held and operated with one hand, so two hands come into play. Here again, thumbs play an all-important role. We tend to grab tablets at the sides, and while the specific location wanders up and down, thumbs settle at the middle to top third of the screen. This grip makes the neighboring sides and top corners most friendly to touch. On the flip side, the top and bottom edges of tablet screens are hostile zones, because of the necessary reach. The bottom is especially tough, since thumbs are rarely near the bottom—and sometimes that portion of the screen isn’t even visible. In the laziest and perhaps most common tablet posture—lying down—the bottom bezel disappears into blankets, sweaters, or soft bellies.

Zones showing thumb access for a two-handed grip on a phablet screen.

Because the tablet grip is typically at the side edges, the thumb zone changes completely from the phone’s.

We also, of course, often reach into the middle of the screen; as screen size grows, our hands field ever more surface. However, unlike a mouse cursor, which sweeps effortlessly across a screen’s sprawl, our fingers are weighed down by this thing called an arm. This meat pointer goes all the way up to the shoulder, and hefting it around the screen demands effort. An interface shouldn’t be a physical workout: group frequent controls within easy reach of thumbs. Nobody ever broke a sweat twiddling their thumbs.

Hybrids and laptops: slap a keyboard on it

If scaling up the screen size has such a dramatic effect on how we hold a device, it should come as no surprise that adding a keyboard shakes things up even more. Our postures, along with our hands and arms, shift yet again to accommodate the keyboard. Until recently, it was rare to spot this hybrid touchscreen-keyboard combination in the wild. And then came Windows 8.

In 2012, Windows introduced touch interaction to the desktop in a total overhaul of the world’s most-used operating system. In response, a new category of touch devices—touchscreen laptops and tablet-keyboard combos—flooded the consumer market, creating a new ergonomic environment…and fresh demands on designers.

The wrinkle is that hybrids require us to move our hands between keyboard and touchscreen. Before this generation of hybrids arrived, many dinged the concept as ergonomically untenable: shuttling hands to and fro would be too much effort, resulting in a fatigue dubbed gorilla arm. It’s a criticism leveled at the science-fiction interfaces of Minority Report and Iron Man too: Who wants to work with their arms constantly in the air? “Touch surfaces don’t want to be vertical,” a dismissive Steve Jobs said in 2010. “It gives great demo, but after a short period of time you start to fatigue, and after an extended period of time, your arm wants to fall off.”

Research suggests such worries were unnecessary. A study by Intel found that people quickly embrace touch in these new devices, opting for the touchscreen 77% of the time instead of the mouse or keyboard. Despite the availability and precision of the old-school cursor, people said the touchscreen felt more intimate and direct. Other studies have documented this emotional resonance. One reported that people attach more value to products they “touch” on a website versus click with a mouse. When touch is introduced, cold pixels somehow take on the warmth and emotional investment of physical objects. We’ll look at this idea more deeply when we poke at gestural interfaces in Chapter 4.

Appeal aside, the touchscreen isn’t a complete mouse replacement, but rather a welcome addition to the mix—“like having a laptop with an extra gear,” one tester told Intel. With these hybrid devices, people move easily among touch, keyboard, mouse, and trackpad: whatever input seems most convenient. That’s a lot of back and forth, though, and you’d think that would only worsen the gorilla-arm problem. Why aren’t people’s arms going numb? Turns out people quickly figure out how to work the touchscreen without lifting their arms. A study by researcher John Whalen found that when we use touchscreen laptops, we rest our arms alongside the keyboard, keeping a loose grip at the bottom corners of the screen.

The hybrid’s thumb zone

This hands-on-the-corners posture defines the thumb zone for hybrids. Once again, placing touch targets within easy reach of the thumbs makes for easy tapping and, in this case, avoids the need to raise the arms.

Zones showing thumb access on hybrid device screens & Zones showing index finger access on hybrid device screens.

The hot zone for thumbs on hybrid devices settles into the bottom corners, nearly opposite the hot zone for the index finger.

Not everyone adopts the bottom grip, though. Others (especially newcomers) go free-form, jabbing at the screen with their index finger as they roam the entire interface. For designers, this introduces a head-scratcher; the index finger’s hot zone is the reverse of the thumb zone. For index fingers, the center of the screen is easy to hit, and corners are troublesome.

Optimizing for thumbs means a subpar experience for the index finger, and vice versa. One layout has to win, though, and as with every other touch device, studies give the thumb the edge. After a bit of experience with the device, hybrid users soon prefer thumb use for everything, keeping arms planted alongside to thwart gorilla arm.

Photograph showing an example of thumb use in the middle of a hybrid device screen.
Photograph showing an example of thumb use in the middle of a hybrid device screen.

Expert users of touchscreen hybrids prefer heavy thumb use, even to reach deep into the screen. Photographs by Intel Free Press (top, bottom).

And that’s the most striking consistency across the form factors we’ve reviewed: thumbs do the driving no matter how large the screen. The thumb offers the most convenient range of motion with the least possible effort. This physical ease is exactly what Bell Lab’s researchers—along with every industrial designer ever—had to take into account as they designed their interfaces. These ergonomic considerations will determine the layouts for your digital interfaces too. We’ll start with some general principles for all touch designs, then dive into guidelines for different devices.

Infocon: green

 ∗ SANS Internet Storm Center, InfoCON: green

Known “Good” DNS, An Observation

Known “Good” DNS, An Observation, (Thu, Nov 26th)

 ∗ SANS Internet Storm Center, InfoCON: green

This has come up enough it seems worth noting for this U.S ...(more)...


 ∗ One Big Fluke

Fun sailing game you can play in your browser. You need a keyboard. Arrow keys to steer, Z and X to trim the sail.

Malicious spam - Subject: RE: Bill, (Wed, Nov 25th)

 ∗ SANS Internet Storm Center, InfoCON: green


Earlier today (Wednesday2015-11-25), one of our ...(more)...

This week's sponsor: TeamGantt

 ∗ A List Apart: The Full Feed

Keep your projects on track and your clients up to date with intuitive project scheduling from our sponsor TeamGantt.

ISC StormCast for Wednesday, November 25th 2015, (Wed, Nov 25th)

 ∗ SANS Internet Storm Center, InfoCON: green




ISC StormCast for Tuesday, November 24th 2015, (Tue, Nov 24th)

 ∗ SANS Internet Storm Center, InfoCON: green


Superfish 2.0: Dell Windows Systems Pre-Installed TLS Root CA, (Tue, Nov 24th)

 ∗ SANS Internet Storm Center, InfoCON: green

Recently shipped Dell systems have been found to include a special Root CA Certificate and privat ...(more)...

BizCN gate actor sends CryptoWall 4.0, (Tue, Nov 24th)

 ∗ SANS Internet Storm Center, InfoCON: green


Earlier this month, the BizCN gate actor switche ...(more)...

Supreme Court


Writing for the majority, Justice Kennedy called the man's arguments that he could be either Alito or Ginsburg "surprisingly compelling, but ultimately unconvincing."

ISC StormCast for Monday, November 23rd 2015, (Mon, Nov 23rd)

 ∗ SANS Internet Storm Center, InfoCON: green


OpenDNS Research Used to Predict Threat, (Sun, Nov 22nd)

 ∗ SANS Internet Storm Center, InfoCON: green

Two researchers (Dhia Mahjoub Thomas Mathew) have recently presented at BruCON on how they have ...(more)...

Nmap 7.00 is out!, (Sat, Nov 21st)

 ∗ SANS Internet Storm Center, InfoCON: green

After 3.5 years, Fyodor has just released Nmap 7 ...(more)...

Maldoc Social Engineering Trick, (Sat, Nov 21st)

 ∗ SANS Internet Storm Center, InfoCON: green


№ 139: Every Time We Touch—Josh Clark, author of “Designing For Touch”

 ∗ Zeldman on Web & Interaction Design

Author Josh Clark on The Big Web ShowTOUCH introduces physicality to designs that were once strictly virtual, and puts forth a new test: How does this design feel in the hand? Josh Clark’s new book, Designing For Touch, guides designers through this new touchscreen frontier, and is the launchpad for today’s Big Web Show conversation.

In a fast-paced, freewheeling conversation, Josh and I discuss why game designers are some of our most talented and inspiring interaction designers; the economy of motion; perceptions of value when viewing objects on touchscreen versus desktop computer; teaching digital designers to think like industrial designers (and vice-versa); long press versus force touch; how and when to make gestures discoverable; and much more.

Sponsored by DreamHost and BrainTree. Big Web Show listeners can save 15% when ordering Designing For Touch at with discount code DFTBIGWEB. Discount valid through the end of January 2016.


Big Web Show Episode № 139
Big Medium
Designing For Touch

The post № 139: Every Time We Touch—Josh Clark, author of “Designing For Touch” appeared first on Zeldman on Web & Interaction Design.

Mixing Color for the Web with Sass

 ∗ A List Apart: The Full Feed

Color is one of the most powerful components of art and design. We use it to influence mood, create an environment, and tell a story. Over 125 years ago, a great impressionist painter changed the way we think about color by observing light’s role in it. So far, these observations have been largely lost on design for the web, but a preprocessor like Sass gives us a tool to shed new light on our color palettes.

One morning in 1890, Claude Monet began painting the haystacks outside his window. But he didn’t paint just one painting, and he didn’t even paint just one painting at a time. He would have his assistant cart out wheelbarrows of canvases and would work quickly and minimally on each one as the light changed throughout the morning. Sometimes he would work on a painting for just a few minutes before the lighting conditions had changed enough to warrant moving on to the next canvas. When he was finished, Monet had painted twenty-five canvases of the same haystacks in different sunlight, seasons, and weather. The same haystacks, the same base colors—yet presented in myriad ways.

Claude Monet, Haystacks: Snow Effect (1891). Scottish National Gallery; public domain image.
Claude Monet, Haystacks: Snow Effect (1891). Scottish National Gallery; public domain image.

Historically, our ability to translate this kind of flexibility to the web has been limited. We’ve neglected the art of mingling color for emotional impact, while making the most of statically declared CSS color codes. Meanwhile, manipulating color on the fly has been relegated to the arcane realm of programmers.

Thankfully, new tools give us more power over color than ever before. But although color on the web continues to march forward, CSS alone is still pretty inflexible. That’s where preprocessors become useful. Let’s explore some of the capabilities they can lend to our stylesheets:

  • Aliases help us better recognize which colors we’re using.
  • Lightening, darkening, and scaling give us fine-grained flexibility over palettes.
  • Color mixing unlocks our inner Monet and a whole new world of nuance and artistry.

A hex on hex codes

Start with the color declaration: you have to know the exact values of your colors in order to use them. That means that, unless you’re using prefabricated named colors, your style sheet fills up with multiple instances of cryptic hex codes or ambiguous HSL numbers. CSS variables are on the horizon, and they’ll help clarify which color is which with natural language—but what if we don’t actually have a name for our color? That’s the kind of power CSS preprocessors give us. There are several out there to choose from, but my examples rely on Sass. Other preprocessors probably have similar functionality, but I’ll leave you to do that research on your own.

Let’s dig into this to see what I mean.

We’ll create a new brand and choose two colors to represent it. The first thing I’m gonna do is name the colors: $toolbox and $ol-blue.

Brand colors, $toolbox and $ol-blue, for a hypothetical site called Gullfoss Travel Supply Co.

Now that I’ve established my brand colors, I’ve used them to build a website for Gullfoss Travel Supply Co. The concept behind this hypothetical site is to revitalize well-designed luggage labels that show off where you’ve travelled around the world. Variations of my brand colors exist throughout this site in different (lighter) tints and (darker) shades.

Hypothetical site for Gullfoss Travel Supply Co.
Hypothetical site for Gullfoss Travel Supply Co.

Take, for example, this button:

An “Add To Cart” button using a simple gradient.

I wanted to give my button a sense of clickability, which I can easily achieve with a simple gradient. The button is based on the color I dubbed $toolbox. The highlight is a lighter version of the swatch and the shadow is a darker version.

Traditionally, I would write this in CSS like so:

	background-color: $toolbox;  // fallback
	background-image: gradient(
		hsl(0, 33%, 52%),  // highlight
		hsl(0, 41%, 39%);  // shadow

While the button color is based on one of my brand colors, two of these colors (my highlight and shadow) are not in my Sass constants. I had to figure them out on my own. I opened up a color picker and manually picked variations of the swatch. Not a big deal, really, but if I want to add a secondary button, this time based on $ol-blue, I’ll need to go back into the color picker once again and figure out the new values.

And each of these buttons needs a hover state, too! The hover highlights and shadows are going to be lighter than those on the normal button, so do I declare four more constants, or do I just fill these values in once and hope I don’t need to use them again later?

As it turns out, Sass can do this for me. It has built-in functions to process these colors without having to keep track of all the variations.

Packing up the color picker for Sass

One way to lighten a color is to use the lighten function:

lighten($toolbox, 20%);

And to darken a color, we can use the darken function:

darken($ol-blue, 30%);

Simple as that! Now we have a pair of tools to mix color on the fly. Go wild! Okay, don’t go too wild. This can get a bit tricky. Consider this: if we lighten $toolbox by 50 percent, we get a very light version of $toolbox. But if we lighten $ol-blue by 50 percent, it becomes completely white. That’s because $ol-blue is a much lighter color than $toolbox.

In order to know how far we can lighten a color before it turns white, we have to know that color’s lightness value ahead of time. That information is conveniently encoded in its HSL notation. If we subtract the color’s lightness value from 100 percent, the result is the amount we can lighten a color to get to white.

x = 100% - l

Since $ol-blue’s lightness value is 60 percent, we can lighten it up to 40 percent before it becomes perfectly white. $toolbox’s lightness is 40 percent, so we can lighten it by 60 percent.

Table showing that when lightening our colors, $ol-blue turns white faster than $toolbox, because it has a higher base lightness value.
When lightening our colors, $ol-blue turns white faster than $toolbox, because it has a higher base lightness value.
Table showing that when darkening our colors, $toolbox turns black faster than $ol-blue, because it has a lower base lightness value.
When darkening our colors, $toolbox turns black faster than $ol-blue, because it has a lower base lightness value.

Therefore, in order to master this new color palette, we’ll simply need to memorize the lightness values of each of our colors. Kind of annoying, but hey, it’s better than memorizing hex codes, right? Sure! But I’ll do you one better.

Proportional palettes with color scaling

Sass has another color function called scale-color() that can move a color’s components proportionally. scale-color() works on the red, green, and blue channels in RGB, and the saturation and lightness channels in HSL. (To adjust the hue similarly, you would use the aptly-named adjust-hue() function.)

As I noted before, if we were to lighten $ol-blue by 50 percent, it would become pure white, but if we were to scale the lightness with scale-color() by 50 percent—

scale-color($ol-blue, lightness, 50%);

—it would be halfway between the original color and white.

Now I know exactly how much to scale any of my colors to get to white: it’s always going to be 100 percent. If I scale $ol-blue’s lightness by 99 percent, it will still be 1 percent $ol-blue. Likewise for $toolbox or any other color you can dream up (barring colors that are already so light that they may round up to white earlier); they will always top out at 100 percent lightness.

You can more easily see what I mean with the following color table:

Table showing that when scaling the lightness of our colors, they become proportionally lighter, and therefore more predictable.
When scaling the lightness of our colors, they become proportionally lighter, and therefore more predictable.
Table showing that when scaling the darkness of our colors, they become proportionally darker, and therefore more predictable.
The darker variations are proportional, too.

With scale-color(), you can keep your color palette limited to your base constants, but still have incredible, intuitive flexibility with tints and shades. Now our gradient declaration might look something like this:

	background-color: $toolbox;  // fallback
	background-image: gradient(
		scale-color($toolbox, lightness: 50%),
		scale-color($toolbox, lightness: -30%);

button: hover,
button: focus{
	background-color: scale-color($toolbox, lightness: 50%);  // fallback
	background-image: gradient(
		scale-color($toolbox, lightness: 60%),
		scale-color($toolbox, lightness: -20%);

	background-color: $ol-blue;  // fallback
	background-image: gradient(
		scale-color($ol-blue, lightness: 50%),
		scale-color($ol-blue, lightness: -30%);

	background-color: scale-color($ol-blue, lightness: 50%),  // fallback
	background-image: gradient(
		scale-color($ol-blue, lightness: 60%),
		scale-color($ol-blue, lightness: -20%);

In this example, notice I’m only using two of my constants and scaling them as desired. In fact, this can be applied across the entire page. The content on the homepage of the Gullfoss Travel Supply Co. only uses two brand colors, scaled to different lightness values. Despite the simple palette, there’s still a lot of flexibility here.

Mastering color with mixing

There’s one more way you can achieve these kinds of proportional palettes, and that’s with an even more intuitive, more powerful Sass function called mix().

If we want to tint $ol-blue by 60 percent, we’ll write:

mix(white, $ol-blue, 60%)

Think of it like mixing a tube of white paint into a tube of Ol’ Blue. Likewise, if we want to shade $toolbox, we’ll write:

mix(black, $toolbox, 30%)

It turns out that mixing with white and black does perceptually the same thing as scaling a color’s lightness but, conveniently, it’s shorter to type. Beyond that, mix can help you easily create a look and feel on your websites that was previously not possible. If we can mix colors like paint now, can we make our websites look more like paintings? I believe we can—but we have to think less like programmers and more like artists.

Consider, again, Monet’s haystack paintings. They’re a remarkable study of light, and wonderful from a purely aesthetic standpoint. But from a design standpoint, there’s a useful lesson to be found in them. In the words of another French impressionist, Pierre Bonnard, “Color does not add a pleasant quality to design—it reinforces it.” Remember the way the color of light affected the appearance of Monet’s haystacks. What if we could take our base colors and easily influence the color in our designs the way he did back in 1890?

Sass’s mix() function unlocks that for us. Let’s take our color palette again and add in just a couple extra colors: a highlight and a shadow. Now let’s mix our brand colors once more, but instead of simply mixing with black and white, let’s use our new colors:

A couple of new colors for our palette: $highlight and $shadow.

Suddenly the whole palette becomes warm and inviting, and the darker colors are rich and vibrant.

Color table showing that tinting with a yellow highlight gives the palette a sunnier appearance.
Tinting with a yellow highlight gives the palette a sunnier appearance.
Color table showing that shading with a complementary shadow makes the palette feel more natural.
Shading with a complementary shadow makes the palette feel more natural.

If I decide I don’t like this scheme, I can simply choose new values for those two constants, and the next time the Sass is compiled into CSS, the design will automatically reflect my change.

With this next scheme, I’m starting again with the same brand palette, but now the highlight is bright pink, while the shadow is a dark, desaturated green.

New $highlight and $shadow colors.

It totally changes the look of the palette, yet it remains based around our original brand.

Table showing that a change to the highlight and shadow colors is automatically reflected in your color palette when the Sass is compiled into CSS.
A change to the highlight and shadow colors is automatically reflected in your color palette when the Sass is compiled into CSS.
Table showing that highlights and shadows can be tweaked to achieve just the right mood or story for your site, without making tedious changes throughout your stylesheets.
Highlights and shadows can be tweaked to achieve just the right mood or story for your site, without making tedious changes throughout your stylesheets.

Looking back at Gullfoss Travel Supply Co., I’ve demonstrated some of the possibilities with this kind of color mixing on each of the sticker pages. Looking at Olympia’s page, the mood is totally different from the homepage, yet all of the markup, typography, and basic layout stay the same. But since nearly every color has been mixed to some degree with yellow highlights or purple shadows, a new light (literally) has been cast on the page. Now the content background is an eggshell color and the “Add to Cart” button is natural, yet vibrant.

The Olympia page of the Gullfoss Travel Supply Co.  site.

Lincoln’s sticker is colored strongly with tints and shades of red, so I wanted the page to reflect that. I chose reddish highlights and shadows to make the design cohere with the illustration.

The Lincoln page of the Gullfoss Travel Supply Co. site.

When you visit the page for Barton Springs Pool, the cool waters and green leaves are reflected throughout. The difference between the original colors and the new ones is subtle but distinct, and that’s the point. Your colors should work together to create an aesthetic that enhances your design.

The Barton Springs Pool page of the Gullfoss Travel Supply Co. site.

But if drama is what you’re after, look no further than The Grid. This page reverses highlights and shadows and lends a look inspired by the movie Tron. Quite a striking change achieved just by swapping out a few constants!

The Grid page of the Gullfoss Travel Supply Co. site.

Additional considerations for developing your palette

Nearly every color on these pages is mixed with a highlight or shadow to one degree or another, but sometimes the elements in your design can look a little too homogenous, and they start to blend together. In such cases, feel free to supplement your designs with another set of color mixers. This can give the layers of your pages more depth and really make them pop.

Let’s look again at the page for Lincoln. Remember, I wanted to give it a reddish tint. It’s hard to read text against bright red, so I dialed the highlights back a lot; they’re barely red at all. Then I set the background to green. Because green is red’s complement, it plays a trick on your brain, making the very light colors appear redder, while still maintaining a pleasing contrast ratio. (Note: Because this site is responsive, the background layer isn’t visible on narrow screens.) These separate layers use very different highlights and shadows that interact with each other.

To pursue legibility and readability a bit further for a moment, it’s also essential to keep in mind the accessibility of your color schemes. Take another look at the page for The Grid. If you found it uncomfortable to read, you’re not alone! The menu at the top of the page suffers from a low contrast ratio. According to the WCAG guidelines, it should be 4.5:1, but it comes in well below at just 2.6:1! Good contrast ratios of text and background colors make using a site much more pleasant. There are plenty of tools and recommendations for exploring this topic further.

Before I conclude, I want to go over browser support real quick, just so it’s clear. Because all this color processing is compiled into basic CSS color declarations, everything gets translated into a static declaration, which, of course, every browser today can understand. This means that you can start playing around with these techniques today!

Color on the web has come a long way, and it continues to improve steadily as browsers and devices add support for new technologies. Meanwhile, preprocessor mixing has given color an evolutionary leap forward. It offers us unprecedented power to create tints and shades that help us tell our stories, give our palettes more nuance, and bring out our inner Monet.

Designing a good portfolio

 ∗ journal

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…


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.


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

 ∗ journal

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

 ∗ journal

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.

Adventures with Plex

 ∗ journal

I’ve written before about going completely digital for our home entertainment. To recap: I have a big, shared hard drive attached to an iMac that two Apple TVs share to using ATV Flash This was fine for a while, but, frankly, ATV Flash is a little buggy over our network and the Apple TV struggled with any transcoding (converting one file type to another) and streaming – especially in HD. So, we needed something better. In steps a few things: Netflix, Plex and a Mac Mini.

Plex has been on my radar for a few years and up until recently didn’t really make much sense for me. But as ATV Flash was becoming more unstable as Apple updated their OS, then Plex started to look like a good alternative.

The hardware

As you may have read from my older post, I did have shared hard drive with all the media on hooked up to an iMac which the Apple TVs shared into to browse the media. The issue here became network and sharing reliability. Quite often, the shared hard drive was invisible because the iMac was asleep, or the network had dropped. Sometimes this happened in the middle of a movie. Not ideal.

The new setup is almost identical, but instead of using the Apple TVs as hardware to browse the library, they are now being used just as a device to Airplay to. I barely use the Apple TV UI at all. Browsing from my iPad and then air playing to the Apple TV. What’s cool here is that the iPad just acts as a remote, the file itself is being transcoded on the server and just pushed to the Apple TV directly.

What about a standalone NAS (Network Attached Storage)?

Plex does run on a NAS , but the issue there is most consumer NAS boxes don’t have the hardware grunt to do the on-the-fly transcoding. So, I finally decided to ditch my iMac in favour of a headless Mac Mini to run as a decent media box, running Plex.

Getting started with Plex

  1. Download it. Get the Media Server on your computer or NAS of choice (Plex has huge device support). Also, get hold of the mobile apps. Once you’re done there, download Plex for your connected apps: from Chromecast, Amazon Fire TV, Roku, Google TV or native Samsung apps and, now, the Xbox One, too. The app support is really quite incredible.

  2. Plex Pass. Even though the software for Plex is free, there are some additional things that are left for a subscription that you have to buy. The good thing is, you can get a lifetime subscription and the cost is very reasonable at $149.99. For that, you get early access to new builds, syncing content remotely, things like playlists and trailers. But the killer feature of the Plex Pass is the ability to create user accounts for your content. Now this is something I’ve been after for ages on the Apple TV, and even more important now my eldest daughter regularly watches films on it. I need the ability to filter the content appropriately for her.

  3. Setting up a server is a breeze. Once you’ve installed the server software, get yourself a user account on the Plex website and set up a server. This launches some web software for you to start adding files to your libraries and fiddle away to your hearts content with all the settings.

  4. If you did get the Plex Pass, I’d recommend creating multiple user accounts and playlists with the features Plex Pass gives you. The way I did this was to have email addresses and user accounts for server-plex, parents-plex and kids-plex. server-plex is for administering the account and has all the libraries shared with it. ‘parents’ for Emma and I, and ‘kids’ just has the ‘children’s’ library shared with it. Now, by simply signing in and out of the iPad, I can access the appropriate content for each user group.

Next up: streaming, or ‘How do I watch the film on my telly!?’

There are a few options:

  1. Native apps (Samsung, XBox One etc) These are apps installed directly on your TV or Xbox. To watch your content, simply fire up the app and away you go. Yesterday, I installed the Xbox One app and was up and running in less than three minutes.

  2. iOS and Airplay This is what I described earlier. Simply download the iOS apps and hook up to your plex server. Once you’re done, browse your library, press play and then airplay to your Apple TV.

  3. iOS and Chromecast Exactly the same as above!

Now, there are some disadvantages and advantages to streaming.

Disadvantages: From what I understand, adding Airplay into the mix does have a slight performance hit. Not that I’ve seen it, though. I’m only generally streaming 720 rather 1080 resolution, so the file sizes are coming up against network limitations. I do expect this to change in the coming years as resolution increases. Advantages: It’s a breeze. I use my Plex app on my iPad, choose a film or TV show I want to watch and then just stream it via Airplay. When I’m travelling, I take a Chromecast with me to plug into the TV and stream to that (more on that in another post).

‘Hacking’ the Apple TV

Currently there is no native app for the Apple TV, but there is a way to get around this by ‘hacking’ the Trailers app to directly browse your content on your plex server using PlexConnect or OpenPlex. Now, there’s a lot to read to get up to speed on this, so I’d recommend a good look through the plex forums. I followed the instructions here to install the OSX app, add an IP address to the Apple TV (to point to the plex server) and, so far, so good.

To be honest, though, I tend to just Airplay these days. The iPad remote / Apple TV combination is quite hard to beat. It’s fast, flexible and stable.

Is this it for my digital home needs?

For a good few years now I’ve been looking for the optimum solution to this problem. My home media centre needed the following:

  • Multi-user accounts
  • Full-featured remote
  • Large file format support
  • Manage music, photos and movies
  • Fast transcoding and streaming (minimum 720)

Both iTunes, ATV Flash, Drobo (in fact, any domestic NAS) fail on all or most of these points. Plex not only ticks every single box (if it’s run on a decent machine for transcoding), but provides very broad device support, an active developer community and a really good UX for the interface.

Who knows how long I’ll stick with Plex as I do have a habit of switching this around as often as I change my email client (quite often!). But, for now, it’s working just fine!

It's not you, it's me

 ∗ journal

Dear web conferences, It’s not you, it’s me. Something’s changed and it’s not your fault. I’m just on a different path to you. Maybe we’ll be friends in a while, but at the moment I just want some space to do and try other things. I still love you. But we just need a break. Love, Mark

I’m taking next year off speaking at web conferences. It’s not that I don’t have anything to say, or contribute, but more that I have better things to do with my time right now. Speaking at conferences takes about two weeks per conference if it’s overseas once you factor in preparing and writing the talk, rehearsing, travel, and the conference itself. That’s two weeks away from my wife, my daughters, my new job and a team that needs me.

Two conferences the world over

What I’ve noticed this past year or so is, largely, we have two different types of web conference running the world over: small independents and larger corporate affairs. The former is generally run by one person with hoards of volunteers and is community-focussed (cheap ticket price, single track). The latter is big-budget, aimed at corporations as a training expense, maybe multi-track and has A-list speakers.

As well as these two trends, I see others in the material and the way that material is presented. ‘Corporate’ conferences expect valuable, actionable content; that is what corporations are paying for. Schlickly delivered for maximum ROI. ‘Community’ conferences have their own trends, too. Talks about people, empathy, community, and how start-ups are changing the world. Community conferences are frequently an excuse to hang out with your internet mates. Which is fine, I guess.

My problem with both of these is I’m not sure I fit anymore. I’m not what you would call a slick presenter: I ‘um’ and ‘ah’, I swear, I get excited and stumble on stage in more ways than one. Some would say I’m disrespectful to the audience I’m talking to. I’m lazy with my slides, preferring to hand-write single words and the odd picture. I’ve never used a keynote transition. I’m not really at home amongst the world’s corporate presenters who deliver scripted, rehearsed, beautifully crafted presentations. They’re great and everything, but it’s just not me. Not for the first time in my life, I don’t quite fit.

And then there’s the community conferences. I feel more at home here. Or at least I used to. This year, not so much. A lot of my friends in this industry just don’t really go to conferences that much anymore. They have family commitments, work to do, and – frankly – just aren’t that into getting pissed up in a night-club after some talks with 90% men. Younger men at that.

Time for something different

All of that may sound like I’m dissing the conference industry. That’s not my intention, but more like a realisation that, after nearly ten years at speaking at events, I think it’s time I had a little break. Time away to refresh myself, explore other industries that interest me like typography and architecture. Maybe an opportunity to present at one of these types of conferences would present itself; now that would be cool.

I know it’s a bit weird me posting about this when I could quietly just not accept any invitations to speak. To be honest, I’ve been doing that for a little while, but not for the first time, writing things down helps me clarify my position on things. For a while I was angry at web conferences in general. Angry at the content, disappointed with speakers, disappointed at myself. Then I realised, like so many times before, that when I feel like that it’s just that my ‘norm’ has changed. I’m no longer where I used to be and I’m getting my head around it.

It’s just this time, I’m going to listen to my head instead of burying it two feet in some sand.


A Purple Princess

 ∗ journal

When I told my eldest daughter, Alys, about Rebecca Meyer passing away, she wanted to draw her a purple picture. Rebecca was the same age as Alys and she knew ‘exactly what she’d like’. So, here it is:

A purple princess for Rebecca Meyer from Alys Boulton

A Purple Princess for Rebecca Meyer from Alys Boulton, Age 6

In memory of Rebecca, whose favourite colour was purple.

My Handbook – Environment

 ∗ journal

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.


 ∗ journal

Jeremy wrote something special yesterday. That’s not unlike Jeremy, but this blog post in particular struck a chord with me.

A couple of weeks ago, Google Chrome has toyed with the idea of removing most of the URL because it’s a “power user” feature in favour of a simple, easy to understand signpost of where the user is. Jeremy’s point is there is a deeper warning here of ease of use.

… it really doesn’t matter what we think about Chrome removing visible URLs. What appears to be a design decision about the user interface is in fact a manifestation of a much deeper vision. It’s a vision of a future where people can have everything their heart desires without having to expend needless thought. It’s a bright future filled with seamless experiences.

I read Jeremy’s post and kept re-reading it. My instant thought was of food.

I enjoy cooking – have done for a decade – and the more I do, the more I care about ingredients. Good produce matters. Now, I’m not talking about organic artisan satsumas here, but well grown, tasty ingredients; in season, picked at the right time, prepared in the right way. The interesting thing is most people who eat the resulting dish don’t think about food in this way. They experience the dish, but not the constituent parts.The same way some people experience music – if you play an instrument, you may hear base-lines, or a particular harmony. If you enjoy cooking, you appreciate ingredients and the combination of them.

But ingredients matter.

And they do of websites, too. And the URL is an ingredient. Just because a non-power user has no particular need for a unique identifier doesn’t mean it’s any less valuable. They just experience the web in a different way than I do.

Without URLs, or ‘view source’, or seeing performance data – without access to the unique ingredients of websites – we’ll be forced into experiencing the web in the same way we eat fast food. And we’ll grow fat. And lazy. And stop caring how it’s grown.

As Jeremy says: Welcome aboard the Axiom.

A new beginning for Five Simple Steps

 ∗ journal

I’m so happy to tell you that Five Simple Steps has been acquired by Craig Lockwood and Amie Duggan. The dynamic duo behind Handheld conference, The Web Is, FoundersHub and BeSquare. Before I tell you again how thrilled I am, let me take you way back to 2005…

Next year, it will be ten years since I wrote a blog post called Five Simple Steps to better typography. The motivation behind the post was simple: the elements of good typesetting are not difficult, and, with a few simple guidelines, anyone could create good typographic design. That one article became part of a small series of five posts: five simple steps, with each article containing five simple steps. It was a simple formula, but it turned out pretty well.

Soon after that initial post, I wrote Five Simple Steps to designing grid systems for the web, then the same for colour theory. This was now 2006 and I’d just left my job at the BBC. It was a dreary October day and, whilst sat in a coffee shop in Bristol after just visiting one of my first freelance clients, I was talking over email to the Britpack mailing list about compiling my posts into a book. In 2008, Emma and I hired my brother to help me design it and in early 2009, we finally released it. And with the release of that first book, Five Simple Steps Publishing was born. But we didn’t know it at the time.

Over subsequent months and years other authors saw what we produced and wanted us to publish their books. Before we really knew it, we were a publisher with a catalogue of titles and providing a uniquely British voice to the web community. But publishing is tough. As we found out.

All over the world, publishers’ profits are being eroded; from production costs to cost-difference in digital versions. And – except for a couple of notable companies – you see it in the physical books that were being produced for our customers by competitors: terrible paper quality, templatised design, automated eBook production. Everywhere, margins are being squeezed, and the product really suffers.

Our biggest challenge was that Five Simple Steps started as a side project, and always stayed that way. Over time, we just couldn’t commit the time and money it needed to really scale. We had so much we wanted to do – there was never any shortage of great authors wanted to write a book – but could never find the time and energy when we had to run a client services business. Oh, and also during this time, Emma and I had two children. Running and growing two businesses is somewhat challenging when you’re being thrown up on and have barely four hours sleep a night.

So about a year ago, Emma and I sat in our dining room and faced a tough decision: wind down Five Simple Steps, sell it, or give it one more year. We chose the latter. It was a tough year, but Emma, Nick and the team worked to make the Pocket Guide series a great success. So much so, it required tons of work and compounded the problem we had: Five Simple Steps needed to take centre stage rather than be a side project.

A month ago today, Emma and I announced that Five Simple Steps was closing. The team were joining Monotype, and Five Simple Steps could no longer be sustainable as a side project. The writing had been on the wall for a while, but the stop was abrupt for us, the authors and the team. We tried to find the right people to take the company forward before the sale, but we couldn’t find the right people. Luckily, immediately following the announcement, a few people got in touch about seeing if they could help. Two of those people really said some interesting things and got us excited about the possibilities: Craig Lockwood and Amie Duggan.

Craig and Amie live locally in Wales. They run conferences: Handheld conference and The Web Is conference later this year. They also run a co-working space in Cardiff called FoundersHub. They have a background in education and training, and together with their conferences and BeSquare – a conference video streaming site – they have the ecosystem in place to take Five Simple Steps to places we could only dream of. As you may gather, we’re chuffed to bits that Five Simple Steps is going to live on. Not only that, but it’s in Wales and in the competent hands of friends who we know are going to give it the attention it deserves.

Emma and I can’t wait to see where it goes from here.

Conference speakers, what are you worth?

 ∗ journal

Over the past couple of days, there have been rumblings and grumblings about speaking at conferences. How, if you’re a speaker, you should be compensated for your time and efforts. My question to this is: does this just mean money?

I’ve been lucky enough to speak at quite a few conferences over the years. Some of them paid me for my time, some of them didn’t. All of them – with the exception of any DrupalCon – paid for my travel and expenses.

When I get asked to speak at a conference, I try to gauge what type of conference is it. Is it an event with a high ticket price with a potential for large corporate attendance? A middle sized conference with a notable lineup. Or, is it a grassroots event organised by a single person. In other words, is it ‘for-lots-of-profit’, ‘for-profit’, or ‘barely-breaking-even’. This will not only determine any speaker fee I may have charged, but also other opportunities that I could take for compensation instead of cash.

Back to bartering

When I ran a design studio, speaking at conferences brought us work. It was our sales activity. In all honesty, every conference I’ve spoken at brought project leads, which sometimes led to projects, which more than compensated me for my time and effort if it kept my company afloat and food on the table for myself and my team. The time away from my family and team was a risk I speculated against this. Conference spec-work, if you will.

In addition to speculative project leads for getting on stage and talking about what I do, I also bartered for other things instead of cash for myself or my company. Maybe a stand so we could sell some books, or a sponsorship deal for Gridset. Maybe the opportunity to sponsor the speaker dinner at a reduced rate. There was always a deal to be done where I felt I wasn’t being undervalued, I could benefit my company, product or team, but still get the benefit of speaking, sharing, hanging out with peers and being at a conference together.

It’s about sharing

If every speaker I knew insisted on charging $5000 per gig, there will be a lot less conferences in the future apart from the big, corporate, bland pizza-huts of the web design conference world.

My advice to anyone starting out speaking, or maybe a year or so in, is have a think about why you do it. If you’re a freelancer, let me ask you: is speaking at a conference time away from your work, and therefore should be calculated as to how much you should charge based on your hourly rate? Or, is it an investment in yourself, your new business opportunities, and the opportunity to share. Of course, the answer to this is personal, and – for me – depends on what type of conference it is.

This community is unique. We share everything we do. We organise conferences to do just that. Most of the conference organisers I know come from that starting point, but then the business gets in the way. Most speakers I know, get on stage from that starting point, but then the business gets in the way.

There’s nothing wrong with valuing yourself and your work. If speaking is part of your work, then you should be compensated. But next time you’re asked to speak by a conference, just stop for a moment and think about what that compensation should be.


 ∗ journal

Just like most two year olds, my daughter likes to ask ‘why?’ Recently, I’ve tried responding to every ‘why’ to see where it leads. It’s like a cross between improv and some perverse version of Mallet’s Mallet. Here’s a transcript of a conversation I recorded in the car earlier today:

  • Me: We’re going into Cardiff today.
  • Two year old: Why?
  • Me: To go to the castle
  • Two year old: Why?
  • Me: Because it’s better than watching TV, and it’s a nice day!
  • Two year old: Why?
  • Me: That’s what happens when the sun shines
  • Two year old: Why?
  • Me: Because there are no clouds
  • Two year old: Why?
  • Me: It’s due to high pressure
  • Two year old: Why?
  • Me: Because that’s how weather works
  • Two year old: Why?
  • Me: There’s lots to it: solar radiation, air movement, global warming…
  • Two year old: Why?
  • Me: Weather is complicated
  • Two year old: Why?
  • Me: Lots of factors. That’s why we have people telling us what the weather will be.
  • Two year old: Why?
  • Me: So we know when to wear a coat
  • Two year old: Why?
  • Me: So we don’t get wet
  • Two year old: Why?
  • Me: Because wearing wet clothes is miserable, and it’ll give you a cold.
  • Two year old: Why?
  • Me: Because, apparently, it can make you more at risk of infection.
  • Two year old: Why?
  • Me: Maybe your immune system. Everyone has one.
  • Two year old: Why?
  • Me: To stop you getting sick.
  • Two year old: Why?
  • Me: So you can continue living.
  • Two year old: Why?
  • Me: To procreate.
  • Two year old: Why?
  • Me: To continue the human race.
  • Two year old: Why?
  • Me: You know, i’ve no idea.
  • Two year old: OK.

A conversation like that has happened almost every day for the past few weeks. This was the longest. And deepest.

Mark Boulton Design and Monotype

 ∗ journal

Today is a big day for me. One of the biggest of days. I’m delighted to announce that Mark Boulton Design has been acquired by Monotype. You can read the full press release here, but before you do, I’d like to take you back a few years…

Eight years ago, Emma and I were driving down from visiting my parents near Manchester. It was a sunny, blustery day in June 2006.

During this time, we both worked for the BBC – Emma in Audience Research, and me in, what was then called, New Media. As a lot of designers do, I was working some freelance work on the side. A couple of weeks prior to that car trip, however, I’d been offered a freelance project that was too good to turn down, but it was big. Bigger than a few hours a night when I got home from the day job. On that car trip, we decided that one of those jobs had to go: my freelance work, or the job at the BBC. I chose the latter, and the very next day, handed in my resignation at the BBC. It was time to head out alone.

Eight years later and it’s time for another change.

Running a design studio has been a fabulously rewarding experience. I’ve worked with some talented people on some great projects for wonderful clients. But, all through this time, there has been a niggling problem, one that I’ve talked about at a couple of design conferences this year. When we’re hired by a company to work on their project, just by the nature of the engagement, we’re not as close to the problem as we need to be. We’re not in-house. We’re not experiencing them day by day. And, quite often, we’re not in the position to help fix the problems in the organisation as we uncover them. Having the opportunity to be closer to the problem really excites me, and that’s why this change is such an important decision for me at this time in my career.

We know the web is going through an interesting time right now. This is not so much being felt by us in the industry, but by the myriad of companies who publish content that are struggling to cope with the changes and demands their readership and customers put on their services. Being close to that problem excites me, and that’s just what this opportunity with Monotype represents. We’re going to be working with some of smartest people I’ve met on a broad range of tools and services that cross the boundaries of two fields of design I hold dear: web design and typography. What could be better than that?

Five Simple Steps will also be closing its doors. For five years, Emma and I have been accidental publishers and, together with the team here, and some talented authors, have produced many practical and influential books. Those books aren’t going away, though. As of today, Five Simple Steps is ceasing to trade, but is giving those books back to the authors to distribute as they see fit. We’re also freely distributing our ePub template and process, to help people self-publish just like I did five years ago. And, today, I’m also giving away my book, Designing for the Web. You can freely download it in PDF, ePub and Kindle (.mobi) formats.

Our responsive grid application, Gridset, is currently being considered as how it can sit alongside Monotype’s Typecast product. Since both services launched, I’ve lost count of the amount of people who use the two together and asked us to integrate somehow.

The last eight years has been quite a ride, but as I said, it’s time for a change. And, for me, a great change at that. The team here at Mark Boulton Design will still be working with me. We’ll still be contributing to the community the best way we can. I’ll still be harping on about something or other on Twitter.

Today marks the closing of one chapter and the beginning of another. It’s the part in any story that I love the most, because, to my mind, it’s the best bit.

Collaborative Moodboards

 ∗ journal

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

 ∗ journal

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

 ∗ journal

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.


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.

Net Awards 2014 Nominations

 ∗ journal

It’s that time of year again. The 2014 .net award long list is published and I’m rather chuffed that Mark Boulton Design is nominated across community, technology and design categories.

It’s also really nice to see CERN nominated for the Line Mode Browser hack days we helped organise last September.

Being nominated in these awards is like a nice pat on the back for all the hard work my team do. From trying to help communicate one of human-kinds most important discoveries, to building a tool to help us make websites a little bit easier, to making books for our community. It makes the nomination for Agency of the year, for the second time, that little bit more special.

If you feel that inclined, a vote would be nice!

Al Jazeera & Content shelf-life

 ∗ journal

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.

The story is the link

 ∗ journal

2013 brought with it more work in and amongst editorial processes for Mark Boulton Design. And with it, some challenges designing systems that can react to the speed of the story.

News happens quickly and therefore needs to be captured quickly. This is why news organisations have latched onto the immediacy of publishing platforms like Twitter, blogs, Instagram and the like. The flow from story to pixel is dramatically reduced compared to incombant editorial processes. Sure, journalists will cry of the death of proper journalism; story-telling will suffer at the hands of snippets of information drip-fed to hungry millenials. We’ve all heard the horror stories. The truth is that these services allow for a story to happen in near real-time, and as such, the emphasis on an editor’s work is no longer writing, but on guiding, the story. Creating connections between content to build a bigger picture in the reader’s mind, but, certainly, in a near-live environment, many news organisations are not authoring this content; it’s being created elsewhere by other people.

I’ve had a long-standing professional interest in content management systems. I’ve designed a few along the way, and almost without exception, the project has started as a software design project, and ended up a process design problem. The problems lie with people, not with user interfaces or technology.

In his recent post How to design a CMS for a modern newsroom, Lee Simpson from the Guardian eloquently describes the situation:

So much has changed in the ‘electronic publishing’ landscape in the last year. For every month of 2013 there was a hot new writing application, hip new publishing platform or collaboration silver bullet for writers, newsrooms and media organisation to run through the mill. Tools and applications for content publishing had matured in such a short period of time, individually they lacked the cross workflow power to be of complete use to a newsroom like The Guardian’s, but collectively it was starting to look a lot more interesting.

He goes on to say:

The software requirements for a modern, paper producing newsroom, are vast. The needs of the newsroom are increasingly difficult to define due to the nuances in production processes across desks, publications and offices, a moving target that is getting faster by the day.

In my experience, the faster and more important a story was, the less likely it was to follow established processes – especially where convoluted and difficulty to use software was concerned. It quickly devolved into Post-it Notes, hushed whispers and hurried editing. News journalists are human, and sometimes the speed of the story is just too fast for software. It gets in the way.

Given the change in how this type of content is created, curated, edited, processed and published, more and more organisations are finding they need new tools. New content management systems to help solve their publishing problems. My fear is, they’re looking in the wrong place.

Last year, I spoke at Handheld conference about how content is created over time. How a story moves from being a snowflake to a snowball; gathering pace, other content, debris. Before an editor knows it, the story is no longer a page, but a bunch of different things: links, images, words, video, other articles, tweets, blog posts. The list goes on. But they all share two things in common: the topic of the story, and the link between them. This is where I feel we need to focus our attention.

The hyperlink is at the very core of what the web is: an interconnected hyperlinked bunch of resources. The hyperlink is everything to the web, yet it is the thing we take the least care of. URLs die. Links rot. This isn’t a post about digital preservation, or a rant about how we should be taking care of these links for future generations, but that we should be taking care of them now!. As I hope I’ve demonstrated, the link between content is going to become increasingly important as we create more fragmented and modular content for display in multiple contexts. If we don’t look after these links, the story will be lost. Because the story isn’t a page anymore. The story is the link.

Modern content management systems should be focussed on exposing links between content. Making it easy for editors and journalists to make connections between things and not just when a story is created; stories live over many days, weeks, months or years. Modern content management systems should allow for constant editorial iteration and creation by showing the links between things.

It’s interesting to me to see this happen in a parallel industry. Just as designers and developers are struggling to adapt to the increasingly rapid changing web, writers and journalists are, too. Creating news content for the web is no longer about writing a page and hitting publish. It requires a fastidious approach to content curation over a longer period of time. It means being where your readers are; Twitter, Facebook, the TV. It requires pulling together all the various fragments of a story into a cohesive narrative. Now, does that sound like your CMS is designed to help? No. I thought not.

Some social good

 ∗ journal

I was going to do a usual year-end wrap up for this blog post as I have done in previous years. But, as it’s the start of the new year already, I thought set my stall out for the coming year. What do I want to do, rather than what have a just done.

A couple of days ago, I was reminded of a video I watched a while ago about Free Enterprise via my friend Andy Rutledge.

“Don’t Eat Your Dog: The Surprising Moral Case for Free Enterprise. Based on his best-selling book “The Road to Freedom,” AEI President Arthur C. Brooks explains how we can win the fight for free enterprise by articulating what’s written on our hearts.”

I’m always interested in how other country’s politics, viewpoints and economics work, and this was no exception. Rather than to bat down things like capitalism, I’m making a concerted effort to understand the nuance in such things.

As someone who runs a design studio, a publishing company and a web-based design tool, you could count me in the group of people who work hard for what I get. And I’m rewarded for that. I don’t expect a free ride. I don’t expect anything beyond the realms of what is offered in the country I live in (such as state health care and education etc. In fact, I pay for that through my taxes – the NHS is not free). But before I disappear into a politics hole, I want to bring this back to design.

Running a design company, we charge clients for the work we do and for the customers who use our products and buy our books. In doing so, we create jobs, and more tax revenue for the government. But one thing I don’t agree with from the video above is that what i’m doing is a purely selfish exercise. I’m not just doing business to pay the bills, design great products for clients, and give people work to do. To me, there is more to making things than just making things.

I believe my job is not only about doing work for clients but that I have a social responsibility to make the world a better place through the work I do. Design is a powerful tool to affect social change. However small.

Let me give you an example.

You’re out for a walk at lunchtime. You come at a road crossing and there is a family by your side waiting to cross the road. The crossing indicator is counting down the seconds, but you spot a small gap in the traffic for you to cross. You just skip across the road, running in between cars and carry on. The family is left waiting for a safe gap in the traffic.

Do you:

  1. Think that what you did was fine? It was safe for you to cross. No problem.


  1. Do you think that you should’ve waited next to the family to build upon the good example the parents were trying to show to their small children that they should wait for a safe gap in the traffic to cross?

It’s a small but important thing. And this is social responsibility. A responsibility to help the community around you, and not through just helping yourself. Next time you take on a design project, just stop for a second and think:

“beyond getting paid for this, and making my client’s business better, what is the benefit in doing this work? What is the social good?”

In addition to the work itself, ask them if you could blog about the process, or speak about the work at a conference. If it’s something you really believe in, could you offer do it pro-bono, or heavily discounted? Could you open source the code produced? How about aspects of the design – such as icons? Could you have one of their team members sit with your team for the whole project to soak up your skills? How could you benefit the web design and development community and still get paid well?

We’re in an incredibly fortunate position as designers to create change in the world. Many people can’t. Or simply won’t. Through our products, our work, and how we talk about it, we can have a much greater benefit to society that just lining our pockets.

This is exactly what I plan on doing in 2014. Happy New Year!

Running ragged

 ∗ journal

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)

Responsive times two: essential new books from Ethan Marcotte & Karen McGrane

 ∗ Zeldman on Web & Interaction Design

Responsive Design times two! New books from the geniuses, Ethan Marcotte and Karen McGrane.

IT WAS the early 2000s. The smoke from 9/11 was still poisoning my New York.

Karen McGrane was a brilliant young consultant who had built the IA practice at Razorfish while still in her early 20s, and was collaborating with my (now ex-)wife on some large, exciting projects for The New York Public Library. Ethan Marcotte was a Dreadlocks-hat-sporting kid I’d met in Cambridge through Dan Cederholm, with whom he sometimes collaborated on tricky, standards-based site designs. The first edition of my Designing With Web Standards was in the can. I figured that, like my previous book, it would sell about 10,000 copies and then vanish along with all the other forgotten web design books.

Nothing happened as I expected it to. The only thing I got right besides web standards was the desire to some day work with Karen, Ethan, and Dan—three dreams that, in different ways, eventually all came true. But nothing, not even the incredible experience of working with these luminaries, could have prepared me for the effect Ethan and Karen and Dan would have on our industry. Even less could I have guessed back then the announcement it’s my pleasure to make today:

Ethan Marcotte’s Responsive Design: Patterns and Principles and Karen McGrane’s Going Responsive are now available in our A Book Apart store.

It was thrilling to bring you Ethan and Karen’s first industry-changing A Book Apart books. Being allowed to bring you a second set of absolutely essential works on responsive design from these two great minds is a gift no publisher deserves, and for which I am truly grateful.

Building on the concepts in his groundbreaking Responsive Web Design, Ethan now guides you through developing and using design patterns so you can let your responsive layout reach more devices (and people) than ever before.

Karen McGrane effortlessly defined the principles of Content Strategy for Mobile. She’s helped dozens of teams effectively navigate responsive projects, from making the case to successful launch. Now, she pulls it all together to help you go responsive—wherever you are in the process.

Ebooks are available immediately and paperbacks ship next week. Buy Responsive Design: Patterns and Principles and Going Responsive together and save 15%! (Learn more.)

The post Responsive times two: essential new books from Ethan Marcotte & Karen McGrane appeared first on Zeldman on Web & Interaction Design.

Save “Save For Web”

 ∗ Zeldman on Web & Interaction Design

TWENTY years or so ago, Adobe Photoshop was, as its name suggests, primarily a tool for professional commercial photographers. Strange though it may seem for a company that now sells its software via a “Cloud” subscription service, the web was not at all on Adobe’s radar in those days. “Save For Web” was not even a widely held concept, let alone a Photoshop menu option.

This vacuum created an opportunity for independent developers and designers. Which is how the very talented Craig Hockenberry of Iconfactory and I came to release Furbo Filters, an indie shareware product that let designers prepare images for the web. It did a few other things as well, such as offering garish, psychedelic treatments you could apply to any image—not unlike the far more expensive (and also far, far more developed) Kai’s Power Tools. (And you know what they say: if you’re old enough to remember Kai’s Power Tools, there’s a Drop Shadow in your closet. But I digress.) Some of you may have used DeBabelizer to manage your web color palettes in those days when Adobe and Photoshop ignored the web. Some may even have used Furbo Filters.

Then Adobe created a “Save For Web” option (in Photoshop 5.5), and Furbo Filters’s beautiful market was gone in a moment. All that remains as a memento of that time and that product is the domain name, which is where Craig keeps his blog.

I was reminded of this during a workplace discussion about the seeming disappearance of “Save For Web” from modern Photoshop.

To be clear, “Save For Web” still exists in Photoshop CC 2015. But it has been rather awkwardly deprecated, as revealed through both UX (“Save For Web” no longer appears in the part of the interface where we’ve been trained to look for it for the past twenty years) and language: when we stumble onto “Save For Web” hiding under Export, after not finding it where we expect it, we’re presented with the words “Save For Web (Legacy),” clearly indicating that the feature is no longer a recommended part of today’s workflow.

Adobe explains: “Because Save for Web is built on the former ImageReady product (now discontinued), the code is too antiquated to maintain and develop new features.” (If Furbo Filters and DeBabelizer didn’t resurrect dead brain cells for some of you, I bet “ImageReady” did. Remember that one? Also, how scary is it for me that half the tools I’ve used in my career only exist today as Wikipedia entries?)

Instead of Save For Web, we’re to use Export: Export As…, which Adobe has built on its Generator platform. Stephen Nielson, writing on Jeff Tranberry’s blog for Adobe, explains:

Adobe Generator is a new, modern, and more efficient platform for exporting image assets from Photoshop. We have been building new capabilities on top of this platform for the past two years, including the new Export As and Device Preview features. The Generator platform allows us to build new, streamlined workflows and incorporate more efficient compression algorithms like PNGQuant into Photoshop.

The new Export As workflows are a complete redesign of how you export assets out of Photoshop. Export As has new capabilities like adding padding to an image and exporting shapes and paths to SVG. We also introduced the Quick Export option, which allows you to export an entire document or selected layers very quickly with no dialog.

Going forward, we will no longer develop new features in Save for Web, which is why it now is labeled as “Legacy”. Don’t worry; no features have been removed from it and we know there are critical workflows that still require Save for Web. However, Save for Web does not support, for example, new Artboard documents.

—Jeff Tranberry’s Digital Imaging Crawlspace, “Save for Web in Photoshop CC 2015

While I believe the Export As function is built on newer code, and I get that Adobe is committed to it, after months of use, I still spend a tremendous amount of time searching for Save For Web whenever I use Photoshop. And when I make myself use Export As, I still don’t feel that I’m getting the speed, power, and options I loved and came to depend on in Save For Web. This is a subjective reaction, of course, and “users hate change” is not a truth to which designers are immune—but I’ve yet to meet a designer who prefers the new tool and doesn’t feel confused, frustrated, and bummed out about the switch.

What I’m saying is, Craig, let’s talk.

The post Save “Save For Web” appeared first on Zeldman on Web & Interaction Design.

Reliably hosted by