Google Sidewiki makes it easy for visitors of your website to share helpful information with each other. Unlike regular comments, all Sidewiki entries are ranked by usefulness so that the best ones are shown first. The element was built entirely on the Sidewiki API and can be customized in many ways to fit into your site. Sidewiki originally launched as a feature of Google Toolbar and as a Chrome extension - this element is our newest step in making Sidewiki more open and accessible across the web. If you'll be using the element on your site, let us know via @googlesidewiki on Twitter!

If you're looking for a way to add commenting to an otherwise static page, the Google Sidewiki element gives you an easy and simple way to collect and display comments about a page. One of the new and exciting features of the Sidewiki element is that it allows visitors to leave a comment even if they do not have Sidewiki or Google Toolbar installed. Like all Sidewiki entries, the comments in the element will be ranked to show the most useful items more prominently.

Checkout element

The Google Checkout element allows you to quickly and easily create an online store using a spreadsheet. Once you have a Google Checkout merchant account, you just have to add details for each item you're selling into a Google Spreadsheet, then use the wizard and copy/paste the code into your website. The element is compatible with Blogger, Google Sites, iGoogle, and personal websites where HTML can be modified, but doesn't require any programming skills or experience. In fact, you can get your first online store up and running in under five minutes.

Wave element

The Google Wave element enables you to quickly drop a wave -- a shared workspace -- onto your own website. The wave could be used for many different things, including: encouraging collaborative discussion among the visitors, or as a means of publishing content on the page. For deeper integrations of waves onto your own site, please check out the recently improved Wave Embed API. For more information on embedding waves, see the Google Wave Developer Blog post.

Virtual Keyboard element

Adding a virtual keyboard to your site just got easier with the Google Virtual Keyboard element. After choosing a keyboard layout, copy and paste the HTML into your page and voila, a virtual keyboard will be able to enter characters into any text input or text area on your page. If you've never heard a virtual keyboard, it's an on screen keyboard which translates the input from one keyboard layout to another and it allows users to type their own languages on foreign keyboards or by clicking the on screen display.

Google Web Elements are great for folks who don't have much time or experience. However, even for advanced developers, elements are a great starting point, as most are backed by an underlying API to give you even more control over the content or look and feel. Take a look at all of the elements at http://www.google.com/webelements and stop by our help forum if you have any questions.

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.

A couple weeks ago I was up in Seattle talking about the Google Apps Marketplace with local SaaS companies. I was happy to be joined by Smartsheet, Concur and Skytap and even more excited when they all talked about their success on the Marketplace.

We’ve invited Smartsheet to talk about their success on the Google Apps Developer Blog and their founder, Brent Frei, has written an excellent post which I hope you’ll all take the time to read. He talks about how they decided to launch on the Marketplace, their technical evaluation, development process and the results they’ve achieved.

Here’s a graph that tells much of the story-- it shows their new customer leads (excluding pay-per-click-ads):

Not everyone likes to start their day with just a search box and logo (no matter how cool it is!). Many users want email, videos, news, weather, games, and other information to be at their fingertips each time they open up a browser window. We launched iGoogle in 2005 to address this need by providing a truly personalized homepage with access to any RSS feed and well over a hundred thousand gadgets.

One of the first developers to create gadgets for iGoogle was Labpixies. Over the years, we worked closely together on a variety of projects, including the launch of a number of global OpenSocial based gadgets. Recently, we decided that we could do more if we were part of the same team, and as such, we're thrilled to announce the acquisition of Labpixies.

The team will be based in our ever-growing Tel Aviv office and will anchor our iGoogle efforts across Europe, the Middle East, and Africa. We are looking forward to working with Labpixies to develop great web apps and leverage their knowledge and expertise to help developers and improve the ecosystem overall.

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:

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.

As we announced in the last update to the former orkut Developer Blog last week, henceforth we’ll be posting all orkut developer updates to this blog.

We think this is also a good opportunity to quickly introduce the newly-launched Developer page to you. We recently added this feature to the orkut sandbox which we hope to be a one-stop solution for developers looking to manage their applications from a single page and view their stats. You can submit your apps directly from here and verify them to complete the submission process. You can also maintain your apps from here and migrate them to a new URL, or delete them entirely from the directory. And if you have applications that have already been approved and included in the directory, expand their details to track the number of installs, uninstalls, renders and other useful stats updated every week.

Here’s what it looks like in action:

Please note that the Developer page requires you to be on the new orkut UI to work.

So keep your apps coming and point your browser to the one page to manage them all: sandbox.orkut.com/Main#Developer. And stay tuned for all orkut updates right here on the Google Code Blog!

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.

