Tags: talk

21

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).

Designing Progressive Web Apps by Jason Grigsby

It’s the afternoon of the second day of An Event Apart Seattle and Jason is talking about Designing Progressive Web Apps. These are my notes…

Jason wants to talk about a situation you might find yourself in. You’re in a room and in walks the boss, who says “We need a progressive web app.” Now everyone is asking themselves “What is a progressive web app?” Or maybe “How does the CEO even know about progressive web apps?”

Well, trade publications are covering progressive web apps. Lots of stats and case studies are being published. When executives see this kind of information, they don’t want to get left out. Jason keeps track of this stuff at PWA Stats.

Answering the question “What is a progressive web app?” is harder than it should be. The phrase was coined by Frances Berriman and Alex Russell. They listed ten characteristics that defined progressive web apps. The “linkable” and “progressive” characteristics are the really interesting and new characteristics. We’ve had technologies before (like Adobe Air) that tried to make app-like experiences, but they weren’t really of the web. Progressive web apps are different.

Despite this list of ten characteristics, even people who are shipping progressive web apps find it hard to define the damn thing. The definition on Google’s developer site keeps changing. They reduced the characteristics from ten to six. Then it became “reliable, fast, and engaging.” What does that mean? Craigslist is reliable, fast, and engaging—does that mean it’s a progressive web app.

The technical definition is useful (kudos to me, says Jason):

  1. HTTPS
  2. service worker
  3. manifest file

If you don’t have those three things, it’s not a progressive web app.

We should definitely use HTTPS if we want make life harder for the NSA. Also browser makers are making APIs available only under HTTPS. By July, Chrome will mark HTTP sites as insecure. Every site should be under HTTPS.

Service workers are where the power is. They act as a proxy. They allow us to say what we want to cache, what we want to go out to the network for; things that native apps have been able to do for a while. With progressive web apps we can cache the app shell and go to the network for content. Service workers can provide a real performance boost.

A manifest file is simply a JSON file. It’s short and clear. It lists information about the app: icons, colours, etc.

Once you provide those three things, you get benefits. Chrome and Opera on Android will prompt to add the app to the home screen.

So that’s what’s required for progressive web apps, but there’s more to them than that (in the same way there’s more to responsive web design than the three requirements in the baseline definition).

The hype around progressive web apps can be a bit of a turn-off. It certainly was for Jason. When he investigated the technologies, he wondered “What’s the big deal?” But then he was on a panel at a marketing conference, and everyone was talking about progressive web apps. People’s expectations of what you could do on the web really hadn’t caught up with what we can do now, and the phrase “progressive web app” gives us a way to encapsulate that. As Frances says, the name isn’t for us; it’s for our boss or marketer.

Jason references my post about using the right language for the right audience.

Should you have a progressive web app? Well, if you have a website, then the answer is almost certainly “Yes!” If you make money from that website, the answer is definitely “Yes!”

But there’s a lot of FUD around progressive web apps. It brings up the tired native vs. web battle. Remember though that not 100% of your users or customers have your app installed. And it’s getting harder to convince people to install apps. The average number of apps installed per month is zero. But your website is often a customer’s first interaction with your company. A better web experience can only benefit you.

Often, people say “The web can’t do…” but a lot of the time that information is out of date. There are articles out there with outdated information. One article said that progressive web apps couldn’t access the camera, location, or the fingerprint sensor. Yet look at Instagram’s progressive web app: it accesses the camera. And just about every website wants access to your location these days. And Jason knows you can use your fingerprint to buy things on the web because he accidentally bought socks when he was trying to take a screenshot of the J.Crew website on his iPhone. So the author of that article was just plain wrong. The web can do much more than we think it can.

Another common objection is “iOS doesn’t support progressive web apps”. Well, as of last week that is no longer true. But even when that was still true, people who had implemented progressive web apps were seeing increased conversion even on iOS. That’s probably because, if you’ve got the mindset for building a progressive web app, you’re thinking deeply about performance. In many ways, progressive web apps are a trojan horse for performance.

These are the things that people think about when it comes to progressive web apps:

  1. Making it feel like a app
  2. Installation and discovery
  3. Offline mode
  4. Push notifications
  5. Beyond progressive web app

Making it feel like a app

What is an app anyway? Nobody can define it. Once again, Jason references my posts on this topic (how “app” is like “obscenity” or “brunch”).

A lot of people think that “app-like” means making it look native. But that’s a trap. Which operating system will you choose to emulate? Also, those design systems change over time. You should define your own design. Make it an exceptional experience regardless of OS.

It makes more sense to talk in terms of goals…

Goal: a more immersive experience.

Possible solution: removing the browser chrome and going fullscreen?

You can define this in the manifest file. But as you remove the browser chrome, you start to lose things that people rely on: the back button, the address bar. Now you have to provide that functionality. If you move to a fullscreen application you need to implement sharing, printing, and the back button (and managing browser history is not simple). Remember that not every customer will add your progressive web app to their home screen. Some will have browser chrome; some won’t.

Goal: a fast fluid experience.

Possible solution: use an app shell model.

You want smooth pages that don’t jump around as the content loads in. The app shell makes things seem faster because something is available instantly—it’s perceived performance. Basically you’re building a single page application. That’s a major transition. But thankfully, you don’t have to do it! Progressive web apps don’t have to be single page apps.

Goal: an app with personality.

Possible solution: Animated transitions and other bits of UI polish.

