Once you understand them, you can’t help but stand in awe at your newfound power to create powerful and elegant navigation systems for your app, whether it’s a multi page application (MPA) single page application (SPA) or some hybrid of the two.

Let’s start with some fundamentals

The URL is a place where we can store data, just like any other container (like groups and custom states). However, due to the fact that the URL is essentially just one long text string, we have speak to it in text. But that’s okay, text is all we need.

Within the URL we can store data either in the path (as segments, more on those in a moment), or in parameters. These come after your root domain (yourapp.com, or yourapp.com/version-test if you’re in development mode).

Note, we can also store data as anchors which scrolls the user to a particular element on the page (useful for blog posts, documentation etc). We’re not discussing them here, but see Bubble’s documentation for more info.

Paths are easy to read, favourable by SEO, and have a natural hierarchy to them, like folders or files nested inside of folders. They’re suitable for storing information about what the user should be seeing (i.e. the view/page). The order in which they appear is important, and having too many can make your page navigation overly confusing.

Parameters don’t have a natural hierarchy: each one is a standalone nugget of information, made up of a key (it’s label) and a value (the information). This means you can add an arbitrary number of them in any order, which makes them are suitable for storing information (variables) that the page needs to operate.

In the example below from Mailerlite, the path, subscribers, is telling us what page or view we’re on, while the parameter, status, is being used to filter a table on the page.

If I use a dropdown on the page to change the filter from active…

to unsubscribed….

… then the URL parameter changes accordingly.

Alas, parameters are a conversation for another day.

When it comes to paths, we store these as segments; individual pieces of information separated by /. So a path can be made up of a list of segments.

In the example above, we’re on the page p, and then within p, looking at a particular article, retrieved using demystifying-url-paths.

Alright, but how do we actually deal with these path segments in Bubble?

URL paths in Bubble

In order to retrieve any data from the URL, we use get data from page URL.

When we do this, we get several options.

If we choose path segments as list, this returns a list of texts, where each item in the list is a path segment.

So in the case of blog.mattneary.co/p/demystifying-url-paths, this list would be:

1. p

2. demystifying-url-paths

Since, unlike parameters, we can’t identify a path by a key value (a label for that data, basically), in order to access a particular segment, we must grab it by it’s position (it’s index) in the list.

As you can see above, the first path segment is always the page name. It’s populated for us simply by virtue of being on a particular page. Each segment which follows we must push into the URL ourselves (we’ll get to how to do that shortly).

What about grabbing just the ‘path‘?

Now, as an extra complication, Bubble actually gives us the option to grab, not the page segments, but just the path.

You might expect this to be the first segment in the URL, i.e., the page name (setting, in the example above). But, it’s not.

If you grab the path from the page URL, this is the same as path segment #2.

To grab the page name, you either grab path segment #1, or use a different expression: current page name; just note that you can only access this expression from within a reusable element.

Populating the URL with path segments

Finally, to actually populate the URL with such paths, we use the go to page action, sending the URL paths in the data to send input.

Having elements react to changes in the path

We’ve already seen how we can extract URL paths using get data from page URL. From here, it’s simply a matter of constructing expressions that utilize them.

Conditional logic

To add conditional formatting to the buttons, we can simply extract the path (or path segment number x) and compare it to some other value.

In the above example, I’m manually typing out “profile“, but what you really should be doing to avoid duplication is storing value in a single place that you can then reference everywhere (like in a group acting as a variable, or in an option set). I’ll elaborate on this kind of setup in a separate post.

The same principle as above can be used to display the content on the page which corresponds to the current view. And thus, within-page navigation is born!

Extracting URL paths as data

Now, with the setup above, we’re extracting the url path as text. But Bubble also lets us pull it out as any data type.

Yet if, at the end of the day, all we have is text in a URL, how does this work? How do we go from text, to say, a product?

To demonstrate, let’s look at the following products page. We’ve got a repeating group of food products. Clicking one of the products pushes that product’s unique ID into the URL

So the path segments in text form at this point are:

1. products

