Google I/O

May 30, 2008

For the past two days I have all been in San Francisco attending Google I/O - Google's first annual conference dedicated to web development. They covered topics along the lines of Ajax and Javascript, Google's API's and Tools, Maps & Geo, the Mobile Web (including Android), Open Social, and a slew of other micro topics. What follows are some of the the most applicable takeaways I brought back:

On Ajax and Javascript

The founders of Ajaxian gave a "State of Ajax and Javascript" talk right off the bat. The discussion focused heavily on javascript frameworks and their applications. Although their are hundreds of well implemented JS frameworks, there are really only 4 major player: Google Web Toolkit, Dojo (with Dijit), Prototype (with Script.aculo.us) and jQuery (with jQuery UI). In the past, each major framework had a specific use and could be assigned to specific tasks. Today, however, all 4 include essentially the same layers (a core, an ajax framework, and a ui toolkit) and can be used based simply on preference.

Personally, I use jQuery exclusively on new development because of it's lightweight, css based selector structure, and easy to use Ajax implementation and this choice was entirely validated at the conference.

Perceived performance was hit on quite a bit in the seminar as well. Humans can perceive delays in interactivity as small as .1 second and a train of thought can be broken (enough so for a person to leave a site) when delays reach the 1 second mark. This applies directly interactive work. You need to really sit and think whether an animation or transition is really key to a site's success and weigh that against the possibility that it could be perceived as a loss of performance.

On Accessibility

A large part of what I'm trying to achieve is universally accessible website and web applications and who better to listen to a speech on accessibility than a blind software engineer? The Chief Engineer for everything Accessibility was on hand giving a lecture on making websites more universally accessible and it's larger implications and first hand accounts of what it's like to be a disabled web user. Developers today don't have to choose between Ajax and accessible websites, using some new techniques including broadcasting updates, scoping targets, navigation keys, and even client side JS frameworks, fully accessible websites can be easily achieved and having more accessible websites doesn't just assist disabled but power users as well, allowing shortcuts and quicker paths to more frequently used features.

On Performance

Steve Souders, creator of YSlow and the YSlow rules for website performance, gave an amazing talk on creating faster websites. Alternative techniques for loading script and style data into a webpage were presented that we hadn't ever thought of. Some so amazingly simple and effective that I've started implementing them on current projects before even leaving the conference.

As it turns out, 80-90% of page load times are client side, meaning http requests, executing javascript, and other front-end matters. These can all be sped up dramatically by utilizing parallel downloading and execution, splitting the payload between what's needed on load versus on demand, and rearranging your load order to prevent blocks in the browser waiting for execution and DOM rendering.

Progressive rendering was also heavily pushed. Instead of holding back certain data, waiting for an entire page/site/section to be loaded and then presented to a user, give users items to interact with as soon as their ready to be rendered. On the whole, most users will begin to interact with a page before loading has completed and by holding back data until every last item is ready to be rendered out is only detrimental to the user experience.

On Search

In what was probably the most informative seminar of the conference, we had a chance to listen to a google engineer discuss developing sites to be more searchable. We got to hear first hand that, as far as search goes, flash is essentially a black hole for search bots. Developers shouldn't stop using flash, but should start using it sparingly, or instead as a content delivery mechanism instead of containing the base content itself. What this boils down to is progressive enhancement: start with a base page that is completely indexable (like HTML or XHTML) and then use flash on top of that to add to the user experience. Serving content directly through flash is essentially putting it into a black box that search bots can see into.

Some quick tips to help maximize searchability:

• Appropriately title all pages
• Add meta descriptions to help with search result displays
• Give images appropriate titles and always fill in their alt text
• choose www or not (http://www.example.com or http://example.com) and redirect from one to the other. don't have duplicates of the site at both
• Avoid keyword stuffing
• Implement robots.txt and use sitemaps xml files to assist in crawling

There are a massive amount of tools provided by google that can help to tweak and fine-tune page ranks and get the most out of google's indexing that can be found at Google Webmaster Tools

On Google Practices

Google's obviously the king of search, but they also do a lot of other things internally that really make them stand apart from most other businesses. A big part of that is what they call 20% time. Each employee is given a day out of the week to develop on their own without set schedules or deadlines or project teams or anything like that. They are free to explore their passions and generally have fun with development. It keeps them fresh and engaged and benefits the company tremendously. In the past year half of all launched Google products (including Google News, Feed Reader, Google Calendar, and many more) began as 20% time projects. Keeping people interested in what they are doing is the perfect way to foster a creative environment where great ideas are what push the industry forward.

Internal project are also an extremely large part of Google. They've developed their own filesystem, their own database, even their own internal distribution of the Linux kernel to solve development issues that spanned the entire business. Products like Google Web Toolkit (a javascript framework) and Google App Engine both started out as internal libraries used to assist development. I think this would be a great way to push the envelope of your own development practices. Maybe develop and data providers or content management systems to help rollouts of new pages, work on more serious component frameworks for flash or other heavily used platforms, build up your code and utility libraries across all languages so you're not catching rourselves re-inventing the wheel with every client. Even the smallest of projects have the potential to one day grow into something that might change how you handle all of your development and that's the sort of thing that will keep us out in front of the industry

All in all, Google I/O was a great experience. If you'd like to talk more about any of these topics, check me out on twitter or shoot me a message