Day two of Alistapart's web conference was just as satisfying as the first day, full of a mixture of technical, business, and design inspiration.

Doug Bowman: Design to Scale

In keeping with presentations of the past, Doug Bowman used his humanity-scale metaphors to explain how the audience should challenge their way of working. The only thing different, was that this time, his tenure at Google encouraged him to showcase a company's achivements rather than his own.

Doug's old Stop Design office was in the top of this buildingAbout two years ago Doug announced his move to Google. With the world, and I, forever curious as to how his incredible talent was being focused, he opened his presentation with an explanation. Most software companies, and most obviously, Apple, have a very polished visual brand, which propagates into a consistent and loved graphic style in their products. Google, on the other hand, does not, and needs Doug as a driving force towards consistency between their homegrown and aquired products, as well as finding Google a more beautiful rendition of their minimalistic, geeky theme.

Doug's background, for those who don't know, included progressing through Hotwired, the web's first real magazine, until it got too big (See Jeffrey Veen's screenshot-embedded account), before going off on his own to redesign influential sites like Blogger. With so much going well for him, it I don't envy being in his situation to abandon StopDesign for Google, although it does seem like a natural, but tough, detour. 

Finger nail

So, to get your mind off that news, I'll mention Doug's creative use of showing a fingernail. He showed the picture here then  zoomed out to demonstrate it in a different context: as a newborn finger clasping a parent. It was an artful way to get back to the topic at hand: scale.

Doug initially summarised how cities inspire and adapt to growth via railways, freeways, skyscrapers, city planning, and even lanes that change direction to cope with rushhour and drunk drivers.

Golden Gate bridge traffic diagram

Having introduced the point, he crossed to websites and apps to demonstrate the correlation. Cities and companies know how to grow quickly, and the lessons from these should, and can, be applied to websites;

  • Expect and fuel growth. Find the railways that will coax the millions of visitors to your land, but be organised and anticipate their needs so you can cope with the demand. Moreover, given the growth of our world population, and the advance of China and other nations, your website or product will need to handle popularity.
  • Ensure flexibility; people are different and so your product needs to allow for their idiosyncracies. Let users use different browsers, font sizes, and window dimensions. Allow for menu items and text-based labels so that they can be translated, knowing that not only is German often longer thanEnglish, but that menu tabs in Chinese may only be a single character and yet need to be findable and clickable.
  • A popular website needs to be fast, simple, and not burden its infrastructure. If a task can be done in a few pages, not only does it make for a better user experience, it lessens your server requirements. If that task is a sign-up process, then the simpler it is, the more likely your entire business will succeed, as Doug demonstrated with Blogger.
  • Extending his point on infrastructure, Doug also mentioned the notion of downtime in 9s (without the myths), and reminded us that for a popular system, a few kilobytes shaved off a webpage equates to 100GB of traffic when you have 20 million users; often the case for Google.

Doug also scored a few points for his slide design...

Jina Bolton: Interface cosmetology

Design 101. Jina brought us back down to earth, to focus us on her obsession of design, beauty, the world, and herself... which all makes perfect sense when you discover she's a designer for Apple, and co-author of The Art and Science of CSS

Gina Bolton

As someone who appreciates but never "learnt" design, it was an edifying hour.  I'm sure those who did know design were still impressed and motivated by the array of awesome website work showcased.

I liked her play with the phrase "you need to know the rules before you can break them". I'll have to use that next time people don't want to learn rules!

Some of her Design 101 material included;

  • Making use of curves, which is hard with CSS; you need to use  images. E.g. sylvialoh.com
  • Use 2 to 4 typefaces, often balancing a serif with sans serif. Altering letter-spacing can be used as create subtle differences without creating a page full of too many typesfaces.
  • Do worry about typesetting, in other words, the placement and spacing of letters, words, lines, paragraphs.
  • Favour left aligned headings and paragraphs, although justified text  generally favours centered headings.
  • Capitalise on whitespace and real punctualtion (emdash, elipsees) to enhance ledgibility and a feeling of polish.
  • Be decorative and use ornamentation, e.g. begin sentances with a drop cap or smallcaps. Want inspiration? See ilovetypography.com
  • Use photography or illustration but share the mood, motivation and palette with the webpage. Online fashion store Urban Originals shows how a photo and webpage blend together for a consistent effect.
    Urban Originals homepage
  • The rules of photography apply also to illustration. Case in point:  DannyBlackman.com (do scroll up and down lots)
  • Use volume and depth, and perspective
  • We all know colours strike different moods (anger, relaxation, sterile, etc). Remember that when coming up with colour schemes.
  • Use pattern and texture to provide enhance the mood created by colours.
  • Simplify. If you put a website in our showcase that obviously shows you've sequentially added each of the above attributes one by one,  it will probably look as tacky and overdone as a MySpace page. Contemplate "Its not how the work looks, its how the look works".
  • Have others critique your work.
  • Use websites like cssremix.com and horde well-designed things to inspire

