Posted:
Last week I was privileged to host PPK (Peter-Paul Koch) for a Google tech talk entitled "The Open Web Goes Mobile". Most developers building web apps have benefited from PPK's browser compatibility research hosted on his well known site quirksmode.org. Now, fortunately, PPK is turning his attention to the world of mobile web devices. To no one's surprise, browser compatibility on mobile devices is even worse than it is on the desktop. Or as PPK puts it on his opening slide "Hell is other browsers". Check out his slides or watch the video here.



PPK starts by identifying the four main problems with getting web sites to work well on mobile clients: small memory, small display, flaky browsers, and flaky connections. Memory is an area for more research, especially benchmarking. PPK offers some suggestions for dealing with a small display, including using media queries in CSS (@media all and (max-width: 300px) {}) and offsetWidth in JavaScript.

Mobile browsers themselves are flaky when it comes to advanced CSS and JavaScript. But PPK finds that even basic stuff, such as font-style: italic, has to be verified. As a result of his testing, PPK categorizes mobile browsers into three levels of compatibility:
  • top level: Android WebKit, Safari, Opera Mobile
  • mid level: S60 WebKit, Blackberry, Opera Mini
  • bottom level: NetFront, IE Mobile
Obviously, this is not an exhaustive list of mobile clients. PPK also mentions OpenWeb, Nokia S40, Palm Blazer, Iris, Bolt, Skyfire, Obigo, Fennec, and Teashark. This is the challenge in developing for the mobile web - there are a large number of clients and they exhibit diverse compatibility behavior.

When it comes to flaky connections, PPK points out that your connection speed is affected by the activity of the people around you. It's unlikely that this is going to change any time soon, so it's important to reduce the size of your downloads as much as possible. The problem is that caching on mobile devices isn't always reliable.

The impact of flaky connections can be mitigated by saving your core files on the mobile device. W3C Widgets offers a solution for achieving this. They're local applications written in HTML, CSS, and JavaScript that run inside the mobile browser. Ajax is used to download what's required: data. An advantage of using W3C Widgets is that, if the specification gets wide adoption, widgets will run across multiple mobile devices, and companies won't have to build a custom application for each target device. Right now, W3C Widgets work in Vodafone and Nokia S60 phones and Opera/T-Mobile phones for Windows Mobile, so evangelism to other mobile devices is needed. But the possibility of sharing applications across phones is compelling, for both the user experience as well as reduced development costs for mobile app developers.

Posted:
There are over 60 Google APIs across a wide range of products and technologies. The AJAX APIs include Google Search, Language, Maps, FriendConnect, and Visualization APIs. The team recently launched v2 of the AJAX APIs Playground, an app designed to show interactive code samples for some of our coolest Javascript APIs. The Google Data APIs provide a simple standard protocol for reading and writing data on the web and are used by many products including YouTube, Calendar, Picasa Web Albums, and as of last week, Analytics.

