Glen Murphy who is Google Chrome's designer and an engineer on its front-end team gave a talk at the BayCHI monthly meeting

Backgrounder
Glenn started out stating what we already heard via the press, that Google had no plan to author a Browser or any other desktop ambitions that complete with Microsoft. However (and you may find this hard to believe), Google is the most secretive software company I know in Silicon Valley. The Google culture is absolute secrecy about products and road maps. Even when employees leave Google, they are bound to confidentiality. I have close friends; they cannot even tell their girl friend any of their work. Consequently Glen passed little anecdotal data (only slip ups).

Designing Google Chrome

Design
* Content not Chrome
* OS > Browser > Web App > Content
* Removal of unnecessary features (home button:)
* From the outset, design team shared a common thinking, tabs on top navigation. (Flow down navigation, natural for HCI)

Tab Isolation
* Tabs led naturally to process isolation, which met the main motivation goal for investment; increased speed and reliability for feature rich browser based apps.
* The very first working version had one tab. Striking resemblance to the released Chrome
* Tabs drag and drop, even drag between Chrome instances
* Tabs angels, 1600 generated in Photoshop. Color Blue felt right, angled tabs felt right. (Attention to detail = iteration until just right)

Omni Box
* Search & location bar combination
* Multi word query Cheese.com – URL / Cheese.js – NAV (works like a charm)
* Single work query is the challenge - PIE (British pie or BI pie?)
* Omibox solution - attempt to navigate & search in the background (parallel very fast, versus 5-6 seconds for sequential)

Development process
* Team size (could not say), very large team at Google
* All developers have design experience, all designers have development experience
* Tight loop iterations (back and forth) white board and talk-talk specific meetings with the team, allows subtle edges incorporated into Chrome most efficiently.
* Mock ups as written specs, no one read the specs. No wire frames. Meet and make design objectives clear, get consensus, and full formed simplest working example, test it.
* Chrome Target platform design goal Windows XP (not Vista or MAC). Notice this in the

Slip ups
* Development ethos, work faster than any other company.
* No ETA for Mac. Said Googlers found the XP blue revolting on the MAC. Tester refused to continue unless they can change XP blue.
* Acknowledged the entire Firefox team was present (I saw 6-8 guys tops)
* Reduce Back button navigation by 85pct (remove default back button). Reduce Reload by 50pct (make Reload button less obvious). Reduce Open Book mark (make book marking less obvious). Hence the design of Chrome thumbs nails.
* Look up at your browser, do you see Content or tool bars? (showed a ridiculous browser tool bar, half a page of menu layered plug-ins, slide 55 in presentation)

Takeaway
During my Windows career orchestrating ERP, product marketing always came running with the latest Microsoft Office looks and navigation. They wanted the same Office design in ERP. Now I see product mgmt caught up the same, satisfying customer expectations in Web ERP created by transliterations in web search engines. Where Google has broken the mold with Microsoft is to rethink carefully the user experience for navigation and the technical experience for speed and reliability. Combing the two experiences into Chrome (a brand new product). I feel we do the same on Web ERP and other products where profitable. Producing the best design by thinking and making, by reducing, by getting mad when it's just not right. This is the luxury of creating from brand new. Later on, when customers are familiar using apps, making design changes (even if needed) becomes more difficult (people don’t like change). Making incremental changes (can work).

Possible steps for ERP
* Omibox navigation.
* Removing features from ERP. I know by experience, harder to do than taking a bullet in the head (have to start from scratch).
* Creating new products requires centralized teams, distributed is too much process overhead like specs without sparks and getting mad.