Tags: event

177

sparkline

Live-blogging An Event Apart Seattle

I tried do some live-blogging at An Event Apart Seattle. I surprised myself by managing to do all six talks on the first day. I even managed one or two after that, but that was the limit of my stamina. Torre, on the other hand, managed to live-blog every single talk—amazing!

Some of the talks don’t necessarily lend themselves to note-taking—ya kinda had to be there. But some of the the live-blogging I did ended up being surprisingly coherent.

Anyway, I figured it would be good to recap all the ones I managed to do here in one handy list.

  1. Beyond Engagement: the Content Performance Quotient by Jeffrey Zeldman. I think I managed to document the essence of what Jeffrey was getting at: for many sites, engagement isn’t the right metric to measure—the idea of a Content Performance Quotient is one alternative.
  2. Digital Marketing Strategies for the Busy “Web Master” by Sarah Parmenter. The structure of Sarah’s talk lent itself well to live-blogging, but I strongly disagreed with one or two of her suggestions (like encouraging people to install the disgusting abomination that is Facebook Pixel).
  3. Scenario-Driven Design Systems by Yesenia Perez-Cruz. This one was hard to live-blog because it was so packed with so many priceless knowledge bombs—an absolutely brilliant presentation, right up my alley!
  4. Graduating to Grid by Rachel Andrew. The afternoon sessions, with their emphasis on CSS, were definitely tricky to capture. I didn’t even try to catch most of the code, but I think I managed to get down most of Rachel’s points about learning new CSS.
  5. Fit For Purpose: Making Sense of the New CSS by Eric Meyer. There was a fair bit of code in this one, and lots of gasp-inducing demos too, so my account probably doesn’t do it justice.
  6. Everything You Know About Web Design Just Changed by Jen Simmons. There was no way I could document the demos, but I think I managed to convey the excitement in Jen’s talk.
  7. Navigating Team Friction by Lara Hogan. I only managed to do two talks on the second day, but I think they came out the best. Lara’s talk was packed full with great advice, but it was so clearly structured that I think I managed to get most of the main points down.
  8. Designing Progressive Web Apps by Jason Grigsby. I had a vested interest in the topic of Jason’s talk so I was scribing like crazy. Apart from a few missing diagrams, I think my notes managed to convey most of Jason’s message.

Of course the one talk I definitely couldn’t live-blog was my own. I’ve documented lists of links relating to the subject matter of my talk, but if you weren’t at An Event Apart Seattle, then the only other chance to see the talk is at An Event Apart Boston in June. That’s the only other time I’m giving it.

I thoroughly enjoyed giving the talk in Seattle, particularly when I treated the audience to a scoop: I announced my new book, Going Offline, during the talk (I had been scheming with Katel at A Book Apart and we co-ordinated the timing to a tee).

Understandable excitement

An Event Apart Seattle just wrapped. It was a three-day special edition and it was really rather good. Lots of the speakers (myself included) were unveiling brand new talks, so there was a real frisson of excitement.

It was interesting to see repeating, overlapping themes. From a purely technical perspective, three technologies that were front and centre were:

  • CSS grid,
  • variable fonts, and
  • service workers.

From listening to other attendees, the overwhelming message received was “These technologies are here—they’ve arrived.” Now, depending on your mindset, that understanding can be expressed as “Oh shit! These technologies are here!” or “Yay! Finally! These technologies are here!”

My reaction is very firmly the latter. That in itself is an interesting data-point, because (as discussed in my talk) my reaction towards new technological advances isn’t always one of excitement—quite often it’s one of apprehension, even fear.

I’ve been trying to self-analyse to figure out which kinds of technologies trigger which kind of reaction. I don’t have any firm answers yet, but it’s interesting to note that the three technologies mentioned above (CSS grid, variable fonts, and service workers) are all additions to the core languages of the web—the materials we use to build the web. Frameworks, libraries, build tools, and other such technologies are more like tools than materials. I tend to get less excited about advances in those areas. Sometimes advances in those areas not only fail to trigger excitement, they make me feel overwhelmed and worried about falling behind.

Since figuring out this split between materials and tools, it has helped me come to terms with my gut emotional reaction to the latest technological advances on the web. I think it’s okay that I don’t get excited about everything. And given the choice, I think maybe it’s healthier to be more excited about advances in the materials—HTML, CSS, and JavaScript APIs—than advances in tooling …although, it is, of course, perfectly possible to get equally excited about both (that’s just not something I seem to be able to do).

Another split I’ve noticed is between technologies that directly benefit users, and technologies that directly benefit developers. I think there was a bit of a meta-thread running through the talks at An Event Apart about CSS grid, variable fonts, and service workers: all of those advances allow us developers to accomplish more with less. They’re good for performance, in other words. I get much more nervous about CSS frameworks and JavaScript libraries that allow us to accomplish more, but require the user to download the framework or library first. It feels different when something is baked into browsers—support for CSS features, or JavaScript APIs. Then it feels like much more of a win-win situation for users and developers. If anything, the onus is on developers to take the time and do the work and get to grips with these browser-native technologies. I’m okay with that.

Anyway, all of this helps me understand my feelings at the end of An Event Apart Seattle. I’m fired up and eager to make something with CSS grid, variable fonts, and—of course—service workers.

Navigating Team Friction by Lara Hogan

It’s day two of An Event Apart Seattle (Special Edition). Lara is here to tell us about Navigating Team Friction. These are my notes…

Lara started as a developer, and then moved into management. Now she consults with other organisations. So she’s worked with teams of all sizes, and her conclusion is that humans are amazing. She has seen teams bring a site down; she has seen teams ship amazing features; she has seen teams fall apart because they had to move desks. But it’s magical that people can come together and build something.

Bruce Tuckman carried out research into the theory of group dynamics. He published stages of group development. The four common stages are:

  1. Forming. The group is coming together. There is excitement.
  2. Storming. This is when we start to see some friction. This is necessary.
  3. Norming. Things start to iron themselves out.
  4. Performing. Now you’re in the flow state and you’re shipping.

So if your team is storming (experiencing friction), that’s absolutely normal. It might be because of disagreement about processes. But you need to move past the friction. Team friction impacts your co-workers, company, and users.

An example. Two engineers passively-aggressively commenting each other’s code reviews; they feign surprise at the other’s technology choices; one rewrites the others code; one ships to production with code review; a senior team member or manager has to step in. But it costs a surprising amount of time and energy before a manager even notices to step in.

Brains

The Hulk gets angry. This is human. We transform into different versions of ourselves when we are overcome by our emotions.

Lara has learned a lot about management by reading about how our brains work. We have a rational part of our brain, the pre-frontal cortex. It’s very different to our amygdala, a much more primal part of our brain. It categorises input into either threat or reward. If a threat is dangerous enough, the amygdala takes over. The pre-frontal cortex is too slow to handle dangerous situations. So when you have a Hulk moment, that was probably an amygdala hijack.

We have six core needs that are open to being threatened (leading to an amygdala hijacking):

  1. Belonging. Community, connection; the need to belong to a tribe. From an evolutionary perspective, this makes sense—we are social animals.
  2. Improvement/Progress. Progress towards purpose, improving the lives of others. We need to feel that we do matters, and that we are learning.
  3. Choice. Flexibility, autonomy, decision-making. The power to make decisions over your own work.
  4. Equality/Fairness. Access to resources and information; equal reciprocity. We have an inherent desire for fairness.
  5. Predictability. Resources, time, direction future challenges. We don’t like too many surprises …but we don’t like too much routine either. We want a balance.
  6. Significance. Status, visibility, recognition. We want to feel important. Being assigned to a project you think is useless feels awful.

Those core needs are B.I.C.E.P.S. Thinking back to your own Hulk moment, which of those needs was threatened?

We value those needs differently. Knowing your core needs is valuable.

Desk Moves

Lara has seen the largest displays of human emotion during something as small as moving desks. When you’re asked to move your desk, your core need of “Belonging” may be threatened. Or it may be a surprise that disrupts the core need of “Improvement/Progress.” If a desk move is dictated to you, it feels like “Choice” is threatened. The move may feel like it favours some people over others, threatening “Equality/Fairness.” The “Predictability” core need may be threatened by an unexpected desk move. If the desk move feels like a demotion, your core need of “Significance” will be threatened.

