Writing about this has been on my list for a while. These ideas aren’t very polished, but might still be interesting.
The main idea here is that there’s no clear boundary between spreadsheets and infinite canvases.
Let me list some types on this spectrum:
Schema first spreadsheets / databases
I’m thinking about Notion databases, Airtable, Tana, …Excel as a canvas
Many users don’t just set up their tables as databases, but use them as canvases. Or have multiple tables on one sheet. It’s not so different from an infinite canvas. It’s just a lower resolution grid.
Spreadsheets are not just tools for doing “what-if” analysis. They provide a specific data structure: a table. Most Excel users never enter a formula. They use Excel when they need a table. The gridlines are the most important feature of Excel, not recalc.
https://www.joelonsoftware.com/2012/01/06/how-trello-is-different/
Excel tables
Excel lets you create tables on a sheet.
Good demo of that:Coincidence that I quote Joel Spolsky twice?
And just like you can create tables on a spreadsheet, you should be able to create tables on an infinite canvas.Infinite canvases
So many good apps here: https://infinitecanvas.tools/gallery/Paper
Infinite canvases are probably the digital experience closest to paper and whiteboards.
Paper is used in many different ways too. Just writing linear text, putting paint on it, stacking it, cutting it, folding it, …
Paper comes in different shapes for different use cases.
So what can we build that feels as unconstrained as paper, while allowing to add restrictions when needed?
Examples of adding restrictions could be:
In Excel, starting with an unconstrained sheet, and turning it into a table
More general example:
In Formable, starting schemaless, and later introducing a schema / typesWhen working in teams, adding constrains might be even more necessary. But then at the same time, one should be able to view and edit data in a private view where they might not have the team’s rules.
So what do I imagine here?
I would suggest to start with an infinite blank canvas, where you can freely move things around and place any item anywhere.
Getting closer to a table, you could just display a dot grid, like FigJam does. Or grid lines, like Excel. Add a snap to grid feature, which would behave differently for different kinds of items, and you got something like a spreadsheet.
If you only want that for part of your canvas / sheet, or want more freedom in a certain area, you could do something like nested boards in Muse.
Thinking in Formable’s structures, that would rather be called nested views. So you could just bring in / open a new view on the canvas, or group items into one.
But it shouldn’t just feel like an embed or link to another view, but more like one sheet of paper that might have another one glued on top. You could still draw a line over both of them.
I’d imagine Formable’s canvas to feel like a gridded paper when you start. Pull in anything you want, which could be a table. It shouldn’t feel like an iframe, but rather sit embedded right inside the papers grid.
Formable doesn’t have any clear designs yet, but I’d like to work with the ideas presented here.
Let me know what you think!
–Emil
This is an interesting take on some of these issues, notably how to provide the baseline capability that most people use most often, while also providing a smooth path to more complex use cases. The "transforming" of content into data and structure. This is probably a result of how I interpret what you wrote, but your description here seems to leave out the idea of multiple representation and transformation of data in view but not structure (that you've written about previously, and which attracted me most to Formable in the first place). I wrote some ideas of my own on that previously here: https://garden.oshyan.com/t/a-continuum-of-functionality-and-data-representation/145
But I'm most interested in how those ideas (and the nifty animations you've scattered throughout the website that illustrate them) connect with the spatial free-form-to-table ideas here.