This outlines the expectations Million Labs has regarding development of applications using Bubble.io. It summarises the best practices that we have collated for the delivery of software with this platform. 

Basics

There are some simple rules every Bubble developer should follow: 

• Name all your elements clearly. “Group J copy” is no use to anyone. 

• Always change the page Title form the default

• Use the style sheet religiously. Elements should not have styles removed. If you don’t have a relevant style, create one.

• Ensure that all the basic information in the settings tab like icons, SEO information, brand colours and the clients admin email are set. 

• Install the client’s URL and test the DNS settings. You may have to help the client set the DNS up correctly. 

• Make sure that API keys for Google and Sendgrid are added to an app. Use the clients keys. Do not use Million Labs keys. 

Implementing the User Interface

Don’t have multiple copies of a page for different use cases. Have a single page with conditional elements and re-use the workflows. Maintaining duplicate pages inevitably leads to errors. 

Always use styles. Every element should have a style applied. Some general style rules: 

• You should not require more than a handful of text styles.

• Make sure text styles have consistent font, spacing, sizing and colours.

• Make sure that inputs have consistent font, spacing, sizing and colours. Check the focus state and the invalid state are also consistent. 

• Set padding for groups. Groups should have at least 10px internal padding where it contains text images etc. 

• Do not forget to ensure that infrequently used elements like date pickers, picture uploaders etc are also consistent. 

If an application is responsive it should be built in the Bubble responsive setting (now mandated) and should look good at all screen sizes from 320px wide up. “Look good” means: 

• No overlapping elements.

• Elements should wrap before minimum width makes them look bad or unreadable.

• Where elements do not work for mobile (like tables) make sure they are replaced by a form factor that does (like cards) using conditional hide and show. 

Pages are usually set to be columns (with internal groups stacking vertically). Internal groups should be used to manage the position of elements on the page. Groups should almost never be set to ‘Fixed’. 

