Monthly Community Update -- November 2021

Hi all,

This is our November community update; you can read October’s update here.

I’ll jump right in with the question I’m guessing is on everyone’s minds: Where is the new responsive design engine???

The answer is we didn’t quite hit our goal to get it shipped by end of October, but we’re now aiming for a open beta release this week. At this point, all the core functionality is completely finished, and what we’re working on are small bug fixes, tweaks to the user interface based on feedback and confusions that came up while testing, and documentation.

Our general product philosophy is to have a target ship date but to extend the timeline as necessary in order to ship something we think is polished and that we believe in. (Which is one of the reasons I’ve been resistant to giving ETAs for features in these updates!) We’re overall extremely excited about the responsive release, and just found more little details to nail down and corner-cases to fix than we expected, which is what pushed the date out.

We can’t wait to get it live; this is the most exciting product update we’ve made in quite a while. We expect there to be three main benefits:

  • Speed and ease-of-use: our current responsive engine requires a lot of trial-and-error and tweaking to get layouts right, whereas the new engine it’s much easier to just specify exactly how you want it to behave.

  • Features: the new engine is more flexible and addresses a broader range of layouts than the old engine. It’s also easier to extend, so we anticipate being able to build follow-on improvements faster if there’s additional functionality we decide is important to add.

  • Performance: it’s significantly faster to render pages built with the new engine than the old engine, and we expect that when users convert their apps, they’ll notice meaningful improvements in how fast elements draw when loading or resizing the page.

That said, as a warning, there will be a learning curve to the new engine. We don’t think it’s harder to learn than the existing engine, but it’s different, and it’s not necessarily simpler. That’s one of the reasons we want to finish videos and documentation before the wider release. We definitely think it’s worth learning, and will radically improve how easy it is to build responsive layouts on Bubble!

The other big theme this month is, like the last couple months, hiring. We had three new people join the team, and we’ve extended a ton of job offers for people joining in future months. Please welcome:

  • Shravan and Alex, joining the engineering team
  • Theo, joining the marketing and growth team

If you’re interested in joining us, here’s a list of our open roles. In particular, I’d like to call your attention to two roles we’d love to get help from the community in filling:

  • Our associate and experienced product designer roles: help us take the Bubble editor and homepage to the next level!

  • Our video producer role: help us produce amazing educational content and videos

Changes we made this month

This was another light month on the product side, since most of the things we are working on are bigger initiatives that will ship in future months. We did add a nice improvement to geographic search boxes allowing access to place names which should make it easier to build a number of place-related workflows.

We made a number of updates on the community side:

This month in numbers

  • New conversations via bug reports or support@bubble.io: 6,585 (down 3.6%).

  • Average first response time to messages: 4h 23m during business hours (up 27.6%)

  • Average response time to messages: 4h 06m during business hours (up 12.7%)

  • Time to resolve bug reports escalated to the engineering team: the average lifespan of open bugs and bugs resolved in the last month is 11.4 days (up from 8.7)

Things on our minds

One of our big internal focuses this month was our code shipping rhythm, quality assurance, and the pipeline for investigating and escalating critical user bugs. We’ve had discussions both internally and on the forum about the frequency at which we’ve been shipping code and making sure that if something does get broken in user applications, we deal with it in a timely manner.

Part of the prompting for this conversation came from a few incidents this month where bugs made it to production, and worse, made it onto the scheduled cluster because we didn’t realize things were broken in a timely fashion.

Digging into this internally, what we realized is that a lot of the issues were due to the inadequate backpressure on our engineering team from our success team: as we shipped more code, it introduced more bugs, leading to more bug reports and the success team falling behind. As they fell behind, response times to bug reports went up, which meant engineers got less feedback that they were shipping buggy code, leading them to ship more new code instead of doubling back on fixing the problems in the already-shipped code.

Tactically, as soon as we realized what was going on, we paused all new deployments except for critical bug fixes for a couple days to give the support team a chance to catch up. The team put in an all-out effort to get on top of the growing pile of reports. Once we got things under control, we made a number of process and automation changes to help prevent a similar occurrence going forward:

  • We’ve added several new automations to our email client to distribute work on support team more efficiently and get eyes on questions and bug repors sooner

  • We created an internal tool and notification system to streamline the process of escalating bugs

  • We implemented a new Success-Engineering process to streamline how we handle performance and infrastructure tickets

As a result of the team’s effort and new processes, average response times decreased back to about two hours by the end of October, from a high of close to four hours. Our goal with these process changes is to operate efficiently and to make sure that engineers get rapid feedback if the community is reporting issues with the code we ship.

