Don't do that. Please.
Why?
It's maybe good enough for protoyping, but that's all.
11–18 of 18 posts
Earlier quoted context omitted.
Why?
Because Google Speadsheet isn't designed to be a database. For example there are no datatypes. It's maybe good enough for protoyping, but that's all.
Love the idea. Clearly, a ton of effort put into this, congrats on shipping. But if you're going to abstract away Google Sheets, you might as well make a thicker abstraction. I want to use Google Sheets like a key-value store or some Mongo-like API, without thinking about worksheet names, column names, or underlying worksheet-specific implementation details. Your custom designed API is too much of a leaky abstraction…
That's a very good insight! We treat spreadsheet more like a database with a schema. What you propose is a schema-less approach. I like this idea, and I think we will try to implement it, as we see that in such solutions schema is needless and is adding more complexity for the end user, which, in most cases, don't care if there is any schema or not - she is just a spreadsheets user. From the other hand, it's hard to…
Love the idea. Clearly, a ton of effort put into this, congrats on shipping. But if you're going to abstract away Google Sheets, you might as well make a thicker abstraction. I want to use Google Sheets like a key-value store or some Mongo-like API, without thinking about worksheet names, column names, or underlying worksheet-specific implementation details. Your custom designed API is too much of a leaky abstraction…
That's a very good insight! We treat spreadsheet more like a database with a schema. What you propose is a schema-less approach. I like this idea, and I think we will try to implement it, as we see that in such solutions schema is needless and is adding more complexity for the end user, which, in most cases, don't care if there is any schema or not - she is just a spreadsheets user. From the other hand, it's hard to…
Love the idea. Clearly, a ton of effort put into this, congrats on shipping. But if you're going to abstract away Google Sheets, you might as well make a thicker abstraction. I want to use Google Sheets like a key-value store or some Mongo-like API, without thinking about worksheet names, column names, or underlying worksheet-specific implementation details. Your custom designed API is too much of a leaky abstraction…
That's a very good insight! We treat spreadsheet more like a database with a schema. What you propose is a schema-less approach. I like this idea, and I think we will try to implement it, as we see that in such solutions schema is needless and is adding more complexity for the end user, which, in most cases, don't care if there is any schema or not - she is just a spreadsheets user. From the other hand, it's hard to…
Then you can have other apis on top of it for opinionated usage like a kv store or other stuff.
For representing a nested key the first implementation that springs in mind is to use the indent (number of empty colums on the left) as indicator of parent-child relationship.
Don't do that. Please.
You list Code for America, imgur, Berkeley, Stanford, and others under partners on your website. How are they using this? And do you have some links to blog posts of them talking about it or something?
Folks from Code for America were using it for very simple CMS to show dates of some events.
Guys from GeneralUI are using this for a quick solution for prototyping and have forms up and ready without setting up middlewares, servers, etc.
A customer from imgur is using this for some user research process (getting feedback).
Basically, most of them are using this in places where marketing or UX meets IT. Or there's no budget for IT to be involved, and they need to setup something on their own. We are trying to get all of those awesome use cases and make stories and blog posts from there. We are really amazed by some of them, what people can build if they need to.