Page layout and naming conventions
For a consistent user experience across all components/domains, it is helpful to stick to the following guidelines.
These guidelines simplify decision-making for developers and ensure that users are able to recognize patterns and know what to expect, regardless of the Novulo components they are using.
This article suggests a basic layout for a new generic page within a Novulo application. Please stick to these patterns, unless you have a valid/strong reason to deviate from them.
How to name pages and grids
When you define a new concept, in the Architect you have to dedicate a new page to it to define its features.
Imagine you created the concept N_Product and you want to create a page to describe all features of a product its relations to other records.
Within Novulo there are some pretty straight forward naming conventions:
- Grid: When a record can be accessed via grid, give that grid the same name as the concept, but in plural form.
- Example: The main grid that contains all products is named “Products”. You can extend it with additional text to make filtering more clear. For example, “Sales products” and “Purchase products”. However, make sure to add at least one grid under settings/overviews that contains no filtering and only the name “Products”.
- Example: If you link several products to a supplier with a grid, the title of that grid has to at least contain “products”. You can extend it with additional text to explain eventual filtering. For example: “Available products”.
- Page: Give the page and the first panel on a page the name of the underlying record, but in singular form
- Example: The user clicks on a row in a list of “Products” (or “Purchase products”) and expects to end up on a page of a “Product”. Therefore, the page should be named “Product”. If you want, you can extend the page name with additional text to make it more unique, but never replace it completely. For example: “Product - 123456” is fine but “Rubber Duck - 123456” can be confusing. From the title alone one cannot deduct that the page is a “product”. Be also aware that the page name should also be reflected in the titel of the first/fixed form panel.
How to structure a basic page?
A page consists of panels and grids. Via the More - Menu users can choose what content a page will contain, depending on their individual need. (See 6, 9 and 11). You can recognize it because of the dashed lines of the tabbed panels. When you create a new page in the Architect, you some panels are will be fixed (see content of 1). This means, the user cannot choose to hide them, if the information on those panels is not important for him. Therefore, you have to ensure that all content that you place on the main panels contains key information.
A standard layout of a new page looks like this in the Architect:
- Fixed PageRow5050: Every page should contain at least one fixed pagerow at the top. A page row that contains 2 equally wide sections is the default for a new page. If you do not have strong reasons to differ from this layout, simply stick to it since it is the most common. Examples for exceptions are M7811 - Magazijn odrachten scannen and M4177 - Novulo Kassa. These components are not indented to simply describe a record but they have a focus on supporting different processes from a single screen. User feedback highlighted the benefit of a 6633 (3366) layout over a 5050 layout.
- Fixed form name: To add UI elements, you first have to add a form. A form has a name/label. The first panel on a page, on the top left, should always have the same name as the page. (see previous section “How to name pages and grids”). This label defines the context for all other panels and grids on the page. Users will also use this label to find this record on other places in the application which will help them while creating their own mental model of how records relate to each other.
- Fixed form rows: All information that is placed in the first panel (e.g. not on a tabbed panel) has to pass the following test: “Does every possible user of this page need to see this information?” The answer should always be “yes” since the first panel will be always visible to all users of this page. Features, settings or properties that do not pass this test have to be placed on a “tabbed panel” or need to have suited visibility conditions (6).
- Fixed links form: The first panel on the top right is reserved for important links to other records. If a record does not have one to one (many to one) relationships with other records, you can omit this panel. However, be aware that in the future these links might be necessary if other components add them. So it is wise to just add it and give it a visibility condition of false to reserve the space for future links.
- Fixed search links: In this panel, use search links instead of dropdowns. Search links give the possibility to navigate to related records since they are displayed as actual “links”, and dropdowns don’t. Add dropdowns to the left panel, if they are important enough. Furthermore, if the record has a single parent (e.g.: Parent: Product, Child: Product versions) place the parent at the top since it is the most defining link that the record can have.
- Tabbed panel: All content that does not fit the criteria of 3 and 5 has to be placed on “tabbed panels”. This ensures that the user has the freedom to see (and load) only the content that he requires. Give the panel tab a name that sums up all of its content without being too generic. This is not always easy. Ask colleagues for help if you cannot find suited names. Never use one of the following names since they are too generic: “Advanced, Settings, More, Extra, Other, …”. Read the next section for more info.
- First form in tabbed panels: Give the first form in a panel tab the same name as the tabbed panel. Why? Once a tabbed panel is placed on the page, its name (which is used in the “More” menu and on tiles) is not visible anymore, but only its forms. If a user adds “Optional content” to the page via the MORE menu, he expects to see a panel/grid with the name “Optional content” appear on the page. Also, when the user selects a tile that is called “Optional content” he expects to navigate to “Optional content” and not to some other place.
- Links form in tabbed panels: If the optional content consist of links to other records, stick to the same rules explained in point 5.
- Tabbed panel with optional grid: If you want to relate more than one record of one type to your page, use a grid on a tabbed panel for this. Grids should always be placed on tabbed panels, since loading its contents requires a lot of resources, which can eventually slow down page loading. Therefore, users should be able to choose whether they want to spend that waiting time or not. Make sure that the panel has the same name as the grid.
- Optional grid on a tabbed panel: Stick to the rules mentioned in the previous actions about “How to name a grid”. Always include the name of the record type (in plural), to ensure that the user will have the right expectations about the page he is about to open.
I shouldn’t name my tabbed panel “Settings” but how am I going to add settings then?
In step 6 of the previous section, the following guideline was stated:
[…] “never use one of the following names since they are too generic: Advanced, Settings, More, Extra, Other, …”
To find a suited name for your tabbed panel (11 & 12) that should contain settings, you can choose one from the available predefined names below:
| Name English | Name Dutch |
|---|---|
| Sales settings | Verkoopinstellingen |
| Marketing settings | Marketinginstellingen |
| Purchase settings | Inkoopinstellingen |
| Logistics settings | Logistiekinstellingen |
| Realisation settings | Realisatie-instellingen |
| Service settings | Service-instellingen |
| R&D settings | R&D-instellingen |
| Finance settings | Financiële instellingen |
| HR settings | HR-instellingen |
| Management settings | Managementinstellingen |
| Application maintenance settings | Applicatiebeheerinstellingen |
Every domain has a “Settings” icon that looks like a gear (
), colored with the domain specific color. Always apply the correct icon from the correct domain to such a “tabbed panel”. This ensures that the tabbed panel will show up under the correct domain in the “More” menu".
Keep in mind that the name of your tabbed panel should also be the name of the first form (rule 7).
The decision to strictly separate settings tabs per domain emerged from the experience that generic tabs quickly become very cluttered. This makes it hard to find the correct setting and to maintain an overview of all related settings. To give you an example of what should not happen: This is how the “Settings” tab of the product page looked at some point. Unrelated settings are next to one another and panel names are incoherent, which makes it hard to find the correct information.
Visibility conditions OR When should UI elements be hidden?
By default, UI elements should be visible. If you apply the previous rules as intended, the user will have the choice to add only the forms and grids to the page that he is interested in. Therefore, visibility conditions should not be used for “page customization” but only to hide otherwise misleading or duplicate information.
If none of the statements applies to your situation, then you should leave the visibility of your UI element to “true”:
- The UI element shows wrong or misleading information
Example: Some UI elements only make sense under certain conditions. For example a label that reminds he user to fill in a certain field. When the field is filled in, the label should be hidden, since it would otherwise show misleading information. - The UI element has a “twin” that contains the same information, and one of both elements is always visible.
Example: The selection of a “contact person” on the sales page is split up into two UI elements to simulate a “clickable dropdown”. Even though this construction might not be beautiful, it is a valid reason to hide otherwise duplicate UI elements (M3445). This usecase is not needed anymore for 3.8 applications, since searchlinks have “dropdown-like” recommendations. - The information that the element contains is strictly intended for “behind the scenes” expressions or processes.
Example: The “Cached filter amounts” grid on the products page M5253. - The information is dependent on another, single visible element on the page and it is only useful depening on a certain setting
Example: The Product page has a checkbox ‘is sales product’ and fields to show the default sales item and sales price. The default sales item and sales price should be made invisible if it is not about a sales product. However, the checkbox ‘is sales product’ should always be visible, to show users the option exists. - To be continued…
Non valid reasons:
-
“The UI element shouldn’t be used by users because of XY, and therefore I want to hide it so that the user can’t mess it up with strange inputs.”
Textfields, dropdowns, searchlinks, grid etc carry important information, even when they are not intended for use. Firstly, it shows the user that certain features exist. Even though he might not use the features now, he might want to use them in the future. Instead of hiding UI elements they should become “uneditable”. It should be clear to the user why those UI elements cannot be used right now. This enables the user to change the conditions that prevent him from using the elements, if he wants to. -
“The UI element is empty because of XY, and therefore I want to hide it so that the user is not confused by empty UI elements.”
Textfields, dropdowns, searchlinks, grid etc carry important information, even when they are empty. Firstly, it shows the user that certain features exist. Even though he might not use the features now, he might want to use them in the future. Instead of hiding UI elements with a visiblity condition add them, to an optional tabbed panel and set the editability to false. -
To be continued