Journal tags: aeasf08

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

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.

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.

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.

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.

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.

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.

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. The golden ratio 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.

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.

• 960
• Blueprint
• Content With Style
• That Standards Guy
• YAML
• YUI
• Elements
• Tripoli
• WYMStyle

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.

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.