Hi! I'm one of the developers of Object Spreadsheets and will do my best to answer the substantive questions in this thread. Thanks to richardboegli for notifying us.
If you tried to access the public demo server with Google Chrome and got an error message, "Oops, looks like there's no route...", that should now be fixed. Sorry for the inconvenience. If anyone runs into further problems, please continue to email us at objsheets@mit.edu.
Can you handle multiple users with different security/permissions? 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?
> Can you handle multiple users with different security/permissions?
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.
Thanks for the thoughtful questions (even if the answer to many of them was "not yet"!). It looks like most people are done here, so I'm no longer watching the thread. If you'd like a response from us, please email objsheets@mit.edu.
There's also a company developing a web spreadsheet solution that allows for inlining code of different dialects into spreadsheets to reference cells like a SQL table: http://alphasheets.com/. They're targeting financial analysts too, iirc.
I went to the Resolver One launch in London about 10 years ago. I was excited about it, being something of a Pythonista. I think it suffered from the same problem that afflicts many attempts to create a better Excel; which is being somewhat incompatible with Excel. In enterprise IT one often hears managers talk about the "server estate" or the "application estate". Companies off all sizes have spreadsheet estates too. These are end user generated Excel sheets that have become business critical. To tap into that market you have to deliver something to the users of those existing sheets that "just works". IMHO, natch...
I just ran through our "simplified parent-teacher conference" example in Airtable. It looks like the main things Object Spreadsheets has and Airtable doesn't are:
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.
Kayia had intrigued me before but I seem to have lost my notes about it, so I watched the video again. I confess I still don't feel like I have a solid understanding of the semantics. It looks like Kayia (like many general-purpose programming languages) has more than enough flexibility to set things up so that applications can be built with similarly clean code as in Object Spreadsheets, but also enough flexibility for novice users to mess things up in unobvious ways once they start creating nontrivial nested structures. I believe we're better off enforcing a schema and showing the entire hierarchical data set on one screen so novice users can recognize more quickly when something isn't the way they want. (For large data sets, we may need folding, or drill-down in separate windows as in Kayia may even be preferable, but showing everything at once is a great place to start to build user understanding of the tool on small data sets.)
I need first to say that you should be commended on working on Object Spreadsheets. Alan Kay has always warmly received anything effort in that space -- it's simply neglected and for no clear reason.
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.
FWIW, user-defined functions as such and the ability to pass composite data types by value are part of our vision but haven't been a priority to implement. In the meantime, a formula can be mapped over a set with a computed field (you only really need a user-defined function when you need the same logic at two different places in the schema), and the typical use cases for relations are also accommodated by our existing features.
There are a couple of recorded webcasts where they mentioned the pricing; it's approximately $2k/seat/year, if I recall correctly. They do make you register for the trial, but they approve it quickly. It's definitely worth checking out.
Thanks for the info. It's a bit expensive for me. I've been wondering about a good long term project and this might be it. I'll have to think about it.
It's hard to say. It's very much like a spreadsheet, but has additional features. One of the ideas from it is now in Excel as pivot tables, but it's done much better in Improv.
I'm not sure if I quite understand this. It's like a database GUI tool but for spreadsheets with some structured data inside the cells? Is it for researchers? Is the idea that you'll generate an underlying explicit schema for the end user?
Abstract from paper [1] gives a better explanation:
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.
> It's like a database GUI tool but for spreadsheets with some structured data inside the cells?
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.
Completely missing at this point are (1) the ability to edit stored procedures via the spreadsheet UI and (2) integration with a UI builder to design the application UI.
Lotus Notes was a bit more usable than Access, InfoPath was interesting as well... In the end, the more "usable" it is, the harder it generally is to migrate when you need scale beyond what's in the box.
Fieldbook has some memory and general slowness problems with 30MB of data, as I currently have there.
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.
Interestingly, we (Fieldbook) used handsontable for a long time, but eventually found it wasn't performant enough for the size of data we had (also we just needed to be able to do more customization than we could wrangle out of it)
I didn't see this in the video, but is there a planned way to read/write the stored data from one of your instances? What does it look like? For certain things (anything with real volumes of data) it's impossible to do data population by hand.
We want to have a good API for this, but we haven't figured out yet what it should look like. Right now, it's possible to read and write the underlying data representation via the Meteor Dynamic Data Protocol, and we have some JavaScript library code to help with this. That's what the spreadsheet client-side code does for all reads and most writes, and what the client-side code of the example applications does for all reads. (For completeness, I'll mention that certain complex data writes and all schema writes from the spreadsheet go through APIs, and all writes from the example applications go through an API to invoke stored procedures.) We're planning to build a better API bit by bit as we do more things with the system; I don't think I can estimate a time by which it will be stable.
