Why the Objectsheet?

The "large grid and scattered formulas" approach of the traditional spreadsheet makes it a useful tool for simple calculations. But as spreadsheet-based models grow and are refined, they become difficult to deal with. Ensuring that models are robust as they grow, working against a preponderance of dialog boxes and disjoint capabilities (e.g., cell naming, formatting, data checking) is tedious and often not done. As a result, spreadsheets quickly become fragile data repositories. Much has been written on the risks of complex spreadsheets. Other recent developments in spreadsheets address data centralization and collaboration, but have done little to improve robustness and usability of the "large grid".

The Objectsheet fixes these problems by dispensing of the idea of the single large grid of cells. Objectsheet Tables have a finite size, an underlying data structure based on objects, and use a "Template" to organize repeated formulas, formats, and other rules. These features eliminate many of the error-prone characteristics of spreadsheets and improve usability.

To illustrate the basics of the Objectsheet, below are a spreadsheet and the corresponding Objectsheet. Look at the spreadsheet on the left and see if you can determine what's going on. For the Objectsheet on the right, it's easy to figure out the logical flow and what is expected of you as the user of the model.

Traditional Spreadsheet		Objectsheet Table
Relationships between cells not apparent; formulas are scattered and hidden.	→	Rules (formula row) distinct from and can be made visible along with values: easy to tell logical flow
Not clear where formulas are and where you are supposed to enter data.	→	Automatic highlighting of directly entered formulas or values (white background) and rule-based values (gray background).
Formulas need to be replicated into each cell	→	Formulas apply to all rows; entered once
Data labels ("day", "hr", etc.) are just visual and not part of the data itself.	→	Easy to create meaningful names for cells and use them in formulas
Overriding an replicated formula with a manual value (e.g., $B$4) destroys the original formula	→	Proper default/override mechanism for cell formulas; e.g. if the manually entered value 10     in row 2 is erased, the orginal formula ("day*24") is restored.
Manipulating rows and columns in one part of a spreadsheet can damage other parts.	→	Sections of data are self-contained and naturally independent of each other.
Must keep track of absolute vs. relative cell references when creating and replicating formulas.	→	Correct referencing inherent in data structures; absolute vs. relative referencing is not needed.

The attributes on the left are common source of difficulty and error in traditional spreadsheets; these are avoided by using the Objectsheet. In addition, data validation, which is tedious to implement and of limited flexibility in spreadsheets, is straightforward and powerful with the Objectsheet.

From an ease-of-use standpoint, it would take twice the number of data/formula entry steps to provide the functionality and visual feedback of the Objectsheet. The Objectsheet handles the above features automatically, by convention; it is not dependent on the attention of the model developer.

For more information on how the Objectsheet implements the above features and examples, please see the overview and the tutorials. There are notes on other spreadsheet alternatives, like Google Spreadsheets and WikiCalc. There are also some notes on the limitations of the current Objectsheet implementation.