Over the next few weeks, we'll be inviting developers from these companies to do guest posts on this blog -- giving you insight into their development work and their approach to using Google technologies like Chrome, the Android SDK, GWT and Google APIs.

And for those of you who'll be at Google I/O next month, you'll have the opportunity to meet these developers in person at the Developer Sandbox, which runs for the duration of the conference (see event schedule).

Earlier today Meeboannounced Extended Authentication (XAuth), an open platform that makes it possible for users to bring their preferred services with them across the web.

To learn more about XAuth and why we're among the supporters of this technology, check out our post on the Social Web Blog.

From a technical perspective, we wanted to offer you some additional insights into how this technology works.

If you visit Meebo's XAuth page, you should see an array of logos:

When this page loaded, it requests the list of services that have been registered with XAuth by making an HTML5 window.postMessage request to xauth.org. As you can see in the graphic, no active sessions were detected.

When the user clicks through to one of the linked demo pages — we'll use googxauthdemo.appspot.com in this case — the same JavaScript is loaded from xauth.org. When the user successfully authenticates, some basic information is pushed to the browser's HTML5 localStorage:

<scripttype="text/javascript">

functiondoLogin(doneUrl){

/* Tell XAuth.org that a user has just signed into Google on this browser. */

XAuth.extend({

// reveals "someone is logged into Google"

token:"1",

// Expires after 24 hours or if the user explicitly logs out

expire:newDate().getTime()+60*60*24*1000,

// Allow any domain to read this info (could also be a whitelist of partners)

extend:["*"],

// Optional callback function once extend() has completed.

callback:makeRedirectFunc(doneUrl)

});

}

</script>

This information — that the user has an active session at googxauthdemo.appspot.com — is now available to any site on the web (because extend: ["*"] uses the wildcard case to make this information world-readable; providers can also choose to restrict access to this information to certain domains or partners).

Upon returning to meebo.com/xauth, the page requests the list of active sessions from XAuth, and passes the browser an array of domains that the browser will match against the local storage for xauth.org:

The major performance and scalability benefits of this design are a result of the single HTTP request made to xauth.org to determine which services are currently active, rather than one-request-per-domain. The request and response are also purely client-side, so there's no waiting for a server to look up anything in a database — and the XAuth JavaScript files get cached after they are first retrieved, making XAuth overall very efficient.

Once the tokens are retrieved the program iterates through them looking for matches, and then modifies the interface according the service token discovered, like this:

<scripttype="text/javascript">

functionreceiveTokens(responseObj){

vartokens=responseObj.tokens;

vartoken=tokens['xauth.org'];

varpartners={};

vartokensFound=false;

if(tokens['googxauthdemo.appspot.com']){

partners['google']=true;

tokensFound=true;

varstatus=document.getElementById('status-google');

status.innerHTML='Signed In!';

status.style.color='#0A0';

}

}

</script>

In this way, site publishers can detect a user's set of active and preferred services, or request a subset of known services, and present only those services which are known to be currently active. In practice, the list of services provided at any given time by xauth.org should not be considered exhaustive, but instead a suggestion for how to prioritize complex service selection dialogs and interfaces, like those known as "NASCAR" interfaces.

For more technical information about XAuth, please read the spec, or visit the informational page on xauth.org.

From there, you can do some basic customization of the buttons, including specifying the content that will be included when users post. When you configure the URL option for your button, we’ll use that URL to include a preview of the page based on its title and meta description tags. If you don’t specify a link, we’ll take our best guess by including the page on which you placed the button. Likewise, when you set up an image URL, we’ll add a thumbnail of that image to the post your users create. If you prefer to set up your buttons by hand, these options and more are also available through our JavaScript API -- for more details, check out our spec.

Given a list of cell phone towers, the cost or gain of upgrading each one, and the requirement that every upgraded tower can only have upgraded towers in its range, can you find the most profitable set of towers to upgrade?

Caught your attention? Then we have the competition for you.

We’re thrilled to announce Google’s annual Code Jam competition. Google Code Jam is a programming competition in which professional and student programmers solve complex algorithmic challenges in a limited amount of time. The contest is all-inclusive: Google Code Jam lets you compete in the programming language and development environment of your choice.

And, this year, for the very first time, the final competition will take place in Google’s Dublin office.

The qualification round starts on May 7th, 2010 and after four rounds of online competition, the top 25 competitors will be flown to Google's Dublin office to match wits for the $5,000 first prize — and the title of Code Jam champion!