We are not mind readers, so we can’t see when someone’s amygdala takes over. But we can look out for the signs. Forms of resistance can be interpreted as data. The most common responses when a threat is detected are:

  1. Doubt. People double-down on the status quo; they question the decision.
  2. Avoidance. Avoiding the problem; too busy to help with the situation.
  3. Fighting. People create arguments against the decision. They’ll use any logic they can. Or they simply refuse.
  4. Bonding. Finding someone else who is also threatened and grouping together.
  5. Escape-route. Avoiding the threat by leaving the company.

All of these signals are data. Rather than getting frustrated with these behaviours, use them as valuable data. Try not to feel threatened yourself by any of these behaviours.

Open questions are powerful tool in your toolbox. Asked from a place of genuine honesty and curiosity, open questions help people feel less threatened. Closed questions are questions that can be answered with “yes” or “no”. When you spot resistance, get some one-on-one time and try to ask open questions:

  • What do you think folks are liking or disliking about this so far?
  • I wanted to get your take on X. What might go wrong? What do you think might be good about it?
  • What feels most upsetting about this?

You can use open questions like these to map resistance to threatened core needs. Then you can address those core needs.

This is a good time to loop in your manager. It can be very helpful to bounce your data off someone else and get their help. De-escalating resistance is a team effort.

Communication ✨

Listen with compassion, kindness, and awareness.

  • Reflect on the dynamics in the room. Maybe somebody thinks a topic is very important to them. Be aware of your medium. Your body language; your tone of voice; being efficient with words could be interpreted as a threat. Consider the room’s power dynamics. Be aware of how influential your words could be. Is this person in a position to take the action I’m suggesting?
  • Elevate the conversation. Meet transparency with responsibility.
  • Assume best intentions. Remember the prime directive. Practice empathy. Ask yourself what else is going on for this person in their life.
  • Listen to learn. Stay genuinely curious. This is really hard. Remember your goal is to understand, not make judgement. Prepare to be surprised when you walk into a room. Operate under the assumption that you don’t have the whole story. Be willing to have your mind changed …no, be excited to have your mind changed!

This tips are part of mindful communication. amy.tech has some great advice for mindful communication in code reviews.

Feedback

Mindful communication won’t solve all your problems. There are times when you’ll have to give actionable feedback. The problem is that humans are bad at giving feedback, and we’re really bad at receiving feedback. We actively avoid feedback. Sometimes we try to give constructive feedback in a compliment sandwich—don’t do that.

We can get better at giving and receiving feedback.

Ever had someone say, “Hey, you’re doing a great job!” It feels good for a few minutes, but what we crave is feedback that addresses our core needs.

GeneralSpecific and Actionable
Positive Feedback
Negative Feedback

The feedback equation starts with an observation (“You’re emails are often short”)—it’s not how you feel about the behaviour. Next, describe the impact of the behaviour (“The terseness of your emails makes me confused”). Then pose a question or request (“Can you explain why you write your emails that way?”).

observation + impact + question/request

Ask people about their preferred feedback medium. Some people prefer to receive feedback right away. Others prefer to digest it. Ask people if it’s a good time to give them feedback. Pro tip: when you give feedback, ask people how they’d like to receive feedback in the future.

Prepare your brain to receive feedback. It takes six seconds for your amygdala to chill out. Take six seconds before responding. If you can’t de-escalate your amygdala, ask the person giving feedback to come back later.

Think about one piece of feedback you’ll ask for back at work. Write it down. When your back at work, ask about it.

You’ll start to notice when your amygdala or pre-frontal cortex is taking over.

Prevention

Talking one-on-one is the best way to avoid team friction.

Retrospectives are a great way of normalising of talking about Hard Things and team friction.

It can be helpful to have a living document that states team processes and expectations (how code reviews are done; how much time is expected for mentoring). Having it written down makes it a North star you can reference.

Mapping out roles and responsibilities is helpful. There will be overlaps in that Venn diagram. The edges will be fuzzy.

What if you disagree with what management says? The absence of trust is at the centre of most friction.

DisgreeAgree
CommitMature and TransparentEasiest
Don’t CommitAcceptable but ToughBad Things

Practice finding other ways to address B.I.C.E.P.S. You might not to be able to fix the problem directly—the desk move still has to happen.

But no matter how empathic or mindful you are, sometimes it will be necessary to bring in leadership or HR. Loop them in. Restate the observation + impact. State what’s been tried, and what you think could help now. Throughout this process, take care of yourself.

Remember, storming is natural. You are now well-equipped to weather that storm.

See also:

Fit For Purpose: Making Sense of the New CSS by Eric Meyer

Time for even more CSS goodness at An Event Apart Seattle (Special Edition). Eric’s talk is called Fit For Purpose: Making Sense of the New CSS. Here are my notes…

Eric isn’t going to dive quite as deeply as Rachel, but he is going to share some patterns he has used.

Feature queries

First up: feature queries! Or @supports, if you prefer. You can ask a browser “do you support this feature?” If you haven’t used feature queries, you might be wondering why you have to say the property and the value. Well, think about it. If you asked a browser “do you support display?”, it’s not very useful. So you have to say “do you support display: grid?”

Here’s a nice pattern from Lea Verou for detecting support for custom properties:

@supports (--css: variables)

Here’s a gotcha:

@supports (clip-path: polygon())

That won’t work because polygon() is invalid. This will work:

@supports (clip-path: polygon(0 0))

So to use feature queries, you need to understand valid values for properties.

You can chain feature queries together, or just pick the least-supported thing you’re testing for and test just for that.

Here’s a pattern Eric used when he only wanted to make text sideways, but only if grid is supported:

@supports (display: grid) {
    ...
    @supports (writing-mode: sideways-lr) {
        ...
    }
}

That’s functionally equivalent to:

@supports (display: grid) {
    ...
}
@supports (display:grid) and (writing-mode: sideways-lr) {
    ...
}

Choose whichever pattern makes sense to you. More to the point, choose the pattern that makes sense to your future self when you revisit your code.

Feature queries need to work together with media queries. Sometimes there are effects that you only want to apply on larger viewports. Do you put your feature queries inside your media queries? Or do you put your media queries inside your feature queries?

  • MOSS: Media Outside Support Statements
  • MISO: Media Inside Supports Object

Use MOSS when you have more media switches than support blocks. Use MISO when you only have a few breakpoints but lots of feature queries.

That’s one idea that Eric has. It’ll be interesting to see how this develops.

And remember, CSS is still CSS. Sometimes you don’t need a feature query at all. You could just use hanging-punctuation without testing for it. Browsers that don’t understand it will just ignore it. CSS has implicit feature queries built in. You don’t have to put your grid layout in a feature query, but you might want to put grid-specific margins and widths inside a feature query for display: grid.

Feature queries really help us get from now to the future.

Flexbox

Let’s move on to flexbox. Flexbox is great for things in a line.

On the An Event Apart site, the profile pictures have social media icons lined up at the bottom. Sometimes there are just a few. Sometimes there are a lot more. This is using flexbox. Why? Because it’s cool. Also, because it’s flexbox, you can create rules about how the icons should behave if one of the icons is taller than the others. (It’s gotten to the point that Eric has forgotten that vertically-centring things in CSS is supposed to be hard. The jokes aren’t funny any more.) Also, what if there’s no photo? Using flexbox, you can say “if there’s no photo, change the direction of the icons to be vertical.” Once again, it’s all about writing less CSS.

Also, note that the profile picture is being floated. That’s the right tool for the job. It feels almost transgressive to use float for exactly the purpose for which it was intended.

On the An Event Apart site, the header is currently using absolute positioning to pull the navigation from the bottom of the page source to the top of the viewport. But now you get overlap at some screen sizes. Flexbox would make it much more robust. (Eric uses the flexbox inspector in Firefox Nightly to demonstrate.)

With flexbox, what works horizontally works vertically. Flexbox allows you to align things, as long as you’re aligning in one direction. Flexbox makes things springy. Everything’s related and pushing against each other in a way that makes sense for this medium. It’s intuitive, even though it takes a bit of getting used to …because we’ve picked up some bad habits. To quote Yoda, “You must unlearn what you have learned.” A lot of the barrier is getting over what we’ve internalised. Eric envies the people starting out now. They get to start fresh. It’s like when people who never had to table layouts see code from that time period: it (quite rightly) doesn’t make any sense. That’s what it’s going to be like when people starting out today see the float-based layouts from Bootstrap and the like.

Grid

That’s going to happen with grid too. We must unlearn what we have learned from twenty years of floats and positioning. What makes it worth is:

  1. Flexbox and grid are pretty easy to get used to, and
  2. It’s amazing what you can do!

