Friday, September 5th, 2008
pre-dConstruct
It’s D-Day in Brighton. In just a few more hours, dConstruct will commence at the Brighton Dome. Twitter is all a-twitter as the geek invasion reaches critical mass.
It’s wonderful having so many friends descend on Brighton in one go. It seems like half of the UK geek scene and a goodly portion of San Francisco are already here. As you can imagine, things have been pretty busy at Clearleft Towers. We just successfully wrapped up two days of workshops and now it’s time for the main event.
I’m feeling a distinct mix of nervousness and excitement. I think the line-up looks pretty awesome (it’s basically our dream conference come to life) but that last name on the bill has got me worried. I’m supposed to close the show. I’ve spent the last couple of weeks fretting and freaking out but, bit by bit, my talk has come together. I have a feeling that some people will really like it but others will definitely hate it.
This won’t be my usual technology-focused kind of talk. There will be no word of Ajax, markup or microformats. Instead, I’m going to try to boil down years of studying network theory into less than 45 minutes. If I can just convey some of the excitement that I feel about this stuff, I’ll be happy.
In the meantime, I hope I can get some sleep before the big day kicks off. It feels like the night before Christmas …but a Christmas that involves a paralysing public appearance in front of 800 of my peers.
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:
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, 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:
- Understanding Web Design by Jeffrey Zeldman
- The Lessons of CSS Frameworks by Eric Meyer
- Storytelling by Design by Jason Santa Maria
- Web Application Hierarchy by Luke W.
- Shepherding Passionate Users by Heather Champ
- The Framework Age by Liz Danzico
- 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 namespacedwebkit-andmoz-border-radius declarations. Dan puts these vendor-specific properties into a separate stylesheet calledenriched.cssto 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
opacitybut 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 likeborder-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
clearfixsolution 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 ofgroup. - 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-widthon 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.laston 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:
- Organisation. The structure of the app.
- Interaction. The behaviour of the app.
- 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:
- Visual organisation.
- 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:
- 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.
- 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.
- 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.
- 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.
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:
- Hacks that point to failings in CSS like self-clearing floated elements and things like pseudo-padding.
- 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.
