Monthly Community Update -- May 2022

Hi all,

This is our May community update! Read last month’s update here.

This was an exciting month on a number of fronts! From a product perspective, we launched some important features for our new responsive engine, as well as an experimental features framework, we increased the hours of support we offer, and from a team-building perspective, we made some important hires and had our first full-company get-together since the beginning of COVID.

We’d like to welcome to the team:

  • Jenna, joining our People organization
  • Jack and Stephen, two new engineers
  • Abhinav, who is going to help us produce videos and educational content
  • Jason, joining us as a Technical Product Support Specialist
  • Ramzi, a new product designer
  • Tatiana, who will be leading our marketing department

Our open roles can be found here. If you’d like to join us, a great role for proficient Bubblers is our Technical Product Support Specialist opening!

Changes we made this month

We launched two of the biggest open items on our list of things to complete before taking the new responsive engine out of beta:

From an engineering perspective, we are now very close to being done with everything we wanted to complete before making the new responsive engine the default experience for new applications. Our remaining work includes continued documentation, bug fixing, and improving the plugin editor based on any developer feedback we get from our alpha testers, as well as working with our ecosystem to get as many templates and plugins compatible with the new responsive engine as we can. We would love to have a strong selection of templates and plugins compatible with the new engine on day 1, so if you have a template in the marketplace, please consider porting it to the new system!

Another thing we are excited to launch is a user interface for opting into experimental features. This will give us more freedom to test new things with the userbase and get feedback. The first feature we’re testing using this new system is one that has been a long time coming: the ability to have parentheses in the dynamic expression editor, to enable building more complex expressions! We want to see if this is an easy, convenient way to add them in – please give us any feedback you have on them in the linked thread!

In addition to those big feature releases, we also made some small performance improvements to the editor and to specific elements.

We made a number of changes to our homepage as well:

Another exciting launch: we now offer 24/7 product support for whenever you need to contact us. Currently, this only includes our Tier 1 team, who can now help 24/7 with questions about your account, app plans, bootcamps, building your applications, and more. Our Tier 2 escalations and bug investigations team will continue to be available from 9-6 PM ET for now. We are excited about this expansion and for the opportunity to support our community of builders around the globe!

We’ve released a number of new resources:

Finally, two educational offerings:

This month in numbers

  • New conversations via bug reports or support@bubble.io: 7,986 (down 13.1%).

  • Average first response time to messages: 1h 20m during business hours (down 30.1%)

  • Average response time to messages: 1h 38m during business hours (down 18.2%)

  • Open tickets being investigated by the engineering team: 65 (up from 57)

  • Of those, tickets that have been open longer than 7 days: 25 (down from 33)

Things on our minds

This month, most of the team met up in-person in Miami. This was the first time many of us had ever met each other, since we grew the company very significantly during COVID, from roughly 30 people pre-COVID to almost 80 people today. While we still have an office in New York City, the team is spread across the United States (as well as a small presence in Europe). The focus was more on getting to know each other and having fun than it was on work, and by and large it was a really good time.

While a company-wide meetup might feel a little trivial, we actually think it was very important: building real friendships, camaraderie, and cross-team awareness leads to higher productivity and better decision making. This is especially top of mind for us given the failed pricing rollout in March. Earlier this month, we conducted a retrospective on the project to understand how we landed on a set of proposals that so badly missed our intended objective. We have already shared many of the learnings from that conversation with the community in prior forum posts, particularly around our failure to get enough user feedback and to make sure the feedback was adequately quantitative. The most important takeaway from our retrospective that we haven’t already shared was that several people on our team had anticipated the problems with the new pricing prior to launch, but because we did not do a good job listening to each other, those concerns did not get escalated into a serious discussion.

Keeping open lines of communication, and a culture that rewards raising potential issues, can be challenging in a rapidly-expanding company, and the remote work environment we’ve operated in since COVID adds to the difficulty. We intend to make a committed effort to build a culture where we do a great job listening to each other and freely communicating internally, as well as doing a great job listening to the community. Given that, it was really nice to be able to spend some purely fun time together, and we feel a little more connected and on the same page as a result.

What we’re currently working on

As discussed above, we are preparing our new responsive engine for a full rollout: at this point, we are done with the engineering heavy-lifting and most of the work is reacting to bugs and feedback, as well as preparing documentation and working with the ecosystem.

Following up on our latest post about pricing, we are doing technical investigation work on capacity and auto-scaling, since after extended conversations with the community, we believe it would be a win for everyone if users have more control over what happens when their apps consume more server resources than our current capacity system allows. As mentioned in that post, we intend to do further rounds of community feedback once we have completed the technical investigation work, and do not anticipate releasing anything disruptive that would jeopardize anyone’s ability to build on Bubble.

