31–40 of 79 posts
Earlier quoted context omitted.
But then how would you support choices or conditions for example?
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
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…
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.
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.
> This style of form is aggravating to fill out, In what sense? 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.
> In what sense?
You just answered your own question.
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.
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.
Not the case here though.
This is more like a DSL with Markdown embedded for the textual parts, but still cool. An actual Markdown syntax extension for forms would be interesting. [_____] for text fields?
My user test: https://www.loom.com/share/9287cfe4e7024330bfe752ef8b9ad9bd
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.
Yes, but he's very close to the obvious solution that will spark web 4.0.
Closest I've seen yet.
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
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.
> uncanny valley Yes, but he's very close to the obvious solution that will spark web 4.0. Closest I've seen yet.