Creating Groups as Embeddable Widgets

Hey Bubblers. I’ve been reading up on iframes and that seems to be the best route to take for what I want to do. @keith you’re currently doing something similar with grupz. I’m trying to create groups that can be used as customizable widgets by customers so they can embed it on their website (such as a form, gallery etc.).

So far the only solution I found is to make a small web page and create an iframe doing that. But I want to do that with bubble elements like groups so it can be customized. It seems like I should be placing a div container specifying that specific bubble element but I’m not entirely sure how to do that. Also, when I copied and pasted the code using Chrome’s dev tools into the HTML element it creates an extremely long code.

Any ideas? Thanks.

1 Like

Right. You create your “embeddable widget” in a page like this:

And this becomes the page that your users will iframe (with code that you will create and supply). Viewed on its own, such a page will look like this:

(Here’s the actual page: GRUPZ Embedded Vacation Rental Calendar Listing 1533598513737x940983987061391400)

And, embedded as an iframe:

Now, you have to generate the code for your users. In GRUPZ, it comes out like this, for example:

All that css there is to do the little loading spinner. Also, my iframe embed code itself isn’t really fully modern and correct (I’m going to change that soon) so I wouldn’t literally use that as the best model, but you get the idea.

To enable your app to be iframeable, you have to do this:

Note that this is a server setting and all we have control over in Bubble is to allow embedding or not. You can’t control this per-page, so just know that any page in your app is potentially iframe-able.

You will build pages in your app that enable your users to customize their widgets. Like in GRUPZ, there’s pages like this:

And then we create and deliver the code:

As you can see, currently I use a rather long text expression to dynamically fill in values that the user will need. There are slightly sexier ways to do this that result in less ugly expressions, but hey it gets the job done.

The user sees:

4 Likes

Wow, thanks for the detailed explanation! That’s great info and gives me a better understanding. Do you know if it’s possible to use id attributes as an alternative? Like say I have it set up similarly to yours where there’s a list of editable options for the widget on one side and the widget on the other. If someone wanted to to embed that, do you think it’s possible to use a div that uses the id attribute inside an iframe?

Seems that something like this would be an ideal solution. Thoughts?

Well, what you can do (and I left this out before) is design your widget inside of a reusable (or convert your object to a reusable). And then, in your edit page, you can just display that reusable in some cases. But you may have to iframe it – it depends on what data you want to pass, etc., etc. But if you want to not have to iframe your widget in the edit pages of your app, put them in reusables.

I’m not sure what you mean. What you ultimately create is a page designed to be iframeable, that displays your widget properly. You then give the user the code to properly embed it. An iframe just holds a page from some other domain.

How would you go about iframing a reusable element? Basically what I’m trying to accomplish is having a shortcode version much like jotform or elfsight (which I realize us js). I figured iframes would be the best route to go but it seems to me that using the id attributes would be simpler in that regard.

I’m trying to make it so that they can cycle through various widgets on one page, customize it, then receive a shortform code to pop it into their website. iframes will end up displaying a whole page and I only want to display that specific element.

Sorry sometimes I have trouble explaining things clearly. I’m not a super technical person. I hope this helps.

I think once that part is cleared up I should be good to go.

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.

Sound advice and all excellent points. I appreciate it! I was able to get something simple working at least. It’s going to require some finesse on the UI part but it’s a start. Like you said I’ll let the users guide some of the development process and go from there.

1 Like

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