Try to follow good mobile and desktop design standards. There are plenty of good resources online for this and so we won’t repeat them here. Example: (https://uxdesign.cc/8-rules-of-mobile-design-1b8d9936c241). 

A tiny sprinkle of animation is a delight. A lot of animation makes your project look like it was created for a 13 year olds web design coursework. 

Hover states are for desktop apps. Think about how people know what to press next on all devices. 

Storing and Recalling Data

Data should be stored and linked in the most efficient way possible. Tell tale signs of a poor data architecture: 

• You perform a ‘do a search for unique ID’ (or similar) to find a link between two records rather than using a link like ‘this shop’s product’;

• You are using an advanced filter

• You are referring to a list in a repeating group rather than on a row of data

• You need to use hidden inputs on the page to perform calculations

• You need to use list states where a list on a data field would be more effective

You should never need to create a blank record in the database that needs to be cleared up later. If blank records are occurring in a workflow, revisit your workflow. 

Try to avoid creating workflows that require multiple ‘Make changes to step one’ actions as these are prone to issues. 

Repeating groups should almost never be set to recall all items in a database. 

If you are using a database to load options into a drop down menu consider whether it would be possible to use an option set instead. 

Personal data should never, ever, be stored in a database that has no privacy rules set. 

When deleting a thing with a file attached to it, delete the file first. 

Workflows

Some simple standards: 

• Be tidy: On busy pages use workflow colours and folders to make things easy to identify.

• Duplicate Workflows: Don’t have many duplicate workflows. Create one Custom Workflow and call it with triggers. 

• Branching: Consider where you use a conditional statement to branch a workflow. A workflow that has many action conditions is a bad workflow if that could have been avoided by having a conditional statement on the Event itself.

• Back End: Where possible schedule long workflows on the server (backend) to allow the user to get on with using the app. 

• Show and Hide: Use states to manage what is visible rather than multiple show and hide actions.

Third Party Services

When adding a third party service (like stripe) to a Bubble application you should: 

• Ensure that you are using the clients account and that you have been given developer access. Do not use the Million Labs account. 

• Ensure that the client understands any licensing or ongoing costs that they might incur and when they will be charged. 

• Be careful to create secure authentication using the standard set out in the services documentation.

• Do not locally store data that is not absolutely necessary. For instance:

• Financial information like card numbers;

• Personal data like names and addresses;

• API keys and tokens

• Make sure you test the third party service in development and live environments before you hand the application over to the client.

Remember Plugins often have a licensing cost and are part of the page loading process. Unused plugins should be removed and you should check that they are no longer subscribed.

Security and Privacy

It is incredibly important to protect customer data and privacy. Failing to do so can result in huge liabilities for our clients and reputational damage to Million Labs. Some simple rules: 

• Personal customer data should never be visible to the public. A user must be logged in to see any personal customer data.

• Customers that are providing data should consent to its use and should have access to enough information that allows them to understand how their data will be used (like a privacy policy)

• Customers must be given access to the means to update or delete their personal data from the application. 

Remember: Static data that is hidden on the page and only visible when a condition is met is insecure. Dynamic data is secure but not where the information is visible on page load and hidden by a condition. Any data that you wish to be secure should not be visible on page load and should be loaded from a data type. Note: option sets are not secure, these are visible on page load.

All Bubble data type must have relevant privacy settings: 

• Data always public - no privacy is required;

• Users should only be able to access their own data (no access is granted to any other user): “This Things Creator is Current User”;

• Data is visible to all users that have logged in: “Current User is Logged in”.

Where Backend workflow public API's are enabled always ensure that authentication is required to access any data that is not public. 

Customers may ask about the security of their data at rest and in transit. The correct response is to point them to Bubble’s own security information as it changes from time to time: https://bubble.io/security

Before Handover to a client run the Million Labs Bubble Security Checker on the app

https://app.millionlabs.co.uk/bubble_security_checker/

Performance

Some basic rules that are simple to follow: 

• Pages: Don’t make people load a new page for every step of a user flow if showing and hiding groups achieves the same experience. Page loads are slow and frustrating for users. Conversely you should not overload a single page with interactions, it will be painfully slow on initial load (and difficult to maintain). There is a balance to be struck here;

• Page Load Workflow: Don’t overload the ‘On Page Load’ workflow. Think carefully about the actions you require and whether a requirement can be resolved another way (for instance by using fields within the User Record)

• Data: Try to load data in an efficient manner. Don’t try to call hundreds of rows of data from data types or API all at once. Try to make searches efficient through good data architecture rather than using filtering. Try to avoid modifying data on page load as this has more impact on performance than, say, changing a state.

• Elements: Don’t load MB’s of data on page load. Only load what you need. Bubble loads the code for all elements on a page (visible and invisible) on page load. Consider making dynamic elements rather than duplicating an element;

• Images: Optimise your images. Use smaller, high quality SVG if possible; 

• Other: Options sets and plugins also load on page load. Get rid of unnecessary plugins and keep your option sets light;

Testing

During the delivery of a project you should test: 

1. Each function (workflow) that is delivered

2. Each integration that is delivered

3. Each end to end user flow

While we understand that you will complete functional tests and integration tests during the build phase a complete end to end test should be completed: 

1. At the end of the build phase (Smoke Testing); 

2. After all bugs have been resolved; and/or

3. At the end of the completion of any change request (Regression Testing). 

When the project is completed the application should be released into the live environment and version controlled. Clients will then be asked to complete their own tests to sign off their acceptance of the application (User Acceptance Testing). After all testing is complete please ensure that you have deleted all of your test data. 

Where an application is released to Google Play and IOS App Stores we will also use ‘Sauce Labs’ for Android and TestFlight for iOS to complete device testing (Mobile Testing).

Before you hand over an application you should run the Optimiser (Settings - General - Optimize application) to remove all extraneous files and images.