Tags: aeasf



Tuesday, October 25th, 2022


Speaking of in-person gatherings, I’ve got some exciting—if not downright nervewracking—events coming up soon.

Next week I’ll be in London for Leading Design. Looking at the line-up that Rebecca is assembled, I’m kind of blown away—it looks fantastic!

You’ll notice that I’m in that line-up, but don’t worry—I’m not giving a talk. I’ll be there as host. That means I get to introduce the speakers before they speak, and ask them a question or two afterwards.

Then, one week later, I do it all again at Clarity in New Orleans. I’m really honoured that Jina has invited me to MC. Again, it’s a ridiculously fantastic line-up (once you ignore my presence).

I really, really enjoy hosting events. And yet I always get quite anxious in the run-up. I think it’s because there isn’t much I can do to prepare.

During The Situation, I had something of an advantage when I was hosting UX Fest. The talks were pre-recorded, which meant that I could study them ahead of time. At a live event, I won’t have that luxury. Instead, I need to make sure that I pay close attention to each talk and try to come up with good questions.

Based on past experience, my anxiety is unwarranted. Once I’m actually talking to these super-smart people, the problem isn’t a lack of things to discuss, but the opposite—so much to talk about in so little time!

I keep trying to remind myself of that.

See, it’s different if I’m speaking at an event. Sure, I’ll get nervous, but I can do something about it. I can prepare and practice to alleviate any anxiety. I feel like I have more control over the outcome when I’m giving a talk compared with hosting.

In fact, I do have a speaking gig on the horizon. I’ll be giving a brand new talk at An Event Apart in San Francisco in December.

It was just a month ago when Jeffrey invited me to speak. Of course I jumped at the chance—it’s always an honour to be asked—but I had some trepidation about preparing a whole new talk in time.

I’ve mentioned this before but it takes me aaaaaaaages to put a talk together. Don’t get me wrong; I think it’s worth it. I may not be good at much, but I know I can deliver a really good conference talk …once I’ve spent ridiculously long preparing it.

But more recently I’ve noticed that I’ve managed to shorten this time period. Partly that’s because I recklessly agree to prepare the talk in a shorter amount of time—nothing like a deadline to light a fire under my ass. But it’s also because a lot of the work is already done.

When I have a thought or an opinion about something, I write it down here on my own website. They’re brain farts, but their my brain farts. I consider them half-baked, semi-formed ideas.

For a conference talk, I need something fully-baked and well-formed. But I can take a whole bunch of those scrappy blog posts and use them as raw material.

There’s still a lot of work involved. As well as refining the message I want to get across, I have to structure these thoughts into a narrative thread that makes sense. That’s probably the hardest part of preparing a conference talk …and the most rewarding.

So while I’ve been feeling somewhat under the gun as I’ve been preparing this new talk for An Event Apart, I’ve also been feeling that the talk is just the culmination; a way of tying together some stuff I’ve been writing about it here for the past year or two.

It’s still entirely possible that the talk could turn out to be crap, but I think the odds are in my favour. I’ve been able to see how the ideas I’ve been writing about have resonated with people, so I can feel pretty confident that they’ll go down well in a talk.

As for the topic of the talk? All will be revealed.

Monday, December 16th, 2019

Liveblogging An Event Apart 2019

I was at An Event Apart in San Francisco last week. It was the last one of the year, and also my last conference of the year.

I managed to do a bit of liveblogging during the event. Combined with the liveblogging I did during the other two Events Apart that I attended this year—Seattle and Chicago—that makes a grand total of seventeen liveblogged presentations!

  1. Slow Design for an Anxious World by Jeffrey Zeldman
  2. Designing for Trust in an Uncertain World by Margot Bloomstein
  3. Designing for Personalities by Sarah Parmenter
  4. Generation Style by Eric Meyer
  5. Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew
  6. Designing Intrinsic Layouts by Jen Simmons
  7. How to Think Like a Front-End Developer by Chris Coyier
  8. From Ideation to Iteration: Design Thinking for Work and for Life by Una Kravets
  9. Move Fast and Don’t Break Things by Scott Jehl
  10. Mobile Planet by Luke Wroblewski
  11. Unsolved Problems by Beth Dean
  12. Making Research Count by Cyd Harrell
  13. Voice User Interface Design by Cheryl Platz
  14. Web Forms: Now You See Them, Now You Don’t! by Jason Grigsby
  15. The Weight of the WWWorld is Up to Us by Patty Toland
  16. The Mythology of Design Systems by Mina Markham
  17. The Technical Side of Design Systems by Brad Frost

For my part, I gave my talk on Going Offline. Time to retire that talk now.

Here’s what I wrote when I first gave the talk back in March at An Event Apart Seattle:

I was quite nervous about this talk. It’s very different from my usual fare. Usually I have some big sweeping arc of history, and lots of pretentious ideas joined together into some kind of narrative arc. But this talk needed to be more straightforward and practical. I wasn’t sure how well I would manage that brief.

I’m happy with how it turned out. I had quite a few people come up to me to say how much they appreciated how I was explaining the code. That was very nice to hear—I really wanted this talk to be approachable for everyone, even though it included plenty of JavaScript.

The dates for next year’s Events Apart have been announced, and I’ll be speaking at three of them:

The question is, do I attempt to deliver another practical code-based talk or do I go back to giving a high-level talk about ideas and principles? Or, if I really want to challenge myself, can I combine the two into one talk without making a Frankenstein’s monster?

Come and see me at An Event Apart in 2020 to find out.

Wednesday, December 11th, 2019

The Technical Side of Design Systems by Brad Frost

Day two of An Event Apart San Francisco is finishing with a talk from Brad on design systems (so hot right now!):

You can have a killer style guide website, a great-looking Sketch library, and robust documentation, but if your design system isn’t actually powering real software products, all that effort is for naught. At the heart of a successful design system is a collection of sturdy, robust front-end components that powers other applications’ user interfaces. In this talk, Brad will cover all that’s involved in establishing a technical architecture for your design system. He’ll discuss front-end workshop environments, CSS architecture, implementing design tokens, popular libraries like React and Vue.js, deploying design systems, managing updates, and more. You’ll come away knowing how to establish a rock-solid technical foundation for your design system.