Eric quotes from an article called How We adopted CSS Grid at Scale:

…we agreed to use CSS Grid at the layout level and Flexbox at the component level (arranging child items of components). Although there’s some overlap and in some cases both could be used interchangeably, abiding by this rule helped us avoid any confusion in gray areas.

Don’t be afraid to set these kind of arbitrary limits that aren’t technological, but are necessary for the team to work well together.

Eric hacked his Wordpress admin interface to use grid instead of floats for an activity component (a list of dates and titles). He initially turned each list item into a separate grid. The overall list didn’t look right. What Eric really needed was a subgrid capability, so that the mini grids (the list items) would relate to one another within the larger grid (the list). But subgrid doesn’t exist yet.

In this case, there’s a way to fake it using display: contents. Eric made the list a grid and used display: contents on the list items. It’s as though you’re saying that the contents of the li are really the contents of the ul. That works in this particular case.

The feature queries for that looked like:

@supports (display: grid) {
    ...
    @supports (display: contents) {
        ...
    }
}

Eric is also using the grid “ASCII art” (named areas) technique on his personal site. This works independent of source order. For that reason, make sure your source order makes sense.

Using media queries, Eric defines entirely different layouts simply by using different ASCII art. He’s switching templates.

For a proposed redesign of the An Event Apart site, Eric used CSS grid as a prototyping tool. He took a PDF, sliced it up, exported JPGs, and then used grid to lay out those images in a flexible grid. Rapid prototyping! The Firefox grid inspector really helps here. In less than an hour, he had a working layout. He could test whether the layout was sensible and robust. Then he swapped out the sliced images for real content. That took maybe another hour (mostly because it was faster to re-type the text than try to copy and paste from a PDF). CSS makes it that damn easy now!

So even if you’re not going to put things like grid into production, they can still be enormously useful as design tools (and you’re getting to grips with this new stuff).

See also:

Scenario-Driven Design Systems by Yesenia Perez-Cruz

I’m at An Event Apart Seattle (Special Edition) taking notes during the talks. Here are my notes from Yesenia’s presentation…

In the last few years, we’ve seen a lot of change in web design as we have to adapt to so many viewports and platforms. We’ve gravitated towards design systems to manage this. Many people have written about the benefits of design systems, like AirBnB.

But how do you define a design system? You could say it’s a collection of reususable components.

Donella Meadows wrote Thinking in Systems. She said:

A system is an interconnected group of elements coherently organized in a way that achieves something.

A good design system inspires people to work with it. A bad system gets bloated and unusable. Yesenia has seen systems fail when there’s too much focus on the elements, and not enough focus on how they come together. Yesenia has learned that we should start our design systems, not with components, or modules, or legos, but with user scenarios.

Yesenia works at Vox Media. They have eight editorial networks. Two and a half years ago, they started a project to move all of their products to one codebase and one design system. Maintaining and iterating on their websites was getting too cumbersome. They wanted to shift away from maintaining discrete brands to creating a cohesive system. They also wanted to help their editorial teams tell stories faster and better.

It was hard. Each brand has its own visual identity, editorial missions, and content needs. So even though they wanted eight brands to use one design system, there needed to be enough flexibility to allow for unique needs.

There were some early assumptions that didn’t work. There was a hunch that they could take smaller modular components to address inconsistencies in design: layout, colour, and typography. They thought a theming system would work well. They started with layout modules, like three different homepage hero elements, or four different story blocks. They thought they could layer colour and typography over these modules. It didn’t work. They weren’t reflecting critical differences in content, tone, and audience. For example, Curbed and Recode are very different, but the initial design system didn’t reflect those difference.

That brings us back to Donella Meadows:

A system is an interconnected group of elements coherently organized in a way that achieves something.

They weren’t thinking about that last part.

They learned that they couldn’t start with just the individual components or patterns. That’s because they don’t exist in a vacuum. As Alla says:

Start with language, not systems.

They started again, this time thinking about people.

  • What’s the audience goal?
  • Is there a shared audience goal across all brands or are there differences?
  • What’s the editorial workflow?
  • What range of content should this support?

This led to a much better process for creating a design system.

Start with a fast, unified platform. It should load quickly and work across all devices. All patterns should solve a specific problem. But that doesn’t mean creating a one-size-fits-all solution. A design system doesn’t have to stifle creativity …as long as the variants solve a real problem. That means no hypothetical situations.

Identify scenarios. Brad uses a UI inventory for this. Alla talks about a “purpose-directed inventory”. Map core modules to user journeys to see how patterns fit together in the bigger picture. You start to see families of patterns joined together by a shared purpose. Scenarios can help at every level.

The Salesforce design system starts by saying “Know your use-case.” They have examples of different patterns and where to use them. Thinking in user-flows like this matches the way that designers are already thinking.

Shopify’s Polaris system also puts users and user-flows at the centre: the purpose of each pattern is spelled out.

The 18F Design System doesn’t just provide a type system; it provides an explanation of when and where to use which type system.

At Vox, “features” are in-depth pieces. Before having a unified system, each feature looked very custom and were hard to update. They need to unify 18 different systems into one. They started by identifying core workflows. Audience goals were consistent (consume content, find new content), but editorial goals were quite different.

They ended up with quite a few variations of patterns (like page headers, for example), but only if there was a proven content need—no hypothetical situations.

Brand expression for features is all about the details. They started with 18 very different feature templates and ended up with one robust template that works across device types but still allowed for expression.

The “reviews” pieces had a scorecard pattern. Initially there was one unified pattern that they thought would be flexible enough to cover different scenarios. But these scorecards were for very different things: games; restaurants, etc. So people’s needs were very different. In the end, instead of having one scorecard pattern, they created three. Each one highlighted different content according to the user needs.

Homepages were the most challenging to unify. Each one was very distinct. Identifying core workflows took a lot of work.

What’s the value of the homepage? Who is the audience? What are they looking for?

They talked to their users and distilled their findings down into three user goals for homepages:

  • What’s new?
  • What’s important?
  • What’s helpful?

Those needs then translated into patterns. The story feed is there to answer the question “What’s new?”

When it came to variations on the home page, they needed to make sure their design system could stretch enough to allow for distinctly different needs. There’s a newspaper layout, an evergreen layout, a morning recap layout.

Again, Alla’s advice to focus on language was really helpful.

In the process of naming an element, you work out the function as a group and reach agreement.

The last piece was to have a scalable visual design system. Brands need to feel distinct and express an identity. They did this by having foundational elements (type scale, colour system, and white space) with theming applied to them. Thinking of type and colour as systems was key: they need to cascade.

But how do you tell good variation from bad variation? Variation is good if there’s a specific problem that you need a new pattern to solve—there’s a user scenario driving the variation. A bad variation is visual variation on components that do the same thing. Again, the initial design system provided room for “visual fluff and flair” but they were hypothetical. Those variations were removed.

The combination of a scenario-driven system combined with theming allowed for the right balance of consistency and customisation. Previously, the editorial team were hacking together the layouts they wanted, or developers were creating one-off templates. Both of those approaches were very time-consuming. Now, the reporters can focus on telling better stories faster. That was always the goal.

There’s still a lot of work to do. There’s always a pendulum swing between consistency and variation. Sometimes the design system goes too far in one direction or the other and needs to be recalibrated. They want to be able to add more detailed control over typography and spacing.

To wrap up:

  1. Successful design patterns don’t exist in a vacuum.
  2. Successful design systems solve specific problems.
  3. Successful design systems start with content and with people.

See also:

Digital Marketing Strategies for the Busy “Web Master” by Sarah Parmenter

It’s time for the second talk at An Event Apart Seattle (Special Edition). Sarah is talking about Digital Marketing Strategies for the Busy “Web Master”. These are the notes I made during the talk…

Recently Sarah was asked for her job title recently and she found it really stressful. She wasn’t comfortable with “Art Director”. And, even though it would probably be accurate, “Social Media Expert” feels icky. A more fitting title would be “Social Media Designer” but that’s not a thing. Ironically the term “Web Master” probably fits us better than it did back in the ’90s.

We have a bit of a defeatist attitude towards social media at the moment. It feels like that space has been claimed and so there’s no point in even starting. But we’re still in the first 10,000 days in the web. There is no social media, Gary Vee says. It’s a slang term for a collection of apps and websites that now dominate attention in our society.

Sarah likes the term “consensual hallucination” (that I borrowed from William Gibson to describe how we did web design for years). It applies to social media.