Really, it’s all about delight.

Installation and discovery

In your manifest file you can declare a background colour for the startup screen. You can also declare a theme colour—it’s like you’re skinning the browser chrome.

You can examine the manifest files for a site in Chrome’s dev tools.

Once you’ve got a progressive web app, some mobile browsers will start prompting users to add it to their home screen. Firefox on Android displays a little explainer the first time you visit a progressive web app. Chrome and Opera have add-to-homescreen banners which are a bit more intrusive. The question of when they show up keeps changing. They use a heuristic to decide this. The heuristic has been changed a few times already. One thing you should consider is suppressing the banner until it’s an optimal time. Flipkart do this: they only allow it on the order confirmation page—the act of buying something makes it really likely that someone will add the progressive web app to their home screen.

What about app stores? We don’t need them for progressive web apps—they’re on the web. But Microsoft is going to start adding progressive web apps to their app store. They’ve built a site called PWA Builder to help you with your progressive web app.

On the Android side, there’s Trusted Web Activity which is kind of like PhoneGap—it allows you to get a progressive web app into the Android app store.

But remember, your progressive web app is your website so all the normal web marketing still applies.

Offline mode

A lot of organisations say they have no need for offline functionality. But everyone has a need for some offline capability. At the very least, you can provide a fallback page, like Trivago’s offline maze game.

You can cache content that has been recently viewed. This is what Jason does on the Cloud Four site. They didn’t want to make any assumptions about what people might want, so they only cache pages as people browse around the site.

If you display cached information, you might want to display how stale the information is e.g. for currency exchange rates.

Another option is to let people choose what they want to keep offline. The Financial Times does this. They also pre-cache the daily edition.

If you have an interactive application, you could queue tasks and then carry them out when there’s a connection.

Or, like Slack does, don’t let people write something if they’re offline. That’s better than letting someone write something and then losing it.

Workbox is a handy library for providing offline functionality.

Push notifications

The JavaScript for push notifications is relatively easy, says Jason. It’s the back-end stuff that’s hard. That’s because successful push notifications are personalised. But to do that means doing a lot more work on the back end. How do you integrate with preferences? Which events trigger notifications?

There are third-party push notification services that take care of a lot of this for you. Jason has used OneSignal.

Remember that people are really annoyed by push notifications. Don’t ask for permission immediately. Don’t ask someone to marry you on a first date. On Cloud Four’s blog, they only prompt after the user has read an article.

Twitter’s progressive web app does this really well. It’s so important that you do this well: if a user says “no” to your push notification permission request, you will never be able to ask them again. There used to be three options on Chrome: allow, block, or close. Now there are just two: allow or block.

Beyond progressive web apps

There are a lot of APIs that aren’t technically part of progressive web apps but get bundled in with them. Like the Credentials Management API or the Payment Request API (which is converging with ApplePay).

So how should you plan your progressive web app launch? Remember it’s progressive. You can keep adding features. Each step along the way, you’re providing value to people.

Start with some planning and definition. Get everyone in a room and get a common definition of what the ideal progressive web app would look like. Remember there’s a continuum of features for all five of the things that Jason has outlined here.

Benchmark your existing site. It will help you later on.

Assess your current website. Is the site reasonably fast? Is it responsive? Fix those usability issues first.

Next, do the baseline. Switch to HTTPS. Add a manifest file. Add a service worker. Apart from the HTTPS switch, this can all be done on the front end. Don’t wait for all three: ship each one when they’re ready.

Then do front-end additions: pre-caching pages, for example.

Finally, there are the larger initiatives (with more complex APIs). This is where your initial benchmarking really pays off. You can demonstrate the value of what you’re proposing.

Every step on the path to a progressive web app makes sense on its own. Figure out where you want to go and start that journey.

See also:

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:

Graduating to Grid by Rachel Andrew

It’s time for a gridtastic afternoon at An Event Apart Seattle (Special Edition). Kicking it off is Rachel with her talk Graduating to Grid. Here are my notes…

When Rachel spoke at An Event Apart last year, grid layout was still on the horizon. Then in March 2017, Chrome, Safari, and Firefox all shipped within weeks of one another. Then at An Event Apart Seattle last year, Edge announced that they were shipping too. So within a very short time, CSS grid got really good browser support.

What’s it like being in the middle of a launch of a big new CSS feature? Very quickly, we had 90% browser support. Suddenly it wasn’t just Jen and Rachel talking about grid—everyone was talking about grid. It involved a lot of email. Alas, Rachel couldn’t answer all those questions (she has a job, after all) but she did start collecting those questions. She found that people were excited, confused, and scared. So much to learn!

Rachel put out a survey and asked “How do you feel when a new CSS feature is announced?” Responses included “Oh, no!” and “Tired.” Some of us in the audience can, no doubt, identify with that.

People started emailing Rachel asking for her blessing. Were they doing the right thing? But Rachel can’t tell you what to do. She’s not in your situation. But she can help you develop the skills to make those decisions yourself. She can offer you confidence. She wants everyone to be the amazing CSS layout person on their team. That’s what this talk is for.

First of all, you need to understand CSS. There’s no shortcut here. But that doesn’t mean you need to learn every single property and value by heart. That’s not what CSS is about. That’s like learning phrases in a foreign language—knowing the words for “coffee” or “beer” doesn’t help you grok the language. It’s the same for CSS. There are some core ideas that help CSS layout make sense. You probably have an understanding of them already, but maybe you don’t have the right words for them.

