Wednesday, December 10, 2008
Google Chrome's Agile Design and Development
With Google Chrome doing something strange for a Google app, exiting beta, BayCHI's December talk by Glen Murphy, Google Chrome's designer and an engineer on its front-end team, becomes a little more topical. Glen gave a very good presentation. Nothing revelatory, but I thought there's a lot to learn from how they organized their development team, especially for those looking for successful agile projects inside big companies.
- The reason for building Chrome was to create a platform that can run increasingly complex web applications in a browser as well as desktop applications run in an OS. To make this a reality they identified two primary goals: speed and reliability. All included features had to be fast and reliable.
- Building compelling web applications requires making features feel fast. The user should be able do everything they need to do fast. We'll see how this impacted the OmniBox design.
- The need for reliability is what made them decide on the isolated tab model. Content is organized around tabs and each tab runs in an isolated environment so the failure of one part won't bring down another. The idea is each tab could be considered a separate application.
- The team had a single organizing principle: content, not chrome. The idea here is that content, what people care about in your typical web app, is wrapped by too many layers. You have an OS, browser application, web application, and then content. Each of these layers distances the user from the content and imposes another layer of interface to navigate. Chrome wants to collapse the layering. This vision is what guids them when making design choices.
- The content vision led them to some places you might not otherwise go. That's the power of a central organized vision. It's generative. It helps you creatively form something that feels like natural, like that's the only way it could have been implemented. You see this in the combo box, tabs, coloring, and lack of many traditional browser features.
- One goal was no dialogue boxes. Didn't work out in practice, but through user testing they found nobody paid attention to dialogues so it's better to figure out how not use them. One audience member asked if they had removed the evil Fire Fox dialogue box that appears after a crash on startup asking if you want to restore previous sessions. He seemed quite peeved that FF wouldn't start until this dialogue box was appeased. The FF team assured him in 3.1 it has been removed. I was never annoyed with dialogue box, what annoyed me is that it pointed out a design weakness that your open windows were not treated as a collection that had convenient operations on the collection. Chrome solves this problem by not remembering your open windows (boo) and using tabs as the central content organizing metaphor.
- User testing found that most people don't use most of the commands available on the browser so they do away with them. 85% of people use back, 50% use reload, 33% open a book mark. So do away with the rest and focus on the content.
- The team is multi-disciplinary: designers, users, and engineers. This allowed them develop a tight feedback loop where changes happened in Chrome quickly because there wasn't a layering of responsibilities that required long cycles to work through. Engineers who are designers can be trusted to make good implementation decisions. Designers that are engineers can be trusted to keep in mind how plausible it is to build responsible features. So there were no large design documents. There were no wire frames or prototypes. Chrome started very simple (a few draggable tabs) and evolved over countless iterations of feedback from the team, Google employees, and user studies.
- Engineers attended usability tests so they could see how people were using the product in real-life. It turned out even 1 pixel changes in tab heights, for example, could radically change usability because it effected the ability to select a tab. These are the sort of things that you get from real life.
- Usability studies were used as a data driven approach for solving arguments about how features should be implemented. What angle is best for tabs, for example? They generated over 1600 different versions and tested them.Yet, they also used their gut for decisions like what color the frame should be (blue). No testing was done.
- Their goal was to have Chrome feel natural and intuitive. So they went with native Windows conventions and implementations where ever possible. Which is why I assume the Mac version will take some time to implement. They just aren't porting a single look and feel. Chrome will have to change to match how the Mac works so it feels natural on the Mac.
- The OmniBox design brings all the goals of natural, intuitive, speed and reliability together. This is the single box at the top of the browser that allows you to enter a URL or a search term and Chrome will do the right thing. There's no difference between navigation and search. Through user testing they found multiple boxes for different kind of searches just made people randomly try different boxes, so they went with one box. The design though is not obvious. When multiple terms are searched for it's relatively easy to tell if it's a URL or a search term. They look for top level domains etc. When a single word is entered, like "pie" it becomes impossible to tell because there could be a local machine called pie that someone wants connect to, not a search for pie. Since 99% of people are really searching for pie they make search the default action. In the background they check if there's a machine called pie on the network and if there is they'll offer that as an option, remember their selection, and make that the default interpretation going forward. A very nice solution. It takes a lot of often unappreciated work to bring this seamless a feel to features.
- Another design point of the OmniBox is what options are displayed in the drop down box. The found that people don't pay attention to drop down boxes and most people only go to 10 or 15 different sites a day. So the autosuggest function isn't a surrogate search function. Search results are not displayed in the drop down, that what the tab is for. Autosuggest is designed to shorten what users want type which shortens their work. Only a few of the most plausible options are displayed in the drop down list. This feature is was developed in a tight loop which allows the feature to behave naturally to the user. No big spec was developed over several months of tedious meetings. Instead, what was natural was discovered through use. What wouldn't work and was quickly iterated until the solution converged.
- If people on the team show an aptitude in a certain area their interests are fostered. People aren't locked into a single role.
- Without detailed design docs QA is difficult. Developers write extensive unit tests. The QA people are engineers and would watch code changes, read the changes, and write tests to the code. As new features are implemented developers are expected to announce them so everyone stays synced. This is a very difficult way of working for QA.
- Development and design happen simultaneously. Changes are made to an actual working product. When developing new features the thought is that using the real thing is the only way you truly know if it works or not.
- An emphasis was put on "surfacing" features. It's not like tabs are original with Chrome. Far from it. What Chrome does is surface tabs as a first class feature. When Chrome starts two tabs are created so people know the tabs are there. When a new link is opened it opens in a tab. There's a + sign next to the tabs so it's obvious how to create a new tab. Tabs can be selected and dragged. Tabs are the top of the frame instead of below several browser toolbars. This is part of the content not chrome ideal. So using tabs is natural and obvious in Chrome and that's a very conscious part of the design.
- Chrome is Open Source but they aren't sure what that means yet or how it will work. It's hard to be open and control everything at the same time.
- Google has lots of groups like usability, graphics, security, QA, etc. It's hard to compete with all those resources even though the core Chrome team is probably pretty small. Google strangely doesn't like to say how many people are in a group. It's that whole open-closed tension again.
- Extensions are on the roadmap, but it's not clear how to do extensions in way that meets all their goals for Chrome. Adding 10 layers of toolbars to the browser hides the content. How cant that be done cleanly?
The word "agile" wasn't mentioned in the presentation, but they are describing a very agile way of working. Small multi-talented groups working in tight iterations implementing features based on vision and customer feedback. Working code is valued over documentation. The result is a quality product with a very comfortable and natural feel. Thanks Glen for the excellent talk.
|| © Copyright
3/12/2009; 12:58:55 PM.