Creating a screen
As a use standard, you must start with a prebuilt app that already has sample screens. The screen data must be modified before saving it, to ensure that it is adapted to the specific needs of the project.
If a prebuilt screen cannot be used, you must read the the App Layout Templates and Flex Container component documentation to make sure you follow the standards and best practices defined to build a new screen.
Screens are created and configured using the screens editor in Studio. To learn more about the use of the editor and its features, read Screens Editor.
Screen configuration
When building an app screen, it is crucial to follow certain best practices to ensure consistency as the project advances. These practices are applied through different stages during the building:
Settings Definition
Before saving the screen, you must complete the following fields:
Important
The name, together with the View/area and Sequence make up the id of the screen that appears in the navigation and whenever you need to invoke that screen from other entity (for example, from an event or a lambda process).
View/area: This drop-down menu includes the areas defined for the layout to be used. You must understand the layout configuration to define the adequate layout.
Note
In the case of a mobile app, the view/area is always Contents1.
Sequence: It is an alphanumeric datum, which must start with the letter S followed by the Name identificator (see below).
Name: It identifies the screen. In fact, it is part of the whole name. Important: these three identificators together make up the id that appears in the navigation. For example: VV01|contents1:S009;footer:S008.
Description: brief text that explains the purpose of the screen.
Tags: words that help you and your project team easily identify the screen. You must also follow naming conventions for tags.
Read Screen Naming Conventions below to apply best practices when defining the settings mentioned.
Screen Naming Conventions
The screen name must be defined according to naming conventions defined for Veritran entities. To learn about naming conventions for screens and its components, read Naming Conventions. In addition, consider the following best practices to guide you in defining the name.
Language: use English.
Consistency and semantics: name screens clearly and consistently, using descriptive names that reflect their function, such as login or user_profile.
Compound names: preferably, add context instead of abbreviating words and avoid duplicating unnecessary information.
Reserved words: do not use words reserved by the platform or words that are too generic such as: Main, Page1, Component, Test, Screen1, among others.
Visual organization: group screens by features or module. To name them, follow these standards:
Use prefixes and suffixes to to group related screens by section, while facilitating search and maintenance. Example: login_intro, login_onboarding, among others.
If the screens are inside a module and the module already carries the name of the section, do not use it in the screen name.
Avoid using the expression screen.
As a recommendation, use a site map or information architecture document (IA) to help you define the hierarchical structure of the screens, using separators such as / or - to represent section breaks.
Interdisciplinary collaboration: naming should be defined in collaboration with the technical leader and the designer, ensuring that the site map reflects the app structure and flow.
Discussions with the team: Involve other team members in naming decisions to make sure identificators are intuitive and functional.
Important
At this stage, you define acronyms, names and structures. As the project advances, these definitions are crucial for order and consistency. It is important to spend time defining and agreeing with the team on how to name screens. The leader in charge of the technical aspects of the project is in charge of ensuring an adequate organization of the screen building process.
Treeview Review
As mentioned before, the standard is to duplicate the prebuilt screens for your app and configure them according to your project's needs. Then, you must review the treeview of your screen. It is essential to ensure that the visual structure of the screen is optimal and adapts correctly to different devices, especially for mobile devices. For this, you must apply the best practices defined below.
Components in the canvas
To configure a screen, you must drag and drop the components in the left panel to the screen canvas, while ensuring that best construction and naming practices are followed.
The use of components in screen building involves dragging and dropping elements into the work area. It is important to follow established practices to ensure that the components are integrated in a coherent and functional manner.
The components are dragged and dropped within the defined areas of the layout. As a best practice, components must not be placed outside of a specific area (such as a header, content or footer).
To learn more about components and how to use it, read Screens Editor.
When adding components to the screen canvas, you must follow the best practices listed below, related to the component attributes configured in the right panel.
Veritran Components
The configuration of components in the canvas is the final step in the process of building screens. This document details how to configure library components to ensure efficient and effective integration into the final product.
A component, either native or configurable, is a reusable set of interface pieces designed and developed with visual and functional consistency. Each component encapsulates both appearance and behavior, while facilitating its integration into any part of the digital product.
The correct implementation of basic and advanced components, together with the strategic use of the Veritran components, guarantees a consistent and high-quality user experience. Using components in the screens editor offers the following benefits:
Scalability: it allows building digital products faster, while reducing duplicated work.
Consistency: it ensures a unified experience across the entire interface.
Development speed: it reduces time-to-market by avoiding having to design and configure each feature from scratch.
Errors reduction: less repeated code means fewer bugs.
Improved collaboration: it facilitates communication between designers, developers and product managers.
The screens editor in Studio contains the Components tab, which includes both Native and Configurable, components.