I will attempt to liveblog the Frostmeister…

“Design system” is an unfortunate name …like “athlete’s foot.” You say it to someone and they think they know what you mean, but nothing could be further from the truth.

As Mina said:

A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.

A design system the story of how an organisation gets things done.

When Brad talks to companies, he asks “Have you got a design system?” They invariably say they do …and then point to a Sketch library. When the focus goes on the design side of the process, the production side can suffer. There’s a gap between the comp and the live site. The heart and soul of a design system is a code library of reusable UI components.

Brad’s going to talk through the life cycle of a project.


He begins with selling in a design system. That can start with an interface inventory. This surfaces visual differences. But even if you have, say, buttons that look the same, the underlying code might not be consistent. Each one of those buttons represents time and effort. A design system gives you a number of technical benefits:

  • Reduce technical debt—less frontend spaghetti code.
  • Faster production—less time coding common UI components and more time building real features.
  • Higher-quality production—bake in and enforce best practices.
  • Reduce QA efforts—centralise some QA tasks.
  • Potentially adopt new technologies faster—a design system can help make additional frameworks more managable.
  • Useful reference—an essential resource hub for development best practices.
  • Future-friendly foundation—modify, extend, and improve over time.

Once you’ve explained the benefits, it’s time to kick off.

Kick off

Brad asks “What’s yer tech stack?” There are often a lot of tech stacks. And you know what? Users don’t care. What they see is one brand. That’s the promise of a design system: a unified interface.

How do you make a design system deal with all the different tech stacks? You don’t (at least, not yet). Start with a high priority project. Use that as a pilot project for the design system. Dan talks about these projects as being like television pilots that could blossom into a full season.


Where to build the design system? The tech stack under the surface is often an order of magnitude greater than the UI code—think of node modules, for example. That’s why Brad advocates locking off that area and focusing on what he calls a frontend workshop environment. Think of the components as interactive comps. There are many tools for this frontend workshop environment: Pattern Lab, Storybook, Fractal, Basalt.

How are you going to code this? Brad gets frontend teams in a room together and they fight. Have you noticed that developers have opinions about things? Brad asks questions. What are your design principles? Do you use a CSS methodology? What tools do you use? Spaces or tabs? Then Brad gets them to create one component using the answers to those questions.

Guidelines are great but you need to enforce them. There are lots of tools to automate coding style.

Then there’s CSS architecture. Apparently we write our styles in React now. Do you really want to tie your CSS to one environment like that?

You know what’s really nice? A good ol’ sturdy cacheable CSS file. It can come in like a fairy applying all the right styles regardless of tech stack.

Design and build

Brad likes to break things down using his atomic design vocabulary. He echoes what Mina said earlier:

Embrace the snowflakes.

The idea of a design system is not to build 100% of your UI entirely from components in the code library. The majority, sure. But it’s unrealistic to expect everything to come from the design system.

When Brad puts pages together, he pulls in components from the code library but he also pulls in one-off snowflake components where needed.

The design system informs our product design. Our product design informs the design system.


Brad has seen graveyards of design systems. But if you make a virtuous circle between the live code and the design system, the design system has a much better chance of not just surviving, but thriving.

So you go through those pilot projects, each one feeding more and more into the design system. Lather, rinse, repeat. The first one will be time consuming, but each subsequent project gets quicker and quicker as you start to get the return on investment. Velocity increases over time.

It’s like tools for a home improvement project. The first thing you do is look at your current toolkit. If you don’t have the tool you need, you invest in buying that new tool. Now that tool is part of your toolkit. Next time you need that tool, you don’t have to go out and buy one. Your toolkit grows over time.

The design system code must be intuitive for developers using it. This gets into the whole world of API design. It’s really important to get this right—naming things consistently and having predictable behaviour.

Mina talked about loose vs. strict design systems. Open vs. locked down. Make your components composable so they can adapt to future requirements.

You can bake best practices into your design system. You can make accessibility a requirement in the code.


What does it mean to “launch” a design system?

A design system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.

—Nathan Curtis

There’s a spectrum of integration—how integrated the design system is with the final output. The levels go from:

  1. Least integrated: static.
  2. Front-end reference code.
  3. Most integrated: consumable compents.

Chris Coyier in The Great Divide talked about how wide the spectrum of front-end development is. Brad, for example, is very much at the front of the front end. Consumable UI components can create a bridge between the back of the front end and the front of the front end.

Consumable UI components need to be bundled, packaged, and published.


Now we’ve entered a new mental space. We’ve gone from “Let’s build a website” to “Let’s maintain a product which other products use as a dependency.” You need to start thinking about things like semantic versioning. A version number is a promise.

A 1.0.0 designation comes with commitment. Freewheeling days of unstable early foundations are behind you.

—Nathan Curtis

What do you do when a new tech stack comes along? How does your design system serve the new hotness. It gets worse: you get products that aren’t even web based—iOS, Android, etc.

That’s where design tokens come in. You can define your design language in a platform-agnostic way.


This is hard.

  • Your design system must live in the technologies your products use.
  • Look at your product roadmaps for design system pilot project opportunities.
  • Establish code conventions and use tooling and process to enforce them.
  • Build your design system and pilot project UI screens in a frontend workshop environment.
  • Bake best practices into reusable components & make them as rigid or flexible as you need them to be.
  • Use semantic versioning to manage ongoing design system product work.
  • Use design tokens to feed common design properties into different platforms.

You won’t do it all at once. That’s okay. Baby steps.

Tuesday, December 10th, 2019

The Mythology of Design Systems by Mina Markham

It’s day two of An Event Apart San Francisco. The brilliant Mina Markham is here to talk to us about design systems (so hot right now!). I’m going to attempt to liveblog it:

Design systems have dominated web design conversations for a few years. Just as there’s no one way to make a website, there is no one way to make a design system. Unfortunately this has led to a lot of misconceptions around the creation and impact of this increasingly important tool.

Drawing on her experiences building design systems at two highly visible and vastly different organizations, Mina will debunk some common myths surrounding design systems.

