Yes/No question as a Radio button

[orlando]

Problem you are facing

Right now Yes/No questions are rendered as a checkbox. If you need to require an answer for a question from users specifically answer No, we can't.

Possible Solution

Instead of rendering these as Checkboxes, we should render them as Radio buttons.
Ex

Context

Have a Yes/No question rendered as a Radio button

Some questions we need for users to explicitly answer either Yes or No

[rixx]

Sorry, but that won't be useful for other cases, such as [x] I accept the terms and conditions.

Instead, please create a choice question with the options "Yes" and "No" if you want to permit both options. They will render as radio buttons.

[orlando]

@rixx I tried that but was rendered as a dropdown. I'll double-check to see if there's an option to make it as a radio button.

Also, this can be made as an option instead of changing the behavior. I should have added that detail to ticket

[rixx]

My mistake, it seems you are right! I think offering Radio inputs is better UI in nearly all cases here, so let's do that by default on "Choose one from a list" questions.

[orlando]

Thanks! @rixx. Well not nearly all. We are adding a Country of Origin question that requires to be a dropdown. Radio buttons will break the UI for sure. I believe this needs to be provided as an option instead of by default

[rixx]

That's a good point, but I still disagree on the additional setting. Settings fatigue is a thing, and I'd rather provide a sensible default than force users to configure a bunch of things like these. I think displaying up to three options as radio buttons, and anything over that as dropdown seems sensible.

[benabraham]

@rixx As a UX designer I agree, that sensible default is a great thing. But you have to be sure you’re making the right choice for the users. That is not easy. If you’re not sure, please let users decide what they want to show in their form and don’t force your opinion on them.

There is no rule in UI design that anything over 3 items should be a dropdown. Yes, there are situations when it’s the right choice but there are many more, when much more items can be shown and it’s a better design choice for the situation.

Google Forms for example has exactly that choice (and many others) and I don’t see it as a cause of setting fatigue. It‘s well designed, icons help with understanding, there are sections…

As a developer I understand that your solution is much easier one. But that doesn’t necessarily mean the best one.

Just my 2 cents.

[rixx]

Please avoid commenting on issues that have been closed for four years. If you want to change something in pretalx now, please open a new pull request stating your problem in the current UI plus potential solutions, and if past issues are relevant to the discussion, refer to them in the new issue.

[benabraham]

Thank you for your reply and sorry for not being clear about my intent with the comment which was posted to express my view and may be make think about it for a while. I haven’t expected to change anything.

This issue was the only thing that I found when I was looking for explanation why some form fields are radios and some dropdowns and how to change that.

I know how OSS works but I have a community conference to organize with CfP launching in days which means I don’t have time to take on more work and PR isn’t probably a way to change anything quick enough, so it would matter to our event.

[rixx]

I haven’t expected to change anything.

Ah right, sorry for the misinterpretation.

I know how OSS works but I have a community conference to organize with CfP launching in days which means I don’t have time to take on more work and PR isn’t probably a way to change anything quick enough, so it would matter to our event.

Sure, when it's very urgent, I can't guarantee that a PR would make it in time. However, you can always choose to create a fork, where you have full creative control. :)