Mule Design Studio's Blog: Ads are Content

Please read this piece about ads on your page, it makes a good point that the ads are part of your brand. And that you should pick them with care, not accept anything a banner farm throws at your site.

Mule Design Studio's Blog: Ads are Content: "The ads you allow on your site are part of your brand."

In my opinion this also is true about the speed you want to give your visitors. Still too many banner farms ( I won't name and shame, but you know how you are. ) and ad agencys don't do anything about speed. Using for instance extremely slow javascript solutions to serve the banners. At one of my clients I tried to convince them to just give us some xml or json and let us place the banners from the link provided by them, but they didn't wanted to do that. Hiding behind tracking the visitor 'cause it was important to them, the continued to worsen the experience we could provide for our visitors.

In fact it was so bad the the load time was multiplied by 5 with banners. FIVE times as long, all because they wanted to track users to better their experience...

ANWB.nl revamped

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.

Technorati Tags:, , , , , , , , , , ,

just browsing and found (6)

May 02, 2008 0 Comments
Tagged: , and

Because it is friday and I am working,

I will put up a decent post when deadline season is over. Should be in a couple of weeks...

Technorati Tags:, ,

redesign

in progress and this time it's live. Check every few hours to see the design form slowly...

  1. step 1 setting up reset.css and looking at how to customize the php...
  2. step 2 setting up css after sleeping on a design..wnas-website-20080322.png
  3. Tweaking the css for almost a day now, got it asides from some usability issues. The logo (which is the a inside the h1) is clickable, but I got a h2 with the blog name not a link. In order to solve that I gotta throw a lot around in the php. Not used to dabbling in php anymore, so step lively now...
  4. Now for a break, will look at the icons and javascript after this, in no particular order... Site is now build using only two images (besides the ones in the articles), no javascript so just POSH..

Is web equal to print? (aka : The Question)

Warning, rave ahead

The past 10+ years, I have been building web applications and sites. And with me coming from a print / graphic design background, you inevitably get The Question popped to you one way or the other. The question is what drives us, kinda like in the matrix. And it is:

Is web equal to print?

The people who ask me (or us if you are fellow web worker) this question have different background. They are skilled project managers, very talented graphic designer and even user interface designers that ask The Question.

The Question can be asked in many different ways, it kinda depends whom it comes from...

From project managers you hear it like this:
  1. I want this to look exactly the same in every browser.
  2. It looks kinda funny on my computer (with strange settings), but don't spend any time on accessability. Just fix it!
From graphic designers you may hear something like:
  1. I really want that header in Baskerville SemiBold Italic font.
  2. Make sure that you align this the same no matter what.
  3. Just make it look like my psd.
From user interface designers you get:
  1. This is not like my visio.
  2. I don't care what the browser does, do it like I said

The strange thing is that a lot of these people have been around for quite some time doing web work. And they still don't know what the answer to The Question is.>

If you really want to know, I will provide you with a gentle answer:

the answer

So take it from me, if you want a happy, productive web worker. Don't ever asume that you know the answer to The Question is anything other than I just provided for you.

We as web developers are being hired for our skill, so use it and ask us before you assume anything about your design.

No project managers, graphic designers or user interface developers were harmed writing this post

Technorati Tags:, , , ,