Mina is a designer who codes. Or an engineer who designs. She makes websites. She works at Slack, but she doesn’t work on the product; she works on slack.com and the Slack blog. Mina also makes design systems. She loves design systems!

There are some myths she’s heard about design systems that she wants to dispel. She will introduce us to some mythological creatures along the way.

Myth 1: Designers “own” the design system

Mina was once talking to a product designer about design systems and was getting excited. The product designer said, nonplussed, “Aren’t you an engineer? Why do you care?” Mina explained that she loved design systems. The product designer said “Y’know, design systems should really be run by designers” and walked away.

Mina wondered if she had caused offense. Was she stepping on someone’s toes? The encounter left her feeling sad.

Thinking about it later, she realised that the conversation about design systems is dominated by product designers. There was a recent Twitter thread where some engineers were talking about this: they felt sidelined.

The reality is that design systems should be multi-disciplinary. That means engineers but it also means other kinds of designers other than product designers too: brand designers, content designers, and so on.

What you need is a hybrid, or unicorn: someone with complimentary skills. As Jina has said, design systems themselves are hybrids. Design systems give hybrids (people) a home. Hybrids help bring unity to an organization.

Myth 2: design systems kill creativity

Mina hears this one a lot. It’s intertwined with some other myths: that design systems don’t work for editorial content, and that design systems are just a collection of components.

Components are like mermaids. Everyone knows what one is supposed to look like, and they can take many shapes.

But if you focus purely on components, then yes, you’re going to get frustrated by a feeling of lacking creativity. Mina quotes @brijanp saying “Great job scrapbookers”.

Design systems encompass more than components:

  • High level principles.
  • Brand guidelines.
  • Coding standards.
  • Accessibility compliance.
  • Governance.

A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.


Rules and creativity are not mutually exclusive. Rules can be broken.

For a long time, Mina battled against one-off components. But then she realised that if they kept coming up, there must be a reason for them. There is a time and place for diverging from the system.

It’s like Alice Lee says about illustrations at Slack:

There’s a time and place for both—illustrations as stock components, and illustrations as intentional complex extensions of your specific brand.

Yesenia says:

Your design system is your pantry, not your cookbook.

If you keep combining your ingredients in the same way, then yes, you’ll keep getting the same cake. But if you combine them in different ways, there’s a lot of room for creativity. Find the key moments of brand expression.

There are strict and loose systems.

Strict design systems are what we usually think of. AirBnB’s design system is a good example. It’s detailed and tightly controlled.

A loose design system will leave more space for experimentation. TED’s design system consists of brand colours and wireframes. Everything else is left to you:

Consistency is good only insofar as it doesn’t prevent you from trying new things or breaking out of your box when the context justifies it.

Yesenia again:

A good design sytem helps you improvise.

Thinking about strict vs. loose reminds Mina of product vs. marketing. A design system for a product might need to be pixel perfect, whereas editorial design might need more breathing room.

Mina has learned to stop fighting the one-off snowflake components in a system. You want to enable the snowflakes without abandoning the system entirely.

A loose system is key for maintaining consistency while allowing for exploration and creativity.

Myth 3: a design system is a side project

Brad guffaws at this one.

Okay, maybe no one has said this out loud, but you definitely see a company’s priorities focused on customer-facing features. A design system is seen as something for internal use only. “We’ll get to this later” is a common refrain.

“Later” is a mythical creature—a phoenix that will supposedly rise from the ashes of completed projects. Mina has never seen a phoenix. You never see “later” on a roadmap.

Don’t treat your design system as a second-class system. If you do, it will not mature. It won’t get enough time and resources. Design systems require real investment.

Mina has heard from people trying to start design systems getting the advice, “Just do it!” It seems like good advice, but it could be dangerous. It sets you up for failure (and burnout). “Just doing it” without support is setting people up for a bad experience.

The alternative is to put it on the roadmap. But…

Myth 4: a design system should be on the product roadmap

At a previous company, Mina once put a design system on the product roadmap because she saw it wasn’t getting the attention it needed. The answer came back: nah. Mina was annoyed. She had tried to “just do it” and now when she tried to do it through the right channels, she’s told she can’t.

But Mina realised that it’s not that simple. There are important metrics she might not have been aware of.

A roadmap is multi-faceted thing, like Cerebus, the three-headed dog of the underworld.

Okay, so you can’t put the design sytem on the roadmap, but you can tie it to something with a high priority. You could refactor your way to a design system. Or you could allocate room in your timeline to slip in design systems work (pad your estimates a little). This is like a compromise between “Just do it!” and “Put it on the roadmap.”

A system’s value is realized when products ship features that use a system’s parts.

—Nathan Curtis

The other problem with putting a design system on the roadmap is that it implies there’s an end date. But a design system is never finished (unless you abandon it).

Myth 5: our system should do what XYZ’s system did

It’s great that there are so many public design systems out there to look to and get inspired by. We can learn from them. “Let’s do that!”

But those inspiring public systems can be like a succubus. They’re powerful and seductive and might seem fun at first but ultimately leave you feeling intimidated and exhausted.

Your design system should be build for your company’s specific needs, not Google’s or Github’s or anyone’s.

Slack has multiple systems. There’s one for the product called Slack Kit. It’s got great documentation. But if you go on Slack’s marketing website, it doesn’t look like the product. It doesn’t use the same typography or even colour scheme. So it can’t use the existing the design system. Mina created the Spacesuit design system specifically for the marketing site. The two systems are quite different but they have some common goals:

  • Establish common language.
  • Reduce technical debt.
  • Allow for modularity.

But there are many different needs between the Slack client and the marketing site. Also the marketing site doesn’t have the same resources as the Slack client.

Be inspired by other design systems, but don’t expect the same resutls.

Myth 6: everything is awesome!

When you think about design systems, everything is nice and neat and orderly. So you make one. Then you look at someone else’s design system. Your expectations don’t match the reality. Looking at these fully-fledged design systems is like comparing Instagram to real life.

The perfect design system is an angel. It’s a benevolent creature acting as an intermediary between worlds. Perhaps you think you’ve seen one once, but you can’t be sure.

