Magic Torch

I gave a talk at the end of April, as part of the Equator Academy lunchtime seminar series. Went pretty well, by all accounts. My own memories are a bit vague. But a few technical and presentational lessons were learned, and it was definitely enjoyable (yes, really) once I got going. The more conversational Q&A at the end was something I could have done all afternoon.

It was a bit rapid-fire though, so I thought I’d put together a bit of extra info about the things I touched on.

First off, here are the slides that I used. There are a few more involved ones, but mostly I wanted sign-posts for the talk, rather than putting it all up there to read. I was definitely conscious of avoiding the turning-to-the-screen-and-just-reading-what-is-there syndrome.

Mostly worked.

Anway. Here’s some notes and links for stuff I found useful when I was putting the talk together.

The Front-End as Abstract Information

This more abstract perspective of the front-end is normally something that sits at the back of my head when I’m working. It’s good to periodically evaluate what I’m doing in these terms, to keep me right and help me plan what’s going where.

The Early Web

I had a look at the Internet Archive, which archives pages and sites going back to the mid ’90s, and went over some very early websites. It’s amazing to see this stuff and realise it is only ten, fifteen years old. It can be a little scary looking back at what was considered cutting edge, or at least acceptable enough back then. Especially the early iterations of big corporate sites. The impression you get is that no-one really had any idea what was about to happen.

Can’t help but make you think if the stuff we are producing today will be regarded in the same way a decade from now.

“Web 2.0? Aww, they really didn’t have a clue, did they?”

Tower Of Babel (to) Present Day

Here’s the article from A List Apart that I mentioned: To Hell With Bad Browsers. Today, supporting the latest browsers is the sexy, but 8 years ago making that choice must have been tricky and at odds with what everyone else was doing. Again, worth noting how much things have changed in a very short period.

Two other site I mentioned briefly were the Web Standards Project and the CSS Zen Garden:

The Web Standards Project did a lot of behind-the-scenes, non-sexy work in the early (and later) days of Standards awareness. Their site is still a good place to read about the basic reasons for embracing standards, as well as that historical perspective.

CSS Zen Garden started as a more design-focused attempt to encourage standards-based design and using CSS for presentation in particular. It has used the same markup since then, which contributors then transform by adding CSS and image to this.

And obviously, there is a ton of technical documentation at the W3C. The basic definitions of the technologies, but also a lot of learning material.

Modern Web Standards

I used Andy Rutledge’s Bullet List Only page to illustrate both how powerful CSS now is at laying out page and also that this power can often hide bad markup that could create issues in other situations, where the primary stylesheet isn’t being used. With standards both HTML and CSS can really do what they were designed for, and as a result both can step up a gear.

There’s a ton of stuff to read about where Web Standards are these days. Lots of newer topics too, as the ideas and insights have developed and multiplied. Here are a few more things to get started with:

How To Grok Web Standards – A great piece that explores the basic ideas of standards and semantics from different, non-webby perspectives.

Understanding Progressive Enhancement – Progressive enhancement takes the tools we have in Web Standards and think about using them more effectively, with a eye on both the present and the future. Definitely the way forward as the browser market gets more crowded and something we’ve embracing at Equator.

We Interface Developers have been talking recently about the range of browsers we support and test our sites against. IE8 is threatening to be released any day now, and almost as importantly it is definitely not threatening to kill off substantial use of IE6 and/or IE7 anytime soon.

So we have a trilogy of different Internet Explorer browsers doing things their own, interesting ways. Plus the Webkit and Gecko-based alternatives, like Safari, Firefox, Camino and Chrome (I would call these necessities rather than alternatives, but I’m still in the minority according to the stats).

It means a lot more work for Interface Development. In the same amount of time. So instead we need be smart and not just keep the smartness to ourselves.

Up until now we’ve been able to support a fairly generous production process, in terms of what the client has been getting. That is, sites that work and present themselves pretty much identically in all the browsers we support, IE6 included. Working that way is the result of many things, not least the fact that our team really knows what it’s doing when it comes to wrangling angry browsers.

But a new perspective is needed. One that recognises that treating all browsers the same actually does more harm than good in the long run.

I’m a bit obsessed when it comes to clean, semantic markup. It’ll tend to the be the first thing I look at when studying a site. You may be rocking the best visual style the world has ever seen, but you’ll not get any opinion from me until I’ve hit “view source” or fired up Firebug and checked out the DOM. At which point it can all go horribly wrong.

Of course, being an inhabitant of the real world, an attitude like this is tough to maintain when you are actually making web stuff, and compromise is never a bad thing when a deadline is approaching or an extra bit of markup gives a more robust finish.

But priorities and expectations about the web have changed radically in the last couple of years, such that compromise on markup standards has become a luxury rather than a necessity. We don’t have time to keep hauling struggling browsers along at the same speed as the pack leaders. We have to accept what has always but which we’ve been able to ignore up until now: All browsers are not equal so they should not be treated as equal.

We need to adopt a approach of Progressive Enhancement and make this the core of our process. We need to allow flexibility in the user interface to give enhanced functionality across all browsers.

The best browsers today can do amazing stuff given the chance. The worst browsers today can provide better functionality and speed given the chance.

How to achieve this is simple: don’t try and apply a one-size-fits-all interface, because actually it doesn’t fit anybody. The old browser struggles with the extra markup, styling and images. The new browser is stuck handling a legacy implementation it could run rings around given something fresher to work with.

And then the future turns up and things really get bad.

Let’s go the other way. It has frickin’ lasers and everything.

There’s a bit of team renaming going on the office right now. The front-end crew (of which I am a member), who previously had the awful title of Build Team, are now the Interface Development team.

I think there is something to be said for having a cool-sounding team name. I’d previously voted for Science Ninja Team but Interface Development is pretty decent. There is plenty of space in there to fill up with a heady mix of abstract ideas and 7-browser-tested bulletproof solutions. It’s something to live up to. Something to be owned.

The main thing I dislike about being a ‘Builder’ is that it doesn’t imply much in the way of… well, much of anything beyond the mechanics of putting the code together. All the deep thought having already been taken care of by the Design team. All the fiendish logic being hewn from the very living rock by the Back-end Application Development team. We in the middle, just stacking the bricks.

Well, f*ck that.

You want semantic information architecture so cunning you could brush your teeth with it? You want accessibility bleeding from every nook and cranny of a site, not just a crappy compliance icon in the footer? You want dynamic behaviour that works as much for the people who aren’t interested in it, as for the people who are?

Then speak to a Science Ninja Interface Developer at your earliest convenience, peoples.