Other ongoing workstreams:

  • For version control, we are continuing to improve the algorithm, and we have designed a set of feature improvements to give more visibility into changes collaborators have made to their versions. We are in the process of getting community feedback on the mockups for the new version control user experience: the feedback we have gotten so far is very positive and we will likely continue in that direction.

  • We are working on better in-editor educational resources for the Data tab, to help new users get up to speed faster

  • We are continuing to roll out some of our optimizations for invisible elements, and will likely be using the new experimental features user interface to allow testing this out.

  • We are still working on the months-long project to generate HTML and CSS upfront instead of on the fly, which we think will have significant page load speed and SEO impact

  • We are working on some performance optimizations to make bulk data manipulation via backend workflows faster

  • We are making more changes to our homepage, including adding new pages to go in depth on various Bubble use cases, and reorganizing our showcase page to do a better job of helping new visitors understand what Bubble is capable of

  • We are still in the planning phase for the overhaul of our network architecture and infrastructure

  • In order to increase our overall reliability, we are working on the way our alerting and observability systems work, so that we can be more proactive about tackling impending problems

  • We are wrapping up the planning stages for a project to improve how easy and fast it is to build beautiful apps on Bubble. The project involves improvements to managing colors and fonts across your app, and a replacement of our under-used element templates feature with a more mature component system.

  • Our push to migrate code of CoffeeScript continues; we are now down to 39.8% CoffeeScript in our main codebase.

Wishing you all a lovely May,

Josh and Emmanuel

43 Likes

Thanks Josh, exciting to read your updates as always :cowboy_hat_face:

Quick question on that - will the old responsive engine be still available after the new one gets out of beta? In other words, will apps built on the old engine still be fully functional, and will we be able to edit these without the need to update to the new one?

2 Likes

:smiley:

4 Likes

Yes. We will likely turn off the ability to create a brand new app on the old system, but existing apps will remain editable without upgrading

8 Likes

Parentheses :heart_eyes:

15 Likes

Thanks for the monthly update, always exciting to read these.

Any ETA?

These are some exciting developments! Can’t wait to try out the parentheses.

1 Like

Your transparency and vulnerability in sharing shortcomings is refreshing and reassuring! Love it

I keep coming back to bubble because I trust your leadership

4 Likes

Very curious to see what this is going to mean. :blush:

3 Likes

@josh Should we not be storing variables in a popup if the element is invisible? In a few cases I have used this to compute complicated formulas without displaying the elements on the page, just to only display the result on the page.

3 Likes

Jo - this could be so big - like figma components but with working stuff

Also if you work with components right now with the reusable elements it gets really messy - so a folder structer in there would be sooo helpfull

BTW. great update and great work as well.

1 Like

Thanks for the update @josh! Can’t wait to see what’s to come :eyes:

@josh

Could you please share with us what is the nature of the optimization for invisible elements?

… Will popups continue to be loaded along with all of the page resources on page load? (they are “invisible” elements … and complementing/elaborating on Jason’s @J805 comment … many of us use popups (that are never opened) to house lots of logic that is fed down to the page. It would worry me if this would no longer be possible at some point in the future (invisible elements passing values to visible ones).

7 Likes

The version control updates will be massive for us! This is currently our biggest hurdle since we have many developers working on one app.

2 Likes

The deferred drawing logic should not interfere with elements that always stay invisible, but load data that is required elsewhere (as is current behavior)

7 Likes

Thanks @josh for the monthly updates. I believe using industry standards terms may help users migrate or learn bubble faster.

Ex. We use the action “Creat a new thing” when actually we are creating a new record.
Other ex. Custom data types = table

Not just the database terms but across the entire development process. If we use industry standard terms it’ll make it easier for new users to get familiar with bubble quickly and lower the learning curve.

2 Likes

YES! Maybe finally it will be possible to make those small elements just once and update around whole application with one settings :wink:

Fingers crossed X

@cmarchan @J805

Perhaps this warrants a new thread, but I’m curious as to why. :face_with_raised_eyebrow: What are the advantages over reusable elements, custom events, and/or custom states?

Hi @sudsy

When you use a group or an rg to house “state” data you gain access to conditionality. Custom states cannot do this.

You can also do “visual” calculations and expressions by assigning values to groups as numbers or to house a searched object’s dynamic number in a group.

… quite powerful! :smiley:

1 Like

Thanks, Carlos, for taking the time to elaborate!

I might need to see a working example to fully grasp what you’re saying. I’m a “hands-on” kind of guy. :slightly_smiling_face: Since the value of a custom state can certainly be set conditionally, I’m wondering if maybe the approach you describe just offers a preferable UX for some users?

At the very least, it seems like it might be something the Bubble team could investigate to see if there’s the potential to enhance the editor for an improved experience.

1 Like