Google I/O will feature many sessions covering the AJAX and Google Data APIs. Here are a few of the developers who'll be leading sessions and/or demoing at the Developer Sandbox:
  • Redfin
    Redfin is an online brokerage site for buying and selling homes. Redfin uses the Google Maps, Charts, and Feeds APIs. Redfin actively talks about the behind-the-scenes development decisions, which can be found at the Redfin Developer Blog. (For example, they blogged about why they switched to the Google Maps API) Sasha Aickin, Engineering Manager, will be speaking on a session called Performance Tips for Geo API Mashups.

  • Lonely Planet
    Lonely Planet is known by travelers for producing informed and honest travel advice. Lonely Planet uses the Google Maps Javascript API to power interactive maps on lonelyplanet.com, the Google Static Maps API on its cross-device mobile site, m.lonelyplanet.com, and OpenSocial, App Engine, and Android in products soon to be launched. Ken Hoetmer, Lonely Planet's neogeographer in residence, will be speaking on a session called Maps APIs & Mobile.

  • Adobe
    Introduced with Adobe Creative Suite 4, Adobe Community Help utilizes Google Custom Search (a product which also supports the AJAX APIs) to aggregate the most relevant help content from the broader community. By integrating search directly within the application workflow, users can find answers to their software questions no matter where those answers may be found. Currently, Adobe is exploring ways of expanding Custom Search to include code samples directly within Adobe development environments for products like Flash and Flex. (Read Adobe's blog post about Adobe Community Help)

  • LuckyCal
    LuckyCal is a calendaring application which utilizes several of the Google Data APIs to create a dynamic calendar experience. They authenticate using OAuth to retrieve data from the Calendar and Contacts Data APIs. Based on where you'll be, who you know and what you like, LuckyCal finds events that are relevant to you. LuckyCal has also created a Google Gadget and uses the Maps API (both for UI and for Geocoding) extensively.

  • Eye.fi
    The Eye-Fi Card stores photos & videos like a traditional memory card, and fits in most cameras. When you turn your camera on within range of a configured Wi-Fi network, it wirelessly transfers your photos & videos to either your computer or services like YouTube, Picasa Web Albums, etc via the YouTube and Picasa Web Albums Data APIs.

  • Vast Rank
    Vast Rank is a college ranking website that utilizes the Google Maps API in their interactive ranking map (where visitors see rankings based on what is in view on the map). With the Client Location API, Vast Rank’s personalization engine can weigh the visitor’s location into the criteria used to suggest interesting colleges to the visitor. Vast Rank creator Jon Kragh will be leading a session, Using AJAX APIs to Navigate User-Generated Content.

  • 280 North
    280 North's application, 280 Slides, enables users to easily create web-based presentations. With the AJAX Search API and Google Data APIs, 280 Slides builds in the ability to search Google for images and YouTube for videos and drag media directly into a presentation. 280 North is also the creator of Cappuccino, an open source JavaScript-based web development framework. Check out co-founder Ross Boucher's videos where he talks about 280 Slides' implementation.
Finally, a friendly reminder that early (discounted) registration for Google I/O ends this Friday, May 1. Visit code.google.com/io to sign up and learn more about sessions and demos that'll be in store this year.

*Follow us for the latest I/O updates: @googleio.

Posted:
With recent launches like Google Latitude and Google Toolbar with My Location, it's clear we think location-based services are useful and fun! We also want developers everywhere to be able to use location to build cool new features and applications.

I'm pleased to announce that Google's Location Service (the same service which powers the My Location feature in many Google products), is now the default location provider in Mozilla Firefox 3.5 beta 4. This means that developers can, with users' permission, gain access to their approximate location without requiring any additional plug-ins or setting configurations. It just works!

Mozilla Firefox 3.5 beta 4 uses the W3C geolocation API, a standard being adopted by many major browsers, so you won't have to branch code in the future.

For web developers, using geolocation services in Firefox is easy! Here's a simple example to get you started:
<html>
<head>
<script type="text/javascript">

function displayLocation(loc) {
var locDiv = document.getElementById("locationDiv");
locDiv.innerHTML = "lat: " + loc.coords.latitude + ", lon:" + loc.coords.longitude;
}

function getLocation() {
navigator.geolocation.getCurrentPosition(displayLocation);
}

</script>
</head>

<body>
<a href="#" onClick="getLocation()">Click here to display location</a><br>
<div id="locationDiv"></div>
</body>
</html>
When your site calls getCurrentPosition, a drop down will ask the user permission to get his or her location. Upon acceptance of the request, the callback function you specify will run with the machine's approximate location contained in the loc parameter. Here's a screenshot of the permission dropdown:


We hope you find the new and useful ways to use the new geolocation capabilities of Firefox!

Posted:
As a developer, one of the coolest things about working on the Google Chrome web browser is that there's very little difference between being a Googler working on it and being an external contributor. Most development happens via public wikis, mailing lists, bugs, and code under the Chromium project. Chomium's openness is something we take a lot of pride in.

Last Wednesday 5 of Chromium's top contributors gave tech talks on a wide range of very technical topics. Given our commitment to openness, it shouldn't surprise you that we went to great lengths to film them. None of us had filmed a tech talk before, but through a great team effort we were able to capture some really great presentations. If you're interested in the guts of Chromium's code base, I encourage you to check them out:

Posted:
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 Alex Moffat, Chief Engineer - Blueprint, Lombardi Software

Lombardi has been using Google Web Toolkit (GWT for short) since January 2007 to build Lombardi Blueprint, an online, collaborative business process modeling and documentation tool. The client part of Blueprint is completely written using GWT and runs in any modern browser, that is IE6 and anything later, such as IE7, IE8 or Firefox. One of the biggest advantages of Blueprint is that it's easier to learn and quicker to use than a pure diagramming tool like Visio and it's more effective because it's focused on process mapping.

One of the things we do to make Blueprint more effective is automatic diagram layout. This allows the user to focus on describing their process instead of worrying about object positioning and line routing. You can see this in action in the video below as objects are added to the diagram.



Remember, this is JavaScript compiled by GWT from Java code, but it's as fast as, or faster than, anything you could write by hand, compact, and much, much, easier to maintain. The ability to use the excellent tooling available for Java is one of the great advantages of GWT.

One of the goals for our automated layout routines is to generate a flow diagram that looks like it was produced by a human. When the algorithms don't get it quite right, Blueprint also supports hinted layouts so that the user can drag and drop hints about where one object should be positioned in relation to another. Working out what the final layout should be and where the lines should go for large diagrams can be computationally expensive.

Modern browsers have very fast JavaScript engines. For these systems, there are no problems. However, we still need to support the browsers our customers use, which may not necessarily be the fastest or most up-to-date.

This is where GWT gives us a unique benefit. We can implement our algorithms in Java and compile this implementation twice, once with GWT to produce JavaScript to run on the client and once with javac to produce JVM bytecode to run on the server. This lets us use the much faster JVM if we need to without having to create, and maintain, separate client and server layout implementations. There's no other toolkit that makes this possible, never mind easy.

Blueprint client code continuously measures how long it takes to perform the layout and routing operation in the browser. If this exceeds our threshold value, then the code dynamically switches to trying a server side layout. We call the server code with GWT and the data structures returned, via the GWT serialization mechanism, are of course the same ones produced by the layout when executed on the client. The time required for a server layout is also measured, which includes both the execution time and any network delays so we account for the different connection experiences people have. After the first server layout, Blueprint chooses whichever method, client or server, has the lowest average elapsed time. I'm still amazed by how easy this was to implement.

Damon Lundin and I will be talking at Google I/O this year about how we built Blueprint, both what we do technically with GWT to get high performance and how we organize development so that we can make the most effective use of GWT. We look forward to meeting fellow GWT developers in person!

Posted:
On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices built on HTML5. We shared the behind-the-scenes story through this blog and would like to share more of our learnings in a brief series of follow up blog posts.

The HTML5 draft adds a lot of exciting functionality to browsers. Perhaps the most exciting is adding a way for websites to be launched offline. For devices that have a high bandwidth and highly available connection, offline functionality might not be so important. For web applications running on mobile devices however, being able to launch offline can dramatically improve the web application experience.
AppCache support on the iPhone is still under development, but as of firmware 2.2.1, it is usable.

To make use of AppCache, a webpage must provide a "manifest" to the browser that lists all of the URLs that it intends to use. Creating an HTML5 manifest file is extremely simple, as shown by the following example.
CACHE MANIFEST
jsfile1.js
jsfile2.js
styles.css
/images/image1.png
/images/image2.png
It is important to note that it is not necessary to list the URL of the main webpage in the manifest because it is treated as an implicit entry. However, if you have more than one top level URL that you want to be available offline, they must all be listed in the manifest. In addition, they must all set a manifest attribute on the HTML tag that points to the manifest. For example, if the manifest URL was "/sitemanifest", then each page in the site would have an HTML tag that looked like this:
<html manifest="/sitemanifest">
Finally, the manifest must be served using the content type "text/cache-manifest". And that's it!

So now that you know how to create a manifest for your site, it's a good idea to know what's going on during page load. When the page is loaded for the first time, it will load as if there is no application cache associated with it. Once it has finished loading, the browser will fetch the manifest and all resources listed in it that have not already been fetched during page load. From this point on, any GET request that your page makes that is not listed in the manifest will fail, and any GET request that is listed in it will not hit the network, but will be satisfied by the cache. Once your page is loaded into AppCache, the next time the user loads the site, all of the resources will be served out of the cache. The only GET request done on page load will be for the manifest file, in order to see if it has changed. If it has changed, then all of the resources in it are fetched in the background and will be used the next time the user refreshes the page.

Stay tuned for the next post where we will share more about what we know about AppCache and how we use it on the Gmail team. Also, we'll be at Google I/O, May 27-28 in San Francisco presenting a session on how we use HTML5. We'll also be available at the Developer Sandbox, and we look forward to meeting you in person.

References

The HTML5 working draft:
http://dev.w3.org/html5/spec/Overview.html

Apple's MobileSafari documentation: http://developer.apple.com/webapps/docs/documentation/AppleApplications/Reference/SafariJSRef/DOMApplicationCache/DOMApplicationCache.html

Webkit Source Code:
http://trac.webkit.org/browser/trunk/WebCore/loader/appcache

Posted:
The Visualization API is about charts and visualizations, so we try to push out new features and options to our growing list of charts every several weeks or so.

Here are a few examples of recently launched charting options and additions:
  • Lots of customization options for the Table visualization, so you can customize it any way you want. You can even make it look as ugly as this:


  • The popular Motion Chart has become even more interactive and appealing, now with zoom option, bars, and an option to save and restore the chart state.

    This way you can track your data over time with the default bubble view:



    Or dynamically switch to a bar view when it makes sense:


  • Plus, we've made all of our charts and visualizations easier to share with others through the toolbar helper element that enables you to export your data in a variety of formats, or embed the visualization in another page through a simple user oriented UI:


Check out our What's New page from time to time to see other new features we've added to the API.

At the upcoming Google I/O developer conference, we'll give in-depth sessions on creating Visualization API data sources, using the Visualization API with GWT, and more. We look forwarding to seeing you there!


Posted:
Heads up, early registration for Google I/O ends May 1. After this Friday, the rates increase $100 and even worse, you'll lose out on your Google Chrome Comic book.

Google I/O will feature 80+ sessions that cover Android, HTML5, App Engine, Chrome, AJAX APIs as well as special sessions for Enterprise and Social app developers. These technical sessions will be led by engineers from Google and a wide range of developers from the community. We'll also have Fireside Chats and Office Hours, giving attendees a chance to meet with Google engineers and get answers to all those pressing questions.

This year's newest addition to Google I/O is the Developer Sandbox. Over 100 developers representing a wide range of companies and apps will be on hand to demo their products, which they built using Google technologies. We've announced a few thus far and will continue to announce more over the coming weeks here on the Code Blog.

We've also worked really hard to make your visit to the San Francisco Bay Area as affordable as possible, including lower-than-usual hotel rates. Those rates expire on May 4 so register and make your hotel reservations today to secure them. For more information visit the Google I/O website.

If you plan to attend, register before the fee increases. We look forward to seeing you at I/O!

Posted:
We are happy to announce that Project Hosting on Google Code now supports the Mercurial version control system in addition to Subversion. This is being initially rolled out as a preview release to a few invited users on a per-project basis, so that we can iron out the kinks before making this available to the general public.


Mercurial, like Git and Bazaar, is a distributed version control system (DVCS) that enables developers to work offline and define more complex workflows such as peer-to-peer pushing/pulling of code. It also makes it easier for outside contributors to contribute to projects, as cloning and merging of remote repositories is really easy.

While there were several DVCSs that we could support, our decision to support Mercurial was based on two key reasons. The primary reason was to support our large base of existing Subversion users that want to use a distributed version control system. For these users we felt that Mercurial had the lowest barrier to adoption because of its similar command set, great documentation (including a great online book), and excellent tools such as Tortoise Hg. Second, given that Google Code's infrastructure is built for HTTP-based services, we found that Mercurial had the best protocol and performance characteristics for HTTP support. For more information, see our analysis.

If you would like to help us launch Mercurial and to try out the features as an invited user, please fill out the following form. We are currently looking for active projects with more than two users that are willing to try out Mercurial and work with us to identify issues and resolve them. For projects that plan on migrating from Subversion, see our conversion docs for the steps required for this process.

Our implementation of Mercurial is built on top of Bigtable, making it extremely scalable and reliable just like our Subversion on Bigtable implementation. For more information on our Mercurial implementation, we will have a TechTalk at Google IO that will be led by Jacob Lee, one of the core engineers working on Mercurial support. Let us know if you plan on attending and we'll give you access to Mercurial ahead of the talk.

Posted:
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!

Posted:
Google Web Toolkit, or GWT for short, recently went live with their 1.6 release, which also included a Google plugin for Eclipse and integration with App Engine's Java language support. Google I/O will be rich with GWT content, including a number of sessions on improving productivity and app performance with GWT. In addition, there will be a number of external GWT developers leading some of these sessions and/or part of the Developer Sandbox.

As mentioned last week, we're giving you a closer look at developers who'll be presenting or demoing at I/O. Here is a taste of these GWT developers below. (New to GWT? Check out this overview)
  • JBoss, a Division of Red Hat
    JBoss is well-known by developers for their enterprise open source middleware. Red Hat developer communities such as the Fedora Project and jboss.org have collaborated with Google on a number of developer initiatives over the years including Google Summer of Code, Hibernate Shards, integration with Drools and the Seam Framework and Google Gadgets integration with JBoss Portal. JBoss will be present at the Developer Sandbox.

  • Timefire
    Timefire produces highly scalable, interactive visualizations of up to millions of data points for business intelligence, analytics, finance, sensor networks, and other industries in what they like to call "Google Maps, but for the time dimension." Their platform's built on Google Web Toolkit from the ground up, but also runs natively on Android. Timefire also uses App Engine's new Java language support for their social charting tool, Gadgets, OpenSocial, GData, Google Maps, GViz, YouTube Player API, and Protocol Buffers. Ray Cromwell will be at the Developer Sandbox as well as speaking on 2 sessions - Building Applications on the Google OpenStack and Progressively Enhance AJAX Applications with Google Web Toolkit and GQuery

  • StudyBlue
    StudyBlue is an academic network which enables students to connect with each other and offers study tools. StudyBlue's website is built entirely with GWT. According to StudyBlue, GWT allows for complete AJAX integration without sacrificing usability or integration capabilities. StudyBlue will be at the Sandbox.

  • Lombardi Blueprint
    Lombardi Blueprint is a cloud-based process discovery and documentation platform accessible from any browser. They've used GWT since early 2007 to write the client side of Lombardi Blueprint. GWT has enabled Lombardi to focus on writing and maintaining their Java code, while taking care of creating the browser-specific optimized AJAX for them. Alex Moffat and Damon Lundin will be at the Developer Sandbox as well as leading a session, Effective GWT: Developing a complex, high-performance app with Google Web Toolkit. (Check out Alex Moffat's video about Lombardi's use of GWT)
Finally, one little known fact - a number of Google products were developed with the help of GWT. This includes Google Moderator, Health, Checkout, Image Labeler, and Base.

Don't forget - early registration for Google I/O ends May 1. This means $100 off the standard list price (and a copy of the Chrome comic book). To register, check out the latest sessions, or see more developers who'll be presenting at I/O, visit code.google.com/io.

*Follow us for the latest I/O updates: @googleio.

Posted:
Today we are pleased to announce the launch the Google Analytics Data Export API. This new API is being launched in Labs and is available to all Analytics users. If you haven't already heard, Google Analytics, is a free, powerful web analytics tool that provides a wealth of data about how visitors find your website, where they go and if they turn into customers.

So what's so exciting about this API?

The Analytics API will allow developers to extend Google Analytics in new and creative ways that benefit developers, organizations and end users. Large organizations and agencies now have a standardized platform for integrating Analytics data with other business data. Developers can integrate Google Analytics into their existing products and create standalone Google Analytics applications. Users could see snapshots of their Analytics data in developer created dashboards and gadgets. For example, how would you like to access Google Analytics from your phone? Now you can, with this Android application from Actual Metrics. How about accessing Analytics from your desktop? It's here from Desktop-Reporting.

So how does it work?

We made the API very easy to use. First, there are no complicated developer tokens, you only need to request an authentication token. Second the Analytics Export API is free and available for all Google Analytics users. The Analytics API is a GData API which is based on the Atom 1.0 and RSS 2.0 syndication formats. This is the same API protocol for Google Calendar, Finance and Webmaster Tools. If you've used any of these APIs in the past, the Analytics Export API will look very familiar to you.

Accessing your Google Analytics data generally follows these three steps:
  • Request an authentication token from your Google Account
  • Create a URL with the data you'd like to get back from the API
  • Make an HTTP request to the Export API using the authentication token and the URL you created
Currently the Google Analytics API supports two GData feeds: an Account Feed (which lists all the Google Analytics accounts and profiles you have access to) and a Data Feed (which allows access to all the data available through the GA interface). The Analytics data feed is very powerful and allows you to query which GA dimensions and metrics you want to access, for a specified date range and even across a subset of data.

So it's now simple to access data GA data to answer questions like:
  • What are the top referral sources by conversions to my site?
  • What are the top browser language settings in the United States vs. the United Kingdom?
  • What are the top keyword refinements and destination pages being used on my internal site search?
How do I get started?

There are three key resources you'll want to use when you start developing on top of the Google Analytics API. First we've provided two client libraries to abstract and simplify the process. The Java client library is available in the GData client library. And a JavaScript client library is now available through the Google AJAX APIs GData loader. We're also working on supporting more programming languages. In the meantime, for any programming language you want to use, you can make requests directly to the API over HTTP and access the data in XML. You can find example code, a developer guide, FAQ, and the complete API reference at Google Code.

Second, be sure to sign up for the Google Analytics API Notify email group so you get the key announcements on feature updates, code changes and other service related news that relate to the API. (Don't worry, this will be a low-traffic email list and we promise to only send emails when there is something important that affects developers.)

Finally, you'll want to become a part of the Google Analytics Developer community by joining the Google Analytics APIs Group for developers. This user forum is a great way to share ideas and get feedback from other developers. We also check in on these forums so let us know what you think about the API there, and share your ideas and your applications with us. We look forward to seeing your creativity!

Posted:
Most content on the web today is in 2D, but a lot of information is more fun and useful in 3D. Projects like Google Earth and SketchUp demonstrate our passion and commitment to enabling users to create and interact with 3D content. We'd like to see the web offering the same type of 3D experiences that can be found on the desktop. That's why, a few weeks ago, we announced our plans to contribute our technology and web development expertise to the discussions about 3D for the web within Khronos and the broader developer community.

Today, we're making our first contribution to this effort by sharing the plugin implementation of O3D: a new, shader-based, low-level graphics API for creating interactive 3D applications in a web browser. When we started working on O3D, we focused on creating a modern 3D API that's optimized for the web. We wanted to build an API that runs on multiple operating systems and browsers, performs well in JavaScript, and offers the capabilities developers need to create a diverse set of rich applications. O3D is still in an early stage, but we're making it available now to help inform the public discussion about 3D graphics in the browser. We've also created a forum to enable developers to submit suggestions on features and functionality they desire from a 3D API for the web.

If you are interested in learning more about O3D, you can visit our site, subscribe to our blog and join our discussion groups. We also invite you to join us at Google I/O (May 27th -28th), where you can see presentations about O3D and meet with the team.

A video of the O3D Beach Demo:



Posted:
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 Steven Willmott of 3scale.

Public APIs are a great way to share data and functionality, both for existing applications and as useful resources in their own right. Google Maps, Calendar and many other APIs lead the way in this and are now powering tens of thousands of sites and applications. Flickr, Twitter and others also provide great data and functionality which can be used to enhance and build new applications.

While APIs can provide great value add, it's not always obvious how to make one available if you're not Google or Yahoo. Although serving content via an API is effectively no different than via a user-facing web app - just serving HTTP traffic with XML, JSON or arbitrary data rather than HTML, CSS and Javascript normally destined for a browser - it does come with some unique challenges: authentication works differently, inbound traffic is often automated and response times need to be rapid for the API to be usable within another site - all a bit different from a standard web app.

Since we're in the API business we often get asked about how to quickly get a new API up and running, and one neat new way to do this is using Google App Engine, which provides a lot of the core ingredients needed to launch a new API and help it scale. To see how this works we put together a quick and dirty trial service which exposes App Engine's Image manipulation functions as a new Web API:
  1. First we set up a standard App Engine account giving us the standard dashboard and deployment environment. This provides the runtime environment plus a range of tools to monitor the application - all useful to track resource usage which we'll need to worry about later.

  2. The service itself in this case is a simple wrap of wrapping App Engine's available image manipulation features which provide standard image manipulation features, but it could easily be more complex.

  3. Next up, the functionality is wrapped in a simple RESTful interface. There are multiple ways to do this, libraries such as the App Engine Rest Server and the Django rest interface or a port of the Ning-like REST interface can be used to do most of the heavy lifting. Gae-Rest for example includes indexes and memcache and other features to optimise response times on the API. These give the API standard GET, POST, PUT, DELETE operations we'll need to push images in and out of the application.

  4. Finally, while we have the service ready to roll we still need a way for developers to access the service, manage their resource usage and track activity on the API. To do this we can use 3scale's API management platform which provides these features out of the box. Connection works using a standard python plugin and the system creates a configurable management portal for the service which handles signup keys, usage limits, traffic analysis and the documentation needed to support developers using the new API. For heavy users we can also add paid plans to cover any App Engine costs or make a small profit - check out the appspotimage portal here:


The service can now take advantage of App Engine's scalability - even under the constraints of the plan, your API should comfortably serve up 500,000 - 1 Million hits per day (although note that you need to check other resource limits - not just hits) which would be non-trivial to arrange and potentially high cost on a lot of existing hosting services. If you're serving traffic from appspot.com (for appspotimage we serve the management interface from appspotimage.com and the API traffic from appspot.com) response times from App Engine tend to be very fast (sub 10ms if you're on the west coast US) - which is great for API users.

Although backend APIs are not quite as visible as a new Android or iPhone App, they often provide a great resource and hopefully we'll see more and more datasets and new types of processing on line as APIs.

You can find the service itself here along with a longer tutorial on how we built it. Stay posted for some other services coming soon, as we start to play around with Java language support on App Engine.

We'll be at Google I/O on May 27-28 and look forward to talking APIs and App Engine, so stop by the Developer Sandbox. See you there!

Posted:
Last April, we started providing translations of code.google.com pages in five languages: Simplified Chinese (中文[简体]) , Japanese (日本語) , Portuguese (Português) , Russian (Pусский) , and Spanish (Español). You didn't think we were done, did you?

Today, we're happy to add Korean (한국어) and Traditional Chinese (中文[繁體]) to that list. We've translated the site directory and top-level site pages, and from now on, you'll find those languages in the drop-down language selector at the top of the page header on code.google.com.

For Korean, you can now find full developer guide translations for OpenSocial API, Gadgets API, Themes API, and Adwords API. We have some API guides coming soon in Traditional Chinese, but unfortunately you'll have to guess which ones while we finish putting the final touches on those translations. If you're interested in hearing about new translations in these languages, you might want to subscribe to the APAC Developer Blog for updates as we add more content.

Good code is a universal language, spoken by developers all over the world. We don't think you should have to read English to build a great app.

Posted:
I set a quarterly goal to write an application in my 20% time that uses publicly available Google APIs. While some would call this scenario testing, I refer to it as "method user experience design" (think method acting). The process can often be painful, but I do it in the hope that it will make me a better designer. It puts me in the shoes of our customers who build products on top of Google's products. I read the same documentation, search the web for the same solutions, write code against the same APIs, and deploy to the same infrastructure. From this exercise come product improvements and empathy. I also enjoy attempting to make something useful, sketching with Python and JavaScript (the charcoal and conte crayon of web development), and proving that 20% time is alive and well.

When it came time to pick last quarter's application, I wanted to work with YouTube's APIs for two reasons: I have a background in video (as a filmmaker and as a software designer) and I wanted to share family videos with my oldest brother, who is hard of hearing and learning disabled. Fast forward a few months later and I had CaptionTube, an application for creating captions for YouTube videos. CaptionTube has launched on TestTube and Hiroto has written a post about it on the YouTube blog.

In addition to the YouTube Data and Player APIs, the application is hosted on Google App Engine and uses the Datastore, Google Accounts, Mail, and URLFetch Python APIs. I used several open source software projects to create it: Django and jQuery, and app-engine-patch. If you are attending Google I/O in May and would like to ask me questions about my experience or discuss your experience using Google's developer's products, please look for me in the developer sandbox or office hour sessions.

Posted:
We frequently hear that developers want to hear from peers who've built interesting applications. That's why we're excited that this year's Google I/O (May 27th - 28th in San Francisco) will involve more developers from the community at large. Today, we're raising the virtual curtain on some of the developers who'll be participating in Google I/O this year.

These developers represent a wide range of companies and apps - all of which are strong examples of Google developer products and open web technologies in action. They'll be presenting technical sessions and demoing their apps at the Developer Sandbox, a new addition to Google I/O featuring demo station "pods". With so many developers at Google I/O, this is a great opportunity for event attendees to check out their apps, ask questions, exchange ideas, and meet new people.

Given the recent App Engine launch, we thought it'd be fitting to introduce a subset of the App Engine developers who will be demoing or presenting at Google I/O:

  • Salesforce.com
    Force.com is the enterprise cloud computing platform offered by Salesforce.com. Salesforce.com is committed to letting developers take advantage of the web as the ultimate platform. Force.com developer evangelist Ron Hess will lead a session outlining how to connect the Force.com SOAP Web Services API to Google App Engine for Java. The project includes an open source Web Service Client that has been completely ported to App Engine. The session will discuss the porting effort, how to use URLFetch to achieve cross- cloud communication and demonstrate a sample integration between App Engine and the Force.com SOAP API.

  • ThoughtWorks and SpringSource
    Guillaume Laforge is the official Groovy Project Manager for SpringSource, and the spec lead of JSR-241, the Java Specification Request that standardizes the Groovy dynamic language. Ola Bini of ThoughtWorks is the creator of the language Ioke and has been one of the core developers for JRuby since 2006. Guillaume and Ola will be speaking about running Groovy (and Grails) and JRuby on top of Google App Engine for Java, respectively.

  • Walk Score (a project of Front Seat)
    Walk Score uses App Engine for the Walk Score API that serves Walk Score data to millions of real estate listings daily. The Walk Score website also uses Google Local Search for their scoring algorithm and Google Maps API for displaying walkability of addresses and heat map views of neighborhoods and cities. The three developers behind Walk Score will be leading a session, AppEngine Nitty-Gritty: Scalability, Fault Tolerance, and Integrating Amazon EC2, outlining their experiences scaling on App Engine and combining App Engine with external services including EC2. They'll also be on hand at the Developer Sandbox.

  • Best Buy
    Giftag, Best Buy's browser add-on for clipping, saving, and sharing web page snippets, launched on App Engine just before Black Friday last year. Using the hProduct open standard and App Engine's datastore API, Giftag enables users to add items to one or more wishlists, then share these via the App Engine-hosted front-end or Facebook. The engineers behind Giftag will be at the Developer Sandbox. (Check out their blog post and video where the team talks about migrating to App Engine)

  • BuddyPoke
    BuddyPoke uses App Engine for fluid and cost effective scalability to handle a rapidly growing user base of over 36 million OpenSocial users. Dave Westwood, founder of BuddyPoke, will be part of the Developer Sandbox. (Check out Dave's video talking about scaling on App Engine)

  • 3scale networks
    3scale provides a Python plug-in that integrates seamlessly to App Engine so that developers can put all their resources into their API's core functionalities. User management, access control, billing and payments can be easily externalized with 3scale for those APIs that run on top of App Engine. The 3scale team will be part of the Developer Sandbox.

To check out speakers, visit the speakers page. To see who'll be demoing at the Sandbox, check out the Developer Sandbox page.

Keep in mind what you see currently on these pages is still 'in progress'. Over the next few weeks, we'll be regularly updating the I/O website with more sessions, speakers, and Developer Sandbox demos, so keep checking back. And each week on the Code Blog, we'll give you a closer look into who these developers are, including guest blog posts authored by them that share their development experiences and tips. (The AJAX API team's gotten a headstart on this)

Finally, we can't end a blog post about Google I/O without a (shameless) plug for actually signing up for the event, so here it is:

<shameless plug>
Early registration for Google I/O ends May 1, so if you're thinking of attending, now's a good time. Sign up at code.google.com/io. We look forward to meeting you!
</shameless plug>

*You can also follow our tweets: @googleio.

Posted:
Last week we had a number of exciting announcements and we've received a lot of good feedback so far. We've heard from developers who were excited about cron support, intrigued by the Google Secure Data Connector and pleased with database import. However, most of the excitement has been reserved for the new integrated development environment which was created through the marriage of Google-Web-Toolkit (GWT), Google App Engine for Java and the Google Plugin for Eclipse. Now not only can web app developers write both client and server code using the familiar Java language, they can also share and reuse code between client and server.

I wanted to capture some real world developer feedback, so as part of our Developer Profiles series I sat down with Paul Hammant of ThoughtWorks to discuss his first impressions with the platform. As Paul continues to tinker with the platform you can of course follow him on his blog.



If you have a compelling application that you've written with Google App Engine and GWT I'd like to hear about it.



Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.

Posted:
We are excited to open registration for our second Google Developer Day event this year, to be held on June 9th in Yokohama, Japan.

June 9, 2009 -- Yokohama, Japan

Located outside of Tokyo at the Pacifico Yokohama Convention Complex in Yokohama, you will learn about the latest with our APIs and developer tools, including Android, Google Chrome, App Engine, AJAX APIs, Maps and more. The topics will vary so you can be sure to discover new and interesting ways to use our applications. And don't forget to take part in the time set aside to socialize with fellow developers and Google engineers - it is a great networking opportunity.

If you are in Asia, registration for Google Developer Day China is also open, though space is running out fast! We hope you can join us for one of our upcoming events.

Posted:
It's time for another Google Narrative, highlighting a Google AJAX Search API developer, Chirag Mehta.

Chirag is developer in St. Petersburg, Florida who got started coding on a ZX Spectrum almost twenty years ago and has dabbled in graphics, animation, databases, ERP/CRMs, and productivity apps. He is currently working as an IT director and is in a graduate program in Technology Management at University of Tampa. He co-founded Chime.TV in 2007 and Sched.org in 2008. His favorite area of development is simple web utilities. Chirag and his wife love animals and when he's not coding or studying, he is either kayaking or playing with their pets.Q: Tell me about how you used Google AJAX Search API for Wiki Search and Drop Search and how you came up with the ideas.

A: My wife's currently in medical school and constantly doing searches online for medical terms. Wikipedia offered tons of information but she found their search feature to be insufficient for her needs. 90% of the time, you have no idea what you're searching for or guessing at it - it doesn't do anything to help you out. I wanted to help my wife have a faster, more dynamic experience so I brainstormed how to build a XML-type of search feature, similar to Google Search Suggest, while you were on Wikipedia. (It also helped that I'd always found Wikipedia interesting and researched databases that used it as a source of information.) That also led me to start looking at implementation options and of them all, AJAX Search seemed the easiest to integrate in a quick manner. Instead of taking two weeks to research documentation and then implement with other APIs, it took about an hour with Google AJAX Search. Also, I had worked with many Google APIs on other projects before, but the Google AJAX API was the best. The speed was amazing!

The idea for creating Drop Search came soon after fiddling with more Google AJAX search documentation. My implementation gives the everyday person without a programming background the ability to add a customized search engine to any site. It's code that you can copy and paste into your application and customize for your own needs using CSS, which I did for my own blog. A friend of mine at Rutgers University saw what I did and wanted the same type of feature for their professional development site so I released the code that I created to everyone on my projects page.

Q: Describe any obstacles you had with implementation.

A: There were none. Actually I had a couple of questions at first but I looked at the forums and got the answer fairly quickly. They were around legal issues - Am I allowed to query as I type? Is it legal that I'm doing this with Wiki search? I wish legal terms were much clearer on Google Code. I had some assumptions, only to find out they were recommendations rather than requirements. I do have to say that the documentation on Google Code is perfect. One minute you're reading documentation, the next you're in the forums reading about other developers' experiences. Help pages are broken down into every bit so it makes coding a cakewalk. It's a really good experience compared to other sites.

Q: Can you provide any tips for other developers using Google AJAX Search API?

A: Before you try to build something, find out if Google already has. Google will build 98% of your needs on the back end, leaving you 2% of the work to focus on making your user interface exactly what you need for the front end. Also, another tip... listen to your wife's complaints.
Thanks for your time Chirag! We love hearing from developers in our community about inspiring stories, so if you have something you'd like to share, visit our online submission form. Or better yet, come to Google I/O and tell us your story in person.

Posted:
We just posted updated terms of service for 5 more APIs to include transparent deprecation policies. This is part of their increased commitment as graduates of Google Code Labs. As we mentioned in March when we introduced Labs, each of these deprecation policies states that we'll support each version of the API for a guaranteed length of time from when it's deprecated or a newer version is introduced. While it's 3 years for most, it might be less for some. With this batch of updates, for example, the Checkout API has a policy of supporting old versions for 1 year while all of the others will support old versions for 3 years.

You can see the updated terms for all 5 APIs:

Posted:
In this video, eBay Platform Architect Farhang Kassaei explains the details behind the launching of eBay's new Selling Manager (beta), which uses OpenSocial's gadget technology to Google Developer Advocate Chris Schalk at the Web 2.0 Conference in San Francisco, CA on April 1st, 2009.

Farhang describes both why they chose to use OpenSocial and Apache Shindig, and how they integrated its gadget server technology into their platform. He also provides information on where gadget developers can go to learn more about eBay's new platform and how to get started building applications.



Farhang Kassaei is a principal architect at eBay Marketplaces where he leads eBay platform design and architecture. During his career with eBay Farhang has been responsible for multiple infrastructure initiatives including identity and access management, open platform, user verification and risk, messaging, user generated content and user graph analysis and infrastructure. He is also a member of eBay Enterprise Architecture team.

Chris Schalk is a Developer Advocate on Google's Developer Programs team.

Posted:
When I sat down to write this post I decided to glance back at my last post on this blog. One sentence in particular jumped out at me: "...I would never again feel compelled to build an [Object-Relational] Mapping framework in Java." Well, friends, never say never. Now that we've unveiled an early look at Java support for Google App Engine, I'm thrilled to announce the availability of a JDO and JPA implementation for the App Engine datastore under the Apache 2 open source license.

The App Engine datastore is an incredible piece of technology. Based on Google's own Bigtable, it's one of the key reasons App Engine enables developers to write web applications that scale without infrastructure headaches. But, it isn't necessarily what most of us are accustomed to using for persistence. Wouldn't it be lovely if we could use an existing programming model on top of the datastore API? And wouldn't it be even lovelier if that existing programming model simplified the process of porting web applications on and off App Engine?

Fortunately for us Java developers we have not one, but two persistence standards at our disposal, JDO and JPA. And, to make adopting these persistence standards easier, we have the DataNucleus project (formerly JPOX), which provides plugins that connect these standards to various types of datasources. Andy Jefferson, founder of the DataNucleus project, was not only enthusiastic about our effort to add an App Engine plugin to his project, he was also incredibly helpful (thanks Andy!). I hope you're as excited about the results as I am: Standards-based persistence for the App Engine datastore!

Since App Engine for Python launched almost a year ago I've admired not just the applications that have been built by the developer community but the infrastructure as well. Even though the DataNucleus App Engine plugin was developed by Googlers, it uses the public App Engine APIs that are available to everyone. It uses no backdoors or special privileges. Rather, it is merely the first instance of what I hope will be a torrent of Java infrastructure developed for App Engine for Java. Feel free to peruse the code at http://code.google.com/p/datanucleus-appengine. If you find a bug, send us a patch. And if you think you can do better, do better! There's absolutely nothing stopping you.

Posted:
I'm excited to announce new, highly requested features for App Engine which we unveiled a few minutes ago at Campfire One.

First, we're giving developers an 'early look' at Java™ language support for App Engine. The team has taken a standards based approach, implementing standard Java APIs on top of App Engine where possible. So instead of using the underlying App Engine datastore API, developers can program against Java Data Objects or Java Persistence API.

Developers will also be able to easily build AJAX web applications end-to-end in Java through integration with a new version of Google Web Toolkit and a Google Plugin for Eclipse to support the development experience.

In addition to the Java features, we've also released cron support , data import support, and secure access to data behind the firewall. To learn more, read the full announcement on the App Engine Blog and watch the videos from Campfire One below: (Note: The video will be live soon)



Still needing a developer fix? If you want to dive deeper into these new features, and how to get more out of App Engine and Google Web Toolkit, we encourage you to come talk to us at Google I/O on May 27-28 in San Francisco CA. We'll be there conducting in-depth App Engine and Google Web Toolkit technical sessions and talking to developers. We'd love to hear your feedback about the features, and just see what you are up to.

*Java™ is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries.

Posted:
When I first started at Google, we were building a Java ME email client for the phones of the day. It's an excellent product - still the fastest, slickest way to get your Gmail on many devices because of Java ME's widespread penetration. Yet it always bothered us that this client didn't really leverage the core strength of the desktop Gmail platform: sheer ease of access from anywhere, and constant updates and improvements. To use the client, you have to figure out how to install it and possibly navigate confusing network permission pop-up dialogs, and improvements could only be rolled out a few times a year in upgrades that required every user to download and reinstall their software.

The mobile team started thinking about how we could bring the benefits of the server-side approach to these clients. We started thinking about a world where we could deliver a GUI specified in XML to a Java ME client, enabling us to iterate on the server side and deliver new features that could delight users when they were ready, rather than on a lengthy release cycle. I was especially struck by a friend who said "What I like about Gmail is that it just constantly keeps getting better. It's like waking up to a new little present from Google each month!" We wanted our mobile users to feel the same way, so we felt the logical thing to do would be to build a general client that could be controlled by the server.

Not too long after, the team first saw the new Android browser. Still in its early stages, the Android browser was built on the latest version of WebKit and could render desktop pages with ease. The XHTML, images, JavaScript, and CSS that could be rendered on this platform presented great potential for building very high-end web applications. However, this was ages before Android was due to ship and Android would only be one of many mobile platforms.

Those drawbacks aside, we couldn't help but think that new browsers in Android's league would eventually become a reality. These powerful browsers could have the kind of functionality we needed to build top-notch, offline user interfaces that didn't need to be "installed" by users or "upgraded". Gmail could be Gmail: a constantly evolving way to handle lots of email quickly and efficiently. The only fly in the ointment was the need for Gears: users would have to download a browser plug-in, and most web browsers on mobile devices don't even support that. What we really needed was for Gears to inspire innovation in HTML itself, so that the whole web could move forward.

Enter HTML5. We're very excited about the evolving HTML5 standard because it enables mobile and desktop website designers to deliver the advantages of client-side and server side development to their users simultaneously! New APIs let web applications start offline and store data on the client. The canvas API lets you draw complex user interfaces, or you can use advanced CSS tricks to get the browser to render a rich UI. In addition, the W3C Geolocation API is being adopted and implemented by browser developers, enabling entire new categories of web applications to be built. The benefits are clear: you can develop fantastic new applications, benefit from server-side analytics and iteration to deliver features that your users want, and know that offline functionality keeps things running as the user moves in and out of coverage. Your users can enjoy fast, capable web apps that they can access from any device, without the need to copy their data from place to place or worry about installing software or being online.

We decided to build new versions of mobile Gmail and mobile Calendar on top of this functionality. First, we built a small javascript wrapper around the database functionality in HTML5 and Gears. This wrapper abstracts away the differences between the two APIs, so that our applications are supported on the broadest set of browsers possible while older browsers get updated with implementations of the new offline APIs. We noticed that we weren't the only ones thinking about this: a quick search shows that other developers saw the similarities too. The main difference between the Gears database API and the HTML5 database API is that the Gears API is synchronous, requiring separate worker threads to do the database calls, while the HTML5 database API uses callbacks and is asynchronous. With the wrapper built, we knew our code would run on all high-end mobile browsers today, and look forward to even more distribution as everybody implements HTML5.

We knew we could apply various approaches to building better experiences for Gmail and Calendar. The key principle we kept in mind is an age-old one: KISS. Simply caching responses in the database for re-use is surprisingly effective: you can get a lot of improvement with just a read-only environment. This approach worked well for Calendar, where usage is predominantly read-only and we can rely on the user being online to make edits.

For Gmail, more complexity was needed. A queue of user actions needs to be maintained in the database (in case the user runs out of battery or powers down for their flight). Later, when the device is back online, it can execute that queue of mails to send, archive or delete, and so on.

Having the ability to store your data and actions offline isn't much good if you can't start the application while offline. So besides making use of the database API, we needed a way to get the application itself loaded without an internet connection. The HTML5 specification comes to the rescue here, with an application cache that is capable of storing all resources in your web app so that the browser can load them while offline. This API has just one small drawback: once you've decided you're going to override how HTTP GET works to fetch resources from the application cache, you also commit to never issuing a GET for a resource the cache doesn't know about. The specification contains methods for extending what URIs the cache knows exist, but these entry points are not widely implemented in production browsers. Instead, it's important to use HTTP POST requests for all dynamic data, since POST requests are never cached and therefore do reach the network.

The end result is an incredible thing: a web app that loads offline, and lets you read your Gmail or view your events provided the data have previously been cached. The experience is seamless as you ride the subway or the bus through terrible coverage: your data are ready, quickly, all the time. To see the new Gmail for mobile web app, go to gmail.com from an Android-powered device or iPhone (OS 2.2.1 or above).

Of course we didn't get there without a few hard knocks. As an evolving standard, HTML5 has been fast-changing target and we've skinned our knees and bruised ourselves along the way. So rather than just deliver the fruit of all those bumps and scratches to end users in our own products, we decided we wanted to write a few blog posts to share what we've learned so that others can take advantage of HTML5 as well. In addition, we look forward to opportunities like our upcoming developer conference, Google I/O (May 27-28 in San Francisco, CA) where we'll be hosting a few sessions, to meet you in person and share demos and know-how.

Whether or not you can make it out to Google I/O, stay tuned to the blog for upcoming posts with examples such as how to avoid making your databases too large, handle upgrades gracefully, and tune performance.

Posted:
Google Developer Days 2009, a set of one-day developer events, are returning again and will take place in various locations around the globe. Like last year, we've designed these events for developers with strong coding experience so we can discuss our APIs, developer tools and applications.

We'll host Google Developer Day in these locations:
  • Beijing, China (June 5)
  • Tokyo, Japan (June 9) -- more information coming soon
  • Sao Paulo, Brazil (June 29) -- more information coming soon
If you're based in the US, we encourage you to come to Google I/O, on May 27-28 in San Francisco.

At Google Developer Day, attendees will learn about Google developer products from the engineers who built them. They will share their inside knowledge on our developer tools and APIs, including Android, Chrome, Ajax APIs , GWT, and App Engine. We will also do deep dives into our products at "office hours," during which developers can bring their own snippets of code or specific product questions to the Google engineers behind the product.

We've posted detailed information for China and will be adding more information for other locations soon. Space is limited so make sure you sign-up early. Hope to see you there!

Posted:
I am very pleased to announce version 2 of the AJAX APIs Playground. For those of you not familiar with it, the Playground is an educational application designed to show interactive code samples for some of Google's coolest Javascript APIs. Of the new changes, the most obvious is the sweet new UI, thanks to help from Roman Nurik of the Google Earth team.

The new features are:
  • * Break points (simulated in Javascript)
  • * Firebug Lite in output for debugging
  • * Line numbers in code editor
  • * Ability to edit HTML of samples



    The breakpoints and Firebug Lite additions are my favorite new features. But why did I include Firebug Lite when all web developers (should!) have Firebug installed? Because when code runs on the Playground, it runs in an iFrame. That iFrame does not have the Firebug object initialized in it. Since it is a cross-domain iFrame, there's no simple way to add Firebug to the iFrame's window object, so adding Firebug Lite was the best approach. This makes it so you can now use all of your favorite Firebug debugging convenience functions in the Playground!

    To use Firebug Lite and breakpoints, simply click on the line number you want to add a breakpoint to and hit "Debug Code". This will insert Firebug Lite into the output and pause the execution on the breakpoint line number until you to click the play button to continue. Try adding a breakpoint to a line, clicking "Debug Code", then opening Firebug Lite and typing in a variable name to inspect the contents/value of the variable at that point in the code.

    Adding breakpoints and forcing Firebug into a local function context were really fun engineering problems, so if you want to check them out (or contribute code to the Playground) go to the open source repository for it, come chat it up on IRC, or talk with me in person at the quickly approaching Google I/O conference (early bird registration runs until May 1).

    Also, it's really important that you share your feedback so that I know what you'd like to see in the next version of the Playground! Thanks, and enjoy the Playground!