At the heart of this is the first word in the language we’re talking about: cascading. You need to understand the (much-maligned) cascade. And you can’t talk about the cascade without encountering specificity. The MDN page on the cascade and specificity is a good explanation.

Then there’s dimensions. In any language with a horizontal writing mode, the inline dimension runs left to right or right to left, and the block dimension runs down the page from top to bottom. In vertical writing mode, it’s different.

In grid, we talk about the inline axis as rows, and the block axis as columns.

Sizing matters. It has become obvious that no one understands how big anything is. We’re living in a world where you don’t control the size of things.

In older float-based systems, everything is given a percentage. As long as our percentages don’t exceed 100%, everything’s okay. And we’ve got wrappers to keep things within rows. We end up with something that looks like a grid. It involves us doing a lot of calculating. You can do this with flexbox too, but it’s much the same—figuring out percentages. These past layout methods create the appearance of a grid by lining things up.

With the new layout, we don’t have to do the calculations. We need to understand CSS intrinsic sizing and extrinsic sizing (say that ten times fast).

With a regular div, you’ve got a block-level element. The box will stretch as far as it will go, to the viewport width by default. You can specify an intrinsic size by saying, say, width: 500px. That makes 500 pixels wide in the inline direction.

However the content of the box has a size. The maximum size of a string of text is how much space it would take up if it never wrapped. The minimum size is the space it would take up if everything wrapped. Now in CSS we can say width: min-content or width: max-content.

Let’s say our div was in a container that had a width of 20em. The max-content of the contents of the div (which is more than 20 ems) is wider than the width of the div and so the content overflows.

In flexbox, let’s say we’ve got a flex container with four items and we’ve declared that each one should take up max-content. Each item takes up as much space as it needs. Each one uses max-content as its starting point, and then width is removed to make all four items fit in the container. flex: 1 1 auto will distribute space according to the content. flex: 1 1 0 will distribute the space equally (you’re effectively saying that the max-content is zero).

It’s similar with grid layout but with slight differences. Flexbox is starting from max-content and taking space away. Grid is starting from min-content and adding space.

Those content keywords aren’t well supported outside grid layout. They’re safe to use for track sizing.

grid-template-columns: repeat(4, min-content);

That will make everything squished down.

grid-template-columns: repeat(4, max-content);

That one will probably cause an overflow.

grid-template-columns: repeat(4, fit-content(15ch));

That one will make 15 characters an upper limit!

You can make a grid layout using fr units and grid-gap. No need for figuring out percentages. You can use percentages if you like though. You can use percentages for gaps, for example.

Remember, you don’t have to stick with a twelve column grid. Slack started with that because it was what they were used to. Then they realised they didn’t have to.

Imagine a media object pattern, where you don’t want the image to ever be bigger than 300 pixels.

grid-template-columns: fit-content(300px) 1fr

As Rachel creates more layouts with grid, she finds she’s using less and less CSS, which is great. The browser is doing the work. That matches the reality of the situation where you don’t know the size of your content in advance—long titles, and so on.

This is not exciting. But it will let you do exciting things. Learning about sizing is the CSS equivalent of eating your vegetables or getting enough sleep.

“Why is all of this so complicated?”, is something Rachel hears a lot. It’s like all software. People want all the features, and they also want it to be easy to use.

More capability and flexibility means more to learn. But it’s worth remembering that you don’t have to learn everything at once. Once you switch your mindset to the grid way of thinking (where you define things on the layout) it gets easier. It’s all just lines.

If you name your grid lines, e.g. “content-start” and “content-end”, you automatically get a named area called “content.”

It works the other way around too. If you create an area called “content”, you automatically get lines named “content-start” and “content-end”.

You don’t have to use any of that. You have real choice for the first time.

A lot of the assumptions we’ve had in the past about what isn’t possible don’t hold up any more. You can now ask, “what’s the best way to do this?” instead of asking “which patterns does our framework give us?”

Well, that’s fine, you might be thinking, for shiny new things. But what if you’re building things that have an old codebase? Rachel asked “How old is the oldest CSS in your project?” in her survey. People have code that’s over ten years old. But old CSS in your codebase doesn’t mean you can’t use new CSS. You can design components or a section of a page using a new technique. This is where understanding CSS comes in really useful—the cascade, especially.

Rachel shows an example of a page made with Bootstrap. She drops a grid component into that layout. It works fine. Nothing explodes. They coexist side by side.

You can create systems with new layout. You’ve got a lot of choice. You can start to make decisions about which layout method works best for different situation. Other layout methods still exist. Don’t try to recreate floats within grid—just use floats. It’s like when we moved from tables for layout, some people went too far and stopped using tables for tabular data. If you need content to flow around an element, float that element. Likewise, if you’re doing layout in just one dimension, you don’t have to use grid; use flexbox.

Off-the-shelf frameworks are designed to solve generic problems. We end up solving problems we don’t have. Do you want your project to inherit the CSS problems of the rest of the world? Solving your specific problems only will result in lighter, easier to understand code.

You don’t need to lean on somebody else’s framework to get reusable code for your project and your team.

What about working with less capable browsers? (these may not always be old browsers). Let’s go back to 2006 and Yahoo’s graded browser support matrix. It was updated quarterly. It was useful. A lot of discussion around browser support was happening with a lack of understanding on one side (bosses, clients) meeting a lack of confidence on the other (developers). Yahoo’s browser support matrix gave us ammunition. If it was okay for Yahoo to say that it was okay for certain browsers to not receive certain features, then that argument was easier to make.

