Journal

2560 sparkline

Tuesday, March 5th, 2019

From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets

The unstoppable engine of An Event Apart in Seattle rolls onward. The second talk of the second day is from the indominatable Una Kravets. Her talk is called From Ideation to Iteration: Design Thinking for Work and for Life. Here’s the description:

Have you ever had a looming deadline and no idea where to start? Do you have a big task to face but are having trouble figuring out how to get there? Have you ever wanted to learn a technology, or build a side project but didn’t know what to build? In this talk, Una will go over an actionable approach and several techniques for applying design thinking to our work and every aspect of our lives. This includes ideating product features, blog post ideas, or even what general direction we want to move toward in our businesses. We’ll go over traditional approaches and breakout techniques that will leave you feeling more in control and ready to reach your goals.

Let’s see if I can keep up with this…

Una’s going to talk about design thinking. Una does a variety of different work outside her day job—a podcast, dev doodles, etc. Sometimes at work she’s given big, big tasks like “build a design system.” Her reaction is “whut?” How do you even start with a task like that.

Also, we make big goals sometimes. Who makes new year’s resolutions? But what does “get more fit” or “earn more income” even mean?

In this talk, Una will break things down and show how design thinking can be applied to anything.

Design thinking

A stategic, solution-based approach to solving problems.

It’s a process. It’s iterative. It’s used by IBM, Apple, GE, and it’s taught to students at a lot of different universities.

Tim Brown of Ideo points out that there’s a Venn diagram of feasability, desirability, and viability. In the middle is the point of innovation.

The steps are:

  1. Empathise — develop a deep understanding of the challenge
  2. Define — clearly articulate the problem.
  3. Ideate — brainstorm potential solutions.
  4. Prototype — design a protoype to
  5. Test — and iterate.

Una feels that the feedback part is potentially missing there. IBM uses a loop diagram to include feedback. Ideo uses these steps:

  1. Frame a question
  2. Gather inspiration
  3. Generate ideas
  4. Make ideas tangible
  5. Test to learn
  6. Share the story

Another way to think about this is how the teams interact. There’s divergence and convergence throughout. Then there’s the double diamond: design, deliver, discover.

Ideo wrote a book called Design Thinking for Libraries. It has some useful tools and diagrams. Una found this fascinating because it wasn’t specifically about products. In healthcare, GE Health used design thinking for their Adventure Series MRI scanners—it resulted in 80% less need to use sedatives. The solution might seem obvious to us in hindsight, but it wouldn’t have been obvious to medical professionals in their everyday busy lives.

Design thinking is bullshit, says Natasha Jen. She describes how it’s become an over-used term that has lost its value. Una can relate—she gets annoyed when there’s too much talking and not enough doing. Design thinking is not diagrams and sticky notes. It’s a process. It’s very much about doing something to shift perspective. It’s another tool in our toolkit, even if it has become an overused term like “synergy.”

Back in 2014, when Una was working at IBM, she thought design thinking was stupid. It seemed to be all talk, talk, talk. It felt tedious. It was 75% talking and 25% development. The balance wasn’t right.

But it’s also true that solutioning too early leads to cruft. If you end up going back to the drawing board, maybe the time could’ve been better spent doing some design thinking up front. Focus on the problem, not the solution.

Now some developers might be thinking that this is outside their area. But it can really help you in your career. It can help you choose technologies. Also, everyone on the team, regardless of role, is responsible for the product.

1. Empathise

Understand your users and the challenge. This could be a task that a user is trying to accomplish, or it could be you trying to get a raise.

Sometimes we forget who our user is. The techniques in this first step helps us solve their needs, not our needs.

You might have many users that you’re trying to help, but try focusing in on a few. You can create personas. When Una was working at Digital Ocean, the users were developers. The personas reflected this. Do the research to get to know your users.

Next, you can create an empathy map for your users. What are their goals? What are their hopes? What will they gain from your product?

Connect the empathy map to a specific context—a goal and or a scenario that the user is going through.

Bear in mind that there are many layers to your user. There are conscious rational thoughts, but also subconscious emotional thoughts. Empathy mapping helps you understand how to best communicate with your user.

Una shares a real-life scenario of hers: create a new shop-able product that increases time on site. That’s a pretty big goal. She creates a persona for a college-educated woman working in the medical field who commutes on the subway, keeps a skin-caring routing, and is getting into cake-making. Next, Una creates an empathy map for this persona. What she says, thinks, feels, and does. All of this is within the context of browsing your fashion media website casually at work.

2: Define

The problem statement should be:

  • Human-centred,
  • Specific, but not too technical (don’t solutionise too soon),
  • Narrow in scope.

How can we best create a product-highlighting web experience that Rosalyn will enjoy to increase her time on site?

You can use a tool with two columns: As-Is and to-Be. The first column is what users currently do. The second column is what you want to achieve.

3. Ideate

This is the fun part. Good old-fashioned brainstorming is good here. Go for quantity here. Get loads of ideas out.

There’s also a “worst possible ideas” game you can play at this stage. It can be a good ice-breaker.

Have a second round of brainstorming where you play the “yes, and…” game to build on the first round.

When Una was working on The Zoe Report, she found that moodboards were really useful. The iteration cycle was very fast. A moodboard allowed them to skip a lot of the back and forth between design and development. They built the website without any visual design mock-ups. They prototyped quickly, tested quickly, and shipped quickly.

Journey-mapping is the next tool you can use in this ideation phase. Map out the steps between the start and end of a user journey. Keep it simple. This is a great time to refine your product and reduce complexity.

Next, start sketching out ideas. Again, this is a great time to uncover issues and solve problems before things get too defined. But remember, when you’re showcasing your ideas in sketches, too many ideas can lead to analyis paralysis.

Oh dear. Jam. Jam. Jam. Jam. Jam. Yes, Una is using the paradox-of-choice jam example …the study who’s findings could not be reproduced.

4. Prototype

Go forth and build. A prototype can exist on a number of different axes:

  • Representation—the form it takes.
  • Precision—the detail it contains.
  • Interactivity—the extent a user can interact with it.
  • Evolution—the life stage it is at.

There are lot of prototyping tools out there. Prototypr.io helps you find the right tool for you. It breaks things down by fidelity and life cycle.

But not all prototyping has to be digital. Paper prototyping only needs pen, paper, and scissors. Some tips:

  • Use a transparency sheet for forms.
  • Use well-visible and mid-tip pens.
  • Draw up your prototype in black and white—people can get caught up in colour.

But on the web, Una recommends getting to digital as quickly as possible because interaction is such a big part of the experience. That’s why Una likes to prototype in code. But this is still a rapid prototyping phase so don’t get too caught up in the details.

5. Test

Testing with internal teams is fine during the ideation phase, but to understand how users will relate to your product, you need to test with representative people. We are not our users.

As well as the user, have a facilitator, a computer, and a scriber. As a facilitator, it’s a good idea to reduce the amount of input you give a user. Don’t hand-hold too much or you will give away your pre-existing knowledge. Encourage your user to be verbal.

Sessioncam is a tool for creating a heatmap of where people are interacting. There are also tools for tracking clicks or mouse hovers. These all feel so utterly icky to me.

The metrics you might be looking to gather could be click-through rate, time-on-site, etc. But, Una cautions, be very wary of adding all these third-party scripts to your site and slowing it down. Who’s testing the A/B tests?

On Bustle, Una wanted to measure interactions on mobile. They tested different UI elements for interactions. They ended up updating the product with a horizontal swiping component. They were able to improve the product and ship a more refined experience.

6. Review and iterate

Una feels that this step is the most important. Analyse your successes and failures, and plan to improve.

Technology changes over time so what’s feasible and viable also changes.

Design thinking on the daily

You can use design thinking in your everyday life. Maybe you want to learn JavaScript, or write blog posts, or get more fit. Una used design thinking brainstorming to break down her goals, categorise and organise them.

“Get better at JavaScript” is a goal that Una has every year.

Empathise. In this situation, the user is you. You can still create a persona of yourself. Define. Why do you want to get better at JavaScript? Is it about making better use of your time? Ideate. There are so many different ways to learn. There are books and video courses. Or you could have a project to focus on. Break. It. Down! Create actionable steps and define how you will measure progress. Match the list of things you want to learn with the list of possible side projects. Prototype. Don’t take it literally. Just build something. Test. You’re testing on yourself in this case. Review. Una does an annual review. It’s a nice therapeutic exercise and helps her move forward into the next year with actionable goals.

Another goal might be “Write a blog post.”

Empathise. Your users are your potential readers. Who do you have in mind? Make personas. Define. What’s the topic? Ideate. If you don’t know what to write about, brainstorm. What are you working on at work that you’re learning from? Select one to try. Prototype. Write. Test. Maybe show it to co-workers. Review. How did it go? Good? Bad? Refine your process for the next blog post.

