MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you:
By Scott Knaster, Google Developers Blog Editor

Hey, wanna start a band? A new Chrome Experiment, JAM with Chrome, lets you play music in a web app and jam with others online in real time. You get to pick from 19 different instruments, including drums, guitars, and keyboards. Once you get really good, you can use shortcuts on your (computer) keyboard to play your instrument.



When you’ve had enough fun making music with your friends, you can explore how JAM with Chrome works. Take a look at the tools and technologies that were used to make this app, and for details, read the case study. Then you can decide whether you want to build the next great web app or become a rock star instead.

Speaking of stars, scientists have astonishingly figured out how to learn about light from every star that ever existed. Researchers used the orbiting Fermi Large Area Telescope to look at distant galaxies and measure photons from various places around the universe. This data goes back to the formation of the first stars more than 13 billion years ago.

Finally, back on our own planet, you might have noticed that Google Maps recently added more building footprints to map displays. In case you didn’t count them, over 25 million new building footprints have been added to both desktop and mobile versions of Google Maps. Maybe you’ll see the new footprints while exploring your favorite city this weekend.


On Fridays we detour slightly from our usual posts and publish a Fridaygram, a fun compilation of nerdy stuff to amuse you (and us). And how cool is it that we have orbiting telescopes?

2013, By: Seo Master

Seo Master present to you:
By Ken Hoetmer, Product Manager, Google Maps JavaScript APIs

We’re constantly working to build the most comprehensive, accurate and usable maps in the world for our users--no matter where or how they access Google Maps. While millions of people come directly to maps.google.com to search for a nearby business or get directions, many people around the globe experience Google Maps on their favorite website or application thanks to the Google Maps API (and some very talented developers). In fact, today 800,000 active websites and apps are using the Google Maps API to create interesting and useful experiences for you.

MoreThanAMap.com
To demonstrate the capabilities and features of the Google Maps API, today we’re launching a new website called morethanamap.com. This site showcases the unique features of the Google Maps API and how developers are using it.


Through morethanamap.com you’ll learn how developers can embed popular Google Maps features like Street View, public transit directions, location data, and advanced data visualization capabilities into their website or app. The interactive demos on morethanamap.com show how these features are ready to be added to any website or app.


Even if you’re not a developer, the animated London Heathrow flight map or global population heat map are a fun way to visualize data and explore the power of Google Maps.

Google Maps Developers Stories from Around the World
Morethanamap.com also features stories from our community of developers who are using the Google Maps API to start businesses, help improve their communities or save the environment. Starting next week we’ll showcase these stories weekly on the Geo Developers Blog. And follow us on Google+ to learn more.


With just a backpack and a camera Google Maps team member Carlos Cuesta went on a global tour to video blog six distinct developers who are creating thriving applications with the Google Maps API.

Start exploring what’s possible with the Google Maps API today at: morethanamap.com.


Ken Hoetmer is Product Manager of the Google Maps JavaScript APIs, based in Sydney, Australia. A long time Maps API developer, he claims to have been the first external user of JavaScript Maps API v3.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Scott Knaster, Google Developers Blog Editor

While many of us have been on vacation recently, our maps team has been keeping the world informed with new features and data for travelers and locals. Just in the past couple of weeks, there’s a bunch of new stuff, including:

• Voice-guided, turn-by-turn directions and live traffic info added for thousands of towns in India as part of Google Maps Navigation (Beta).
• Biking directions in New Zealand. Plus, bicycle people can use Map Maker to add or edit bike lane and trail information.
• New street view images for more than 150 university campuses, adding to more than 100 that were already available.

Maybe the Maps folks are taking holidays after all. It’s just that they’re mapping the places they visit.

Speaking of traveling and mapping, no human-made object has traveled farther from Earth than Voyager 1. Now 35 years and two days into its journey, Voyager is nearing the edge of the solar system. We Fridaygrammed about that once before, and we told you that Voyager was leaving our system soon, but now it looks like Voyager is taking its sweet time in departing, and it might be two to three more years before it exits into interstellar space. We’ll keep on top of this story for you.

Voyager is going where no one has gone before, and the man who introduced us to that phrase received his own quiet tribute earlier this week from the U.S. National Hurricane Center. Nicely done, Forecaster Cangialosi. (And we’ve done our own tribute in today’s Google Doodle.)


Code: the final frontier. These are the posts of the Google Developers Blog. Our mission: to seek out Google developer news, except on Fridays, when random nerd fun takes over. Your mission: have a great weekend!

2013, By: Seo Master

Seo Master present to you: By Dion Almaer, Google Developer Programs

It has been a busy week as usual, especially for those interested in the world of Geo.

In API and developer-product news...

Base diving with Google Gears covers an application that we built that searches Google Base and saves the information with Google Gears allowing for off-line use.

The Safe Browsing API was released, which allows your application to use the API to download an encrypted table for local, client-side lookups of URLs that you would like to check. Now you can stop phishers and malware abusers.

Guicing Up Your Testing is the first article in a series on Google Guice by our own Dick Wall.

The Google AJAX Feed API's Slide Show Control is now available as a Google Gadget.

The mapping world was busy as always:

• Add Traffic to Your Mashup (Button + Legend, too)!
• Three new KML resources up
• Set Country/Viewport Restrictions in your GClientGeocoder for More Tailored Results

Around Google

T.V. Raman has discussed his experience using the new open source OCR that we are working on, comparing it to commercial alternatives that he uses.

Put your business on Google Maps with the Local Business Center which has launched a new look.

The Linux Foundation Collaboration Summit took place at Google last week. For more information read the wrapup article.

Google Tech Talks

Semantic Web: The Semantic Web is a field aiming a the creation, deployment, and interoperation of machine readable data on the Internet. In the talk we present some projects in DERI on Semantic Web technologies - notably Semantic Interlinking of Online Community sites, Social Semantic Collaborative Filtering, and ActiveRDF, a library for Browsing, programming and navigating Semantic Web data.

View more tech talks.

Podcasts

In Google Developer Podcast Episode Four we had the chance to interview Mark Limber on Google SketchUp, and how developers can use the Ruby, C++, and other APIs.

The OpenMRS Project: You'll get a chance to learn from Paul about the history of OpenMRS, life as a brand new organization in Summer of Code, and the social change uses of open source in developing nations.2013, By: Seo Master

Seo Master present to you: If you attended Google I/O 2009 a few weeks ago, you may have noticed a kiosk station on the 2nd and 3rd floors of Moscone West labelled 'Interactive Conference Map, powered by Google Maps'. The kiosk simply pointed to a JavaScript Maps API-based interactive map of the venue I created in my 20% time.

Now that all the I/O session videos and presentations are live, we took the opportunity to mash up the videos with our interactive conference map to provide developers with an alternate way to navigate through 80+ keynote and session videos, and bring the action at I/O to life virtually. For example, here are videos of sessions that took place in Room 1 (click the tabs for Wednesday and Thursday sessions). And here's where the keynote sessions took place. Check out where we filmed interviews with I/O sandbox developers on their apps, technical challenges and business best practices.


Now, hopefully you enjoyed using the map and are now thinking, "Cool, I want to do something like this for my next event!" (or your college campus, or such). If you are, then good news everyone, I've open sourced the interactive conference map and all relevant resources. Inside the project, you'll also find a how to article outlining the steps I went through to create the map.

If you attended I/O, then I hope you enjoyed it and had time to stop by the conference map kiosk! If not, no worries, just make sure to check out the open source project and see if you can use the code and/or techniques in your next mapping project!

By Roman Nurik, Developer Programs Engineer2013, By: Seo Master

Seo Master present to you: By Dion Almaer, Google Developer Programs

This week it felt like the day after the wedding. The developer day was complete, and now we need to move on, gather up the feedback from the community, and start on the real work of producing APIs and tools for you all.

In API and developer-product news...

DragZoomControl v1.0: Easier zooming, coming right up!

Andre Lewis has contributed his GZoom control to the Google Maps Utility Library which is a set of useful additions to the Maps API, distributed under an open source license. The new control is DragZoomControl, and does what it says on the box.

New KML Developments and Documentation

Mano Marks told us about the new documentation available that tells us about how to get Google to search your KML files, and the release of KML 2.2 beta reference material. KML will now support use of the Atom Syndication format atom:author and atom:uri elements for attribution.

AJAX Feed API Slide Show Enhancements

Mark Lucovsky upgraded the AJAX Feed API Slide Show to allow you to tweak the experience by using various callbacks that let you hook slide transitions, clicks, etc. For an example, he created a slideshow view
of PodTech that allows you to play videos inline as the appropriate image shows up.

Around Google

Google Calendar Gallery

The Google Calendar Gallery helps you find public calendars that may interest you. Plug in the Red Sox schedule, or the Netflix release dates, directly into your calendar.

FeedBurner Acquisition

FeedBurner lets you manage your feeds in interesting ways. You offload the traffic to the service, can add features on top of your own feed (enable Podcast on the fly, advertising, etc), and see great statistics on how your users are using it. We are proud to have the FeedBurner team part of the Google family.

Featured Projects

San Francisco Giants Mashup

Paul McDonald, of the Google Mashup Editor team, has put together a nice mashup on all things SF Giants. As with all Google Mashups, everyone is open source, and you can "view source" on anyones application. Take a peak at this example to see how you can use the mashup editor to do some sophisticated application building.

Remember The Milk Offline

The Remember The Milk team had an advantage. They were in Sydney where we released Gears, and they were obviously on the case. They quickly released an offline version of their TODO list application.

Google Tech Talks

Java on Guice: Dependency Injection, the Java Way

Bob Lee has been traveling the world speaking on Guice recently. This week he got to give his talk right here in Mountain View, and it was recorded for your viewing pleasure.

Hey, What's That? A Map Hack

Michael Kosowsky came to chat about his cool Maps application that lets you see what you could see from a high point (e.g. Longs Peak). Fun math and visualizations indeed.

Podcasts

Google Developer Podcast Episode Three: Mike Tsao on Google Gears