A lot of the discussion now is about older Internet Explorer—IE11 comes up a lot. If IE10 and 11 are your oldest supported versions, you can use the ms- prefixed grid layout.

Some people are using devices that aren’t updating to new browsers. UC browser for Android is used a lot. It’s very popular in India (35% usage). Many browsers without grid support are mobile browsers, popular in areas where data is expensive.

People want a magical grid polyfill that will make grid work in non-supporting browsers. Please stop asking for that! Why, oh, why would you send more JavaScript to less-capable devices!

You can use feature queries to ask if a browser supports a feature before using it. The great thing about doing this is that you are future-proofing: as browsers get support for features, your code works automatically.

You can create complex layouts for browsers that support them with a few lines of CSS. Being able to do new cool stuff is great. Saving developer time is great. But making the web available to everyone …that’s exciting!

To wrap up, Rachel recounts some of the other responses to her survey. People said they were “Excited!”

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

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.

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

Resilience retires

I spoke at the GOTO conference in Berlin this week. It was the final outing of a talk I’ve been giving for about a year now called Resilience.

Looking back over my speaking engagements, I reckon I must have given this talk—in one form or another—about sixteen times. If by some statistical fluke or through skilled avoidance strategies you managed not to see the talk, you can still have it rammed down your throat by reading a transcript of the presentation.

That particular outing is from Beyond Tellerrand earlier this year in Düsseldorf. That’s one of the events that recorded a video of the talk. Here are all the videos of it I could find:

Or, if you prefer, here’s an audio file. And here are the slides but they won’t make much sense by themselves.

Resilience is a mixture of history lesson and design strategy. The history lesson is about the origins of the internet and the World Wide Web. The design strategy is a three-pronged approach:

  1. Identify core functionality.
  2. Make that functionality available using the simplest technology.
  3. Enhance!

And if you like that tweet-sized strategy, you can get it on a poster. Oh, and check this out: Belgian student Sébastian Seghers published a school project on the talk.

Now, you might be thinking that the three-headed strategy sounds an awful lot like progressive enhancement, and you’d be right. I think every talk I’ve ever given has been about progressive enhancement to some degree. But with this presentation I set myself a challenge: to talk about progressive enhancement without ever using the phrase “progressive enhancement”. This is something I wrote about last year—if the term “progressive enhancement” is commonly misunderstood by the very people who would benefit from hearing this message, maybe it’s best to not mention that term and talk about the benefits of progressive enhancement instead: robustness, resilience, and technical credit. I think that little semantic experiment was pretty successful.

While the time has definitely come to retire the presentation, I’m pretty pleased with it, and I feel like it got better with time as I adjusted the material. The most common format for the talk was 40 to 45 minutes long, but there was an extended hour-long “director’s cut” that only appeared at An Event Apart. That included an entire subplot about Arthur C. Clarke and the invention of the telegraph (I’m still pretty pleased with the segue I found to weave those particular threads together).

Anyway, with the Resilience talk behind me, my mind is now occupied with the sequel: Evaluating Technology. I recently shared my research material for this one and, as you may have gathered, it takes me a loooong time to put a presentation like this together (which, by the same token, is one of the reasons why I end up giving the same talk multiple times within a year).

This new talk had its debut at An Event Apart in San Francisco two weeks ago. Jeffrey wrote about it and I’m happy to say he liked it. This bodes well—I’m already booked in for An Event Apart Seattle in April. I’ll also be giving an abridged version of this new talk at next year’s Render conference.

But that’s it for my speaking schedule for now. 2016 is all done and dusted, and 2017 is looking wide open. I hope I’ll get some more opportunities to refine and adjust the Evaluating Technology talk at some more events. If you’re a conference organiser and it sounds like something you’d be interested in, get in touch.

In the meantime, it’s time for me to pack away the Resilience talk, and wheel down into the archives, just like the closing scene of Raiders Of The Lost Ark. The music swells. The credits roll. The image fades to black.

Research on evaluating technology

I’ve spent the past few months preparing a new talk for An Event Apart San Francisco (and hopefully some more AEAs after that). As always happens, I spent the whole time vacillating between thinking “this is good!” and thinking “this is awful!” I’m still bouncing between those poles. I won’t really know whether the talk is up to snuff until I actually give it to a live audience.

Over the past few years, my presentations have built upon one another. Two years ago, my talk was called Enhance! and it set the groundwork for using a layered approach to web design and development. My 2016 talk, Resilience, follows on with a process and examples for that approach (I also set myself the challenge of delivering a talk about progressive enhancement without ever using the phrase “progressive enhancement”).

My new talk goes a bit meta, but in my mind, it’s very much building on the previous talks. The talk is all about evaluating technology. I haven’t settled on a final title, but I was thinking about something obtuse, like …Evaluating Technology.

Here’s my hastily scribbled description:

We work with technology every day. And every day it seems like there’s more and more technology to understand: graphic design tools, build tools, frameworks and libraries, not to mention new HTML, CSS and JavaScript features landing in browsers. How should we best choose which technologies to invest our time in? When we decide to weigh up the technology choices that confront us, what are the best criteria for doing that? This talk will help you evaluate tools and technologies in a way that best benefits the people who use the websites that we are designing and developing. Let’s take a look at some of the hottest new web technologies like service workers and web components. Together we will dig beneath the hype to find out whether they will really change life on the web for the better.

