Gallery Apps
By Zeroqode Team
Various members of the Bubble ecosystem contributed these use case-oriented database guides. There's always more than one way to do something in Bubble, but the advice here can help you get started if you're new to Bubble!
Speaking about gallery type of apps will surely lead you to apps like Instagram, Facebook, Pinterest, and many others.
Gallery apps often come with features like image management by categories, comment threads for each image, likes/dislikes from other users, and others. We can use Instagram as an example of such an app.
The following article will show the recommended data types and option sets that can be a good starting point when developing the database of your gallery application. An app built with such data types will allow users to efficiently upload, manage and share images in a user friendly way.
The key data type is GalleryImage, which corresponds to the type of item being displayed in the gallery. Users upload GalleryImages, sort them into Categories and can create Comments on anybody’s Images.
The key data type that is used in this kind of application. Images can be stored both within the app itself or on third-party storage (to lower the database storage costs).
- image (image): most important field, where the image file itself is stored
- title (text): a title can help other users better understand the image
- description (text): in addition to the title, a short description can be useful too
- categories (list of Category): stores one or multiple Categories that the image is attributed to
Optional
- favorite (yes / no): lets a user mark certain of their own images as favorites, e.g. so that they can be displayed at the top of that user’s profile page
- Note: if you want to build the feature to allow other users to “like” another user’s image, that would most likely be its own data type and is beyond the basic starting point of this guide; see this documentation for guidance
- views (number): saves how many times the image has been viewed by users
Assuming this is a public gallery, where anybody can see the images in the gallery, we might not need any privacy rules on image since none of the fields are particularly sensitive. You may want to consider allowing the creator of an image to use auto-binding to modify some of the fields within their control, like the title, description, categories or favorite.
For better image management and UX, our app will be able to assign one or more categories to an image. This is conceptually similar to an “albums” feature or a “tags” feature.
- name (text): the category’s name
- images (list of images): stores the images assigned to this category
- Note: here we are choosing to both save the assigned categories on an image as well as save the assigned images on a category; this is effectively double-writing the data and this decision comes with its own advantages and disadvantages; see documentation to learn more
Since this is not sensitive information, we likely do not need privacy rules on this data type.
Publicly available images often come with a comment thread where any user can leave a comment. This data type stores each comment as its own thing in the database.
- contents (text): stores the comment text
- galleryimage (GalleryImage): attributes the comment to a specific image in the database
- hidden (yes/no): a useful field to have in case you want the ability to moderate comments
Generally our assumption is that all comments can be viewed by anyone, so again we probably do not need privacy rules here. If you want to build a moderation feature, you can create a privacy rule to not find any Comments in searches if ‘hidden’ is yes.
All apps come with the User data type. We’ll assume that there are different ‘levels’ of users in this app with different privileges
- displayname (text): stores the name the user wants to be publicly seen as
- role (User Type): stores whether the user has special permissions like moderator or admin rights
User information tends to be sensitive, so privacy rules are a good idea here. You likely want to create privacy rules so that only the user can see their own email address, for example, while the displayname field is what’s public to everyone. If you want admins to be able to see users’ emails too, that would be another privacy rule on User to allow that. You likely also want to hide the role of the user from anybody except themselves, moderators and admins. Note that if you have the role here, you can create privacy rules on previous data types we’ve seen (e.g. the hidden field on Comment) so that moderators and admins can update that field as needed.
- Fashion
- Cars
- Sport
- Health
You can extend this list to include any categories that fit your app and audience. It is also a decision you have to make as the app creator whether to have Categories as an option set or a data type - here is some documentation to help you with that choice.
- Admin
- Moderator
- User
This option set is used to define the available user types. Different user types can have different permissions in the app.
- On the homepage of the app, you could show all images in the gallery by using a repeating group doing a simple search for GalleryImage with no filters.
- For each user’s profile page, you can fill a repeating group with a search for all GalleryImages with the filter that the creator is the page’s user
- When you ‘click into’ a GalleryImage, you might have a page that just features that one GalleryImage with a repeating group that is filled with a search of all Comments where the galleryimage is the GalleryImage of the page
To make your app attractive, it would be nice also to integrate the possibility of image editing, adding short videos like Tik Tok, as well as receiving push notifications and following/unfollowing other users.
The suggested data types and option sets are just a recommendation, so feel free to build your app in your own style!
Last modified 1yr ago