Here’s a goal: “Buy a gift for someone.”

Empathise. What does this person like? What have they enjoyed receiving in the past? Define. Is the gift something they’ll enjoy for a long time? Something they can share? Ideate. Bounce ideas off friends and relatives. Prototype. In this case, this means getting the gift. Review. Did they like it?

“Get Fit.”

In this case, the review part is probably the most important part.

Marie Kondo asks “Does this spark joy?” Ask the same question of your goals.

Remember, design thinking is not just about talking, and sticky notes. It’s about getting in the right headspace for your users.

Design thinking matters—because everything we do, we do for people. Having the tools to see through the lens of those people will help you be a more well-rounded person.

How to Think Like a Front-End Developer by Chris Coyier

Alright! It’s day two of An Event Apart in Seattle. The first speaker of the day is Chris Coyier. His talk is called How to Think Like a Front-End Developer. From the website:

The job title “front-end developer” is very real: job boards around the world confirm that. But what is that job, exactly? What do you need to know to do it? You might think those answers are pretty cut and dried, but they’re anything but; front-end development is going through something of an identity crisis. In this engaging talk, Chris will explore this identity through the lens of someone who has self-identified as a front-end developer for a few decades, but more interestingly, through many conversations he’s had with other successful front-end developers. You’ll see just how differently this job can be done and how differently people and companies can think of this role—not just for the sake of doing so, but because you’ll learn to be better at your own jobs by understanding how other people are good at theirs.

I’m going to see if I can keep up with Chris’s frenetic pace…

Chris has his own thoughts about what front-end dev is but he wants to share other ideas too. First of all, some grammar:

I work as a front-end developer.

I work on the front end.

Those are correct. These are not:

I work as a front end developer.

I work on the front-end.

And this is just not a word:

Frontend.

Lots of people are hiring front-end developers. So it’s definitely a job and a common job title. But what does it mean. Chris and Dave talked to eight different people on their Shop Talk Show podcast. Some highlights:

Eric feels that the term “front-end developer” is newer than the CSS Zen Garden. Everyone was a webmaster, or as we’d say now, a full-stack developer. But if someone back then used the term “front-end developer”, he’d know what it meant.

Mina says it deals with things you can see. If it’s a user-facing interface, that’s front-end development.

Trent says that he thinks of himself as a web designer and web builder. He doesn’t feel he has the deep expertise of a developer, and yet he spends all of his time in the browser.

So our job is in the browser. You deal with the browser (moreso than other roles). And by the way, there are a lot of browsers out there.

Maybe the user is what differentiates front-end work. Monica says that a back-end developer is allowed not to care about the user if their job is putting a database together. It’s totally fine not to call yourself a front-end developer, but if you do, you need to care about the user.

There are tons of different devices and browsers. It’s overwhelming. So we just gave up.

So, a front-end developer:

  • Is a job and a job title.
  • It deals with browsers, devices, and users.
  • But what skills does it involve?

It’s taken for granted that you can use a computer. There’s also the soft skills of interacting with co-workers. Then there are the language-specific core skills. Finally, there are the bonus skills—all the stuff that makes you you.

Core skills

The languages you need to strongly understand to read, write and maintain them.

HTML and CSS. Definitely. You don’t come across front-end developers who don’t do those languages. But what about JavaScript?

Eric says it’s fine if you know lots of JavaScript but it’s also fine if you don’t write everything from scratch. But you can’t be oblivious to it. You need to understand what it can do.

So let’s put JavaScript into the bucket of core skills too.

Peggy believes that as a front-end developer you need to have a basic proficiency in accessibility too. This is, after all, about user-facing interfaces.

Bonus skills

The Figma team have a somewhat over-engineered graphic of all the skillsets that people might have, between “baseline” and “supplementary”.

Perhaps we all share a common trunk of skills, and then we branch in different directions.

Right now though, it feels like front-end development is having an identity crisis. It’s all about JavaScript, which is eating the planet.

JavaScript

JavaScript is crazy popular now. It’s unignorable. Yes, it’s the language in the browser, but now it’s also the language in loads of other places too.

Steven Davis says maybe we need to fork the term front-end development. Maybe we need to have UX engineers and JavaScript engineers. Can one person be great at both? Maybe the trunk of skills forks in two very different directions.

Vernon Joyce called this an identity crisis. The concepts in JavaScript frameworks are very alien to people with a background in HTML, CSS, and basic interactive JavaScript.

You could imagine two people called front-end developers meeting, and having nothing in common to talk about. Maybe sports.

Brad says he doesn’t want to be configuring build tools. He thinks of himself as being at the front of front-end development, whereas other people are at the back of front-end development.

This divide is super frustrating to people right now.

Hiring

Michael Schnarnagl brings up the point about how it’s affecting hiring. Back-end developers are being replaced with JavaScript engineers. Lots of things that used to be back-end tasks are now happening on the client side. Component-driven design, site-level architecture, routing, getting data from the back end, mutating data, talking to APIs, and managing state—all of those things are now largely a front-end concern.

Let’s look at CodePen. There’s a little heart icon on each pen. It’s an icon component. And the combination of the heart and the overall count is also a component. And the bar of items altogether—that’s also a component. And the pen it sits under is a component. And the page it’s in is a component. And the URL for that page is a component. Now the whole site is a front-end developer’s concern.

In the past, a front-end developer would ask a back-end developer for an API endpoint. Now with GraphQL, the front-end developer can craft a query to get exactly what they need. Sure, the GraphQL stuff had to be set up in the first place, but that’s one-time task. Once it’s set up, the front-end developer has everything they need.

All the old work hasn’t gone away either. Semantics, accessibility, styling—that’s still the work of a front-end developer as well as all of the new stuff listed above.

Hiring is a big part of this. Lara Schenk talks about going for an interview where she met 90% of the skills listed. Then in an interview, she was asked to do a fizzbuzz test. That’s not the way that Lara thinks. She would’ve been great for that job, but this single task derailed her. She wrote about it, and got snarky comments from people who thought she should’ve been able to do the task. But Lara’s main point was the mismatch between what was advertised and what was actually being hired for.

You see a job posting for front-end developer. Who is that for? Is it for someone into React, webpack, and GraphQL? Or is it for someone into SVG, interaction design, and accessibility? They’re both front-end developers. And remember, they can learn one another’s skills, but when it comes to hiring, it has to be about the skills people have right now.

Peggy talks about how specialised your work can be. You can specialise in SVG. You can specialise in APIs and data.

We’re probably not going to solve this right now. The hiring part is definitely the worst part right now. One solution is to use plain language in job posts. Make it clear what you’re looking for right now and explain what background you’re coming from. Use words instead of a laundry list of requirements.

Heydon Pickering talks about full-stack developers. Their core skills are hardcore computer science skills.

Brad Frost concurs. It tends not to be the other way around. The output tends to be the badly-sketched front of the horse.

Even if there is a divide, that doesn’t absolve any of us from doing a good job. That’s true whether it’s computer science tasks or markup and CSS.

Despite the divide, performance, accessibility, and user experience are all our jobs.

Maybe this term “front-end developer” needs rethinking.

The brain game

Let’s peak into the minds of very different front-end developers. Chris and Dave went to Dribbble, pulled up a bunch of designs and put them in front of their guests on the Shop Talk Show.

Here’s a design of a page.

  • Brad looks at the design and sees a lot of components of different sizes and complexity.
  • Mina sees a bunch of media objects.
  • Eric sees HTML structures. That’s a heading. That’s a list. Over there is an unordered list.
  • Sam sees a lot of typography. She sees a type system.
  • Trent immediately starts thinking about how the design is supposed to work in different screen sizes.

Here’s a different, more image-heavy design.

  • Mina would love to tackle the animations.
  • Trent sees interesting textures and noise. He wonders how he could achieve those effects without exporting giant image files.
  • Brad, unsurprisingly, sees components, even in a seemingly bespoke layout.
  • Eric immediately sees a lot of SVG.
  • Sam needs to know what the HTML is.

Here’s a more geometric design.

  • Sam is drawn to the typography.
  • Mina sees an opportunity to use writing modes.
  • Trent sees a design that would reflow and reshape itself well.
  • Eric sees something with writing mode, grid, and custom fonts.

Here’s a financial mobile UI.

  • Trent wants to run it through a colour-contrast analyser, and he wants to know if the font size is too small.

Here’s a crazy festival website.

  • Mina wonders if it needs a background video, but worries about the performance.

Here’s an on-trend mobile design.

  • Monica sees something that looks like every other website.
  • Ben wonders whether it will work in other parts of the world. How will the interactions work? Separate pages or transitions? How will it feel?

