Saturday, May 21, 2011

[Gd] Be A Revolutionary!

| More

OpenSocial API Blog: Be A Revolutionary!

On May 12, 2011, the OpenSocial community came together for the annual State of the Union event. That day will be remembered as the start of the “Open App Revolution!” (#openapprevolution)  A special thank you to Google, who was kind enough to host us at their offices in San Francisco, CA. (Tweet: “Thanks Google & Paul Lindner for hosting the OpenSocial State of the Union #ossotu #OpenSocial #openapprevolution”)

The event featured were a number of prominent speakers at the event discussing what’s coming in OpenSocial 2.0. Monica Wilkenson and Evan Prodromou discussed the value of Activity Streams and the importance of aligning this work with the spec. Several folks from IBM, Ryan Baxter, & Andrew Davis, demonstrated how OpenSocial based applications can be embedded directly in the stream. 

Even more exciting was work that is being done to enable apps on mobile devices. Jason Gary, Andy Smith, also from IBM, showed the same OpenSocial application running on seven different mobile devices. Jason & IBM committed to the OpenSocial community to have all the code contributed to Apache Shindig! This is great news for the community and will significantly advance and accelerate apps on mobile! (Tweet: “Can’t wait for Road Trip and Chassis to be in Shindig!!-Thx Jason #openapprevolution”)

Paul Lindner discussed the roadmap for Apache Shindig. Most implementations of OpenSocial are based on Shindig, and his presentation demonstrated how vibrant and active development is on the code base. This was followed by Chris Cole demonstrating the simplicity and power of the advanced features of OpenSocial, including templating and data-pipelining. Matt Null from Survey Gizmo talked about his experience building an application that works on three different containers, Jive, SAP, and iGoogle—with more to come.  

We concluded the State of the Union with an engaging panel discussion the focused on the business value of building applications and the economics of app markets. The panel consisted of Chris Kohlhardt from Gliffy, Ryan Nichols from Appirio, Mark Halvorson from Attlasian, Jeff Hotchkiss from Xobni, and was moderated by Robin Bordoli of Jive. You can find many of the slides from the event on the OpenSocial wiki. We'll continue to post the videos as we get them. 

2011 – The year of Business Applications
2010 was more than just a growth year for OpenSocial. With the expanded set of consumer targeted social networks, an increase in domain specific social networks, and the adoption of OpenSocial as a platform technology by enterprise vendors, OpenSocial has established itself as the fundamental technology driver of the app based economy.  In 2011 we will see application market places from enterprise vendors like Jive, Xobni, and Atlassian—all based on OpenSocial.

Open technology is the foundation of the Web. This is the time for application providers to leverage these platforms and market places to break down the barriers of software acquisition, open up new delivery channels, and change the way business gets done. Innovative companies like Gliffy and Surveygizmo are great examples of the new way to build and deliver powerful business applications.

The time is NOW for an Open App Revolution.

This is YOUR call to arms. 

Be A Revolutionary!

Posted by Mark Weitzel, President, OpenSocial Foundation
URL: http://blog.opensocial.org/2011/05/be-revolutionary.html

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

The Chrome Beta channel has been updated to 12.0.742.60 for all platforms.  This release contains a number of UI tweaks and performance fixes.  The full list of changes is available in the SVN revision log.  Interested in switching to the Beta channel?  Find out how.  If you find a new issue, please let us know by filing a bug.

Jason Kersey
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/05/beta-channel-update_18.html

[Gd] Troubleshooting Instant Previews in Webmaster Tools

| More

Official Google Webmaster Central Blog: Troubleshooting Instant Previews in Webmaster Tools

Webmaster level: All

In November, we launched Instant Previews to help users better understand if a particular result was relevant for a their search query. Since launch, our Instant Previews team has been keeping an eye on common complaints and problems related to how pages are rendered for Instant Previews.

When we see issues with preview images, they are frequently due to:
  • Blocked resources due to a robots.txt entry
  • Cloaking: Erroneous content being served to the Googlebot user-agent
  • Poor alternative content when Flash is unavailable
To help webmasters diagnose these problems, we have a new Instant Preview tool in the Labs section of Webmaster Tools (in English only for now).



Here, you can input the URL of any page on your site. We will then fetch the page from your site and try to render it both as it would display in Chrome and through our Instant Preview renderer. Please keep in mind that both of these renders are done using a recent build of Webkit which does not include plugins such as Flash or Silverlight, so it's important to consider the value of providing alternative content for these situations. Alternative content can be helpful to search engines, and visitors to your site without the plugin would benefit as well.

Below the renders, you’ll also see automated feedback on problems our system can detect such as missing or roboted resources. And, in the future, we plan to add more informative and timely feedback to help improve your Instant Previews!

Please direct your questions and feedback to the Webmaster Forum.

Posted by Michael Darweesh, Software Engineer
URL: http://googlewebmastercentral.blogspot.com/2011/05/troubleshooting-instant-previews-in.html

[Gd] Easier URL removals for site owners

| More

Official Google Webmaster Central Blog: Easier URL removals for site owners

Webmaster Level: All

We recently made a change to the Remove URL tool in Webmaster Tools to eliminate the requirement that the webpage's URL must first be blocked by a site owner before the page can be removed from Google's search results. Because you've already verified ownership of the site, we can eliminate this requirement to make it easier for you, as the site owner, to remove unwanted pages (e.g. pages accidentally made public) from Google's search results.

Removals persist for at least 90 days
When a page’s URL is requested for removal, the request is temporary and persists for at least 90 days. We may continue to crawl the page during the 90-day period but we will not display it in the search results. You can still revoke the removal request at any time during those 90 days. After the 90-day period, the page can reappear in our search results, assuming you haven’t made any other changes that could impact the page’s availability.

Permanent removal
In order to permanently remove a URL, you must ensure that one of the following page blocking methods is implemented for the URL of the page that you want removed:
This will ensure that the page is permanently removed from Google's search results for as long as the page is blocked. If at any time in the future you remove the previously implemented page blocking method, we may potentially re-crawl and index the page. For immediate and permanent removal, you can request that a page be removed using the Remove URL tool and then permanently block the page’s URL before the 90-day expiration of the removal request.



For more information about URL removals, see our “URL removal explained” blog series covering this topic. If you still have questions about this change or about URL removal requests in general, please post in our Webmaster Help Forum.

Written by Jonathan Simon, Webmaster Trends Analyst
URL: http://googlewebmastercentral.blogspot.com/2011/05/easier-url-removals-for-site-owners.html

Friday, May 20, 2011

[Gd] ADK at Maker Faire

| More

Android Developers Blog: ADK at Maker Faire

This weekend is Maker Faire, and Google is all over it.

Following up on yesterday’s ADK post, we should take this opportunity to note that the Faire has chased a lot of ADK-related activity out of the woodwork. The level of traction is pretty surprising giving that this stuff only decloaked last week.

Convenience Library

First, there’s a new open-source project called Easy Peripheral Controller. This is a bunch of convenience/abstraction code; its goal is to help n00bs make their first robot or hardware project with Android. It takes care of lots of the mysteries of microcontroller wrangling in general and Arduino in particular.

Bits and Pieces from Googlers at the Faire

Most of these are 20%-project output.

Project Tricorder: Using the ADK and Android to build a platform to support making education about data collection and scientific process more interesting.

Disco Droid: Modified a bugdroid with servos and the ADK to show off some Android dance moves.

Music Beta, by Google: Android + ADK + cool box with lights for a Music Beta demo.

Optical Networking: Optical network port connected to the ADK.

Interactive Game: Uses ultrasonic sensors and ADK to control an Android game.

Robot Arm: Phone controlling robot arm for kids to play with.

Bugdroids: Balancing Bugdroids running around streaming music from an Android phone.

The Boards

We gave away an ADK hardware dev kit sample to several hundred people at Google I/O, with the idea of showing manufacturers what kind of thing might be useful. This seems to have worked better than we’d expected; we know of no less than seven makers working on Android Accessory Development Kits. Most of these are still in “Coming Soon” mode, but you’ll probably be able to get your hands on some at the Faire.

  1. RT Technology's board is pretty much identical to the kit we handed out at I/O.

  2. SparkFun has one in the works, coming soon.

  3. Also, SparkFun’s existing IOIO product will be getting ADK-compatible firmware.

  4. Arduino themselves also have an ADK bun in the oven.

  5. Seeedstudio’s Seeeeduino Main Board.

  6. 3D Robotics’ PhoneDrone Board.

  7. Microchip’s Accessory Development Starter Kit.

It looks like some serious accessorized fun is in store!

URL: http://android-developers.blogspot.com/2011/05/adk-at-maker-faire.html

[Gd] WebP in Chrome, Picasa, Gmail With a Slew of New Features and Improvements

| More

Chromium Blog: WebP in Chrome, Picasa, Gmail With a Slew of New Features and Improvements

Since we announced WebP, a new image format based on WebM technology and the VP8 codec, we’ve been working hard with the open web community to improve and enhance it. Today we are happy to share news about a few new features and expanded support for WebP.

New Features

WebP's compression algorithms have been significantly improved while remaining completely
compatible with the previous releases. We hope the quality of a few sample images in the new gallery will delight you.

On the decoding side, we have integrated a fancy upsampler. Fancy upsampling reduces the pixelation of strong edges. You can see this feature when you zoom in, for example on a WebP image with red edges converted from this PNG original:

Original image in PNG format
Without fancy upsampling: strong stair-like patternWith fancy upsampling: smoother edge

We also introduced the ability to incrementally decode the data as your computer downloads it from the web, a feature that allows the browser to display images without having to wait for the whole file to download. This feature is already enabled in Chrome 12.

On the encoding side, to further improve quality, we focused on segmenting the picture into areas with similar compressibility. For each of these segments, we tune the amount of compression and filtering differently, and bits are redistributed where they are most useful. Take for instance the image reproduced below [1]:

The easy segment contains lot of disparate signals and can be compressed more than the difficult one, which will be assigned more bits. In this example, the encoder only used two segments. By using even more segments (up to four), WebP is now able to retain many of the original details of the image [2]. This is in contrast to the frequent ringing artifacts one can clearly see in JPEG images.

The uneven distribution of bits between difficult and easy area is controlled in the new encoder using the -sns parameter, short for Spatial Noise Shaping. Its value can be set from 0 to 100 (0 meaning OFF) and with a default of 80. Note that when you enable SNS, PSNR may be degraded, but the overall visual quality is much improved.

We’ve added simple encoding and decoding example binaries to the libwebp library. In addition, we’ve added JNI support that allows Java programs to decode WebP images. Next up is transparency, also known as Alpha channel; we’re experimenting with it now and planning to add it to the next stable version of the codec. In parallel, we continue to improve the codec’s speed and will release a complete specification for the metadata format.

Increased adoption

WebP is now natively supported in Chrome and Opera. Google products including Gmail and Picasa Web Albums, have also added support to WebP so you can share, send and receive WebP images. WebP support is coming to AppEngine. In addition, Google Instant Previews now store images in WebP to reduce their storage needs.

Users that want to manipulate WebP images can now do so using software developed by the community including Pixelmator, ImageMagick, the WebP format plugin for Photoshop and the Java VP8 decoder. The open-source community has also contributed support for Mac OS X with MacPorts packages, Linux Debian, OpenSUSE and Gentoo packages and the Apache HTTP Server. On Windows, users who want to view WebP images natively, can download the WebP codec. This codec brings WebP support to such software as Microsoft Office 2010, Windows Media Center and Photo Edit.

The new features, quality improvements and increased adoption of WebP get us excited about its future. As always, we’re looking for more feedback as well as code contributions from the community. Let us know on the mailing list how your experiments are panning out and what new features you’d like to see in the future.


Image credits:
[1]: "Kayaker at Ekstremsportveko 2010, Voss". Image Author: Kjetil Birkeland Moe. Reproduced with permission of the author. PNG source, and Blog post by author with comparison of JPEG and WebP.

[2]: A storm at Pors-Loubous, Plogoff, Finistère, France. Image Author: Henri Camus. Permission: CC-BY; CC-BY-1.0. Source: http://commons.wikimedia.org/wiki/File:A_storm_at_Pors-Loubous.jpg

Posted by Richard Rabbat, Product Manager and Pascal Massimino, Software Engineer
URL: http://blog.chromium.org/2011/05/webp-in-chrome-picasa-gmail-with-slew.html

[Gd] Fridaygram

| More

The official Google Code blog: Fridaygram


By Scott Knaster, Google Code Blog Editor

Did you participate in Google I/O last week? Nearly 1 million people did, by attending in person in San Francisco, gathering at dozens of I/O Extended events around the world, or watching the live streamed keynotes and sessions on YouTube.


Google I/O pushed an enormous amount of information out into the world. Here on this blog, we did our part by publishing many posts about new Google announcements, along with a bunch of guest posts written by developers. Because there were so many posts last week, I figured you might have missed some, so I want to highlight a couple of them here.

In this post, Cameron Henneke writes about his experience developing GQueues Mobile, a task manager app. Cameron discusses the trade-offs developers have to think about when coding for mobile platforms. Should you develop in HTML or go native? What are the advantages to each? How will that choice affect development? What do your users really want? Cameron’s post contains a thorough and candid discussion of his decision-making process.

Another post describes a versatile new technology called near field communication (NFC) and how doubleTwist uses it to share information from one Android device to another. NFC provides a super-low overhead way for two devices to exchange a small amount of data, and doubleTwist’s post not only demonstrates a practical use of NFC in an app, but also provides a lot of sample code to show how they did it.


Finally, I was pretty busy during Google I/O and I didn’t get to see all the sessions I wanted. Luckily, it’s not too late for anybody to experience more of I/O by watching session videos on YouTube. For my weekend nerd fun, I plan to grab some popcorn and go here. When it’s time to take a break, I can even rock out with Jane's Addiction on the After Hours video. Party!

URL: http://googlecode.blogspot.com/2011/05/fridaygram.html

[Gd] A Bright Idea: Android Open Accessories

| More

Android Developers Blog: A Bright Idea: Android Open Accessories

[This post is by Justin Mattson, an Android Developer Advocate, and Erik Gilling, an engineer on the Android systems team. — Tim Bray]

Android’s USB port has in the past been curiously inaccessible to programmers. Last week at Google I/O we announced the Android Open Accessory APIs for Android. These APIs allow USB accessories to connect to Android devices running Android 3.1 or Android 2.3.4 without special licensing or fees. The new “accessory mode” does not require the Android device to support USB Host mode. This post will concentrate on accessory mode, but we also announced USB Host mode APIs for devices with hardware capable of supporting it.

To understand why having a USB port is not sufficient to support accessories let’s quickly look at how USB works. USB is an asymmetric protocol in that one participant acts as a USB Host and all other participants are USB Devices. In the PC world, a laptop or desktop acts as Host and your printer, mouse, webcam, etc., is the USB Device. The USB Host has two important tasks. The first is to be the bus master and control which device sends data at what times. The second key task is to provide power, since USB is a powered bus.

The problem with supporting accessories on Android in the traditional way is that relatively few devices support Host mode. Android’s answer is to turn the normal USB relationship on its head. In accessory mode the Android phone or tablet acts as the USB Device and the accessory acts as the USB Host. This means that the accessory is the bus master and provides power.

Establishing the Connection

Building an Open Accessory is simple as long as you include a USB host and can provide power to the Android device. The accessory needs to implement a simple handshake to establish a bi-directional connection with an app running on the Android device.

The handshake starts when the accessory detects that a device has been connected to it. The Android device will identify itself with the VID/PID that is appropriate based on the manufacturer and model of the device. The accessory then sends a control transaction to the Android device asking if it supports accessory mode.

Once the accessory confirms the Android device supports accessory mode, it sends a series of strings to the Android device using control transactions. These strings allow the Android device to identify compatible applications as well as provide a URL that Android will use if a suitable app is not found. Next the accessory sends a control transaction to the Android device telling it to enter accessory mode.

The Android device then drops off the bus and reappears with a new VID/PID combination. The new VID/PID corresponds to a device in accessory mode, which is Google’s VID 0x18D1, and PID 0x2D01 or 0x2D00. Once an appropriate application is started on the Android side, the accessory can now communicate with it using the first Bulk IN and Bulk OUT endpoints.

The protocol is easy to implement on your accessory. If you’re using the ADK or other USB Host Shield compatible Arduino you can use the AndroidAccessory library to implement the protocol. The ADK is one easy way to get started with accessory mode, but any accessory that has the required hardware and speaks the protocol described here and laid out in detail in the documentation can function as an Android Open Accessory.

Communicating with the Accessory

After the low-level USB connection is negotiated between the Android device and the accessory, control is handed over to an Android application. Any Android application can register to handle communication with any USB accessory. Here is how that would be declared in your AndroidManifest.xml:

<activity android:name=".UsbAccessoryActivity" android:label="@string/app_name">
<intent-filter>
<action android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED" />
</intent-filter>

<meta-data android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED"
android:resource="@xml/accessory_filter" />
</activity>

Here's how you define the accessories the Activity supports:

<resources>
<usb-accessory manufacturer="Acme, Inc" model="Whiz Banger" version="7.0" />
</resources>

The Android system signals that an accessory is available by issuing an Intent and then the user is presented with a dialog asking what application should be opened. The accessory-mode protocol allows the accessory to specify a URL to present to the user if no application is found which knows how communicate with it. This URL could point to an application in Android Market designed for use with the accessory.

After the application opens it uses the Android Open Accessory APIs in the SDK to communicate with the accessory. This allows the opening of a single FileInputStream and single FileOutputStream to send and receive arbitrary data. The protocol that the application and accessory use is then up to them to define.

Here’s some basic example code you could use to open streams connected to the accessory:

public class UsbAccessoryActivity extends Activity {
private FileInputStream mInput;
private FileOutputStream mOutput;

private void openAccessory() {
UsbManager manager = UsbManager.getInstance(this);
UsbAccessory accessory = UsbManager.getAccessory(getIntent());

ParcelFileDescriptor fd = manager.openAccessory(accessory);

if (fd != null) {
mInput = new FileInputStream(fd);
mOutput = new FileOutputStream(fd);
} else {
// Oh noes, the accessory didn’t open!
}
}
}

Future Directions

There are a few ideas we have for the future. One issue we would like to address is the “power problem”. It’s a bit odd for something like a pedometer to provide power to your Nexus S while it’s downloading today’s walking data. We’re investigating ways that we could have the USB Host provide just the bus mastering capabilities, but not power. Storing and listening to music on a phone seems like a popular thing to do so naturally we’d like to support audio over USB. Finally, figuring out a way for phones to support common input devices would allow for users to be more productive. All of these features are exciting and we hope will be supported by a future version of Android.

Accessory mode opens up Android to a world of new possibilities filled with lots of new friends to talk to. We can’t wait to see what people come up with. The docs and samples are online; have at it!

[Android/USB graphic by Roman Nurik.]

URL: http://android-developers.blogspot.com/2011/05/bright-idea-android-open-accessories.html

Thursday, May 19, 2011

[Gd] ChromeVox: Built-In Spoken Feedback For Chrome OS

| More

Chromium Blog: ChromeVox: Built-In Spoken Feedback For Chrome OS

Cross posted at the Google Code blog

We recently unveiled ChromeVox — a built-in screen reader for Chrome OS — during Google I/O 2011. This is an early developer beta that is designed to help authors of web applications come up to speed with platform accessibility on Chrome OS.

ChromeVox is built as a Chrome extension — this means that unlike most accessibility software, it is built using only web technologies like HTML5, CSS and Javascript. As the built-in accessibility solution for Chrome OS, it can help users with special needs access modern web apps, including those that utilize W3C ARIA (Access to Rich Internet Applications) to provide a rich, desktop-like experience.

ChromeVox leverages two of Chrome's experimental extension APIs, the experimental.tts API for cross-platform text-to-speech, and the experimental.accessibility API that lets an extension listen for accessibility events in Chrome's menus and toolbars. In turn, ChromeVox exposes a simple screen reader API to web developers who wish to further customize the ChromeVox user experience. Thus, within your application, you can:
  • Automatically generate spoken messages and earcons.
  • Set ChromeVox to synchronize with your application's current focus.
ChromeVox also comes with an interactive online tutorial that demonstrates how users of spoken feedback interact with webpages. Examples range from static content to interactive applications. You can test these same navigation techniques within your own applications to quickly verify users can reach all portions of your application using the keyboard and obtain meaningful feedback. You can then annotate your application with the necessary ARIA properties and other accessibility enhancements to ensure that blind and visually impaired users gain complete access to your application. Please see our Google I/O 2011 talk for more.

Details on enabling accessibility in Chrome OS can be found on the Accessibility help page, and the Chrome extension is available for download from our Wiki page. For now, ChromeVox is targeted at end-users on Chrome OS, but it may also prove a useful tool to web developers using Chrome on all major platforms. We welcome your feedback via our Open Source project website at http://google-axs-chrome.googlecode.com.

Posted by T.V. Raman, Research Scientist
URL: http://blog.chromium.org/2011/05/chromevox-built-in-spoken-feedback-for.html

[Gd] SSL FalseStart Performance Results

| More

Chromium Blog: SSL FalseStart Performance Results

Last year, Google’s Adam Langley, Nagendra Modadugu, and Bodo Moeller proposed SSL False Start, a client-side only change to reduce one round-trip from the SSL handshake.

We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times. SSL False Start reduces the latency of a SSL handshake by 30%1. That is a big number. And reducing the cost of a SSL handshake is critical as more and more content providers move to SSL.

Our biggest concern with implementing SSL False Start was backward compatibility. Although nothing in the SSL specification (also known as TLS) explicitly prohibits FalseStart, there was no easy way to know whether it would work with all sites. Speed is great, but if it breaks user experience for even a small fraction of users, the optimization is non-deployable.

To answer this question, we compiled a list of all known https websites from the Google index, and tested SSL FalseStart with all of them. The result of that test was encouraging: 94.6% succeeded, 5% timed out, and 0.4% failed. The sites that timed out were verified to be sites that are no longer running, so we could ignore them.

To investigate the failing sites, we implemented a more robust check to understand how the failures occurred. We disregarded those sites that failed due to certificate failures or problems unrelated to FalseStart. Finally, we discovered that the sites which didn’t support FalseStart were using only a handful of SSL vendors. We reported the problem to the vendors, and most have fixed it already, while the others have fixes in progress. The result is that today, we have a manageable, small list of domains where SSL FalseStart doesn’t work, and we’ve added them to a list within Chrome where we simply won’t use FalseStart. This list is public and posted in the chromium source code. We are actively working to shrink the list and ultimately remove it.

All of this represents a tremendous amount of work with a material gain for Chrome SSL users. We hope that the data will be confirmed by other browser vendors and adopted more widely.



1Measured as the time between the initial TCP SYN packet and the end of the TLS handshake.

Posted by Mike Belshe, Software Engineer
URL: http://blog.chromium.org/2011/05/ssl-falsestart-performance-results.html

[Gd] ChromeVox: built-in spoken feedback for Chrome OS

| More

The official Google Code blog: ChromeVox: built-in spoken feedback for Chrome OS


By T.V. Raman, Research Scientist

We recently unveiled ChromeVox — a built-in screen reader for Chrome OS — during Google I/O 2011. This is an early developer beta that is designed to help authors of web applications come up to speed with platform accessibility on Chrome OS.

ChromeVox is built as a Chrome extension. This means that unlike most accessibility software, it is built using only web technologies like HTML5, CSS and Javascript. As the built-in accessibility solution for Chrome OS, it can help users with special needs access modern web apps, including those that utilize W3C ARIA (Access to Rich Internet Applications) to provide a rich, desktop-like experience.

ChromeVox leverages two of Chrome's experimental extension APIs, the experimental.tts API for cross-platform text-to-speech, and the experimental.accessibility API that lets an extension listen for accessibility events in Chrome's menus and toolbars. In turn, ChromeVox exposes a simple screen reader API to web developers who want to further customize the ChromeVox user experience. Thus, within your application, you can:
  • Automatically generate spoken messages and earcons.
  • Set ChromeVox to synchronize with your application's current focus.
ChromeVox also comes with an interactive online tutorial that demonstrates how users of spoken feedback interact with webpages. Examples range from static content to interactive applications. You can test these same navigation techniques within your own applications to quickly verify users can reach all portions of your application using the keyboard and obtain meaningful feedback. You can then annotate your application with the necessary ARIA properties and other accessibility enhancements to ensure that blind and visually impaired users gain complete access to your application. Please see our Google I/O 2011 talk for more.

Details on enabling accessibility in Chrome OS can be found on the Accessibility help page, and the Chrome extension is available for download from our Wiki page. For now, ChromeVox is targeted at end-users on Chrome OS, but it may also prove a useful tool to web developers using Chrome on all major platforms. We welcome your feedback via our Open Source project website at http://google-axs-chrome.googlecode.com.


T. V. Raman is a research scientist at Google. He leads a team of engineers building innovative user interfaces on Android and Chrome OS, and researches creating highly efficient eyes-free interfaces.

Posted by Scott Knaster, Editor
URL: http://googlecode.blogspot.com/2011/05/chromevox-built-in-spoken-feedback-for.html

Wednesday, May 18, 2011

[Gd] Vaadin 6.6 Ships with GWT 2.3

| More

Google Web Toolkit Blog: Vaadin 6.6 Ships with GWT 2.3

Guest blog post by Sami Ekblad, Vaadin.com.





Accompanying the GWT 2.3 release, Vaadin is happy to announce version 6.6 of the Vaadin Framework. Vaadin is a server-side UI component framework that uses GWT on the client-side for rich user experience. With origins in Finland (a "vaadin" is a reindeer), there is now a very active Vaadin community world-wide. The framework has become especially popular during the last two years, with nearly twenty thousand downloads monthly.


Vaadin UI components are similar to GWT widgets, but their state is stored at the server. Every component has a client-side peer widget responsible for the presentation, and the synchronization between the server and the browser is automatically handled by the framework.


This makes development with Vaadin fast. It is mainly used to develop business web applications where pure client-side web application development is not a feasible option, but the web browser as a platform provides unparalleled benefits. One can think of Vaadin as a simplified Swing for web applications.


Touch support and Eclipse plug-in


Vaadin 6.6 follows the latest trends in web application development and adds touch device support. With GWT's new touch features, we were able to touch-enable all Vaadin components. Touch scrolling, selections, and drag and drop work out-of-the-box. Also thanks to GWT, we were able to add official support for Internet Explorer 9, which has been requested a few times already.


In addition to the new framework version there is a new version of the Vaadin plug-in for Eclipse available. The main addition is the visual editor for Vaadin that has now been included by default. With that you can visually design the user interface and then just continue editing the generated Java code to add some logic.


Summary


Over the years, we have seen the development team behind GWT doing an excellent job adding new functionality while keeping the framework as a solid platform for our development.


Today we are also actively contributing new widgets to the GWT community. You can find some of them hosted at Google Code and also available in the Vaadin Add-on Directory. Take a look at the GWT Graphics, SparkLines and SimpleGesture for some interesting examples.


Vaadin 6.6 is a big thing for us and to celebrate it, we decided to release it at Google I/O 2011. Find out more and download at vaadin.com.

URL: http://googlewebtoolkit.blogspot.com/2011/05/vaadin-66-ships-with-gwt-23.html

[Gd] Impact of new optional-login accounts on the AdWords API

| More

AdWords API Blog: Impact of new optional-login accounts on the AdWords API

We recently changed the workflow for creating a new client account within an MCC. Until now, all new accounts were required to have a unique email address and password from the onset, but going forward that step will be optional. For AdWords users that rely on an MCC account to access their clients, this provides a more secure, scalable experience. However, API developers will need to consider how this impacts the way they access and manage accounts in their custom applications.

All AdWords accounts will continue to have a unique numerical customer ID, as well as a “descriptive name” field. Any account that already has a login email will continue to function normally, and you can invite a new unique login email to any account (regardless of how it was created) if necessary.

Here are some ways that your API application might rely on login emails:
  • If you use login emails as unique identifiers in your database or UI
  • If you use the <clientEmail> header instead of the <clientCustomerId> header
  • If you request Auth tokens at the client level as opposed to the MCC level
  • If you filter calls to the InfoService by login email; it does not yet support filtering by customer ID
  • If you use v13’s AccountService.getClientAccounts() call, which returns an array of login emails, you should explore switching to v201101’s ServicedAccountService.get() call, which includes the customer ID in the return value.
In short, the safest thing is to make sure your application does not assume the existence of a login email for any client accounts that you manage via MCC. For more information on optional-login accounts, visit the AdWords Help Center on this topic.

-Aaron Karp, AdWords API Team
URL: http://adwordsapi.blogspot.com/2011/05/impact-of-new-optional-login-accounts.html

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 13.0.767.1 for Windows, Mac, Linux and ChromeFrame

All
  • Print preview work continues
  • Omnibox string matching improvements
Linux
  • We are discontinuing support for Ubuntu Hardy for 13.0, in effect matching that Ubuntu has officially stopped supporting Hardy (including stopping security updates) as of May 12th, 2011.
More details about additional changes are available in the svn log of all revision.

You can find out about getting on the Dev channel here: http://dev.chromium.org/getting-involved/dev-channel.

If you find new issues, please let us know by filing a bug at http://code.google.com/p/chromium/issues/entry

Anthony Laforge
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/05/dev-channel-update_17.html

Monday, May 16, 2011

[Gd] Chrome OS Beta Channel Update

| More

Google Chrome Releases: Chrome OS Beta Channel Update

The Chrome OS Beta channel has been updated to R12 release 0.12.433.38 including Chrome 12 Beta, new trackpad, new flash player and several stability and functional improvements over the previous release.

This release contains the following security fixes:
  • Disallow root escalation by creating /var/lib/chromeos-aliases.conf and inserting commands. [Credit to Chrome OS Team (Sean Paul)]

  • Disallow modification of about:flags in Guest mode [Credit to Chrome OS Security Team (Jim Hebert)]

  • Multiple package updates (openssl, dbugs, pango, sudo, strongswan, acl, libxml2, dhcpd) [Credit to Chrome OS Security Team]


In addition to all Chrome 12 new features (see Chrome 12 blogpost), there are several Chrome OS great improvements including:
  • File browser
  • Shiny new look
  • Improvements to GSM support
  • Verizon activation improvements
  • New Flash player
  • Feedback link is now under the wrench menu ("Report an issue")
  • 3G connection to the carrier fixes
  • Wi-Fi connectivity/Out of the Box fixes
  • New trackpad and sensitivity setting adjusted
  • Auto update engine and debugging improvements
  • Power optimizations
  • GTalk video/chat optimizations
  • Improved on screen indicators: brightness, network status, update icon

Known issues:
  • [Bug 15211] Angry Birds displays black screen in SD and HD version during intro video
  • [Bug 14592] 3g Activation does not complete first try but succeeds on second after a workaround
  • [Bug 13269] Chat window refuses to open, even if contacts list will
  • [Bug 12671] Encountered the recovery screen upon resuming from suspend (hard reboot helps)
  • [Bug 15085] "He's Dead Jim" message while playing specific video in 720p

You can find a full list of fixes in ChromeOS R12 in the chromium-os bug tracker. If you find new issues, please let us know by visiting our help site or filing a bug.

Orit Mazor
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/05/chrome-os-beta-channel-update_16.html