It’s a drag and drop form builder that saves as JSON schema. You can export and use in your own app, or submit to our backend and send Webhooks to an automation service like zapier.
I use it in my client projects since I frequently need to customize form fields, then I can reuse them across clients.
https://ResponseVault.com is built for that. Drag and drop React form components that can embed in any app. All responses and the form definition are saved in json-schema and can be exported to be used with any package that interprets json-schema.
It's great to see more libraries that deal with rendering JSONSchema. I've been working on a drag and drop formbuilder / grid [0] for creating crud apps that leverages react-jsonschema-form.[1]
I noticed that while I create custom rails apps for clients, they often want to create additional forms and still leverage the authentication, permissions, and existing data in the app. This rules out most 3rd party form builders like typeform, jotform etc. which are mostly for surveys anyway. Sometimes the dev time to create them(UI, DB migrations, testing, validations) is too costly for an idea they just want to test.
So, I use the builder to create a JSON Schema, then embed the form into the rails app. What's cool is that I can utilize permissions from the core app to disable certain fields, and I can pass in enum values so drop downs have up-to-date options pulled right from the DB.
We use react-jsonschema-form, but the jsonschema we produce could be used in any of the tools mentioned in this thread.
I'm close to opening this up to other devs soon, and would love your feedback. There's a signup form on the website if you're interested.
Early on, it's meant spending months on implementation, hand-holding the first few users so they can become evangelists within the company. It's not a lot of work, it's just over a long period of time.
I track usage metrics every day and routinely message power users to ask what may be keeping others from adopting, asking non-users if they've been trained, and asking execs if they have evangelized from the top down.
So, you have to hit everyone over a long period of time.
I guess my point is that there are some crews where all their work is remote and subject to spotty cell service. It all depends on the kind of work the company is doing. So, for some companies, it's not a corner case at all, it's a factor in the primary use case.
The company I work with gives everyone a verizon cell hotspot and an android tablet. These work fine in city areas where this company does a lot of utility work.
But, when you do an install of electric wire towers on a mountain, you might not have cell connectivity. Most apps get by this by saving data locally, and then transmitting on the next connection.
Having built a field management system in the construction industry[1], I can confirm, it's a tough market. And, most of it comes down to getting in front of people. A lot of my time is spent going to trade shows and pitching, just like Tracy did, when I'm not coding.
There's a stigma that this industry is full of people who resist technology, but I really don't think that's the case. People in this industry resist change because change is risky. There's too much money at stake, and delays associated with new technology can ruin an entire job. Paper processes are usually terrible, but you're never going to have to battle wi-fi connectivity to flip through your spec, or experience your pencil throwing a 500 when you fill out a safety analysis. It takes a while for anyone in the field to get comfortable with the pros and cons of a new process versus a paper process that's worked for years.
It's changing incredibly quickly, though. There's a lot of new products getting funded, and a big opportunity to integrate between them.