Mobile app branding optimization
I want to share my experience in optimizing mobile application branding. By branding is meant creating a copy (“clone”) of the main application with a modified design and content. The main application that we will brand is a reference service for finding and buying movie tickets.
The need for branding arose because of the new business model of the Customer, the essence of which is that the cinema chain receives its own mobile application for free, and the Customer an additional channel for selling tickets. Accordingly, before the development was the task to minimize the cost of developing branded versions.
The main application is native (not based on html), consisting of ~ 20 screens, on two platforms: iOS, Android. A branded application is made for cinema networks already existing in the main application, essentially “filtering” the main application to the size of a specific cinema network.
The branded version should differ from the main application as follows:
The first version of iOS for a single cinema cost us quite dearly - the actual effort was 15 days. The task of reducing the development time of the next branded version was the technology of branding , that is, optimizing the basic processes of creating an application - from an incoming request to publishing an application.
We tried to optimize everything :
')
Corporate design of the application varies:
For typical interface elements, we use the tools of the graphic editor Sketch, which allows you to automatically change the color of all elements at once, which accelerated the preparation of the design.
When the design is agreed, it remains to "cut" the graphics for the developer. Here the designer had requirements for cutting and an example of cutting from the main application. As a result, the Android developer could only substitute a folder with such a thread into the project, and the updated graphical interface of the application was obtained immediately, without additional gestures.
For iOS it was even easier, since the icons were used in the SVG format and could be repainted programmatically. Therefore, for iOS, the main graphics were transferred to the developer in the form of a color scheme of the application:
All this made the preparation of graphics for both platforms fast, and the detailed formulation of the problem allowed the flexibility to connect any designer freely to this work.
On both platforms, the optimal organization of the code was seen in the general module of the code with the introduction of the parameters of the branded versions into a separate configurator. In iOS, the Viper architecture used allowed the application to be branded by simply replacing the display modules and services.
The foundations of a modular structure for the future "designer" of possible custom features of a particular cinema (in the form of an arbitrary element in tabbara) were also laid.
Since the code base is common for the main and branded applications, the development of the main application made it extremely popular to use unit tests to check the correctness of the functionality of all versions of the application when the code changes in the kernel.
In particular, first of all, tests were carried out to verify the correctness of data parsing, which worked immediately for all branded versions.
As the application versions became more and more, we set up a build server, which, when the code in the project's code changed, automatically rebuilt the builds of all the branded versions, and laid them out in a convenient form for testing (Fabric taxis!). Thus, the time spent on preparing for testing and publishing was reduced.
From the third branded version there was a question about their accounting and control in a convenient form. Without further ado, Google Sheet was selected with a table with technical and management information on key project milestones.
For the convenience of our partners, we have made step-by-step instructions explaining every step that the cinema needs to take.
According to our business model, the cinema application is provided free of charge, and this imposes a number of restrictions on the application. Therefore, the problem of unwarranted expectations of cinemas immediately surfaced. For example, we can not offer cinemas "any" additional functionality, and therefore gave a lot of failures to cinemas on their Wishlist. Of course, such refusals could have negatively added to our relations with cinemas, therefore, in order to adjust the expectations of cinemas, we supplemented our cooperation proposal with a description of the restrictions on the provided application relating to:
The initial survey of cinemas showed that the application must be a kind of designer, from which the necessary functionality could be assembled for each cinema. In particular, the talk was about a personal loyalty program, share promotions, restaurant reservations, popcorn purchases and 3D points for a session. However, after working out the requirements for some of the "Wishlist", in particular, on the integration of the cumulative card under the loyalty program, it turned out that the integration will be very expensive, and will not scale to all cinemas, since many have individual loyalty programs. Thus, the majority of similar “hotelok” did not fit into our business model of a cheap branded application.
As a result of this screening, from the great and terrible requests “add me an erp key here, please”, there was only the opportunity to add a few cinema elements to the menu that opened a webview with links to cinema pages with the necessary content, such as News, Promotions, Restaurants .
The need to maintain multiple versions has led to the fact that the application must be updated in the app stores when critical changes accumulate in the application core. And since all applications are template, to minimize costs, the update will take place without notifying the cinema and agreeing on changes to the application. The same applies to the approval of the changes. True, given that all changes are being made to improve the application, no one has yet complained.
All this anticipated the birth of unwarranted expectations at the cinema about the application and did not lead to negative points in communication with them.
After the creation of the 1st application, it turned out that the bottleneck in the chain is that cinemas provide their own accounts for publication in the App Store and Google Play. It was originally planned that the application will be published in your own cinema account, which in fact was the competitive advantage of the application.
However, in practice, it was extremely difficult for cinemas to agree on setting up and paying for Android accounts ($ 25 one-time), not to mention the App Store ($ 99 annually).
Therefore, it was decided to offer the possibility of publishing under our account. Suppose that in the line the name of the developer of the application is not a movie theater, but our company, but in this way already 7 cinemas could have received applications!
All of the improvements described in the creation of branding technology have borne fruit. From the initial 15 days to the first version, the costs have decreased, starting from the 4th branded version, to ~ 4 hours for developing the code for the new version for iOS and up to ~ 6 hours for Android (on the graph, rounded up to 1 day of development).
The moral of this story is that consistent work on each process from the approval of the application to its publication leads to saving work time, and therefore to what customers like so much - to save the budget.
The need for branding arose because of the new business model of the Customer, the essence of which is that the cinema chain receives its own mobile application for free, and the Customer an additional channel for selling tickets. Accordingly, before the development was the task to minimize the cost of developing branded versions.
Introductory
The main application is native (not based on html), consisting of ~ 20 screens, on two platforms: iOS, Android. A branded application is made for cinema networks already existing in the main application, essentially “filtering” the main application to the size of a specific cinema network.
The branded version should differ from the main application as follows:
- Have a cinema identity
- Satisfy one of 3 possible types:
- for one cinema
- for the network of similar cinemas
- for a network of cinemas with different corporate identity - Maintain custom functionality.
Branding cost optimization
The first version of iOS for a single cinema cost us quite dearly - the actual effort was 15 days. The task of reducing the development time of the next branded version was the technology of branding , that is, optimizing the basic processes of creating an application - from an incoming request to publishing an application.
We tried to optimize everything :
- Design
- Development
- Management
- Support
')
1. Design: two clicks, please!
1.1 Layouts
Corporate design of the application varies:
- colors and application logo,
- Startup Screens for Downloading Content
- icons for additional webview with customer content.
For typical interface elements, we use the tools of the graphic editor Sketch, which allows you to automatically change the color of all elements at once, which accelerated the preparation of the design.
1.2 Cutting
When the design is agreed, it remains to "cut" the graphics for the developer. Here the designer had requirements for cutting and an example of cutting from the main application. As a result, the Android developer could only substitute a folder with such a thread into the project, and the updated graphical interface of the application was obtained immediately, without additional gestures.
For iOS it was even easier, since the icons were used in the SVG format and could be repainted programmatically. Therefore, for iOS, the main graphics were transferred to the developer in the form of a color scheme of the application:
All this made the preparation of graphics for both platforms fast, and the detailed formulation of the problem allowed the flexibility to connect any designer freely to this work.
2. Development and support
2.1 Code
On both platforms, the optimal organization of the code was seen in the general module of the code with the introduction of the parameters of the branded versions into a separate configurator. In iOS, the Viper architecture used allowed the application to be branded by simply replacing the display modules and services.
The foundations of a modular structure for the future "designer" of possible custom features of a particular cinema (in the form of an arbitrary element in tabbara) were also laid.
2.2 Using automated development tools
Unit tests
Since the code base is common for the main and branded applications, the development of the main application made it extremely popular to use unit tests to check the correctness of the functionality of all versions of the application when the code changes in the kernel.
In particular, first of all, tests were carried out to verify the correctness of data parsing, which worked immediately for all branded versions.
Build server
As the application versions became more and more, we set up a build server, which, when the code in the project's code changed, automatically rebuilt the builds of all the branded versions, and laid them out in a convenient form for testing (Fabric taxis!). Thus, the time spent on preparing for testing and publishing was reduced.
3. Management
From the third branded version there was a question about their accounting and control in a convenient form. Without further ado, Google Sheet was selected with a table with technical and management information on key project milestones.
4. How we improved interaction with cinemas.
4.1 Instructions for theaters to get their own application
For the convenience of our partners, we have made step-by-step instructions explaining every step that the cinema needs to take.
4.2 Adjustment of expectations
According to our business model, the cinema application is provided free of charge, and this imposes a number of restrictions on the application. Therefore, the problem of unwarranted expectations of cinemas immediately surfaced. For example, we can not offer cinemas "any" additional functionality, and therefore gave a lot of failures to cinemas on their Wishlist. Of course, such refusals could have negatively added to our relations with cinemas, therefore, in order to adjust the expectations of cinemas, we supplemented our cooperation proposal with a description of the restrictions on the provided application relating to:
- design (only logo and colors)
- custom functionality (webview only)
- application changes
- application updates in stores
Custom functionality
The initial survey of cinemas showed that the application must be a kind of designer, from which the necessary functionality could be assembled for each cinema. In particular, the talk was about a personal loyalty program, share promotions, restaurant reservations, popcorn purchases and 3D points for a session. However, after working out the requirements for some of the "Wishlist", in particular, on the integration of the cumulative card under the loyalty program, it turned out that the integration will be very expensive, and will not scale to all cinemas, since many have individual loyalty programs. Thus, the majority of similar “hotelok” did not fit into our business model of a cheap branded application.
As a result of this screening, from the great and terrible requests “add me an erp key here, please”, there was only the opportunity to add a few cinema elements to the menu that opened a webview with links to cinema pages with the necessary content, such as News, Promotions, Restaurants .
Application development and updates on the App Store
The need to maintain multiple versions has led to the fact that the application must be updated in the app stores when critical changes accumulate in the application core. And since all applications are template, to minimize costs, the update will take place without notifying the cinema and agreeing on changes to the application. The same applies to the approval of the changes. True, given that all changes are being made to improve the application, no one has yet complained.
All this anticipated the birth of unwarranted expectations at the cinema about the application and did not lead to negative points in communication with them.
4.3 Bottleneck - accounts for publishing
After the creation of the 1st application, it turned out that the bottleneck in the chain is that cinemas provide their own accounts for publication in the App Store and Google Play. It was originally planned that the application will be published in your own cinema account, which in fact was the competitive advantage of the application.
However, in practice, it was extremely difficult for cinemas to agree on setting up and paying for Android accounts ($ 25 one-time), not to mention the App Store ($ 99 annually).
Therefore, it was decided to offer the possibility of publishing under our account. Suppose that in the line the name of the developer of the application is not a movie theater, but our company, but in this way already 7 cinemas could have received applications!
results
All of the improvements described in the creation of branding technology have borne fruit. From the initial 15 days to the first version, the costs have decreased, starting from the 4th branded version, to ~ 4 hours for developing the code for the new version for iOS and up to ~ 6 hours for Android (on the graph, rounded up to 1 day of development).
The moral of this story is that consistent work on each process from the approval of the application to its publication leads to saving work time, and therefore to what customers like so much - to save the budget.
Source: https://habr.com/ru/post/295920/
All Articles