The truth is that design system work is like laying down the railway tracks while the train is moving.

For a developer, it is a rare gift to be able to implement a project with a clean slate and no obligations to refactor an existing codebase.

Mina got to do a complete redesign in 2017, accompanied by a design system. The design system would power the redesign. Everything was looking good. Then slowly as the rest of the team started building more components for the website, unconnected things seemed to be breaking. This is what design systems are supposed to solve. But people were creating multiple components that did the same thing. Work was happening on a deadline.

Even on the Hillary For America design system (Pantsuit), which seemed lovely and awesome on the outside, there were multiple components that did the same thing. The CSS got out of hand with some very convoluted selectors trying to make things flexible.

Mina wants to share those stories because it sometimes seems that we only share the success stories.

Share work in progress. Learn out in the open. Be more vulnerable, authentic, and real.

Friday, August 29th, 2008

hCard Wizard

The microformats meetup in San Francisco after An Event Apart had quite a turnout. The gathering was spoiled only by Jenn getting her purse stolen. Two evenings earlier, Noel had been robbed at gunpoint. San Francisco wasn’t exactly showing its best side.

Still, the microformats meetup was a pleasant get-together. Matthew Levine pulled out his laptop and gave me a demo of the Lazy Web in action…

On the first day of An Event Apart, I twittered a reminder that my liveblogging posts were filled with hCards. Christian asked how I added the hCards and I replied that, while I just add them by hand, some kind of “wizard” for adding simple hCards to any textarea would be very welcome.

Less than 48 hours later, Matthew had whipped up exactly what I asked for. It’s a bookmarklet. Drag it to your bookmarks bar and click on it whenever you want to add a simple hCard. It uses JavaScript to create a faux window with a form where you are prompted to enter given name and family name. You can also add a middle name and a URL.

This is just a small subset of all the properties available in hCard so it isn’t suitable for detailed hCards. If you’re creating the markup for a contact page, for example, you’d be better off with the hCard-o-matic. But this little bookmarklet easily hits 80% of the use cases for adding hCards within body text (like in a blog post, for example).

This is a first release and there will inevitably be improvements. The ability to add XFN values would be a real boon. Still… that’s really impressive work for something that was knocked together so quickly.

If you want to use the bookmarklet (regardless of what blogging engine or CMS you use), drag this to your bookmarks bar:

hCard Wizard

Wednesday, August 20th, 2008

An Event Apart, Day Two

The second day of An Event Apart San Francisco is drawing to a close. The day opened with my talk, Patterns in the Process. You can download the slides if you like—Creative Commons licensed, as usual—but just looking at the slides is like trying to listen to a presentation by putting a glass against the wall of the building next door.

When I was giving my talk, I thought it was kind of rambling and incoherent. But it went down well and lots of people told me they liked it afterwards so I’ll put my self-criticism away.

I was glad to have my talk over and done with. I was able to relax and enjoy the other presentations. The very high standard set on the first day was upheld. I was completely blown away by Jeff’s fantastic smörgåsbord of storytelling and data viz porn: I think I had a little design orgasm in my brain.

At one point during his talk, Jeff showed this very site! He then proceeded to show the style-switching in action by switching to the Zeldman theme …while I was sitting next to Zeldman! When I think back to ten years ago when I was reading Webmonkey and Ask Dr. Web, I never, ever, ever thought I would find myself in this situation.

I’ll be leaving San Francisco tomorrow with a warm glow and good memories. Before that, I’ll be heading to the microformats meetup at the food court of the Westfield Center this evening. If you’re around, maybe I’ll see you there.

Tuesday, August 19th, 2008

An Event Apart: San Francisco [Day 2]...live blogging

Wesley Hodgson liveblogged the talk I just gave at An Event Apart San Francisco — Patterns in the process.

An Event Apart, Day One

The first day of An Event Apart is wrapping up in San Francisco. The quality of talks has been outstanding. Now I’m really bricking it about my talk tomorrow morning. The bar has been set ridiculously high.

I’ve done my best to liveblog throughout the day. Inevitably there will be mistakes and omissions in these second-hand reports but here they are:

  1. Understanding Web Design by Jeffrey Zeldman
  2. The Lessons of CSS Frameworks by Eric Meyer
  3. Storytelling by Design by Jason Santa Maria
  4. Web Application Hierarchy by Luke W.
  5. Shepherding Passionate Users by Heather Champ
  6. The Framework Age by Liz Danzico
  7. Implementing Design: Bulletproof A-Z by Dan Cederholm

I’m kind of wiped out from all the typing. I probably won’t be able to manage a second day of liveblogging. I can’t wait to have my talk out the way and enjoy the rest of the speakers.

Implementing Design: Bulletproof A-Z

Dan Cederholm is in the house at An Event Apart San Francisco. He’s all about the bulletproofing.

Simplebits describe what they do as hand crafted pixels and text. This idea of craft, building something with your hands, is what Dan wants to concentrate on. It isn’t always obvious in web design how well-crafted a web site is. Dan will run through a case study that focus on three aspects of web design: being bulletproof, being adaptable and focusing on the details. Like progressive enhancement for JavaScript, Dan will be using Progressive Enrichment for CSS which really means using cool stuff that doesn’t work in IE.

