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

Seo Master present to you: Google I/O is well underway, and we're excited that we've been able to highlight some Chrome Experiments at the event. During the keynote on Wednesday, we opened with the following video. Matt Waddell from our Developer team composed the music playing in the background. We're posting a subtitled version of the video, so you can enjoy the song in all it's HTML5 glory.



We've loved the experiments we've received so far and encourage you to check out the ones listed below:

• Google Sphere
• Browser Ball
• Twitch
• Wavy Scrollbars
• Bomomo
• Monster
• World of Solitaire
• Canopy
• js touch
• HasCanvas

We're continually updating Chrome Experiments to feature new and crazy JavaScript experiments, so keep submitting!

By Aaron Koblin, Google Chrome Team2013, By: Seo Master

Seo Master present to you: This morning at Google I/O we are unveiling a developer preview of Google Wave, a new collaboration and communication product. Google Wave introduces a new platform built around hosted conversations called waves--this model enables people to communicate and work together in new and more effective ways. On top of that, with the Google Wave APIs, developers can take advantage of this collaborative system by building on the Google Wave platform. We want to expand upon that platform, which is why we've put together the initial draft of the Google Wave Federation Protocol, the underlying network protocol for sharing waves between wave providers.

Yes, that's between wave providers: anyone can build a wave server and interoperate, much like anyone can run their own SMTP server. The wave protocol is open to contributions by the broader community with the goal to continue to improve how we share information, together. If you're interested in getting involved, here are a few things you should check out on www.waveprotocol.org:

• Draft Protocol Specification -- This is an early draft and will definitely change
• Community Principles -- Understand how this open source project works
• Architecture Whitepapers -- Learn more about the components of Google Wave

This is just the beginning. To help potential wave providers get started, our plan is to release an open source, production-quality, reference implementation of the Google Wave client and server, as well as provide an open federation endpoint by the time users start getting access.

We're eager to hear your feedback, so please tell us about your interest, and drop a note on the technical engineering forum with your feedback.

Beyond the federation protocol, you may also be interested in learning more about the Google Wave APIs, as described on the new Google Wave Developers blog.

By Dan Peterson, Google Wave Team2013, By: Seo Master

Seo Master present to you: Day 1 of Google I/O was an action-packed endeavor, shared with an excited community of developers on the ground learning about developing web applications with Google and open technologies, and showcasing some of their best apps.

Here are a few highlights from our keynote speech:

• Google Web Elements is launched: Adding Google products to your website or blog has never been easier.
• App Engine for Java is now out of preview and open for signups
• Google Web Toolkit 2.0 previewed upcoming new features, including in-browser debugging and developer-guided code splitting (also known as runAsync())
• Android Developer Challenge 2 launched: Win awards for building great apps on Android
• Google Latitude on iPhone 3.0 was previewed

Check out a video playlist of this morning's keynote:


Since a picture is worth a thousand words, we thought we'd recap the 1st day of I/O with photos captured throughout the day:


In case attendees had trouble finding Moscone West, they were directed to look for the life-sized Google Maps pin placed right in front of the entrance.


I/O 2009 had higher attendance, but registration went much more smoothly this year.


An attendee checks out the I/O agenda board. Product stickers were distributed to attendees to stick on their conferences badges to identify fellow attendees with similar product interests.


Eric Schmidt greeted developers and kicked off the keynote


Vic Gundotra takes the stage to talk about "a more powerful web, made easier."


Vic welcomes Jay Sullivan, VP of Mozilla, while also thanking Mozilla and the larger developer community for tireless efforts towards new web standards. Jay gave a glimpse of Firefox 3.5 features.


Michael Abbott, SVP of Palm, talks about why the web is the platform and Palm webOS.


A view from the audience.


We gave all Google I/O attendees a limited edition Android-powered device in order to encourage and facilitate further application development on the Android platform, and provided a preview of Donut features.