We got to interview Mike Tsao of the Google Gears team on how Gears came about, the design decisions, and lessons for developers as they go about offline-enabling their applications.

The Mono Project

Miguel de Icaza was joined by three former students for Mono: Aaron Tomb, Alan McGovern and Michael Hutchinson. They chat about the past, present, and future of Mono and what the summer of coders are working on now.2013, By: Seo Master

Seo Master present to you: Today we’re releasing videos from the Tech Talks and Fireside Chats at I/O 2010. A look back on each track:

Tech Talks:

From new programming languages to venture capital to 5-minute lightning talks, the Tech Talks track at I/O was a veritable potpourri of geeky goodness.

You can find videos and slides for the Tech Talks on the linked session titles below:

• Go programming - The Go programming language was released as an open source project in late 2009. Rob Pike and Russ Cox discussed how programming in Go differs from other languages.


• Opening up Closure Library - Closure Library is the open-source JavaScript library behind some of Google's big web apps like Gmail and Google Docs. Nathan Naze talked about the library, its design, and how to integrate it in with your setup.


• Optimize every bit of your site serving & web pages with Page Speed - Richard Rabbat and Bryan McQuade talked about Page Speed, an open-source Firefox/Firebug Add-on which allows web developers to evaluate and improve the performance of their web pages.


• SEO site advice from the experts - Matt Cutts, Greg Grothaus, Tiffany Lane, and Vanessa Fox offered SEO feedback on a number of actual websites submitted by the audience.


• Beyond design: Creating positive user experiences - John Zeratsky and Matt Shobe shared their tips on how to keep users coming back to your applications through a positive user experience.


• How to lose friends and alienate people: The joys of engineering leadership - Brian Fitzpatrick and Ben Collins-Sussman regaled the audience with tips on how to lead vs. manage.


• Ignite Google I/O - Brady Forrest and Ignite returned to I/O with an awesome line-up of speakers - Ben Huh, Matt Harding, Clay Johnson, Bradley Vickers, Aaron Koblin, Michael Van Riper, Anne Veling, and James Young.


• Technology, innovation, computer science, & more: A VC panel - This year was the first time that we had investors/VCs speaking at I/O. Albert Wenger, Chris Dixon, Dave McClure, Paul Graham, Brad Feld, and Dick Costolo (moderator) debated hot tech topics including betting on start-ups with non-technical founders and open vs closed platforms.
  

The Tech Talk videos are also available in this YouTube playlist.


Fireside Chats:

In the 9 fireside chats at I/O this year, Google teams were eager to talk about the latest ongoings with their respective product areas, as well as spend most of the time on audience Q&A.

This year, we decided to record fireside chats because we know how popular they are not just with I/O attendees, but everyone interested in hearing from the engineers behind our products. You can find videos for the fireside chats below:

• Android Team


• Android Handset Manufacturers


• App Engine Team


• Google Chrome Team


• Enterprise Team


• Geo Team


• GWT Team


• Social Web Team


• Google Wave Team

These videos can also be found in this Fireside Chats YouTube playlist or the YouTube playlist for each session track. (ex. the two Android Fireside Chats are also in the Android playlist)

On Monday, we’ll be posting the last batch of I/O videos from the Geo, Google APIs, and Google Wave tracks. Stay tuned!

Posted by Christine Tsai, Google I/O Team
2013, By: Seo Master

Seo Master present to you: By Dion Almaer, Google Developer Programs

We have published the second episode of the Google Developer Podcast, just in time to get you ready for Google Developer Day which kicks off this week.

This weeks episode discusses:

News for Google Developers

• Check out the latest schedules and information about the event. Check the location!
  
• JavaOne recap: thoughts about the show, and the Google booth
• Discussing the new AJAX Feed controls
• Our thoughts on Searchology and Universal Search
• The new YouTube API blog was announced
  
• Featured project: GWT Maven Support
• Featured project: Hey, What's That?

Interview with Pamela Fox of the Google Maps team

We want to thank Pamela for taking the time to chat to us about Google Maps, and the Google Maps API.

What you will learn from Pamela:

• Her role, and background
  
• A little history on the Google Maps API
  
• Information about mashups
  
• How you can overlay map content such as MapWOW, Lord of the Rings, and your own
  
• How to be hard code with custom tiles, to give you a full level of detail
  
• How to use simple ground overlays
  
• About the Google Moon API
  
• How KML and Google Earth fit into Google Maps
  
• The magic of GGeoXml()
  
• What the Maps group is going to be doing for developer day
  
• How to use the JavaScript API
  
• How you can use Maps from within GWT, Rails, and other platforms
  
• What's GMap2, and how does the API handle versioning
  
• Enjoying the scroll-wheel zoom
  
• How My Maps fits into Google Maps
  
• How Google Maps helped launched the Ajax meme
  
• Pamela's favorite recent Maps mashups (bones, crop circles, and more)
  
• The sample code available in the gmaps-samples
  
• Using the Google Spreadsheet Data API as a data store
  
• Understanding the limitations on Google Maps API use
  
• What are the hidden features in the Google Maps API that people tend not to use
  
• Why you should GLog
  