The case study will be a site all about coffee called Iced or Hot (it doesn’t actually work).

  • A is for anchor links with meta information. If you’re going to put data inside links, think ahead to links with really long text.
  • B is for border-radius. This is progressive enrichment. Rounded corners are usually a pain in the ass. But you can do them today with namespaced webkit- and moz- border-radius declarations. Dan puts these vendor-specific properties into a separate stylesheet called enriched.css to keep them quarantined like hacks. What about other browsers? Well, they don’t get rounded corners but so what? Rounded corners just degrade gracefully to rectangles.
  • C is for colour transparency with RGBa. You could use opacity but that sets the transparency for an element and all its children. Giving colour values with RGBa (background-color: rgba(0,0,0.7);) you only set the opacity of the background. A PNG would reach more users but like border-radius, RGBa is great for prototyping.
  • D is for Do Websites Need To Look Exactly The Same In Every Browser? No!
  • D is also for decision-makers who get that. The example of the semi-transparent menus on the Sundance Festival site (made by Airbag) demonstrates this. IE just gets flat colours and that’s fine. Dan himself used generated content on Foamee to add images to the headlines. Browsers that don’t support generated content don’t get the ornaments and that’s fine.
  • E is for easy clearing of floats. There’s the classic clearfix solution but man, that’s a crappy class name to put in your markup. The alternative of creating a list of wrappers that you want to clear is as bad. Dan uses a class name of group.
  • F is for frameworks. We all use our own frameworks: the code you start from for each project.
  • G is for gridlasticness. From the latin Gridius Lastius Emius which means working with em-based grids. Dan shows some grid-based designs: Mark Boulton, CNN, Erskine. Then he gives a refresher in elastic layout. Em-based layouts force you to ensure ultimate flexibility. You have to think about font sizes, layout, margins and padding in ems. Richard’s 62.5% rule helps make the calculations easier. Set a max-width on elastic layouts (of 100%) you can make sure that the layout won’t go outside the viewport. On Iced or Hot, has four columns of 16em with a 2em gutter between them. The XScope tool is handy for checking your grid lines.
  • H is for horizontal grid? Sure. Vertical grid? Sort of. Here, Dan is talking about that annoying habit that visual designers have of lining everything perfectly on the top and bottom of element. It looks great in Photoshop but it bears no relation to reality. It’s like those people who make the pillows look perfect on the bed. It’s a waste of time because they’re just going to get messed up. But we can uses classes for groups of content so that there are break-points in the vertical layout.
  • I is for IE8 beta still refuses to resize text sized in pixels. WTF? We still need to use relative units for text sizes. Does page zoom change things? Who knows.
  • J is for jQuery. Spontaneous applause from the audience. Dan hates JavaScript and he normally doesn’t talk about it in presentations but jQuery makes his life easier. It uses the familiar CSS selector syntax.
  • K is for Kitty.
  • L is for .last. Dan is constantly having to put a class of .last on the last item in a list (for style reasons). You can use jQuery to add the class programatically. jQuery('ul.lst li:last'),addClass('last');
  • M
  • N
  • O
  • P
  • Q
  • R
  • S is for shifting backgrounds. Heeeeere’s Silverback! Parallax scrolling is a great example of craftmanship. Not everyone is going to see it but it’s a lovely added extra.
  • T is for a testimonial for reset.css.
  • U is for ur stats. When can we…? Drop support for X. Start using Y. Answer: when your site shows the stats to support that decision.

The alphabet ends with U.

The Framework Age

Liz Danzico is talking at An Event Apart San Francisco about frameworks. Not CSS frameworks, not JavaScript frameworks, not Rails, not Django, but websites as frameworks. These days we’re designing frameworks for user interaction rather than static artefacts.

Liz tells a story about Miles Davis who showed up at the studio with six slips of paper listing the six musicians he wanted to play with on his record. Over the course of one day, these people who had never played this music together recorded a whole album. Davis wanted to capture something called creative instability. Kind of Blue came out of this framework that he created.

Liz wants to talk about frameworks that are uninscribed and detectable cues that loosely govern a set of actions. These are interaction frameworks, frameworks that shape how people behave.

Back to music. Classical music uses classical notation. If you can’t read notation, you can’t make sense of it so it’s kind of elitist. It also provides rules like tempo and key. If you step outside these boundaries, you are deviating from the notation. Also, every note is accounted for in the notation. You can’t improvise it. Jazz notation is different. It provides chord progressions. It’s up to the musician to improvise around this framework. Modal jazz is even more abstract. That’s what Miles Davis invented that day in the studio. Kind of Blue was created out of just a scale.

On the web, we’re making the same transition from classical to jazz. We’re improvising. We’ve moved from a hard-coded system of building pages to an open system of creating participatory environments.

But this kind of tension is nothing new. It’s being going on for years. There’s been a long-running tension between orality and literacy. The printing press destroyed a lot of oral tradition but we still use word of mouth to pass on urban legends and recipes. Liz mentions Alex Wright’s observation in Glut that we are seeing a resurgence in this kind of oral tradition online. Even though we’re writing in blogs and mailing lists, we’re not so much publishing as talking.

There’s evidence of improv online. Exquisite simplicity was how pianist Bill Evans described Miles Davis’s framework of six slips of paper.

Quoting from The Paradox of Choice, Liz shows how the default settings can make a big difference (in the number of organ donations, for example, which could be opt-in or opt-out). Geni has some smart default settings. Same with Tripit. All you need to do is forward an email and it will take care of the rest. Focus on creating smart defaults.

In improv, you need to involve the audience. It’s important to adapt to what your audience is doing. Here’s an example from architecture: there was a fountain that was built in Washington Square Park in New York but before they got ‘round to turning it on, people started using it as a seating area. When the city tried to turn on the fountain, people revolted. The fountain is dry to this day and is used for public theatre.

Referring to the redesign of the Wordpress admin, Liz points out that it’s really important to involve users in the design process. There’s a difference between asking your audience what they think of a system compared to looking at how they are actually using that system.

Listen and watch. That’s another lesson we can take from music and apply to the web. When you’re playing with other people, not only do you have to listen to what the other people are doing, you have to watch them too. It’s the same with architecture. Desire paths are created by people actually using a space. They show clearly where paths should be built. Eyetracking can reveal the desire paths of users interacting with an application. There are other tools like User Voice which can involve the audience. Observe. Listen. Pay attention.

A common technique in Jazz is call and response when musicians play off one another. You see this online in reviews where the reviews start reacting to each other rather than the original item being reviewed. Allow users to build on one another.

User-centred design and participatory design are great ways of involving the users in the design process but that’s still different to actual use. It’s time for a new way of working: designing for improvisation (but remember that no one single process will ever be successful). Our design process should reflect the trend towards user participation that we’re seeing on the web. People’s tolerance for improvisation is increasing and our role as framework providers should reflect that.

Monday, August 18th, 2008

Shepherding Passionate Users

Heather Champ is speaking about community management at An Event Apart San Francisco.

