This is a bit of a challenge in Bubble (actually in any app, platform aside), ain’t gonna lie. The issue is you have to abstract the “things you can customize” and then, depending upon the widget the user wants to customize, present the appropriate editing interface.
Consider that in GRUPZ, as an example, the things you can customize for a Calendar Widget are WILDLY different from what you can customize for a Booking Widget. It’s kind of impossible to make one page work for both without UI compromises that negatively impact both.
Now that GRUPZ is powered by my Calendar Grid Pro plugin, there are many new options that could be made available for calendar widgets, and I do have a page (not exposed) that could let users access “templates” of pre-built styles that can be further customized.
But I’ve not yet deployed that as I’m SUPER unhappy with the UI for it. You basically get into building a Single Page App for this one feature. It’s a pain. (And simply not easy to build in Bubble as everything must have a visual component that lives in a layer on the page. This is one area where code vastly trumps visual programming tools. The modularity is just sooo different.)
Anyway, it’s something that is difficult and is not necessary for you to launch your product. Make it work basically at first. Let your users drive where you put your energy and effort after that.
The same would be true in a code-based environment.
Aside: I resisted many customization options at first as I knew users would do stupid things. Then a smart user said, “I’d like to be able to…” and then I added various extra customization options and you know what happens?
The users do stupid shit.
So think about that, too.