Widget as a Service
Enterprise Widgets to accelerate feature developments
When we develop an application or game we want to do it as quickly as possible, precisely to be able to go on the market and start receiving feedback from our users.
But how can we do it if our products sometimes have so many functionalities that we have no other way than to redevelop them?
Well, there is something that at etermax we named Widget as a Service and that comes to help products by delivering lego pieces to build the application or game we want.
Wait wait! What is a Widget?
A control element in a graphical user interface — an element of interaction, such as a button or a scroll bar.
- Wikipedia
I don’t know about you, but when somebody names me the word widget, the first thing that comes to mind is the weather widget that I have on my cell phone. Right?
Although widgets are also often named as components, I like to say that widgets are more than components, that they are autonomous components.
If we quickly analyze the weather widget in the photo above, we can understand that clearly the operating system (iOS) does not understand anything about weather, but loads this widget that is going to fulfill a particular task, which is to show the forecast and the temperature. It even has different ways of representing itself, such as:
And what does this have to do with developing products or games?
Well, imagine that the Operating System is the product and the functionalities it has inside are widgets that fulfill particular tasks, let’s list some examples that we usually see in games:
- Shop Widgets: List of products, List of products by category or tag, percentage of offers, timer of offers.
- Authentication Widgets: Email forms, buttons like login with Facebook, Apple, Google, Instagram, Twitter… ok… you got it.
- Missions/Quests: List of missions, missions by priority, progress, tags or even notification alerts.
- Ranking Widgets: Users list, ranking timer, the user’s current place or league.
- Economy Widgets: User’s balance (coins, gems), resources with time like lives or energy.
What I named above sounds like functionalities that we clearly want to reuse in all our products, or minimally have them available in case the product would need it at some point.
But the question is how can we deliver these Widgets?
Etermax Development Evolution
To understand the previous question it is necessary to give a little more context by showing the history of our developments.
- Years ago each team performed all its functionalities, from the product business, views, UI components and backend. This caused each team to have to perform the functionalities from scratch and it was obviously time consuming to create a product (between 6 months and 1 year).
- Then the Platform team, also known as Foundation or Core, was born to provide generic services, from the backend to C # clients for our games in Unity. This sped up the product developments but they still had to make the components to show the data that those services provided.
- Today we are embracing the concept of Widget as a Service. Each functionality has a library of Widgets that already know how to represent the information and how to react to user input. We are creating these widgets as they are needed in the products.
Basically it is to tear a monolithic application into small autonomous pieces, so that the product can focus on its business rules, achieving developments between 2 and 4 months.
Widget as a Service Properties
To achieve this, from Platform we had to list some conclusions that define when a Widget can be used as a service.
Widget Library
The delivery should be a package that contains a collection of widgets that represent functionality in different ways. Such as the missions-widgets package. Also the package should be versioned and it can scale in the future by adding more widgets.
Autonomous Components
What makes this flow so rich is that the product does not have to know how a widget does its tasks, the product just orchestrates them. Widgets are like a black box that know how to obtain data, react to user inputs, give feedback and emit events towards the product.
Here we see an example of integration of the questions-widgets package.
No Product Rules
Widgets are free components, they do not know their context or how and when it’s going to be used. The advantage of not having product rules within the widgets gives teams the flexibility to put the necessary rules where they need to be.
Extensible
Important for a product is not to get caught up in not knowing what to do when the widget library does not deliver what it really wants to represent. Internally, there must be a design that allows teams to extend and create their own widgets, providing them the data as fast as possible.
Collaboration
With the previous point, something that ends up making this flow even richer is the collaboration of the products to the library. When a product develops its own widget then it can add it to the package and the content will grow with each product needs.
Context Deconstruction
With widgets, the product can create the contexts it wants, and when I speak of context I mean views or screens that make the product unique.
In the following example we see how the Home or Landing Page context is composed of different widgets, lightening the productive code of the project.
Conclusion
Widget as a Service is a powerful model that allows companies to build a foundation of the functionalities they have in their products that over time will be further enriched.
I share with you the craft conf talk where we explained all about this. Enjoy it!