Office Hours are a new addition to I/O, where attendees can drop in and bring questions for Google engineers. View Office Hours schedule.


Alon Levi speaks on his App Engine session, From Spark Plug to Drive Train: Life of an App Engine Request.


At the Google Web Toolkit Fireside Chat - members of the GWT team listen to audience question.


Anybot struck up conversation and hung out with developers.


View of the Developer Sandbox from the escalator.


Enjoying a complimentary chair massage.


Developers crashed on bean bags, taking a break to check email and get some work done.


The Street View trike roamed the halls.


A developer pondering what to grab from the drink coolers, available throughout Level 2 for attendees to quench their thirst.


Developers enjoyed bins of chocolate covered raisins, M&Ms, pretzels, trail mix, and other goodies throughout the day.

To follow the latest at Google I/O, check out twitter and twazzup. Stay tuned for Day 2!

By Christine Tsai, Min Li Chan & Mike Marchak, Google Developer Team2013, By: Seo Master

Seo Master present to you: At Google, many teams use the Visualization API to create charts and visualizations of their data - both for external and internal products.

The Visualization API wire protocol has been made available publicly so that anyone can connect their data on the web to the list of powerful visualizations available (from Google and third parties) since late last year.

However, internal developers at Google had access to our complete code base for implementing data sources with full query capabilities and more. We felt that the whole web community should also enjoy the same benefit, so yesterday we released a full open source Java library that lets developers expose their data (publicly or to select users) for visualizations, charts and dashboards with a fraction of the effort required previously. This is the first complete free Java package for implementing a Visualization API data source - complete with a full implementation of the API's query language - and it joins our growing list of other tools and data source implementations by third parties and Google.

While we were at it, we also took the opportunity to bring our developer community many more goodies. Most notably:

• We're launching new versions of the wire protocol and query language, including improved security features for sensitive data.
• We're launching a generic image chart that provides access to all our popular Chart API's charts and their options through the simple but robust Visualization API JS interface (without the limitation on data quantity imposed on the Chart API URL length limitation).

Check out the full list of new stuff on our What's New page.

We will be reviewing the Java library and many of the new features in our sessions at Google I/O. If you can't make it be sure to check out our full documentation, where we will also post the videos from the sessions.

By Itai Raz and Yaniv Shuba, Google Visualization API Team2013, 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 Jesse Lorenz from Salesforce.com.

Many companies are storing their data in the cloud, and they are looking for ways to gain insight to this data. The Google Visualization API is a great way to do just that, which is why salesforce.com has built a set of Google Visualization components for Force.com. These components enable Force.com customers and partners to quickly embed sophisticated reporting and analysis functionality in to their Force.com applications. You can even use the Annotated Time Line visualization to visualize your sales progress:


The Google Visualization component project is one of the most popular projects on developer.force.com/codeshare. Force.com partners have already begun to leverage the components to build new business intelligence apps so that Force.com users can quickly generate reports and dashboards that provide them with new insight to their data.

If you’d like to learn more about embedding Google Visualizations into your Force.com applications, this tutorial is the best place to start. It contains a walk-through of how to get started as well as links to sample code for all of the supported components. The project is open source and everyone is encouraged to contribute!

Salesforce.com will be co-presenting a session at Google I/O that will discuss how to embed the power of the Google Visualization API in Force.com business applications, and how to turn a Force.com application in to a Google Visualization data source. We hope to see you there! To learn more about developing applications on Force.com, go to developer.force.com.

Guest By Jesse Lorenz from Salesforce.com.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: 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: Google I/O has sold out and general registration is now closed. If you have received a registration code, you can still register here. If you're unable to join us next week, we will post all of the videos and presentations shortly after I/O -- keep an eye out for updates on that. During the event, you can follow us on the @googleio Twitter account and on the Google Code Blog for the latest in-conference updates and announcements. And if you're coming to Google I/O, we look forward to seeing you there!

By Azhar Hashem, Google Developer Team2013, 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: 2013, By: Seo Master

