Hi all.

6gunz wants to make the spreadsheet model significantly more powerful without making it significantly more complicated -- no jump to "traditional" programming/scripting, just a smooth slope of "one more useful trick" after another.

Made part-time over the last few months, now in open preview. Probably still pretty buggy, and not yet Turing complete. (Solo flounder, looking for confounders etc...)

Pretty genius but I would intensively think about how to improve usability (ease of use, complexity) before continuing implementing features.

EDIT: Actually, more useful than me suggesting a scattershot bunch of things, it'd probably be more efficient to ask what bits gave you pause, which bits look too complicated or difficult to use.

---

Yeah, I agree. The lowest-hanging fruit is probably around the formula box at the moment -- it's easy to type a syntactically incorrect formula, it's unforgiving with typos, and there's a lack of discoverability. I think some "programming editor features" like tab-completion, syntax highlighting and automatic insertion of closing quotes/parens will be a good first step there. Clicking on sheet elements to insert terms in formulas will probably help a little too.

With regard to complexity, though, I'm not too sure there's much to be done. I imagine most uses will look a bit simpler than the demo video because a greater fraction of the time will be spent working on the data, but wrt logic I think the complexity may be irreducible. Maybe better support for foreign keys instead of using lookup expressions? If the user can "relate" tables by columns (and an "arity" -- "one to many" etc) then we might be able to make some formulas simpler with some ORM-esque magic. Then in the example we could write

    trips.from_airport

rather than

    airports[name: trips.from]

though I'm not sure it's a big win.

Maybe we really do need Clippy... Or some kind of formula-writing wizard. Pivot tables...

Gotta find a designer (and/or some users) to keep me honest, I guess.

I really don't want to bring you off your roadmap but I'm going to start working on my own startup in November and am planning how it should look like. I even created a spreadsheet with sub sheet functionality already (but canvas - not DOM based) --> but the sub sheets have a different purpose in my application.

Some weeks ago a very smart friend was arguing with me about the necessity of the spreadsheet that is functioning as a "map". What he meant (I didn't have the opportunity to speak to him since), I think, was that there is no reason that the sub sheets cannot be moved around freely in the entire map but instead are placed within another spreadsheet. In your case the objects (to be placed) are: 1. table; 2. Object; 3. Array..

So the question I wanted to bring up before it's too late is: Why can't these 3 object be placed on an empty space instead of a parent spreadsheet?

At the moment all sheets in my program literally are objects, though the converse isn't true -- not all objects can be viewed as sheets.

That might change in the future -- I think that being able to nest data arbitrarily is pretty important, and so is being able to visually explore that nested data. Maybe that means having "sheets in sheets in sheets".

My program having a list of top-level sheets is slightly unsatisfying. I guess there could instead be a single top-level object/sheet to contain them, bringing everything "into the data model". I don't know if that extra bit of purity would actually make anyone's life better, though.

I am quite hesitant to let anything "float in free space". I think the grid serves as a useful, lightweight structuring tool, like lines on a piece of paper. It provides a little constraint that rarely gets in your way, and often stops you from getting in your own way. Maybe the user should have the option of placing things in continuous space, but I don't think it's a good default. A good demo could convince me otherwise, though ;-).