• What the common issues that new Maps API users come across
  
• Best practices for developing Google Maps Mashups

You can download the episode directly, or subscribe to the show.

As always, please contact us to let us know if there is anything that you would like to see on the podcast.2013, By: Seo Master

Seo Master present to you: This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Sanjay Vakil, founder of LuckyCal.

1.0 Introduction
LuckyCal is a new sort of calendar service that takes advantage of the web -- and about a dozen Google APIs. LuckyCal reinvents calendaring software by transforming calendars from staid repositories of information into a dynamic, anticipatory, interactive tools, making each appointment a search query and in the process changing your calendar into a concierge.

Ok, enough marketing speak! The real problem is that like anything really new and shiny, LuckyCal can can be a bit tricky to explain. The best we've been able to do is this video:



From a technical standpoint, LuckyCal subscribes to the calendars owned and published by its users and analyzes those calendars for time/date/interest information. LuckyCal uses the inferred location of the user to find events, friends, bands, and teams that are near where the user will be and which the user will find interesting. With this, LuckyCal publishes a new personalized calendar to which the user can subscribe which is full of "Lucky Events" based on the locations of the original events.

2.0 Google Calendar Data
Early iterations of LuckyCal used iCal and retrieved calendars from Google Calendar's "magic URLs". However, after some fits and starts, the team at LuckyCal switched over to using the Google Calendar Data APIs instead. We got several benefits from this: security, granularity, access to multiple calendars, repeating events and more.

Luckily, Google Calendar allows access to more of the "raw data" of the calendar. Each calendar has its own meta data and a collection of events. The calendars are represented via XML with a well-defined schema. Each individual event is also represented via XML. Using a secure mechanism (discussed later), LuckyCal can retrieve calendar and event data from the correct "feed", manipulate it, mine it, and then generate new events.

2.1 Recurring Event Feed
One of the most useful elements of using the Google Data APIs is the ability to access the same information through multiple feeds. Each feed provides a different view of the same data. While it is possible to get the native form of each event, it turns out to be much more useful allow the team at Google to do the heavy lifting to avoid some of the sharp edges of the calendars' API. In particular, one of the most useful capabilities is to avoid dealing with recurring events.

Recurring events are stored as a starting event with an "RRULE" which specifies when they are to be repeated. Unfortunately, the language that defines this repetition is baroque and difficult to understand. This is partly because it has to deal with many edge conditions: if the Geek Dad Dinner fell on Christmas, we'd probably cancel it. That exception -- that a specific instance was cancelled -- needs to captured as part of the recurring event.

Thankfully, the Google Calendar Data API "unrolls" repeating events, completely with exceptional and edge cases and then gives a view into this events for a given calendar based solely on a time range. The complex mess of recurring events is effectively hidden from the developer and we simply get a list of events that we know are occurring.

2.2 Creating new Events
As discussed earlier, LuckyCal creates new events for its users. These events are grouped together into a single new calendar so that they can easily be accessed and hidden and so that they do not detract from the primary calendar usage.

Creating new events is a good deal more difficult than reading a feed of existing events. Constructing a POST request that is correctly formatted and authenticated is tricky primarily because of escaping issues. Between the various escape characters that live in HTML, XML and the authentication encodings, it can be difficult to cleanly create an event which works.

Our advice is to start off with a simple, working example of simple text and slowly add complexity one step at a time: add a link, then an HREF, then a quotation, then an apostrophe and so forth. The reality is that there are many characters that end up having to be escaped and the majority of them will end up in the body of your events -- especially if those events are generated by your users.

3.0 Security
Calendar data is sensitive. Where/when people are going to be is intensively personal information. The body of events -- what you're doing there -- may be even more so. Google recognizes this and provides secure means to retrieve data and allows the user to maintain control over services that have access to their data.

Early on, LuckyCal used AuthSub to retrieve data. We've since superceded AuthSub with OAuth. The latter has the advantage of being more widely supported and of being the future of Google third-party authentication strategy.

Perhaps the most valuable characteristic of OAuth is that LuckyCal does not have to ask for -- or retain -- our users' Google Account passwords. Instead, we retain a LuckyCal-specific token which provides us access. Enabling developers to interact with Google Account information without having to convince users to trust us with their passwords is a huge advantage.

While there are a number of libraries available that implement OAuth for various languages, we ended up building our own version in Ruby. If you decide to attempt this, a useful tool to be aware of is the Google OAuth Playground which has recently been open-sourced.

4.0 Geocoding
LuckyCal works at the intersection of a Calendar -- time -- and the implied location of its users -- space. In order to find location information, LuckyCal uses Google's Geocoding facilities.

LuckyCal hands a textual description -- as found in the "where" fields in a calendar entry -- to the service and gets back a canonical name and latitude/longitude information. We also get back a measure of how accurate the information is: street, city, state, or country. This is critical to LuckyCal as it gives us a sense of whether the location is accurate enough to warrant trying to find nearby events for.

Another thing we've learned is that the Geocoder can easily get confused by extraneous information. As an example this address works perfectly:

"1600 Amphitheatre Parkway, Mountain View, CA"