Seo Master present to you: We hope you enjoyed watching the previous set of previews for Google I/O sessions. These previews are a way for the speakers to present their topics in their own voice and for you to be able to pick and choose which sessions you would like to attend ahead of the conference. Keep an eye out for more previews on the other sessions at I/O in the coming weeks; we look forward to seeing you at Google I/O, on May 27-28.

Brad Chen - Native Client: Using Native Code to Build Compute Intensive Web Applications




Sven Mawson - Evolution of the Google Data Protocol: New Features for Building more Efficient Applications




Ben Lisbakken - Fun Hacks and Cool JavaScript: The Advanced Techniques Behind the Google AJAX API Playground



By Neel Kshetramade, Google Developer Programs2013, By: Seo Master

Seo Master present to you: By Steve Souders, Member of Technical Staff

This post is one in a series that previews Google I/O, our biggest developer event in San Francisco, May 28-29. Over the next month, we'll be highlighting sessions and speakers to give Google Code Blog readers a better sense of what's in store for you at the event. - Ed.

In April I announced that I'm starting another book. The working title is High Performance Web Sites, Part 2. This book contains the next set of web performance best practices that goes beyond my first book and YSlow. Here are the rules I have so far:

1. Split the initial payload
2. Load scripts without blocking
3. Don't scatter scripts
4. Split dominant content domains
5. Make static content cookie-free
6. Reduce cookie weight
7. Minify CSS
8. Optimize images
9. Use iframes sparingly
10. To www or not to www

I'm most excited about the best practices for improving JavaScript performance (rules 1-3). Web sites that are serious about performance are making progress on the first set of rules, but there's still a lot of room for improving JavaScript performance. Across the ten top U.S. sites approximately 40% of the time to load the page is spent downloading and executing JavaScript, and only 26% of the JavaScript functionality downloaded is used before the onload event.

In my session at Google I/O I'll present the research behind rules 1-3, talk about how the ten top U.S. web sites perform, demonstrate Cuzillion, and give several takeaways that you can use to make your web site faster.2013, By: Seo Master

Seo Master present to you: Web developers face many limitations when trying to develop web applications that match the functionality of desktop applications. Many people are working on removing these limitations and helping make the open web an even more powerful platform. Browsers have recently focused on and significantly improved JavaScript performance, and new HTML5 and related APIs are currently being formulated and implemented, giving developers even more capabilities. Through efforts like O3D, Chromium, and Native Client, we want to contribute our technology and web development expertise to developing and promoting open web standards that will ultimately help developers build better apps and make their users happy.

Here are some of the developers who'll be at Google I/O (only 19 days away) and speaking or demoing their products built on open web technologies:

• Browser Perspectives: An Open Discussion
  Web developers are asking more from today's browsers — more speed, more functionality, and a greater ability to build web applications that make users happy. To talk about how browser development happens with respect to new standards, such as what influences decisions around which new APIs to implement first and how to implement new features in the face of still-changing standards proposals, we have a panel with representatives from Google, Microsoft, Mozilla, and Opera. The discussion will be moderated by Mike Schroepfer, VP of Engineering at Facebook.


• Bespin Project (Mozilla Labs)
  Bespin is a Mozilla Labs experiment that proposes an open, extensible web-based framework for code editing that also promotes the use of open standards. The Bespin web code editor is built on HTML5 technology. Dion Almaer and Ben Galbraith will be leading a session, Bespin and the Open Web, where they talk about their experiences.
  


• Opera Software
  Opera is actively involved in contributing and deploying open web technologies. Specifically, they are currently helping specify GeoLocation, HTML 5, CSS 3, cross-device widgets and SVG, amongst others, and dev.opera.comshowcases techniques and technologies to developers. The Opera Dragonfly developer tools are built using the latest Web technologies. Charles McCathieNevile will be one of the speakers on the Browser Perspectives talk.
  


