If you are reading this, I’m pretty sure you are interested in front-end development, and this notion of creating a whole new universe caught your attention. Am I right, or am I right?

In this article, we’ll show you how OutSystems, as a development platform, can help you address the five atomic rules for starting your scalable front-end architecture. The atomic rules I’ll be focusing on this time are:

  • Defining the HTML layout structure and start working from that base skeleton
  • Controlling your CSS base
  • Using patterns

I’ll explain how you can create foundations from which anyone can build their own new worlds by using and following these somewhat simple rules. You can quickly become something akin to a Master Architect—the one who defines everything that is to be, the ultimate source of all knowledge your builders will eventually make use of.

Sounds all mystical and important, I know. It’s not mystical at all, but extremely important since it will enable other people to build upon and create amazing-looking apps quickly by reusing readily available resources.

Out of the Mist, Into the Mystical

We’re getting a little mystical, at least to start with. Imagine that the burden of creating a new universe falls upon your shoulders.

When you start considering the task at hand, would you start, right off the bat, by creating a planet with little people in there, blue oceans, and white-frosted mountains? Would you also consider that the red planet that is right next to that blue planet has an altogether different atmosphere and an amazing electric car flying its way?

Would you then kick it up a notch and start devising galaxies with millions of stars, and all these different planets, then other galaxies with a completely different set of stars and planets, side by side, in countless combinations?

Keep in mind that you’d have to create all of these one at a time. Can you imagine the sheer amount of work you’d have in front of you?

What I’m offering you is a much more efficient approach to universe building. You first define what your universe will have in it: galaxies with stars and planets in their orbit. After that, you take some time to define what constitutes a galaxy, a star, a planet.

After those characteristics are defined, you move on to patterns: the brightness of stars, the amount of water in planet soil, the atmosphere, asteroids, any other relevant astral entities...you name it. And these are the little things that people scramble to add to the unique galaxies in their universes.

Wouldn’t this way be much easier?

Welcome to Universe-building 101 with OutSystems. I promise we’re going to have some fun.

A template for an OutSystems Universe

Defining the HTML Layout Structure

As a good demiurge, you should always start by defining the HTML layout structure and take it from there. Wouldn’t it be nice if you didn’t have to do this all by yourself? And now you don’t, because OutSystems provides a layout block that enables you to avoid the proliferation of inconsistent layout structures. And, under the hood, it takes care of everything needed to make it work.

This block is included in the theme module if you’re creating web apps and in the application layout for mobile apps. It has a basic structure, with all the placeholders needed, to which you can then add content directly.

The centralization of these resources enables you to create pages and screens quickly and greatly reduces maintenance costs; when you need to make changes to your structure, they will be automagically propagated to all your pages and screens.

Additionally, you get a template module with all the required connections that will enable any future apps to work. It’s like a free pass to the heavens for junior developers, or developers that accumulate more than one specific role, because they can be productive from the get-go.

It’s All About the Base: Control Your CSS Base

With a predefined CSS base, you can create a myriad of resources by simply combining different styles. In the Silk UI Framework base CSS, you get a set of tested and widely used rules to reset your stylesheets and add extra definitions to remove the weight of mastering CSS from your shoulders.

These base rules were created from a wealth of knowledge amassed by an experienced team that is absolutely focused on evolving the product we deliver to match the latest market trends and needs. Everything you’d need to comfortably and confidently set very solid foundations on which your teams can start working on.

Silk UI takes the control of the CSS base to a whole new level: it provides a way to have different types of base custom themes, using multiple layers of CSS bases. This layering allows you to cover all of the most common scenarios for web and mobile apps.

2 different levels of CSS base 

On the Use of Patterns

With the layout and CSS base defined, it’s time to start creating all the patterns you identified and need. Or is it? No, you don’t need to! This is where, in my opinion, you reap the most benefits from using OutSystems. This is a game-changer when it comes to defining your front-end architecture. These are the kinds of things that can take your app universe to the next level, when it comes to scaling its processes.

OutSystems provides out-of-the-box patterns that you can just drag and drop onto your screen. In fact, Silk UI was born to consolidate these otherwise isolated UI patterns and make them all as available and reusable as possible.

You get a baseline of tried-and-true, highly tested patterns, but you also get the ability to extend those patterns and build your own. So, you’re not stuck with what’s available there; you can customize everything to your liking and still make the patterns reusable throughout your projects.

