How to Add Reviews to Bubble: Nothing Grows on Its Own

Bubble is an application builder, and that one fact explains the only real difficulty here. On a website builder a section grows to fit whatever you put in it, so a review list of any height just works. Bubble does not think in documents. Elements have coordinates and dimensions that you set, and an HTML element sized for three cards will show three cards and cut off the fourth. The widget is fine. The box is the problem, and it is a problem you have to fix on purpose.

The HTML Element

Drop an HTML element onto the page where the reviews belong and paste the embed into it. There is no code view to toggle and no escaping to work around, so the snippet goes in exactly as copied.

It is a normal Bubble element in every other respect. It has a position, a width and a height, it participates in whichever layout container it sits inside, and it can be shown or hidden by conditions like anything else on the page.

That last part is occasionally useful. A reviews element that only shows to logged-out visitors is one condition, and it keeps the signed-in view clean without maintaining two pages.

Height Is the Whole Problem

Give the element enough height for the layout you picked, or turn on the option that lets it stretch to fit its content. Without one of those, the element renders at whatever size you drew and anything taller than that is simply not visible.

This produces a very specific symptom that looks alarming: the first two or three review cards appear and the rest are gone, or the last card is cut in half. Nothing is broken. The widget rendered completely and the container is showing part of it.

Stretching to fit is usually the right choice for a reviews section, because review text varies in length and a height that works today can be wrong when somebody writes a long one. Fixed height suits a compact badge, where the content is predictable.

The Responsive Engine Is Doing Its Own Thing

Bubble arranges elements through containers with alignment and spacing rules rather than by document flow, so an HTML element sitting loose on a page and one inside a properly configured container behave very differently as the viewport changes.

Put it in a container with the rest of the section. That way the reviews move with the content around them instead of drifting over or under it on a narrower screen, which is the other common failure and one that only shows up when someone opens the page on a phone.

Check at least one narrow width before calling it done. A widget stacks taller on a phone than on a desktop, which interacts directly with the height decision above.

Landing Page, Not the App

Most Bubble projects contain both a public landing page and the application itself behind a login. Those are different audiences and the reviews belong to one of them.

Public reviews argue for signing up, so they belong on the landing page, the pricing page and anywhere else an unauthenticated visitor can reach. That is where somebody is deciding whether the product is real and whether other people have found it useful.

Inside the app they are dead weight. A signed-in user is trying to complete a task, and the space would be better spent on almost anything else. If the same page serves both, hide the element with a condition on logged-in state.

How Do You Build the Widget?

Paste your Google, Trustpilot or Facebook profile URL, preview your real reviews and rating, then choose from over 100 layout styles across the slider, marquee, grid, list, masonry and badge families, and set the colours to the app palette.

Favour a predictable layout. A slider or a fixed row has a stable height that is easy to size a Bubble element around, whereas a masonry grid changes height with the content and needs the stretch option rather than a drawn box.

The header rating comes from the platform aggregate rather than from the cards on screen. Free plan, unlimited widget views, so a landing page that gets posted somewhere busy costs nothing extra.

Where Should the Reviews Go?

On the landing page, after the section that explains what the application does and before the sign-up call to action. Evidence needs something to be evidence about, so it goes after the explanation.

Add the same element to the pricing page if there is one. Pricing is where hesitation happens, and a rating there answers a question the feature comparison does not.

Do not put it inside the application. Use a condition on logged-in state if a single page has to serve both audiences, so the reviews reach the visitor who needs them and disappear for the user who does not.