She begins with a little history lesson in the Ludicorp/Flickr/Yahoo story. Flickr is constantly evolving and Heather’s job is to make sure that people’s experience on the site remains pleasant. Flickr is huge and sometimes when people are complaining in the forums, Heather would like to just show them the statistics on how much processing Flickr is doing.

Heather demonstrates the amazing spread of real-time information coming into Flickr, showing examples from the Asian tsunami and the July 7th bombings in London. The counterbalance to these really big world events are the personal events being documented: births, deaths, weddings. Heather shows an wonderful touching from Ari of her grandfather’s death.

Heather’s role is community manager. Sometimes she feels like a piñata—people beat you with sticks and you still have to give them candy. She’s helped out by a lot people; regular Flickr users.

Good guidelines really help: Don’t be creepy. You know that guy? Don’t be that guy. As Flickr has grown, the guidelines have stood the test of time really well.

It’s important to give people tools. Allowing people to flag up their own photos as potentially offensive is hugely helpful. Allowing people to block other users is also really empowering. Heather herself has used this to block the angry hordes who were leaving nasty comments about video in her photostream. Then of course there’s always reporting tools; allowing people to report problems.

Communication is key. Heather relates the story of the long downtime; over six hours (never believe the developers when they tell you that everything will be fine). During the downtime there were constant updates on the blog. It’s really important to be open and transparent. When things to go wrong, own it. Admit it. Don’t try to whitewash it. Also, if you need to make a change to how people experience your community, don’t wait. Flickr waited eighteen months to finally do the Flickr/Yahoo merge and they really regret it.

Don’t create super villains. Sometimes you have to make difficult decisions and take actions that won’t be appreciated. If you don’t handle that situation well, you can end up with a super villain—someone who keeps coming back to haunt you forever …just like the people in that amazing New York Times article about trolls.

When the universe gives you lemons, make lemonade. When there was unannounced downtime on Flickr, they turned it into a colouring contest: print out these circles, colour them in and the winner will get a prize. Over 2000 submissions were uploaded. The level of creativity was startling. Every one participated ended up getting an extra three months on their account.

Change is hard. A very vocal minority responded really badly to the addition of video on Flickr. Some people had very fixed ideas about what Flickr’s purpose was. In the first 48 hours of a new feature, you’re just going to get people responding to the fact that there’s been a change of any kind. In the next two weeks, you get a clearer idea about what people think about a feature.

Heather finishes up with some stories.

There’s the tale of the subway flasher. These stories that break into the mainstream bring with them a flood of people to your site who are not part of your regular community.

Another great story involves a thief who stole a Mac and then subsequently used Photobooth and unknowingly uploaded photos to the real owner’s Flickr account.

When they launched geotagging, the Flickr folks thought that there would be islands of porn in the middle of the ocean. What actually happened was that somebody managed to spell FUCK over Greenland, just through geotagging a ton of photos!

You can’t make this stuff up and you certainly can’t predict it.

One last story. Pandas are cute and cuddly. But in the Flickr universe, there are two warring groups of panda conservationists who try to hack each other’s accounts. Unbelievable but true.

Web Application Hierarchy

Luke W., master of forms, is at An Event Apart San Francisco to tell us about hierarchy in web apps. He asks whether visual hierarchy matters and how we can construct a visual hierarchy.

Let’s face it, people don’t read everything when they get to a web page. Instead, they look around frantically until they see something that looks vaguely like what they’re interested in and then click on something to find out if that’s what they want, hitting the back button if it isn’t. We have an evolutionary capability to assess things quickly and tune stuff out.

The are three design considerations with web apps:

  1. Organisation. The structure of the app.
  2. Interaction. The behaviour of the app.
  3. Presentation. How your app looks to the audience.

The presentation layer should communicate how a web app works (interaction) and where stuff is (organisation). The presentation has two components:

  1. Visual organisation.
  2. Personality.

We focus a lot on communicating What is this?, How do I use it?, Why should I care?

Luke shows a screenshot of a very generic looking interface with no real visual hierarchy. No one can tell what it does. By reorganising the page elements, it becomes clearer what the application does. All that’s changed is the hierarchy.

He shows another example: Yahoo Desktop. The old design was very flat, everything was emphasised equally. The redesigned version has emphasised the labels “Search” and “Browse”.

In another example, a listing site, we see that de-emphasising page elements is as important as emphasising. There’s no point in having everything competing for attention.

Having shown us the benefits of visual hierarchy, Luke is going to show us how.

We make sense of the world in terms of relationships. We don’t know when we smell because we’re used to the smell, but other people notice because our smell stands out. It’s much the same with sight. We can associate or disassociate things using contrast, distance and size. We can use contrast in visual weight to guide the eye and create a flow. A screenshot of the Apple website demonstrates a considered creation of flow (compare that to a site where everything has equal weight—your eyes can’t focus on any one thing).

With cheap storage and open-source development environments, the barriers to entry for creating a web application are approaching zero. With so many web apps out there, how do you communicate at a glance what your app does?

When we design web pages, we concentrate on how a page fits into the structure of the site (is it a “parent” page or a “child” page, for example). But increasingly we should be thinking about how our pages fit into the structure of the web. Most people will probably arrive at a web page directly, through a search engine or content aggregation tool, rather than by drilling through the structure of your site.

Enough about the importance of letting people know what they can do on a web page. The next step is to make good on that promise and allow people to do what they came to do. Let people get straight to what they want to do. Don’t put any roadblocks in their way.

Luke’s talk is filled with excellent examples to convey his points but of course, given the visual nature of what he’s talking about, I can’t really do them justice here. You had to be there.

Storytelling by Design

Jason Santa Maria is here at An Event Apart San Francisco to give a design counterbalance to Eric’s code-filled talk.

He kicks off with a heavy question: the meaning of web design. We often talk about the tools like grids and typography but we often overlook the storytelling aspect. Usually we’re trying to accomplish a narrative through design, such as a visitor to a site buying a product.

From an early age, we’re taught to recognise stories. We learn to recognise stories from pictures before we can even read. This is graphic resonance. The game Haunted House on an old-school Atari. It’s fear personified, jokes Jason of the pixelly 8-bit images. The graphics don’t tell you much but if you look at the packaging, it sets the mood for the game.