Here’s an image-heavy design.

  • Monica wonders about the priority of which images to load first.

Here’s an extreme navigation with big images.

  • Ben worries about the performance on slow connections.
  • Monica gets stressed out about how much happens when you just click on a link.
  • Peggy sees something static and imagines using Gatsby for it.

Here’s a design that’s map-based.

  • Ben worries about the size of the touch targets.
  • Monica sees an opportunity to use SVGs.

Here’s a card UI.

  • Ben wonders what the browser support is. Can we use CSS grid or do we have to use something older?
  • Monica worries that this needs drag’n’drop. Now you’ve got a nightmare scenario.

Chris has been thinking about and writing about this topic of what makes someone a front-end developer, and what makes someone a good front-end developer. The debate will continue…

Designing Intrinsic Layouts by Jen Simmons

Alright, it’s time for the final talk of day one of An Event Apart in Seattle. The trifecta of CSS talks is going to finish with Jen Simmons talking about Designing Intrinsic Layouts. Here’s the description:

Twenty-five years after the web began, we finally have a real toolkit for creating layouts. Combining CSS Grid, Flexbox, Multicolumn, Flow layout and Writing Modes gives us the technical ability to build layouts today without the horrible hacks and compromises of the past. But what does this mean for our design medium? How might we better leverage the art of graphic design? How will we create something practical, useable, and realistically doable?

In a talk full of specific examples, Jen will walk you through the thinking process of creating accessible & reusable page and component layouts. For the last four years, Jen’s been getting audiences excited about what, when, and why. Now it’s time for how.

I’m not sure if live-blogging is going to work given the visual nature of this talk, but I’ll give it a try…

How many of us have written CSS using display: grid? Quite a few. How many people feel they have a good grip on it? Not so many.

Jen has spent the last few years encouraging people to really push the boundaries of graphic design on the web now that we have the tools to do so in CSS. But Jen is not here today to talk about amazing new things. Instead she’s going to show the “how?” The code is on labs.jensimmons.com.

Let’s look at laying out a header. You might have a header element with a logo image, the site name in an h1, and a nav element with the navigation. The logo, the site name, and the navigation are direct children of the parent header. By default we get everything stacked vertically.

<header role="banner">
    <img class="logo" src="..." alt="...">
    <h1>Site title</h1>
    <nav>
        <ul>
            <li><a href="...">Home</a></li>
            <li><a href="...">Episodes</a></li>
            <li><a href="...">Guests</a></li>
            <li><a href="...">Subscribe</a></li>
            <li><a href="...">About</a></li>
        </ul>
    </nav>
</header>

Why should we care about starting with semantic HTML? It matters for reusability and accessibility, but also for reader modes in browsers. These tools remove the cruft. If you mark up your content well, it will play nicely with reader modes. Interestingly, there are no metrics around how many people are using reader modes (by design). Mozilla has a product called Pocket that’s a “read later” app. It can also turn saved articles into a podcast for you. Well marked up content matters for audio playback.

Now let’s start applying some CSS. Fonts, colours, stuff like that. Everything is still stacking vertically though. It’s flow content. This can be our fallback layout. Now let’s apply our own layout. We could use float: left on the logo. Now we need some margins. We can try applying widths and floats to the h1 and the nav. Now we need a clearfix to get the parent to stretch to the full height of the content. It’s hacky. floats suck. But it’s all we had until we got flexbox. But even using flexbox for this kind of layout is a hack too. What we really need is CSS grid.

Apply display: grid to the header. Use Firefox’s dev tools to inspect the grid. Seeing the grid helps in understanding what’s going on. We’ve got three grid items in three separate rows. Notice that we don’t have margin collapsing any more. We can get rid of margins and use grid-gap instead. But we want is three columns, not three rows. We’ll try:

grid-template-columns: 1fr 1fr 1fr;

Looks okay. Not exactly the spacing we want though. We want the logo and the navigation to take up less space than the site name. We could translate our old percentage values into fr equivalents. 8% becomes 8fr. 75% becomes 75fr. 17% becomes 17fr. But the logo and the nav never shrink below their actual size. Layout isn’t working like we’re used to. The content will never get smaller than the minimum content size. So the amount of space assigned to each column is no longer linear.

Let’s change those fr units to percentages. Now we need to get rid of our gaps. But now when the layout gets small, everything squishes up. This is what we need breakpoints for. But now we can do something else. Let’s make the logo max-content. That column will now be the size of the logo. The other columns can remain `fr:

header {
    grid-template columns: max-content 3fr 1fr;
}

Let’s also define the last one—the navigation—as max-content. We can toss auto in for the middle content (the site name):

header {
    grid-template columns: max-content auto max-content;    }

Let’s layout the navigation horizontally. The best tool for this is flexbox. The li elements are the flex items. So the ul needs to be the flex container.

ul {
    display: flex;
}

Looking good. Let’s allow items to wrap onto another line:

ul {
    display: flex;
    flex-wrap: wrap;
}

Let’s change that navigation from max-content to auto so that it doesn’t get too long:

header {
    grid-template columns: max-content auto auto;   }

(How you want the navigation items to wrap determines whether you use flexbox or grid. Both are perfectly valid choices. There’s nothing wrong with using grid for the small stuff.)

Just look at how little code we need for this layout!

Let’s try a different layout. We’ll put the navigation on a new row.

header {
    grid-template-columns: min-content auto;
    grid-template-rows: auto auto
}

Let’s get the logo to span across both rows:

.logo {
    row-span: 2;
}

Need to finesse the alignment of the navigation? No problem. Play with align-self property on the nav element.

Again, look at how little code this is!

But these layouts are safe. We need to break out of our habits. What about disjointed text? Let’s take the h1. Apply some typography and colour. Also apply overflow-wrap: anywhere. Now the text can break within words.

We can take this further. But to do that, we have to wrap all of my letters in separate spans. Yuck!

Apply display: grid to the h1 that contains all those span children. Say grid-template-columns: repeat(8, 1fr) to make an eight-column repeating grid.

Let’s make it more interesting. We can target each individual letter with grid-column and grid-row. There are many ways to tell the browser where to place grid items. We can tell them the start lines. By default it will take up one cell.

Let’s add some images. Let’s rotate items. Place items wherever we want them. Mess around with the units to see what happens. Play with opacity when elements overlap. See the possibilities!

But, people cry, what about Internet Explorer? Use @supports

/* code for every browser */

@supports (display: grid) {
    /* code for modern browsers */
}

Set up a fallback outside the @supports block. Toggle grid on and enough in dev tools to see how the fallback will look. If this kind of thinking is new to you, please watch youtube.com/layoutland where Jen talks about resilient CSS.

Let’s try something else. Jen got an email announcement for an event. It had an interesting bit of layout with some text overlapping an image.

Mark up the content: some headings and images. By default the images are displayed inline. The headings are displayed as blocks.

Think about where your grid lines will need to go. How many lines will you need? How about setting your columns with 1fr 3fr 3fr 1fr? Now how many rows do you need? You define and the grid on the container and tell the items where to go. Again, it’s not much code. Tweak it. How about setting the columns to be 1fr minmax(100px, 400px) min-content? You have to mess around to see what’s possible. You can use all sorts of units for columns: fixed lengths (pixels, ems, rems), min-content, max-content, percentages, fr units, minmax(), and auto. Play around with the combinations.

Jen shows a whole bunch of her demos. Check them out. Use web inspector to play around with them.

And with that, the first day of An Event Apart Seattle is done!

Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew

The CSStastic afternoon of day one of An Event Apart in Seattle continues with Rachel Andrew. Her talk is Making Things Better: Redefining the Technical Possibilities of CSS. The description reads:

For years we’ve explained that the web is not like print; that a particular idea is not how things work on the web; that certain things are simply not possible. Over the last few years, rapid browser implementation of advances in CSS have given us the ability to do many of these previously impossible things. We can use our new powers to build the same designs faster, or we can start to ask ourselves what we might do if we were solving these problems afresh.

In this talk, Rachel will look at the things coming into browsers right now which change the way we see web design. CSS subgrids allowing nested grids to use the track definition of their parent; logical properties and values moving the web away from the physical dimensions of a computer screen; screen experiences which behave more like an app, or even paged media, due to scroll snapping and multidimensional control. By understanding the new medium of web design we can start to imagine the future, and even help to shape it.

I’m not sure if it even makes sense to try to live-blog a code talk, but I’ll give it my best shot…

Rachel has been talking about CSS at An Event Apart for over three years now. Our understanding of the possibilities of CSS has changed a lot in that time. Our use of floats for layout is being consigned to history. It’s no less monumental than the change from tables to CSS. Tableless web design often meant simplifying our designs. We were used to designing in a graphic design tool and then slicing it up into table cells. CSS couldn’t give us the same fine-grained control so we simplified our designs. It got us to start thinking of the web as its own medium. That idea really progressed with responsive web design.

But perhaps us CSS advocates downplayed some of the issues. We weren’t trying to create new CSS, we were just trying to get people to use CSS.

What we term “good web design” is based in the technical limitations of CSS. We say “the web is not print” when we see a design that’s quite print-like. People expect to have to hack at CSS to get it to do what we want. But times have changed. We have solved many of those problems (but that doesn’t mean we got all of them!).

Rachel spends a lot of time telling designers: you never know how tall anything is on the web. It used to be a real challenge to get the top and bottom of boxes to line up. We’d have to fix the height of the boxes. And if too much content goes in, the content overflows. Then we end up limiting the amount of content at the CMS side. We hacked around the problem. A technical limitation influenced our design, and even our content management. Then we got flexbox. Not only did the problem disappear, but the default behaviour is exactly what we struggled with for years: equal height columns.

How big is this box? You’ve seen the “CSS is awesome mug”, right?

Our previous layout systems relied on percentage lengths for widths. Those values had to add up to 100%, and no more. People tried to do the same thing with flexbox. People made “grid systems” with flexbox that gave widths to everything. “Flexbox is weird!”, people said. But the real problem is that flexbox is not the layout method you think it is. It’s for taking a bunch of oddly-sized things and returning the most reasonable layout for those things. It assigns space in a smart way. That solves the problem of needing to give everthing a width. It figures it out for you. If you decide to put widths on everything, you’re kind of working against flexbox.

We’re so used to having to hack everything in CSS, we had to take a step back with flexbox and realise that hacks aren’t necessary.

CSS tries to avoid data loss. That’s why the “CSS is awesome” text overflows the box. You don’t want the text to vanish. Visible overflow is messy, but it’s better than making some content disappear.

In the box alignment specification, there’s the concept of safe and unsafe alignment. Safe:

.container {
    display: flex;
    flex-direction: column;
    align-items: safe center;
}

You give the browser permission to align items to the start if necessary. But you can override that with unsafe:

.container {
    display: flex;
    flex-direction: column;
    align-items: unsafe center;
}

Overflow is going to happen. Now it’s up to you what happens when it does.

The “content honking out of the box” problem described in the “CSS is awesome” meme is now controlled with min-content:

width: min-content;

The box expands to encompass the widest content.

You have many choices. But what if the text isn’t running left to right? It might not be a problem we run into for English text. For years, CSS had that English-centric assumption baked in. Now CSS has been updated to not make that assumption. The web is not left to right. Flexbox and grid take an agnostic approach to the writing mode of the document. There’s no “top”, “bottom”, “left” or “right”. There’s “start”, “end”, “inline” and “block”. Now we have a new spec for logical properties and values. It maps old physical values (top, bottom, etc.) to the newer agnostic values.

So even if you use writing-mode to flip direction, width is still a width. Use inline-size instead of width and everything keeps working: the width maps to height when you apply a different writing-mode value. Eventually we’ll use those flow-relative values more than the old values. Solutions need to include different writing modes.

There is no fold. We’ve said that for years, right? But we know where the fold is. We’ve got viewport units that represent the width and height of the browser viewport. We can start to make designs that make use of the viewport. You can size a screen full of images exactly to fit the visible space. Combine it with scroll-snap to get the page views to snap as the user scrolls. You get paged layout. That’s interesting for Rachel because she’s used to designing for paged layout in print versus continuous layout on the web.

What’s next for CSS grid? Grid layout has been the biggest problem-solver of recent years. But that doesn’t mean it has solved all the layout problems. New problems appear as we start to work with CSS grid. We often end up nesting grids. But the nested grids don’t have any knowledge of one another. We’re back to: you never know how tall things are on the web. We need a way to have a relationship. Some kind of, I don’t know, subgrid.

You could use display: contents. It removes a box from the visual display allowing grandchildren to act like children. The browser support is good, but there’s a stonking accessibility bug so don’t use it in production. Also you can’t apply visual styles to anything that’s got display: contents on it. But grid-template-rows: subgrid will solve this problem. The spec is in a good shape. We’re waiting for the first browser implementations.

You will hit problems. Find new technical limitations. It’s just that we can’t do that stuff yet. We get the new stuff when we create it. Write up the problems you come across.

We’re finding the edges. Rachel is going to share her problems.

Rachel wants to put some text into her image grid. No problem. But then if there’s too much text, it might not fit in a height-restricted row. We can adjust the row to not be height-restricted, but then we lose the nice viewport-fitting layout.

In continuous media—which is what the web is—content inside multicol gets longer and longer. You can fix the height of the container but then the columns get created horizontally. What if you could say, I want my multicol container to be, say 100vh high, but if the content overlows, create a new 100vh high container below. Overflow in the block dimension. Maybe that’ll be in the next version of the multicol spec.

Multicol doesn’t solve Rachel’s image grid situation. What she needs is a way for the text to fill up a box and then flow into another box. The content needs to be semantically marked up—not broken into separate chunks for layout—and we want the browser to figure out where to break that content and fill up available space.

It comes as a surprise to people that a lot of paged media—books, magazines—are laid out with CSS. It’s in the paged media module. Prince is a good example of a user agent that supports paged media. There’s the concept of a page box: a physical page into which content can go. You get to define the boxes with physical dimensions like inches or centimeters. You create a bunch of margin boxes with generated content. Enough pages are created to hold all the content. You create your page model and flow the content through it.

Maybe apps and websites with defined screens are not that different from paged contexts. There have been attempts to create CSS specs that would allow this kind of content-flowing behaviour. CSS regions was one attempt. There was -ms-flow-into and -ms-flow-from in the IE and Edge implementations. You had to apply -ms-flow-into to an iframe element.

Regions needs ready-prepared boxes for the content to flow into. But how can you know how many boxes to prepare in advance? You don’t know how big things will be on the web. Rachel has been told that there’s nothing wrong with the CSS regions spec because you can define a final bucket for all leftover content. That doesn’t seem like a viable solution.

CSS regions predated CSS grid and didn’t take off. Now that we’ve got grid, something like regions makes a lot of sense.

Web design has been involved in a constant battle with overflow. Whether it’s overflowing boxes, or there (not) being a fold, or multicol layout. Rachel thinks we can figure out a way to get regions to work. Perhaps regions paved the way for something better. Maybe it was just ahead of its time. There are a lot of things hidden away in CSS specs that never made it out: things that didn’t make sense until more advanced CSS came along.

Regions—like multicol—relies on fragmentation. Ever tried to stop a heading behind the last thing on a page in a print stylesheet? We need good support for break-inside, break-before, and break-after.

We create new things to solve problems. Maybe you don’t see the value of something like regions, but I bet there’s been something where you thought “I wish CSS could do this!”.

Rob wrote up a problem that he had with trying to have a floated element maintain its floatiness inside a grid. He saw it as a grid problem. Rachel saw it as an exclusions problem. Rob’s write-up was really valuable to demonstrate the need for exclusions. Writing things up is hugely valuable for pushing things forward. Write up your ideas—they’ll show us the use case.

Ask “why can’t I do that?” Let’s not fall into the temptation of making things grid-like just because we have CSS grid now. Keep pushing at the boundaries.

Many of things Rachel has shown—grid, exclusions, regions—were implemented by Microsoft. With Edge moving to a Chromium rendering engine, we must make sure that we maintain diversity of thought in the standards process. Voices other than those of rendering engines need to contribute to the discussion.

At a W3C meeting or standards discussion, the room should not be 60-70% Googlers.

More than ever, the web needs diversity of thought. Rachel isn’t having a dig at Google. This isn’t a fight between good and evil. It’s a fight against any monoculture. So please contribute. Get involved. Together we can work for the future of the web platform.

Monday, March 4th, 2019

Generation Style by Eric Meyer

It’s time for the afternoon talks at An Event Apart in Seattle. We’re going to have back-to-back CSS, kicking off with Eric Meyer. His talk is called Generation Style. The blurb says:

Consider, if you will, CSS generated content. We can, and sometimes even do, use it to insert icons before or after pieces of text. Occasionally we even use it add a bit of extra information. And once upon a time, we pressed it into service as a hack to get containers to wrap around their floated children. That’s all fine—but what good is generated content, really? What can we do with it? What are its limitations? And how far can we push content generation in a new landscape full of flexible boxes, grids, and more? Join Eric as he turns a spotlight on generated content and shows how it can be a generator of creativity as well as a powerful, practical tool for everyday use.

Wish me luck, ‘cause I’m going to try to capture the sense of this presentation…

So we had a morning of personas and user journeys. This afternoon: code, baby! Eric is going to dive into a very specific corner of CSS—generated content. For an hour. Let’s do it!

He shows the CSS Generated Content Module Level 3. Eric wants to focus on one bit: the pseudo-elements ::before and ::after. What does pseudo-element mean?

You might have used one of these pseudo-elements for blockquotes. Perhaps you’ve put a great big quotation mark in front of them.

blockquote:: after {
    content: "“";
    font-size: 4em;
    opacity: 0.67;
/* placement styles here */
}

Why is Eric using ::after? Because you can. You can put the ::after content wherever you want. But if your placement styles fail, this isn’t a good place for the generated content. So don’t do this. Use ::before.

Another example of using generated content is putting icons beside certain links:

a[href$=".pdf"]::after {
    content: url(i/icon.png);
    height: 1em;
    margin-right: 0.5em;
    vertical-align: top;
}

But these icons look yucky. But if you use larger images, they will be shown full size. You only have so much control over what happens in there. I mean, that’s true of all CSS: think of CSS as a series of strong suggestions. But here, we have even less control than we’re used to. Why isn’t the image 1em tall like I’ve specified in the CSS? Well, the generated content box is 1em tall but the image is breaking out of this box. How about this:

a[href]::after * {
    max-width: 100%;
    max-height: 100%
}

This doesn’t work. The image isn’t an element so it can’t be selected for.

The way around it is to use background images instead:

a[href$=".pdf"]::after {
    content: '';
    height: 1em; width: 1em;
    margin-right: 0.5em;
    vertical-align: top;
    background: center/contain;
    background-image: url(i/icon.png);
}

Notice there’s a right margin there. That stretches out the width of the whole link. That’s exactly the same as if there were an actual span in there:

a[href$=".pdf"] span {
    height: 1em; width: 1em;
    margin-right: 0.5em;
    vertical-align: top;
    background: center/contain;
    background-image: url(i/icon.png);
}

So why use generated content instead of a span? So that you don’t have to put extra spans in your markup.

Generated content is great for things that work great when they’re there, but still work fine if they’re not. It’s progressive enhancement.

You’ve almost certainly used generated content for the clearfix hack.

.clearfix::after {
    content: '';
    display: table;
    clear: both;
}

Ask your parents. It’s when we wanted to make the containing element for a group of floating elements to encompass the height of those elements. Ancient history, right? Well, Eric is showing an example of a certain large media company today. There are a lot of clearfixes in there.

Eric makes the clearfix visible:

.clearfix::after {
    content: '';
    display: table;
    clear: both;
    border: 10px solid purple;
}

It looks like a span: a 10 pixel wide box. Now change the display property:

.clearfix::after {
    content: '';
    display: block;
    clear: both;
    border: 10px solid purple;
}

Now it behaves more like a div than a span.

The big question here is: who cares?

Let’s say we’re making a site about corduroy pillows (I hear they’re really making headlines).

<header>
<h1>Corduroy pillows</h1>
<p>Lorum ipsum...</p>
</header>

We can add a box under the header:

header::after {
    content: " ";
    display: block;
    height: 1em;
}

You can do stuff with that extra content, like using a linear gradient:

header::after {
    content: " ";
    display: block;
    height: 1em;
    background: linear-gradient(to right, #DDD, #000, #DDD) center / 100% 1px no-repeat;
}

The colour stops are #DDD, #000, and #DDD. You get this nice gradiated line under the header. You can chain a bunch of of radial gradients together to get some nice effects. You could mix in some background images too. Now you’ve got some on-brand separators. You could use generated content to add some “under construction” separators.

By the way, ever struggled to keep track of the order of backgrounds? Think about how you would order layers in Photoshop.

How about if we could use generated content to make design tools?

div[id]::before {
    content: attr(id);
}

Now the generated content is taken from the id attribute. You can make it look like Firebug:

div[id]::before {
    content: '#' attr(id);
    font: 0.75rem monospace;
    position: absolute;
    top: 0;
    left: 0;
    border: 1px dashed red;
    padding: 0 0.25em;
    background: #FFD;
}

You can even make the content cover the whole box with bottom and right values too:

div[id]::before {
    content: '#' attr(id);
    font: 0.75rem monospace;
    position: absolute;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    border: 1px dashed red;
    padding: 0 0.25em;
    background: #FFD8;
}

(And yes, that is a hex value with opacity.)

Let’s make it less code-y:

div[id]::before {
    content: attr(id);
    font: bold 1.5rem Georgia serif;
    position: absolute;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    border: 1px dashed red;
    padding: 0 0.25em;  
    background: #FFD8;
}

Throw in some text-shadow. Maybe some radial gradients. We’re at the wireframe stage. Let’s drop in some SVG images to show lines across the boxes.

How about automating design touches?

pre {
    padding: 0.75em 1.5em;
    background: #EEE;
    font: medium Consolas, monospace;
    position: relative;
}

Let’s say that applies to:

<pre class="css">
...
</pre>

You can generate labels with that class attribute:

pre::before {
    content: attr(class);
    display: block;
    padding: 0.25em 0 0.15em;
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

Let’s align it to the top of it’s parent with negative margins:

pre::before {
    content: attr(class);
    display: block;
    padding: 0.25em 0 0.15em;
    margin: -0.75em -1.5em 1em;
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

Or you can use absolute positioning:

pre::before {
    content: attr(class);
    display: block;
    padding: 0.25em 0 0.15em;
    position: absolute;
    top: 0;
    right: 0;
    left: 0;
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

Now let’s change the writing mode:

pre::before {
    content: attr(class);
    display: block;
    padding: 0.25em 0 0.15em;
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    writing-mode: vertical-rl;
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

Now the text is running down the side, but it’s turned on its side. You can transform it:

pre::before {
    content: attr(class);
    display: block;
    padding: 0.25em 0 0.15em;
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    writing-mode: vertical-rl;
    transform: rotate(180deg);
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

But if you this, be careful. Your left margin is no longer on the left. Everything’s flipped around.

You could also update the generated content according to the value of the class attribute:

pre.css:: before {
    content: '{ CSS }';
}

pre.html::before {
    content: '< HTML >';
}

pre.js::before,
pre.javascript::before {
    content: '({ JS })();';
}

It’s presentational, so CSS feels like the right place to do this. But you can’t generate markup—just text. Angle brackets will be displayed in their raw form.

But positioning is so old-school. Let’s use CSS grid:

pre {
    display: grid;
    grid-template-columns: min-content 1fr;
    grid-gap: 0.75em;
}

pre::before {
    content: attr(class);
    margin: -1em 0;
    padding: 0.25em 0.1em 0.25em 0;
    writing-mode: vertical-rl;
    transform: rotate(180deg);
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

Heck, you could get rid of the negative margins by putting the code content inside a code element and giving that a margin of 1em.

You can see generated content in action on the website of An Event Apart:

li.news::before {
    content: attr(data-cat);
    background-color: orange;
    color: white;
}

The data-cat attribute (which contains a category value) is displayed in the generated content.

Cool. That’s all stuff we can do now. What about next?

Well, suppose you had to put some legalese on your website. You could generate the numbers of nested sections:

h1 { counter-reset: section; }
h2 { counter-reset: subsection; }

Increment the numbers each time:

h2 { counter-increment: section; }
h3 { counter-increment: subsection; }

And display those values:

h2::before {
    content: counter(section) ".";
}
h2::before {
    content: counter(section) counter ":" (subsection, upper-roman);
}

Soon you’ll be able to cycle through a list of counter styles of your own creation with a @counter-style block.

But remember, if you really need that content to be visible for everyone, don’t rely on generated content: put it in your markup. It’s for styles.

So, generated content. It’s pretty cool. You can do some surprising things with it. Maybe ::before this talk, you didn’t think about generated content much, but ::after this talk ,you will.

Designing for Personalities by Sarah Parmenter

Following on from Jeffrey and Margot, the third talk in the morning’s curated content at An Event Apart Seattle is from Sarah Parmenter. Her talk is Designing for Personalities. Here’s the description:

Just as our designs today must accommodate differences of gender, cultural background, and other factors, it’s time to create apps, websites, and internal processes that account for still another strand of human diversity: our very different personality types.

In this new presentation, Sarah shares real-life case studies demonstrating how businesses and organizations large and small are learning to adjust the thinking behind their websites and processes to account for the wishes, needs, and comfort levels of all kinds of people.

We know that the world is full of different conventions—currency, measuring systems, and more—and our web forms address these differences. Let’s do the same for the emotional and psychological assumptions behind our customer profiles. Let’s learn to design for a palette of different personalities.

I’m going to do my best to write down some of what she says…

Sarah works with Adobe, and at a gathering last year, she ended up chatting with some of her co-workers about ancestry, for some reason. She mentioned that she had French and Norwegian roots. The French part is evident in her surname: parmentier means potato farmer. So Sarah did a DNA test. It turned out that Sarah had no French or Norwegian roots—everything in her ancestry came from within an eighty mile radius of her home. It was scary how much she strongly believed for years in something that just wasn’t true.

It’s like that on the web. There are things we do because lots of people do them, but that doesn’t mean they work. Many websites and digital processes are broken and it’s down to us to fix it.

With traditional personas, we make an awful lot of assumptions about people. Have a look at facebook.com/ads/preferences. See just how easy it is for computers to make startling amounts of assumptions.

The other problem with personas is that they are amalgamations. But there’s no such thing as an average costumer. The Microsoft design team add much more context so that they can design for real people in real situations.

Designing for personas only takes care of a fraction of the work we need to do. When we add in another layer of life getting in the way, and a layer of how someone is feeling, you’ve a medley of UX issues that need solving.

The problem is that personality traits aren’t static. They evolve with context. Personas are contextual but static. What we should really be doing is creating the most desirable experience for the user, and we can only do that by empowering them, as Margot also said. We need to give our users control.

If there were such controls, Sarah would use them to reduce motion on websites. She suffers from motion sickness and some websites literally make her sick. There is a prefers-reduced-motion media query but so far only Safari and Firefox support it. It’s hard to believe that we haven’t been doing this already. This stuff seems so obvious in hindsight.

Sarah asks who in the room are introverts. People raise their hands (which seems like quite an extroverted thing to do).

Now Sarah brings up the Meyers-Briggs test, a piece of pseudoscientic bollocks. Sarah is INFJ—introversion, intuition, feeling, judging. Weird flex, but okay.

Introverts will patiently seek out complex UX patterns if it aligns with their levels of comfort. These are people who would rather do anything rather than speak to someone on the phone. An introvert figured out that if you sat on the Virgin Atlantic homepage long enough, a live chat will pop up after twenty minutes.

Apple is great for introverts. They don’t bury their chat options (unlike Amazon). Remember, introverts are a third of the population.

Users will begin to value those applications and services that bother them the least, respect their privacy, and allow them a certain level of control.

Let’s talk about designing compassionate products.

What we’re asking of people in time-critical or exceptionally personal situations is for them to have the foresight to turn on incognito mode. Everyone has an urban legend horror story about cookies following them around the web. Cookies can seem like a smart marketing solution until context lets them down.

Sarah’s best friend got pregnant. She started excitedly clicking around the web looking for pregnancy-related products. She sadly lost the baby. Sarah explained to her how to use a cookie eraser. Her friend that she was joking. Sarah showed her how to clean her search history. But if you’ve liked and subscribed a bunch of things while you’re excited, it’s not that easy—when the worst happens—to think back on everything you did.

There’s an app that’s not in the US. It’s a menstrual cycle and fertility tracking app. It captures a lot of data. At the point when Sarah’s friend lost her baby, this change was caught by the app. The message she got was lacking in empathy. It was more like market research than a compassionate message. At a time when they should’ve been thinking of the mindset of their user, they were focused on getting data. No one caught this when the app was being designed.

The entire user experience of our websites and apps is going to rely on how empathetic we are.

We don’t always save things to reminisce; we save to give us the option to remember. We can currently favourite a photograph or flag as inapropriate. It would be nice to simply save something to a memory vault.

Bloom and Wild is a company in the UK. They send nice mailbox flowers. On March 5th last year, Sarah sent an email to the CEO of Bloom and Wild. She had just received a mailout about mother’s day after her mother passed away. Was their no way of opting out of receiving mother’s day emails without unsubscribing completely?

Well, yesterday they finally implemented it! Bloom and Wild have been overwhelmed by the positive response.

For those of us trying to make the web a better place, sometimes it can be as simple as reaching out to point out what companies could be doing better. And sometimes, just sometimes, they listen.

Also, read Design For Real Life by Eric Meyer and Sara Wachter-Boettcher.

As standard, we should be giving users end-to-end control over how they interact with us.

Sarah wants to talk about designing a personal UX journey. For one of her clients, Sarah dip-sampled hundreds of existing customers. There were gaps in the customer journey. They think that what was happening was the company was getting very aggressive after initial interaction—they were phoning customers. Sarah and her team started researching this. That made them unpopular with other parts of the company. Sarah gave her team Groucho Marx glasses whenever they had to go and ask people uncomfortable questions.

Sarah’s team went on a remarketing effort. They sent an email to people who were in the gap between booking an appointment and making a purchase. They asked the users what their preferences were for contacting them. The company didn’t think they were doing anything wrong but this research showed that 76% of people prefered to avoid phone calls.

They asked a few more questions. If you ask questions, there has to be value in it for the users. Sarah got the budget for some gift cards. They got feedback that many people don’t like taking calls, especially when they’re at work. The best: “I’m an intorvert. I hate calls. Sorry.”

The customer feedback was very, very clear. Even though this would take a lot of money to fix, it was crucial to fix it. Being agile was crucial.

Then they looked at a different (shorter) gap in the customer journey. It was clear that an online booking service was desirable. They made a product quickly that booked more appointments in ten days than had previously been booked in a month by sales agents.

They also made a live chat system. You see a very slow roll-out. At the beginning, it has all new customers. After a while, people return with more questions.

The mistake they made was having a tech-savvy team with multiple browser windows open. That’s not how the customer service people operate. They usually deal with people one on one. So they were happy to leave people waiting on live chat for twenty or twenty five minutes, and of course that was far too long. So when you’re adding in a new system like this, think about key performance indicators that you want to go along with it e.g. live chat must have a response within five minutes.

There’s also a long tail of conversion. Sometimes the sales cycle is very lengthy. They decided to give users the ability to select which product they wanted and switch options on and off. It was all about giving the power back to the user. This was a phenomenal change for the company. They were able to completely change the customer journey and reduce those big gaps. They went from a cycle of fourteen weeks to seven days. They did that by handing the power back to the user.

Sarah’s question for the audience is: What is stopping your user completing your cycle? This can be very difficult. You might have to do horrible things to validate a concept. It’s okay. We’re all perfectionists, but sometimes you have to use quick’n’dirty code to achieve your goal. If the end goal is we’re able to say “hey, this thing worked!” then we can go back and do it properly.

To recap:

  • Respect privacy and build in a personal level of UX adjustment into every product.
  • Outlier data can create superfans of your product.
  • Build the most empathetic experience that you can.

Designing for Trust in an Uncertain World by Margot Bloomstein

The second talk of the first day of An Event Apart Seattle is from Margot Bloomstein. She’ll be speaking about Designing for Trust in an Uncertain World. The talk description reads:

Mass media and our most cynical memes say we live in a post-fact era. So who can we trust—and how do our users invest their trust? Expert opinions are a thing of the past; we favor user reviews from “people like us” whether we’re planning a meal or prioritizing a newsfeed. But as our filter bubbles burst, consumers and citizens alike turn inward for the truth. By designing for empowerment, the smartest organizations meet them there.

We must empower our audiences to earn their trust—not the other way around—and our tactical choices in content and design can fuel empowerment. Margot will walk you through examples from retail, publishing, government, and other industries to detail what you can do to meet unprecedented problems in information consumption. Learn how voice, volume, and vulnerability can inform your design and content strategy to earn the trust of your users. We’ll ask the tough questions: How do brands develop rapport when audiences let emotion cloud logic? Can you design around cultural predisposition to improve public safety? And how do voice and vulnerability go beyond buzzwords and into broader corporate strategy? Learn how these questions can drive design choices in organizations of any size and industry—and discover how your choices can empower users and rebuild our very sense of trust itself.

I’m sitting in the audience, trying to write down the gist of what she’s saying…

She begins by thanking us for joining her to confront some big problems. About ten years ago, A List Apart was the first publication to publish a piece of hers. It had excellent editors—Carolyn, Erin, and so on. The web was a lot smaller ten years ago. Our problems are bigger now. Our responsibilities are bigger now. But our opportunities are bigger now too.

Margot takes us back to 1961. The Twilight Zone aired an episode called The Mirror. We’re in South America where a stealthy band are working to take over the government. The rebels confront the leader. He shares a secret with them. He shows them a mirror that reveals his enemies. The revolution is successful. The rebels assume power. The rebel leader starts to use the same oppressive techniques as his predecessor. One day he says in his magic mirror the same group of friends that he worked with to assume power. Now they’re working to depose him, according to the mirror. He rounds them up and has them killed. One day he sees himself in the mirror. He smashes the mirror with his gun. He is incredibly angry. A priest walking past the door hears a commotion. The priest hears a gunshot. Entering the room, he sees the rebel leader dead on the ground with the gun in his hand.

We look to see ourselves. We look to see the truth. We hope the images coincide.

When our users see themselves, and then see the world around them, the images don’t coincide.

Internal truths trump external facts.

We used to place trust in brands. Now we’ve knocked them off the pedestal, or they’ve knocked themselves off the pedestal. They’ve been shady. Creeping inconsistencies. Departments of government are exhorting people not to trust external sources. It’s gaslighting. The blowback of gaslighting is broad. It effects us. An insidious scepticism—of journalism, of politics, of brands. This is our problem now.

To regain the trust of our audiences, we must empower them.

Why now? Maybe some of this does fall on our recent history. We punish politicians for flip-flopping and yet now Rudy Giuliani and Donald Trump simply deny reality, completely contradicting their previous positions. The flip-flopping doesn’t matter. If you were a Trump supporter before, you continued to support him. No amount of information would cause you to change your mind.

Inconsistency erodes our ability to evaluate and trust. In some media circles, coached scepticism, false equivalency, and rampant air quotes all work to erode consensus. It offers us a cosy echo chamber. It’s comforting. It’s the journalism of affirmation. But our ability to evaluate information for ourselves suffers. Again, that’s gaslighting.

You can find media that bolsters your existing opinions. It’s a strange space that focuses more on hiding information, while claiming to be unbiased. It works to separate the listener, viewer, and reader from their own lived experiences. If you work in public services, this effects you.

Do we get comfortable in our faith, or confidentally test our beliefs through education?

Marketing relies on us re-evaluating our choices. Now we’ve turned away from the old arbiters of experts. We’ve moved from expertise to homophily—only listening to people like us. But people have recently become aware of their own filter bubbles. So people turn inward to narcissism. If you can’t trust anyone, you can only turn inward. But that’s when we see the effects of a poor information diet. We don’t know what objective journalism looks like any more. Our analytic skills are suffering as a result. Our ability to trust external sources of expertise suffers.

Inconsistency undermines trust—externally and internally. People turn inward and wonder if they can even trust their own perceptions any more. You might raise an eyebrow when a politician plays fast and loose with the truth, or a brand does something shady.

We look for consistency with our own perceptions. Does this fit with what I know? Does this make me feel good? Does this brand make me feel good about myself? It’s tied to identity. There’s a cycle of deliberation and validation. We’re validating against our own worldview. Referencing Jeffrey’s talk, Margot says that giving people time to slow down helps them evaluate and validate. But there’s a self-perpetuating cycle of belief and validation. Jamelle Bouie from Slate says:

We adopt facts based on our identities.

How we form our beliefs affects our reality more than what we already believe. Cultural predisposition is what give us our confirmation bias.

Say you’re skeptical of big pharma. You put the needs of your family above the advice of medical experts. You deny the efficacy of vaccination. The way to reach these people is not to meet them with anger and judgement. Instead, by working in the areas they already feel comfortable in—alternative medicine, say—we can reach them much more effictively. We need to meet a reluctant audience on their own terms. That empowers them. Empowerment reflects and rebuilds trust. If people are looking inward for information, we can meet them there.

Voice

The language a brand uses to express itself. You don’t want to alienate your audience. You need to bring your audience along with you. When a brand changes over time, it runs the risk of alienating its audience. But by using a consistent voice, and speaking with transparency, it empowers the audience.

A good example of this is Mailchimp. When Mailchimp first moved into the e-commerce space, they approached it from a point of humility. They wrote on the blog in a very personal vulnerable way, using plain language. The language didn’t ask more acclimation from their audience.

ClinicalTrials.gov does not have a cute monkey. Their legal disclaimer used to have reams of text. They took a step back to figure what they needed to provide in order to make the audience comfortable. They empowered their audience by writing clearly, avoiding the passive voice.

Volume

What is enough detail to allow a user to feel good about their choices? We used to think it was all about reducing information. For a lot of brands, that’s true. But America’s Test Kitchen is known for producing a lot of content. They’re known for it because their content focuses on empowering people. You’re getting enough content to do well. They try to engage people regardless of level of expertise. That’s the ultimate level of empathy—meeting people wherever they are. Success breeds confidence. That’s the ethos that underpins all their strategy.

Crutchfield Electronics also considers what the right amount of content is to allow people to succeed. By making sure that people feel good and confident about the content they’re receiving, Crutchfield Electronics are also making sure that people good and confident in their choices.

Gov.uk had to contend with where people were seeking information. The old version used to have information spread across multiple websites. People then looked elsewhere. Government Digital Services realised they were saying too much. They reduced the amount of content. Let government do what only government can do.

So how do you know when you have “enough” content? Whether you’re America’s Test Kitchen or Gov.uk. You have enough content when people feel empowered to move forward. Sometimes people need more content to think more. Sometimes people need less.

Vulnerability

How do we open up and support people in empowering themselves? Vulnerability can also mean letting people know how we’re doing, and how we’re going to change over time. That’s how we build a conversation with our audience.

Sometimes vulnerability can mean prototyping in public. Buzzfeed rolled out a newsletter by exposing their A/B testing in public. This wasn’t user-testing on the sidelines; it was front and centre. It was good material for their own blog.

When we ask people “what do you think?” we allow people to become evalangists of our products by making them an active part of the process. Mailchimp did this when they dogfooded their new e-commerce product. They used their own product and talked openly about it. There was a conversation between the company and the audience.

Cooks Illustrated will frequently revisit their old recommendations and acknowledge that things have changed. It’s admitting to a kind of falliability, but that’s not a form of weakness; it’s a form of strength.

If you use some of the recommendations on their site, Volkswagen ask “what are you looking for in a car?” rather than “what are you looking for in Volkswagen?” They’re building the confidence of their audience. That builds trust.

Buzzfeed also hosts opposing viewpoints. They have asides on articles called “Outside Your Bubble”. They bring in other voices so their audiences can have a more informed opinion.

A consistent and accessible voice, appropriate volume for the context, and humanising vulnerability together empowers users.

Margot says all that in the face of the question: do we live in a post-fact era? To which she says: when was the fact era?

Cynicism is a form of cowardice. It’s not a fruitful position. It doesn’t move us forward as designers, and it certainly doesn’t move us forward as a society. Cynics look at the world and say “it’s worse.” Designers look at the world and say “it could be better.”

Design won’t save the world—but it may make it more worth saving. Are we uniquely positioned to fix this problem? No. But that doesn’t free us from working hard to do our part.

Margot thinks we can design our way out of cynicism. And we need to. For ourselves, for our clients, and for our very society.

Slow Design for an Anxious World by Jeffrey Zeldman

I’m at An Event Apart in Seattle, ready for three days of excellence. Setting the scene with the first talk of the event is the one and only Jeffrey Zeldman. His talk is called Slow Design for an Anxious World:

Most web pages are too fast or too slow. Last year, Zeldman showed us how to create design that works faster for customers in a hurry to get things done. This year he’ll show how to create designs that deliberately slow your visitors down, helping them understand more and make better decisions.

Learn to make layouts that coax the visitor to sit back, relax, and actually absorb the content your team works so hard to create. Improve UX significantly without spending a lot or chasing the tail lights of the latest whiz-bang tech. Whether you build interactive experiences or craft editorial pages, you’ll learn how to ease your customers into the experience and build the kind of engagement you thought the web had lost forever.

I’m going to attempt to jot down the gist of it as it happens…

Jeffrey begins by saying that he’s going to slooooowly ease us into the day. Slow isn’t something that our industry prizes. Things change fast on the internet. “You’re using last year’s framework!?” Ours is a newly-emerging set of practices.

Slow is negative in our culture too. We don’t like slow movies, or slow books. But somethings are better slow. Wine that takes time to make is better than wine that you produce in a prison toilet in five days. Slow-brewed coffee is well-brewed coffee. Slow dancing is nice. A slow courtship is nice. And reading slowly is something enjoyable. Sometimes you need to scan information quickly, but when we really immerse ourselves in a favourite book, we really comprehend better. Hold that thought. We’re going to come to books.

Fast is generally what we’re designing for. It’s the best kind of design for customer service designs—for people who want to accomplish something and then get on with their lives. Fast is good for customer service designs. Last year Jeffrey gave a talk last year called Beyond Engagement where he said that service-oriented content must be designed for speed of relevancy. Speed of loading is important, and so is speed of relevancy—how quickly can you give people the right content.

But slow is best for comprehension. Like Mr. Rogers. When things are a little bit slower, it’s kind of easier to understand. When you’re designing for readers, s l o w i t d o w n.

How do we slow down readers? That’s what this talk is about (he told us it would be slow—he only just got to what the point of this talk is).

Let’s start with a form factor. The book. A book is a hack where the author’s brain is transmitting a signal to the reader’s brain, and the designer of the book is making that possible. Readability is more than legibility. Readability transcends legibility, enticing people to slow down and read.

This is about absorption, not conversion. We have the luxury of doing something different here. It’s a challenge.

Remember Readability? It was designed by Arc90. They mostly made software applications for arcane enterprise systems, and that stuff tends not to be public. It’s hard for an agency to get new clients when it can’t show what it does. So they decided to make some stuff that’s just for the public. Arc90 Labs was spun up to make free software for everyone.

Readability was like Instapaper. Instapaper was made by Marco Arment so that he could articles when he was commuting on the subway. Readability aimed to do that, but to also make the content like beautiful. It’s kind of like how reader mode in Safari strips away superfluous content and formats what’s left into something more readable. Safari’s reader mode was not invented by Apple. It was based on the code from Readability. The mercury reader plug-in for Chrome also uses Readability’s code. Jeffrey went around pointing out to companies that the very existence of things like Readability was a warning—we’re making experiences so bad that people are using software to work around them. What we can do so that people don’t have to use these tools?

Craig Mod wrote an article for A List Apart called A Simpler Page back in 2011. With tablets and phones, there isn’t one canonical presentation of content online any more. Our content is sort of amorphous. Craig talked about books and newspapers on tablets. He talked about bed, knee, and breakfast distances from the body to the content.

  1. Bed (close to face): reading a novel on your stomach, lying in bed with the iPad propped up on a pillow.
  2. Knee (medium distance from face): sitting on the couch, iPad on your knee, catching up on Instapaper.
  3. Breakfast (far from face): propped up at a comfortable angle, behind your breakfast coffee and bagel, allowing hands-free news reading.

There’s some correlation between distance and relaxation. That knee position is crucial. That’s when the reader contemplates with pleasure and concentration. They’re giving themselves the luxury of contemplation. It’s a very different feeling to getting up and going over to a computer.

So Jeffrey redesigned his own site with big, big type, and just one central column of text. He stripped away the kind of stuff that Readability and Instapaper would strip away. He gave people a reader layout. You would have to sit back to read the content. He knew he succeeded because people started complaining: “Your type is huge!” “I have to lean back just to read it!” Then he redesigned A List Apart with Mike Pick. This was subtler.

Medium came along with the same focus: big type in a single column. Then the New York Times did it, when they changed their business model to a subscription paywall. They could remove quite a bit of the superfluous content. Then the Washington Post did it, more on their tablet design than their website. The New Yorker—a very old-school magazine—also went down this route, and they’re slow to change. Big type. White space. Bold art direction. Pro Publica is a wonderful non-profit newspaper that also went this route. They stepped it up by adding one more element: art direction on big pieces.

How do these sites achieve their effect of slowing you down and calming you?

Big type. We spend a lot of our time hunched forward. Big type forces you to sit back. It’s like that first moment in a yoga workshop where you’ve got to just relax before doing anything. With big type, you can sit back, take a breathe, and relax.

Hierarchy. This is classic graphic design. Clear relationships.

Minimalism. Not like Talking Heads minimalism, but the kind of minimalism where you remove every extraneous detail. Like what Mies van der Rohe did for architecture, where just the proportions—the minimalism—is the beauty. Or like what Hemingway did with writing—scratch out everything but the nouns and verbs. Kill your darlings.

Art direction. When you have a fancy story, give it some fancy art direction. Pro Publica understand that people won’t get confused about what site they’re on—they’ll understand that this particular story is special.

Whitespace. Mark Boulton wrote an article about whitespace in A List Apart. He talked about two kinds of whitespace: macro and micro. Macro is what we usually think about when we talk about whitespace. Whitespace conveys feelings of extreme luxury, and luxury brands know this. Whitespace makes us feels special. Macro whitespace can be snotty. But there’s also micro whitespace. That’s the space between lines of type, and the space inside letterforms. There’s more openness and air, even if the macro whitespace hasn’t changed.

Jeffrey has put a bunch of these things together into an example.

To recap, there are five points:

  1. Big type
  2. Hierarchy
  3. Minimalism
  4. Art direction
  5. Whitespace

There are two more things that Jeffrey wants to mention before his done. If you want people to pay attention to your design, it must be branded and it must be authoritative.

Branded. When all sites look the same, all content appears equal. Jeffrey calls this the Facebook effect. Whether it’s a noble-prize-winning author, or your uncle ranting, everthing gets the same treatment on Facebook. If you’re taking the time to post content to the web, take the time to let people know who’s talking.

Authoritative. When something looks authoritative, it cues the reader to your authenticity and integrity. Notice how every Oscar-worthy movie uses Trajan on its poster. That’s a typeface based on a Roman column. Strong, indelible letter forms carved in stone. We have absorbed those letterforms into our collective unconcious. Hollywood tap into this by using Trajan for movie titles.

Jeffrey wrote an article called To Save Real News about some of these ideas.

And with that, Jeffrey thanks us and finishes up.

Thursday, February 28th, 2019

Patterns Day 2: June 28th, 2019

Surprise! Patterns Day is back!

The first Patterns Day was in the Summer of 2017, and it was a glorious—a single day devoted to all things design system-y: pattern libraries, style guides, maintainability, reusability. It was a lot of fun, so let’s do it again!

Patterns Day 2 will take place on Friday, June 28th, in the beautiful Duke of York’s cinema in Brighton. If you went to the first Patterns Day, then you’ll know how luxuriously comfy it is in there.

Tickets are £175+VAT. The format will likely be the same as before: an action-packed day of eight talks, each 30 minutes long.

I’ve got an amazing line-up of speakers, but instead of telling you the whole line-up straightaway, I’m going to tease a little bit, and announce more speakers over the next few weeks and months. For now, here are the first three speakers, to give you an idea of the quality you can expect:

  • All the way from the US of A, it’s Una Kravets, who needs no introduction.
  • From the Government Digital Service, we’ve got Amy Hupe—she’ll have plenty to share about the GOV.UK design system.
  • And we’ve got Yaili, now a senior designer at Microsoft, where she works on the Azure DevOps design system.

Patterns Day will have something for everyone. We’ll be covering design, development, content strategy, product management, and accessibility. So you might want to make this a one-day outing for your whole team.

If you want to get a feel for what the day will be like, you can watch the videos of last year’s talks

Tickets for last year’s Patterns Day went fairly fast—the Duke of York’s doesn’t have a huge capacity—so don’t dilly-dally too long before grabbing your ticket!

Monday, February 25th, 2019

Accessibility on The Session

I spent some time this weekend working on an accessibility issue over on The Session. Someone using VoiceOver on iOS was having a hard time with some multi-step forms.

These forms have been enhanced with some Ajax to add some motion design: instead of refreshing the whole page, the next form is grabbed from the server while the previous one swooshes off the screen.

You can see similar functionality—without the animation—wherever there’s pagination on the site.

The pagination is using Ajax to enhance regular prev/next links—here’s the code.

The multi-step forms are using Ajax to enhance regular form submissions—here’s the code for that.

Both of those are using a wrapper I wrote for XMLHttpRequest.

That wrapper also adds some ARIA attributes. The region of the page that will be updated gets an aria-live value of polite. Then, whenever new content is being injected, the same region gets an aria-busy value of true. Once the update is done, the aria-busy value gets changed back to false.

That all seems to work fine, but I was also giving the same region of the page an aria-atomic value of true. My thinking was that, because the whole region was going to be updated with new content from the server, it was safe to treat it as one self-contained unit. But it looks like this is what was causing the problem, especially when I was also adding and removing class values on the region in order to trigger animations. VoiceOver seemed to be getting a bit confused and overly verbose.

I’ve removed the aria-atomic attribute now. True to its name, I’m guessing it’s better suited to small areas of a document rather than big chunks. (If anyone has a good primer on when to use and when to avoid aria-atomic, I’m all ears).

I was glad I was able to find a fix—hopefully one that doesn’t negatively impact the experience in other screen readers. As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.

It also led to a nice discussion with some of the screen-reader users on The Session.

For me, all of this really highlights the beauty of the web, when everyone is able to contribute to a community like The Session, regardless of what kind of software they may be using. In the tunes section, that’s really helped by the use of ABC notation, as I wrote five years ago:

One of those screen-reader users got in touch with me shortly after joining to ask me to explain what ABC was all about. I pointed them at some explanatory links. Once the format “clicked” with them, they got quite enthused. They pointed out that if the sheet music were only available as an image, it would mean very little to them. But by providing the ABC notation alongside the sheet music, they could read the music note-for-note.

That’s when it struck me that ABC notation is effectively alt text for sheet music!

Then, for those of use who can read sheet music, the text of the ABC notation is automatically turned into an SVG image using the brilliant abcjs. It’s like an enhancement that’s applied, I dunno, what’s the word …progressively.