Maybe I'm just a cheapskate...
I guess it depends on which kind of business are they after.
I think there should at least be a FREE tier which allows 1 or 2 forms. Once someone sees the value, they'll jump for more.
I understand that textual data is light, but 250MB seems quite low given current costs of hard drive storage.
Why the user limit too? Your costs seem to be in data transfer/storage.
But we seem to need a cheaper plan designed for developers and geeks so that they can play around Ragic with minimal investment.
I may get 2-3 days in the next 30 where I can take some serious time with it - by the time I have any traction, the trial will have ended.
Nah, just that your time is worthless.
It looks like you're close to making a good product. But you're at 90%.
Basically I tried creating a little app and it's very painful. I don't believe you've sat with a user and watched them try to create an app without you intervening and giving guidance.
So sit down with some real users and watch them try to use it. Your front page claims install>customize>import. It doesn't work like that at all. It was confusing. For example the upload excel img looks like it's a button. It's not. When I did manage to create an app I first tried editing the cells directly, but they're not cells like excel. Eventually I realized I had to add a textbox, which was also confusing as the width kept changing and I couldn't stop it. At about this point I gave up. Then got hit with multiple alerts when I tried to close the pages.
Then tried to save it.
The most confusing save mechanism I've ever come across.
Tried to just close the page again. Multiple warnings again.
Argh.
And calm. I'm in the process of stopping smoking so my temper is a little, hmm, Hulkish.
I decided to try again while writing this using the import excel function. It didn't work from the front page at all as you had to already have a project (why?). When I tried to do it via the upload the open file dialog never opened. I gave up again.
Also find someone who knows something about sales and marketing. There's not even a CTA button on the homepage to signup. The copy is terrible. You've made the mistake of going typical corporate million page website which doesn't actually tell me anything at all. The order of the home page is all wrong (you should not be leading with the app concept which doesn't actually seem to be in the product). You're making the mistake of selling features, not benefits.
I'd personally spend a little more time so the sales website didn't look like bootstrap (the irony being you don't even seem to be using bootstrap).
As I said, good, but no cigar yet.
Right now most of the Ragic developers first go through 2 hours of training before they start building. So they kind of know what the basics process are.
We are in the transition process trying to move from a tool that we personally teach developers how to use, to a self help type of product that developers can start by themselves. Functions like drag and drop add fields are added just this month.
I will certainly find a group of users, sit by them one by one to make our learning process a lot smoother. Again, sorry for the confusion. I think I will certainly post again after we tune the process. The HN posting feedback is really helpful.
There's definitely a market for something like this and personally I think Salesforce is a overcharging by a lot and the field is ripe.
Ignore the thing about the guy moaning about $19.95 p/m.
That's a lot of friction to overcome! I suspect there's about between 2 and 3 orders of magnitude ratio for Ragic user-developer's ramp-up time and Ragic developer's time to reduce it.
I read your "how this is different than a spreadsheet" blog, and none of the examples struck me as compelling, even though I use my Excel/SQL toolchain every day. Given how strong the ecosystems are around those tools, I think it would be very challenging to convert power users without some really obvious hook.
That one hook COULD be a good mobile client. For example, I have a dashboard built in Excel with an ODBC connection to a few of my company's DBs. However, I obviously can't see this on my phone, since no mobile Excel client supports ODBC (not to mention the macros I have built in).
I could maybe see a "disruption" angle, where you provide 75% of the functionality of Excel+ODBC+SQL+Workbench in one easier to use package, but I wonder how large the market is for people who want to work with that level of data but don't want power tools. I guess that's one area where you'd have to trust your market research/gut.
Could be wrong though -- would be great if something like this could improve the data/analytical literacy of the general population.
It would be quite a bit of trouble if Excel users want to implement access control on whether some users can read or write certain entries.
This more closely mirrors the workflow in my office at least, where only a handful of people create reports, but maybe 10-20x the number of people just want to consume it.
1. The programmers, utilizing an Excel+SQL setup for users in an IT setting.
2. The business users who use Excel for more than they should be, or use it in a place a DB would be far more efficient.
Like another poster said, the former probably aren't going to find anything above and beyond what they can't already accomplish with a DB and Excel.
The latter, on the other hand, are a huge market and need help. This is the market who hammer spreadsheets, but are completely in the dark when it comes to databases, and to whom, I believe, PG was referring. As one of those users (okay, I know a bit more about DBs than the "average" business person), this looks complicated. I can't determine precisely what it does, and there seems to be a lot of programmer speak. Apps? APIs? "Development" required? It looks hard. In other words, I want an Excel/DB setup, in theory, but don't really know if this is what I think it is.
That said, as a data dabbler, this is intriguing. I'll be following progress.
You mention that a DB would be far more efficient. What kind of efficiency do you have in mind?
The technique I've used in the past is to use SQL to query and output the data I need, then manipulate it in Excel. I'll leave it open that I'm not good enough with Excel, but I find MySQL query language more powerful for filtering, grouping, etc. However, there are a few too many steps in there, and it's not something I'll be teaching my mother. Someone actually has to set up the database, and that's no cake walk for the lay person.
Now, I'm going to take a guess that you're implying that Excel already has these features, to which I'll answer: possibly, but nobody I know is using them. That's why I think it's a large market.
But hey, if you know a solution off the top of your head, let me know. I'm always looking!
Being able to automatically recognize patterns in data which would be suitable for normalization techniques, then managing those techniques behind the scenes, would allow for people using a GUI for data entry, but would open up the possibility for more flexible/powerful/efficient SQL when needed.
In any case, the concept sounds good and is otherwise well presented.
Anyway I haven't tried your products, but I'm very positive about what you're trying to do. The HN community is so comfortable with programming that they'll connect less with the value of this concept than many, so take their comments with a grain of salt. For the countless people out there who feel constrained by their knowledge of spreadsheets --- useful but limited in scale --- this could be very useful, if done right
DB Apps. Exactly [what] you need. Now. Businesses don't need hundreds of unneeded* fields and functions that [are] suppose[d] to cover the need[s] of every company. Ragic delivers your DB apps exactly [the] way you want, fast.
* unneeded isn't required here since it's already implied that these fields and functions are unneeded when you say "Businesses don't need.."
http://en.wikipedia.org/wiki/Lotus_Improv
I've been waiting ages for this. Desktop, web-based, tablets, however.
Old timers may recall that Lotus Symphony had both database and spreadsheet features, like a multi-app. It was cool. At the time, Lotus Improv seemed like a healthy fusion, next logical step, minimum viable product.
Improv was victim of the Innovators Dilemma plus installed base inertia. I remain impressed that even with their market dominance, Lotus was experimenting, releasing crazy new products, and willing to eat their own children. (Though I can't forgive Lotus Notes, sorry.)
PG's original blurb (http://ycombinator.com/ideas.html):
"22. A web-based Excel/database hybrid. People often use Excel as a lightweight database. I suspect there's an opportunity to create the program such users wish existed, and that there are new things you could do if it were web-based. Like make it easier to get data into it, through forms or scraping.
Don't make it feel like a database. That frightens people. The question to ask is: how much can I let people do without defining structure? You want the database equivalent of a language that makes its easy to keep data in linked lists. (Which means you probably want to write it in one.)"
He's old enough that he should know better.
The pricing and usage limitations on forms for "personal" (one user / 10 forms / $19.95/month) and "lite" (20 users, 10 Forms, $99.99/month) indicate that you don't understand that full collaboration for both large and small entities is where you will find and grow your market of users, and that small groups are not going to be thrilled with crippled functionality.
I suggest charging only on a per-user basis and not cripple the application with limited forms. Make it easy for even small users to want to rely on the full application for all of their activity. They will tell everybody about your useful application, and won't advertise its silly crippled limitation. Let both small organizations and individuals grow into comprehensive and full usage without a big hurdle ($200 a month) for complete functionality.
What's insufficient about Google Docs for that? i.e. a spreadsheet that supports collaborative use.
Things that I can point out as missing:
- no support for other locales (it's dd/mm/yyyy and 2300, not 11pm where I live, US is not the only place in the world)
- no rich-text on long-content fields
- no actual changes visible in revisions, history contains only "changed by xxx on yyy"
From the developer's perspective, the API is really silly. It seems to be completely different from normal access path. Tokens need to be authorized by project owners, not all authentication schemes work with APIs. I don't get at all why is API access treated as something additional, rather than a normal usage pattern. If I've got a user account, I should be able to do via the API every action I'm allowed to do via web - without anyone's blessing.
API design also leaves a lot room for improvements. Custom XML only with things like this definition of a query:
<query>{'5'.CT.'Ragnar Lodbrok'}</query>
<options>num-4.sortorder-A.skp-10.onlynew</options>
Trying to figure out the exact meaning of "field_type", "base_type", "role" and "mode" in the results (all are attributes on every value of the results) along with how to resolve them when they reference values in other tables (which can be done in 3 different slightly underdocumented ways from what I've seen so far) is pretty difficult. This may be a good start for a TDWTF article...
It would be nice for them to have written in the contract to open source their product if they go out of business and are not purchased are liquidated by another company.
I too spent a lot of time utilizing DabbleDB unique tool-set and have yet to get back to the level of productivity after they went under.I want to reiterate what has already been said; this does not feel like Excel. If you spend some time watching (medium-to-low skill) people who use Excel as a general purpose tool to perform general tracking and calculation tasks, you'll see there's a very different way they work.
They start with a blank sheet, and start putting data in rows. Then they add some formulas to the rows, and do a bunch of sums on some columns. The idiom you've chosen, of dragging and dropping, is a significant workflow change.
A few more things that I haven't seen pointed out already.
Your pricing scheme should differentiate between designer and non-designer users. If I buy a personal account, it's kinda useless when I can't give my url to someone and tell them to create a new entry and edit data.
Also regarding users, the lack of OpenID integration seems an obvious lack. Creating an account just to enter some data is a pretty high bar. Ideally, I should be able to share a form via email, implicitly granting data entry permissions to the recipient, then they can click the link in the email and be prompted to use their email provider's OpenID to authenticate.
Anyway, you've got some good ideas here, but I don't think you've got the right focus on Excel/Access users quite yet. It lacks the feel of Excel, and lacks the features of Access.
If the user already have data on an Excel, we provide an import wizard so that they can import their Excel and create a database with it.
If the user does not have existing data from Excel, they can first define the data fields on Ragic using the design mode. They can actually create cells as fields just like they would on a spreadsheet, but a lot of users find it hard to catch on so we added the drag and drop model just recently. So both ways should work okay.
And actually we do support OpenID log in, and the ability to click on an URL in e-mail to grant access to some DB entries. I guess we have to work on making these features more obvious to users.
Thanks for the feedback!
The logo is not showing up for me, or for that matter, neither are any of the images on your Features or Pricing pages.
On your home page, what is your primary call to action? Do you want people to watch the video? Could you have people try something out? How about making the applications clickable to show more details or have people play with the applications? Have your video proofread for grammar. Good luck!
FWIW I think this is an interesting approach. We're trying to approach one specific use case in our own product (I'm in agreement that smaller companies need an alternate solution to larger CRM tools). Good luck!
Things should work normally now.