• Yahoo! Pipes
  Pipes lets users remix popular feed types and create data mashups using a visual editor. This visual editor allows you to drag pre-configured modules onto its canvas and wire them together. Pipes use the HTML5 <canvas> tag extensively in the Pipes Editor and Pipe thumbnails.


• Large Animal Games
  Large Animal Games has developed over 75 games for a variety of platforms, many of which are fully integrated with OpenSocial. They've developed a cross-network game platform called Toga which enables the simultaneous deployment of games across multiple social networks, including those that support OpenSocial. They're also in the process of developing a game using O3D that will ultimately be integrated with social networks via Toga.


• Crazy Pixel Productions
  Crazy Pixel Productions is a full service 3D animation and game development studio that specializes in top notch art and incredibly immersive worlds. Crazy Pixel has worked on producing art for the O3D Beach demo and is now developing a new game based on O3D.

You can also take a look at our sessions page for a full list of sessions. In particular, sessions under the "Client" track focus on making changes in client products such as browsers to empower the open web platform, implementing HTML5 and related APIs, discussions around 3D and native code, and more. The Sandbox will include engineers of Google product teams that are deploying open web technologies, like the Gmail for mobile HTML5 app, Native Client, Chrome extensions, and O3D.

Google I/O is only 19 days from now - to sign up, go to code.google.com/io!

*Keep up with the latest I/O updates: @googleio.

By Christine Tsai, Google Developer Team2013, 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 Adrian Graham, co-founder of nextstop.com who will give us a demo inside the Developer Sandbox.

When building nextstop's HTML5 mobile app, we were able to leverage a powerful combination of HTML5 and Google API's to build a mobile web experience that we believe rivals what we could have built natively. For more on our mobile app, check out this post -- here we will just focus on the technologies that made this experience possible.

Lately HTML5's video features have gotten a lot of attention, but it's three other HTML5 features that we've found most useful for mobile web development.

1. Prefetching using LocalStorage: It's no secret that mobile data networks are slow but by putting a bit of thought into what users will tap on next, and prefetching that data in the background you can build a dramatically faster user experience. It's possible to do limited forms of prefetching using plain old JavaScript, but using the localStorage key/value storage built into HTML5, we're able to store much more data and therefore prefetch more aggressively.

If you're using a recent version of Chrome or Safari or on an iPhone 3 or Android 2 phone and want a sense of what prefetching feels like, try clicking the left and right arrows here (you can ignore the warning you will see in Chrome and Safari).

2. Geolocation: Using the geolocation features built into HTML5 (and available on iPhone 3 and Android 2), we're able to connect you with local information based on the GPS in your phone, so all you have to do is launch the app to see nearby recommendations. I wish it were a bit faster, but it sure beats entering an address or zip code -- and it's super easy to hook into as a developer.

3. App Caching: The last HTML5 feature that we heavily rely on is the application cache. If a cache manifest file is specified, the browser won't re-download files unless the content of the manifest file has been updated. This may not sound like a big deal, but the latency of cellular networks can be long enough that requesting multiple files at startup can slow down your app by 10 or 20 seconds. Ideally, you'd put all your static JavaScript, CSS, and image files in the manifest file, so users never have to wait for them to be downloaded more than once.

As excited as we are about HTML5, things get even more interesting when you combine these technologies with Google APIs.

1. Google Maps API V3: Google Maps V3 has been rewritten from the ground up to better support modern mobile web browsers, and it shows. We were able to build a map interface into our mobile app that is nearly as full featured as our main site, including support for dynamic updates when the user pans and gestures like pinch to zoom on the iPhone. Coupled with the Geolocation support in HTML5, we can easily show users where they are in relation to the recommendations on the map. A year ago, this would have required writing a fair amount of native code. Today it can be done in the browser and works on both Android 2 and iPhone 3 devices.

