In the realm of mobile applications, it is common to encounter the need to modify existing features. These changes can range from significant facelifts and the introduction of new functionalities, like mobile deep linking to minor adjustments such as color modifications, image replacements, or content updates.
These minor changes, particularly content changes in text fields, are time-consuming and unnecessary expenses.
In this article, I present a potential solution to this issue while showcasing a more advanced variation that our team implemented.
Let’s consider a typical scenario in one of the products we are building, Jamdoughnut: an application with multiple screens and various content elements, including a “Gift section” that features horizontal cards containing images and accompanying texts. Suppose the marketing team identifies the need to modify the content within these sections due to inadequacies.
Traditionally, this would entail engaging two developers (one for iOS and one for Android) to update the text across all relevant screens manually. Subsequently, a test version would be created, published, and reviewed by a marketing team member before the developers proceed to generate a production version and submit it to Apple and Google App Stores.
Even in the best-case scenario, where this process only takes three days, it remains excessive for a seemingly minor change.
Static components
So, how can we streamline this process and achieve the same change in less time?
Let’s begin with reevaluating the developers’ approach. In the example above, the developers had to update the text on five different screens since they implemented each screen independently, including the “Gift section”. This fragmented implementation represents a significant oversight.
Instead, we can implement the “Gift section” as a reusable UI component that can be integrated into multiple screens. Consequently, when changes to the section’s content are required, modifications will only be made in one central location where the component was initially implemented.
Does this significantly save time? The answer is both yes and no. While it does accelerate the process of updating and testing the modified content across various screens, the more time-consuming tasks, such as building and submitting the application for review, remain unchanged.
Nevertheless, the component approach does not exhibit any notable downsides. When properly planned and designed, a component can offer flexibility, allowing for unique texts or images in each instance by adjusting the component’s parameters. However, it is crucial to note that a component should serve a singular purpose and avoid unnecessary complexity.
In some cases, it may be more advantageous to split a component into subparts or create distinct similar yet unique elements.
Backend driven components
While utilizing components can certainly enhance efficiency, it remains insufficient. Therefore we propose the adoption of a Backend Driven UI approach. This simple yet powerful concept involves storing content on a remote backend rather than within the mobile application itself. Upon application startup, the content is fetched from the backend and displayed accordingly.
With this approach, content can be modified in real-time without releasing a new application version. Users no longer need to frequently update their apps, while developers can focus on implementing new features.
How does content modification work with a backend? We highly recommend employing an admin site, typically a web page, where individuals, including non-developer team members, can easily access and edit content. Thus, in the previous example, the marketing team alone could access the admin site, make the necessary content changes, save them, and instantly observe the updated content within the application.
This process eliminates the need for developer involvement, obviates the requirement for new test or production builds, and reduces the overall time spent. Instead of a three-day process, it could be completed within 10 minutes.
How to do it
Now, let’s piece together the key elements required for this approach. Firstly, it is imperative to create well-designed and modular components that can be updated via the backend. Identifying the core aspects of a component that may be subject to backend-driven changes is essential.
These commonly include text content, images, decorative colors (such as background and text colors), and component positions or orders. Once these elements are identified, it becomes necessary to establish limitations and ground rules.
For instance, if the text content can vary, it becomes the content provider’s responsibility to ensure its length adheres to the component’s design constraints. Clear communication of these limitations should occur during the initial integration of components.
The next step entails implementing the backend infrastructure. This involves establishing the storage mechanism and creating a web-based content editor. Although there is yet to be a definitive recipe for this process, we recommend incorporating verification rules into the content editor to prevent common mistakes, such as incomplete fields or exceeding character limits.
Lastly, it is crucial to provide access to those responsible for the content provision and educate them on effectively utilizing the backend editor.
Advantages of backend-driven components
- Rapidly change and update the application’s context and user interface. Significant development efforts are no longer required for modifications, and errors can be rectified without necessitating new releases.
- Anyone can maintain the application’s content thanks to a user-friendly editor. No longer is developer involvement necessary for making changes.
- Users are not burdened with frequent app updates. Content modifications can be delivered without requiring an app restart.
- Development time can be reduced as final content does not need to be present during the initial development phase, enabling it to be added later.
- Reduced application size, as content is stored on the backend rather than within the codebase.
- Personalization of content becomes possible for individual users.
Disadvantages of backend-driven components
- The initial planning phase may be lengthier due to the need to thoroughly identify the components suitable for backend-driven updates, even in seemingly simple UI designs.
- Development may require additional time due to the creation of both mobile and backend components and the establishment of communication between the two.
- Displaying the final UI may experience slight delays as data is fetched from the internet, potentially resulting in longer loading times. The extent of this delay depends on the number of dynamic components within the application.
- To account for potential internet connection errors, it is necessary to plan additional UI elements to handle error states or loading indicators.
- It is important to note that while most screens can benefit from this approach, it may only be suitable for some screens. Some screens may become needlessly complex solely to enable dynamic changes.
Our advanced version
At VeryCreatives, we have already implemented applications using this approach and have taken it even further. For instance, at Jamdoughnut, we have developed a fully backend-driven Home Screen. Allow me to showcase what we have accomplished and how remarkable it is.
On the Home Screen, we have an extensive list of available merchants, banners for articles, banners for the “Refer your friends” screen, and a search bar. The merchants are visually represented as small cards grouped by categories. Our achievement here lies in making this entire page dynamically configurable via our backend.
Initially, we created backend-driven components for each specific item, including the Article banner component, Search bar component, Refer your friend component, and a horizontal carousel component housing the merchant cards. Each piece can be individually configured, enabling changes to text, logos, and even colors.
Next, we devised a vertical list capable of accommodating these components. To display the components, we require both the component type and an index for ordering purposes. Whenever a user visits the Home Screen, we fetch the component list from our backend without storing the order or types. This flexibility empowers us to alter the order of categories and banners during runtime without requiring a new deployment. Additionally, the horizontal carousels offer additional configurable options, such as the number of rows or card types.
To effect changes in the list, we have an active admin site listing all the Home Screen components. Each entry can be individually configured on a separate screen. Once changes are made, clicking the save button updates the content that users will see the next time they access the Home Screen.
Need help building the SaaS product of your dreams? No worries, we’ve got you covered. Book a free assesment call with us to get started!
