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

Seo Master present to you: 2013, By: Seo Master

Seo Master present to you: By Nir Bar-Lev, Product Manager

When we launched the Visualization API we wondered, which new visualization types will the developers out there come up with? Which one will be successful? Will we quickly see the long tail of visualizations being developed?

Visualizations, as with many other things, follow a rule we know very well at Google: Their distribution is such that there are a few visualizations at the 'head', which get the majority of usages, and then there is a long tail of special visualizations, that by virtue of their subject matter or type, get little overall use.

Take for example the ubiquitous line chart vs the radar chart:




Line charts are extremely useful in visualizing continuous changes over time or other factors, and as such are used for data sets ranging from displaying financial results, to the growth of germs on petry-dishes to following presidential candidates' accumulation of votes. You'll find line charts in almost every type of presentation, even in cartoons:



On the other hand, radar charts are relatively rare and most people have never encountered one, unless they happened to have taken an advanced university course in Marketing, for example.

Obviously there are highly specialized visualizations that are extremely common. For example, the 2-hands clock view, is one of the most wide-spread used visualization to display time. Yet, many visualizations have been developed for specific use in specialized fields of study, or work.

As such, you can imagine we had a fun time betting on which visualization will come out and which will catch on. Some of the bets in the team were made on us first seeing specialized visualizations. Perhaps a network diagram. Others, had bet on seeing new, high end, pivoting and data drill-down, slice-and-dice wizardry. Who won? Apparently we all lost our bets.

It seems the common straightforward visualizations can be reinvented with a just few simple changes to make them immensely powerful - and fun - as visual tools. Enter, the Bar (or Column) Chart and the Piles of Money visualization:





By altering the standard visual design of the bars (or columns) as wide lines, or rectangles and simply converting them to an image of a growing pile of money, the Piles of Money chart has rocketed to the top five most popular visualizations used over the Visualization API. This simple change can provide the same insight as any bar chart, yet when used on data sets related to cost, revenue or any other financial measurement, it becomes a fun, engaging chart, not derogating in any way from its original purpose and actually adding additional emphasis that the subject matter is money.

The Bars of Stuff chart was added just after Piles of Money, and provides the same treatment to the horizontal bar chart as Piles of Money did to the vertical bar chart. Users can choose on of several cool visual designs, like chocolate, cute worms, etc to be used instead of the bars.

I can't wait to see someone take the idea behind Piles of Money and advance it to the next step: create a visualization in which the user can visualize bars of anything they want by choosing the image to be integrated into the visualization: Piles of Boxes, Piles of Shoes, Bars of Soap.

To see all of the Visualization API's current list of visualizations by Google and the community, check out our gallery.2013, By: Seo Master

Seo Master present to you: On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow up blog posts. Over the last few weeks we've talked about how to use the AppCache functionality of HTML5 to launch an application offline. We discussed the impact that AppCache can have on your mobile web applications, as you enable users to launch your app faster in the face of flaky or slow internet connections. This week, I'll talk about how we're using both HTML5 Structured Storage and the Google Gears Database to make devices tolerate flaky network connections.



Although these technologies allow web applications to cache user data on the mobile device and perform data modifications locally, HTML5 Structured Storage uses an asynchronous model, where the Google Gears Database uses a synchronous model. This difference makes it difficult to develop an application on top of both platforms. We dealt with this problem by creating the Web Storage Portability Layer (WSPL) for Gmail. Coming soon under a liberal open source license to code.google.com/p/webstorageportabilitylayer, WSPL provides a common API that supports an identical asynchronous programming model for both platforms by using a worker thread in Gears. Let's take a look!

The WSPL consists of a collection of classes that provide asynchronous transactional access to both Gears and HTML5 databases. It can be used to execute nested statements within callbacks, create statement templates, and optionally control the synchronous/asynchronous modes of the Gears Database Wrapper. There are five basic classes.

google.wspl.Statement - A parametrizable SQL statement class
google.wspl.Transaction - Used to execute one or more Statements with ACID properties
google.wspl.ResultSet - Arrays of JavaScript hash objects, where the hash key is the table column name
google.wspl.Database - A connection to the backing database, also provides transaction support
google.wspl.DatabaseFactory - Creates the appropriate HTML5 or Gears database implementation

Let's take a look at how we can use this API to perform a simple query, starting with the creation of a Database. Note that you'll need to provide a URL to the worker file hosted from your domain.

var database = google.wspl.DatabaseFactory.createDatabase('db name', 'http://yourdomain/dbworker.js');

You can then execute SQL statements without worrying about the specifics of HTML5 and Gears. Refer to the recent blog posts about AppCache to find steps you can follow to see your database contents using sqlite3.

var statement = google.wspl.Statement('SELECT col from test_table;');
database.createTransaction(function(tx) {
  tx.executeAll([statement], {onSuccess: function(tx, resultSet) {
    // Statement succeeded.

    for(; resultSet.isValidRow(); resultSet.next()) {
      window.console.info(resultSet.getRow()['col']);
    }
  }, onFailure: function(error) {
    // Statement failed.
  }}); 
}, {onSuccess: function() {
    // After transaction commits, before any other starts.
}, onFailure: function(error) {
    // After transaction fails, before any other starts.
}});

I've found that using the Gears database asynchronously will nicely split up the JavaScript execution, allowing event handlers and other code to execute between the callbacks. This can improve the responsiveness of your application if you're using long transactions. You can also use SQL triggers to avoid the read-modify-write pattern that causes "ping ponging" between threads -- either the main thread and Gears worker or the main thread and the HTML5 SQL thread.

That's all I'll show you for now, but you can look for more details about the Web Storage Portability Layer at Google I/O, May 27-28 in San Francisco where we'll be presenting a session on the architecture of a generic application using HTML5. We'll also be available at the Developer Sandbox and are looking forward to meeting you in person. Stay tuned for the next post where we'll talk about improving the performance of HTML5-based web applications.

By Matthew Bolohan, Software Engineer, Google Mobile2013, By: Seo Master