Here's one use case: i tried importing a 500+ row wine spreadsheet into it (it has columns like type, producer, name, vintage, rating, source etc).
I had to save the file as CSV and import it -- or at least that's what I thought, but filepicker seems to support picking from google drive. I don't know if it would have accepted a spreadsheet.
Your app seems sluggish to scroll compared to Google Docs at that size, and the record density seems low (I see 29 records per page vs 50 on Google Docs). This is using Chrome 38 on Linux.
The "link to another table" seems interesting, but my data came denormalized so I have a column with e.g. 10 different repeated values on 500 rows. Maybe it would be nice to automatically clean that up somehow. For example, I could Copy the column and have a some Paste (unique values only) option. Maybe the dialogue that comes up (suggesting to expand the spreadsheet) could even tell you about that. Or maybe there could be an option to convert a text field to a separated linked table.
I had some conditional formatting set up via Google Docs, which could be nice to have here; e.g. red wines have a red background in that wine type table.
I don't have a simple primary key -- it's really a composite of {wine producer, wine name, vintage}. The app didn't mind importing non-unique values into that first column. I don't know what the alternative might have been -- an auto-generated primary key?
Having said all of the above, I really like Google Docs and it will take some amazing features to make me switch to anything else. Multi-user planning and documentation via docs is great -- I have a shopping list everyone can update and I can see it change real time on the phone in the shop while someone is changing it from their desktop, and it's always up to date.
Thanks a lot for your feedback, these are definitely things we're looking to tackle.
We're planning on improving scrolling performance soon, it's definitely a priority for us to improve our performance for large datasets.
As for the linking, we definitely want to do more to help you normalize your data. We can also infer column types to help with the import process. Doing this type of thing on paste is an interesting idea.
We have some ideas for how to make it so that you don't need a primary column. One thing that you can do now is make the primary column a formula, and then reference other columns to generate a key.
If you're interested in talking about the challenges of creating a performant spreadsheet, I've built a javascript-based spreadsheet backed by a database that's more performant than Google Docs/any open source table available on the internet. I'd be happy to share the techniques.
This looks like a nice product. Software companies have been struggling to make a mass-market database program ever since Lotus 1-2-3 (the "3" was a database), but the spreadsheet remains king, despite the fact that for storing structured data, it is almost as bad as a Word document with macros. So I'll be rooting for you.
One complaint: Referring to your Basic plan as being "Free forever" is a bit disingenuous. In my opinion, the FTC ought to prohibit use of this term by tech companies located in the 650 and 415 area codes.
> Software companies have been struggling to make a mass-market database program ever since Lotus 1-2-3 (the "3" was a database)
Not really; there were several post 1-2-3 mass-market database programs that had considerable success (dBase, Paradox, Access, FileMaker), though of those only Access is still successful.
> In my opinion, the FTC ought to prohibit use of this term by tech companies located in the 650 and 415 area codes.
Is this part of an East Bay / San Jose economic development plan?
> Software companies have been struggling to sell a mass-market database program ever since Lotus 1-2-3 [that is not Access]
There, I fixed it for you. (disclosure: I worked on a similar tool, had a friend, one of the best programmers I know, who built a similar tool, worked on an ERP system that addressed many of the same use cases, and I started Skysheet, YC W09, with gruseom).
I'm not sure if the "forever" keyword was ever involved, but two examples that spring to mind are Google Apps and Dyn, both of which have discontinued their free tier.
By the area codes provided by EvanMiller (415 = San Francisco, 650 = Palo Alto) I don't think he meant "free first, then they started charging". I think he meant "got acquired" / "pivoted" "went out of business".
Let's see. There was Apple's iTools, .mac, MobileMe, and now iCloud service (sort of one big evolving service, with some bits chopped off or replaced at various points in time), which has gone from free to paid to freemium.
There's Google Apps for your Domain, which killed off its free service in favor of the $5/user per month service.
Ning shut down their free service and switched to a paid only model.
DynDNS also shut down their free service, only offering paid.
This looks fantastic! I was drooling during the demo video - you've improved on so many things from the standard spreadsheet at once.
If I could make a request for the API: it's almost impossible to get a simple JSON serialization of a table in Google Spreadsheets. There are so many times where I just want to make a really simple MVP with a backend data source, but don't want a full-fledged Firebase database. If I could just stick my data in an Airtable sheet and point my Javascript to load it and create the page dynamically, that would be ideal.
You should give prismic.io a spin. You basicaly define data format in as JSON, CRUD interface is generated just from data description. The data you you add is also JSON you can easily retrive. You can query the data with predicates. Did a few projects with it, didn't need a database, or create a CRUD, such a relive.
Thanks very much! Re: API, yes absolutely. Our web and mobile apps already use an internal API that uses RESTful JSON routes for reading tables, updating rows, etc. If you want to chat more about it or discuss the specifics of what you need from the API, you can reach me directly at howie@airtable.com
No plans to automate. I would have emailed the OP but couldn't see any contact details in their profile.
Detected via a Firefox extension [1] (there are several on AMO). Given the nature and severity of the vulnerability, and how widespread it still is (I get an alert every few days), I'm surprised everyone doesn't use one.
FYI, we require that you oauth in via a Google account purely for authentication right now. We don't request permissions for your email, calendar, contacts, or other data--only your name, email, and profile picture (which is used in the UI). We're working on support for email/password based signup, as well as oauth support for other services.
If you click through the link in this HN post ( https://airtable.com/invite/a3sz9t7b ) it has an invite code embedded in the URL. Once you're signed in, if you visit airtable.com/templates you will be able to browse through and directly add a template to your workspace. You can also visit airtable.com/templates without an invite code and browse (but not add)
Congrats! I got very excited when I first saw the video. Then I signed in to use it, but got stuck.
For me the UI seems a bit heavy. Not sure what it is about the UI, but it feels very constrained for me. It could just be the color, the size of the fields or something. But I think with a small amount of UI tweak it'll feel more welcoming and happy.
I know I'll use it for sure, but now I just don't see a reason to reach out for it over Google Apps. Which is a challenge you'll face.
For example, your demo apps are all great, but for anyone who is hiring or sales leads are a pain, there is already a fully integrated product out there. For the rest, Google Apps might just work fine.
Basically, I think it comes down to fining your product-market fit and going after that segment.
I don't suppose they've considered making IEEE 754-2008 decimal floating point numbers the default number representation. It's a shame Intel didn't consult Dr. William Kahan earlier in their design of the x87 floating point unit. At this point, binary floating point is deeply entrenched despite most uses outside of scientific modeling being better suited to decimal floating point.
Most spreadsheet calculations are better suited to decimal floating point, and decimal floating point numbers are more intuitive for most users. A surprising number of the "Excel bugs" you find online are people misunderstanding binary floating point numbers, or some of the display hacks Excel uses to hide binary artifacts.
It's pretty hard to use a custom floating point representation that isn't supported as a primitive type. To make the matters worse even the standard binary floating point number doesn't map to JSON. E.g. +/- Inf and NaN don't have JSON representation.
We strive hard to provide intuitive user experience and abstract away the complexity of modern computing for non-technical users. At some point we might use a decimal floating point or better yet a fixed point decimal as the default representation for numbers.
There's also DEC64, Douglas Crockford's proposal for a decimal floating point type to serve as the only numeric type in future programming languages: http://dec64.org/
POWER and RISC-V processors already have hardware support for IEEE 754-2008 decimal floating point numbers, and C# has language support for IEEE 754-2008 decimal floating point.
It seems the main claimed advantage of dec64 over IEEE 754-2008 decimal64 is in the fast-path zero-exponent case. Note that V8, SpiderMonkey, and many other dynamic language implementations use a separate compact fast-path representation of integers that renders this point moot. Also, no benchmarks are provided to show the supposed speed advantages of dec64 libraries over decimal64 libraries.
Also, I doubt the dec64.org's claim that the primary reason for slow uptake of decimal64 is the speed of software implementations.
In short, dec64 is mildly interesting, but its claimed advantages aren't enough to justify abandoning the decimal64 format that already has hardware support and language support in a very popular language. Intel also had a large role in standardizing the decimal64 format, so I suspect they'd be much more likely to implement decimal64 in hardware instead of dec64 in hardware.
Edit: on a side note, it's unfortunate that neither dec64 nor decimal64 forces normalization, complicating comparison and sorting.
Readit News
I had to save the file as CSV and import it -- or at least that's what I thought, but filepicker seems to support picking from google drive. I don't know if it would have accepted a spreadsheet.
Your app seems sluggish to scroll compared to Google Docs at that size, and the record density seems low (I see 29 records per page vs 50 on Google Docs). This is using Chrome 38 on Linux.
The "link to another table" seems interesting, but my data came denormalized so I have a column with e.g. 10 different repeated values on 500 rows. Maybe it would be nice to automatically clean that up somehow. For example, I could Copy the column and have a some Paste (unique values only) option. Maybe the dialogue that comes up (suggesting to expand the spreadsheet) could even tell you about that. Or maybe there could be an option to convert a text field to a separated linked table.
I had some conditional formatting set up via Google Docs, which could be nice to have here; e.g. red wines have a red background in that wine type table.
I don't have a simple primary key -- it's really a composite of {wine producer, wine name, vintage}. The app didn't mind importing non-unique values into that first column. I don't know what the alternative might have been -- an auto-generated primary key?
Having said all of the above, I really like Google Docs and it will take some amazing features to make me switch to anything else. Multi-user planning and documentation via docs is great -- I have a shopping list everyone can update and I can see it change real time on the phone in the shop while someone is changing it from their desktop, and it's always up to date.
We're planning on improving scrolling performance soon, it's definitely a priority for us to improve our performance for large datasets.
As for the linking, we definitely want to do more to help you normalize your data. We can also infer column types to help with the import process. Doing this type of thing on paste is an interesting idea.
We have some ideas for how to make it so that you don't need a primary column. One thing that you can do now is make the primary column a formula, and then reference other columns to generate a key.
Edit: reach me at shri (at) freshvc (dot) com
One complaint: Referring to your Basic plan as being "Free forever" is a bit disingenuous. In my opinion, the FTC ought to prohibit use of this term by tech companies located in the 650 and 415 area codes.
Not really; there were several post 1-2-3 mass-market database programs that had considerable success (dBase, Paradox, Access, FileMaker), though of those only Access is still successful.
> In my opinion, the FTC ought to prohibit use of this term by tech companies located in the 650 and 415 area codes.
Is this part of an East Bay / San Jose economic development plan?
There, I fixed it for you. (disclosure: I worked on a similar tool, had a friend, one of the best programmers I know, who built a similar tool, worked on an ERP system that addressed many of the same use cases, and I started Skysheet, YC W09, with gruseom).
Deleted Comment
How so? I haven't had a company ever tell me this then start charging. Oftentimes they go out of business, but that is a different problem. :)
There's Google Apps for your Domain, which killed off its free service in favor of the $5/user per month service.
Ning shut down their free service and switched to a paid only model.
DynDNS also shut down their free service, only offering paid.
How many more examples do you need?
If I could make a request for the API: it's almost impossible to get a simple JSON serialization of a table in Google Spreadsheets. There are so many times where I just want to make a really simple MVP with a backend data source, but don't want a full-fledged Firebase database. If I could just stick my data in an Airtable sheet and point my Javascript to load it and create the page dynamically, that would be ideal.
If you are looking to update the Sheet too I've not explored that far; otherwise let me know which of the above you're having trouble with!
http://en.wikipedia.org/wiki/Dabble_DB
Detected via a Firefox extension [1] (there are several on AMO). Given the nature and severity of the vulnerability, and how widespread it still is (I get an alert every few days), I'm surprised everyone doesn't use one.
[1] https://addons.mozilla.org/en-US/firefox/addon/foxbleed/
For me the UI seems a bit heavy. Not sure what it is about the UI, but it feels very constrained for me. It could just be the color, the size of the fields or something. But I think with a small amount of UI tweak it'll feel more welcoming and happy.
I know I'll use it for sure, but now I just don't see a reason to reach out for it over Google Apps. Which is a challenge you'll face.
For example, your demo apps are all great, but for anyone who is hiring or sales leads are a pain, there is already a fully integrated product out there. For the rest, Google Apps might just work fine.
Basically, I think it comes down to fining your product-market fit and going after that segment.
Most spreadsheet calculations are better suited to decimal floating point, and decimal floating point numbers are more intuitive for most users. A surprising number of the "Excel bugs" you find online are people misunderstanding binary floating point numbers, or some of the display hacks Excel uses to hide binary artifacts.
It's pretty hard to use a custom floating point representation that isn't supported as a primitive type. To make the matters worse even the standard binary floating point number doesn't map to JSON. E.g. +/- Inf and NaN don't have JSON representation.
We strive hard to provide intuitive user experience and abstract away the complexity of modern computing for non-technical users. At some point we might use a decimal floating point or better yet a fixed point decimal as the default representation for numbers.
It seems the main claimed advantage of dec64 over IEEE 754-2008 decimal64 is in the fast-path zero-exponent case. Note that V8, SpiderMonkey, and many other dynamic language implementations use a separate compact fast-path representation of integers that renders this point moot. Also, no benchmarks are provided to show the supposed speed advantages of dec64 libraries over decimal64 libraries.
Also, I doubt the dec64.org's claim that the primary reason for slow uptake of decimal64 is the speed of software implementations.
In short, dec64 is mildly interesting, but its claimed advantages aren't enough to justify abandoning the decimal64 format that already has hardware support and language support in a very popular language. Intel also had a large role in standardizing the decimal64 format, so I suspect they'd be much more likely to implement decimal64 in hardware instead of dec64 in hardware.
Edit: on a side note, it's unfortunate that neither dec64 nor decimal64 forces normalization, complicating comparison and sorting.