But this one fails:

"Google at 1600 Amphitheatre Parkway, Mountain View, CA"

The latter is a completely reasonable example of what a user might enter in the "where" field, and it would be a shame not to be able to find that location. At LuckyCal we use some very simple algorithms to find addresses which are not canonical enough for the geocoder to recognize: we tokenize the address by spaces and commas and construct a set of new addresses that remove tokens from the front of the description until we have a match.

In this example, when "Google at 1600 Amphitheatre Parkway, Mountain View, CA" failed, we'd drop back to "at 1600 Amphitheatre Parkway, Mountain View, CA" which also fails, and then to "1600 Amphitheatre Parkway, Mountain View, CA" which succeeds.

This can lead to problems: removing the earlier section of an address can reduce its accuracy. We're lucky: LuckyCal only needs city-level accuracy.

5.0 Maps API
LuckyCal uses the Maps API to build the centerpiece of our web page showing our users what to do while they're on a trip.



Using a web-native client to view this information is wonderful -- we can render HTML directly in the info bubbles and allow users to interact exactly as they'd expect.

6.0 Conclusion
LuckyCal uses Google's APIs in a number of different ways to provide the best possible experience for our users. Given that our service pushes the envelope of what people expect calendars to do, it is gratifying to have access to a range of tools that streamline some portion of our efforts.

Guest Post by Sanjay Vakil, LuckyCal2013, By: Seo Master

Seo Master present to you:
By Scott Knaster, Google Developers Blog Editor

On Fridaygram we love to celebrate amazing new Street View images. This week we announced new panoramic views of the Galapagos Islands, collected with with the Street View Trekker in partnership with the Charles Darwin Foundation (CDF) and the Galapagos National Parks Directorate (GNPD). These images will go live on Google Maps later this year, but you can see a preview below and on the Official Google Blog.

The Maps team’s 10-day adventure included lots of interaction with local wildlife, but didn’t take place entirely on land. The team worked with the Catlin Seaview Survey to collect underwater ocean images too. And in addition to being beautiful and fun, these pictures have a practical use: they act as a visual record that can be compared to changes observed in the future.

Speaking of wildlife, do you have a smart dog? And does your smart dog know 1000+ words, plus have a basic comprehension of grammar? Meet Chaser, a 9-year-old border collie who has been taught to recognize the names of 1000 objects, as well as the meaning of some verbs and prepositions. In tests, Chaser correctly (most of the time) responded to commands such as “take ball to Frisbee”, or even “to Frisbee take ball”. If only our friends and family were that helpful.

Finally, there’s some typically mind-blowing news from the world of quantum physics. We already know that quantum particles can share a connection called entanglement, which allows one particle to reflect the state of another no matter how far apart they are. Now an experimental discovery shows that particles can be entangled even if they don’t exist at the same time. We agree with experimenter Jeremy O'Brien of the University of Bristol, who said “It’s really cool”.


Fridaygram is about randomly cool and nerdy stories that we hope will amuse you and possibly inspire your weekend. Around here we’re still feeling the Google I/O afterglow, so we’re going to recommend you spend some time this weekend watching some of the many session videos from I/O. If that’s not your thing, maybe you’d like this brief but inspiring video that kicked off the conference.

2013, By: Seo Master

Seo Master present to you: This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Sasha Aickin, Engineering Manager at Redfin.

The oldest saw in real estate is that the three most important things about a house are location, location, and location, and at Redfin we took that as our user interface mantra as well. We made a decision early on that we were going to build a dynamic AJAX web app where the Google Map wasn't just a feature of the application but was the main driver of user interaction. The map is how users tell us where they want to search and what houses they are interested in buying, and our users tell us time and again that the map is what keeps them coming back.

That being said, we've made a lot of mistakes along the way, and I thought it might be helpful if I shared a few of the lessons we've learned over the last few years about building a map-driven UI:


#1 Always Be Thinking About Speed

Rich web apps that mash up many different APIs can be incredibly powerful, but after a while you'll start to look with a gimlet eye at every new API that comes down the pike. Why? Because every new API you add makes your site vulnerable to slowdowns, and your users will punish you for slowness.

Some of these slowdowns are inevitable, but many can be avoided by clever use of code loading techniques and HTTP caching. My best advice to people who ask me what they need to know before building a fast AJAX site? Follow everything that Steve Souders does. Read his book ("High Performance Web Sites"), follow his blog, and go to every talk of his you have a chance to. You'll learn how to defend your site's speed and delight your users.

#2 Carefully Consider The Full Screen Map

One early design decision you have to make with a map-driven site is whether your site is more like an app or more like a web page. Apps don't have scroll bars, and they resize all their controls when the browser resizes. Google Docs, 280slides, and Redfin are all examples of app-like sites, as is the main Google Maps site. Web pages, on the other hand, feel like documents. You can scroll through them, they often don't resize in a dynamic way, and they remind you more of a Word document than Word the application.

