19 June 2013

An Analysis for Transition from Spreadsheets to Fusion Tables, part 2

This is part of a multipart post taken from my essay entitled "An Analysis for Transition from Spreadsheets to Fusion Tables". It may sound boring, but a questioning reader may find it rather useful to understand the value of Google Sheets and Google Fusion Tables in the workplace and readers may also find additional ideas for improving their usage of either product.

The Promises of Fusion

Some number of months ago, Google released a new product, Fusion Tables, to the public. While Fusion Tables are designed to handle large amount of data, they present a compelling opportunity for evolution to the Ecosystem. Such progression, however, does not come without some sacrifice.

Fusion Tables represent a return to the database format we had originally abandoned when creating the Ecosystem, but with some twists. With an eager excitement I began a new project called “Fusion system”, a functional prototype of our Company data spreadsheet converted to a set of Fusion Tables, to test out the potential of this new system. Adoption of Fusion system would not mean throwing out all of our spreadsheets, just converting our largest, most complicated spreadsheet into a Fusion Table. The rest of the Ecosystem would remain the same.

Custom Data Combination

One of the biggest benefits of the Fusion Tables is the ability to easily combine data across different tables without having to permanently combine the data. In fact, temporary “joins” as they are called in database jargon, are part of the Fusion Table backbone. It allows for almost endless, non-destructive data merging. This, in conjunction with what we smart data propagation, makes it advantageous to segregate data into logical groupings rather than a large conglomerate as we did with Company data because relevant data can be pulled and combined whenever desired for an enhanced view and, unlike importRange, this is accomplished more reliably.

Data Propagation

Data, no matter where it was originally stored, where it ends up being presented or with what other data it ends up being merged, always remains editable. More importantly, changes to data—again, without regard to where and what—are propagated throughout all iterations of the data so that wherever the data is presented, it is always the newest revision.

This ability for universal editing means that there would be no reservation in creating customized data sets because there would be no break in the data being viewed. In theory, each user could have a set of tables that have been tailored for efficiency in their specific task. This is vast improvement over our current spreadsheet that enable one-way transmission of data (they can read data from other sheets but cannot push edits back).

Record Editing

Fusion Tables have a built in record editing mechanism that we have not been able to mimic with satisfactory reliability in the Company data. Moreover, this edit mechanism adapts to the columns presented in the current view of the data. That is, users are always presented with an editing screen that matches the current table.

This improved presentation of editing help to ensure that data is only intentionally edited as the editing mode must be expressly entered (instead of simply typing over existing data) and prevents users from unknowingly switching their editing to a different row.

Filtering

Fusion Tables presents a simplified data filtration system that makes it easier to restrict the current data view based on any number of criteria. While the Fusion Table filtering is not as robust as that found in Sheets, it is more suitable for our purposes.

Custom Presentations

While Fusion Tables focuses on managing large data sets, it is also built to present the data with great flexibility. To this end, the system has a built in ability to present the data in many different ways including rows and cards. Rows are essentially echoes of the original table but cards allow for an almost endless customization of the data presentation. Using simplified HTML tags for the layout, cards permit users to quickly build templates for how the data will be presented. The presentation engine is not the most feature rich; still it enables basic reporting on a level that is extremely difficult within a spreadsheet all with ease.

Limited Views

Views, as they are called in Fusion Tables, are custom built representations of data sets. They can be crafted from a single table or several tables, they can include custom filters or present full data sets. Of most interest, however, is that once a View has been created and shared it is locked in. That is, the filters and tables connected to the View cannot be altered. All of the previously mentioned features are still available: the View will always show the most recent data and, if editing is allowed, will pass data edits back to the original data set. This is particularly useful in solving the problem of presenting each client with the most current data while not having to manage separate data stores and, at the same time, keeping other clients’ data protected.

An additional use of Views is in considering parent/child relationships. For example, some clients need access to information from several other clients by way of leasing agreement but the leasing clients should not have access to other leasing client data. Using Fusion Tables we can provide a View for the Lessor client that includes all the leasing client while providing individual leasing clients with Views of only their own data. This process would not require any additional data entries or any extra data updates. All data would be current and protected.

Improved Reporting

It would be wrong to say that Fusion Table will represent vastly improved external reporting (i.e. reports generated for email or print). Instead, reporting will go much the same as it has before, just run a little faster. Currently, entire data sets are reviewed in the process of finding the relevant information; scripts compare, line by line, data against a series of criterion. Fusion Tables uses an SQL like query methodology which means instead of importing a whole data set and then sifting through it to find the few relevant lines we can simply request the data that matching a given criterion and dispense with the sifting entirely.

No comments:

Post a Comment