This article aims to be a guide for designers in order to understand how GeneXus will interpret what you draw when designing an application.
: Before reading the article, you must know that there are two main rules for achieving a good-looking application on the first try:
1. Keep your design simple.
2. Be tidy when designing.
The developer will appreciate you follow these rules.
Symbols are used for reusing common elements in your design.
GeneXus will interpret these elements of your design as Stencil objects, and they will be named as they were named in your design.
Artboards define the area where a designer will draw every panel of the application.
GeneXus will interpret these elements of your design as Panel objects (if it is a mobile application) or Web Panel objects (if it is a web application), and they will be named as they were named in your design preceded by a "View" prefix.
Links allow the designer to define how the Artboards are related between them, including animations.
GeneXus will interpret these Links between Artboards as Calls between Panels or as a Return command in case of Back-Links, including a Form Enter/Exit effect transition when it has been set.
- These interactions are modeled in GeneXus through the Event of the control that represents the layer with the link.
- Remember to avoid loops when designing the interaction through links between artboards.
Images, as every designer knows, are resources of vital importance in any application to easily improve the user experience and captivate your audience. Also, there could be complex controls (like calendars) or drawings (like icons) that should be marked as Exportable (with the appropriate densities) in order to generate an image for them, and then the developer can easily integrate them into the application.
GeneXus will interpret both of these resources as Image objects that will be stored in the Knowledge Base and they will be loaded in the target panel with a Variable based on the Image data type.
Texts, as every designer knows, are fundamental elements in any design for the simple fact that they communicate information to the end user, and not only through the content itself but also in the way the information is presented, involving sizes, colors, distribution, typography, casing, anchoring (responsive behavior), etc. What's more, in order to reuse that 'pieces' of visual information you want to convey, it is highly recommended that you use Text Styles.
GeneXus will interpret texts as Variables based on the VarChar data type that the developer can change if necessary. Every text will define a style-class in the Design System Styles section unless you define Text Styles, in which case those text-layers that share the same Text Style will also share the same Class property value (i.e. same style-class). If your Text Style defines a color, it will be added to the #color type in the Design System Tokens section and referenced by the target style-class.
Also, if your text has custom fonts, GeneXus will import them as File objects, include them in the Design System Styles section as a @font-face rule, and set them in the corresponding style-class.
Styles are meant to be a way to reuse visual design, distinguishing two categories: Text Styles (described in the previous section) and Layer Styles. For this last category, a designer is able to define Fills and Border styles.
GeneXus will interpret Styles as style-classes in the Design System Styles section. If your Fill/Border styles define colors, they will be added to the associated the Design System Tokens section, specifically in the #color type, and referenced by the target style-class.
Color Variables aims to define a color scheme for your design. As you may know, colors can contribute to how your design is perceived by humans, helping them to better understand the application and how to interact with it.
GeneXus will interpret Color Variables as elements of the #color type in the Design System Tokens section, which will be referenced by the target style-classes defined in the Design System Styles.
Resizing Constraints are vital features for manipulating responsiveness in your design. Take into account that your application may run on devices of different sizes and resolutions. So, use fixed sizes when your layer must not grow or shrink, and pin-to-edge those elements that must not change its position.
GeneXus will interpret Resizing Constraints when it generates the Table control that will contain the controls the designer has drawn. Every control will be placed in a cell in the Table that will have a relative (%) or absolute (dips/px) size and position depending on the constraint you set. In case you overlap controls, GeneXus will generate a Canvas control instead but it also applies a Z-Order property in order to define the overlapping order.
These sections apply as of GeneXus 17.