The full screen app style makes a lot of sense for sites like ours that use maps as their main navigation, but you can end up with a lot of user interface issues if you don't think the interaction through carefully. Before you make a full screen map UI, realize that your screen real estate is going to be severely limited, especially on laptops. Know that browser resize code can be buggy and difficult, especially if you have to support IE6. Understand that you will have to cut information you think should be in the interface for lack of space. If you have the time, create some prototypes of both app-style maps and web page-style maps and test them with users before going all-in.

#3 Make It Bookmarkable

This tip goes for all AJAX apps, but it is especially important for map-driven sites. Traditionally, AJAX apps have not been truly bookmarkable, and that has hindered both their shareability and utility. You want your users to share links to your site, and you want those links to always represent the same view on the map. If your users twitter or IM a link to your map-based site and it doesn't show their friends the same results that they are seeing, they're going to be confused at best and angry at worst. Furthermore, their friends aren't going to be exposed to your site, and you're going to miss an opportunity to create new users.

I won't lie, bookmarkability does add complexity to your app, but it's worth it. Pick up any of the many bookmarkability or back button JavaScript libraries and integrate it into your app. Your users will reward you for it.

#4 Decide How To Show Large Result Sets

If you're displaying results on a map, at some point you're going to come up against the problem of displaying many, many results on a map, and you're going to have to consider the problem of pagination vs. regionation.

Let's say you've built the ultimate map-based cafe finder, and someone searches the whole of San Francisco. San Francisco's a city that loves its hipster cafes, so you have 1000 results, but you can't possibly show those all on the map because you will confuse your users. Now you're faced with a choice: paginate or regionate?

Pagination would have you break down the results into groups of, say, 50 and show them one set at a time on the map, much the way that Google Search paginates your results. This is usually relatively easy to implement, but in my opinion it often misleads users. The typical response we've seen to paginated results on a map is that users think that they are seeing everything at once, and they get confused when a result that should show up isn't there.

Regionation, on the other hand, is the process of showing all the results on the map, but clustering them into groups so that the user can get a feel for where the results appear and zoom in to see more detail. Regionation usually provides a better user experience for large result sets but can be more work to implement. Search for "google maps clustering" to get some suggestions on how to start.

These are just a few of things we've learned over the years, and we'd love to discuss more of them with you either at the Google I/O Developer Sandbox or at the Performance Tips for Geo API Mashups session, where we'll be giving a short demo.

P.S. We've talked about Google Maps' speed previously on our developer blog, if you're interested in a little more detail.

Guest Post by Sasha Aickin, Redfin2013, By: Seo Master

Seo Master present to you: This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Ken Hoetmer of Lonely Planet.

Lonely Planet has been using Google Geo APIs since 2006 - you can currently find them in use on destination profiles at lonelyplanet.com , in our trip planner application , in our hotel and hostel booking engine , on lonelyplanet.tv , and in our mobile site, m.lonelyplanet.com . I could talk for hours about any of these sites, but in preparation for Google I/O and my talk at the Maps APIs and Mobile session, I'll spend this post discussing our use of the Google Static Maps API and the HTTP geocoding service on m.lonelyplanet.com.

Our mobile site's primary feature is highlighting points of interest (POIs) around you, as selected by Lonely Planet. The site is browser based and targeted at a baseline of devices. This accessibility is great for on the road, but because of this choice, we can't obtain precise user locations via a location API. Instead, we've asked our users to self-select their location by entering it into a free form text field when they first arrive at the site. This location is then posted to our server, geocoded on the back end by forwarding the text to the Google HTTP geocoding API, and then used to either set the user's location or return a list of options for disambiguation.

Knowing the user's position, we then forward the position and a radius in kilometers to our Content API's POI proximity method, returning a list of points within range, in order of proximity. Once we have the POIs, we need to present them on a map, relative to the user's location. This is where the Google Static Maps API comes in. We can't rely on the availability of Flash, JavaScript, and Ajax, but the Static Maps API enables us to serve a JPEG map by simply providing our list of POI geocodes, a few bits about labeling markers, and a height / width (which we calculate per device by querying screen sizes from WURFL) as query parameters to a URL. Below the map we put a few links for switching the map between (road)map, satellite, hybrid, and terrain base maps.

That gives us a basic map, but what if the user wants to look a little farther to the north or east? To enable this, we augmented the map with a lightweight navigation bar (north, south, east, west, zoom in, zoom out), with links to new static maps that represent a pan or zoom action. Here's how we generated the links:

Let's say our page has a static map of width w pixels, height h pixels, centered at (lat,lng) and zoom level z.

$map_link = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$lat},{$lng}&zoom={$z}";

Then, we can generate north, south, east, and west links as follows (this example assumes the existence of a mercator projection class with standard xToLng, yToLat, latToY, lngToX routines):

// a mercator object
$mercator = new mercator();

// we'll pan 1/2 the map height / width in each go
 
// y pixel coordinate of center lat
$y = $mercator->latToY($lat);

// subtract (north) or add (south) half the height, then turn
 back into a latitude
$north = $mercator->yToLat($y - $h/2, $z);
$south = $mercator->yToLat($y + $h/2, $z);


// x pixel coordinate of center lng
$x = $mercator->lngToX($lng);

