Also see: Overview,
An Example, Detailed Trades, References
The spreadsheet is an extremely versatile tool; it have been a fundamental means of computer-based analysis since its invention in 1978 by Dan Bricklin. Spreadsheets provide a simple, coherent interface for analytical problem solving in a free form environment. They allow mixing of text, numbers, and formulas in arbitrary spatial arrangements, limited only by the will of the user. A set of formulaic relationships on a grid of cells, the foundation of the spreadsheet's structure, is applicable to a wide range of problems. It is important to consider the advantages of spreadsheets:
Unfortunately, spreadsheets have several inherent disadvantages, as anyone who has had to use or maintain a substantial spreadsheet will attest. As a given problem grows in complexity, the simple spreadsheet model become cumbersome and limiting. The Spreadsheet structure has the following disadvantages:
Basically, all spreadsheet
references use a row-column representation, like A1,
B2, etc. This forces the user to constantly
translate between the semantic ("Q3 Sales Subtotal"),
and the spatial ("cell C13") when crafting
formulas.
While it is possible to create named aliases for spreadsheet cells and cell groups, this is an inconvenient process. Even if one has gone through the trouble to create such aliases, there results no direct, visual cues on the sheet itself. Unless the cell alias has been memorized, one must resort to popping up a list of aliases to find the right one.
A spreadsheet's analytical structure is tangled up the with its visual representation. While this modeless environment is a strength of spreadsheets, it is still the case that changing the visual layout risks damaging the logical structure of the model, as well as formatting details of the individual cells. For instance, removing values from a table often leaves holes in the referencing scheme.
As an additional example, many spreadsheets are built around the notion of a table, with columns of parametrized variables along with scalar, single-celled variables. In what-if analyses though, we often need to parameterize a constant, moving a single celled value into its own column. This requires restructuring the spreadsheet (formula replication and changing reference types in those formulas). Often, significant time is spent in this re-layout step, and is an error-prone process.
Macros must be stored in a place separate from the spreadsheet, detracting from the otherwise modeless nature of spreadsheeting. This also contributes the the difficulty in understanding a spreadsheet, since significant portions of a spreadsheet's logic may be bound up in macros and hidden from view.
Distinct macro language entities are necessary to provide traditional named data structures (variables), as well as basic flow control constructs. This increases the knowldge required to instill a spreadsheet with such procedural behavior.
For use by another, or for later reference to the author, it is generally desirable to distinguish cells that have formulas from those that expect explicit values. In traditional spreadsheets, cells destined for manual entry can be given a particular format like a distinct text color, background shade or cell border. Unfortunately, this special formatting is a manual operation. It is also time-consuming and inconvenient, and not often done per rule, but per whim of the author, so designations can change from one spreadsheet to another.
Hidden Parts In addition, important aspects of the spreadsheet model are hidden from view, detracting from robustness and understandability:
A spreadsheet user can view a single formula at a time in the formula bar, or can show all formulas at the expense of hiding the resulting data. Unfortunately, spreadsheets are generally laid out for visual presentation and not for semantic flow, making the logical structure difficult to follow. For more complex spreadsheets, this (as well as inconvenient commenting) leads to difficulty in understanding how a given spreadsheet works, either by another user, or even by the spreadsheet's creator, after a time.
It is also difficult to track exceptions to a group of otherwise identical formulas. Exceptions are inherently inconspicuous in a spreadsheet. There is no way to indicate these, except by explicit, manual notation by the user. This can lead to subtle errors, not easy to troubleshoot.
Multiple sheets in a workbook are frozen in a "Card" (one sheet at a time) layout, selectable by worksheet "tabs". Viewing multiple sheets simultaneously is cumbersome and they can only be printed individually. Single spreadsheets often contain multiple logical structures (tables, constants, and the like), and sheet-level formatting (row and column widths, hiding, etc.) can have adverse effects across all those structures.
Entering named references into formulas requires the user to either remember the needed name or to switch modes to a separate dialog box and locate it. There is overhead not only in declaring a cell name, but in using it. Named references are therefore inconvenient in a spreadsheet.
The fundamental spreadsheet structure has not changed since its inception. Progress in spreadsheet programs over the past 20 years has essentially been to embellish the basic model; these improvements have provided some, but not significant, alleviation of the issues described above. (The references point to similar observations of others). The result is that the fundamental spreadsheet structure has become an inefficient (and arguably ineffective) means to reflect much complexity in a given problem space.
Some of the problems of a complex spreadsheet can be alleviated by graduating the problem to a formal programmed solution. Programmed implementations, with databases as storage mechanism can be seen as a complement to the simpler, more interactive, spreadsheet. At the expense of a more formal, expensive, and time consuming developmental process, programmed solutions are often better structured and can be (theoretically, at least) made more robust, via strong type checking, better data integrity enforcement, and a more thorough design process. Object oriented structures are particularly intuitive means of structuring a problem and providing a reasonably robust solution. Object-oriented techniques can further improve the quality of a programmed solution through more intuitive logical structuring, simplified logical interfaces, and more efficient component reuse, when compared to older techniques.
Unfortunately, the programmed approach, is for many problems, not feasible because of high cost, development time, and the difficulties inherent in translating the problem to an "IT professional". Furthermore, the applications that result have little flexibility, its rules having been "hard coded". The cost of maintenance is therefore also high.
As a solution develops in spreadsheet form, there is often high resistance to abandon the quick, free form, but limited spreadsheet model to programmed solution. As noted in the references, this leads to high spreadsheet maintenance costs, a great risk of spreadsheet error and expense to fix, or if left undetected, potentially hazardous errors in business operations.
As the spreadsheet indeed provides a valuable combination of free flowing development and simple interface, so can its essential elements be applied to an object-oriented problem solving environment. If this is achievable, the advantages of spreadsheets and object oriented problem solving can be merged, then we can enable object-oriented analysis and solution of many problems without requiring a programmed implementation.
We need not limit the object-oriented solution domain to the procedural or programmed, and we need not limit the spreadsheet model to the Cartesian. We seek the best of both worlds, an interactive, free-form environment that allows solutions to be structured in an object-oriented context.
We propose a interpreted, loosely-typed, object oriented environment for representing analytical and structures and behaviors in a visual context. Entire classes and individual objects are created and manipulated on the fly, with direct visual feedback. Objects and their properties are created and filled in with either literal data or by formula, all interactively, flowing from a user's thought process. Entered or calculated results can be based on literals, formulas, or procedures (methods). Data are inherently referenced by semantic name, providing directly and easily understood formulas. A persistance (file storage) mechanism is also provided with XML-compliance, enabling easy access to a model's data structure and results from other applications.
It is understood that an object model is a much more sophisticated construct than a matrix of cells in a spreadsheet. The critical challenge is to acheive the simplicity of the spreadsheet while implementing the power of the object model.
The fundamental package around which all aspects of the object model will be captured is the Objectsheet. It is also the primary element of the user interface, and contains both class-level definitions (i.e. property and method definitions) as well as actual data embodied in the associated instances (i.e. its objects).
A simple Objectsheet is shown below. Visually, it looks very much like a spreadsheet. The Objectsheet is composed of a rectangular grid of cells, each cell holding a unit of information. Like spreadsheets, Objectsheets allow mixing of entites of different types (although there is a provision for type-checking), and allow formulaic relationships between the cells within it. In fact, Objectsheets can be made to behave almost exactly like traditional spreadsheets. As with a spreadsheet, interactions with Objectsheet occur within a single operating mode. Still, there are subtle, yet critical, differences in the structure of the Objectsheet that set it apart from the spreadsheet. These differences are outlined here, and expanded on in the following section.
A Sample Objectsheet
The basic premise that is the foundation of the Objectsheet is to impart a small amount of semantic structure to a grid of cells. The row and column headings in an Objectsheet can be given names, and therefore meaning, to the user. Those names give visual cues (as any table column and row headings), but also are the logical references to the information contained within. While such row and column labeling is easy, it is not required. Provisions are made for manipulating and referencing between Objectsheets, each with its own meaning and structure. Provisions are also made for constants and globally-accessible variables.
Pieces of data are referred to by their named row/column headings, with one direction (rows, typically) corresponding to individual objects and the other (columns, typically) corresponding to individual properties. The information within the Objectsheet is referenced by those names (or indices, if no names are explicitly given). The Objectsheet structure maintains those semantics, whether a reference is absolute or relative.
Formulas exist primarily in an area of the Objectsheet called the Template. Formulas in the Template are entered once and automatically apply to all contained objects; they are the "Rules" (read: class definitions) under which an Objectsheets values are calculated. The template can also be made visible along with the individual objects. Exceptions to those "rules" are captured by placing a formula directly in a object's cell.
Rules are also specified for other cell attributes, like cell number formatting and display style. These different types of rules each inhabit their own row of the Template. For instance, all the "display style rules" for an objectsheet sit in a single row. One can therefore create and change the style rules of the entire objectsheet just by progressing along this row. This feature is important when specifying cell value constraint checks-- as the process for doing so is much more convenient than for a spreadsheet (making it more probable that you will specify these checks and make the Objectsheet safer in the process).
Objectsheets are graphically independent of each other, and can each follow distinct layout (formatting, sizing, coloring), or be assigned to a generic style. Objectsheets can be grouped and manipulated as a single unit; individual Objectsheets may also be split and the parts separately manipulated to improve readability.
These few characteristics go a long way towards eliminating the traditional difficulties with spreadsheets. In the discussion that follows, we go into more detail about these and other attributes of the Objectsheet. We will show that we have a) all but eliminated nonsematic cell references, b) made much of what is hidden and scattered with traditional spreadsheets more organizable, coherent, consistent, and apparent, and c) have separated visual formatting from the logical structure, while retaining the modelessness of traditional spreadsheets.
First and foremost, Objectsheets have a semantic structure. The Objectsheet dispenses with reliance on the bare Cartesian referencing of the traditional spreadsheet; while cells are arranged in "rows" and "columns" visually, they are not referenced as such. In the Objectsheet entries in columns represent "properties", and entries in rows "objects". (In this White Paper, consider rows synonymous with objects and columns with properties. In general, Objectsheets are transposable, placing objects in "columns" and properties in "rows".).
In the Rooms Objectsheet below, the names of objects (MasterBedroom, MasterBath, etc.) and
the names of properties (Length,
Width, and Area) are entered by
the user, and form both logical and visual labels. (Spaces and
some punctuation are allowed for these labels; we have avoided
using them in this introduction. Also, manually entered row and
column names are not strictly required ("unnamed"
objects and properties); we will discuss that case in the next
section).
With this structure comes an inherently simple, associative
means to reference cells. Within an Objectsheet, we can directly
reference any piece of data using the syntax of Object-dot-Property.
Within the above Objectsheet for instance, MasterBedroom is a
single object. It, and all the other objects (rows) on the
Objectsheet have the three properties: Length, Width, and Area. The width of the
MasterBedroom is
referenced simply as MasterBedroom.Width,
while referencing it from another Objectsheet is done by
prefixing the Objectsheet name, i.e. Rooms.MasterBedroom.Width.
This is much more descriptive than using a nonsemantic Cartesian
reference (like "B2")
and is more visually direct (and efficient) than assigning names
to each cell manually. Unnamed objects and properties are
considered in the next section.
As individual objects or entire properties are added and moved, this associative referencing remains intact. If an object or property name is changed, all formulas that refer to that object or property are changed to reflect the new name.
Absolute references between cells are sometimes not useful or even possible. Relative references are needed when: a) we want to have a formula to reflect relative changes between objects, or b) explicit object names are meaningless or inconvenient. Unnamed references are enabled by certain reserved object and property names to allow easy access within an objectsheet without explicit labels. This will make the Objectsheet as easy to use as a traditional spreadsheet even for simple, casual calculations.
First, the a special array called "object[]"
can be used as a reference to the array of objects in a
particular Objectsheet, allowing addressing of objects by numeric
index (row number). In the Rooms
Objectsheet above, object[1] refers to the MasterBedroom object (assuming
one-based row indexing [see the Note
on array bases]), object[2]to the MasterBath object, etc.
Another means of referencing is associative, allowing indirect
addressing of objects. Individual objects are elements of the
sheet's base object (called ob). As an example with
the Rooms Objectsheet, Rooms[7], ob["Kitchen"] and object[7]
are all equivalent references to the Kitchen
object from within the Rooms Objectsheet.
Another entity provides for relative addressing. this is a reserved
object array with index indicating a row offset instead
of an absolute row number. For instance, this[-1] refers to the
object in the row immediately above, and this[offset] refers to
the object offset
rows down. As a great majority of relative references are in a
single direction and only refer to the very previous row or
column, another reserved object, prev,
is provided to refer to "the object immediately before this
one". There is more discussion
of the referencing scheme in the Notes.
Finally the prop[] and propIndex[] arrays are
provided to allow relative referencing between properties. While
relative property references is not discussed here in detail, we
provide an example of such a reference. this[propIndex[-1].name]
refers to the value of the property immediately to the left of
that in the cell currently being evaluated. Relative referencing
of properties should have only limited use in Objectsheets as we
envision properties to nearly always be named and absolute, even
when the objects themselves are not.
The basic Objectsheet referencing scheme is independent of Cartesian space. Moving, transposing, grouping, or otherwise changing the view or layout of an Objectsheet has no effect on referencing or logical layout. Furthermore, since the majority of the rules governing the Objectsheet are defined in the Template (described below), the overall layout and behavior is generally unaffected by the action of adding, deleting, or moving objects and properties. Contrast this with the traditional spreadsheet where cell borders, background and foreground colors, and the like, are not always consistently retained after cell/row/column manipulation. While the Objectsheet's analytical model and graphical layout inhabit the same, modeless interface, they are behaviorally independent of each other.
Since we have introduced a coherent structure to the cells within an Objectsheet, we can introduce formulaic (or procedural) rules that apply to the given property of all objects. These rules are specified only once on the Objectsheet and automatically apply to all its objects.
These rules are found in a portion of the Objectsheet called the Template. The Template is a new construct and is a basic component of the Objectsheet (it is indicated in the figure below). We distinguish the Template section, with shaded background in this and the following Figures from the instance section, with no shading. The Template contains metainformation, describing the attributes of all objects in the Objectsheet and other, sheet-level, information.
For instance, the formula row in the Template contains a cell for each property in the Objectsheet. If one of these cells is filled with a (Javascript) formula, each value down that column will be automatically calculated for each object. Other rows in the Template describe how a property entries are to be formatted, protected, etc.
Objectsheet Template and Instance Sections
With rules come exceptions. Rules cause cells in the instance
section to be filled in automatically. Exceptions occur either
when we wish to override a given rule, or when rules don't apply
(for instance, in the Rooms
Objectsheet above, the Name,
Length, and Width properties are
be entered by hand). Overriding a cell's value is accomplished
simply by entering a value directly into an object's cell. This
rule/exception approach will simplify many of the interactions
with the Objectsheet compared to the traditional spreadsheet.
Note that traditional spreadsheets, without any inherent structure, have no way to distinguish between "rules" and "exceptions"; there are only "cell formulas". Interestingly, the Objectsheet can be considered a general case of the spreadsheet, with the Objectsheet degrading to the spreadsheet when all formulas are overridden directly into instance cells, and the unifying object structure ignored.
As an example in the Rooms
Objectsheet, the room Name,
Length, and Width properties are
entered in the actual cells (they are manually-entered values in
this case). The Area
property is calculated from the Length
and Width cells,
its formula placed in the Formula row in the Template section.
This is shown below.
An Instance-based Property Formula
Note that even if we didn't give the rooms explicit names, we would have still wanted to name the columns. In this case, the formula still has meaningful names.
To alleviate the danger of inconspicuous overridden formulas, visual indicators distinguish between the various ways a cell's value may be generated. Separate formatting is provided for explicit-value, or manually-entered properties (that is, properties without a Template formula), for cells automatically calculated from Template formulas, and for cells whose Template formulas are overriden. In the above example, calculated cells are indicated with light (green) shaded background.
In addition, formula cells in different Objectsheet Templates can reference each other, enabling oft-used formulas to be specified (and modified) in a single place, and referred to from other locations..
The implications of this rule/exception approach are numerous.
- When new objects are inserted into an existing Objectsheet, formulas and formatting are automatically applied to the object (compared with a traditional spreadsheet, where sometimes formatting is often not retained).
- The Template formula is viewable along with the values it generates.
- Changing the formula is now a single step process; all applicable values in the Objectsheet are automatically calculated (contrasted with spreadsheets that require a multistep process of formula change and replication).
- Even when objects (rows) have no explicit or meaningful names, properties generally do. In nearly all cases therefore, formulas use named references.
- Rules are not absolute; override values or formulas may inhabit any particular cell
- Overridden cells and manually-entered information can be visually distingushed from one another; exceptional cases can be highlighted, as well as cells that expect manual entry of values.
Spreadsheets have two difficulties with hidden rows and columns. First, only entire columns or rows can be hidden in a spreadsheet. If there are multiple structures on the sheet, those structures generally require adjustment so as to not hide important data. Second, hidden columns and rows make it more difficult to follow the formulaic flow through a spreadsheet.
The Objectsheet approach to "hiding" properties is to remove the property as a dedicated column from the instance section but to retain its formula in the Template. (We will call a property with its own column a instance-based property, and a property that exists soley within the Template a Template-based property.) A simple menu command (or dragging and dropping the property name) transforms an instance property into a Template property and back again.
As an example, the result of hiding the Area property of the
Rooms Objectsheet is illustrated below. No logical change takes
place; all internal and external referencing remains as before.
Other cells referencing the Area
property of a given Rooms
object will obtain the same value, regardless of the location of
the property definition. All other propery-related attributes (metaproperties,
like formatting and such) are retained within the collapsed
property and can be turned back in to a columnar property intact.
A Template-based Property Formula
This approach to hiding and displaying properties implies three important advantages. First, formulas can always be made visible. Second, since this change only affects the current Objectsheet, it is graphically independent of other Objectsheets in view (i.e. the "hiding the column" does not affect any other Objectsheet). Third, and most importantly, this allows one to easily switch between formulas and constants for any property. In spreadsheets, constants are entered as single celled values, and references to that constant are absolute (with dollar signs preceeding the cell indices). With an Objectsheet, a property defined in the Template can be assigned a constant for a value, but may later be given a formula that can be access from elsewhere in the Objectsheet. All this takes place without affecting the logical structure of the rest of the Objectsheet.
If we wish to do a what-if analysis of a parameter in a traditional spreadsheet, we must re-organize the existing layout for each change of parameter, as well as change all references to that parameter. In a complex spreadsheet, this can easily disrupt existing references if care is not taken. With the Objectsheet model, parameterization is a simple, straightforward process, and is independent of other parts of the Objectsheet.
With a consistent Objectsheet referencing scheme, the analytical engine can use a consistent syntax for both individual formulas and entire procedures. In addition, the combination of multi-statement formulas (that Javascript innately provides) and word-wrap cell formatting enables entire procedures to be defined within a single Objectsheet row, or even within a single cell. This eliminates the distinction between formula and macros in traditional spreadsheets. The same syntax can be used as "snippets" in formulas and as entire procedures. There is also a hideable area where you can place and maintain formal procedures, shortcut or convenience variables, etc. In addition, utilizing a standard processing engine, along with its syntax and structure (e.g. Javascript/ECMA Script) takes advantage of its installed content and training base.
Single Context, Multiple Objectsheets Instead of creating groups of "related" cells within a single traditional spreadsheet, we work with multiple Objectsheets organized within a single graphical context, each with its own structure. Organizing multiple tables within a single traditional spreadsheets is cumbersome since all components are part of the same grid of cells and changing one part often effects others. Organizing individual Objectsheets is much simpler since Objectsheets are graphically self-contained; they are like shapes in a drawing, and can be moved around without disturbing others. Like drawing shapes, Objectsheets can be graphically "grouped", fixing their relative layout while still allowing the whole to be movable. Furthermore, this allows other graphical elements (lines, shapes, images, etc.) to be introduced within the same environment, and grouped and manipulated with the same set of rules as apply to to the Objectsheet itself.
Grouping The grouping behavior of Objectsheets is weak; in contrast to traditional grouping behavior in drawing applications. Objectsheet grouping does not lock and utterly fix its components together. Objectsheets in a group can still by modified by a single click. An individiual Objectsheet within a group can be moved; moving merely changes the position of that Objectsheet relative to the others. When the group itself is moved (by dragging a graphic "handle" associated with the group) all components within move as well.
Splitting Objectsheets may be split apart (and later recombined) to improve readability and layout flexibility. Again, the logical structure is left intact. For instance, Template-based constants may be separated from the rest of the Objectsheet, and placed along side it, or grouped with other sets of constants. Objectsheets with long, narrow instance sections (many rows, few columns) can be split and arranged in multiple columns for legibility.
These basic characteristics of the Objectsheet represent a trade between completely typeless, free formatted cells in a spreadsheet and the fixed structure of a database or programmed implementation. We have picked the best characteristics of each, providing a model about as simple as the spreadsheet, with enough sematic awareness to make it much easier to understand and manipulate. Objectsheets provide a convenient means for a user to create and manipulate an analytical structure that is easy to follow.
Further development must take place on many fronts, many of them concurrent. The object model must be developed, while retaining as much consistency as possible with the selected analytical engine. The object model must also closely pace development of the persistence model, which must follow the rules of XML, and be further extended within those rules to allow embedding of formulas and methods. The graphical interface must be laid out and glued with these other aspects of the environment, including plotting and visual manipulation; it must be finely honed to provide simplicity and intuitive operation.
Object structures are more complex and sophisticated than that found in simple spreadsheet algebra. There are a thousand nooks and crannies where lie complicating facets of the Objectsheet structure. During development, aspects of the structure, GUI, and persistence mechanism will conspire to make the environment more difficult to operate, more confusing, and to limit the application space.
Still, the utility of the Objectsheet is apparent. There is a significant gap in the implementation space between spreadsheets and object oriented programs and databases. Objectsheets are more scalable (and generally more effective) than spreadsheets in tackling analytical problems. Objectsheets are a closer cousin of object oriented programs, and should provide an easier transition, both with the basic object structure as well as the persistence scheme. It will be the mission of the developmental activity implied from this white paper to create an effective problem-solving environment; to not require the user to be a programmer or even "power user", but to allow easy access to both formulas and procedures, in an overall framework where that user can easily construct, develop, and view solutions to problems.
The following provides a quick introduction to several additional capabilities of the Objectsheet. For additional detailed discussion, please follow the links at the end of each.
As a analytical model grows in complexity, the ability to provide consistency checking can be quite useful in maintaining the quality and integrity of the model. This is not possible in the typeless realm of the Spreadsheet, where there is no consistency checking beyond the trivial (for instance, parameters passed to functions and existance of references). A row in the Objectsheet Template, called the Constraints row, serves to check the validity of a calculated or entered property value. A constraints metaproperty causes entered or calculated values that do not conform to the entered constraint to be flagged with special (user-specifed) formatting. Some examples of constraint tests are: number type (integer, floating point), numeric range (positive numbers only, explicit numeric range, like -2 to 2), or a value in an enumerated list (True/False, "Yes"/"No", "Large"/"Medium"/"Small", etc.). (More...)
Graphical elements can be used instead of the traditional spreadsheet cell text-box, to represent values. These graphical elements include checkboxes, radio buttons, different types of list boxes, scrollbars, and the like, have a place in the Objectsheet. An Objectsheet property's "Properties" dialog box contains a tab to specify a visual interface element.
These visual elements can be created in a traditional spreadsheet. Unfortunately, this is done "on top of" the spreadsheet structure itself, becoming an additional layer and mode of functionality, with additional steps to link it to a calculation. In the Objectsheet model, the graphical element becomes the cell; creating one is a single step process, and seamlessly integrates with the rest of the sheet. (More...)
Instance-based and Template-based Properties were discussed above. In each case, their associated formulas are applied to each non-overridden, instantiated object. Summary properties are logically different from Template-based properties in that they do not reference individual objects, and are not evaluated for each row of the Objectsheet. Summary properties operate on entire arrays of objects. This is akin to spreadsheet functions that average and sum "cell ranges". Summary properties take up their own row on an Objectsheet; they can be placed anywhere in the Template or instance section. When placed in the instance section, the calculating engine skips over summary properties, and comes back and calculates them only after evaluating all the instantiated objects in the sheet. The Objectsheet structure thus separates logical flow and visual presentation: we can add, move, and delete summary properties within a contiguous table without affecting the Objectsheet's logic.(More...)
It is often difficult to document a spreadsheet's use instructions, let alone its logic. There is often not room within a set of cells to enter documenting comments in a free cell. Alternatively, comments that don't use up cell space are possible in spreadsheets, but they use a different interface structure, and require additional learning. Objectsheets on the other hand, enable commenting and documenting in a simpler fashion, without adding to the structure and complexity of the operating environment, and without impacting the logical flow of the model. Objectsheet comments (signified by the "//" prefix) may be appended to entered cell formulas or values, or can serve the to comment an entire cell or Objectsheet row. Commented Objectsheet rows are skipped during model calculation, and only serve as visual labels or documentation. Changing visual formatting of comments (row height, font size, background color, etc.) allows them to serve as usage instructions, titles, sub-headings, etc.). This also allows comments to be interspersed within arrays of data without affecting the referencing above or below the comment, again separating logical structure from visual layout (inserting a comment in the middle of a column of data in a traditional spreadsheet would require remapping references around such a comment).
To organize and gain an overview of the Objectsheets that make up a single "document" on the computer, a "Class Browser" is provided. This construct shows, at a glance, a summary of all (or selected) Objectsheets along with their associated properties and individual objects. The Class Browser takes the form of a heierarchical expansion list (akin to heierarchical "file views" in desktop operating systems). Mouse sensitive arrows or plus and minus signs allows one to expand an Objectsheet entity as single line into a list of its instantiated objects and properties.
The class browser is another capability that does not exist for traditional spreadsheets, but is a natural construct for Objectsheets. This kind of model overview can provide valuable insight into how a complex model is structured.
Also see: Overview,
An Example, Detailed Trades, References
rk, 4 July 1999
email author