Rethinking Google's Banner Area

Explained...

One interesting design problem that's presented when dealing with critically accessed pages like Google is tradeoff. Meaning: An interface feature that could add weight to the page could place significant stress on overall bandwidth and server resources owing to the large number of downloads.

For fun, I just wanted to see if I could achieve a balance between the addition of event-based-feedback and Fitts'-Law improvements and the resultant total character weight. I found, surprisingly, that I could make some changes and actually lighten the page.

The changes and their net weight change:

1. Moved logo to root (-7 chars)
2. Changed HREF of nav images anchors to no slash (-12 chars)
3. Changed button value from "Google Search" to "Search" (-14 chars)
4. Changed logo size from 200x76 to 158x60 (-424 bytes)
5. Changed cellpadding of the tabs TABLE from 0 to 2 (No weight change)
6. Removed dark gray cells in the tabs TABLE (-310 chars)
7. Added underline hover to tabs TABLE links (+38 chars)
8. Added "tt" id to top links cell and added bottom padding (+31 chars)

Net weight change: Trimmed about 1KB. (Specifically: around 698-972 bytes depending on the character set of the page.)

I also altered some HTML and CSS to mimic what I suspect is the result of server-side application logic regarding Netscape 4 and charset ISO-8859-1. These changes would not actually have to be implemented for the above changes to work.

1. Changed charset in META from UTF-8 to ISO-8859-1 (+5 chars, this setup only)
2. Added comments to hide Netscape-breaking CSS (+9 chars, this setup only)

This experiment brought to you by Massless.