In reading this book I had a grand realization: most of our misconceptions about which dinosaurs lived and ate which other dinosaurs is because we know dinosaurs better by the order they were discovered than the order in which they lived. For example, ankylosaurus and stegosaurus died off long before tyrannosaurus-rex started chomping stuff.
Interesting tidbit: A man was sent out to find a triceratop but came back with a t-rex. His sponsors were shocked and elated.
Gutman points out that smiling is ingrained in our biology and persons who smile frequently typically have better, longer lives. Go figure.
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.
While Fusion Tables promises much in the way of streamlining operations and improving managed data sharing, it is not without some drawbacks. Even when entering the Promised Land, some of the wonders of Egypt had to be left behind.
To start with, Fusion system would be a return to the database structure abandoned by Company data. While column changes would still be possible, they would be more difficult than currently supported (but still much easier the previously). Further, Views and data merges are non-additive. Once they have been completed columns can be removed but no new ones—or old ones, including one previously removed—can be added. To accomplish addition requires building a new merge or View (unless introducing a completely new data set). Because of this, it is likely to take several attempts to get the proper blend of data. Removing old attempts will invalidate links and bookmarks requiring them to be updated.
Those “feel good” social markers (namely the cell highlights) are completely absent from Fusion Tables. In fact, working on a Fusion Table is a bit like working in a black hole: there is no indication that any other user has a Fusion Table open let alone where they are working. The only indication that one is not working alone is if data changes after a browser refresh.
There is no real-time updating. All updates to a Fusion Table happen on refresh. This can increase the chances of overlapping work, duplicate data entry or functioning on old data.
Fusion Tables does not permit anything near the robust formulas of a spreadsheet. While they permit basic math and a few other limited functions, if/then and other comparative functions are limited at best but are frequently missing entirely. Useful features like links to clients folder based on online enrollment suddenly become impossible.
While it is possible, and even likely, that more powerful functions will be added as Fusion Tables continue to develop, they are not available now. The same is true for our conditional formatting. This shifts some of the analysis that Company data does automatically back to the user. Missing information will blend in with complete information, poor ratings will sit quietly beside good ones and words will go back to being just a number relying of the user to remember what the values mean. These issues can be migrated with concerted training but it is less elegant to have to track such drab details manually.
Perhaps one of the most glaringly absent features is an inability to print. None of the data sets, Views or reports can be printed. Instead, they are locked securely in their digital existence. The nearest ability to print them is to export them and print from the exportation.
Currently, Fusion Tables lacks the ability to be scripted with custom menus. This means that running custom scripts will no longer be as simple as going to the Scripts menu and telling it to run. In fairness, this will only effect two scripts that were tied directly to Company data directly and thus should not be considered a major concern.
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.
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.
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, 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).
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.
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.
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.
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.
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.