// subtract (west) or add (east) half the width, then turn back into a longitude
$east = $mercator->xToLng($x + $w/2, $z);
$west = $mercator->xToLng($x - $w/2, $z);

So that our north, south, east, west links are:

$north = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$north},{$lng}&zoom={$z}";
$south = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$south},{$lng}&zoom={$z}";
$east = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$lat},{$east}&zoom={$z}";
$west = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$lat},{$west}&zoom={$z}";

Of course if you're serving a page knowing only a list of points and their geocodes, then you don't have a zoom level value for calculating the map links. Thankfully, mercator projection implementations often offer a 'getBoundsZoomLevel(bounds)' function, which serves this purpose (create your bounds by finding the minimum and maximum latitudes and longitudes of your list of geocodes). If your implementation doesn't provide this function, it's not complicated to write, but I'll leave that to the reader (hint: find difference in x and y values at various zoom levels and compare these to your map width and height).

As mentioned earlier, I'll be joining Susannah Raub and Aaron Jacobs to delve deeper into maps and mobile devices at Google I/O. In addition, Matthew Cashmore (Lonely Planet Ecosystems Manager) and I will be meeting developers and demoing our apps in the Developer Sandbox on Thursday, May 28. We'd love to meet you and we'll be easy to find - simply follow the noise to the jovial Welshman.

Guest Post by Ken Hoetmer, Lonely Planet2013, By: Seo Master

Seo Master present to you: By Mickey Kataria, Google Maps API team

We just released the Google Maps API for Flash, which gives developers access to Google Maps from Flash/Flex apps using ActionScript. For more details, check out the Google Maps API blog, and as always, let us know what you think.2013, By: Seo Master

Seo Master present to you:
By Aurelio Tinio of The Bay Citizen

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.

The Bay Citizen is a nonprofit, nonpartisan news organization dedicated to fact-based, independent reporting of issues in the San Francisco Bay Area. We are interested in visualizing public data that is useful to the local community. One such effort is our Bike Accident Tracker. In this post, I’ll present a simple example of how we used Google Maps and Google Fusion Tables to accomplish this.

This is what our accident map looks like:


Want to add our accident map to your site? Here is the code:

<html style='height: 100%'>
  <head>
    <script type='text/javascript' src='http://maps.google.com/maps/api/js?sensor=false'></script>
    <script type='text/javascript'>
      function initialize() {
        var bc_office = new google.maps.LatLng(37.788901, -122.403806);
        var map = new google.maps.Map(document.getElementById('accident-map'), {
          center: bc_office,
          zoom: 13,
          mapTypeId: google.maps.MapTypeId.ROADMAP
        });
        var accidents_layer = new google.maps.FusionTablesLayer(433634);
        accidents_layer.setMap(map);
      }
    </script>
  </head>
  <body onload='initialize()' style='height: 100%; margin: 0px; padding: 0px'>
    <div id="accident-map" style='height: 100%'></div>
  </body>
</html>

That’s it. To test this yourself, just save the raw file, open the file with a browser and you will have a copy of the accidents map running locally on your computer. The code mainly deals with setting up Google Maps, with one critical line that sets up Fusion Table integration:

var accidents_layer = new google.maps.FusionTablesLayer(433634);

You can expand this integration by filtering the results through the use of Fusion Tables’ sql-like query syntax. As an example, to display accidents from May 2009, change the line above to look like this:

var accidents_layer = new google.maps.FusionTablesLayer(433634, {
  query: 'SELECT FullAddress FROM 433634 WHERE Year=2009 AND Month=5'
});

A quick gotcha to point out here is that Google Maps v3 only supports a SELECT operation on the location value column. So the location query above works just fine, but the COUNT query needed to get the number of accidents does not work:

'SELECT COUNT() FROM 433634 WHERE Year=2009 AND Month=5'

Instead, to get the number of accidents in this case, you can use the Fusion Tables API endpoint directly:

https://www.google.com/fusiontables/api/query?sql=SELECT COUNT() FROM 433634 WHERE Year=2009 AND Month=5

You can see the actual response from the count query here. Because The Bay Citizen is built on the Django framework, we can leverage the Python libraries Google provides for query generation and API calls. Also, since the location query is so similar to the count query, I consolidated the filter logic so it happens on the server side using a jQuery AJAX call. As a result, when users apply a filter, they see an updated map and results bar all thanks to the following few JavaScript lines:

$('#filter-form').ajaxForm({
  success: function(responseText, statusText)  {
    var data = $.parseJSON(responseText);
    accidents_layer.setMap(null);
    accidents_layer = new google.maps.FusionTablesLayer(433634, {
      query: data.map_query});
    accidents_layer.setMap(map);
    $('#filter-results').html(data.results);
  }
});

I was really happy with this approach. The performance hit is negligible, the code is much cleaner, and the filter logic is rewritten in the programming language I currently know best (Python).

I hope this post gives you a taste of what it's like to work with Google Maps and Fusion Tables. Also, please note that our data is public and can be referenced at Table #433634. This means you’re free to use the same data we do to develop and design your own map interface. When we update the data, your project will be updated as well.

