This is probably one of the most exciting things we’ve been working on over the last few months: responsive layout! It’s not done yet, but we’re now pushing it so that users can start experimenting and give us feedback. Depending on how the feedback loop goes, we hope we’ll have something ready for production in 2/3 weeks (before that, you shouldn’t use it for apps that are in prod).
Here is how it works. At this stage you should do this on a test page.
Firstly, you have to turn on responsive design for your page. To do this, double click on the page area and then check the “Enable responsive page rendering engine” box.
Once this is done, you’ll be able to go to the Responsive Viewer (above the hidden element box).
When this is turned on, elements will get resized as the page’s width changes. For different elements, you can set up a minimum width. That’s a way to make sure elements don’t go below a certain number of pixels. And you’ll also be able to specify, for some elements, some rules (for instance, for an image, you can say “Keep element proportions as the page is resized”.
At this stage, not all elements are adapted to the new system. You can experiment with Text, Image, Input, Groups, Icon. We’ll add more elements over the next few days.
And please drop here some notes if you think some part of the behavior isn’t the right now (as you play with resizing the page). The more feedback, the better the algorithm!
Our eventual game plan here is for all new apps + pages to use the new, responsive rendering layout engine. It is not backwards compatible with the current layout engine, so we’re going to make it opt-in for existing pages to avoid breaking live apps. Once the new layout engine is ready for production (after you guys get a chance to test it out and give us feedback), we’ll make the curent engine unavailable on new apps, and we’ll make new pages on old apps default to using the new engine.
Bubble’s layout engine today is basically fixed-width at its core, though we have some features (such as stripes, full-page-width backdrops, and floating groups) that you can use to fake some responsiveness. The new engine is reversed; it’s fundamentally responsive at its core, but we’ll have features (such as being able to set minimum widths for elements) that will allow you to implement fixed width designs on top of it if you want to.
Great start! I would also like to see the ability to specify percentage based widths and heights. I am still unable to make a vertical section that spans the entire height of a page or a horizontal section that spans the width of the window.
As @Kfawcett said, percentage widths or heights is critical for responsive elements and layouts. Nice start but not sure of the way this is implemented so far… I was expecting something like Bootstrap or Foundation framework integration, i’ll keep playing with it but have to say I am a bit disappointed though I understand this is still in Beta.
Also, elements are disappearing when page is previewed. What does the Responsive Viewer do? In Building Mode I have a text element with dummy text, when switched to Responsive Viewer is the text element supposed to be there? In my case its blank so I am confused what to do there…
We’ll post some demos and maybe tutorials over the next week showing how the new system works. Don’t worry, though, you can definitely create full-width layouts… we implicitly calculate percentage widths for you based on how you draw the page, so if you draw two groups, one taking up 30% and one next to it taking up 70%, those ratios will be preserved as you resize the page, assuming there’s no minimum width set on the groups.
The basic idea is:
-In Building Mode, you can drag & drop stuff on the page without worrying too much about how it will get shrunk down for mobile or expanded for really large screens.
-Our algorithm makes a series of guesses about how you want it to work – when should elements break to the next line, when should they expand and shrink ,etc.
-You can use the Responsive Viewer to preview the decisions the algorithm makes at different screen sizes, and tweak settings if you disagree with one of the algorithms decisions (like controlling how far an element will shrink, or automatically showing / hiding elements at different screen widths).
On behalf of all of us here i would like to extend our appreciation on this great step forward. During the testing process i have faced an error where the below options are not being displayed any more. I think this is an error.
P.S. this page doesn’t have responsiveness enabled.
@josh It would be nice to be able to actually specify 70% versus drawing in order to make elements consistent. Percentages are even more important for vertical items. I want a sidebar to fill the full length of the user’s browser view.
@Kfawcett – mind sending me a link to a website that has the kind of full length sidebar you have in mind? I’ll see if I can reproduce it using the new layout system.
Re: explicit percentages for horizontal elements, we’ll think about it… it’s tricky because the rules are often significantly more complicated than just a flat percent. We spent a lot of time looking at how real-life examples such as Kickstarter’s homepage (https://www.kickstarter.com/) behave as you resize your browser, and the actual behavior is often something like “it should be 20% wide while it is on the same line as two other elements, but when the page narrows, break the rightmost element to the next line, and then it should be 40%, and then when the page narrows further, break the middle element, and then it should be 90% minus two 20 px margins”. There might be a way of making our implicit rules more explicit / easily editable, though… will think about it as we continue the testing process.
