Hi Bubblers!
Wanted to release another part of our Best Practices doc, this one focusing on best design/layout principles for your Bubble apps. Topics like creating a design system, choosing between groups and pages, reuseables, and more are discussed.
Hope you find it useful,
Vlad
Canvas by AirDev
Good info. Thanks for sharing.
@vlad and team.
Just had a look at your guide. It’s really a very good and useful resource. I will be forwarding people and mysef to that guide.
You are filling the gap of best practices in Bubble’s documentation.
Keep up the great work.
Good stuff! Thanks, @vlad!
@vlad this is wonderful, thank you for sharing with the community!
I especially loved the bit on speeding up applications 
Thanks @oli, @sudsy, @JonL, and @gnelson! Really appreciate the positive feedback and glad that you’re finding the material useful.
This i really helpful. What is your suggestion with the size of the navigation bar on the left side? Should it extend all the way to the bottom of the screen? Should it just end when the text ends? Curious about what the best design for this would be.
Also, do you use a normal group for this? A floating group? Other?
Hey @vlad - this is great! I hadn’t seen a third-party best practices guide before, but this would have saved me a ton of time in planning layouts and data structures that I had to just learn the hard way. Keep it up!
Hi @J805,
Those are all very good questions.
What is your suggestion with the size of the navigation bar on the left side?
In general, the left side navigation bar should be less than the mobile width (typically anywhere between 250-320px - depends on the longest width of your text). In our Canvas template, the sidebar width is 285px.
Should it extend all the way to the bottom of the screen? Should it just end when the text ends?
For most portal/dashboard pages, the sidebar typically extends all the way to the bottom of the screen because there are usually multiple links. This format is also more scalable as it’s easier to add more links vertically vs. adding them horizontally in the top navigation menu bar (at some point, the horizontal menu will need to be hidden and users will have to click on a hamburger menu to view the menu options).
Another version of the sidebar you’ll see a lot is a sidebar that has no background. This layout is typically used when you have a lot of content on the page and want to make the page feel less busy. It might feel like the navigation bar ends where the text ends but in reality, the sidebar extends all the way to the bottom of the screen and only the right side is scrollable content.
Also, do you use a normal group for this? A floating group? Other?
Do you need the sidebar to always be accessible? If not, consider using a normal group for this.
If you do need the sidebar to always be accessible, then I would use a combination of normal group and floating group to get this effect:
https://share.vidyard.com/watch/wdt9XN6oNn5s3vUhV487ii
You can check out the settings pages in our free Canvas: App Foundation template to see how we used a normal group and floating group to set up that UI.
Hope this help!
Stephanie
Canvas by AirDev
Thank you for that wonderful reply! 
I have been playing around with it a bit and it has helped me tremendously to create a much more professional looking app. Crazy how just a few tweaks here and there can make a big difference. 
learned a lot from your guide. +1
Great stuff here, @vlad Thanks for sharing it.
Hey, just by chance, do you have a sample app -or some screenshots- for one single page with multiple groups using url parameters for navigation?
Regards!
Definitely @CapiBalid! An example is the Canvas Portal itself - most of it is one page with URL parameter navigation. You can get a similar page layout yourself if you install the free Canvas template, it’s the “Settings” page.
That’s a really nice UI, @vlad. I could have sworn, though, that using query string params for navigation allowed the browser back/forward buttons to work, no?
@sudsy - yep, you’re right it will allow back/forward buttons to work but we have the Replace the entry in the browser history option checked, which prevents that from working. So unchecking that will do the trick.
Aha, that explains it.
Thanks so much for putting this together, very useful and eye opening. I’ve been reading through the section about database structure and have a couple questions. Not sure if there was errors or not, so want to clear up my confusion.
In this it shows the datatype of Tweet having a datafield of original tweet with a field type of tweet.
Is this because there may be a tweet that is a reply to an original tweet or a new tweet that is actually retweeting a previous tweet and keep it all connected? Or, is it that the tweet is referencing itself?
I believe the “List of follows” should have a field type of “List of Users” instead of the single user.
I haven’t finished reading the entire document but have already picked up a bunch of great tips from it. Thank you again for putting it together and I highly recommend bubblers to read it not only in the beginning of their bubble experience but also after they have learned a bit to get a clearer view.
When I started a lot of this was over my head as I had no previous experience in app development what so ever, but after several months learning bubble it all makes sense to me know and is so much more valuable at this point.
So glad you’re finding the document useful! Some answers:
Do let us know if you have further questions.
