Object Spreadsheets
sdg.csail.mit.edu
sdg.csail.mit.edu
Not yet. We obviously need this for real-world use, but we assumed it would be straightforward compared to the other features we've been working on, so it hasn't been a priority to actually implement it.
> Is it possible to gracefully grow an object spreadsheet into a real application, on scale of facebook.com, with performance and battery concerns along with a fully programmable UI? If not what is missing?
We haven't thought much about this so far; the small to medium applications are the lower hanging fruit for our approach. A few missing things I can think of:
1. We haven't put much work into performance, so the current implementation doesn't scale beyond small demos. It may be straightforward to move the execution to a relational DBMS, but it would take significant engineering (and maybe UI design) to make the spreadsheet UI useful for large data sets and complex schemas; there may be precedent in other tools.
2. Our language currently does not have the abstraction features one would want in order to write really complex business logic, e.g., object-oriented programming (or some alternative) and the ability to pass composite data types by value. If we wanted to support something like Facebook, our language might end up looking somewhat like that of object-relational DBMSes such as PostgreSQL, but with some differences for our data model.
The product was pretty slick, too. I hope someone can crack the nut.
I think that Kayia (http://kayia.org) is also similar but more relational than both this and AirTable.
For Kayia, you can set constraints which enforce schema, if you want, but it's not recommended. I would rather have too much flexibility for novice users than not enough, because that's the side we err on. We often (I'm speaking generally) remove complexity by removing or limiting function, and I disagree with that, philosophically. I would rather steer than stop.
1. Object nesting for the purposes of the spreadsheet UI and cascading deletion.
2. Computed fields that return a set of object references (as real references that can be a starting point for further formulas, not just a string of comma-separated names), which we use to implement the "availableSlot" field in the example.
3. Computed object types, which can be used to map a formula over a set of values returned by another formula, keeping everything in context (as opposed to defining a separate database view). These are not used in the simplified parent-teacher conference. An example can be seen in the "view model" of the full parent-teacher conference, but a better example that demonstrates the need for them is described in section 4.4 of our paper (http://sdg.csail.mit.edu/projects/objsheets/objsheets-onward...).
Many of the other tools we have tested, including Knack, Intuit QuickBase, and Microsoft Access, are also missing these three features.
Lotus Improv on NeXTStep
Abstract Spreadsheets offer many advantages as the computational and data-storage engine for applications that are authored by end users. Paradoxically, however, their main failing in this regard is their computational model. Despite being used in almost all cases to represent data that is essentially relational (with some hierarchical structuring), the spreadsheet model treats the two-dimensional grid as largely unstructured, with formulas linking cells in an ad hoc way. This paper reports on a quest to rethink the spreadsheet model. The model we propose supports not only conventional flat tables, but also nested variable-size lists and object references. It includes a formula language suited to the data model and procedures to specify updates. The model has been implemented in a tool called Object Spreadsheets, which is intended for the development of data-centric web applications. We describe several example applications we built using the tool to demonstrate its applicability.
[1] http://sdg.csail.mit.edu/projects/objsheets/objsheets-onward...
I'm not sure exactly what you mean here. Our tool provides a spreadsheet-style interface to an underlying structured data model with a schema, like you'd have in a relational database. (We often abbreviate this by saying the tool is a spreadsheet with full support for structured data.) The difference from relational databases and the GUI tools that have been developed for them is that we've attempted to optimize the data model and computational model to make sense in a spreadsheet; the full design rationale is given in sections 3 and 4 of our paper. Judge for yourself if we've succeeded. :)
> Is it for researchers?
If what you're getting at is that researchers need to store and analyze structured data, e.g., measurements from repeated trials conducted under different conditions, then yes. It's also true that the tool is a research prototype and development so far has focused more on demonstrating ideas to computer science researchers than meeting the immediate needs of our target user population, but that's an orthogonal issue.
> Is the idea that you'll generate an underlying explicit schema for the end user?
Yes! This is the key thing that Sumwise (http://www.sumwise.com/) is missing. And unlike some tools that merely guess a schema for an existing traditional spreadsheet, we try to provide editing operations that make sense in terms of the schema.
So they're trying to reinvent Microsoft Access?
Would this be faster and more flexible? It seems to be using Handsontable for the spreadsheet component. It seems heavy, but I guess the computations, views and queries is where things get complicated.