GoodBarber at the AppDays 2016 : Feature Templates, Open Product...
Written by Muriel Santoni on
![Credit: Philippe Barbosa Credit: Philippe Barbosa](jpg/10678413-17595484e527.jpg?v=1480428266.61034)
Credit: Philippe Barbosa
For the second year in a row we decided to attend the AppDays, the leading event related to everything mobile held in France. In 2014, we couldn't make the trip because the dates coincided with the Web Summit event in Dublin. As a result, AppDays 2015 was our first experience, and a positive one which is why we decided to make the trip again in 2016, with the intention to share our expertise in software development and the evolution of GoodBarber.
Whenever we can, we try to make you a part of the events we attend, be it through social media only, or even with tickets to allow some of you to attend. This year, for AppDays, we were able to send out a few invitations to some of our Resellers. The event also extended the favor with discounts for GoodBarber clients that couldn't get an invite!
On our end, the team members making the trip were Mathieu , Dominique , Jérôme and Muriel . We enjoyed every chat on and off the event, exchanging experiences and getting feedback about our product. A special thought goes to Olivier Waubant from l'Atelier des Applis , as well as Julie and Gregory from happyngood , thank you for the contagious enthusiasm!
On our end, the team members making the trip were Mathieu , Dominique , Jérôme and Muriel . We enjoyed every chat on and off the event, exchanging experiences and getting feedback about our product. A special thought goes to Olivier Waubant from l'Atelier des Applis , as well as Julie and Gregory from happyngood , thank you for the contagious enthusiasm!
Feature Templating
![Credit: Philippe Barbosa Credit: Philippe Barbosa](jpg/10678413-175960696854.jpg?v=1480494924.4732392)
Credit: Philippe Barbosa
This year, we got to introduce our development philosophy to the informed audience of the AppDays.
The GoodBarber adventure has seen its share of landmarks, evolving from a service company delivering apps to a more industrialized app building process, which lead to GoodBarber as you know it!
During our conference, we walked down memory lane to show the audience how we transitioned from one stage to the next, with one challenge: ensuring a high standard of performance, minimizing complexity and maintenance costs while the number of projects in production kept increasing.
The GoodBarber adventure has seen its share of landmarks, evolving from a service company delivering apps to a more industrialized app building process, which lead to GoodBarber as you know it!
During our conference, we walked down memory lane to show the audience how we transitioned from one stage to the next, with one challenge: ensuring a high standard of performance, minimizing complexity and maintenance costs while the number of projects in production kept increasing.
A challenge we overcame with a different approach, after coming to this conclusion:
- Two different apps are actually often more alike than they seem.
- The more apps in production, the more complex the maintenance process.
Once we came to terms with that observation, it seemed obvious to focus on the initial investment part, meaning: what can we achieve today to spare us a lot of work tomorrow?
So far, the way we had been operating consisted in creating a specific app core for each project, with generic re-usable modules.
We decided to look at it the other way around and reverse that logic, creating a generic app core, commonly shared throughout projects. And build upon that generic core, with specific bricks (re-usable or not) to cater to the needs of each client. And that's how our new approach came to be!
- Two different apps are actually often more alike than they seem.
- The more apps in production, the more complex the maintenance process.
Once we came to terms with that observation, it seemed obvious to focus on the initial investment part, meaning: what can we achieve today to spare us a lot of work tomorrow?
So far, the way we had been operating consisted in creating a specific app core for each project, with generic re-usable modules.
We decided to look at it the other way around and reverse that logic, creating a generic app core, commonly shared throughout projects. And build upon that generic core, with specific bricks (re-usable or not) to cater to the needs of each client. And that's how our new approach came to be!
Our philosophy is a compromise between two diverging trends:
1/ Using micro components, which allows for a large commercial offering but requires pooling the different modules for each project
2/ Creating the project as a "mold", where the app is a standalone component, which allows to save time when it comes to development, but considerably narrows down the commercial offering.
Our guideline: creating medium-size components in charge of a specific feature.
This strategy does introduce a few constraints before launching the project, but it optimizes the maintenance stage.
Also, to ensure stability of our projects, we decided to configure these components, not through lines of code, but with descriptive parameters.
The investment consists in foreseeing every possible usage scenario of a given feature, in order to integrate enough parameters to leave room for customization.
The resultant is a brick structured assembly, with each brick tested individually to facilitate pooling.
If you want to learn more about how we've been using Feature Templating, the recording of our conference is available here (the talk is in French):
1/ Using micro components, which allows for a large commercial offering but requires pooling the different modules for each project
2/ Creating the project as a "mold", where the app is a standalone component, which allows to save time when it comes to development, but considerably narrows down the commercial offering.
Our guideline: creating medium-size components in charge of a specific feature.
This strategy does introduce a few constraints before launching the project, but it optimizes the maintenance stage.
Also, to ensure stability of our projects, we decided to configure these components, not through lines of code, but with descriptive parameters.
The investment consists in foreseeing every possible usage scenario of a given feature, in order to integrate enough parameters to leave room for customization.
The resultant is a brick structured assembly, with each brick tested individually to facilitate pooling.
If you want to learn more about how we've been using Feature Templating, the recording of our conference is available here (the talk is in French):
What's the status on GoodBarber Open Product?
![](jpg/10678413-176052648079.jpg?v=1480496525.2261415)
Last year, during AppDays 2015, we unveiled a new project, GoodBarber Open Product. Throughout the year we’ve gathered insightful feedback which brought us to rethink this project.
We shared GoodBarber Open Product with a narrow circle of partners, in its alpha version. We're glad we did because it's only when confronting an idea to reality that one can really mesure its relevance. We are also very well aware of the fact that more of you would have enjoyed taking part in the experiment, but GBOP is a side project, with not enough resources to include a large number of alpha testers.
On paper, GBOP was a great idea, but in practice we came to the realization that it placed too many constraints on developers. The way we first thought out GBOP required to develop for iOS, Android as well as the web. A huge workload! Furthermore, a lot of developers mentioned that not being able to use the back office of their app anymore made for a loss in fluidity when it comes to selling apps for clients. Indeed, when the GoodBarber engine is forked, compiling the project must happen outside of the GB environment.
We've therefore decided to rethink GoodBarber Open Product and apply the "Feature Template" philosophy explained above. The idea is to stick to a very generic native core, maintained by GoodBarber, and capable of evolving independently, regardless of the interconnections with modules. Now, among those modules, bricks developed in Angular JS by developers will integrate seamlessly. With one unique language, apps will be enriched, regardless of the platform they operate on.
We think this is the best approach to allow third party to extend the functional perimeter of GoodBarber. We now have to find the time to perform the necessary adjustments for everything to function. But rest assured, we are really looking forward to making this a possibility, and as soon as we find the time, we'll definitely move the project forward.
On paper, GBOP was a great idea, but in practice we came to the realization that it placed too many constraints on developers. The way we first thought out GBOP required to develop for iOS, Android as well as the web. A huge workload! Furthermore, a lot of developers mentioned that not being able to use the back office of their app anymore made for a loss in fluidity when it comes to selling apps for clients. Indeed, when the GoodBarber engine is forked, compiling the project must happen outside of the GB environment.
We've therefore decided to rethink GoodBarber Open Product and apply the "Feature Template" philosophy explained above. The idea is to stick to a very generic native core, maintained by GoodBarber, and capable of evolving independently, regardless of the interconnections with modules. Now, among those modules, bricks developed in Angular JS by developers will integrate seamlessly. With one unique language, apps will be enriched, regardless of the platform they operate on.
We think this is the best approach to allow third party to extend the functional perimeter of GoodBarber. We now have to find the time to perform the necessary adjustments for everything to function. But rest assured, we are really looking forward to making this a possibility, and as soon as we find the time, we'll definitely move the project forward.
See you soon
All in all, the 2016 edition of the AppDays was really enlightening for us, to collect valuable feedback on our product, but also share our take on the flourishing market of mobile apps.
Stay tuned for our next stage!
Stay tuned for our next stage!