StartPad Countdown 5 - Google Geo: Mobile Mapping

Editor's Notes

• #3: We're going to talk about the options for various devices.  Though we're all excited about the iPhone and Android and the other devices coming to the market with fully-featured browsers, I'll mention solutions for non-JS enabled devices. The static maps API, which I'll go into greater detail about, provides a solution for the lowest common denominator: it requires no JS and so can render in any phone browser.  Users cannot interact with it, but it at least gives the ability to show locations on a map. Native APIs provide for a slick user interface and take full advantage of the phone's hardware. And then there's the JavaScript API that is officially supported on iPhone, works pretty well on Android, and has the potential to work on other high-end browsers.
• #4: Since the browser has so many issues with both startup and interaction  performance, why not just create an application using client APIs?  The  experience of using the native API on the iPhone is bound to be smoother.  At Google, we've found the web browser to be incredibly powerful.  Downloads introduce a steep barrier to entry.  And how many times have Mac users asked when their favorite Windows application will be available for them?
• #5: Since the browser has so many issues with both startup and interaction  performance, why not just create an application using client APIs?  The  experience of using the native API on the iPhone is bound to be smoother.  At Google, we've found the web browser to be incredibly powerful.  Downloads introduce a steep barrier to entry.  And how many times have Mac users asked when their favorite Windows application will be available for them?
• #7: Has streetview, polylines, and much more
• #8: There are a number of issues that make developing in a mobile browser tricky. User interface: The iPhone and Android-based devices have changed the way we are able to interact with maps.  We are working to make the browser based maps experience as smooth as a native application.  We introduced touch and multi-touch functionality in v2.  Mention touch events, desktop components, clickability, webkit
• #9:    A. server side      1. our servers are fast - serving the files takes negligible time compared to other causes of latency.      2. Distance is a factor. Consider finding local caches for your data if you have users in distant lands (like Australia).    B. download time is limited by bandwidth. Detecting low bandwidth users and serving them appropriately downgraded data (particularly images) can have profound impact. Bandwidth on high speed mobile devices (3g) is good - download time is a fairly constant but small factor in latency (numbers for 10kB, 50kB, 200kB file)    C. parsing/execution time. On both iphone and android devices, parsing time is severely slower than on desktop machines. This is cpu bound. As devices have more processing power, this may improve, but we're designing for today's devices. (Numbers for 10kB, 50kB, 200kB file)
• #11: A. Compiling/obfuscating: Because parsing time on the iphone and android are so slow, obfuscate/compile your code to significantly reduce code size.   (Mention publicly available js compilers?)    B. Download as few scripts/images as you need.  Keep in mind that there is overhead in each download, so the balance between breaking the JS apart and making fewer requests is important.
• #12: A. Compiling/obfuscating: Because parsing time on the iphone and android are so slow, obfuscate/compile your code to significantly reduce code size.   (Mention publicly available js compilers?)    B. Download as few scripts/images as you need.  Keep in mind that there is overhead in each download, so the balance between breaking the JS apart and making fewer requests is important.
• #15:    A. takes Xs to load on the iphone over wireless, Ys over 3G    B. design: uses an MVC (model-view-controller) design to download only the state storing models initially. When objects like Map or Marker are instantiated, the modules required to render their views are downloaded asynchronously    C. first requests a static map to reduce user perceived latency. Then makes that map draggable even before tiles have necessarily loaded    D. expected increase to initial download per feature (how much did marker and infowindow add?)      1. untangling of modules: map knows nothing about marker or infowindow or marker about infowindow. You can have as many infowindows as you want and they can be associated with any object that inherits from our generic MVC object known as MVCObject.    E. basic development should be as simple as v2 (although interface has changed so it may seem awkward at first!). We've exposed the basic object that all of our models and views inherit from. This allows you to create rich applications fairly simply. We've become big fans of MVC while developing the new API. See how simple it is to create the OverlayMapControl. In v2 that took X lines of complicated state tracking.
• #16: One of the most obvious differences between desktops and mobile devices that has not changed even with the introduction of full-featured browsers is the size.  Designing a mobile applications remains a different and challenging task.  Whereas on a desktop, you may be able to expose a map and content on one page, you may prefer for your map to fill the page and expose extended content on user action.  We have worked to enhance the mobile maps experience in the v3 API by detecting the map size and ensuring appropriately sized controls are used by default and that info windows are bound by the map size.
• #17:    A. takes Xs to load on the iphone over wireless, Ys over 3G    B. design: uses an MVC (model-view-controller) design to download only the state storing models initially. When objects like Map or Marker are instantiated, the modules required to render their views are downloaded asynchronously    C. first requests a static map to reduce user perceived latency. Then makes that map draggable even before tiles have necessarily loaded    D. expected increase to initial download per feature (how much did marker and infowindow add?)      1. untangling of modules: map knows nothing about marker or infowindow or marker about infowindow. You can have as many infowindows as you want and they can be associated with any object that inherits from our generic MVC object known as MVCObject.    E. basic development should be as simple as v2 (although interface has changed so it may seem awkward at first!). We've exposed the basic object that all of our models and views inherit from. This allows you to create rich applications fairly simply. We've become big fans of MVC while developing the new API. See how simple it is to create the OverlayMapControl. In v2 that took X lines of complicated state tracking.
• #20: One of the most obvious differences between desktops and mobile devices that has not changed even with the introduction of full-featured browsers is the size.  Designing a mobile applications remains a different and challenging task.  Whereas on a desktop, you may be able to expose a map and content on one page, you may prefer for your map to fill the page and expose extended content on user action.  We have worked to enhance the mobile maps experience in the v3 API by detecting the map size and ensuring appropriately sized controls are used by default and that info windows are bound by the map size.
• #21: One of the most obvious differences between desktops and mobile devices that has not changed even with the introduction of full-featured browsers is the size.  Designing a mobile applications remains a different and challenging task.  Whereas on a desktop, you may be able to expose a map and content on one page, you may prefer for your map to fill the page and expose extended content on user action.  We have worked to enhance the mobile maps experience in the v3 API by detecting the map size and ensuring appropriately sized controls are used by default and that info windows are bound by the map size.