Once upon a time we had to sell the benefits of just being online to our clients. Our businesses now need to get into the mindset of “How can I help you?” and “What can I do for you?” We’re moving away from being sales-y and getting down to being more honest. We’re no longer saying “Look at what I’ve got.”

The average time spent on social media per day is 1 hour and 48 minutes. The average time spent on the kind of sites we make is 15 seconds.

Quarterly design reviews are a good idea—strategically designing your social media campaigns, reviewing successes and failures.

The first thing to mention is vanity metrics. You might need to sit down and have “the talk” with your boss or client about this. It’s no different to having hit counters on our sites back in the ’90s. While we’re chasing these vanity metrics, we’re not asking what people really want.

Google brought a roadshow to Sarah’s hometown of Leigh-on-Sea a while back. There was a really irritating know-it-all chap in the audience who put his hand up when other people were asking about how to get followers on social media. “You need to post three times a day to all social media channels”, he said. “And you need to use the follow-unfollow method with a bot.” Sarah’s eyes were rolling at this point. Don’t beg for likes and follows—you’re skewing your metrics.

“What about this Snapchat thing?” people asked. Irritating guy said, “Don’t worry about—young people use it to send rude pictures to each other.” Sarah was face-palming at this point.

But this event was a good wake-up call for Sarah. We need to check our personal bias. She had to check her own personal bias against LinkedIn.

What we can do is look for emerging social networks. Find social networks that aren’t yet clogged. People still fixate on displayed numbers instead of the actual connection with people.

We all have a tendency to think of the more successful social networks as something that is coming. Like Snapchat. But if you’re in this space, there’s no time to waste. Sarah has been interviewing for social media people and it’s fascinating to see how misunderstood Snapchat is. One big misconception is that it’s only for youngsters. The numbers might be lower than Facebook, but there’s a lot of video on there. Snapchat’s weakness is “the olds”—the non-intuitive interface makes it cool with young people who have time to invest in learning it; the learning curve keeps the parents out. Because the moment that mums and grandmums appear on a social network, the younger folks get out. And actually, when it comes to putting ads on Snapchat, the interface is very good.

What can we do in 2018?

  • By 2019, video will account for 80% of all consumer internet traffic. If you’re not planning for this, you’re missing out.
  • Move to HTTPS.
  • Make your website mobile ready.

Let’s ban the pop-up. Overlays. Permission dialogs. They’re all terrible. Google has started to penalise websites “where content is not easily accessible.”

Pop-ups are a lazy fix for a complex engagement problem (similar to carousels). It’s a terrible user experience. Do we thing this is adding value? Is this the best way to get someone’s email address? They’re like the chuggers of the web.

Here’s an interesting issue: there are discount codes available on the web. We inform people of this through pop-ups. Then it when it comes to check-out, they know that a discount is possible and so they Google for discount codes. You might as well have a page on your own website to list your own discount codes instead of people going elsewhere for them.

There’s a long tail of conversions, particularly with more expensive products and services. Virgin Holidays has a great example. For an expensive holiday, they ask for just a small deposit up front.

Let’s talk about some specific social networks.

Facebook

Facebook Pixel should be on your website, says Sarah. It collects data about your customers. (Needless to say, I disagree with this suggestion. Stand up for your customers’ dignity.)

Facebook is a very cheap way to publish video. Organic Facebook engagement is highest on posts with videos. (I think I threw up in my mouth a little just typing the words “organic”, “Facebook”, and “engagement” all in a row.) Facebook Live videos have six times the engagement of regular videos.

Sarah just said the word synergy. Twice. Unironically.

Facebook changed its algorithm last year. You’re going to see less posts from business and more posts from people.

Facebook advertising does work, but if it doesn’t work for you, the problem is probably down to your creative. (We’re using the word “creative” as a noun rather than an adjective, apparently.)

Google

With Ad Words, measure success by conversions rather than impressions. You might get thousands of eyeballs looking at a form, but only a handful filling it out. You need to know that second number to understand how much you’re really paying per customer.

trends.google.com is useful for finding keywords that aren’t yet saturated.

Google My Business is under-used, especially if you have a bricks’n’mortar store. It can make a massive difference to small businesses. It’s worth keeping it up to date and keeping it updated.

Instagram

700 million active users (double Twitter, and three times WhatsApp and Facebook Messenger). A lot of people are complaining about the changed algorithm. Social networks change their algorithms to deal with the “problems of success.” Instagram needs to help people with the discoverability of posts, says Sarah (again, I strongly disagree—it disempowers the user; I find Instagram’s we-know-best algorithm to be insultingly patronising).

Hashtags are the plumbing of the social media ecosystem. They’re not there for users to read. They’re for discoverability. Eleven hashtags are optimal.

Instagram Stories are a funny one. People are trying to use them to get around the algorithm, posting screenshots of photos to a story.

Archiving is a handy feature of Instagram. For time-sensitive content (like being closed during a snowstorm), it’s very useful to be able to archive those posts after the fact.

Planoly is a great website for managing your Instagram campaign. You can visually plan your feed. Only recently did Instagram start allowing scheduled posts (as long as they’re square, for some reason).

Influencer marketing is a thing. People trust peer recommendations more than advertising. You can buy micro-influencers quite cheaply.

(Side note: I think I’ve seen this episode of Black Mirror.)

How much do influencers cost? Not as much as you think. The average sponsored post rate is $180.

Case study

We need to have a “Design once. Use Everywhere.” mindset. Others we’ll go crazy. Away is doing this well. They sell a suitcase with built-in USB chargers.

The brands dominating social media are those with the most agile teams with exceptional storytelling skills. Away are very brave with their marketing. They’ve identified what their market has in common—travel—and they’re aiming at the level above that. They’re playing the long game, bringing the value back to the user. It’s all about “How can I help you?” rather than “Look at what I’ve gone.” Away’s creative is compelling, quirky, and fun. They work with influencers who are known to create beautiful imagery. Those influencers were given free suitcases. The cost of giving away those bags was much less than a traditional marketing campaign.

Their product is not front and centre in their campaigns. Travel is front and centre. They also collaborate with other brands. Their Google Ads are very striking. That also translates to physical advertising, like ads on airport security trays.

On Facebook, and on all of the social networks, everything is very polished and art-directed. They’re building a story. The content is about travel, but the through-line is about their suitcases.

When things go bad…

To finish, a semi-amusing story. Cath Kidston did a collaboration with Disney’s Peter Pan. Sarah had a hunch that it might go wrong. On paper, the social campaigns seemed fine. A slow build-up to the Peter Pan product launch. Lots of lovely teasers. They were seeding Instagram with beautiful imagery the day before launch. There was a real excitement building. Then the coveted email campaign with the coveted password.

On the site, people put in their password and then they had to wait. It was a deliberately gated experience. Twenty minutes of waiting. Then you finally get to the store …and there’s no “add to cart” button. Yup, they had left out the most important bit of the interface.

Sarah looked at what people were saying on Twitter. Lots of people assumed the problem was with their computer (after all, the web team wouldn’t be so silly as to leave off the “add to cart” button, right?). People blamed themselves. Cath Kidston scrambled to fix the problem …and threw people back into the 20 minute queue. Finally, the button appeared. So Sarah looked at a few bits ad pieces, and when she hit “add to cart” …she was thrown back to the 20 minute queue.

Sarah reached out to try to talk to someone on the web team. No one wanted to talk about it. If you ever find someone who was on that team, put them in touch.

Anyway, to wrap up…

Ensure the networks you are pursuing make sense for your brand.

Find your story for social media longevity.

See also:

Beyond Engagement: the Content Performance Quotient by Jeffrey Zeldman

I’m at An Event Apart Seattle (Special Edition). Jeffrey is kicking off the show with a presentation called Beyond Engagement: the Content Performance Quotient. I’m going to jot down some notes during this talk…

First, a story. Jeffrey went to college in Bloomington, Indiana. David Frost—the British journalist—came to talk to them. Frost had a busy schedule, and when he showed up, he seemed a little tipsy. He came up to the podium and said, “Good evening, Wilmington.”

Jeffrey remembers this and knows that Seattle and Portland have a bit of a rivalry, and so Jeffrey thought, the first time he spoke in Portland, it would be funny to say “Good morning, Seattle!” …and that was the last time he spoke in Portland.

Anyway …”Good morning, Portland!”

Jeffrey wants to talk about content. He spends a lot of time in meetings with stakeholders. Those stakeholders always want things to be better, and they always talk about “engagement.” It’s the number one stakeholder request. It’s a metric that makes stakeholders feel comfortable. It’s measurable—the more seconds people give us, the better.

