Archive: 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!

CSS for lunch » Mastering the presentation layer of the web… at lunch time.

Here's a great project from Andrew Mager. He takes a little time out at lunch to post a small markup or CSS tip. Over time this builds up into a really valuable resource.