ANWB.nl revamped
html css javascript
Introduction
The past 9 months I have had the pleasure and the privilege to work on one of holland's biggest websites, ANWB.nl. I had a lot of fun and learned a lot. I also had the pleasure to work with a great team and I thank you guys, you know how you are.
As this was the biggest jobs I have ever done, I will take the time to share my experience with you.
History ( or why )
ANWB had been working with a custom built cms and it began to show the wear and tear of being used and added to in too many years so they decided to go for a complete rebuild. What it lacked was a plan during the development phase was a master plan, so all of these nice features worked against each other. The worst thing was that is was slow ( and to me, that it produced really horrible front end code ).
First we researched on what kind of cms they needed. After some time we decided on Hippo, a dutch open source cms. This had some implications: as hippo does not come with a front end right out of the box, so we had to build one ourselves. The reason for that is obvious, once you look at it. Hippo manages content and does that really well. They let others serve that content so that they can focus on their job.
They asked me to do the front end, - css, html and javascript - and to help others in that field by coaching and teaching
Techniques ( or what and how )
Cocoon
We built the front-end using apache cocoon, which turned the xml from hippo into decent (or so I think) xhtml. The XHTML is only about the structure, not about presentation or behavior. This helped us to built some really versatile and robust templates. There are only 7 templates that serve several thousand pages, so versatile they had to be. Quit a few had some overhead in them that made it even more important that they were robust.
We also used cocoon and the yui compressor to concatenate and minify the js and css files, something that greatly reduced the number of http requests. It also gave us the freedom to write well documented code and seperate the code into a large number of small files. Each of those files is for something different : we got js files for small functions with half the filesize being comments. When we serve it to the customers, they only get one file instead of 50, without any comments in it which would only increase the file size.
HTML
The html was one of the most important bits of the site, as all of the other stuff (css and js) can't work well with it. The XHTML is one of the most important parts of the front end design, as it is the base upon the other two (CSS and js) work upon. It was refined during several revisions as requirements got clearer. It is one of the >aspects of this project that I am proudest of.
It is valid xhtml 1.0 transitional and as semantically correct as possible. So : no .redborder2px classes in the css or superfluous div's (thinking of a large dutch bank...). Not everything is perfect, but most of these things come from third parties, so they are out of our control. The bad thing is that some of these (banners and iframes) multiply our loading time by an x-factor, but alas, that is the real world for you.
Everything should work in all major browsers (we did a variation of the yahoo browser support). In fact the development started on firefox and safari on a mac and IE testing started only after 4 months of building.
Now if we only could educate the editors how to write proper markup, but alas. That is one of the disadvantages of a real world job: you never know how people will use it.
CSS
The CSS is also as valid as possible, though it is not completely valid, as we used various CSS versions, as well as some IE specific stuff. The IE declarations are all nicely tucked away in its own conditional stylesheet and no more than the absolute minimum of declarations were used. quite a feat for such a large site...
Javascript
The javascript was done with jQuery but some older applications still used some prototype that we had to rewrite.
Prototype extends some of the native javascript functions in the global namespace, so this collided on some occasions. We rewrote some of the prototype code like prototype.extend to prototype.prototypeextend so it would play nice with the rest of the javascript code.
We made sure that the javascript was as unobtrusive as possible, something that worked out well in pages we had control over but not so good in the older applications... We also used event delegation which helped us to increase the performance.
Overhead
The real challenge lay in incorporating the more than 40 different applications into the new templates, css and javascript. Some of those were written in the middle ages and the average origin of these was about 1873. What they produced in html is not quite what we wanted and we had a lot of fun tweaking stuff until everything was working.
We also learned a lot from this, stuff like rewriting parts of prototype and jquery for instanceneeds rephrasing, not clear. We also had to check the javascript that wrote parts of the page and correct the invalid html with even more javascript. Some had js to close unclosed div's which provided a challenge...
As an idealist I wanted to rewrite those so called applications, but as a pragmatist I didn't (at some urging from the project manager). The cost would have outweighted the benefits but hopefully some will be rewritten in a proper fashion soon.
Conclusion
At the end of the project we can look at some nice results, the total amount of http requests has gone dramatically down. We started with as much as 15 external css files and 10 external js files, which we reduced to one. We also managed to get rid of all of the inline styles and scripts as well as tables for layout. With that we reduced to average filesize of a html page from 170kb to 25kb, something that speeds things up for our customers.
As we took all of the presentation and behavior out of the structure, the resulting pages are more flexible : so maintenance should benefit from this.
Thanks ( or whom )
During this project I had the pleasure to work with some of the best in their fields. I also could use the work of the builders of jQuery and the knowledge of yahoo!, without which I would have been lost. The project was lead by some great project and program managers, without whom our work would not have been as stress free.With javascript issues I could turn to the expertise of a co-worker and for cross browser stuff I had a master to help me.
Last but not least thanks to Gilles Ruppert for editing my post.