Large forms with custom UI. Best practices needed!

I have to build a lot of web forms with validation, on-the-go calculations and stuff like that. And it was going well when I used standard Bubble elements and worked within their limits.

But now I have to use this design system. And I guess it’s a very well documented system with good code. But it looks like it doesn’t make a bubbler’s life easier.

Take an ordinary checkbox
2018-07-28_14-01-01

There’s no native control in Bubble that allows adjusting the style of the checkbox’s box. I’ve tried adding a JS to the header that transforms the style, but the result looks bad and is different across browsers and devices.

I ended up using HTML block with these checkboxes, pushing onclick data through Toolbox plugin to Bubble and loading the data back using JS action in the workflow. It works, but not feasible and is a pain to support and update: I had to write a few pages of custom JS just to make a stupid group of checkboxes work.

Then, an input. What could be easier? But in my custom UI I have to do a dotted frame around on focus and some extra elements just for the validation:

Well, I recreated everything on Bubble’s native elements. Now every single input requires to be in a group with other 5 elements each with its own custom states:

Now imagine having a form with 20 inputs like this mixed with 3 HTML blocks of checkboxes and radio buttons, each with custom JS. Imagine a workflow to validate and submit this form. Do you feel my pain?

I don’t want to believe the experienced bubblers do this. There should be smooth and smart ways. I’ll appreciate if you share your way to build large web forms with custom UI.

1 Like

It sounds like you have a pretty good command for design and programming. It’s just a matter of translating what you know into Bubble structure.

Generally speaking, when you’re looking to apply a design system - that also includes contextual elements (ie. an error message or coloring an external element) - you’ll use a combination of styles and conditional formatting.

Most of what you’re doing (when the element is focused, is valid, isn’t valid) can be defined directly as part of a reusable style associated with the given element. Then, for error messages, you will create a condition to the effect of “when input A’s value isn’t valid this text is visible” Same thing goes for a border color on a group.

Whether you are building in Bubble or another platform, you’d likely contain all of these elements within a div (group) so they are contained together. That ensures all the elements work as a group (ie. help text appears in-line with the element(s), coloration matches up with the associated element(s).

Dan (creator of LearnTo, it’s like Netflix for learning Bubble)

1 Like

Thank you for you answer!

Right, that’s exactly how I ended up to work with inputs. I don’t like this mess, but it works somehow.

But I have no idea what to do with checkboxes and radio buttons. As I mentioned, I can’t style them with Bubble and HTML+JS+Bubble mixing approach seems to be infeasible (and it’s not no-code anymore, which was the whole point).

Ah, yeah, taking a closer look, I can see the pain for radio buttons and checkboxes.

For the radio buttons and checkboxes, if you need to emulate the style of those components, you can build it as a custom reusable element. And in this case, you would want to use a custom state (for setting the value of the thing; potentially another for other functionality).

Using the US Web Design System checkbox, I built a quick proof of concept for you so you can see how you might do it entirely within Bubble without having to use custom code. Feel free to copy it if it works for your purposes. (Note: there’s still more you’d want to do to fully emulate - ie. setting up a not-clickable state).

2 Likes

Thank you so much for your help and for your demo! Using stacked groups with customs states inside reusable elements seems like a good approach to manage large web forms based on a design system.

Unfortunately, It will probably not work for me. The thing is accessibility is the important part of this design system. Users have to be able to fill out the whole form without using a pointer (just with a keyboard). And to support it I need an onFocus state so I can highlight the focused element (e.g. checkbox) and then change it’s state on pressing Space.

Right now even if I can catch your checkbox with tab, I don’t understand how to style this dotted selection and “on press Space” I’ve got the page scrolled (and have no idea how to catch this onPress Space event to check this custom checkbox).

Do you have any ideas?

Can you send a link to an example in the US Digital Service documentation where they require use of keyboard only? For accessibility sake, I can understand why they may say no pointer. But it does make things difficult.

Bubble does has a set focus action. However, as you might expect, it is only accessible for inputs.

I think your request highlights an accessibility gap that’s worth solving if feasible on Bubble’s end. As a next step, I think it would be worth asking the Bubble team to expand stylization of the checkbox input within the Bubble editor (similar to how you would style any other input).

Let me know if you agree and I’ll make the suggestion.

1 Like

As they say here:

All of our designs meet the WCAG 2.0 AA accessibility guidelines and are compliant with Section 508 of the Rehabilitation Act

Then, if you follow this link and check WCAG 2.0 AA:

Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.

So once we go with our walk around with groups in reusable elements instead of checkboxes we are not AA compliant anymore (and there’s a number of people that will never be able to fill out our form). But the whole point was to make a truly accessible UI.

I agree. That would be fantastic if you make this suggestion on the accessibility gap.

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.