As ever, I’ll begin and end with a long-zoom pretentious arc of history, but I’ll dive into practical stuff in the middle. That’s become a bit of a cliché for my presentations, but the formula works as a sort of microcosm of a good conference—a mixture of the inspirational and the practical, trying to keep a good balance of both.

For this new talk, the practical focus will be on some web technologies that are riding high on the hype cycle right now: service workers, web components, progressive web apps. I’ll use them as a lens for applying broader questions about how we make decisions about the technologies we embrace, and the technologies we reject.

Technology. Now there’s a big subject. It’s literally the entirety of human history. I had to be careful not to go down too many rabbit holes. I’m still not sure if I’ve succeeded, but I’ve already had to ruthlessly cull some darlings.

One of the nice things that the An Event Apart crew started doing was to provide link lists for each talk to attendees. That gives me an opportunity to touch briefly on a topic in the talk itself, but allow any interested attendees to dive deeper at their leisure.

For this talk on evaluating technology, I’ve put together this list of hyperlinks for further reading, watching, listening, and researching…

People

Papers

Presentations

Books

Talking about hypertext

#CSSday starts off with a great history lesson of our industry by @adactio

I’ve just published a transcript of the talk I gave at the HTML Special that preceded CSS Day a couple of weeks back. I’ve also recorded an audio version for your huffduffing pleasure.

It’s not like the usual talks I give. The subject matter was assigned to me, Mission Impossible style. PPK wanted each speaker to give an entire talk on just one HTML element. He offered me the best element of them all: the A element.

There were a few different directions I could’ve taken it. I could’ve tried to make it practical, but I quickly dismissed that idea. Instead I went in the completely opposite direction, making it as pretentious as possible. I figured a talk about hypertext could afford to be winding and circuitous, building on some of the ideas I wrote about in my piece for The Manual a few years back. It’s quite self-indulgent of me, but I used it as an opportunity to geek out about some of my favourite things; from Borges, Babbage, and Bletchley to Leibniz, Lovelace, and Licklider.

I wouldn’t usually write out an entire talk word-for-word in advance, but somehow it felt right for this one. In fact, my talk preparation this time ‘round was very similar to the process Charlotte recently wrote about:

  1. Get everything out of my head and onto a mind map.
  2. Write chunks of content in short bursts—this was when I was buddying up with Paul.
  3. Put together a slide deck of visuals to support the narrative.
  4. Practice delivering the talk so I don’t look I’m just reading off a screen.

It takes me a long time to prepare talks. As the deadline for this one approached, I was getting quite panicked. It was touch and go there for a while, but I managed to get it done in time.

I’m pleased with how it turned out. On the day, I had fun delivering it. People seemed to like it too, which was gratifying.

Although with this kind of talk, it was inevitable that I wouldn’t be able to please everyone.

I guess this talk was a one-off affair. That said, if you’re putting on an event and you think this subject matter would be appropriate, let me know. I’d be more than happy to deliver it again.

Presentation

Rosa and Charlotte will both be speaking at Bytes Conf here in Brighton next week (don’t bother trying to get a ticket—it’s all sold out).

I’ve been helping them in their preparation, listening to them run through their talks, and offering bits of advice on the content and delivery. Charlotte said she was really nervous presenting to just the two of us. I said “I know what you mean.”

In the past I’ve tried giving practice run-throughs of upcoming conference talks to some of my co-workers at Clearleft. I always found that far more intimidating than giving the talk to room filled with hundreds of strangers.

In fact, just last night I did a practice run of my latest talk at Brighton’s excellent Async gathering, and seeing both Charlotte and Graham in attendance increased my nervousness.

Why is that?

I’ve been thinking about it, and I think it comes down to self-presentation.

We like to think that we have one single personality, but the truth is that we adjust our behaviour constantly to suit the situation. I behave differently when I’m interacting with a shopkeeper than when I’m interacting with my co-workers than when I’m interacting with my family. We adjust how we present ourselves, in subtle and not-so-subtle ways.

If you’re presenting a talk at a conference, it helps to present yourself differently than how you’d present yourself when you’re hanging out with your friends. There’s an element of theatricality—however subtle—in speaking in front of a room full of people. It can really help to slip into a more confident persona.

But if you’re presenting that same talk in a small room to a group of friends, it feels really, really strange to slip into that persona. It feels as strange as interacting with your family as though you were interacting with a shopkeeper.

I think that’s what’s at the root of the discomfort I feel when I try testing a talk on my co-workers. If I present myself in the informal mode I’d usually take with these people, the talk feels all wrong. But if I present myself in my stage persona, it feels weird to do that with these people. So either way, it’s going to feel really strange. Hence the nervousness.

Thing is …I’m not sure if being aware of this helps in any way.

Whatever works for you

I was one of the panelists on the most recent episode of the Shop Talk Show along with Nicole, Colin Megill, and Jed Schmidt. The topic was inline styles. Well, not quite. That’s not a great term to describe the concept. The idea is that you apply styling directly to DOM nodes using JavaScript, instead of using CSS selectors to match up styles to DOM nodes.

It’s an interesting idea that I could certainly imagine being useful in certain situations such as dynamically updating an interface in real time (it feels a bit more “close to the metal” to reflect the state updates directly rather than doing it via class swapping). But there are many, many other situations where the cascade is very useful indeed.

