I’ve just about finished my first site of 2011 and as ever learnt some things along the way.
Lesson one: Killing IE6 only makes things slightly easier
The Internet hates Internet Explorer 6. Not supporting it was a weight off my mind but look at your browser list without it and you’d be forgiven for not jumping for joy. I can’t remember the last time I didn’t have to make something with gradient backgrounds and fades nevermind, the now standard, rounded corners and drop shadows.
So, positives, I get to use descendant selectors and multiple classnames and feel like I’m programming and not throwing vague rules around. Negatives are I still have far too many background images, I’ve got Raphael to draw SVG and fall-back to VML, and jQuery so I don’t have to write three times as much JavaScript to do things.
Update: I forgot to say that you should use the button tag where previously you’d use input type submit, do it, if only so you can put the span inside the button so it looks right when you focus on it!
Lesson two: Do not be afraid of SVG
SVG are in my opinion one of finest parts of the modern day web toolkit. You can keep your CSS transitions (lets face it, they’re propriety and there is too much code for them… keyframes though, they’re good) and your webGL (all very Flashy, in that it looks like it’s not going to interact well with the other page elements).
The code to create the lines and curves of SVG takes a bit of a jump but if you can keep your mind in it’s coordinate language (I wish the 0,0 point was bottom left not top left, I was going loopy trying to draw the graph axis) then you’ll soon be comfortable. I just wish my maths was better. Although if it was maybe I’d prefer webGL
Lesson three: Use events to communicate between logical parts of your application architecture
I’ve been a fan of event driven programming for a while but I’ve struggled to come up with a good example for using it, but I think I finally have one!
The key part of this project was that we were visualizing data, and that that data might change dependent upon a user or server action. By separating the data from the controller or elements that use it we can simplify our connections to the data and compartmentalize it’s operations. The events come into play when those data stores are updated, we broadcast that data has been updated using a traditional event, if a controller has registered to listen for that event then it will perform it’s action from that point. It’s an alternative to registering the handler directly to the data update function, leaving the responsibility on the listener itself rather than the class handling the data updates.
Lesson four: Learn for the next one
I may have exclaimed that the lightbox was the finest I’d ever built, most of the styling and positioning done through CSS etc. But of course it’s not that simple, I’d used position fixed so when suddenly we got some long lightbox designs it’s not going to expand the page beyond the viewport. Turns out the JavaScript controlled one I did last year worked better in the real world. Lesson learned