Reusable elements are a great way to solve this issue.
The main drawbacks with them are:
You need to have a single bubble editor tab open in your browser, because as you said, it takes too long to switch back and forth via bubble
Certain workflows need to talk to the page itself. If I need to trigger a workflow inside of a floating group on my index page, it can be a major struggle trying to do it remotely.
The Satellite Plugin can help a ton, but sometimes it’s just too much // too difficult.
I’d still recommend trying to convert as many of your groups as possible to reusables. The 2 second delay along with the visual clutter on my index page is honestly sickening and makes editing a chore.
We do have some in place, but we’re looking on improving:
better monitoring for editor performance in the wild: our tests are better at catching bugs that happen immediately than things like “after using the editor for 30 min it starts slowing down”
better test coverage of deeper interactions — our tests generally catch things where a UX component is completely broken, but more complicated interactions don’t always have coverage
An update on the general situation: we pushed a number of fixes yesterday that we think helped a lot, but we have another couple known bugs we are working on right now and a few more bug reports we are investigating. We think the editor is more stable than it was yesterday but we are not ready to call an “all clear, back to last week’s level of stability” (which is a baseline that we want to improve on but an improvement from the last couple days). We expect significantly more progress by EOD
Last week was buggy too, so I’m not sure if this is the standard you should be going for.
These bugs have been around for weeks. Editor gets stuck when trying to edit an expression, mostly on the backend workflows. This is a constant bug for a few weeks now. Is that the one you are trying to fix?
There are just so many bugs that I have given up doing bug reports.
Yeah, the 'not being able to click on a workflow, or click an expression data source when the data source menu is opened until page refresh is still a pain.
But having ‘beta’ editor versions before deploying to everyone using Bubble is an obvious solution.
My inbox looks like I am a Bubble support agent. Had to stop using the bug reports because it is too time consuming when I’m having to send in 5-6 reports daily with videos, then having to explain to the fresh support agent how Bubble works and why what I am reporting is a bug…to then only hear back that the issue ‘is intended behavior’ because it seems like Bubble engineering have come up with a novel way to not have to fix issues, which is state ‘that is what we intended when we built it’ even when the reported behavior has not been present over the past 5+ years.
I’m glad that you brought this to @josh attention. I attempted to do that on the July Monthly update when the update indicated they made great progress on fixing the issues in the editor, to which my retort was, people are just tired of reporting all the bugs.
Another thing that just grinds my gears, is all the new feature implementations that are catering toward a novice user, with intention to make it easier for them, but in effect make it harder for them and for experienced users. Like the expression composer remaining open until you are forced to click out. I’ve been having to second guess my expressions constantly now, because when it doesn’t close (as had always been the case in the past with an incorrect expression) I believe that the expression must be improper. I couldn’t imagine the confusion of a new user with this.
It’s all ‘intended behavior’ or ‘submit to idea board’ now a days. Something has to be fixed internally with how they are operating the support, as well as managing releases.
At least I’ve been smart enough to quote my clients a time range estimate rather than a flat rate for project development…editor issues cause a lot of time delays in development.
Anyway that we can get some kind of setup for support so that experienced users get their bug reports routed to experienced and knowledgeable support staff?
Feels like I get newbies all the time and I have to explain how Bubble works before they are able to understand what I am reporting is a bug for them to pass it to engineering.
Also, anyway that the concept of ‘intended behavior’ could be not a thing any longer, and be a little bit more open minded about the mistakes within the UX of certain features that when professional Bubble developers who use the system everyday all day to earn a living, might have a better sense of what the UX should be. I report issues all the time now that get retorted with ‘this is intended behavior, please post an idea to the idea board’. Kind of frustrating.
I think this is another example of why Bubble should move as quickly as possible to a WordPress-esque type of update system, where updates are released but not automatically pushed, so users have a chance to test changes before applying them to their apps.
Thank you everyone for all the patience here. To share a quick update: our engineering team deployed a few fixes today that should have improved several aspects of the recent editor slowdowns. They are continuing to work on addressing the full range of behaviors flagged in bug reports and here in the forum.
If you’re experiencing ongoing interruptions (or improvements), please let us know via any existing threads with our Success team or submit a bug report if you haven’t already. The reports have been incredibly helpful in working towards a resolution, so we really appreciate the ongoing help from the community.
We’ll make sure to share more updates as soon as we can!
Everything seems to be falling back into place, the editor is once again sufficiently fast and usable. Thanks to the Bubble technical team for their swift action.
I run 3 tabs, one is the editor, one is the preview (because I can’t use the responsive tab, because the editor is too slow - useless feature) and the third is youtube. Running a 6 core i9. The sluggishness of the editor is 100% a bubble issue.
My internet speed test…I’m sorry Bubble, it is not me, it is you. Fix yourself.
Responsive tab has been a useless feature since the release of the flexbox system. Doesn’t show any conditional layout changes or anything. Google Chrome Dev tools responsive doesn’t like Bubble flexbox implementation so it doesn’t work right either. I only test responsive in Firefox dev tools now.
What should have taken me 20 minutes took me an hour. Bubble should stop saying Bubble helps you build 5X faster than traditional code and change that to ‘Bubble Could help you build 5X faster, but our editor is so slow, you can build 0.5X faster than traditional code’.
What a mess.
The price changes didn’t make me jump ship. These editor problems just might.
While I get your point - this is a standard approach of any service desk (1st line support) to give generic answers just to be sure that users environment (device, browser) is OK. That’s their job and it helps not to forward each and every ticket to higher levels of support.
A little trick to bypass this stage is to add something like “I’ve cleared cache, browser is updated to the latest version, blah-blah-blah…” during reporting a bug.
I’m sorry, no. First, we should review all the information you submitted with the ticket. If you are familiar with enterprise support, this isn’t it. I only say enterprise because the prices are already there.
Instead of making excuses all the time, we should look at some solutions.
Increase support for higher-level plans
Introduce support packages…
Filter tickets better? In terms of skill level of submitter for example?
In no way am I attacking the support team or bubble; I just think it could be improved.