Objectsheet Overview

So What's Wrong With Spreadsheets?

It's easy to think that there are no real problems with spreadsheets -- we have become rather used to them over the past 20-plus years. The problems are indeed subtle. For simple situations, they're easily ignored. But as a model grows in complexity, spreadsheets get tedious, and at worst can lose their robustness and break easily. Some of the issues that contribute to this are:

• Cells use nonsemantic Cartesian names (A1, B2)
  Writing spreadsheet formulas requires a an explicit mental process to convert from a piece of information ("February's Sales Forecast") to a cell name ("J15"). This is not a serious problem in small spreadsheets, but in large ones with many cells, one often ends up "looking around" for the right cell number to enter. Cells can be given textual names, but this requires many special-purpose user interface elements (commands, dialog boxes) and resulting process steps. more...
• Moving things around in a spreadsheet risks damaging the logical model
  A spreadsheet's analytical structure is tangled up the with its visual representation. Changing the visual layout (moving cells, inserting rows or column in a table, etc.) of a spreadsheet risks damaging the logical structure of the model, as well as formatting details of the individual cells. This is especially true when multiple data structures inhabit a single worksheet. more...
• Macros are stored in a place and in a language separate from the spreadsheet itself
  Macros require both user interface context switching and language switching. For many, anything beyond trivial "recorded macros" are impossible because of the hurdle of learning a new language. more...
• It is cumbersome to distinguish user-entry cells from calculated cells
  In spreadsheets, it's often important to somehow highlight user-entry cells. But this special formatting is a manual operation, and generally not done consistently, often not even within a single spreadsheet.
  More importantly, spreadsheets are great for "what-iffing", but experimentation often results in typing explicit values into previously formula'd cells, and vice versa. This can easily screw up the clarity of the above formatting and the integrity of the sheet itself. more...
• Validation of cell values is very cumbersome in spreadsheets
  Subtle problems can creep in to spreadsheet models because of the other issues described here. Validation checks (on data type, numeric range, text pattern matching, etc.) can help catch these problems. Some type checking is automatically provided in spreadsheets, and there are some tools to do limited constraint checking. But this is cumbersome, requring either insertion of new cells or navigating yet another user interface (Data > Validation, in Excel 2000, which most users probably don't even know exist). This is inconvenient enough that it if ever done, it's only in reaction, after problems arise.
• Many components of spreadsheets exist in different user interface "modes" and are normally hidden from view
  • Formulas and analytical flow more...
  • Exceptions in data and formulas more...
  • Other "worksheets" in a single file more...
  • Cell "names" more...
  • Cell comments

Modern spreadsheets contain partial solutions to all these problems. But this has resulted in an enormous amount of application complexity (menu commands, UI modes, syntaxes, process steps) layered on top of an essentially unchanged 23-year old data structure. The Objectsheet replaces the Visicalc-based simple cell grid with a Javascript-based engine and data structure.

The purpose of the Objectsheet is simply to wrap a coherent visual environment around Javascript objects, while hiding much of the complexity of managing them.

Objectsheet Benefits

Objectsheets overcome many of the difficulties of spreadsheets by introducing the following features:

• Objectsheets have a Semantic Structure
  Each Objectsheet organizes a single table. Each table is comprised of objects (in rows or in columns) and properties (running orthogonal to objects). The result (see above) looks similar to a traditional spreadsheet). But Objectsheet column and row headings are editable to provide useful names, and these names con be used in formulas. This removes the semantic indirectness of the spreadsheet's A1-B2 approach. more...
• Objectsheets use formula "Rules" and "Exceptions"; there is no need for replicated formulas
  Formula and formatting "rules" live in a place called the Template-- the architecture of the Objectsheet enables its logic to be completely encapsulated there. This means that formulas, cell formatting, type and contstraint checks, etc. can be easily specified in one place and are automatically applied to relevant cells. But then, rules are meant to be broken; you can override any rule by entering formulas directly in target cells. more...
• Validation checks on cell values are easy and natural
  Constraint checks can be specified by simple formulas, and directly affect the formatting of the checked cell. The rules for these checks in an objectsheet are specified in one place (the Template's Style row). This makes it easier to enhance model robustness with constraint checks as a matter of course rather than of reaction. more...
• Objectsheets interact computationally, but are graphically independent
  Each Objectsheet organizes a single table. One file can contain multiple sheets (tables), whose calculations can interact, but which can be formatted and restructured independent of each other. Objectsheets are essentially immune to the structrual dependency issues of the spreadsheet.. more...
• The Objectsheet uses one syntax for formulas and macros
  The Objectsheet uses Javascript/ECMAScript for formulas, macros, and the underlying data structure. Formulas in Objectsheets use a function syntax similar to that of spreadsheets (so training for basic objectsheeting is minimal), but the underlying calculation engine for everything is Javascript. This removes all boundaries between formulas and traditional spreadsheet macros. more...
• The Objectsheets requires fewer user interface "modes" than spreadsheets
  • Formulas can be viewed along with the data they generate
  • "Manual Entry" cells are automatically distinguished from calculated cells and "manual overrides" to formulas are automatically highlighted
  • All "sheets" in a file exist in a single window and can be manipulated as individual graphical "objects"
  • Formulas can use in-line commenting
  • The Objectsheet's macro input area (or "script area") is visually part of the Objectsheet itself, but can be shown and hidden.

These few differences enhance the usability of the Objectsheet and go a long way to reducing common sources of "spreadsheeting errors". There are many other aspects of Objectsheets that allow them to retain (and sometimes surpass) the simplicity of the traditional spreadsheet, while providing huge benefits for more complex models.

The Objectsheet uses a slightly more sophisticated data architecture than the traditional spreadsheet, but results in a much simpler and more powerful application architecture.

Where To Go

There is a working proof of concept Objectsheet application that you can play with. It is less than 100 KB in size; and does not install as an application, but loads like a web page. If you would like to dive into that, I urge you to use the tutorial as your introduction. There is also a more detailed application reference.

For a more thorough overview of the Objectsheet, please check out the white paper. For even more, you can check out my technical notebook.

R. Knopman, © 2001