2. [some-product ID] (i.e. 24234234233x23453242324

If we retrieve the path segments as a list of products, not texts, what happens?

As you can see, we’re retrieving two segments from the URL here (products and [some-ID], but only one of them is being recognized as a product.

For the segment that Bubble does recognize as a product, it automatically retrieves that product from the database, using it’s unique ID to locate it1. It then returns that product in place of the path segment. Since only one of those segments actually is a product ID, only one product is being returned.

If we were to hack the URL, as it were, and add a third path segment consisting of a product ID, then two products would be returned.

This means that you can pull, as it were, entire objects from the database from the URL and use them to populate containers on the page.

But, you might say, I thought the whole point of URL paths was that they looked pretty? Now you’re telling me I gotta look at this ugly unique ID?

Not if you don’t want to.

Rather than pulling objects in using the technique above, the approach you’ll more likely want to do is push an objects slug into the URL (cause they look pretty) and then simply do a search for that object, using the path slug value as the search constraint.

So this is the fundamentals of URL paths - but we’re really just scratching the surface on what they can do. By stacking different paths, we can build some quite powerful and intuitive app navigation structures. Stay tuned for more guides on how those work!

If you’re still hungry for Bubble educational content:

Check me out on Youtube, where I frequently publish free Bubble tutorials.

Or, if you want a comprehensive, zero-to hero introduction to Bubble, my flagship course, Think it, Build it, is for you. Enrolment opening end of October!

So as it turns out, a weekly newsletter while finishing off Think it, Build it is out of the question.

Alas, I do have something prepared this week.

Tidbit of the week

Stripe are so awesome. Did you know that every time you charge your user, they create a receipt?

It’s saved at a special URL, which unfortunately isn’t returned in the native Stripe plugin’s charge action.

However, if you simply save the charge ID, and pass it along in a GET call to their charges endpoint, you can save it in your DB and link you users to it (like in a table of their payments)!

The problem with giraffes

The giraffe is a marvel at the power and elegance of natural selection. Nature basically did a bunch of A/B tests on different neck heights, over and over again, for millions of years, and poof, Giraffe.

And yet, the Giraffe is also a terrifying example of technical debt.

If you cut open a Giraffe’s neck, you would find the laryngeal never. It’s job is to carry signals from the brain to the larynx, to coordinate things like making sounds and breathing. The distance, from brain to larynx, is a matter of inches. A simple, short wiring job should do. And yet, in Giraffe’s, the nerve leaves the brain, goes all the way down the neck, loops around the heart, and double’s back on itself before connecting up to the larynx; a distance of metres, not inches.

The ridiculous detour is a product of the fact that evolution can not go backwards. Giraffes, like all mammals, evolved from fish-like creatures, where, owing to their lack of neck, the nerve could easily hop from brain to larynx. But it happened to do so behind another nerve connected to the heart. And so as evolution produced mammals, some with necks longer than others, this nerve stretched, as it were, to accommodate the advantages longer necks gave.

The laryngeal nerve exposes one of the downsides of evolution - it can’t go backwards.

It’s tempting to think of our development process like evolution. We’re discovering the right product for the market by making small adjustments to what we already have and then putting that new version in front of users.

From a business perspective, this is a no-brainer, especially with no-code in our back pocket.

However, as the laryngeal nerve tells us, as any system evolves, it’s foundations, the early decisions, lock us in to certain design decisions down the track, lest we embark on a complicated restructuring exercise later on (otherwise known as refactoring).

This is where, as engineers, we have a distinct advantage over natural selection: we can predict how things might evolve.

This doesn’t mean spending hours projecting multiple scenarios. It’s more a matter of asking ourselves simple questions while we set things up to give ourselves maximum flexibility later on. Things like?

• Are there likely to be more user roles than just admin? Consider making them a list of roles (stored as an option set), rather than a number of individual yes/no fields

• Are we going to use the same design for this informational popup in several places? Consider making the alert element a reusable element and populate it’s text fields using a custom event.

• Is the commission our app charges on each transaction likely to change? Then don’t hard code the value in your charge actions, but pull it from an option set

Does this mean we should get the whiteboard out and brainstorm all the possible ways our app should evolve?

Of course not. As with any strategy, planning has it’s limited. You are always dealing with incomplete information, which makes striving for the perfect scalable solution impossible, and likely to waste your time.

But, it does mean making a habit of asking at the outset of each new project or feature, “how could this evolve in future“? Likely there are some low hanging fruits, some particular ways of setting things up, that will make your life much easier in future, but require no, or little extra work now.

If you want to get more Bubble related content from me:

Check me out on Youtube, where I frequently publish free Bubble tutorials.

If you’re a non-technical founder looking for a step-by-step guide to building your app on Bubble, my course Think it, Build it is for you.

Enrolment is currently closed until October, but sign up to this newsletter, and I’ll be sure to give you a bell when it opens!

Subscribe now

G’day everyone.

In this first edition of my newsletter, I’m giving a brief history of my Bubble journey to date.

But first, some trivia.

Tidbit of the week

It’s incredible how so much of thinking can produce so little, and so little thinking can produce so much.

We’re all familiar with this icon.

How do you think the famed hamburger icon came about? Perhaps a world class design team hired by Apple to imagine the future of computing ran a design sprint?

Nope. It was created on a whim by Norm Cox, lead engineer on the world’s first graphical computer interface (the Xerox Star).

He designed it to look like a bunch of stacked tabs. And in his words:

I probably did that at 8:30 at night on a Tuesday and never thought twice about it.

So, the next time you’re overanalysing a logo, a tweet, or anything, think of Norm.

On with the show.

Subscribe now

In 2019, Emmanuel Straschnov (co-founder of Bubble) came to host a small roundtable chat in Amsterdam.

He was there by mistake.

The organizers of TNW, a big tech conference featuring faces as diverse as Reddit’s CTO and Will-I-Am, had got Emmanuel confused with some other founder.

At any rate, I was there by mistake too. Emmanuel’s roundtable had been booked out, but damned if I was going to miss my chance to talk with one of the founders of Bubble!

As the roundtable went on, it was clear there was a bit of scepticism in the room. Code does a great job. How could a tool like Bubble possibly compete with it?

Emmanuel was undeterred. His conviction was that code was hard to learn and as a society we’re obsessed with teaching everyone to code. But there’s an alternative path.

Rather than pumping out more coding bootcamps and the like, why not change the tools we make software with so that they’re easier to learn?

By doing so, many more people would be able to build software, people who otherwise would never do so.

Emmanuel didn’t know it, but he was talking exactly about me.

A lucky break

I think we all remember that moment where we fully appreciate the power of Bubble. You add an input to the screen, setup a workflow to save it’s value to the database, and pull that value back out to display on the page.

It’s a simple operation. Boring even. But when you don’t know how to code, seeing that value appear on screen and realising that you alone programmed it is exhilarating.

For me, that moment came in mid 2017. I had dropped out of university 6 months prior, and was trying my best to live up to the college dropout who starts a million-dollar company persona. I had a big idea for a blockchain-powered peer-to-peer education platform, and zero experience or skills for how to create it.

I was naïve, but eager. And by sheer luck, one of my desperate Googling sessions uncovered a blog post about Bubble. The title probably said something like build apps without code, and that was enough.

I realized that despite our chronic lack of technical skills, I could build our MVP with Bubble. I was hooked.

As luck would have it, our big audacious idea ended up winning a €50,000 grant from the European Commission.

All of sudden we had a dream scenario. Enough money to pay ourselves full time to work on our startup, and the ability to quickly prototype ideas without any outside help.

What followed was essentially a paid internship in Bubble development. We spent our days coming up with stupid software ideas, building them, and then trying to get people to use them. We were entrepreneurs in search of a business. All the mistakes one could make, we made them.

When we inevitably ran out of money and decided to call time on the startup, I had a year of experience building stupid apps. So I did what anyone would do.

Build stupid apps for clients.

Apprenticing under the best in the business

Ask me now if a Bubble developer is a real developer, and I will argue vehemently that they are. But back in 2018, even while building apps professionally, I was scared to call myself a developer publicly. Real developers code, right? What I was doing was cute, but it wasn’t real development.

That attitude only started to fade away once I started working with people who, in the Bubble world at least, were the real deal.

Gaby, from Coaching No Code Apps, is a true OG of the Bubble world. My professional development career really started once I started working with her, spending a few days a week building functionality in her clients’ apps.

Also at that time was a short spell making tutorial videos for Zeroqode templates, another big name in the Bubble world. It was challenging work. My job was to reverse engineer their templates, figure out how they worked, and then create video tutorials on how to use them.

As anyone who has built from a template can tell you, it’s sometimes easier not to use one at all. Often by the time you’ve worked out how the template works, you could’ve just built the same functionality from scratch.

Yet for me, this was another learning opportunity. I got to see how a professional Bubble agency designed apps. To this day, I believe that reverse-engineering templates is one of the best ways to improve your Bubble skills, provided you have a strong footing in the fundamentals.

Taking this development thing seriously

Things started to properly take off once I joined the Airdev partner program. For those of you who don’t know, Airdev are the largest Bubble agency worldwide. Their partner program was still in it’s infancy back when I joined in 2019, but already they had solid systems in place.

Airdev were ahead of the curve. They had a streamlined process, modular components to build from (in the form of their Canvas template), and coordinated handoffs between specialized roles (designer, QA, and developer).

This experience opened my eyes to the real potential of Bubble. We had no shortage of clients, and they were genuinely thrilled with what we were able to produce in such a short amount of time.

Before long I was offered the chance to work as a product manager (PM), a role that there was increasing demand for. Back then, the PM role was also a sales and design role. We’d be the first face a client sees, and if we managed to convince them to hire us, we’d go ahead and scope out their app requirements, including wireframes, before project managing the build itself.

That role exposed me to a wide variety of different clients and projects, from budget conscious sole-founders launching their first MVP, to seasoned business people hiring a team of devs on retainer to build and maintain enterprise level software. I worked on everything from fintech apps, marketplaces, SaaS apps, and internal project management tools.

Teach a person to Bubble, feed them for a lifetime

Change was afoot again. My journey had started out in education, and I maintained a jealous glance at anyone doing education-related dealings. So when I learned that Airdev ran a cohort-based course training people to become junior Bubble developers, I put my hand up to help.

In a previous life, I worked in video production, and so I put that skillset to use creating a full online bootcamp in Bubble fundamentals.

That bootcamp has done super well, with over 8,000 enrolments, and a large chunk of current partners having gone through it.

Off the back of the bootcamp, I took a role with Airdev as head of learning and development (yes, it was just me in the department). This was more of a strategic role than anything else, figuring out how to improve the training and ongoing education of our growing pool of developers and product managers

In wearing all those different hats, I learned an absolute ton, both about how to build performant, scalable Bubble apps, but also about no- code app development in general; how to scope apps, coordinate projects, manage client expectations, and train new developers (I’ll share my top learnings in a future newsletter).

Nonetheless, I still had the itch to try something on my own, and that’s where I find you now.

The present day

The last months have been a bit tumultuous. I started creating a huge Bubble course, had a baby, and moved house (twice!).

As of right now, I’m mostly focused on getting the course released. Then I’ll plot my next moves. That said:

If you want to get more Bubble related content from me:

Check me out on Youtube, where I frequently publish free Bubble tutorials.

If you’re a non-technical founder looking for a step-by-step guide to building your app on Bubble, my course Think it, Build it is for you.

You can get early access right now for $79, which gives you immediate access to over 18 hours of lessons + lifetime access to the full course once it’s released.

Just note that early access will only be open for one more week. Otherwise you’ll be able to grab the full course in October for $179.

Bubble’s new responsive engine is really based on just three things:

Layout: The high level pattern for how elements arrange themselves

Offset: (gaps, margin, padding) Granular adjustments to the position of elements within the layout

Sizing: How much space elements should take up in the space afforded to them by layout and offset

Layout, offset, and sizing. That’s it.

They all dance together, resulting in beautiful, fluid pages. But their tight choreography can also make it hard to figure out exactly what’s going on when things aren’t behaving as expected.

We’re going to break them down one by one, but first, some definitions to get us all on the same page:

• Parent: High level container (relative to children)

• Child: An element inside a parent container

• Siblings: One or more children

We’ll be using the language of Parent, Children, and Siblings to explain how responsiveness in Bubble works.

It’s important to note that these terms are relative; elements can adjust themselves depending on the settings of the elements around (parent) inside (children) or next to (siblings) them.

Alright — on to the show.

Layout

Every page or module you design starts with layout. Layout dictates how elements should arrange themselves within a container. It’s always set on a parent container (the first of which is the page itself), and results in all of that parent’s children positioning themselves accordingly.

You have four high level patterns:

• Fixed

• Align to parent

• Row

• Column

Row and Column layouts are what do most of the heavy lifting, but the other two have their place as well. We’ll take them one at a time.

Fixed width

The only one of these layouts that lets you do true drag and drop. This is also known as absolute positioning. Wherever you drag a child element onto the page, that’s where it will stay, with a set of x and y coordinates relative to the parent.

Fixed width also let’s you layer elements on top of one another (something that isn’t possible with row or column layouts).

Fixed width can be useful for creating small atomic components, like a notification widget or avatar group, that can be nested inside of a responsive structure without the need for themselves to be responsive; since they are so small they’ll fit on any screen size so long as their positioned appropriately.

Some other examples of components where fixed width is a good choice are:

• Icons

• Small images

• Small buttons

• Upvote counter

Align to parent

It works with a nonant. No, a nonant. Nonant? Yes, a nonant.

To quote directly from Bubble:

A nonant is like a quadrant, but when a rectangle is divided into 9 parts instead of 4.

Children elements can be placed in one of these 9 sections. If the parent container is a nonant, then each child can have it’s position set independently.

Some cases where this is useful are:

• Centring a group inside of another group

• Placing a button in the bottom right corner of a group/card

The thing to watch out for with align to parent is that depending on the screen size, elements in different sections of the nonant can begin to overlap with one another.

Alright, enough of all this nonsensical nonant talk. On to rows!

Rows

Containers with the row layout align their children along the x axis. Or, to put it another way, in a row. They’ll stack up next to one another, left to right, and any elements that can’t fit on the same line will go to the line below.

Elements in a row (or a column) cannot overlap with one another.

This is the first principle for rows: children elements will try to stay as high up in parent container as they can, provided there is room.

In the GIF above, all the elements are left-aligned, meaning they’ll move as far left on the screen as they can. This setting is managed by the parent. You can change it to be:

• Centred: elements will move as close to the centre as they can

• Right-aligned: elements will move as close to the right as they can

• Space around: elements will position themselves so that there is equal spacing between them

• Space between: the elements on the far left and right will snap to their respective edges, and the others will position themselves so there is equal spacing between them (just like space around). This can be useful for distributing elements on the far sides of a header (like a logo and user dropdown menu)

The second principle to keep in mind for rows is that when they can’t all fit together in the row, due to screen size, elements that are lowest in the hierarchy have to move to next row before groups higher in the hierarchy. This is quite intuitive.

What if you want to change the order of elements in a row? Easy — Bubble gives you the option to move an element up or down in the hierarchy, or push it straight to the first or last place.

The last piece to mention for rows is that you are able to adjust the vertical position of each element independently within a row: to the top, middle, or bottom of the row. There’s a fourth option too, which stretches the height of the element vertically to fill the row, but more on that later.

It’s important to note that a row group with a maximum height (meaning it can’t extend indefinitely, more on that below) will have its height split equally amongst each row that it needs to fit all it’s children. E.g. a 600px (pixel) parent that needs two rows will give 300px height to each.

However, the elements within each row may be shorter than their row’s height (200px for example). This can result in gaps between the elements in different rows, depending on the vertical alignment.

Columns

Then of course we have columns! Elements in a column stack themselves vertically, one on top of another.

Just like rows, you have the ability to change the order of elements in a column.

You can also change the horizonal alignment of each element independently in a column. This is similar to rows, just in the opposite direction.

A helpful way of thinking about this is that row and column layouts dictate element positions along one axis (horizontal for rows, vertical for columns) but allow you to set the position of each child element along the opposite axis.

Combining rows and columns

By combining rows and columns you can do some pretty neat things, like creating rows of columns, or columns of rows.

Offsets

Offsetting simply refers to moving the position of elements by some amount. If layout gives you the high level pattern, then offset is what you’d use to make more granular adjustments.

Margin

The margin of any element is simply the space it wants between it and it’s neighbours.

This doesn’t just apply to siblings. A child with margin will push itself away from the border of it’s parent as well.

You can set the margin on any of an element’s four sides.

Margins are useful for one-off spacing adjustments between elements; usually you’ll want to use Gaps for consistency (see below).

Padding

Like margin, padding creates space between elements. Only instead of setting the gap on the outside of an element, it sets it on the inside. This means that any children elements will have their position offset by the padding setting of their parent.

It also means that only containers can set padding, since they’re the only elements that can hold children.

• The exception to this is the page itself; you can’t set padding on the page. To replicate padding, use a master container as the highest element in your page hierarchy, and use max width or margin to create space between the page and this container.

Again, you can set the padding on any of the inner four sides of a container.

You’ll want to use padding primarily to create whitespace (empty space) inside of a parent container.

Gap between

Look at this row group from Sony’s website:

There is a gap in between each of the groups here. Now you could do this by setting a right margin on each of the individual groups, but that’s pretty inefficient.

What if there was a way to, I dunno, just set the same sized gap in between each element in a container. And what if it was called something really intuitive, like gap between.

Thank you Bubble.

Row gap = horizontal space between each row

Column gap = vertical space between each element (only available with row layout, since elements don’t stack horizontally in a column)

You’ll want to use gap spacing as much as possible, both to keep consistency in spacing between your elements, and to make your life easier: updating one spacing property is easier than updating 4 margin properties.

Sizing

So you have your layout set, and you’ve made granular adjustments with offsets. Your elements now have some space in which to reside. But how big should they be? Should they take up all the space, or as little as possible?

Sizing, when thrown in with layout and offset, can often lead to moments of “I have no idea why the page is behaving this way”. But taken on it’s own, it’s actually pretty straightforward.

Overall, the high level principles to keep in mind here are that:

• Elements will change their width and height dynamically depending on various properties, like the page size and their min/max width or height settings. The exception to this is if they:
  a) Have their width or height set to fixed
  b) Are inside of a fixed layout container

• You can set a minimum width/height and a maximum width/height for each element, which essentially gives a range within which that element can be resized.

• Each element will either try to expand or shrink as much as it can. Whether or not it wants to expand or shrink is a setting you control for each element independently.

This last feature has a little bit of nuance to it, as Bubble has given us multiple controls which do the same thing. Let’s proceed one step at a time.

Understanding stretch/shrink settings

The basic premise here is that elements can be in one of two modes:

1. Stretch: Elements will try to make themselves as big as they can

2. Shrink: Elements will try to shrink as small as they can

These modes are set for both the width and height independently.

For width, we control this via the Fit width to content checkbox.

When this is unchecked, the element will be in stretch mode, and when it is checked, it will be in shrink mode. More on how these modes function below.

For height, and this is where things gets slightly confusing, we control this the same way, via a Fit height to content checkbox, but only if the parent container is a column or align to parent layout.

If the parent container is a row, we control the stretch/shrink height setting by selecting Vertical stretch as it’s vertical alignment.

Got it? Vertical stretch = Don’t fit height to content, but only in a row…

Yeah, it’s confusing. Two different buttons that do the same thing, just in different contexts.

Oh yeah, and if the parent layout is a column, you also have a Horizontal stretch option, which does exactly the same thing as leaving Fit width to content unchecked.

Why has Bubble set things up this way? It’s due to the way the underlying technology (flexbox) works — hopefully they can simplify things in future.

However, the upside is that despite all of this nuance, what these settings are actually doing is simple: they’re either telling an element to stretch as big as it can, or shrink as small as it can.

And that brings us to something important — how big, or small, can an element get?

It’s different for each mode, so let’s tackle them one at a time.

Stretch mode

When stretching, an element will try to be as large as it can in the space afforded to it. The space afforded to it depends on a few things:

1. The parent group’s max width

2. Any offset space created by margins, padding, and gaps between. These essentially function as an extension of the space that the element cannot expand into.

3. Other sibling elements in the container (elements that share the same parent)
   - Remember that elements in a row will try to stay as high up in the container as they can, preferably sharing the row with their siblings. If we’re in column layout, this is irrelevant, since the elements stack vertically and will never need to share horizontal space

The parent container’s max width provides the overall space that must be shared amongst the children of a container, with any offsets further restricting the available space.

How siblings share space

When it comes to other siblings in a row, there are rules governing how they should adjust their size relative to one another.

The principle we need to note here is this: elements which are in stretch mode will share the available space relative to their minimum widths/heights.

Let’s illustrate. Below we have two groups in a row container (the page) which both have a min width of 200px. Since their min widths are the same, this means they are splitting the available space equally, 50/50.

But watch what happens when we double the min width of the first of these groups to 400px.

We can see that it takes up a disproportionate part of the row’s width. That’s because it has a larger min width: 400px to the 200px of it’s sibling.

Technically what Bubble is doing here is making all siblings hit their minimum width at the same time. This is the same thing as adding their minimum widths together, which gives the smallest possible parent width where all children will still fit together in the row (600px), and then allocating space to each child according to their min widths (400px and 200px accordingly).

For column layouts, it’s similar, only when elements can’t fit in the vertical space, they just extend over the boundaries of the parent.

We can also set the minimum width as a percentage of the parent’s width, rather than in pixels.

This allows us to add multiple elements in a row/column and set their min widths/heights so that they add up to 100% (or less) and those elements will adjust their size relative to the portion they’ve been assigned.

Shrink mode

When an element has this setting enabled, it will try to be as small as possible before hitting either (whichever is larger):

• If it’s a container, the min width of children elements inside it, or the min width of it’s children’s children, or it’s children’s grandchildren, and so on

• If it’s a visual element, the content inside it (e.g. the text inside of a text element)

• It’s own min width plus any offsets

A common use case for shrinking is having text elements adjust their height depending on the amount of text and the font settings (font type, line spacing).

Tip: When fitting to content, make sure you set either the min width or line spacing for your text so that the button of the text isn’t cut off. This can happen on some fonts because the font’s baseline (the invisible line where the characters sit) is not exactly in line with the edge of the text element. This will need to be done for each font size you are using.

Conditional behaviour

The last tool to add to your toolbelt here is the ability to adjust elements depending on the size of the page, i.e, at certain breakpoints.

You have access to the current page width operator when building your expressions, so for any element you can use it to write a conditional statement that compares the page width with one of your pre-defined breakpoints.

You can set all kinds of properties this way, like changing the size of some text, adjusting the padding of a group, or simply hiding an element altogether. Combine hiding an element with the Collapse when hidden property (and even animate it if you’re feeling frisky) to create designs that look good on any screen size.

Defining page structure

The overall thing to keep in mind when building responsive pages is to start with the high level structure first, and fill in the details later.

Just as a painter will sketch out the main lines of the image before filling in the details, create your main page architecture first and add smaller elements later. In app design we call this wireframing.

Start by defining your main parent containers and their layouts. Add the main children containers that will hold content. Add extra elements carefully and one at a time, making sure not to loose sight of how all the various elements and their settings interlock together.

A good tip here (shoutout to Greg and James from Buildcamp for this) is to create a group style with a dark background colour at 10% opacity. Every subsequent container with this style that you add inside of one of these containers will look progressively darker as the opacities add up, giving you a quick way of wireframing your main groups.

That’s it!

Obviously, this is mostly about the responsive engine itself, not about how you should use it. For that, the options are endless! Some great places to start learning and practicing responsive design are:

• My upcoming Bubble for beginners course (coming May 2022)—you’ll have access to many video tutorials, exercises, and build walkthroughs covering responsive design

• Buildcamp: Greg and James from Buildcamp have built an excellent library of tutorials covering how to create beautiful responsive modules and pages with the new engine

• Atomic Fusion: A lot of top Bubblers are sharing responsive modules here. Grab some, take them apart, see how they’re built, and put them together in a new way

• Play around! Try to recreate the designs of existing apps using the new responsive engine. It won’t take long for you to get the hang of it

Special shout out to design-ninja Faye Watson for giving some invaluable feedback on this guide!

About me

I first discovered Bubble in 2017, and since then I’ve worn a few hats: developer, product manager, and educator.

Most recently I left my job as head of learning and development at Airdev (the biggest Bubble agency) to build my own Bubble course for non-technical folks, which you can check out here.

You can find some of my free Bubble tutorials on Youtube.

Also, come say hi on twitter ! You can find me as mneary0.

Let's say we want to seed a civilization of cultural aliens on another planet. The only rule is that we can't give them any of our own cultural products - no technology or know-how. They start from the proverbial state of nature, just like we had to. How would we do it? Is there any law or guiding principle that we can glean from the way societies evolved on our own planet?

From the outset, we should define what we mean by civilization, without getting bogged down in semantics. We all know a civilization when we see one. Multiple social classes, a large bureaucratic system of governance, urban living, economic specialization, writing and a vast geographical range - these are some of the hallmarks of civilization.

Clearly, civilizations do not emerge out of nowhere. Before the Sumerian civilization blossomed in what is today the Middle East, there were thousands of years of agrarian farmers and herders. Before the modern West, there was the scientific revolution. Before the scientific revolution, there was the Gutenberg printing press. Before the Gutenberg printing press, there was the invention of paper, ink, and a literate population. We can dimly sense that there must be a relationship between these things, yet how could we possibly isolate them fully?

Efforts to untangle these causal links is akin to tracing the lineage of a forest in terms of every plant that had to decompose in it’s soils, every bird that distributed it’s seeds, and every rodent that defecated on its roots. Even if we understood all pieces in play, setting them up like dominos to fall would be impossible since the existence of later pieces is dependent on earlier ones. Our job is to set the initial parameters; the base environmental conditions that are suitable to grow a civilization. Just as a rainforest will emerge, given enough time, in an area with a suitable climate, what is the climate in which our civilization can take root?

To answer this question, we need to think of civilization more broadly. A civilization is nothing but a particular kind of human culture. Not all humans live in civilizations, even in the modern world. For most of our species’ history, we lived as roaming bands of hunter-gatherers. Every civilization that has ever existed can, in theory, trace its emergence to our foraging prehistory. Genetically speaking, we are the same animal we were 200,000 years ago. Our bodies and minds haven’t evolved, but our culture, at certain times and places, has. Remembering that our alien population are cultural creatures like ourselves means that nudging them in the direction of civilization is the same thing as promoting the evolution of their culture.

What though, do we mean by culture? Naturally, rigid definitions are impossible. Perhaps the most useful way for our purposes is to define culture in terms of its function.

All organisms, as put by Richard Dawkins in The Selfish Gene, are survival machines built by genes to carry themselves through time. One has the image of a blob of primordial muck at the controls of a hulking automaton. The image gives the impression of sentience on behalf of the genes, but that is far from the truth. Genes don't behave a certain way as much as they tend towards certain behaviour, just as a ball released at the top of a hill will tend to roll downward.

Every generation, a consortium of genes program their host from scratch. If they do a good job, that host will live to create copies of itself, all of them housing more or less the same consortium of genes, minus a few lost to corruption, plus a few new ones gained by merging with other genes. A useful, if imperfect, analogy is to think of genes like a virus, jumping from host to host across the generations. The better their hosts perform out in the world, the more they replicate, and the greater the proportion of their genes exist compared to rivals. The important point for us is that human beings are, like every other organism, merely a vehicle for genes to propagate themselves into the future.

What then, of culture? If humans are a vehicle for genes, then culture is a vehicle for humans. Humans function to propagate specific genes, and culture functions to propagate specific humans. Seen this way, we might say that culture is a symbolic, or conceptual system whose job is to serve human needs. The needs of humans are like that of all animals, to secure food and reproduce. Culture helps us to do so by encoding and distributing information for how to obtain and process food, but also to show respect, demonstrate loyalty; it provides the rituals and norms for upholding social cohesion.

I said earlier that we should be aiming to promote the evolution of our alien's culture. Such terminology understandably raises eyebrows. Am I saying that some cultures are more evolved than others? Actually, yes. I take evolution to be analogous with complexity. In other words, the more evolved something is, the more complex it is. This is consistent with the original meaning of the word evolve - to unfold, open out, expand.

In other words, to add to oneself. Complexity, from the Latin root com - together, and plectere - to weave, also gives this impression, that of multiple disparate parts coming together to form a cohesive whole.

Therefore, if culture is a system made of different units of information, then its complexity is a measure of both the amount of cultural information and the number of relationships between those bits of information. The fewer those unique relationships, the simpler the system.

It's important to note that we are talking here not about the internal, psychological lives of the individuals themselves, but their culture; that is, their artefacts, symbols, mythologies. An hour spent on YouTube can expose someone to vastly more cultural information than an hour spent with an Inuit hunter-gatherer, but that says nothing about the ingenuity of the Inuit nor the richness of his daily experience.

With that preamble out of the way, how on earth do we explain why some cultures became more complex than others? If we can find an answer to that, then perhaps we can isolate the key principles driving their disproportionate growth.

We must recognize that culture has no power whatsoever until expressed in human behaviour. It is not some gaseous cloud mysteriously governing human affairs. It manifests itself in discrete, physical acts - throwing a spear, threading a needle, whistling a tune. Culture is a material phenomenon. As such, it is beholden to the laws of physics to which humans and every other organism is bound.

Can physics really explain something as malleable as culture? The 20th century anthropologist Leslie White thought so. He argued that culture, like all life, is a thermodynamic system. It takes in energy from its environment and spits it out the other end in degraded form. Every organism can be seen, as White put it, as a "structure through which energy flows''. Energy is taken in as sunlight or nutrients, put to work in the growing of leaves or the lifting of feet, and expended in the form of heat.

Why should culture be any different? When there are abundant energy sources, foods to be harvested, soils to be planted in, rare metals to be traded, then the potential for culture to evolve is great. This basic relationship was put by White the following way:

“culture develops as (1) the amount of energy harnessed and put to work per capita per unit of time increases, and (2) as the efficiency of the means with which this energy is expended increases"

What jumps out here is that the capacity for culture to evolve is not solely dependent on the energy harnessed, but also on the efficiency with which it can be harnessed. Since the work we can do with our physical bodies is constant--the same, if not less, for a modern Western man as an Inuit hunter--White simplified his law to:

“Other things being equal, culture evolves as the productivity of human labor increases”

Technology was for White a crucial ingredient. He formalized the law as:

E x T = P

in which E represents the energy input, T the technological means of utilizing it, and P, the cultural product that results.

What does this formula predict? It predicts that hunter-gatherer societies with simple technology, living in environments that cannot support large populations, will tend to remain small. This is what we see across the historical record, with the Netsilik Inuits of the Arctic and the !Kung of the Kalahari desert as prime examples. The cultures of these groups are perfectly aligned with their ecological reality. Scarce resources make infanticide an acceptable strategy for dampening population growth. Because everybody knows each other, there is no need for large governance structures or distinguished leaders - communal decision-making comes naturally.

Even the perils of subsistence living are counterbalanced with mutual-aid networks. Netsilik boys, for example, are assigned 12 male partners when they come of age, with whom they share the meat of their seal hunts. This partnership of allies gives the boy and his family a social security blanket, a network of allies whose door they can knock on in times of need. What all these cultural norms do is relate the individual to his specific environment in such a way as to best sustain the group.