Kimberly Blessing

What standards are we talking about

A person's first slide is very defining. Kimberly Blessing's showed me I'd never hire her as a designer. However by the end of the show, I don't think I know of anyone better to evangelise and produce website-building standards and have them successfully spread for the true good of an organisation. So, your first slide really shows whether or not you a master of your topic.

Kim brought standards to AOL, which at that time was everything from whether you used <UPPER> or <lower> -case elements through to file-naming conventions, etc. ID and class names, cgi variables. While she apologised that her standards back then weren't the ones that eventually became best practices or the W3C rules that the web developer community believes in, she was breaking real ground back then, and I'm sure it was far easier to modernise those standards than deal with the outfall of having no standards back then.

So why standards? The consistency and uniformity makes people work faster, waste less time on the mundane and unrewarding basics, and ultimately be more profitable. This applies to both companies concerned with their internal teams as much as it does to webdevelopment agencies billing out to clients. 

While it'd be hard to argue that being consistent in the way you build a website saves time personally, as well as across a team, I was impressed with Jessica's quick progression onto dealing with complaints. She'd obviously spent considerable time managing them.

  • Standards are out of date or not completely relevant.
  • They don't address a certain topic.
  • They're too difficult to read or remember (aka I'm too busy)
  • Management told me to skip them
  • They limit my creativity

