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.
You learn quickly not to mention favorably certain taboo subjects here on HN, like Austrian economics or free markets being better than regulated one. (I'll refrain from pointing out others, I want to limit the number of downvotes I get. Self-censorship or, in other words, learned helplessness.)
Look, as much as I dislike the Austrian school (it all hangs on certain premises that I don't believe are necessarily true, so I don't think it contributes much to being able to understand the economy), the main problem with the comment above was that it wasn't very useful in just dropping a link with little context... With a bit of commentary or a brief summary of the article, people would have engaged with it instead of just downvoting.
I don't disagree, I think that certain ideas from the post-Keynesian and modern monetary theory are probably the closest to actual evidence based Economics at the moment.
There no real free market. I highly encourage the book Debt: The First 5,000 Years. The author makes the argument that markets do not exist independently of states, or at least when they do, they exist in the vacuum of a previous state post-collapse.
It's an incredibly eye opening book that talks about debt, money, war and slavery. They are all deeply connected.
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.
Exactly- risk aversion is the driving force. When I was a civil engineer, paper was king. It's wasteful printing 5x copies of one 1000+ page spec, but it's reliable.
I did write a shop drawing automation program when I worked at the office. There was resistance to it at first, but getting the right people on board and demonstrating the improvements helped a lot to get it all the way to the executives of the company. During my push to get my software adopted I learned a lot similar to your perspective; many professionals don't dislike new technology, but they're unwilling to put their name beside it unless it's proven to work.
A lot of young engineers like myself want to walk in on the first day and start shaking things up. But working in a slower, more risk averse field has made me a better software engineer by tempering some of those impulses to adopt the latest and greatest tech. Taking a pragmatic and proven route will nearly always get you reliable and predictable results.
>A lot of young engineers like myself want to walk in on the first day and start shaking things up. But working in a slower, more risk averse field has made me a better software engineer by tempering some of those impulses to adopt the latest and greatest tech. Taking a pragmatic and proven route will nearly always get you reliable and predictable results.
Nice to see your perspective, this is gold! I've worked in the B2B and risk management side of Construction and I'd like to chime in - as a verification - of the market in Construction. It's a multi-billion dollar per month industry in every major City. Property and development and investment are where big money plays. REITs and up.
Two things Construction cares about: Safety & Shrink.
Safety in the human cost of skilled labor - and settling workplace claims of deaths on the job / innocent bystanders / loss of property (on and on and on) - is a giant consideration. Claims are more expensive than, well, anything because they're unpredictable. Can technology help? Yeah, but looking at a tablet ain't gonna do it, unless it's like 30 cameras on the job site...which leads to...
Shrink. That's what it was called in the Big Box store. Losses due to theft. It could be something small, or something kind of big. Or maybe somebody on the job site tipped off a local relative with a good crew who have the brass ones to haul off a couple generators if they're not lifted up on a crane over the weekend...again, there's a nice middle ground of disruption for technology, but it has to be grounded in real world learning.
Sketching out a few ideas on a white board will probably not be anywhere close to the 3 years I consulted with Field Safety Managers, Claims Managers, Managing Directors who speak at Conferences to this day...I was the guy who could write it down, put it in images, because Construction people have their own world.
I'll never forget one story a highly accomplished team leader said on a conference call about Safety: "Last week at the new XXXX auto plant, installing a 4 ton brace that was freshly painted, the crew was so worried about scratching the paint that one got jammed between the brace and the wall and lost his life. Priorities are our concern."
TL;DR: Nobody makes a good brisket in a microwave.
I agree with your thesis and would like to anecdotally expand on your second point. It's been my experience that people in the construction industries -- and I say this as someone who comes from a multi-generational family of builders -- tend to be on the leading edge of technology adoption.
For example:
- Quick adoption of pagers, cell phones (originally the physically installed "car phones", later, Motorola's "brick"), Sprint's "Direct Connect", to now using iPhone or Android-based devices for on-site visual status updates.
- GPS and RFID vehicle, inventory and tool tracking.
- Computer-assisted design (CAD) and manufacturing (CAM).
Not to mention all sorts of back-office software and tools.
All of these things need to be vetted in light of risk mitigation, as you stated. Most builders I know have been burned multiple times in the past when tools and processes fail, so they tend to hesitate before jumping to the "next-greatest-thing-ever".
> People in this industry resist change because change is risky
I'm researching a similar field, where risk of change is the biggest barrier to improvement. What have you been doing to combat this / how do you reduce the risk? What makes a user willing to take the jump?
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.
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.
Well of course remote work is going to have its own challenges, but I don't get the feeling that that's what's going on here. So, besides corner cases, is there any reason not to consider cellular tablets in the construction world?
Job sites, especially those in the throes of major structural construction, are a horrible place if you are seeking consistent wifi or cellular coverage.
Generally: The thick concrete walls, exposed rebar, and intentional and unintentional geometric structural elements combine to form a giant Faraday-esque electromagnetic exclusion zone. Even with wifi repeaters on each floor you aren't assured a connection.
I worked for LATISTA as a product designer and spent a significant amount of time on-site speaking with users about this exact problem. It's getting better, especially with the larger construction management / development firms, but it's not a solved problem (unless your firm spends a significant amount on portable IT infrastructure).
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.
They don't have to be "equal" in any sense. All that matters is whether they meet some (probably ill-defined) threshold of reliability. In at least some circumstances, neither does, even if cellular gets closer.
OP. Yea, that was interesting on my end using chat. I probably would hate that on your end as much you did. I did have some pretty fun conversations though. I removed it, because that got exhausting.