But is that really the right metric?

There are some kinds of sites where engagement is definitely the right metric. Instagram, for example. That’s how they make money. You want to distract yourself. Also, if you have a big content site—beautifully art-directed and photographed—then engagement is what you want. You want people to spend a lot of time there. Or if you have a kids site, or a games site, or a reading site for kids, you want them to be engaged and spend time. A List Apart, too. It’s like the opposite of Stack Overflow, where you Google something and grab the piece of code you need and then get out. But for A List Apart or Smashing Magazine, you want people to read and think and spend their time. Engagement is what you want.

But for most sites—insurance, universities—engagement is not what you want. These sites are more like a customer service desk. You want to help the customer as quickly as possible. If a customer spends 30 minutes on our site, was she engaged …or frustrated? Was it the beautiful typography and copy …or because she couldn’t find what they wanted? If someone spends a long time on an ecommerce site, is it because the products are so good …or because search isn’t working well?

What we need is a metric called speed of usefulness. Jeffrey calls this Content Performance Quotient (CPQ) …because business people love three-letter initialisms. It’s a loose measurement: How quickly can you solve the customer’s problem? It’s the shortest distance between the problem and the solution. Put another way, it’s a measurement of your value to the customer. It’s a new way to evaluate success.

From the customer’s point of view, CPQ is the time it takes the customer to get the information she came for. From the organisation’s point of view, it’s the time it takes for a specific customer to find, receive, and absorb your most important content.

We’re all guilty of neglecting the basics on our sites—just what it is it that we do? We need to remember that we’re all making stuff to make people’s live’s easier. Otherwise we end up with what Jeffrey calls “pretty garbage.” It’s aesthetically coherent and visually well-designed …but if the content is wrong and doesn’t help anyone, it’s garbage. Garbage in a delightfully responsive grid is still garbage.

Let’s think of an example of where people really learned to cut back and really pare down their message. Advertising. In the 1950s, when the Leo Burnett agency started the Marlboro campaign, TV spots were 60 seconds long. An off-camera white man in a suit with a soothing voice would tell you all about the product while the visuals showed you what he was talking about. No irony. Marlboro did a commercial where there was no copy at all until the very end. For 60 seconds they showed you cowboys doing their rugged cowboy things. Men in the 1950s wanted to feel rugged, you see. Leo Burnett aimed the Marlboro cigarettes at those men. And at the end of the 60 second montage of rugged cowboys herding steers, they said “Come to where the flavour is. Come to Marlboro Country.” For the billboard, they cut it back even more. Just “Come to Marlboro Country.” In fact, they eventually went to just “Marlboro.” Jeffrey knows that this campaign worked well, because he started smoking Marlboros as a kid.

Leaving aside the ethical implications of selling cigarettes to eight-graders, let’s think about the genius of those advertisers. Slash your architecture and shrink your content. Constantly ask yourself, “Why do we need this?”

As Jared Spool says, design is the rendering of intent. Every design is intentional. There is some intent—like engagement—driving our design. If there’s no intent behind the design, it will fail, even if what you’re doing is very good. If your design isn’t going somewhere, it’s going nowhere. You’ve got to stay ruthlessly focused on what the customer needs and “kill your darlings” as Hemingway said. Luke Wroblewski really brought this to light when he talked about Mobile First.

To paraphrase David Byrne, how did we get here?

Well, we prioritised meetings over meaning. Those meetings can be full of tension; different stakeholders arguing over what should be on the homepage. And we tried to solve this by giving everyone what they want. Having a good meeting doesn’t necessarily mean having a good meeting. We think of good meetings as conflict-free where everyone emerges happy. But maybe there should be a conflict that gets resolved. Maybe there should be winners and losers.

Behold our mighty CMS! Anyone can add content to the website. Anyone can create the information architecture …because we want to make people happy in meetings. It’s easy to give everyone what they want. It’s harder to do the right thing. Harder for us, but better for the customer and the bottom line.

As Gerry McGovern says:

Great UX professionals are like whistleblowers. They are the voice of the user.

We need to stop designing 2001 sites for a 2018 web.

One example of cutting down content was highlighted in A List Apart where web design was compared to chess: The King vs. Pawn Game of UI Design. Don’t start by going through all the rules. Teach them in context. Teach chess by starting with a checkmate move, reduced down to just three pieces on the board. From there, begin building out. Start with the most important information, and build out from there.

When you strip down the game to its core, everything you learn is a universal principle.

Another example is atomic design: focus relentlessly on the individual interaction. We do it for shopping carts. We can do it for content.

Another example on A List Apart is No More FAQs: Create Purposeful Information for a More Effective User Experience. FAQ problems include:

  • duplicate and contradictory information,
  • lack of discernible content order,
  • repetitive grammatical structure,
  • increased cognitive load, and
  • more content than they need.

Users come to any type of content with a particular purpose in mind, ranging from highly specific (task completion) to general learning (increased knowledge).

The important word there is purpose. We need to eliminate distraction. How do we do that?

One way is the waterfall method. Do a massive content inventory. It’s not recommended (unless maybe you’re doing a massive redesign).

Agile and scrum is another way. Constantly iterate on content. Little by little over time, we make the product better. It’s the best bet if you work in-house.

If you work in an agency, a redesign is an opportunity to start fresh. Take everything off the table and start from scratch. Jeffrey’s friend Fred Gates got an assignment to redesign an online gaming platform for kids to teach them reading and management skills. The organisation didn’t have much money so they said, let’s just do the homepage. Fred challenged himself to put the whole thing on the homepage. The homepage tells the whole story. Jeffrey is using this same method on a site for an insurance company, even though the client has a bigger budget and can afford more than just the homepage. The point is, what Fred did was effective.

So this is what Jeffrey is going to be testing and working on: speed of usefulness.

And for those of you who do need to use engagement as the right metric, Jeffrey covered the two kinds of metrics in an article called We need design that is faster and design that is slower.

For example, “scannability” is good for transactions (CPQ), but bad for thoughtful content (engagement). Our news designs need to slow down the user. Bigger type, typographic hierarchy, and more whitespace. Art direction. Shout out to Derek Powazek who designed Fray.com—each piece was designed based on the content. These days, look at what David Sleight and his crew are doing over at Pro Publica.

Who’s doing it right?

The Washington Post, The New York Times, Pro Publica, Slate, Smashing Magazine, and Vox are all doing this well in different ways. They’re bringing content to the fore.

Readability, Medium, and A List Apart are all using big type to encourage thoughtful reading and engagement.

But for other sites …apply the Content Performance Quotient.

See also:

Links from a talk

In two weeks time, I’ll be in Seattle for An Event Apart. I’ll be giving a brand new talk. The title is The Way Of The Web (although perhaps a more accurate title would be The Layers Of The Web).

Here’s the description:

Do you ever get overwhelmed by the ever-changing nature of web design and development? Exhausting, isn’t it? How are you supposed to know which technologies and tools you should invest your time in? Will they stick around or will you just have to relearn everything in another few months? Join Jeremy as he takes a tour of the past, present, and future of working on the web. From the building blocks of HTML, CSS, and JavaScript through to frameworks and libraries right up to the latest and greatest Progressive Web Apps, this talk will examine our collective assumptions with a critical eye. By learning from the past, we can make sensible design decisions today to build the web of tomorrow.

There’s a direct evolution line from my previous talks—Resilence and Evaluating Technology—to this new one. (Spoiler: everything I talk about is in some way related to progressive enhancement …even if I never use the words “progressive" or “enhancement" in the talks.)

I’ve been preparing this new talk for months. It started with a mind map—an A3 sheet of paper with disconnected thoughts, like something from the scene in the crime movie where they enter the lair of the serial killer and find a crazy wall.

Then I set it aside and began procrastinating. But it was the good kind of procrastinating, right? I mean, I had made a start and all those thoughts were now bubbling around in my head.

Eventually I forced myself to put things in some sort of order and started creating slides. That’s the beginning of the horrible process bouncing between thinking “this is pretty good!” and “this is absolute crap!” To be honest, I never actually know if a talk is any good until I give it in front of an audience (practice runs at work are great for getting feedback but they’re not the same as doing the talk for real).

Anyway, I think the talk is ready to roll. If you see me giving this talk and you’re interested in diving deeper into the topics raised, I’ve gathered together some of sources I used.

Further Reading

Related posts on adactio.com

Progressive Web Apps

Books

Films

Global Diversity CFP Day—Brighton edition

