After using bubble now for some months and building succesfull some (complex) custom solutions, I´m at a point where I was wondering how to decide how to structure pages and groups in which case.
I´ve built an inhouse solution with multiple functions like a CRM-database, profiles, dashboards, project management and some workflow-based functions for internal and external use. (e.g. an approval workflow for content approval with access for our customers)
I´ve built our internal solution with three pages.
- index with login and register
- internal page
- customer page
Our internal page now has about 35 “first-level”-groups and i seperate them with custom states.
Negative: The development gets more and more complex and slow because of the mass of data in the design- and workflow-tab.
Positiv: We´ve got nearly no loading times while using/navigating inside our app.
At the moment I am working on a project for a customer to manage their internal service workflows for their caravan workshop and trading.
On this app I gave every “main function” a seperate page. Like one for customers, one for customer-vehicles, one for contracts, one for service-tickets and so on. Inside these pages I used the same technique as I do in our internal app - groups with custom states.
Negative: The navigation between the seperate pages is slower.
Positive: The development is much much easier and feels more structured.
Now I am wondering if there are any “rules” or general recommendations for how to structure the pages and groups in which usecase and how you guys are doing that.
Best wishes from germany!
Use workflow folders. They will help you stay organized on the pages where you have a lot of workflows.
Use reusable elements for app pages and/or components. This is especially important if you are building a single-page app (SPA). It will help you keep it nicely organized and modular.
The best of luck from Texas!
The workflow folders are great, but keep in mind the best thing for dealing with the Workflow tab loading times is not having too many workflows in the first place.
Which is a topic that ties back into reusable elements…
In your example of the caravan workshop and trading app, instead of having each main function living on a separate page, you could build it as a SPA and put the content of each of the pages inside of a reusable element instead, which you would then toggle on and off as required.
Taking this one step further, if you have certain workflows that currently reoccur across different pages, you could also remake those as custom events in a reusable element and trigger them from any page or reusable element that the reusable element containing the custom events is present on:
You can also turn parts of the UI that commonly reoccur throughout your app into reusable elements. For example, a project management app that I’m currently working on has a reusable element for the user’s avatar that shows either the user’s profile picture or, if there’s no picture uploaded, the first letter of the user’s first name. To avoid rebuilding the same thing across a bunch of different places—the navbar, a live chat similar to Slack, an element showing which users have access to the project, an element showing which users are on the current user’s team, all sorts of popups, etc.—I placed it inside of a reusable element and just reuse it everywhere without unnecessarily burdening the app with remaking the same thing over and over again throughout the whole app.
Two more things to keep in mind:
Custom events can have parameters, which basically makes them the Bubble version of functions in most programming languages. Depending on the specifics of your app, that may allow you to reuse custom events for usecases which may be similar enough, but not identical. (It sounds like you may have a few of these.)
Reusable elements don’t have to be a group. They can be popups (and that is especially useful for complex apps) and floating groups, too.
Thank you so much for that extensive input!
Would you, in general, say that if the app is too complex, a SPA is not the right way? Or would you say there is no limit making it not too complex in development?
@jf1 You are welcome!
Without going too deep into a discussion what “too complex” means in this context, I’ll just say I haven’t built a single multi-page app (MPA) since I saw the light of the SPA approach.