The designer is the narrator. Jason shows the Tufte visualisation favourite of Napoleon’s invasion of Russia. It tells a dramatic story (and conveys lots of information) through design. You can see more modern versions of storytelling through graphic design in magazines like Wired. They vary the layout and the design direction to set a mood for the article. The design helps reinforce the story. But when these articles move online they are all served up in the same template. We’ve distilled our stories down to content.

David Carson says Design can’t not communicate. No matter what you put on a page, you are communicating something. A lot of the time we aren’t thinking about this and that means our stories are lacking. Take a look at all those Web 2.0 logos to see homogenisation in action. It’s pretty much the same with page layouts. Why are we plagued with this sameness?

Who’s heard people say, Most web designers aren’t designers or We’re limited to just five typefaces. It’s such bollocks. You can still tell a story. For many years, print design also had a very limited amount of typefaces but they still came up with great stories through design. Are we just not trying hard enough on the web?

Jason tackles the same chestnut that Jeffrey mentioned: Where are the examples of iconic web design? asked Armin Vit. But it’s apples and oranges to compare print (or any other medium) with the web. It’s a different medium. Here are things that distinguish the web:

  1. The metaphorical page. When we design, we usually do it on a physical medium like a cave wall or a paper page. Figuring out how to convey lots of information in a limited space is not a new problem. There are always constraints. Usually these are physical constraints, like the physical dimensions of say, a book. But what about a web page? There’s no limit to the height of a web page. Web pages can extend beyond the boundaries of the viewport. That gives us a license to talk more.
  2. Ubiquity and WYSIWYG. A magazine doesn’t change from printing to news stand to reader. But a web page can change. We can switch off images or style sheets. Not only can things change through user input, the designer can change the scope of the page.
  3. Collections of pages. With a book, you can tell a lot about the amount of information it contains just by looking at it. It has attainability and grasp of depth. You don’t get that with a web site.
  4. Layout. is a very valuable tool for layout. It’s a pleasing relationship that’s found in nature. We can develop a system based on it. There’s also the rule of thirds. Books are usually held at the same distance in the same way. That’s certainly not true with web sites when they’re viewed on different devices. Ratios and the rule of thirds break down because we cannot predict the dimensions of a web page. So how is it fair to compare the two media.

Jason has found some sites that are telling interesting stories through design. No one belongs here more than you. Fray. A Brief Message. The Principles of Beautiful Web Design.

Jason realised that he was in the same boat as the rest of us. So recently he redesigned his website to try to tell better stories. He has a basic template but he customises the design for each article he publishes, changing colours, fonts, images, even layout. It’s a simple system for quick art direction. We want to publish quickly online and that can be a big hindrance to customising visual design.

It’s always difficult to describe new technologies. We can always fall back on storytelling though. Early photography was described as telling stories with light. No one needs to know about the underlying technology. On the web, we’ve figured out the technology to a large extent: formats, etc. Design for the web has chiefly been driven forward by technology rather than message. Maybe it’s time to go back and start asking what are the stories we are trying to tell. The form of design should be driven by the story.

The Lessons of CSS Frameworks

Eric Meyer is going to talk about CSS frameworks here at An Event Apart San Francisco.

He did a Google search for “CSS Frameworks” and put together a list of the big players. It’s a list of nine frameworks. Eric wants to know two things: what are they doing the same and what are they doing differently.

Let’s get one question out of the way, the question which one is right for you? Answer… none of the above. It’s like templates. There’s nothing wrong with templates but you don’t put together your client’s site based on a template, right? They can be a good starting point for ideas but you do your own designs. If you’re going to use a framework, it should be yours; one that you’ve created. You can look at existing frameworks for ideas and hack at it. But the professionals in this room are not well served by picking up a framework and using it as-is.

Eric put together a grid of features and which frameworks support those features. Every framework does reset, colours, and fonts. The fact that every framework has a reset is evidence of the frustration we all feel with the inconsistencies between browsers. The rules for colour tend to be much more minimal. Font styling, on the other hand, is more fully-featured generally. Whereas the colour might just be set for the body element, font sizes and faces are specified throughout. Usually that font face is Helvetica. Most frameworks steer away from trying to style form elements. Almost all of them do layout, usually combinations of columns. Four of the nine frameworks included print styles. Three of the nine included hacks.

Font sizes

Four of the nine frameworks are setting font sizes on the body with pixels. Tripoli uses Richard’s 62.5% rule. Eric points out how using a 76% rule on the body can lead to inconsistent font-sizing between browsers because of the inconsistencies of rounding off font sizes. Only two of the frameworks aren’t using unitless line-heights. Generally you want a line height of 1 to get propagated down the document tree rather than simply the computed value of 1em in pixels. You don’t want a 40 pixel element having a line height of 12 pixels.

Heading sizes

Most of these frameworks, with the exception of YUI, are setting heading sizes in some form or another. The only place where you’ll see a heading size go below 1em is in a browser style sheet. In the frameworks, no heading size, even h6, goes below the size of body text, 1em. Blueprint and Elements set pretty large sizes on h1 and h2. The other frameworks cluster around the same size range, never getting very big or very small. Eric averaged out all the measurements to get the average size for h1 and h2.

Naming conventions

Where frameworks are using IDs or classes, what names are they using? Four of them use psuedo-namespaced class names beginning with grid- or container- or span- (which you would apply to a div!?). You’re supposed put classes in your markup like grid-3 or span-5 or whatever. This seems pretty complicated. Three frameworks use more intuitive names like page, header or main. In fact header, main and footer are universal IDs across the three frameworks.

Style inclusion patterns

Some of the frameworks have a single short style sheet that you point to from your markup, which then links off to separate style sheets for fonts, colours, layout, etc. But most of them use separate style sheets and you must link to each one in your markup. Eric reckons that this is because IE for Windows will cache the first style sheet you point to with a link element but not any subsequent style sheets with @import.

What the hack?

There are two kinds of hacks:

  1. Hacks that point to failings in CSS like self-clearing floated elements and things like pseudo-padding.
  2. Hacks for Internet Explorer 6.

