I was reminded last week that I had registered this domain a couple of years ago, and why. What I wanted to build was a PaaS (Platform as a Service) for static site owners to handle forms in a more graceful and meaningful way than simply having the form body posted to them by e-mail.
Before I dig too much further into this project, I wanted to get a sense of how popular an idea this was, and how many people wanted it. So I have put up a one-page Rails app at the http://formbase.io domain, and opened it up for comment.
Please let me know what you think about the idea, either here, or through the app.
Thanks,
Walter
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Any of your services are of interest and this naturally too.
It might be a German issue exclusively (or even a personal), but pricing per month (quarterly, year) is the no-go criteria. I love to pay for good, easy and unobtrusive services, but my way of thinking is pay-per-go. Such as FTG was a “create, generate and host” thing (mostly), I’d like to see if possible a similar process.
I’m paying your per form, charging my client - done.
Naturally this may cause the typical “I’m too dumb to integrate … please help” issue. But even this is to handle by excluding support (towards the service-side hosted forms) or a nice video tutorial.
Would you see this possible?
Cheers
Thomas
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Well, there’s a fundamental difference between the two ideas (FTG and FormBase): FTG writes out a bit of code, which you put on your server, and you take care of your server. FormBase would be a service, running on my server, which I have to take care of.
Walter
On Mar 14, 2016, at 9:56 AM, star-lights email@hidden wrote:
„It might be a German issue exclusively (or even a personal), but pricing per month (quarterly, year) is the no-go criteria."
I’ve been doing some more thinking about what problems this service could solve for the static Web site market. There are some easy wins possible here in the User Experience (UX) realm, and there is also an 800# gorilla that we all try to skate around: file uploads. I believe I have a way to solve both of those.
###UX
When you use a modern Web form, you expect certain niceties: server-side validation of input fields with clear and descriptive error reporting, never needing to use the “back” button to fill out the things you got wrong, and an e-mail confirmation of your request.
These are the baseline, and then there are fancier “in-page” validations with JavaScript, and modal dialogs, like the ones on http://formbase.io, too.
You can build much of this in Freeway, if you have a PHP server (most do), aren’t afraid of a little extra code, and don’t mind using (and understanding) several Actions in a specific combination. Some of these are just not possible, though, because the Actions are designed to allow you to keep everything in HTML (for ease of design and preview) rather than building an integrated PHP/HTML page that can modify its own content on the fly.
Nowadays, when I build forms, it is in Ruby on Rails, which gives me access to a huge library of add-on tools for almost any form of programming you can imagine. Let me walk you through a hypothetical workflow with my (as yet un-built) service, and see how this strikes you:
You sign up for an account at http://formbase.io, and register the domain you wish to add forms to. (Your first domain is free – and you may have as many forms there as you like.) You get a unique URL to use for that domain, something like http://formbase.io/sites/sdf72rsdfjs.
You design a form in Freeway, and in the Page / Form Setup dialog, you enter that URL in the Action dialog.
Upload to your server, visit the form page, and fill out and submit a sample request.
You see a generic “Thanks” page, and when you switch back to the FormBase site, you see your submission details, along with a set of controls to modify the form’s behavior:
You enter the URL of your actual Thanks page, so the generic one will not appear.
Then you mark the name and email address fields as being required, and mark the email field as requiring a real address (not just something that looks like one). And you customize the error messages, if you so desire. (If you just need a translation of the default message into another language, then that’s built in, and the visitor’s browser preferences determine which language is used.)
Now you return to your site and submit the form again, only empty this time.
You see your own form page (at the http://formbase.io URL) with the missing fields outlined in red and the error messages at the top of the form. You fill those in, and submit again, and you see your own Thanks page.
You decide that you want the error messages to appear in a specific part of the page, not just where my server managed to insert them programmatically. Back in Freeway, you insert an inline Action where the error message should appear, and upload to your server. Re-run steps 5 and 6, and you see the same messages, only where you placed the marker Action.
Further details you can customize:
A reply message, with or without the details of the visitor’s submission (“here’s the information you sent us…”).
An email address (or multiple addresses) where the form details should be sent (optional).
…
Your form submissions are stored (responsibly) on our server, following bank-level security practices. You can see your own form data, but other members can only see their own. At any point, you can download your form data in a spreadsheet format, erase older data, change the form design, etc. You can give your clients access to the reporting features for their site, while locking them out of the administrative controls so they won’t break anything.
###300# Gorilla
File upload forms are notorious for a number of reasons. On a shared server, like the ones many of us use for static sites, you can’t control every detail of security, and so you open yourself up to serious danger from someone who wants to take over that server. They upload fluffy-bunny.jpg, which is actually nasty-attack-script.php inside, and then manage to get someone to request that file. And since it’s not just your server, when you open up such a hole, you stand to put hundreds or thousands of other businesses at risk.
Furthermore, if some wag decides to upload a 2GB file, your server will sit there spinning for the duration, and then either your account will go over its limits and you may not be able to log in for a while, or the server will die horribly, or they will see an error message – but in any case, nobody else will be able to use that form either. This is known as a denial of service attack.
So imagine this workflow instead:
Back at http://formbase.io, you click a button on the site control panel, which authorizes the FormBase application with your Dropbox account. We store an API key on your account, not your actual password credentials, and the key is useless if someone else gains access to it – it only lets my server connect to your account in this one prescribed manner.
Back in Freeway, you place an inline Action where you want the file upload field to appear. That Action also rewrites the tag in your page so it has the correct attributes on it for file attachments.
You upload your changes, and now whenever someone uploads a file, it appears in your Dropbox in a specially-named folder, and the URL of that file appears in the FormBase interface, as well as within any notification messages that the server sends you. Dropbox takes care of the details – scrubbing dangerous files, handling any amount of file size that your account allows, and making everything easy for you.
So what do you think about these two “pain points”? Can you think of any others that a robust server-based solution could provide? Please let me know, either here, or at http://formbase.io
Thanks,
Walter
freewaytalk mailing list
email@hidden
Update your subscriptions at:
