Treesheets review

There are a number of scientific software packages that work and some that don't really serve a purpose, other than to deceive people into thinking they are useful. This forum is for separating the two, listing weaknesses and strengths from direct experience with these packages. Please post reviews of software intended for scientific data analysis, plotting, display, modeling, interaction, statistical analysis, etc. Any branch of science is acceptable so long as the package can be used by that branch. If there is any doubt, please indicate which branches of scientific investigation or engineering are associated with the package.
Post Reply
Site Admin
Posts in topic: 1
Posts: 14
Joined: Sun Apr 28, 2019 3:48 pm





Treesheets review


Post by jake-boards » Thu Apr 30, 2020 11:27 pm

Treesheets is an advanced spreadsheet concept software. I know it's not strictly science, but I've wanted software like this for a long time. I think it could be useful in a scientific setting .

The software works on a table model, where it's possible to embed tables inside tables, create mind map-like structures, embed images, and generally do neat things. Everything is a table, of one sort or another.

Let's talk a little about the interface. Certain design choices have been made which make operating this software seem alien. Fortunately, there is an excellent tutorial which loads when you start the software. In fact, the tutorial is the best part of the software. It takes you through all the features. That, combined with the screenshots page gives you a good idea as to what the software will do.

The good parts of the interface is that you can easily add cells, rows, columns, and I mean it's incredibly easy... better than Excel for sure. The "hierarchy swap" (F8) with cell tags is complete genius. It allows automatic re-ordering of the priority of nesting. If this feature is stolen from somewhere other than database programming, I've never seen it before. You can use F9 to embed selected cells in a new grid. Variations on F10 will fold and unfold cells. Good design choices in the command bar at the top allow you to add basic colors and icons in a useful manner. There is a semi-functional array programming language that you can embed right into the spreadsheet.

And now for the bad... the programming language is semi-functional and is probably not going to work out. It's not a horrible idea, but solving this problem is analogous to solving a circuit routing problem. You are attempting to carry arbitrary container sizes full of arbitrary data types between cells (in a graphical manner) and figure out how to output the data. It's simple if you just use the normal spreadsheet method, and flipping insane to do it this way. I like it, but it needs a re-think.

Text is, unfortunately, a regression from other packages. Assigning a style to text applies it to the whole cell, not to words or letters like current spreadsheet packages. There is no concept of a canvas zoom. In order to zoom in on a sheet, you have to select the outermost container and enlarge the text. This is a horrible design choice. I doubt very much that it is necessary. The limited layout options are limited and will come back to bite you. In fact, this package doesn't have a clear idea as to how to lay out text. This problem needs to be solved in a fused WYSIWYG and parametric manner. I'm not saying I know how to do it... I'm saying I know that it must be done this way to solve all the sorts of challenges that come with combining calculation with layout.

The major weakness of Excel-like spreadsheets is the naming conventions. Many calculations require something like a global variable. These are cumbersome in a normal spreadsheet. Doing this requires something like a named anchor point in a sheet. Spreadsheet clones have no concept of names relative to an anchor, because there are no anchors. Treesheets does no better. An improvement would have been to name areas, allow the cells to be named relative to the area, and allow cascading names to handle the embedded sheets. This is what an advance in spreadsheets would look like, in my opinion.

Once you start trying to handle general math among arbitrary arrays, you're basically writing another programming language. So, you should probably steal a language that already exists. That way you don't have to re-invent the wheel.

The final rap on this spreadsheet is that it needs more design work. The simplistic interface works well, but the potential is so huge that it needs some major help to become what it should be. Hopefully, someone will pick up the interface improvements of this package and combine it with some better design choices.

word count: 696

Post Reply