There are enough middle-aged straight white men like me speaking at conferences. That’s why the Global Diversity Call-For-Proposals Day is happening this Saturday, February 3rd.

The purpose is two-fold. One is to encourage a diverse range of people to submit talk proposals to conferences. The other is to help with the specifics—coming with ideas, writing a good title and abstract, preparing the presentation, and all that.

Julie is organising the Brighton edition. Clearleft are providing the venue—68 Middle Street. I’ll be on hand to facilitate. Rosa and Dot will be doing the real work, mentoring the attendees.

If you’ve ever thought about submitting a talk proposal to a conference but just don’t know where to start, or if you’re just interested in the idea, please do come along on Saturday. It’s starts at 11am and will be all wrapped up by 3pm.

See you there!

Brighton conferences

I’ve been to four conferences in two weeks. I wasn’t speaking at any of them so I was able to relax and enjoy the talks.

There was UX Brighton on November 3rd, featuring a terrific opening keynote from Boxman.

James Box speaking at UX Brighton 2017

One week later, I was in the Duke of York’s cinema for FFConf along with all the other Clearleft frontend devs—it’s always a thought-provoking day out.

FFConf 2017 Day 2

Yesterday, I went to Meaning in the daytime, and Bytes in the evening.

It was amazing to get to see @ambrwlsn90 speak at #bytesconf tonight. She is a brilliant speaker! 🙌🏻

Every one of those events was in Brighton. That’s pretty good going for a town this size …and that’s not even counting the regular events like Async, Codebar, and Ladies That UX.

The dConstruct Audio Archive works offline

The dConstruct conference is as old as Clearleft itself. We put on the first event back in 2005, the year of our founding. The last dConstruct was in 2015. It had a good run.

I’m really proud of the three years I ran the show—2012, 2013, and 2014—and I have great memories from each event. I’m inordinately pleased that the individual websites are still online after all these years. I’m equally pleased with the dConstruct audio archive that we put online in 2012. Now that the event itself is no longer running, it truly is an archive—a treasury of voices from the past.

I think that these kinds of online archives are eminently suitable for some offline design. So I’ve added a service worker script to the dConstruct archive.

Caching

To start with, there’s the no-brainer: as soon as someone hits the website, pre-cache static assets like CSS, JavaScript, the logo, and icon images. Now subsequent page loads will be quicker—those assets are taken straight from the cache.

But what about the individual pages? For something like Resilient Web Design—another site that won’t be updated—I pre-cache everything. I could do that with the dConstruct archive. All of the pages with all of the images add up to less than two megabytes; the entire site weighs less than a single page on Wired.com or The Verge.

In the end, I decided to go with a cache-as-you-go strategy. Every time a page or an image is fetched from the network, it is immediately put in a cache. The next time that page or image is requested, the file is served from that cache instead of the network.

Here’s the logic for fetch requests:

  1. First, look to see if the file is in a cache. If it is, great! Serve that.
  2. If the file isn’t in a cache, make a network request and serve the response …but put a copy of a file in the cache.
  3. The next time that file is requested, go to step one.

Save for offline

That caching strategy works great for pages, images, and other assets. But there’s one kind of file on the dConstruct archive that’s a bit different: the audio files. They can be fairly big, so I don’t want to cache those unless the user specifically requests it.

If you end up on the page for a particular talk, and your browser supports service workers, you’ll get an additional UI element in the list of options: a toggle to “save offline” (under the hood, it’s a checkbox). If you activate that option, then the audio file gets put into a cache.

Now if you lose your network connection while browsing the site, you’ll get a custom offline page with the option to listen to any audio files you saved for offline listening. You’ll also see this collection of talks on the homepage, regardless of whether you’ve got an internet connection or not.

So if you’ve got a long plane journey ahead of you, have a browse around the dConstruct archive and select some talks for your offline listening pleasure.

Or just enjoy the speediness of browsing the site.

Turning another website into a Progressive Web App.

Speak and repeat

Rachel and Drew are starting a new service called Notist. It’s going to be a place where conference speakers can collate their materials. They’ve also got a blog.

The latest blog post, by Rachel, is called Do I need to write a brand new talk every time?

New presenters often feel that they need to write a brand-new talk for each conference they are invited to. Unless your job is giving presentations, or you are being paid very well for each talk you give, it is unlikely that you will be able to keep this up if you do more than a couple of talks per year.

It’s true. When I first started giving talks, I felt really guilty at the thought of “recycling” a talk I had already given. “Those people have paid money to be here—they deserve a brand new talk”, I thought. But then someone pointed out to me, “Y’know, it’s actually really arrogant to think that anyone would’ve seen any previous talk of yours.” Good point.

Giving the same talk more than once also allows me to put in the extra effort into the talk prep. If I’m going through the hair-tearing-out hell of trying to wrestle a talk into shape, I’m inevitably going to ask, “Why am I putting myself through this‽” If the answer to that question is “So you can give this talk just once”, I’d probably give up in frustration. But if I know that I’ll have an opportunity to present it more than once, improving it each time, then that gives me the encouragement to keep going.

I do occasionally give a one-off specially-commissioned talk, but those are the exceptions. My talk on the A element at CSS Day’s HTML Special was one of those. Same with my dConstruct talk back in 2008. I just gave a new talk on indie web building blocks at Mozilla’s View Source event, but I’d quite like to give that one again (if you’re running an event, get in touch if that sounds like something you’d like).

My most recent talk isEvaluating Technology. I first gave it at An Event Apart in San Francisco exactly a year ago. I’ll present it for the final time at An Event Apart in Denver in a few weeks. Then it will be retired; taken out to the woodshed; pivoted to video.

I’m already starting to think about my next talk. The process of writing a talk is something else that Rachel has written about. She’s far more together than me. My process involves lots more procrastination, worry, panic, and pacing. Some of the half-baked ideas will probably leak out as blog posts here. It’s a tortuous process, but in the end, I find the satisfaction of delivering the final talk to be very rewarding.

Here’s the thing, though: until I deliver the talk for the first time in front of an audience—no matter how much I might have practiced it—I have literally no idea if it’s any good. I honestly can’t tell whether what I’ve got is gold dust or dog shit (and during the talk prep, my opinion of it can vacillate within the space of five minutes). And so, even though I’ve been giving talks for many years now, if it’s brand new material, I get very nervous.

That’s one more reason to give the same talk more than once instead of creating a fresh hell each time.

Material 2017

I’m in Iceland. Everything you’ve heard is true. It’s a beautiful fascinating place, and I had a wonderful day of exploration yesterday.

But I didn’t just come to the land of ice and snow—of the midnight sun where the hot springs blow—just to take in the scenery. I’m also here for the Material conference, which just wrapped up. It was very small, and very, very good.

Reading the description of the event, it would definitely be a tough sell trying to get your boss to send you to this. And yet I found it to be one of the most stimulating conferences I’ve attended in a while. It featured talks about wool, about art, about psychology, about sound, about meditation, about photography, about storytelling, and yes, about the web.

That sounds like a crazy mix of topics, but what was really crazy was the way it all slotted together. Brian weaved together a narrative throughout the day, drawing together strands from all of the talks and injecting his own little provocations into the mix too. Is the web like sound? Is the web like litmus paper? Is the web like the nervous system of a blue whale? (you kinda had to be there)

I know it’s a cliché to talk about a conference as being inspirational, but I found myself genuinely inspired by what I heard today. I don’t mean inspired in the self-help feel-good kind of way; I mean the talks inspired thoughts, ideas, and questions.

I think the small-scale intimacy of the event really added something. There were about fifty of us in attendance, and we all ate lunch together, which added to the coziness. I felt some of the same vibe that Brooklyn Beta and Reboot used to generate—a place for people to come together that isn’t directly connected to day-to-day work, but not entirely disconnected either; an adjacent space where seemingly unconnected disciplines get threaded together.

If this event happens again next year, I’ll be back.

Putting on a conference

It’s been a few weeks now since Patterns Day and I’m still buzzing from it. I might be biased, but I think it was a great success all ‘round—for attendees, for speakers, and for us at Clearleft organising the event.

I first had the idea for Patterns Day quite a while back. To turn the idea into reality meant running some numbers. Patterns Day wouldn’t have been possible without Alis. She did all the logistical work—the hard stuff—which freed me up to concentrate on the line-up. I started to think about who I could invite to speak, and at the same time, started looking for a venue.