I expressed concern that styling via JavaScript raises the barrier to styling from a declarative language like CSS to a programming language (although, as they pointed out, it’s more like moving from CSS to JSON). I asked whether it might not be possible to add just one more layer of abstraction so that people could continue to write in CSS—which they’re familiar with—and then do JavaScript magic to match those selectors, extract those styles, and apply them directly to the DOM nodes. Since recording the podcast, I came across Glen Maddern’s proposal to do exactly that. It makes sense to me try to solve the perceived problems with CSS—issues of scope and specificity—without asking everyone to change the way they write.

In short, my response was “hey, like, whatever, it’s cool, each to their own.” There are many, many different kinds of websites and many, many different ways to make them. I like that.

So I was kind of surprised by the bullishness of those who seem to honestly believe that this is the way to build on the web, and that CSS will become a relic. At one point I even asked directly, “Do you really believe that CSS is over? That all styles will be managed through JavaScript from here on?” and received an emphatic “Yes!” in response.

I find that a little disheartening. Chris has written about the confidence of youth:

Discussions are always worth having. Weighing options is always interesting. Demonstrating what has worked (and what hasn’t) for you is always useful. There are ways to communicate that don’t resort to dogmatism.

There are big differences between saying:

  • You can do this,
  • You should do this, and
  • You must do this.

My take on the inline styles discussion was that it fits firmly in the “you can do this” slot. It could be a very handy tool to have in your toolbox for certain situations. But ideally your toolbox should have many other tools. When all you have is a hammer, yadda, yadda, yadda, nail.

I don’t think you do your cause any favours by jumping straight to the “you must do this” stage. I think that people are more amenable to hearing “hey, here’s something that worked for me; maybe it will work for you” rather than “everything you know is wrong and this is the future.” I certainly don’t think that it’s helpful to compare CSS to Neanderthals co-existing with JavaScript Homo Sapiens.

Like I said on the podcast, it’s a big web out there. The idea that there is “one true way” that would work on all possible projects seems unlikely—and undesirable.

“A ha!”, you may be thinking, “But you yourself talk about progressive enhancement as if it’s the one try way to build on the web—hoisted by your own petard.” Actually, I don’t. There are certainly situations where progressive enhancement isn’t workable—although I believe those cases are rarer than you might think. But my over-riding attitude towards any questions of web design and development is:

It depends.

100 words 060

I spent the day in Greenwich, where there were two different web conferences happening simultaneously—Clearleft’s own UX London, and the annual Talk Web Design conference for web students at the University of Greenwich.

I was bouncing between both events, which meant I never really got immersed in either one. But that’s okay. I managed to meet up with plenty of people at both.

There was one unmissable talk today: Charlotte’s public speaking debut, opening up Talk Web Design with a presentation about her transition from student life to working at Clearleft. It was great. I knew it would be.

Microsoft in London

Microsoft threw an invite-only gathering at its London offices: something about start-ups and Web 2.0. For some reason, I was asked along. Myself, Andy and Simon got on an early-morning train from Brighton to Victoria from whence we shuffled our way down the street to the glass lair of the Redmond giant. Once there, we were ushered into a room to listen to a series of talks.

For me, the whole day was like an anthropological exercise. I was getting a glimpse into a strange alien world of business plans and venture capital—the kind of stuff that I normally have no contact with. Here are the notes I took…

Lars Lindstedt, Microsoft

Here’s a bunch of Arial-filled slides.

Microsoft research labs, like the one in Cambridge, produce swathes of intellectual property that gets licensed to selected partners in the UK. Whoop-de-doo.

There’s a disparity between developed and developing worlds. Technology should be able to help (not if you’re demanding money for IP, it won’t).

Those crazy kids on Bebo who aren’t watching TV should be out kicking a ball around. Point is, it’s not just about a web browser on a PC: it’s about multiple channels.

And now, a graph. It slopes downwards from left to right therefore it must be showing something bad. It’s the UK labour productivity rate. Software increases labour productivity apparently.

All this Arial is making my eyes hurt.

Brent Hoberman, lastminute.com

What made lastminute.com successful? A great original idea. Outrageous ambition. ‘Cause this is meant to be fun and exciting.

Go after a huge market (so much for the long tail). The Web is a market where technology can really help.

When you get a good idea it seems so blindingly obvious that your first reaction is “surely somebody has done this already?” The second reaction you want is when you describe it to people and they say that they would want to use your service.

Then you’ve got to execute your idea. It’s really hard. Each individual slice of what you do is fairly easy to replicate but putting it all together is like a puzzle. You’ve got to balance supply and demand and marketing.

Speaking of marketing, how do you create buzz? Look at people like Facebook and Bebo (Bebo again?) who haven’t spent a penny on marketing. How do you distill that? Sure, luck is a big part of that but there are things you can do. For example, user interface is so important. The new marketing is just to make your product so good that you don’t have to shout about it. Cut the marketing budget in half and put that back into differentiating the product. Invest in tools that customers can use that are better and easier to use than anyone elses.

Brent’s new startup was born out of personal experience of frustration with interior decorating or something like that. Forget about market research. It’s just justification for somebody’s job. Your business should have a culture where failing is okay. Fail quick and fast so that you learn from your mistakes. Big companies have cultures of fear and consensus.

