With the release of OutSystems UI, a single UI framework that supports both mobile and web applications, we took a significant step towards achieving our vision for the front-end of the platform. Launching this unified framework was a very challenging process, and here I’ll provide a developer’s perspective of what was the past and present, and what you may expect from future UIs at OutSystems.
You’ve probably heard about the recent release of Reactive Web, and how it changes the way you develop your applications. If you didn’t, we have a forum post and an article where you can read all about it. But, in short, it provides you with unparalleled performance, great UX/UI, a unified development experience, and a state-of-the-art framework.
For everything to work together, we needed to have UI elements that supported the new development experience and to come up with a solution. But first, we had to ask ourselves a few questions:
Which tools can we create to help accelerate the user interface while using OutSystems? What impact can Reactive Web have on the platform’s broader vision for the UI?
What changes can you expect from the current and future offer?
Prelude to Foundation
As with any success story, according to the legend, it all began as a secret project in a basement. That project soon flourished as the first version of Silk UI Web, a framework to build traditional web apps interfaces. Its massive adoption made clear that we needed tools to accelerate building the UI in the OutSystems platform, and a few years later, we introduced Silk UI Mobile.
In 2018, we updated the framework and introduced new pattern capabilities. With it, we created a design system that would be the foundation for all the UI in OutSystems. This was a crucial step, and you can learn all about it in João Guerra’s article: OutSystems UI: A design system foundation.
The only way to go was forward, and with that in mind, we’ve introduced OutSystems UI Web, a new framework for web applications. Consequently, Silk UI Mobile was also renamed to OutSystems UI Mobile to keep it consistent.
We then had a framework to assist each supported runtime, but it was time to start unifying the experience. It would not only simplify the offer available to the users but also help manage the maintenance effort on our side.
How Did We Get Here?
As the new reactive runtime shared several features introduced on mobile, the first big decision was easy to make. OutSystems UI Mobile would evolve to become OutSystems UI.
For that to happen, UI patterns and layouts had to be updated to reflect the new design system. It meant that they had to be compatible both for web and mobile, and also offer the functionalities that were already introduced in OutSystems UI Web. All this without adding any breaking changes in existing mobile apps, keeping the transition process as lightweight and streamlined as possible.
No pressure there.
UX research is an essential and powerful tool, but it can only get you so far by itself. You should define exactly what you need from it, otherwise it can become a never ending cycle in the bigger process.
With this in mind, we started by analyzing the state-of-the-art UX/UI elements and filtered them by the target apps of our product. We focused on understanding the improvements we were aiming for in five significant areas:
- Patterns, charts, and widgets
- Responsive behavior
- Screen templates
- Customization needs
Our goal was to increase confidence in our framework’s offer. Not only to align it with UX/UI standards but also to guarantee that it would provide the best tools for your projects.
We then cross-referenced the compiled information with the usage metrics of our patterns to validate our research. Maybe some patterns were not as frequent as others, but if we knew they were commonly used in Silk UI or OutSystems UI Web, we wanted to update and support them as well.
We then used the same approach for the new screen templates, identifying the most frequent screens on target apps. From those, we picked the ones that could be abstracted in a single template to accelerate the most common use cases. At the same time, we also kept an eye on the usage metrics from OutSystems UI Web.
As soon as the vision was clear, we started developing the framework by defining the technical path that would enable the new architecture.
OutSystems UI Architecture
To avoid any compatibility issues between old and new frameworks, we needed a clear and robust architecture. This meant that the applications and modules sections had to be restructured to accommodate the new experience.
Now, both OutSystems Charts and OutSystems UI are libraries. To use them for Reactive Web apps, you’ll need to install OutSystems Templates, and for native apps, you need OutSystems Templates Mobile. Both contain the respective templates and screen templates.
With OutSystems UI, we needed to avoid breaking changes on legacy mobile apps, while also adding new features to support web apps and the new design system. To mitigate the risk, we kept the old mobile base theme, and at its base, the phone and tablet themes.
The base (default) theme, was created with Reactive Web in mind, and following the design system, styles, and CSS variables. It’s similar to what we had done with OutSystems UI Web, but applied to mobile patterns. This meant you could reuse most of the OutSystems UI Web style guides on the new reactive runtime, with minimal effort.
Further ahead, we intend on updating the native mobile theme so that it also uses the new design system. For now, new native apps will look the same as they did before.
OutSystems UI Development
After researching and building the main architecture, it was time to have some front-end fun!
First, we needed to make sure that all patterns were prepared to work both with legacy mobile style classes and with the new ones coming from OutSystems UI Web. This part wasn’t as fun as it involved dealing with massive spreadsheets and writing code with needles, but it was essential if we wanted to enable reusing OutSystems UI Web CSS in Reactive Web.
Gallery preview on the new OS UI Website.
How Everything Works Together
Up to this point, we’ve covered the whole process that supported building OutSystems UI. Now, let’s see how it works and what you can do with it.
OutSystems UI is our personalized version of Brad Frost’s Atomic Design, which is a methodology that advocates a modular approach to front-end development. Through it, not only we have defined and documented rules for the most basic UI elements, but they are directly connected to the skeleton of all patterns, ensuring a much more scalable and maintainable framework.
Let’s now get through every piece of this module framework.
As mentioned already, OutSystems UI now supports the design system introduced in OutSystems UI Web. This means all elements of the framework were built using a cohesive and defined set of rules, such as colors, headings, margins, and paddings, which are represented on the CSS variables that you can find at the start of our CSS theme.
These variables reflect in the utility classes available and the new design system Parameters, such as color, shape, size, and space. Therefore, if you change those variables, they’ll impact the elements. You can consistently customize the look and feel of your application, a lot faster.
Example of design system parameters on the Tag.
All patterns now have an ExtendedClass parameter, allowing you to quickly use the utility classes from your style guide or our design system. You don’t need a wrapper div to add a class, and in some cases, you can even avoid making a clone.
Additionally, other patterns, such as CardSectioned, now have additional options like orientation, allowing a more flexible and easy customization.
We also improved support inside Lists, adding the capability of using an unlimited number of items. This is particularly noticeable in patterns like tabs or wizards, which had a fixed number before.
We removed the layout selection from the “New Application” step at the start of the experience, moving it to a new “Layout” flow. You don’t have to commit to such a big decision at the start, and can more easily switch between layouts. Additionally, we introduced three new layouts to build Reactive Web apps.
On top of the offer we already have on OutSystems UI Web, we’ve added a new Layout Base. This can be used together with LayoutBaseSection to make full-width sections, which is perfect for homepage screens.
All these layouts have configurable breakpoints for each device, using the new action SetDeviceBreakpoint on your ApplicationStart. We’ve also added new options to define different menu behaviors to the Layout SideMenu.
New Menu behaviors for Layout Side Menu.
We have ten new screen templates for web apps, ranging from dashboards, galleries, lists, and details. We planned to start slow, with a collection of screens more focused on UI and specific scenarios, followed by periodic releases. The best examples focused on specific situations are the Master-Detail and Bulk Action screen templates, made exclusively for Reactive Web, that aim to accelerate two complex UI use cases.
A Unified Framework For Reactive Web
Quickly recapping, we evolved the OutSystems UI Mobile framework, took Mobile out of its name, and added support for web use cases. That’s how we got to OutSystems UI, and now it doesn’t matter if you’re building a responsive web app or a native app. The patterns are the same, and so is the CSS and your style guide.
OutSystems UI is a definitive step towards a unified and more cohesive UI experience on the OutSystems platform. One that will enable you, the developer, not only to develop faster but to deliver a more consistent, performant, and modern application.
If you want to know more about what’s new in OutSystems UI, or how this works, visit our new OutSystems UI Website. It contains the most relevant information, as well as a preview of all our patterns and screen templates. Besides, the website itself was built using exclusively OutSystems UI. How great is that?