I knew from the start that I wanted it to be one-day single-track conference in Brighton, much like Responsive Day Out. I knew I wouldn’t be able to use the Corn Exchange again—there’s extensive rebuilding going on there this year. I put together a shortlist of Brighton venues and Alis investigated their capacities and costs, but to be honest, I knew that I wanted to have it in the Duke Of York’s. I love that place, and I knew from attending FFconf that it makes for an excellent conference venue.

The seating capacity of the Duke Of York’s is quite a bit less than the Corn Exchange, so I knew the ticket price would have to be higher than that of Responsive Day Out. The Duke Of York’s isn’t cheap to rent for the day either (but worth every penny).

To calculate the ticket price, I had to figure out the overall costs:

  • Venue hire,
  • A/V hire,
  • Printing costs (for name badges, or in this case, stickers),
  • Payment provider commission—we use Stripe through the excellent Ti.to,
  • Speaker’s travel,
  • Speaker’s accommodation,
  • Speaker’s dinner the evening before the event,
  • Speaker’s payment.

Some conference organisers think they can skimp on that last part. Those conference organisers are wrong. A conference is nothing without its speakers. They are literally the reason why people buy tickets.

Because the speakers make or break a conference, there’s a real temptation to play it safe and only book people who are veterans. But then you’re missing out on a chance to boost someone when they’re just starting out with public speaking. I remember taking a chance on Alla a few years back for Responsive Day Out 3—she had never given a conference talk before. She, of course, gave a superb talk. Now she’s speaking at events all over the world, and I have to admit, it gives me a warm glow inside. When it came time for Patterns Day, Alla had migrated into the “safe bet” category—I knew she’d deliver the perfect closing keynote.

I understand why conference organisers feel like they need to play it safe. From their perspective, they’re already taking on a lot of risk in putting on a conference in the first place. It’s easy to think of yourself as being in a position of vulnerability—”If I don’t sell enough tickets, I’m screwed!” But I think it’s important to realise that you’re also in a position of power, whether you like it or not. If you’re in charge of putting together the line-up of a conference, that’s a big responsibility, not just to the attendees on the day, but to the community as a whole. It’s like that quote by Eliel Saarinen:

Always design a thing by considering it in its next larger context. A chair in a room, a room in a house, a house in an environment, an environment in a city plan.

Part of that responsibility to the wider community is representation. That’s why I fundamentally disagree with ppk when he says:

The other view would be that there should be 50% woman speakers. Although that sounds great I personally never believed in this argument. It’s based on the general population instead of the population of web developers, and if we’d extend that argument to its logical conclusion then 99.9% of the web development conference speakers should know nothing about web development, since that’s the rough ratio in the general population.

That makes it sound like a conference’s job is to represent the status quo. By that logic, the line-up should include plenty of bad speakers—after all, the majority of web developers aren’t necessarily good speakers. But of course that’s not how conferences work. They don’t represent typical ideas—quite the opposite. What’s the point of having an event that simply reinforces the general consensus? This isn’t Harrison Bergeron. You want a line-up that’s exceptional.

I don’t think conference organisers can shirk this issue and say “It’s out of my hands; I’m just reflecting the way things are.” The whole point of having a conference in the first place is to trigger some kind of change. If you’re not happy with the current make-up of the web community (and I most definitely am not), then a conference is the perfect opportunity to try to demonstrate an alternative. We do it with the subject matter of the talks—”Our code/process/tooling doesn’t have to be this way!”—and I think we should also apply that to the wider context: “Our culture doesn’t have to be this way!”

Passing up that chance isn’t just a missed opportunity, I think it’s also an abdication of responsibility. Believe me, I know that organising a conference is a lot of work, but that’s not a reason to cop out. On the contrary, it’s all the more reason to step up to the plate and try your damnedest to make a difference. Otherwise, why even have a conference?

Whenever the issue of diversity at conferences comes up, there is inevitably someone who says “All I care about is having the best speakers.” But if that were true, shouldn’t your conference (and every other conference) have exactly the same line-up every year?

The truth is that there are all sorts of factors that play into the choice of speakers. I think representation should be a factor, but that’s all it is—one factor of many. Is the subject matter relevant? That’s a factor. Do we already have someone on the line-up covering similar subject matter? That’s a factor. How much will it cost to get this speaker? That’s a factor. Is the speaker travelling from very far away? That’s a factor.

In the case of Patterns Day, I had to factor in the range of topics. I wanted a mixture of big-picture talks as well as hands-on nitty-gritty case studies. I also didn’t want it to be too developer-focused or too design-focused. I was aiming for a good mix of both.

In the end, I must admit that I am guilty of doing exactly what I’ve been railing against. I played it safe. I put together a line-up of speakers that I wanted to see, and that I knew with absolute certainty would deliver great presentations. There were plenty of potential issues for me to get stressed about in the run-up to the event, but the quality of the talks wasn’t one of them. On the one hand, I wish I had taken more chances with the line-up, but honestly, if I could do it over again, I wouldn’t change a thing.

Because I was trying to keep the ticket price as low as possible—and the venue hire was already a significant cost—I set myself the constraint of only having speakers from within the UK (Jina was the exception—she was going to come anyway as an attendee, so of course I asked her to speak). Knowing that the speaker’s travel costs would be low, I could plug the numbers into an algebraic formula for figuring out the ticket price:

costs ÷ seats = price

Add up all the costs and divide that total by the number of available seats to get the minimum ticket price.

In practice, you probably don’t want to have to sell absolutely every single ticket just to break even, so you set the price for a sales figure lower than 100%—maybe 80%, or 50% if you’re out to make a tidy profit (although if you’re out to make a tidy profit, I don’t think conferences are the right business to be in—ask any conference organiser).

Some conferences factor in money for sponsorship to make the event happen. I prefer to have sponsors literally sponsoring additions to the conference. In the case of Patterns Day, the coffee and pastries were sponsored by Deliveroo, and the videos were sponsored by Amazon. But sponsorship didn’t affect the pricing formula.

The Duke Of York’s has around 280 seats. I factored in about 30 seats for speakers, Clearlefties, and other staff. That left 250 seats available for attendees. But that’s not the number I plugged into the pricing formula. Instead, I chose to put 210 tickets on sale and figured out the ticket price accordingly.

What happened to the remaining 40 seats? The majority of them went to Codebar students and organisers. So if you bought a ticket for Patterns Day, you directly subsidised the opportunity for people under-represented in technology to attend. Thank you.

Speaking personally, I found that having the Codebar crew in attendance really made my day. They’re my heroes, and it meant the world to me that they were able to be there.

Zara, Alice, and Amber Patterns Day Anwen, Zara, Alice, Dot, and Amber Eden, Zara, Alice, and Chloe

Patterns Day videos

Eleven days have passed since Patterns Day. I think I’m starting to go into withdrawal.

Fortunately there’s a way to re-live the glory. Video!

The first video is online now: Laura Elizabeth’s excellent opener. More videos will follow. Keep an eye on this page.

And remember, the audio is already online as a podcast.

Patterns Day

Patterns Day is over. It was all I hoped it would be and more.

I’ve got that weird post-conference feeling now, where that all-consuming thing that was ahead of you is now behind you, and you’re not quite sure what to do. Although, comparatively speaking, Patterns Day came together pretty quickly. I announced it less than three months ago. It sold out just over a month later. Now it’s over and done with, it feels like a whirlwind.

The day itself was also somewhat whirlwind-like. It was simultaneously packed to the brim with great talks, and yet over in the blink of an eye. Everyone who attended seemed to have a good time, which makes me very happy indeed. Although, as I said on the day, while it’s nice that everyone came along, I put the line-up together for purely selfish reasons—it was my dream line-up of people I wanted to see speak.

Boy, oh boy, did they deliver the goods! Every talk was great. And I must admit, I was pleased with how I had structured the event. The day started and finished with high-level, almost philosophical talks; the mid section was packed with hands-on nitty-gritty practical examples.

Thanks to sponsorship from Amazon UK, Craig was videoing all the talks. I’ll get them online as soon as I can. But in the meantime, Drew got hold of the audio and made mp3s of each talk. They are all available in handy podcast form for your listening and huffduffing pleasure:

  1. Laura Elizabeth
  2. Ellen de Vries
  3. Sareh Heidari
  4. Rachel Andrew
  5. Alice Bartlett
  6. Jina Anne
  7. Paul Lloyd
  8. Alla Kholmatova