The hardest bit is the interface between business and technology, getting those people to talk to each other. You can’t just write down an idea and hand it over to the tech guys and get them to give you an estimate. Break it down and find out where the bottlenecks are and take them out. In small companies, you can have that dialogue. But big companies have so many layers that it’s hard to communicate.

Beware of data. As an ex-consultant, Brent knows how data is used to justify what the boss wants to hear. But do harvest as much data as you can about what your customers are doing. His biggest fear with his new project is that he’s sure he won’t get it right the first time. But the key thing is that his team is excited to react to what customers are doing so it will get better quickly.

There’s time for some questions.

Question: What are the differences between US and UK business attitudes?

The UK is actually a great place to do business even though there is something in the British psyche that is more cautious and less gung-ho. The media, who are quite important, are kind of schizophrenic—they promote stuff but at the same time, they love to see people fail.

Question: What are the problems associated with growth?

Innovation can go out the window. You get stuck in marketing (wasting money on TV) and fixing things rather than adding new features. Before launch, write down all those great ideas you’ve all got so that you can revisit them later because you won’t have time to think about this stuff after you launch.

Question: How did you survive the bust?

It made things less fun. Focus on the business even when everyone is telling you it won’t work. Stick to your guns. And don’t forget, outragous ambition will keep everyone on your team excited.

Question: What current trends to you see?

Customers are using better, quicker, more advanced tools; like uploading video to the Web, for example. Mobile was overestimated in the past but in the long term, it is very important. Social networks are powerful. You don’t want to launch a business that’s just a social network but it can be a prominent part of your service. Getting customers to do your work for you is exciting.

Question: Is content still king?

Building great tools so that customers can create content is great. Blending professional content with user-generated content is also great.

Question: Hire superstars or mold them?

Hire primadonnas. Put together a great team and then keep them. Molding them is very hard.

Question: How do you incubate innovation at a big company?

Stop obsessing about return on investment. Have some people who are allowed follow their instincts. The tricky thing is marrying that up with your market. Have a nutcase CEO like Jeff Bezos.

Steve Balmer, Microsoft CEO

Let’s talk about the evolution of software.

The first question that’s often asked is “What do you mean?”

Oh, the sentence continues, “…when you say software plus services.”

Well, here are some more Arial-rich slides.

There’s desktop, servers, online and devices. Each of these models has its advantages:

  • The desktop PC allows most control for the user.
  • Server (or “enterprise”) computing is good for security.
  • People love the internet; just click and run with no intallations.
  • Devices… um.

Ooh, Brent’s phone is ringing now, as if on cue. Glare, Steve, glare.

There’s a bunch of different user interfaces from the richness of the desktop to the reach of web apps, and there’s handwriting and voice recognition on devices. Not everything needs to be a web app or a Silverlight app. Office has some new online capabilities but that doesn’t make it a web app.

Then there’s enterprise stuff (I’m going to have to take a break from note-taking to tick off a bunch of squares on the Buzzword Bingo I’ve got open in my browser window).It’s all about cloud services apparently. It sounds like the stuff that Amazon are already doing. Ooh, he just said that! It’s like he knows what I’m thinking.

Mashups live at this REST level which is simple and easy and great. But we want sophistication and security apparently so forget that stuff—Microsoft have got a great model for talking to Windows-based clients, browsers and Silverlight. Let’s have a product demo from Mark.

Mark (didn’t catch his last name)

Let’s look at some tools with cool-sounding names. Here’s a Sliverlight flight-planning app. Having a plane whizz around a page is more compelling than text it seems.

Steve interrupts to say something about richness.

Back to Mark. This has reach; Windows, Mac, DRM (he snuck that last one in there quite cleverly).

Popfly is a mashup for consumers with a Silverlight UI. Here’s a Flickr component (of course! what mashup demo would be complete without an example that uses the Flickr API?). Mash it up with Virtual Earth. Page-turning animations are also an option. Ahem. Anyway, it’s about lowering the barriers to entry for people to make mashups.

Now what’s this? Looks like a barcode. Zoom in and it’s actually the complete works of Charles Dickens. Zooooom right in on one word. Applause! It’s a monstrous amount of data. This is Seadragon. No matter how big your data and objects are, you should be able to seamlessly flow into it.

There’s another zooming tool: Photosynth. Here’s the Venice example; a 3D model created from people’s photos. Zoom right in. Look, it’s Stephen Hawking on holiday.

Back to Balmer

The emphaisis is on seamlessness.

Uh-oh. Slide problems. Lars comes to the rescue and starts closing a bunch of windows ‘till we’re back to Powerpoint plus Arial.

Here’s a list of “services” and “partner opportunities.” The titles are so unsnappy I’ve forgotten them already. Most of them end with the word “Live” (like advertising a good seedy strip club). I think he’s starting to bore himself now.

There’s a bunch of partner programs. The startup accelerator program begins in the UK as of today. Talk to Lars for more.

Here’s the key point before questions from the audience: there’s been an incredible evolution in software. The model of what we do in creating software is morphing in incredible ways. We have to keep pace with that.

Question: What’s the future of consumer software? Ads?

A lot of things will be ad-funded. People don’t like paying for things. But some things are too expensive to be delivered through advertising and others where advertising is too invasive and painful. For example, basic internet connectivity won’t be ad-funded. Online publications, on the other hand, probably will. There’ll be a mix of things.

Question: want to talk about open source?

