Last month we had a lot of exciting stuff to announce. This month is a little less triumphant, although there’s still some noteworthy changes. Overall, it was a pretty heads-down month for the team: we spent our energy laying some groundwork for the rest of the year.
An overhaul of our Rich Text Editor plugin’s performance. This represents the end of the short-term work we’re doing on the RTE; while it’s still not perfect, we think it’s in a much better place than it was at the beginning of our push on it over the last month or so.
We’ve also been investing in our various documentation and educational resources:
The Fundamentals bootcamp is now live: it’s a great starting point for Bubble beginners who don’t necessarily have a specific app idea in mind but want to build the skill set.
We added a second timeslot for our free Intro to Bubble webinar: Thursdays at 4 pm ET. This is a great starting point for someone brand new to Bubble: we demo the editor, do a live build of a todo app, and answer any questions. EDIT: actually, we had to cancel the second timeslot Sign up for it on Tuesdays at 11 am ET
We published two new App of the Day posts. Please keep telling us about your apps if you’re building something you’d like to see featured!
We also have some new members of the team. Rosalie is joining the growth team and working on our bootcamps program, and Megan is also joining the growth team as an intern, working on our campus ambassadors program. On the engineering team, we’re sad to say goodbye to our interns: thank you so much to Henry, Andres, Patrick, and Gerry for the amazing work you did. But we’re also excited to welcome Yash, Joshua, Nisreen, and Peter, who are going to be interning with us this summer.
This month in numbers
Total number of conversations via bug reports or email@example.com: 5,769 (down 11.7%)
Total received messages: 9,777 (down 7.5%)
Average response time to messages: (1h 32m during business hours, no change)
Time to resolve bug reports escalated to the engineering team: the average lifespan of open bugs and bugs resolved in the last month is 3.8 days (down from 4.0)
Things on our minds
Reliability continues to be something we’re tracking closely. This month wasn’t as good as last month: we had a couple bad code releases that caused some feature and performance issues. That said, we’re still in a better place than we were a three or four months ago. We’re making some process shifts on the engineering team that are going to take some time to roll out but will likely increase the quality of releases going forward.
What we’re currently working on
Not sure this counts as “new”, but now that we’re finished with the asset-building system work that was a blocker, we’re ramping work back up on version control reliability. This is via a series of targeted bug fixes, as well as some improvements to the algorithm and some product work to make it more useable.
We’ve started a project to migrate some of our code to Typescript: this won’t have any immediate user impact, but it will make it easier to proactively catch bugs before release, and to write and deploy code more quickly.
We’re building out a series of cases studies on Bubble success stories. We’re looking for companies that have accomplished business milestones such as hitting significant revenue targets, raising rounds of external funding, reaching large numbers of monthly active users, or other quantifiable accomplishments. If that’s you, and you’d be willing to share your story with us, please drop us a note!
Updates on our ongoing initiatives:
Unfortunately, we didn’t manage to get our SelectPDF replacement out the door before the intern driving the project had to wrap up. We know that a lot of you were excited about this, and we definitely plan to get this project to completion, but it’s going to have to go on pause until we can staff it up again. Part of the reason the timeline stretched out was that we under-allocated the amount of senior engineering time it required, so we want to make sure we can give it an appropriate level of attention before resuming work. I’m sorry about this one: I know this news is not what a lot of people were hoping for. We can’t yet commit to when we’ll resume work, although I’m hoping we’ll be able to staff it in the not-too-distant future.
The new responsive design engine is basically built, and we’re now doing user testing and iterating based on feedback. Our sense is that it’s a substantial improvement over the status quo, although it’s not a magic bullet and there’s still going to be a learning curve and some elements that aren’t perfectly intuitive. The new system is fairly similar to the old system: you still free-draw elements on one tab, then tweak responsive behavior on another tab. The main difference is that the underlying algorithm is now based on CSS, which makes it much faster and smoother to render. Using the new CSS algorithm, it’s easier for us to tweak features, and we’ve taken advantage of this to make some improvements, such as phasing out hiding rules in favor of a single type of invisibility that can either remove things from the layout or leave the space, letting you adjust margins manually on the responsive tab, and more intuitive layout options. Anyway, we’re still making small adjustments to all of these features, though likely not making any radical changes at this point. Once we’re happy with it, we’ll preview it with template creators so they can start porting things to the new system.
The complete redesign of our editor still looks like it is on track to begin alpha testing with users over the summer.
I guess transition for existing apps will be easier, so that’s great in that sense.
But I can not not feel disappointed, that means the learning curve for new comers will remain high I guess. Can’t wait to see how it will work, I sure give you the benefit of the doubt, but I’d thought you would have chosen a totally different path.
@josh Not a fan of this (the signup/login part). It may be the industry “Best Practice”, but it’s fundamentally flawed, as has been pointed out by many people online. It relies on the idea that you shouldn’t expose whether an email address exists for an account already, aka email leakage. Except that if I want to find out if an account already exists, I can simply just try to create an account with that email address. If the creation is successful, then I know the account doesn’t exist. If it isn’t, then I know it does.
If you’d like to implement this on bubble’s login, fine. But please don’t force this on our apps. You can already mimic similar behavior simply by changing both error messages to say the same thing.
Unfortunately we already committed them to other initiatives. Plus, we have a mentorship gap here – we were hitting some technical issues that required attention from senior people on the team. I want to get this staffed up sooner rather than later, but we do need some people’s time to free up
I think at this point we’re done recruiting testers
Not to speak for the forum moderation team, but my guess is given that there wasn’t much engagement on that thread from the community, it’s probably on the back-burner
That’s basically all we’re doing. Right now the feedback is internal, because there’s enough things we want to improve we don’t feel like asking users to spend time on it is a good use of their time yet, but during the alpha testing we’ll get user feedback as well.
We haven’t written off making more radical changes in the (distant) future, but:
We think switching to CSS would make it easier to make radical changes down the line if we want to
We think switching to CSS is a big enough win for our users to justify the project even without more radical changes
We want to tread very carefully with changing the “you can just draw whatever you want” paradigm. There’s a lot to learn for new Bubblers in terms of the programming features, so the “you can just draw” piece lets new users get up the learning curve on the data / workflow side without having to really wrestle with responsive. There’s pros and cons, and there might be a best-of-both-worlds solution, but we’ve had pretty good luck over the years at getting complete beginners to working apps, and don’t want to break what works. Doesn’t mean we can’t do something innovative, but it’s not simple or straightforward.
I hear you, but what we’ve been seeing is a lot of platforms and security audits have been increasingly enforcing this as a requirement. While I agree differentiated messages are slightly more user-friendly, our users kept running into issues with this (for instance, Salesforce’s platform is apparently rejecting any apps that have this behavior). Your mimicking suggestion is smart, but we send the underlying error code as well as the message, so a hacker would be able to tell the difference. So, feedback noted, but I think this likely on-net saves pain for our users.
Understood. Would it be possible then to give us the option in the app settings to choose which behavior? Or perhaps allow for different error messages (that default to the same message for new apps) but the same error code? This seems like for many apps it could prove a decent usability hurdle that at best improves security marginally, at worst encourages the use of easier-to-crack passwords.
Hi, I am eager for this very thing, Bubble is amazing in design flexibility and data relationship, but it’s major achilles heel for me is the expression system, both for allowing more complex logic and better expression editor (right now is a mess editing an existing dynamic expression). Implement a good condicional logic (case, if) along with internal expression variables (let) would allow to make almost anything.
Hope @josh can check this out and say if there is something about this in the roadmap.