If you’re feeling adventurous, you can play the Patterns Day drinking game while you listen to the talks:

  • Any time someone says “Lego”, take a drink,
  • Any time someone references Chrisopher Alexander, take a drink,
  • Any time someone says that naming things is hard, take a drink,
  • Any time says “atomic design”, take a drink, and
  • Any time says “Bootstrap”, puke the drink back up.

In between the talks, the music was provided courtesy of some Brighton-based artists

Hidde de Vries has written up an account of the day. Stu Robson has also published his notes from each talk. Sarah Drummond wrote down her thoughts on Ev’s blog.

I began the day by predicting that Patterns Day would leave us with more questions than answers …but that they would be the right questions. I think that’s pretty much what happened. Quite a few people compared it to the first Responsive Day Out in tone. I remember a wave of relief flowing across the audience when Sarah opened the show by saying:

I think if we were all to be a little more honest when we talk to each other than we are at the moment, the phrase “winging it” would be something that would come up a lot more often. If you actually speak to people, not very many people have a process for this at the moment. Most of us are kind of winging it.

  • This is hard.
  • No one knows exactly what they’re doing.
  • Nobody has figured this out yet.

Those sentiments were true of responsive design in 2013, and they’re certainly true of design systems in 2017. That’s why I think it’s so important that we share our experiences—good and bad—as we struggle to come to grips with these challenges. That’s why I put Patterns Day together. That’s also why, at the end of the day, I thanked everyone who has ever written about, spoken about, or otherwise shared their experience with design systems, pattern libraries, style guides, and components. And of course I made sure that everyone gave Anna a great big round of applause for her years of dedicated service—I wish she could’ve been there.

There were a few more “thank you”s at the end of the day, and all of them were heartfelt. Thank you to Felicity and everyone else at the Duke of York’s for the fantastic venue and making sure everything went so smoothly. Thank you to AVT for all the audio/visual wrangling. Thanks to Amazon for sponsoring the video recordings, and thanks to Deliveroo for sponsoring the tea, coffee, pastries, and popcorn (they’re hiring, by the way). Huge thanks to Alison and everyone from Clearleft who helped out on the day—Hana, James, Rowena, Chris, Benjamin, Seb, Jerlyn, and most especially Alis who worked behind the scenes to make everything go so smoothly. Thanks to Kai for providing copies of Offscreen Magazine for the taking. Thanks to Marc and Drew for taking lots of pictures. Thanks to everyone who came to Patterns Day, especially the students and organisers from Codebar Brighton—you are my heroes.

Most of all thank you, thank you, thank you, to the eight fantastic speakers who made Patterns Day so, so great—I love you all.

Laura Ellen Sareh Rachel Alice Jina Paul Alla

One week to Patterns Day

Greetings!

Patterns Day is one week from today—Friday, June 30th. I’m really looking forward to seeing you in Brighton.

If you’re arriving by train, the venue is a short walk away from the train station. The Duke Of York’s Picture House is at Preston Circus. You’ll recognise the building by its distinctive pair of artificial can-can legs emerging from the roof.

http://tinyurl.com/patternsday

Registration starts at 9am. Show up with some ID, speak friend, and enter. Patterns Day is going to be a bit different to most conferences. Instead of getting a schwag bag and a name badge on a lanyard, you’re going to get a sticker to slap on yourself. The sticker identifies you as an attendee so please don’t lose it.

Once you’re registered, please help yourself to the free coffee, tea, and pastries. I’ll open up the show shortly before 10am with some introductory remarks, and then we’ll be all set for our first speaker at 10am. Here’s how the schedule is shaping up (but always subject to change):

https://adactio.com/journal/12409

There won’t be any conference WiFi. This is by design.

There’ll be a nice long lunch break from 12:30pm to 2pm. You’ll find plenty of tasty options in the neighbourhood. I’ve listed just a few on the Patterns Day website:

https://patternsday.com/#venue

There’ll be more coffee and tea throughout the day, and maybe a nice bag of popcorn in the afternoon.

We’ll finish up before 5pm, at which point we can collectively retire to a nearby pub to continue our discussions. Or we can head to the seafront to douse our melting brains in the English channel. Let’s play it by ear.

I can’t wait to welcome you to Patterns Day, and I’m positively aquiver with anticipation of the talks we’re going to hear from the fantastic line-up of speakers: Laura, Ellen, Sareh, Rachel, Alice, Jina, Paul, and Alla.

See you soon!

—Jeremy

The schedule for Patterns Day

There are only seventeen more days until Patterns Day. Squee!

I’ve got a plan now for how the day is going to run. Here’s the plan:

registration
opening remarks
Laura Elizabeth
Ellen deVries
break
Sareh Heidari
Rachel Andrew
lunch break
Alice Bartlett
Jina Anne
break
Paul Lloyd
Alla Kholmatova
closing remarks

There was a great response to my call for sponsors. Thanks to Amazon Video, we’ll have video recordings of all the talks. Thanks to Deliveroo, we’ll have coffee and tea throughout the day …and pastries in the morning! …and popcorn in the afternoon!!

You’re on your own for lunch. I’ve listed some options on the website, but I should add some more.

I have to say, looking at the schedule for the day, I’m very excited about this line-up. To say I’m looking forward to it would be quite the understatement. I can’t wait!

Sponsoring Patterns Day

It didn’t take long for Patterns Day to sell out (in the sense of the tickets all being sold; not in the sense of going mainstream and selling out to The Man).

I’m very pleased about the ticket situation. It certainly makes my life easier. Now I can concentrate on the logistics for the day, without having to worry about trying to flog tickets AKA marketing.

But I also feel bad. Some people who really, really wanted to come weren’t able to get tickets in time. This is usually because they work at a company where to have to get clearance for the time off, and the cost of the ticket. By the time the word came down from on high that they’ve got the green light, the tickets were already gone. That’s a real shame.

There is, however, a glimmer of hope on the horizon. There is one last chance to get tickets for Patterns Day, and that’s through sponsorship.

Here’s the deal: if I can get some things sponsored (like recordings of the talks, tea and coffee for the day, or an after-party), I can offer a few tickets in return. I can also offer your logo on the Patterns Day website, your logo on the slide between talks, and a shout-out on stage. But that’s pretty much it. I can’t offer a physical stand at the event—there just isn’t enough room. And I certainly can’t offer you a list of attendee details for your marketing list—that’s just wrong.

In order of priority, here’s what I would love to get sponsored, and here’s what I can offer in return:

  1. £2000: Sponsoring video recordings of the talks—4 tickets. This is probably the best marketing opportunity for your company; we can slap your logo at the start and end of each video when they go online.
  2. £2000: Sponsoring tea and coffee for attendees for the day—4 tickets. This is a fixed price, set by the venue.
  3. £2000+: Sponsoring an after-party near the conference—4 tickets. Ideally you’d take care of booking a venue for this, and you can go crazy decking it out with your branding. Two pubs right across from the conference venue have upstairs rooms you can book: The Joker, and The Hare And Hounds.

There you have it. There’s no room for negotiation, I’m afraid, but I think they’re pretty good deals. Remember, by sponsoring Patterns Day you’ll also have my undying gratitude, and the goodwill of all my peers coming to this event.

Reckon you can convince your marketing department? Drop me a line, let me know which sponsorship option you’d like to snap up, and those four tickets could be yours.

Patterns Day speakers

Ticket sales for Patterns Day are going quite, quite briskly. If you’d like to come along, but you don’t yet have a ticket, you might want to remedy that. Especially when you hear about who else is going to be speaking…

Sareh Heidari works at the BBC building websites for a global audience, in as many as twenty different languages. If you want to know about strategies for using CSS at scale, you definitely want to hear this talk. She just stepped off stage at the excellent CSSconf EU in Berlin, and I’m so happy that Sareh’s coming to Brighton!

Patterns Day isn’t the first conference about design systems and pattern libraries on the web. That honour goes to the Clarity conference, organised by the brilliant Jina Anne. I was gutted I couldn’t make it to Clarity last year. By all accounts, it was excellent. When I started to form the vague idea of putting on an event here in the UK, I immediately contacted Jina to make sure she was okay with it—I didn’t want to step on her toes. Not only was she okay with it, but she really wanted to come along to attend. Well, never mind attending, I said, how about speaking?

I couldn’t be happier that Jina agreed to speak. She has had such a huge impact on the world of pattern libraries through her work with the Lightning design system, Clarity, and the Design Systems Slack channel.

The line-up is now complete. Looking at the speakers, I find myself grinning from ear to ear—it’s going to be an honour to introduce each and every one of them.

This is going to be such an excellent day of fun and knowledge. I can’t wait for June 30th!