To overcome these complaints you need to properly create then manage the standards:

  • Standardise the fundamentals to begin with
  • Study work done and in progress to look for conventions and model standards after them, in other words ratifying rather than changing the way you work.
  • Consider future needs (need I remind you of Doug's salient points?)
  • Set a definitive review schedule. For instance, each three months review the standards. Look at work done in the period and see if standards are being followed. If not, why not? (Poor standards or poor adoption of good standards?). What non-standardised aspects of the work are sensible to standardise. Sidestepping proper reviews will ruin your entire standards system, so do it well!

Training & Communications is key to making standards work in an organisation. First of all your must gain satisfaction. Everyone needs to get on board to learn about them, and get their buy-in. Standards must be mandatory; Jessica made a real point of demonstrating how even the top level management needed to be apart of training. If anyone doesn't turn up to training or the announcement about standards, they can shrink away and undermine your efforts to getting your team behind the standards.

Offer training and communicate regularly, and incorporate adherence to the standards part of your project life-cycle. Make it clear that a project is not finished unless its proven to have adhered to the standards. Not only does this ensure your work is better, checking off the project gives you the insights into what to tweak with your overall standards.

Accountability of the standards. You must appoint a single person who is in charge of standards (or different people for different standards). This person trains people to supports the standards (e.g. coach the junior guys who are excited and passionate about such things). This person has to be vocal, in your face, around all the time, not at their computer. They need to yell at anyone when standards are not followed, which includes their boss. On the flipside, like I do with our Google Summer of Code student work, genuinely thank, showcase and congratulate those who do what you want.

So to make a good standard, it needs to do more than just dictate how you do something, otherwise people will often not see the point of doing it. (I know I challenge rules that may be perfectly sound, if I don't have a justification) You must both explain the reason and need of standard, and justify the solution. If people know the intent, such as to improve download speed, or allow your CSS file to work in two different projects, they see the greater good and will like your standard. Have use case, examples to help with both convincing the standard is worthwhile, as well as demonstrating how to use it.

I knew Jessica was on the right track when she began to talk about verbs. I found that our newer staff write documentation with gentle language like "it is good to do x, y and z", and then noticed how flimsy it felt and how no one else would bother to heed the instructions.  So in Jessica's words, instead use "may" and "must", not "should always"! Don't be afraid to lay down the law by saying things like "Never use selector hacks" or "Always set font sizes using ems and percentages".

So to tie it off, Jessica explained you need a single "standards person", who writes good, justified standards; makes sure every understands them, and regularly checks, updates then, and congratulates or scolds the team as appropriate. 

Eric Meyer: The state of CSS in an IE7 world

ie7 logo

Eric did a repeat of the previous day, showing off some neat tricks and explaining for those who've been too busy, about what IE7 has, and hasn't done, and suggested what we should about it.

The main problem with IE7 is IE6. While IE7 didn't resolve all we wanted fixed, the larger issue is that with so many users of IE6 lurking around (exasperated sigh about how intranets are made to be IE6-only compatible, preventing upgrades), the web industry has been shy to eschew IE6 compatibility. For instance, on silverstripe.com this month we have;

FireFox   64.2%
 IE7 17.5% 
IE6  9%
Safari   3.8%
 Other  5.5%

As Eric point's out,  though. You shouldn't care. Look at your own, as they might be completely different :P 

Eric  continued by demonstrating the advantages of IE7, before showing us a neat trick to let us actually use them.

As Eric points out, IE7 has working fixed positioning and number of other CSS concepts.

Improvements to IE7

 

For instance, the > characters selects the direct child, but not anything deeper:

body > div {
  border: 1px dotted red
}

e.g. <body><div>would select this</div></body> yet <body><div><div>not this</div></div></body>

A menu formed from a list often desires styling the first menu item differently. You can do this now:

<ul>
<li>about us
<li>products
<li>services
<li>contact us
</ul>
li {border-top: 1px solid black; list-style: none}
li:first-child {border-top; none}

You can also now use adjacent sibling selector (the plus symbol). Things really got interesting with Eric's summary of attribute selectors, which are clearly explained over at W3C, e.g.

style TEXT input but not other input elements
input[type="text"] {
width: 85%;
border: 1px solid #555;
border-width: 0 0 1px;
}
If a text box has the value required, emphasise it
input[value="required"] {
color: red;
font-weight: bold;
}
Magically put a PDF icon beside downloads
a[href$=".pdf"] {
padding-right: 18px;
background: url(/pix/pdf-icon.gif) 100% 50% no-repeat;
}
Or like this
a[title*="(PDF"] {
padding-right: 18px;
background: url(/pix/pdf-icon.gif) 100% 50% no-repeat;
}

So, now that you're about to personally hunt down each IE6 user and physically upgrade them to [well, I'll leave the IE7, FireFox and Safari debate to you],  Eric pointed out Dean Edwards' IE7 javascript support for IE6. Not only does it make IE6 work like IE7, this script was actually out well before IE7, and was the inspiration for the IE team on what could be easily fixed. (E.g. why else would they have added the <abbr> element?)

To answer's Eric's question, unfortunately, no, it seems that attribute selectors are read once at loadtime, and not in runtime. It would have been awesome to be able to do this:

input[value="required"] { 
color: red;
font-weight: bold;
}
input[value="easteregg"] { 
color: blue;
}

And have something change as you typed in different values. But I've tested it, and it doesn't work. Try it yourself. 

Lastly, Eric talked about how to deal with browser hacks. Eric mentioned both the "html > body" style hacks as well as Conditional Comments, which work reliably to put your hacks in a single, obvious, maintainable, location. Eric didn't push for conditional comments although I certainly believe that approach easier to manage and more likely to be reliable as browsers update.

So, since IE7 is more on par with FireFox and Safari, without further ado, read up on CSS selectors once more, and make some websites that would have traditionally have broken in IE6! (Let me know if you put them in our showcase)

Aaron Gustafson: Learn to love forms

 Learning to love forms

Aaron Gustafson led a very detailed, methodical tutorial on how to write good semantic HTML for forms, and how you should style it. I felt much of the content was fairly widely known, although I was a little distracted by our SilverStripe demo site being down thanks to a city-wide internet outage. Aaron's website, however, does have lots of interesting content for you to read.

Jeffrey Zeldman: Selling design 

Jeffrey runs the rather successful HappyCog webdesign agency and finished the conference off with a very edifying hour of lesson's he's learnt, most of which went well beyond the jurisdiction of purely how to sell design. This was an excellent session so: 

An an example, he raised a very valid point challenge about refuting the conventional business wisdom to agree to clients who run to you with a rushed, last minute, nearly-overdue project:

"Listen for bad-date vibes. When someone comes running like a house on fire, we run away from them. “Your emergency is not my problem.” Here’s what it means: The business wisdom is you can dictate terms. It really means that they knew they wanted to launch on September 1, but they couldn’t agree to a strategy, with committee after committee, like things are like at a university, and then finally it’s almost September 1. When they’re in a rush and they’ve been indecisive and that’s why they’re in a rush, they’ll still be indecisive when they’re your client. They’re the same people."

It doesn't just stop there!

AnEventApart DinnerAs if the speakers, the venue, the networking, and being in a foreign city weren't enough,  AnEventApart  had dinners on both nights with sponsored food and drinks.  A big thank you to Eric, Jeffrey and the rest of the team who put this on - I know how much work it is.

I see next year's dates are already posted at aneventapart.com. I'd certainly suggest attending (and to keep you excited in between, you can pop down to New Zealand in February). 

Update: I put up a write-up of the following day's Google Summer of Code Mentor Summit... 

Post your comment

Comments for this post are now closed.

Comments

RSS

Thanks Walter, fixed.

Posted on 23 Oct 2007 by Siggy

Hey Siggy, you have left ".nz" off that last link. :)

Posted on 13 Oct 2007 by Walter Sobchak