Should you need to create a new pattern during the course of one of your projects, you can approach its creation process by following three possible scenarios. There’s really no one-size-fits-all recipe here, but as a rule of thumb, I’d recommend trying to come up with something that makes use of a Silk UI pattern. It’s also helpful if you have a UX/UI team to consult, so that everyone can understand and ponder the benefits of creating from scratch versus reusing. Anyway, these are the scenarios:

  • Styling Silk UI patterns: This scenario, rated E for easy, uses the structure of Silk UI Patterns, so it doesn’t change the original structure, just the CSS. You get total support and maintenance from Silk UI.
  • Extending Silk UI patterns: This balanced scenario involves extending a Silk UI pattern by wrapping it inside a block so you still get Silk UI updates to the original pattern. I advise you to use it only when you need to add or remove elements from a Silk UI pattern. Only the original pattern is supported and maintained, not your customization.
  • Building a pattern from scratch or cloning a Silk UI pattern: Not for the faint of heart, this hardcore scenario results in your total ownership of the pattern with no support from Silk UI. You have to settle for increased development and maintenance effort and costs, along with an increased risk of bugs as new devices evolve and web standards change.

To further accelerate reuse, download the following set of Sketch files from Silk UI’s website and make sure you share them with your UX/UI folks. This will enhance their work, while reducing the overall need to start patterns from scratch.

Front-End Architecture at Enterprise Scale

Up until now, I’ve shared sets of best practices and helpful tips that will allow you to create bulletproof apps. In all honesty, all this comes together extremely nicely when applied in the context of a low-code digital factory.

To help you understand this a little bit better, we’ll fly back to Universe-building 10, and look at planetary development:

Imagine that you need to create a new type of planet with a mountain range that has seven peaks. If you’ve made good use of the layouts, CSS base, and patterns, you should already have an easy way to create a planet. You have a pattern called mountain that has a placeholder for a peak. So, when done right, all you need to do is to extend your mountain pattern to accommodate seven placeholders for peaks instead of creating a new pattern for this specific case.

Now imagine that instead of a planet, you need to create 250 galaxies with 10 planets each. Not so frightening anymore, right?

Use all the structures, styles, and patterns available, and you will feel absolutely godlike!

By virtue of combination and since you will have the structure detached from the style, you can apply the same structure to several projects; you can even combine it with different themes and also maximize the reuse of patterns.

A typical app universe in a Digital Factory

In a scenario like this, a factory that caters to three channels—B2B, B2C, and B2E— can make use of Silk UI as a base with corporate styles and branding added on top. And a team that defines a transversal vision for all the projects can manage and maintain this system ever more efficiently, since the entire front-end is controlled by them and, therefore, centralized.

This very notion of centralization makes it easier to maintain and evolve patterns or even promote them so they can be used throughout different channels or even the entire factory.

Creating cross-applicational patterns is a marked advantage when it comes to speeding up app development, but it needs to be handled with care. When done right, you can use those patterns in several applications: with the same structure and functional logic, even with a different style, if need be. When done wrong, though, well, let me put it this way: you should tattoo the following rules in an easily accessible place.

The 3 Cursed Don’ts

These three rules follow the same baseline. Abstract your pattern, think only in terms of structure:

1. Don’t Add Inline Style to Elements

Try to style only in CSS files, never directly in the HTML, otherwise you are instigating other developers to use !important to get rid of your code. And, we all know that !important should only be used as a last resort.

Cut my code into pieces, this is my last resort

2. Don’t Add Classes to Elements With Typified Names

Color names (.Black), measures (.Width20px), styling (.Bold) or sizing (.fontSize15): these are all bad practices. Try to use agnostic classes that scale better for multiple applications. Otherwise, the real value of the property may not match the suggested name.

3. Don’t Insert Business Logic in UI Patterns

They should be clean and ready to use for every project, regardless of the business.

Adding business logic to the UI will put you on the endless road of having the same UI pattern multiplied by 40,000 different business use cases.

Is This Some Kind of Paradise?

The straightforward answer is, “No, it’s not.” But the truth is that by using this methodology, development is greatly accelerated, and you will also decrease the margin of human error. Most importantly, though: you can scale or change your apps and apply new features everywhere at once or by phasing it at a pace that makes sense to your business.

Also, you can make use of your time in a way that truly adds value to the apps, instead of spending it on reinventing the wheel only for a specific requirement or a one-off. This will save you time, and will greatly contribute to your sanity.

My last advice is that you go through our training, particularly the front-end development courses, to fly into the depths of the universes that you have built.