Microsoft believes in a commerical model; that’s how they can rent out this space we’re sitting in. But there’s room for different models. Microsoft’s strategy is to compete when they have open-source competitors. It would be great to see open-source innovations happening on top of Windows. The battle isn’t business model to business model: it’s product to product. Microsoft also pays a bunch of lawyers to buy IP and sue the ass off people. Open source people should play along and pay Microsoft money. That would be an IP framework (man, that’s some flavour of bullshit he’s spinning).

Simon Willison: This event is about startups but these days you can’t build anything without patents but you can’t buy patents unless you’re one of the big boys. Should there be a reform?

The patent system is pretty good but it needs overhauling. It’s unclear who benefits more from the current patent regime; the small company or the big company. Probably the small company (huh?). The bigger issue is how unpredictable the current system is. Who qualifies? How do you know about this stuff? The system was designed for mechanical things but now it needs to be reformed for software in the same way it was for the pharma industry (yikes! that’s some precedent to mention).

Question: Does Microsoft have any plans to support startups with revenue-linked licensing plans?

Microsoft have looked at that like the big guys have done (like Sun) but Microsoft’s stuff tends to be a lot cheaper.

The questioner interrupts to talk about SQL quad processing stuff, yadda yadda.

Any other questions, write to steveb@microsoft.com.

And with that, he exits stage right and out the door.

Panel discussion with Saul Klein , Ben Way and Cary Marsh , moderated by Ryan Carson

Ryan: Cary, you’re in a crowded market—online video—how do you compete?

Cary: We made a lot of mistakes. We should have provided a free trial and subscription services. We burned through a lot but we learned from that.

Ryan: Saul, you also run Seedcamp. How do the companies that get €50K use that money?

Saul: We ended up funding six business. The first six months are critical. You probably won’t be paying people, you’ll be motivating them through stock (Bwah-ha-ha!… Oh. He’s serious). You can use Amazon’s services to save money. It’s all about conserving capital and managing cost. You’ll always need more money than you’ve got. Do you need an office? Can you work in your living room?

Ryan: Ben, what tips can you give Web startups?

Ben: Don’t be afraid of making mistakes. Here in the UK, we are quite risk-averse. I failed when I was younger and I was scared of telling people but now I use it to my advantage. The other important factor is people, the people you choose to work with. Key people in key roles is… key.

Question: An article in The Guardian says that startups should act like mega-corporations. Is that at odds with what you guys are saying?

Ben: There’s a balance to be had. You’ve got to be innovative and fast on your feet but you’ve also got to keep an eye on your cashflow.

Saul: There’s nothing wrong with thinking big. You should think that you can be as big as Google or Microsoft. But that doesn’t mean you should spend money like them. That article sounds crazy to me.

Ryan: Anything good that’s happened to our business is because of relationships with people, not how big or small we are or appear.

Ryan: Saul, how are Seedcamp companies generating publicity?

Saul: Publicity is the beginning of a wider conversation you can have with your customers. Start blogging. Reach out to other people in your community like influental bloggers. The blogosphere is your first PR tool. There are blogs like Techcrunch and Read/Write Web that cover startups. But the most important thing is to start having conversations with the people who are relevant to your community.

Ryan: Ben, what’s been your biggest mistake in spending money on marketing?

Ben: The biggest mistakes come when you get a lot of money in the bank and you feel you must spend it. You get so used to not having money that when you get some, you go crazy. That can be an issue with VC funding. A cashflow situation would be better.

Ryan: Cary, can you share with us how much you spend on marketing?

Cary: Nothing apart from some ad words. Getting rid of the “business development” person and just getting a PA for myself, so that I can talk about this stuff passionately, was a great move.

Question: Cary, how do partnerships work out?

Cary: We’ve got a big partnership with Microsoft Windows Movie Maker. That made us global. Microsoft can introduce you to a lot of people. It’s difficult as a startup to knock on doors but if you have a big partner, they can help you.

Question: Saul, when is the right time for a company to raise finance?

Saul: People focus on the money aspect of financing but the people side of things is also important. You’ve got to get along with the investors. Early on, you can identify those people. They can give you advice and credibility when it comes to raising venture money. Raising venture is an important watershed moment for every company and it’s not necessarily right for every company. Try to find the right people first and they will find the right kind of money for you.

Ryan: I see a lot of people starting Web apps that aren’t skyrocketing but they’re doing okay. How do you know when you’ve failed or when you’re succeeding?

Ben: For me, I’m so passionate about an idea that I’d have to hit rock-bottom to give up on it. Honestly, a true entrepeneur keeps going until they can’t go on any more.

Cary: I agree. The one thing that all sucessful companies have is that they never gave up. You’ve got to be so focused but also flexible—be prepared to change and adapt.

Question: How do you maximize your shares when you go and get VC money?

Much mumbling from the audience; this is clearly a contraversial point. But I don’t understand any of it.

Saul: If you want ownership, you’re going to want the best people working with you and the best people investing in you. There’s no magic answer but I’d prefer to have a small share in Google than a very large share in a small company. I think the first fifty people in companies are co-founders, whether they’re called co-founders or not. Be generous with them.

And with that, the event wraps up and we all shuffle out for some sandwiches, sushi, coffee and water (from Microsoft branded bottles). There are a lot of people in suits but like water finding its own level, I end up chatting with Mike Stenhouse and Matt Webb.

Apropos of Mike’s pale skin, Matt looks out at the miserable London weather and comes up with a great idea: umbrellas that have UV lamps built in so that every time it rains, you get a tan.

Now that’s a startup worth funding.