So, as Web Directions USA 2010 (WDUSA10) draws to a close, time to reflect.

Inevitably, I can’t help but compare some aspects to SXSW, even though this is a much smaller event. (prolly less than 300 people at anyone time). Only 2 tracks - design & dev.

WDUSA10 clear winner on the name badges. I didn’t have to lean in and squint to make out someone’s name. But SXSW def wins when it comes to swag in the bag. Not that important of a metric, but I really wanted to use the phrase ‘swag in the bag’.

I really didn’t feel like a target market like I did @ SXSW, so that was nice. There was a little vendor/sponsor space, but nothing on the level of SXSW. example: the entire vendor/sponsor room @ WDUSA10 would have fit in the space Pepsi had at last years SXSW.

Protip for the organizers: for a web conference, make sure each space has a net connection. just sayin. SXSW had this problem the first time I went there too. So actually, maybe the problem is just me? i’ll have to check the logs.

Anyhow, enough ruminating. In no particular order, some highlights from each of the sessions I attended.

Nicole Sullivan - Optimizing Facebook: Integrating OOCSS

Nicole shared some of her experience wrangling CSS into lean mean styling machines. She introduced the concept of Object-Oriented CSS (OOCSS). You can check out her library of tools for this on her github. As of this writing, it seems a bit under construction, but dig into the core folder.

This is the session I got the most out of. There were some good ideas in there. You can read all my notes from this session. But some highlights (all errors are mine - can’t find the slides for her talk yet):

• CSS blocks page render till download.
• She discussed this one idea FB tried - Haste Based Trace packaging. Seemed like a good idea. Based on visitor traffic, the system would create the main style sheet. Start at page 21 of this slidedeck for more info on the concept. Unfortunately, while a cool idea, it didn’t really work out as well as hoped.
• Do a VISUAL INVENTORY!
• Basic idea: think of css as legos - we want to create the building blocks
• Learnt about Dust-Me Selectors - a ff extension which can help you gather a list of rules that you should take a look at. (Would make a good w/e learning project to convert to a chrome extension - although Chrome already has this basic functionality for one page at a time).
• instead of h1, h2, h3 try setting up global values like
  h1, .h1 { ... }
h2, .h2 { ... }
  this will allow allow you to respect semantics, while still allowing visual consistency. Example, you want a large h1 style heading in your sidebar, its better to use a class of h1 as oppossed to the H1 tag.
• Using grep to analyze your css. One of those ‘seems obvious in retrospect’ ideas, but i’ve never actually tried it.
  grep -in 'h[1-6]' style.css
grep -in 'font-size' style.css
grep -in 'float' style.css - finding a large number of these? Maybe its time you looked @ using something that supports nested grids.

As mentioned, this was just some highlights - have a look at all my notes from this session - there was a number of good tips.

Awareness of this is something I will be pushing for a bit more at plank.

Nicholas Zakas - High Performance Javascript

You know the expression ‘He wrote the book on…’, well, in this case it’s literally true. Nicholas wrote the O’Reilly book on High Performance Javascript.

All in all, this was a good session. He went into the UI Thread, how that affects the user experience, and went into various patterns/solutions to help mitigate the problem if you find your JS taking too long. Some key takeaways:

• 100ms cutoff - no js job should take more than 100ms to complete.
• timers - ie: use set timeout pattern to chunk up the work.
• webworkers
  • data driven, async, no access to dom.
  • better than timer method - executes faster, since not having to use delays inherent in the timer pattern.

You need to know the difference between a repaint versus a reflow, and the consequences of each.

Repaint: A visual change which doesn’t require recalculation of layout. eg: color change

Reflow: visual change that requires a layout change. eg: change width of a div

Overall, it’s important to have an understanding of how the UI Thread operates.