We’re also tackling the problem from the quality assurance angle, to help prevent bugs getting out to customers in the first place. We engaged an outsourced QA firm and so far they’ve created over 100 new automated tests. We’re excited about this as a way of rapidly improving our test coverage.

What we’re currently working on

Performance is currently our top priority for the engineering team. Our focus right now is data loading and rendering: if you have a repeating group on your page, we want to see how fast we can make it fetch the data and then draw all the elements. We have three separate teams working on this right now, each tackling the problem from a different angle:

  • One team is working on optimizing the way we handle invisible elements. Currently, if a page or repeating group cell contains invisible elements, we avoid doing all the drawing work until that element is shown, but we still do some work, and on a big page with lots of invisible elements this adds up. We’re seeing how much we can minimize the work we do to defer all the effort until it’s actually time to display the element.

  • Another team is working on pre-fetching data the repeating groups need to draw. Right now, if a cell in a repeating group fetches data, we don’t begin loading that data until we draw the cell. We are working on being smarter about predicting what queries we will need to perform and kicking them off alongside loading the search to populate the repeating group. This is likely going to result in a series of improvements to different kinds of searches and scenarios.

  • Finally, the team currently working on the new responsive engine is slated to start work on a project to enable generating HTML and CSS upfront instead of on-the-fly, which we predict should have a major positive impact on rendering speeds overall.

In addition to work on performance, we’re also working on the following:

  • QA: as mentioned above, we’ve outsourced the buildout of a suite of tests are are now over 100 new tests

  • Version-control reliability: we transitioned the project to a different engineer, who is now up to speed and will be working on it this month. The plan is to focus on building tests for more and more scenarios so that the behavior of different complicated merges is well-defined.

  • Migrating code to typescript: the main push right now is to convert from coffee-script to javascript, since going from javascript to typescript is essentially instantaneous. 48% of our codebase is now javascript.

  • SelectPDF replacement: still on ice for now.

  • New responsive design engine: see above!

Happy November, and thanks again for all the support,

Josh and Emmanuel

54 Likes

This is awesome news :sunglasses:

2 Likes

Thanks Bubble team - really looking forward to testing out the new responsive engine, especially for performance.

Hundreds of our Bubble-built job board pages were recently flagged ‘poor’ in Google Search Console due to load speed > 4s which has caused our organic search results to plummet. We really want to avoid having to move to another solution so it’s a relief that you’re focused on performance at this time.

Cheers!

3 Likes

Performance for the win!!! And can’t wait for those responsive updates :heart_eyes: :raised_hands: :relaxed:

2 Likes

It’s great to hear these updates, thank you @josh! I’m most excited about the new responsive engine and the learning that follows (hopefully won’t be too long or difficult). Let’s go! :rocket:

2 Likes

Some truly awesome updates in here! Keep up the great work guys, Bubble is getting better by the week :metal: :heart_eyes:

5 Likes

YAY!!!

2 Likes

Great update and thank you for the transparency and focus on areas that are most important to your users!

One question – will these upcoming performance improvements also help the Google lighthouse speed score for a Bubble site?

1 Like

@josh, thanks for the update! Will the new responsive engine bring support for dynamic X/Y properties at all?

2 Likes

Take your time Bubble Team! I rather wait for something better than an update with a lot of bugs!

Amazing!

2 Likes

@joao1997domingues our conversation this Saturday!

5 Likes

I also got a majority of all my pages flagged as ‘poor’ by Google as well. I began to research, in earnest, other no-code solutions. But I would love to stay with bubble if they can fix this!

1 Like

Love it !!

awesome - just pinning myself to get notified about the beta access to responsive engine

love the new updates.

Some really exciting projects in the pipeline - excited to try the new responsive editor.

Thanks for providing such detailed monthly updates, it’s great to get a peek into everything that’s happening behind the scenes :slight_smile:

1 Like

If vertical responsiveness is fixed, this will be great. Hopefully the learning curve won’t be too difficult.

5 Likes

Hopefully this open the floodgates and we start seeing more frequent updates and feature enhancements. @josh Please keep us power-users in mind, so that there’s also new features designed to enhance productivity, like hotkeys and organizational features to very large projects. I’ve shared a lot of ideas throughout the forum.

Thank you to the bubble team! :raised_hands:

6 Likes

What’s the purpose of this? Is coffee-script depreciated or simply too caffeinated?

1 Like

Soooo looking forward to the performance enhancements and can’t wait to see the new responsive editor :slight_smile:

3 Likes