As explained in Design Systems, a Design system is a conceptualization of what design is in systems development.
It implies the definition of tools, practices on the one hand and on the other hand the definition of various interaction and visual elements.
Although in GeneXus there are modeling objects that allow defining various elements of what would be a Design System in GeneXus, we want to go one step further in the re-conceptualization of the design modeling in a knowledge base.
In this sense, GeneXus introduces a new type of object: Design System Object, which will be the conceptual basis on which design will revolve in the coming years.
In this sense, the design will revolve around this new concept, which, as its name says, is exactly the representation of a Design System within a knowledge base.
The Design System object has some basic design concepts:
- Allow consistency at various levels of granularity of the multiple experiences built with GeneXus.
- The modeling language will be closer to Front-End developers and designers than to programmers.
- The Design System object will be the source of truth inside a Knowledge base.
Although at some point there may be graphic editors for the language, what was defined is a textual language since we believe that front-end developers are more productive using textual languages after the first steps, achieving greater productivity in the short and medium-term. .
For the selection of element styles within a Design System we have selected a language similar to CSS. In fact, one can use class definitions used in CSS.
As previously mentioned, this object will be in evolution and will shape the design within GeneXus.
In this sense, this first version of the Design System Object begins with two well-defined parts:
A token is the most basic element of a Design System that allows you to capture an option for visual or interaction design.
A token allows you to model a – platform-agnostic– choice of color, typography, spacing, time, media, zindex, border, opacity, size.
With tokens, you can give options for low-level values of your product.
Having a Token set for your Design System will allow your product to be more maintainable and consistent in terms of design.
Styles are a way of representing the design decisions we have made for our system. Together with tokens, they form a fundamental part of the design system.
Nowadays, the way we define styles is with the classes of the theme object.
Within the design system object, this new section is presented, which is the Design styles and provides a simpler way to define our classes.
We have several useful scenarios for the Design system object in mind, but what we are doing at this stage is releasing a first version that already solves some existing pain points in interface modeling in Genexus.
One of the usage scenarios that we already see with the current state of the Design System object is that designers can substitute the use of the Theme for that of the Design System object to start shaping and have better control of all the details of the generated CSS without any type of overhead for a given panel.
This is why in the first version of the Design system object it can be used exactly in all the places where a Theme is used.
Here you can get a sample XPZ. The scenario is related to Travel agency, applying a custom design system to some specific front-end objects
By now you have probably seen the overlap of the Design System object and Themes.
The use of Themes will be reduced over time and it will be the Design system object that will conceptualize and add relationships with other objects in the future.
Therefore, when in doubt about making a new Theme or Design system object, don't hesitate, start with a Design system object.