2. Google Analytics: Since we prefetch most of our content, we end up rendering mobile pages using JavaScript. This makes tracking things like page views a little more tricky than a typical website, since we're not requesting an HTML file for each page view (and the App Cache can further complicate matters). We planned on building a custom mobile analytics system, but we decided to try running Google Analytics in the mobile web browser instead. Using the _trackPageview method (with a URL corresponding to each mobile "page" generated by Javascript) has worked surprisingly well and has had minimal performance impact. Best of all, if you're already using Google Analytics on your main site, you see all your mobile analytics in the same place. This lets you do things like easily compare the time on site for a mobile visitor and a desktop visitor. (Here's one data point if you're wondering whether or not to build a mobile web version of your site: visitors spend over twice as long using our mobile HTML5 app as they do on our website.)

3. Google Local Search API: Coupled with HTML5 geolocation, the Google Local Search API becomes even easier to use. For instance, the nextstop app lets users add places that they like to nextstop's database. In a desktop browser, we have no choice but to ask the user to type in some words and do a local search. However, on the phone, we can show users a list of nearby places by passing the local search api the user's current position. More often than not, no typing is required to locate the place you'd like to add.

If you can't already tell, we're pretty excited about the future mobile apps running inside a browser. As mobile web browsers and web APIs continue to evolve, we expect more and more people to hop on the HTML5 bandwagon as a cross-platform way to build powerful mobile apps.

We'll be at Google I/O in May and would love for you to stop by our demo station in the Developer Sandbox and share any questions, tips, or tricks you have related to HTML5 mobile development. And in the meantime, if you have a great idea for an HTML5 app based on nextstop's data, we encourage you to check out our API.

By Adrian Graham, co-founder of nextstop.com2013, By: Seo Master

Seo Master present to you:

If you’re attending Google I/O next month, you’ve likely taken a gander at this year’s sessions and made a mental note of ones you’d like to attend. (Or if you’re like Julio Menendez, you’ve already made a list)

We’ve just posted our session schedule so you can now start planning out your two days at I/O. We’ve also got a few more things in the works to help you plan your agenda, including:

• Session agenda builder to create a customized agenda you can port to your personal calendar. (Google Calendar, iCal, Outlook)

• Google I/O Android app you can download to your Android device so you can easily reference the I/O schedule, star sessions, look at a map of the venue, and find other event info while you’re walking around Moscone West.

• Google Wave will be in full force at I/O as a channel for discussion and live notes during I/O. Stay tuned for more information on how to use Wave at the event.

We’ll let you know as these agenda planning features go live. Be sure to check @googleio for the latest updates.

In addition, we’ve also posted our Office Hours schedule. Google engineers will be on hand to answer any questions you may have about the products and technologies featured at I/O. We’ll be holding office hours for Android, App Engine, Chrome, Closure Compiler / Closure Library, Enterprise, Developer Docs, Geo, Go, Google APIs, Google Project Hosting, GWT, Social Web, and Wave.

24 days left until I/O - let the countdown begin!

Posted by Christine Tsai, Google Developer Team

2013, By: Seo Master

Seo Master present to you: We launched Chrome Experiments last month to feature some of the crazy things that are now possible with JavaScript. Since then, a number of developers have submitted additional experiments, many of which have made us smile -- take a look at a few of them.

In May, we're going to feature Chrome Experiments during Google I/O, our largest developer event (May 27 - 28), as well as on the Google Code blog.

So if you haven't already started experimenting, here's your chance to create something cool, fun, or quirky with JavaScript. Please submit it by May 26th. We'll reveal the top ten experiments here on the Google Code Blog during Google I/O.

Happy experimenting!

By Aaron Koblin, Google Creative Lab2013, By: Seo Master

Seo Master present to you: Google I/O is now just a month away, and we're incredibly excited by the breadth of companies and developers that will be showcasing their applications in this year's Developer Sandbox. As of today, over 100 companies are listed on the I/O website, and we anticipate over 180 companies to be confirmed by the time of I/O.2013, By: Seo Master

Seo Master present to you:

Ignite will be at this year’s Google I/O! Last year, we had talks on big data, cartography and DIY devices -- a "typical" Ignite line-up. This year, our line-up includes folks like Cheezburger CEO, Ben Huh, and digital artist, Aaron Koblin. However, we also want you! We want to hear your cool ideas, hacks, how-to's, and war stories.

Each Ignite talk is 5 minutes long -- with 20 slides and only 15 seconds a slide (they auto-advance) -- and I'll be hosting the talk at I/O. If you’re not sure what to talk about, watch Scott Berkun's excellent How and Why to Give an Ignite Talk.

Submit your talk by March 31st, and we’ll announce the selected speakers on April 3rd. Those who are chosen to give an Ignite talk will receive a free ticket to Google I/O.

If you need further inspiration, you can watch any of the hundreds of Ignite videos at Ignite Show.

By Brady Forrest, O'Reilly/Ignite

@brady

2013, By: Seo Master

Seo Master present to you:

• Fireside chat with the Android team
  Speakers: The Android team with Chris DiBona moderating
  Pull up a chair and join the Android team at Google for a fireside chat. It's your opportunity to ask us about the platform and to tell us where you'd like to see it go in the future.
  
  
• Fireside chat with Android handset manufacturers
  Come join us for a fireside chat with the top Android handset manufacturers. Hear about the types of devices being planned for 2010 and get your device-specific questions answered.
  
  
• Fireside chat with the App Engine team
  Speakers: Brett Slatkin, Guido van Rossum, Matt Blain, Max Ross, Don Schwarz, Alfred Fuller, Kevin Gibbs, Sean Lynch
  It's been an busy year for the App Engine team with lots of new features and lots of new developers. Come tell us about what you've loved and what still bugs you. With several members of the App Engine team on deck, you'll get the answers to your questions straight from the source.
  
  
• Fireside chat with the Google Chrome and Chrome OS teams
  Speakers: Ian Fette, Brian Rakowski, Linus Upson, Caesar Sengupta, Matt Papakipos
  Curious about what's new in Google Chrome, or what makes Google Chrome OS so exciting? We'll talk briefly about the major developments over the past year, and then field questions from the audience. If you're dying to know something, this is the place to find an answer.
  
  
• Fireside chat with the Enterprise team
  Speakers: Chris Vander Mey, Scott McMullan, Ryan Boyd, David Glazer, Ken Lin
  With the launch of the Google Apps Marketplace, we've introduced a new way to expose your software to businesses - and a new way to extend Google Apps. If you're interested in building apps, what we're thinking about, or if you have other questions about the Marketplace, pull up a chair.
  
  
• Fireside chat with the Geo team
  Speakers: Thor Mitchell, Peter Birch, Matt Holden, Ben Appleton, Bart Locanthi, Thatcher Ulrich
  Here's your opportunity to pick the brains of the people behind the Maps, Earth, and Maps Data APIs! We'll take a quick walk through the milestones of the last year, and then open it up to your questions. Don't miss your opportunity to get the straight scoop on all that's new in the world of Google Geo APIs.
  
  
• Fireside chat with the GWT team
  Speakers: Bruce Johnson, Joel Webber, Ray Ryan, Amit Manjhi, Jaime Yap, Kathrin Probst, Eric Ayers
  If you're interested in what the GWT team has been up to since 2.0, here's your chance. We'll have several of the core engineers available to discuss the new features and frameworks in GWT, as well as to answer any questions that you might have.
  
  
• Fireside chat with the Social Web team
  Speakers: David Glazer, DeWitt Clinton, John Panzer, Joseph Smarr, Sami Shalabi, Todd Jackson
  Social is quickly becoming an integral part of how we experience the web, and this is your chance to pick the brains of the people who are working on Buzz, the Buzz API and the underlying open protocols such as Activity Streams and OAuth which are an essential component of a truly open & social web.

You can check out the fireside chats and other sessions on code.google.com/io. The teams are looking forward to your questions!


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