From our end, we don't have to worry about our servers being overloaded with data API and map generation calls that come from your project. So by all means, hack away, improve the design, and create a better version. All we ask is that if you do come up with something cool, please link back to us, let us know, and then maybe we can even work together.

For additional details, take a look at the extended post Bike Accident Tracker: A Fusion Powered Map.


Come see The Bay Citizen in the Developer Sandbox at Google I/O on May 10-11.

Aurelio Tinio is a software engineer specifically interested in data journalism and visualization. He enjoys coding, basketball, travelling (not while playing basketball), and meeting new people.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Scott Knaster, Google Developers Blog Editor

You know Street View as the cool Google Maps feature that gives you a peek at your destinations as you map them out. This week, Street View went off-road – way off, all the way to the Amazon Basin. Instead of streets, the Street View team photographed forests, villages, and rivers. The team used more than 50,000 photos to build the Amazon views, and the scenery is much more beautiful than most streets.


Speaking of places where there are no streets, take a look (and a listen) to this video of a day in the life of a Solid Rocket Booster (SRB) during a Space Shuttle launch. The video includes a 720p HD version, and the audio was cleaned up by Skywalker Sound to make it sound its finest.



Finally, check out these photos of the sunken Titanic published by National Geographic. This completes our tour of land, air, and sea. Now you can go and enjoy the outdoors yourself!


Once a week we post a Fridaygram, which has little to do with developer announcements and is just for fun. Each Fridaygram item must pass only one test: it has to be interesting to us nerds. Special congrats to the team at Skywalker Sound for resisting the urge to add anything to the SRB video.

2013, By: Seo Master

Seo Master present to you:
By Carlos Cuesta, Product Marketing Manager, Google Maps API

Cross-posted with the Google Geo Developers Blog

When we first launched the Google Maps API, it was all about a map, a pin, and a dream. Back then our technical documentation was relatively simple, consisting of a couple of developer docs and some code samples. Since then the Google Maps API has expanded far beyond our expectations, due in large part to the diverse and innovative developer ecosystem that has grown with us.

With the continuing evolution of the Google Maps API, it became clear that we needed more than just code documentation to convey what’s possible with the Google Maps API. Thus, developers.google.com/maps was born.

In addition to having all the same developer content that was previously available on code.google.com, the site is designed to highlight and illustrate new features of the Google Maps API through fun and interactive demos. Our goal with developers.google.com/maps is to inspire the next wave of innovation on the Google Maps API, and to connect developers and decision makers with the tools and services that can make their products better.


One of the features of the Google Developers site we’re most excited about is the 3rd party developer showcase, which allows us to celebrate a selection of innovative sites in the Google Maps API ecosystem. Showcase content is carefully curated by the Google Maps API team.

In order to help users discover relevant apps and topics in the showcase, we’ve devised a tagging system that allows you to filter examples both by theme, and by Google Maps API features used.



We hope that the showcase and the interactive examples on the new Google Maps API Developers capture your imagination and inspire you with what’s possible using the platform. The imagination of Google Maps API developers has always been what makes the product great and we’re looking forward to seeing what you come up with next.


Carlos Cuesta is the Product Marketing Manager for Google Maps API. He also enjoys travelling, photography, and collecting vinyl.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you: By Adam Feldman, Google Developer Team

The GoogleBar, a control in the Maps API to allow users to search the map for local businesses, landmarks and points of interest, has just launched a new version. In addition to a greatly improved UI, the new GoogleBar includes advertising targeted to the user's searches. This new feature will improve the user experience by providing targeted and relevant sponsored results, and you can benefit by sharing in the revenue of including these results on your site. You can see the new GoogleBar, together with ads, below:


As shown above, the new version of the GoogleBar contains advertising. Profiting from the advertising personally is as easy as signing up for an AdSense account and including your AdSense publisher ID when you create the GoogleBar. See the recent Maps API Blog post for details. Whether you already have a map on your webpage or not, it only takes a few lines of code to embed a fully searchable map into your site - the GoogleBar documentation will tell you everything you need to know.

The GoogleBar is built upon our low-level Local Search Control. For those interested in peeking under the covers, check out the Local Search Control documentation and Code Playground examples.

Questions or comments? Please visit the AJAX API and Maps API discussion groups.
2013, By: Seo Master

Seo Master present to you: Posted by Dion Almaer, Google Developer Programs



If ever cricket lovers needed an excuse to take a trip to the Caribbean, now they have one. The Cricket World Cup 2007 has started today, and it should be a great party. (I myself am a Brit who will hopefully not be praying for rain.)

Once again, the developer community has outdone itself creating useful mashups. The Radioactive Yak has detailed a few of the resources available which include:

• A Google Gadget module that shows the current games on a map of the area
• A Google Earth tour of the venues via a World Cup 2007 Venues KML file
• An up-to-date game schedule on a Google Calendar.

Google India has also made a site available at http://www.google.co.in/cricket with useful tools of its own:

• World cup news gadget
• World cup scores gadget
• A blogging contest for the event
• And much more. Visit the site to participate

2013, By: Seo Master