Google-driven Web Development, Chapter 1
Accessible and Useful Design
It's a question I've asked myself numerous times in the last year. Why write a book on Google?
There are no shortage of books on the Search giant. O'Reilly has the excellent Google Hacks and Google Maps Hacks; Syngress has Johnny Long's Google Hacking for Penetration Testers. There are books on AdWords, Analytics, and PageRank, and as many or more on Google's business and history. I particularly like The Search for a tour of Google's early days. But all of these books fall cleanly in one of three categories.
- Tips and tricks with Google's sites for developers
- Tips and tricks with Google's sites for regular users
- How to understand Google's business and technology roots
There are clearly parts of Google that are not covered in any of these topics. One such area is the extensive list of APIs Google makes available for programmers and web developers. In fact, my interest with Google really originated with the release of their SOAP-based search API. About the time I was writing my first command-line search tool, Gmail started taking off, and then Google Maps, and there was a whole world of possibilities in these JavaScript-based sites. Namely, that you could see the code and hack at the sites yourself. And then, the list of APIs began to grow as Google launched it's Open Source program. So just for fun, I started doing a tutorial at LinuxWorld on using these APIs, how Google used JavaScript to create rich browser-based apps, and other related ideas.
This book, obviously, grew out of that tutorial and tries to fill a different space than the other Google books available. As the beginning of Chapter 1 goes:
Google's mission is to organize the world's information and make it universally accessible and useful. Google's efforts at organizing information on the web are well documented. There are many books and websites concerned with Google's server cluster, its search index, and company policy, and indeed, these elements have helped Google create an index of the World Wide Web that is second to none. This is, however, only one-half of Google's mission, and I would argue, only one-half of what attracts users to Google. The other-half is the web sites that make that amazing index accessible and useful to others. In this chapter, we begin by examining how it is that Google makes information accessible and useful. We'll look generally at Google and its history and specifically at the design of google.com itself.
After including an image of an early version of Google's home page, I note:
From the very beginning, Google set itself apart for the simplicity of its own web page. The emphasis was meant to be on the information to which Google provided access. Remember, too, that the system was originally designed to just rank keywords against the index. There was no need for anything else, so why add it to the web page?
Notice that there are no categories, no services, no news headlines, no weather. Nothing but a simple text box and prominent logo. Nothing but search. Figure 1-2 shows an example of the Google homepage today. Although there are links to alternate services and searches, the homepage remains remarkably uncluttered. To begin a search, just type in the box and click “Google Search."
And from there we talk a bit about Google's roots in Academia and some of the philosophies that underpin Google's choices in design and development. While this is not a book on design philosophy or aesthetics, I do argue that Google puts its users first, which is the key to creating useful and usable web sites and applications. Several of the elements -- like a minimal, uncluttered interface -- on google.com continue to reappear in other forms on other sites.
But this is a tech book, right? So we do get into technical matters, too, even as we lay the foundation for the rest of the book. We talk about Google's search operators and special syntaxes and also how Google uses CSS and JavaScript to enhance search, not as technologies for their own sake. For Google's homepage, JavaScript is used minimally.
function qs(el) { if (window.RegExp && window.encodeURIComponent) { var ue=el.href; var qe=encodeURIComponent(document.f.q.value); if(ue.indexOf("q=")!=-1) { el.href=ue.replace(new RegExp("q=[^&$]*"),"q="+qe); }else{ el.href=ue+"&q="+qe; } } return 1; }
This script may look quite cryptic, but its job is simple. The function qs() is called when any of the links other than the Google search submit buttons are clicked. The el passed to the function is the element that was clicked. If the RegExp and encodeURIComponent objects are available the query is encoded to be used for a URL and the element that was clicked's href attribute -- the link itself -- is replaced with the encoded query string now added to the link. Certain charters are not allowed in URLs, like spaces and ampersands, so this function makes encoding this within the browser easy. In fact, without JavaScript there is no way to ensure a properly encoded URL from within the browser.
This function also exists to further the goal of accessible and useful design. If you have already entered your query terms into the main Google search text box, and then decide you want to search for images instead of web sites. When you click the images link above the text box, your query is encoded and passed along to the image search page, without you having to re-enter the search later. A useful feature indeed! And one made possible by a simple use of JavaScript.
Contrast this with JavaScript usage in Gmail and Maps, and you'll see two very different approaches to JavaScript usage. Although, both are done from the same prespective, "to organize the world's information and make it universally accessible and useful". In Chapter 2, which I'll preview in a week, we really get under the hood of Google more, looking at the JavaScript UI engine that is Google's successful webmail site.
Posted by deryck on February 5, 2007
