Lars Rasmussen - Google Maps

• Consider integration between native app and web app to deliver both convenience and richness
• The native sexiness not available to web apps will shrink
• Explosive growth in 1 day is unlikely for downloadable applications
• Google: The only thing that is required is that something is useful to users
• If you can attract large numbers of users, there will always be a way to monetise it

• End user is royalty
• Go beyond the browser Lowest common denominator - the functionality and implementation doesn't have to be the same for all browsers
• eg: overlay direction lines: in firefox is a generated at the backend as a transparent png; in IE it is done with vml
• Do what it takes! Harness the power of optimism. If you're not crashing the browser, you're not pushing it hard enough.
• Launch early & often; harness the power of your users to get attention and market feedback - Google maps got around 5,000 emails a day when it launched
• Web applications allow rapid fault resolution
• The pain of cross platform/browser web development is still far less than the pain of cross platform native application development
• Web deployment allows rapid deployment of bug fixes which in turn allows earlier (ie. riskier) releases

Lars then gave us a short insight into some of the implementation details including the map tiling and hidden iframe based navigation.

• A problem is that you are doing things beyond the design intentions of the browser eg. forward/back/print buttons
• When you are implementing application sexiness, you need to be careful not to break the simplicity of the browsing experience.
• Harness/Link the forward and back buttons to what the user would expect - try it in IE/google maps. Removes the need for popups

• Google implementation: content navigation happens in an iframe - the iframe browsing history are recorded within the IE history, as does the content of edit fields (not true in all browsers)
• attached an event handler to the iframe, when it changes, put that content into the main page, hide the iframe (I assume the link still needs to target the iframe), also need handler to copy the input field from the copy back into the iframe
• when copying the content, the urls are rewritten to target the iframe

Lars also spoke about the rise of google map hacks, the problems that lead to with their content providers and, as we know, the happy ending that is the google map API. There are some interesting outcomes of public access to your code (which is unavoidable with a jaascript based product).

• www.busmonster.com
• bloggers will describe your design more accurately than your design document
• you WILL be reverse engineered - design your models and publish an API to avoid the pain & encoourage a community to build around you [Mark's thought, not from Lars' slides]
• rss feed to code.google.com featured project link
• after 3 weeks of the api being published, there are 2,500 developers in the discussion group

Future Gazing

Short term

• renewed interest in AJAX

Long term

• increased access to host machine resources
• better development tools
• secure 'greasemonkey' like extensions (loaded javascript has the same access as the viewed page eg. cookies) - the browser needs a richer security model
• need more flexibility to control the behaviour of the next/back/print/save buttons etc.
• But: need to maintain the simplicity of 'surfing' experience

moon.google.com !!

• Choose a development model that suits your application

• demo's have a much bigger impact within google that requirements document
• the process becomes more formal as the product becomes more mature (& therefore has more to protect)

• Google mission statement: organising information.