Group your style changes together. If you have to change a few styles in one go, use a class.
Bad: $('#foo).css('width', '200px').css('color', '#fff')
Better: $('#foo).addClass('bar')

Or, if that’s impractical (for some reason), use cssText property on the style object.
$('#foo')[0].style.cssText = "width:200px;color:#fff;"

Avoid Accidental reflow: A browser doesn’t necessarily calculate reflows right away. However asking for calculated data, ie: computed style, will force the reflow early, since the browser needs to do the reflow to calculate the values.

You can check out Nicholas’ slides from this talk as well as my notes.

Tom Hughes-Croucher - An introduction to Server Side JS

Overall interesting, the most appealing idea behind using SSJS is not having to do things twice. ie: php validation on the backend, js validation on the front end. Done well, you also get progressive enhacement for free. If the client doesn’t have JS, or maybe they have an underpowered JS, ie: a mobile browser, then you render your js on the server side.

For a good example of this in practice, have a look at Dav Glass’ YUI/Express JS Demo.

Definitely made me want to play more with NodeJS (and SSJS in general), though it’s still not something we could deploy for production here @ plank.

Also learnt about the font, Monofur, which I am loving for my day to day.

You can see the slide deck - check slide 10 for much smiles. And my notes.

Ryan Freitas - Balancing Data-Driven & Genius Design

Not to many notes from here for me - but overall was interesting.

One core takeaway: ‘Split testing is your new bff’.

Since it’s so easy to do split testing these days, and to target to only small percentage of your users, it should free the designers to start testing ‘insane shit’. Split testing removes the risk if only 5% of your audience will see aforementioned ‘insane shit’.

Michael Mahemoff - HTML5 Offline, and On

Still a bit of a wild west when it comes to local storage

• localStorage
• sessionStorage
• websql - not supported ie, ff
• indexed DB
• file storage

Learnt about the File API. Using a FileReader, no need to upload the file to give your app ‘access’ to it. Can read straight off the disk.

Also learnt about the new multiple attribute for a file input.
<input type="file" id="images" multiple> which will be a nice addition once everyone supports it.

Michael also discussed the idea of using local storage for building ‘lazy’ registration into your apps. Allow the user to do as much as possible without needing them to register. Just store the relevant info on their localstore. Yes, if the user changes machines, then they won’t have their info, so this is a contextual tip - only use it when it makes sense. And you can always allow the user to register, at which point you send the data to the server so they can access from other machines.

You can check the slides from his presentation, and he also gave some links to other good reads in this area.

Jonathan Stark - Location, Location, Geolocation

Nothing earth shaking here, but part of that is that I’ve been interested in geoloc already. Some takeaways though:

• The 3 ‘pillars’ of a good mobile app: focused, fast, smart. Geolocation plays into the making the app smart angle.
• When deciding Native versus Web app, consider: if it can be done in js, css, html, then you probably should. And using PhoneGap it’s easy enough to take the web app and package it up as a native app for various platforms.

Doug Schepers - How To Kill SVG

Doug’s presentation was pretty interesting, and got me jazzed up about taking a good look at using SVG.

One advantage of SVG is that it is media queries aware - so you can set things up to display the SVG differently depending on device, screen size and whatnot.

Fun facts:

• SVG is a DOM app, just like HTMl.
• You can mix n’ match SVG and HTML in a document.
• You can do SVG via CSS to apply filters to elements.
• SVG is pretty accessible. You can actually copy text from text in an SVG ‘image’. eg: You can double click on the word SVG in this demo and copy - paste into a text file, you will get the word.
• SVG can be a good choice for UI elements - especially for something like an iphone web-app.

There’s a number of tools that support exporting to SVG, so no need to craft it all by hand.

One drawback is that some browsers don’t have SVG support (i’m looking at you ie6/7/8) but there are some workarounds, like SVG Web.

When it comes to Canvas versus SVG, it’s about knowing the strengths and weaknesses of each option. eg: while Canvas is great for quick, fast 2d rendering, ie: games, it’s probably not appropriate for UI Elements in the same way SVG is.

Oh, and the answer on How to Kill SVG? Just keep on not using it - eventually browser vendors will stop putting resources into supporting it.

---

One tidbit I picked up, which didn’t warm my heart, is that the browser for the new Windows Mobile 7 is actually some sort of bastard child of IE7+8.

All of these sessions should be put up as podcasts at some point. Follow @webdirections on twitter - I’m sure they’ll mention it there when the podcasts go up.

In the interest of lazyness (it really is so easy) I’ve thrown up all my notes into a github repo.