Disappointed is what I would say in a word. In learning about Google's design process for their Chrome browser, I was certainly less than impressed at finding out about a fully agile development for software. Google happens to be in a lucky enough environment to have really smart teams and large enough where you can do a big software project that way. However, after having worked in agile environments, I find it causes more headache than help.
Things I learned at this BayChi talk:
1. Google Chrome renders HTML & CSS like Safari
2. There is no revolutionary content model for Chrome. It's an evolution as a faster browser
3. Rapid usability studies really helps in an agile environment if you can spare the resources
Here are my raw notes on the Google Chrome design process:
Designing Google Chrome
- Glenn Murphy
Functionality - Tab Isolation
- Core function, if one tab crashes, the other tabs keep running
Functionality - Omnibox
- Core function, combined Search and location bar
Why?
1. Speed & Reliability
- control their own Google application
- needed a better platform for these applications
- current browsers weren't fast enough so web apps would be 2nd class citizens
2. Better Framework
- Old OS -> Application -> Content
- Current OS -> Browser Application -> Web Application -> Content
Top features used by users in their browsers:
(researched in a one week period)
- Back 85%
- Reload 50%
- Open Bookmark 33%
UX Researcher - Rick Boardman
Cognitive Walkthroughs
Lab based studies
Longitudinal studies
Design Process
- no wireframes
- went to multiple iterations of mock-ups
- designed from final design
- all tabs belonged on the top because information flowed down from them [Arthur: it seems like they didn't really explore other options]
- This overall design was like a tabbed windows explorer. The frame is just glue to stick tabs together
- Thought: What if one of those tabs was iTunes? It should work the same
- Played with 60 types of tab variations and experimented with exact degrees. [Arthur: this was a trial and error and based off of their own judgement]
- Colour of tabs was chosen as something that was neutral but visible separation.
UX - Frame (Graphic designing)
- Frame: Experimented with multi-level tabs, single level would get crowded. Settled on half way between one and two level tabs. [Arthur: Did they test this?]
- Frame: The colour of the frame couldn't use the windows style b/c it would look strange. In research, they found frames in Windows are blue. For something to feel intuitively grabbable, it would have to be blue. Blue also blends into default windows backgrounds (as it should, so you can ignore it)
- Frame: Windows Vista you can ignore that blue b/c they have their own native version.
- Frame Testing: Using a small title bar, people were not able to find out how to drag the frame in user testing. Users aimed for the blue.
UX - Omnibox
- Testing found that users often type URLs into the search bar.
- So they wanted to combine it.
- Hardest to figure out was a single word search.
- One solution was a type-ahead drop down.
- In user studies they found that people didn't follow drop downs. Users look down at their keyboards to type.
- Solution: Search (and try to navigate in the background)
- It takes a while to figure out if that single word URL exists so the check happens in the background.
- Puts a message asking the user if they want to visit the URL www.pie.com
- Autocomplete helps people get to sites that they visit again. Found that users visit 10-15 sites per day.
- The engineers doing the functionality for omnibox was done with rapid iteration. [Arthur: This may be useful for really smart teams but in most cases, you can't iterate that fast]
- Some initial mockups of the type-ahead show more information. e.g. flight detail, snippets of sites, suggested words, history of your search
- They didn't want this list flickering around and typing around. They wanted the user to just finish typing in their query
- Would rather put this on a page so users could see this content and then use the back button
What's next?
- Extensions
- Wants to stop people from adding toolbars so it doesn't look crazy.
- If a user wants to add a toolbar we should let them. But the next exercise is to figure out how to allow the user to not create a mess
- Openness: How do you design in the open?
- Openness: How do we allow users to give feedback to Google yet not put it out in the open web?
Questions
1. Where are the PMs?
- They're scattered throughout
2. How do you QA if no one reads your design docs?
- The QA always watches the code and they design tests as the code gets done
- If an engineer writes code, they let people know it's there and QA catches up
3. Have you tried different graphics on the tabs?
- Yes, we have a large graphics design team
- When they spoke to "people" the angled tabs resonated better.
- Internal to the team, people were into angled tabs, people used to work at NeXT and they were comfortable with angled tabs.
- Chrome was in development at the same time it was designed. The height of the frame above the tabs, they played non-stop for about a year. Kept changing between 15-20 pixels. They would get feedback from people instantly, emails & IMs.
4. If content is new, how do things change with open source. Will it be grassroots change?
- I don't know. There's another team that is in charge of this
5. The Google toolbar is missing from here
- These are the things that belong as extensions
6. How is Blue a grabbable colour?
- We winged it.
- It's what felt natural
- We didn't run user studies
7. You mentioned dropping iTunes into a tab. Is this something you'd keep addressing?
- With the exception of powerpoint, everything i use is online apps
- sometimes I wish I could have tab management
- we're not planning on addressing, but we things tabs are a better way of managing content
8. Rendering
- Go faster on certain benchmarks
- On reliability we track how we crash
- Speed, we think we've met it
9. Render on multiple browsers
- didn't want to add an additional engine
- benchmark against safari
- there will be some pain in the start but we should be compliant with safari and anytime it's not please log a bug against chrome
10. You've put alot of emphasis on tabs. Did you think about the discoverability of tabs?
- Other browsers do an omnibox but don't surface it as much.
- Tab usage is 78% adoption in Chrome
- In firefox, they show 2 tabs on startup
- Some people don't use multiple tabs. People who are curious can find it.
11. Other complicated design issues?
- Users never notice anything you do. You tell them to notice the lock and they never do
- Even if you throw up a screen that says the page you are about to visit isn't the one you think, users will still ignore it.
- Users respond to the full-screen popup
- We're trying to figure out how to keep them safe without annoying people.
- Sometimes there are sites that have malware but I still want to visit them
- We tried to hide the Omnibox and it turns out you do. One of those reasons is for security. Our Google security team jumps on our backs everytime we send out mockups
12. Can you not ask us everytime you restart that you want to restore the tabs? How often were you doing testing?
- Initially we had a mandate to design a browser without any dialogs
- Aza Rafkin says that they're getting rid of it in Firefox 3.1
- Started user testing 1/2 way through the product.
- Testing intensified at the end.
- Cognitive walkthroughs happened anytime there was a question they couldn't answer
- Lab based studies were done at every implementation when they needed questions.
- These weren't new to many of us
- They were useful in settling arguments and they tracked user comments
- The comments they got internally look like comments they get out in the wild.