White's law also predicts that if circumstances change, if say a society with a certain level of cultural complexity moves into an environment with less resources, then it's culture will lose complexity. We can see this phenomenon at work with the Moriori people of New Zealand's Chatham Islands. After moving from the fertile soils of subtropical New Zealand to the harsh subantarctic Chatham islands, 800km out to sea, they proceeded to shed many of their cultural traits. The Chathams were not suitable for agriculture, and so, despite being descended from farmers, the Moriori devolved into a culture of hunter-gatherers, subsisting on seals, shellfish, seabirds and fish. By the time they had contact with outsiders again hundreds of years later, they were a small population that had renounced violence, without strong leadership or organization. This would unfortunately be the undoing of their way of life, as they were decimated by displaced Maori from New Zealand looking for a new home. In contrast, the land the Moriori originally left was packed with Maori tribes producing reliable food surpluses. Not all Maori had to devote their time to procuring food, and so could work as part time soldiers, craftspeople, fort-builders, and tool-makers, fueling consequent development in military strategy, technology, and art.

The most dramatic growth in culture however seems to follow in the wake of technological innovations that unlock new sources of energy. Take the Chumash Indians of California. For 5000 years, they subsisted on acorns and seafood as an egalitarian society of hunter-gatherers. Large fish were a problem though - the Chumash had simple canoes made of bulrushes that made hauling large game problematic. A critical technological innovation allowed them to transcend this limitation: the tomol canoe. Made of redwood or pine, these could be up to 7 meters long and hold 12 people. Crucially, they could make longer journeys out to sea, allowing them to haul in massive swordfish and tuna. They could also now efficiently move between the mainland and the Channel Islands off the coast, a rich source of flint which they used to carve beads from seashells. These beads were valued by inland groups and even became a regional currency. As producers and middlemen for the shell trade, the Chamush were able to profit handsomely. As their population grew it developed a hierarchy, with chiefs administering over the production of tomals and seashell beads. Some the labourers even came from outside the Chumash kinship group, forming a multicultural society collectively benefiting off the local industry.

What these specific cases illustrate is a general principle: that the more energy input that goes into a cultural system, the more complex that system will tend to become. A simplification of the general evolutionary logic, which admittingly misses the endless historical permutations and exceptions, goes something like this:

More resources are able to feed more mouths, more mouths means more hands, and more hands means even more resources.

This autocatalytic process extends to technological innovation. Every individual might have a small chance at discovering some new way to string a bow, but the more individuals trying, the more likely that one of them will, and once they do, the whole group will benefit. Every innovation helps the group to procure more resources with less effort, further accelerating population growth.

A growing population necessitates a growing body of rules. The group has to make decisions and mediate conflict. Often the way to do this is to put someone in charge - a chief. As groups grow, competition for leadership splits groups into disparate parts, each following their own leader. The most successful groups are those able to incorporate the subgroups into larger groupings, creating hierarchies of governance. When more than one of these groups are competing for shared resources, conflict will be won by those with superior social cohesion, allowing them to fight more effectively and develop trading networks with other societies.

Time and again throughout history we see civilizations rise in this way through the domestication of plants and animals, a hitherto unmatched energy source. The yield obtained by harvesting directly from the chance offerings of nature simply cannot be matched by the intentional cultivation of resources.

The reasons why agriculture kicked off initially in some places and not others comes down, again, to the energy sources available. The Sumerians flourished due to the ease of domesticating high yield cereal and pulse crops, as well as sheep and goat, all of which had evolved in the favourable climate and geography of the Eastern Mediterranean. Similar stories can be told in China, Central America, and the Andes.

The civilizations that rose in these areas hit their natural limits when they exhausted the resource base, which is why we never saw Romans launching rockets into space. The ceiling for our own civilization is clearly much higher, the result of an even higher yield energy source: fossil fuels. The bewildering complexity of our own culture--all our occupations, technology, and art--all springs, ultimately, from coal, oil, and natural gas. Augmenting human labour with them has led to the highest levels of productivity and cultural complexity in history.

Yet our large-scale exploitation of fossil fuels did not happen in a vacuum. Humans have used them for thousands of years. The Romans used to heat their public baths with it. Over two thousand years ago the Chinese were extracting natural gas and oil from wells. Yet it’s only very recently that we used it to power our home, vehicles, and factories. If we’ve had the energy source around for so long but neglected to build a civilization with it, couldn’t our aliens fall into the same stasis?

It’s entirely possible that they could. But then, given enough time, they would be likely to figure out how to exploit it fully. Your odds of winning the lotto aren’t bad if you buy a ticket every week for a hundred million years. The mix of social, economic, and technological prerequisites that were needed for the industrial revolution to take place I’m nowhere near qualified to survey, but it seems reasonable that they would have emerged at some point. Just as a river might take thousands of years to carve a channel to the ocean, so does cultural evolution proceed to pinch and probe the environment in order to discover some better way of doing things. Whether or not the configuration it finds represents the final peak before regression, or merely another step in the insatiable march toward complexity, is beside the point. Culture never stands still, and that’s where it’s tendency for growth comes from.

The prescription for our alien experiment therefore is clear - put them somewhere with a high energy source, and wait. White’s law tells us that cultural evolution will ride on the back of human productivity. For that to happen, latent energy sources must be tapped. Our aliens may take thousands of years to figure out how to make use of them. They may get the ball rolling only to degenerate into social anarchy multiple times over. Eventually though, their probing roots will stumble upon fertile ground, and they will find it a strong foundation for their civilization. At least, for a while.