Some cool bits

Some of the frameworks provide compressed versions for production use to keep file size down.

Three of the frameworks had debugging styles that you could “turn on” to say, display the grid in the document.

YAML provides a draft file which is like a template style sheet. The selectors are written out but the declarations are left empty. This could be a handy training tool (fill in the curly braces).

960 provides “sketch” files: PDFs of the grid for you to print out and scribble on.

Thus endeth Eric’s roundup of CSS frameworks.

Understanding Web Design

I’m at An Event Apart San Francisco where Jeffrey Zeldman is taking to the stage. He’s going to talk about web design and what it means.

First question, “What is the thing that you need most?” “Empathy,” he says. He brings up a screenshot of Real.com. Everything that looks like a link isn’t a link. Everything that doesn’t look a link is a link …except the “Free Download” button. This site isn’t being driven by user needs, it’s being driven by corporate needs. Their mission is to compete with Quicktime and other media players but they also want to push the advanced player and make it hard to find the free player …competing needs.

Here’s another site: Consumer Search. You can find consumer reports there. They have a store of reports on how well products work or don’t work. But the site has no visual hierarchy, no sex appeal, just a long list of links.

Both sites suffer from a lack of empathy; empathy with the site’s users.

It’s hard being a web designer. The unmotivated need not apply. You have to constantly educate yourself. There are plenty of tutorials out there on using web design tools like Photoshop, Flash, Dreamweaver, and so on. But teaching Excel is not the same as teaching business. Knowing how to use Photoshop and Illustrator doesn’t make you a web designer. Good resources are hard to find. There’s that really good place in Florida (where Jade studied) that has a great curriculum but it’s the exception that proofs the rule. Once you’re out of college and in a job, you still have to keep learning. Jeffrey asks who often feels like they’re faking it and most of the audience puts their hands on.

The A List Apart Web Design Survey aims to answer some questions about working in web design. Last year’s survey showed that many people found that their education was not relevant to their job. In fact there seemed to be a correlation between how rich you are and how irrelevant your education is. When you break it down by job title, it turns out that graphic designers did find their education relevant but most developers are self-taught.

Web designers get no respect. Imagine you’re on a plane and you start chatting with the person in the seat next to you. If you ask someone what they do and they say they’re an architect then you make some assumptions about them; that they’re educated and respected. You don’t get that when you tell someone you’re a web designer. Part of the problem is that there is no standardisation of job titles. We call ourselves lots of different things. If you’re working with Fortune 500 companies that use lots of baloney titles, you feel you need to make up baloney titles for your company too. If you’re at a university, someone might be called a Webmaster. If you’re at a startup, someone might be called a User Experience Director. But they’re probably doing the same thing.

Another problem for people working in-house is answering the question “Who owns the website?” Usually it’s either Marketing or IT. There should be a separate Web division.

Another thing that the survey showed is that web designers don’t get rich. They make less money than people in comparable fields. This field also suffers from many of the same prejudices as other fields.

So who speaks for web design? Communication Arts is a magazine about graphic design. Every year they have an end-of-the-year round-up of the best in design. The problem with any kind of competition is that it fosters the same kind of design all the time. For example, when Jeffrey was a judge for Communication Arts, there was a beautiful site but it was half a gig in size. Jeffrey didn’t think that was worthy of a prize (although it really was gorgeous). In the 90s in advertising, it was much the same. There was a trend for edgy, sarcastic advertising that won awards and therefore prompted more sarcastic advertising.

Then there’s the Webby Awards, a very glitzy affair. David Bowie was the host this year. Jeffrey loves Bowie (he has bought his music multiple times) but is he necessarily the best judge of web design?

If you can’t rely on competitions and awards, you could turn to traditional news media. A few years ago Wolf Blitzer discovered blogs. They didn’t quite get it.

Jeffrey asks who reads TechC*nt. People put up their hands …they should be ashamed of themselves. Jeffrey, like me, doesn’t read TechC*nt because it just makes him angry. Who gives a shit about how much money people are making? Aren’t the ideas more interesting?

There’s the old chestnut about iconic web design, sparked by Armin Vit’s Under Consideration article. Jeffrey and Jason disagree on this one. Jeffrey thinks that lamenting the lack of a web design equivalent of a Milton Glaser poster is missing the point of web design.

Time for some practical lessons. Most importantly, we need to get away from the guitar solo approach to design. You should not be designing just to make other designers jealous. It happens a lot in design but it happens in development too (I’m looking at you, Ajax). Good design is invisible. It’s about the character of the content, not the character of the designer. Let’s get away from showing off get to empathetic web design. It means user-centred design but by abandoning that label we can side-step the religious wars between UCD and agile.

Here are twelve tips to empathetic web design.

  1. Start with the user. If you’re making a personal site, great, do whatever you want. But if it’s a site for other people, start with the user and stay there.
  2. Know yourself. Know your weaknesses. Know what you’re good at and what you’re bad at. Jeffrey knows that he’s good at painting the big picture on a project but he’s not good at dealing with the details.
  3. Find the right client (or job). Find an environment or project where you can thrive. This ties in with tip number two: when you know what you like doing, you can seek out that environment.
  4. Sell ideas not pixels. Andy paraphrases this as sell the sizzle, not the sausage.
  5. I don’t know is okay. It should be acceptable to tell a client you don’t know something. If you’re afraid of saying that, that might not be the right client.
  6. Build trust. They need to know that you know what you’re doing.
  7. Bring out the big guns. Don’t be afraid to quote research at your clients. They won’t read it but they’ll be persuaded to trust you.
  8. Create a paper trial. Remind people what they already agreed to.
  9. Never underprice your works.
  10. Say no to spec. Don’t work on spec. Don’t work for free.
  11. Say no to rush jobs. They never work. The clients are always in a rush but they’re always late getting back to you. The reason it’s a rush job is because they spent months disagreeing about stuff.
  12. End with the user. When in doubt, go back to the user.

An Event Apart 2008 | The Web Life | ZDNet.com

Follow the fun at An Event Apart San Francisco thanks to the diligent liveblogging of Andrew Mager. The man's a machine!