OutSystems UI Framework: Past, Present, and Future
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.
“It is impossible to live in the past, difficult to live in the present and a waste to live in the future.”
(Frank Herbert, Dune)
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 offers?
Prelude to Foundation
“It is not important what can or cannot be done. What is important is what people will or will not believe can be done.”
(Isaac Asimov, 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?
“To succeed, planning alone is insufficient. One must improvise as well.”
(Isaac Asimov, Forward the Foundation)
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
“Intuition is the art, peculiar to the human mind, of working out the correct answer from data that is, in itself, incomplete or even, perhaps, misleading.” (Isaac Asimov, Forward the Foundation)
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
- Layouts
- 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 to update 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.
We took the opportunity to update and improve the code on some of these patterns. In each new framework, we made an effort to reduce weight and present the most elegant and performant solutions. We started by removing the jQuery dependency on OutSystems UI Web, using exclusively Vanilla JavaScript, and later introduced modern CSS features, like Flexbox and CSS variables.
With the help of a newly aligned spectrum of browsers, we could also use the new CSS features without worrying about compatibility issues. And with it, we were able to reduce the use of JavaScript to a bare minimum in some cases.
One of the best examples is the new Gallery UI pattern. Before, we needed a long script to deal with the width and number of items calculations. Now, the CSS takes care of that work for us. We use JavaScript to create CSS variables based on the input parameters, and these variables are then used together with CSS Grid to create a clean, performant, and responsive gallery.
How Everything Works Together
“Past glories are poor feeding.”
(Isaac Asimov, Foundation)
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.
Styles Foundations
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.
UI Patterns
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.
Templates
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 beginning, 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.
Screen Templates
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.
“We are born of one breath, one word”
(Tool, Pneuma)
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?
Originally published at https://www.outsystems.com.
