This article aims to be a guide for those developers who start their application development by importing a design file. Also, it provides tips and good practices.
In the early stages of a Design Integration cycle, it is recommended that you (as developer) start importing a design with just a few panels at a time. Following this mechanism, developers and designers can not only learn from each other but they can also see how the application starts growing. On the other hand, while a developer starts coding the designer can start drawing a new panel for the next iteration, repeating this cycle until you have a fully functional application.
Remember that you (as a developer) have a powerful tool for inspecting the UI at runtime: Live Editing. This tool will help you to find design mismatches that you can easily fix for achieving a great looking app. Also, do not forget to check the Native Mobile Applications Prototyping article in case you desire to import a mobile design.
The Import Design tool can identify and interpret elements in the design file as the objects listed below. Take into account that for achiving a good-looking result the designer should have followed the guidelines provided in the guide for designers, conventions, and best practices.
Stencil objects are generated from Symbols / Components defined by the designer.
Remember that these objects aim to be reusable in multiple panels, so check if you can identify components in your application that should be reusable, and tell your designer to make a new Symbol. Also, check if their instances are correctly applied (overridden values, theme-class applied, etc.) -- you can find those instances by looking at the References of the target stencil.
Panel objects or Web Panel objects are generated from Artboards / Top-Level Frames defined by the designer depending on whether you checked the Import as Web Panel option or not.
The Layout tab of these objects will be generated from those Groups that the designer defined, and controls will be generated through the conventions applied. In every table, the cell sizes (width/height, absolute or relative) and positions will be generated from Resizing Constraints defined by the designer. Take this into account when importing in case the designer forgot to apply some rules in the design for achieving a good result. Also, if the designer has linked its panels, the Code tab will have the corresponding Call event, and a Form Enter/Exit effect transition is applied if the designer included animations.
Image objects are generated from the images included in the design and also from the layers marked as 'Exportable' (e.g. logos drawn by the designer). These images should have been exported by the designer with the correct densities (1x, 2x, 3x, etc.) in order to display them correctly in the target platform; otherwise, a black image is displayed as a placeholder.
A set of File objects (.otf, .ttf) will be generated for all embedded Fonts in the design file. Then, those Files will be referenced as @font-face rule in the Design System Styles section. Finally, set them in the corresponding theme-class (the Class property value of the target control).
A #color group will be generated in the Design System Tokens section and will include those colors defined by the designer as Sytles, especially as Fill, Border, or Text styles (every color will be suffixed with one of these three categories), and also will include every color defined as Colors Variable / Style in your design.
A set of style-classes will be generated in the Design System Styles section. Every control will have its own style-class unless the designer has defined Styles for it. In case you reimport a design file, remember that the properties will be overridden if you modified them by hand.
Each style-class will inherit from a parent prefixed with a "ExternalDesign" string. For example, if GeneXus infers the tyle-class of a Variable, it will generate a theme-class of an Attribute class that inherits from a "ExternalDesignAttribute" class (similarly to other theme-class categories).
Depending on your project requirements, you can adopt different strategies when using the Import Design tool (or even hybrid strategies) taking into account their pros/cons and considerations.
In this approach, the designer defines each main frame of your app along with its elements, ready for import. While this process may take time iterating with your designer to achieve the best result, it ensures that the front end is fully prepared, leaving no room for ambiguity during development.
Similar to the previous approach, but with shorter exchange cycles with development. Keep in mind that the Import Design tool will override objects without merging. In that terms, it is highly recommended to import a new iteration of a design in a predefined module for that purpose (using the Module option) and then manually merge it into the main branch. Evaluate iterations carefully and consider manual adjustments to avoid a new import if that implies minor changes.
Focus on defining individual components such as icons, buttons, and cards. Create a Main Frame containing instances of these components as a reference for developers, and provide clear instructions to follow on how every component should behave (e.g. when focusing, hovering, etc.). Be aware of any known limitation (described in FAQ and Troubleshooting section) and try alternatives when something cannot be modeled as you design it.
These sections apply as of GeneXus 17.