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.
Techniques ( or what and how )
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.
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.
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...
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.
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 )
Last but not least thanks to Gilles Ruppert for editing my post.