Redesigning Google’s search results page Jan 25th, 2004
I am intrigued by the CSS Zen Garden. It’s a great exercise, and a great contribution to the design community. It got me thinking about other sorts of design exercises that could be useful to folks out there looking to stretch their design muscles.
So in the same vein, I tried a redesign of my own.
To start, the project I’ve chosen is Google’s search results page. This is a page that has become fairly ubiquitous to anyone using the world wide web. So ubiquitous in fact, that to make any changes to it you might quickly realize how hard it is to work through a redesign since you and everyone you know is so used to the current one.
But that’s all part of the fun.
[Disclaimer: This exercise is for educational purposes only. Google owns it's trademark and copyright.]
Now, before you see an example page that I redesigned, let me go over my constraints:
The redesign must be XHTML and CSS valid.
GIFs used must stay below 20k total.
Redesign must accommodate current features of the search results page. Functionality may be added or expressed in a different model than presented currently however.
Rendering of must work in the latest versions of Internet Explorer, Safari, Netscape/Mozilla and Opera.
No CSS hacks allowed.
I did not concern myself with the technical issues that I would be faced with if I worked at Google on how to address legacy browsers; I’m assuming that the technical issues can be solved. I also adjusted the HTML structure as long as the displayed content stayed the same. Unlike the CSS Zen Garden, this exercise is not strictly about variations on the same content using nothing but CSS.
The style sheet is included inline to my example, so just view source of the page and see what I did. And please be kind on the coding. I haven’t had a chance to optimize the CSS inheritance or HTML structure to make everything as slim code-wise as humanly possible. If anyone wants to tackle optimization of my result, be my guest!
So, here was my rough one day shot at it. Basically, I didn’t really attempt to do what I would consider a true redesign, opting to focus on just cleaning up the presenation of the current model for my first pass.
To start, I created an elastic-based layout that also allowed the page to move into compliance with W3C standards. I then went about doing many minor tweaks to try and take away as much excess line and pixel noise as possible. After that, I broke up as much of the even pixel-color coverage as possible to make the page more scannable. I kept the branding and color scheme approach, not wanting to offend the throngs of people out in the world who think Google is fine just the way it is.
Is my redesign more usable? I doubt it is significantly more or less usable in the true sense of the word, although I’m sure many people will react viscerally to it just because it’s different, even if only slightly. Is it more aesthetically pleasing than Google’s current page? I did only a moderate amount of clean up work this first pass, trying to keep true to the spirit of the site’s current simple design, so I’m not sure if it is or not. (It looks better to my eye on Safari, but a good deal of that has to do with Safari and the Mac OS’s superior font rendering.)
Here is a complete list of changes I made to the design, for better or worse.
Do not fear white space
You’ll notice the redesign uses more white space than the current Google site. The current site crams everything together, and has always felt claustrophobic to my eyes.
In this redesign, a gutter has been added around the entire page to move away from the edge. Margins have been placed throughout to add just a touch of white space everywhere, creating a cumulative effect. Lastly, extra space has been added in favor of using dashes in the results, making it easy to scan the uri, file size, cached and similar items.
Excess [line noise] kills
I’ve always disliked the fact that the web standard derived for links is underlines, instead of just using a consistent color, maybe some bolding and reasonable cursor or rollover feedback. Underlines render even moderately good typography attempts on the web into a nearly unreadable heap of line noise. To compound the problem, the notion that links must be underlined and be that horrendous default blue in order to be easy to use was propped up like a house of cards by expert sites like Useit.com.
Now, having said that, note that I did create a CSS class just for the main results as an escape hatch. Truth be told, this would be one of those cases where I would present the design sans all the underlines, and only put them back in if the outcry was so loud and the pain endured by users so great, and I didn’t feel like fighting the good fight that particular day. The change is after all, one CSS value.
Get your money’s worth!
If I was paying for advertising on Google, I’m not sure I would want the supposedly prime spot at the top of the search results list. The top two ads on most Google pages are crammed between a blue bar, which has fairly useless text, and the first result of the Google search. By being placed here, these ads can be one of the easiest things to over look.
I would need data to confirm this, but the spot I moved them to tends to stand out better, especially with the color coding. Further, by putting the ads to the side, it allows the new design to display the same amount of results above the fold while still using more overall white space.
Nickel and diming
You’ll notice many minor tweaks to the text and content itself.
I removed all of the extra leading ellipses. They do nothing but interrupt the search results, and provide minimal amount of usefulness.
I removed all extraneous bolding, only bolding items found in the light gray textual results.
I nuked extra text labels where possible, like the “Categories” label. In the case of categories, the breadcrumbing nature of the links should be plenty to indicate what is going on. (I didn’t do a news example, but I would also nuke the “News” label in that case as well, as the item explains itself reasonably well.)
I moved the “dissatisfied with your results” text into the bottom bar.
I added non-breaking spaces in strategic spots to help with the liquid nature of the redesign.
There’s probably some others I’m forgetting right now.
So, here’s the second iteration.
I used a refinement from Ben Listwon’s on my first pass as the best place to start. To read his changes, please refer to his description of the changes he made. Below are my changes and thoughts around them.
I had used too much bolding in my first effort, which was a result of choosing bold as the link metaphor. Ben’s pass had corrected this, and it’s much better. I went ahead and put back dotted, light gray lines as the link metaphor, as I still feel that using dark solid lines reduces the readability of the results.
“To clarify, add more detail”
You’ll notice that I changed the manner in which the search results are displayed. I left the first five results as they are today, but then changed everything else, while adding up to a 100 results per page. Before I explain why, let me offer this quote:
Visual displays rich with data are not only an appropriate and proper compliment to human capabilities, but also such designs are frequently optimal. If the visual task is contrast, comparison, and choice — as so often it is — then the more relevant information within eyespan, the better. Vacant, low-density displays, the dreaded posterization of data spread over pages and pages, require viewers to rely on visual memory — a weak skill — to make a contrast, a comparison, a choice.
Micro/macro designs enforce both local and global comparisons and, at the same time, avoid the disruption of context switching. All told, exactly what is needed for reasoning about information.
Edward Tufte, Envisioning Information, page 50
Using Tufte’s concept about micro/macro readings that to clarify, you add more detail, I added 100 results to the page, but I truncated each one after the first five to just the title. I put the description for the remaining results into a title tag, which still allows it to be available to the user. (In the mock-up, I only added the title tag to results 6 through 25.) I don’t know about everyone else, but I find that I infrequently go past pages 4 or 5 using the Google pagination widget. Tufte is right about context switching, when I do go past page 4 into pages 7 or higher, I often find it hard to remember which page to return to that contained a certain link.
This new design places many more results on the page, which should significantly reduce context switching between pages. I think it would have the added benefit that people would more often examine more of the results, even going into the two or three hundred range more often.
As a final benefit, I think this single page would work using the 80/20 rule. That is to say, that 80% of the time, users would never need to go past the first 100 search results to find what they are looking for, only needing this one single page for most their search needs.
In adding more results, you’ll also notice I replaced Google’s branded pagination widget. The new one loses using the Google logo as a visual device. Some users might lament the loss of the fun use of the Google logo in this manner, but I think there are other ways to bring that branding sensibility back into the design. Something I will focus on my third iteration.
For now, the new pagination widget works on multiple levels. I use it to break up the results into more readable blocks, while also helping to mark where a result lives in the context of the search. By duplicating the widget throughout, it also reduces the need to scroll to the top or bottom of the page if the user wants to navigate between sets of results.
Using Douglas Bowman’s excellent article, Sliding Doors of CSS, and in keeping with the goal of making this new design follow web standards, I added a graphical tab treatment, but did so using CSS. Since I lost the images for the original Google pagination widget, this falls within the rules. It is also a place where one can add back in some of the fun of Google’s brand.
I’m not sure I like the treatment yet, but will explore other ideas here in the next iteration.
One of the things about the Sliding Doors model for tabs that Doug doesn’t mention in his article is that the entire tab is clickable. This has always been the downfall of many tab attempts in web applications. Often, the text itself might be clickable, but not the tab graphics, or there might be some tricks employed to make the entire area clickable, but it didn’t work on all browsers. The Sliding Doors approach fixes all of that. You get a cursor over the entire tab, it scales, and it works no matter where you click. Brilliant!