Very good work, especially for a solo developer. Feedback:
1. Design language of the forms feels too much like Typeform, you're a talented designer: differentiate the design to establish your own identity. If the forms look like Typeform, form-fillers are not going to investigate what form software it is and use it -- which was a big part of why Typeform grew.
2. The name is terrible. Blocks? The name sounds like you decided on it for a different project (some sort of component framework using Markdown?) and then reused it for this. The domain forms.md is available to register. Anything that include "form" in the name would be a significant improvement.
> differentiate the design to establish your own identity.
But maybe the Typeform design i not very original, too. Maybe it makes sense to use some design that is rather neutral, easy on the eye, automatically recognizable without an effort to parse.
I see a commendable humility in picking a clean, usable, not catchy rendering. What's original here is the form language, which is actually the centerpiece. And frankly, I wish the code examples were more colorful, bringing attention to the keywords and separating them from the static text runs. It would help understand the language structure easier.
1. Yeah I would say this was intentional. Typeforms are almost instantly recognizable, which is a good thing for a new product I think. I actually want to offer more than one form style though. If you look at the CSS file, everything is a variable so that I can add more styles/themes.
2. Haha you're right actually, the idea was slightly different and the name sort of stuck (it was originally blocksdb, which is worse). I don't mind blocks.md though, but marketing is definitely not my best skill.
It says Business Source License 1.1 which basically means I’m free to use as long as I don’t use it to build a competitive offering. Fair enough.
But it changes to AGPL-3.0 on 2028-07-01, what? Basically now I need to open source my entire stack that has any connection to the form? Why would you change it to a more restrictive license (for anyone not looking to build a competitive offering) after a few years?
---
Unrelated, I find the DSL increasingly unwieldy as you get to more advanced features (especially styling). Might want to consider offering a JSX/TSX alternative for more advanced use cases.
So I did not want to open-source yet, which is why I picked BUSL-1.1, and from what I can tell, the other BUSL-1.1 I've looked at had this clause to open-source at a later date (AGPL3 is an open-source license after all).
I'm still trying to figure out the licensing around this whole thing, so this is temporary I believe.
IANAL but from what I understand, folks will be able to use the current version of the software as it is currently licensed, forever. The author is making clear their intent to change the license on a certain date, at which point new versions of the software will only be available under AGPL.
I agree it's odd that folks who use this software something that isn't a "competitive offering" may have to open-source their software stack if they upgrade to a new version in 2028. But, they will always have the option to use an older version of the software that is still covered by the BSL.
No that’s not how these license changes works. The current version is licensed under a source available license until a certain point in the future when it’s converted to an open source license, so people can use the by then possibly very outdated version freely. Or they can upgrade to the newer but still source available version if there is one. It’s meant to be an assurance that in case the business is gone by then, you the user and/or customer can still patch it yourself or rely on a community fork to keep it working.
Except here thanks to the AGPL choice, it seems to be the exact opposite of an assurance: if you use this in a proprietary setting, you’re just fucked if the business is gone and the software needs patching.
If you obtained the version you have under the current license, you can not be held by the more restrictive terms when the license changes at a later date, even if the owner changes the license on the current/older versions rather than just using the new license for new versions.
This isn't like a service where they can try force you to agree to an updated EULA with some "by continuing to use this service…" crap, or a rented device like a "smart" TV that can effectively do the same by refusing to work (though technically you've already agreed to that with a "we can fuck you over at a later date" clause in previous click-through agreements.
The license is one thing before 2028-07-01 and another thing afterwards. That’s the license you get right now, they’re not changing it after the fact. To put it more accurately, there’s no license change in the future, it’s simply one license with a set of terms before a certain date and another set of terms after it, they’re only calling it a license change because the set of terms afterwards constitute a well known license. Contracts like this are absolutely valid. If it still doesn’t make sense to you, think of a trial license.
Ah, I'd misread the comments and assumed it was an actual license change that was planned. Having actually read the LICENSE file on GitHub I have to agree. Mixing the two into one like that basically means you agree to the worst of both options.
I have nothing against AGPL, in fact if I relase anything I'll probably use it, but if I did dislike it, which some very much do, I wouldn't tough this with a bargepole even years before the change.
This style of form is aggravating to fill out, but kudos on making it beautiful.
If you want to be kind to your users, allow them to scroll through the entire form, see it on one screen and ideally skip ahead without filling out required options but block submission.
I suppose for me it kind of matters how many questions are being asked. I'm fine with this UX if it's a specific question or two, but for a whole questionnaire with 14 questions or more, then I'd also prefer to be able to get an overview first.
I want to see what I'm getting my self in for so that companies/entities can't trick me into filling out a questionnaire with 50 questions in that, "Will only take a minute!" It's easy to get people to get answer enough questions that they reach the point that stopping now would mean everything they've just done is a waste of their time, so they keep going. It's abusive.
Give me everything up front and let me decide if I have the time to commit to that.
You can actually have more than one form field within the same slide. I haven't made that very obvious, but one of the advantages here compared to Typeform is the flexibility.
name* = TextInput(
| question = What is your name?
| description =
Let's get started with the survey. First, please tell
us your full legal name according to your passport.
)
Could be just this:
name* = TextInput
# What is your name?
Let's get started with the survey. First, please tell
us your full legal name according to your passport.
Well, you can define the syntax however you like in a new DSL, right?
I like the syntax notpushkin proposed and would extend it a bit like this:
fruits* = MultiChoiceInput
# Pick two out of three fruits
Fruits are healthy, so let's pick two fruits
you will eat every morning for the coming week
- [ ] Apple
- [ ] Orange
- [ ] Banana
Whats the appeal of Markdown anyway when we are not using Notepad? My ide has same number of keystrokes for `<h3>` and `###`? Might as well go all in on JSX.
You forgot to close your h3 tag, so 2x. Changing it is also more keystrokes
Most non technical people are comfortable writing markdown, especially when there is a rich text editor. They are not going to write JSX. Markdown is focused on the textual content, not the presentation
Yeah I'm curious if the Markdown form syntax here is totally new or if other people have done something similar. I'm building an app that extends Markdown with Excel-like formulas (think function calls, not arithmetic) and have considered having formulas that instantiate form elements.
Yeah, is anyone familiar with other DSLs for form/survey building and logic?
For my work, where we produce lots of surveys and reuse parts of them/run near duplicates monthly, I've been curious to see if there's any dual code and GUI options out there to allow for survey programming to be version controlled and forked, etc.
That's a client library for interacting with now defunct Typeform I/O, so it won't work anymore. But maybe the DSL itself could be an inspiration, or you could wrangle a fork of the library to create the forms locally.
I feel like this falls into an uncanny valley between requiring the skill to cognitively model forms in your mind as text, which is fairly close to coding and using a form builder UI.
P.S. You can just write "tahmid.hm.dev@gmail.com". Gmail spam filter is good enough to eliminate automated spam, and also nowadays verbalization provides no additional protection against email address crawlers ;). Might even be the opposite ;)
Any and ever form submission, no matter how simple or complex, can be represented as a single file encoded in Particle Syntax with semantics provided by the Parsers programming language.
Thus, any one filling out any form, no matter how complicated the form (tax returns, electronic medical records, mortgage applications, LSATs, et cetera), could in theory type the form in a single plain text document encoded in Particle Syntax, OR use an HTML multi input form which generates that text document under the hood, or a hybrid of both, since they are isomorphic to each other.
Are there any such solutions/standards available? Tried searching Particle Syntax documents, nothing came up. That's exactly the sort of problem I'm working on now
Yeah, it'd be great if over time they/a community provided a system for visualizing the form logic and a form builder GUI so you can go full-circle with this (building via code and GUI and saving/versioning/forking forms via source).
nice product. but prohibitively expensive. 60$ and even more concerning "Varies" price for actual use is pretty much no-go for this product.
if you are small startup this is too expensive, if you are big company, you might as well built it yourself. got to be cheaper!
UPD: typeform charge more but they provide hosting and analytics, very convenient for people who don't want/cant to code anything. this library is "bring your own backend, analytics, etc.", need coding too, but prices are nearly same ballpark. too expensive.
Hmm I'm still trying to figure out pricing. The "Varies" Enterprise option is just there so people who are interested and I can have a proper chat because the product is so new. Definitely not a typical sales call, although I haven't done a good job to explain that.
Hey builder of this thing here. This blew up like crazy! Thanks for all of the feedback everyone. I'll try to reply to all of them, I think most of it is very valid. In case someone wants to reach out for questions, my email is tahmid(dot)hm(dot)dev(at)gmail.com.
Looks interesting, but I’m having a hard time seeing why a team would adopt this over something like MDX. A comparison page between the two would be great!
Great alternative. I'm the founder of Buildform.ai which is an AI first typeform alternative. With buildform, it's faster and easy to build high-conversion conversational forms and analyze and use the data you collected.
Hey, really appreciate this user test. Like I mentioned in another comment, I would love to catch a chat with you if you're interested: tahmid(dot)hm(dot)dev(at)gmail.com. Thanks again for taking the time to make a video.
why would someone self host? There is always resistance in managing server on our own.
So only people will buy such self hosted typeform alternatives are maybe the one who are using typeforms at scale, large businesses.
1. I don't understand why there's a pricing model for some CSS on forms. if I'm hosting the form & submission endpoint why do I need your backend (? not even sure what your role is here)
2. why not make it into a selfhosted typeform alternative; would be cooler than this saas bs
Looks nice! I was using typeform to collect surveys but found the UX weird so I switched to Google Forms. Found we got more conversions too, it's just simpler to use. The one thing missing was I wanted a way to redirect someone after they completed the form. That wasn't supported so if there is anyone else in a similar boat, I made this (free) service: https://www.gfrdr.com.
This was the easiest and quickest to start with. I don't know about MoRs' reputation in general, I saw Tailwind using Paddle so figured I would too. By the way, I applied to Lemon Squeezy as well, but their verification process made me wait 2 weeks and then asked for an Instagram account, which was crazy because this is such a techy nerdy product.
I was mistaken on their pricing, but making your customers pay 5-25% more even though you have no nexus in 99% of jurisdictions will still hurt sales to a significant degree.
And you think they’ll keep you as a customer if chargebacks are at all an issue for you?
1. Design language of the forms feels too much like Typeform, you're a talented designer: differentiate the design to establish your own identity. If the forms look like Typeform, form-fillers are not going to investigate what form software it is and use it -- which was a big part of why Typeform grew.
2. The name is terrible. Blocks? The name sounds like you decided on it for a different project (some sort of component framework using Markdown?) and then reused it for this. The domain forms.md is available to register. Anything that include "form" in the name would be a significant improvement.