Application interface design standard

---

The following section collects best practices during the building of an application. The proposed solutions will allow you to create clear, ergonomic and functional forms, lists and other GUI elements that will increase the attractiveness of the application you are creating.

Layout

It is common practice to use page templates. Within the application, specify the types of pages (e.g. dashboard, details , 360 view, reports, etc.).

Below is an example of a manager's dashboard - the page contains the most important cumulative information that directly relates to the user.

1. Divide the information into sections and separate them clearly (you can use containers and headers for this purpose).

2. The various components of the form should contain thematically convergent data.
3. In case of a large amount of data, use:

• Sections - are appropriate for data that the user may need right now.

• Tabs - appropriate for separated data (the user will find everything he needs within a tab).

• Separate pages - unrelated sets of data (e.g., working time management, editing address data).

4. Avoid building "high" screens ( >2 screens ). In this case, use: tabs, separate wizard-like pages.

Navigation

1. Navigation should be clear, repeatable and predictable - define a navigation scheme and apply it throughout the application.
2. Navigation guidelines should be considered when creating the window templates described above.
3. Location of main actions:

• Main actions are actions that apply to the entire page and should be located in the action panel on the form.

• The above actions should be visible at all times. A good solution is to dock them at the top of the page.
• If the actions are not docked, it is recommended to show the action panel above the form.
• For pages with content that causes a scroll, it is good practice to repeat these actions below the form.

4. Location of local actions.

• A local action is an action that relates to a part of the form.

• The location of the action should cooperate with the style of the section (frame, background) to which it relates so that it is clear what the action is about.
• The location of the local action in the section should be repetitive (e.g. upper right corner).

Action button style.

1. Styles should be used consistently taking care to underline them according to their meaning/function.

• Standard - basic, technical actions.
• Primary - actions highlighted, expected, causing progress in the ongoing process.
• Success - positive actions (acceptances), end some process (e.g., approve an order) or initiate some significant event (e.g., Send a request).
• Negation - rejection / cancellation type actions, process interruption actions, or actions with a negative meaning in the business context (e.g. Refer for vindication).

2. The order of action buttons in the action panel.

• If you have several action buttons next to each other, make sure that their order is repeated.

• On the left side, we use actions that pause the ongoing process, undo it or navigate BACK.

• In the middle, neutral, technical actions (e.g., save, update data).

• On the right, progress / expectation / highlight actions.

Save

1. It should be clear on the page of what the save action is about.
2. Do not use more than one save action on the page forcing the user to wonder what will be saved.
3. If there is a need to save a change in the value of a particular control "here and now" (its value influences the behavior of the form), a save should be applied to the control's onChange event.

Editing

1. How to edit a "large" form should depend on the context.
2. Below is an example of creating an object element (e.g., an application) where the user will complete all/most of the fields - all fields are editable.

3. Enter editing of an already existing element - you can apply section-level editing using a popup window or a separate form page.

4. Do not use the form in edit mode for each entry to the object details. Edit mode should be available if there is a business case for it. Otherwise, use read mode with an on-demand edit option.

Read mode - two methods

1. Textbox R-O (read only) - use for small forms where you have more space available

2. Label - use to save space.

3. You can adopt a mixed convention according to specific/your own criteria.
4. Select and apply consistently throughout the application.

Icons, symbols

1. Use symbols for obvious and typical actions, understood by the user (save, edit, accept).
2. An atypical action, commonly used in an application, can be treated like a typical one (e.g., "download PDF" in a document handling system where the action occurs on multiple forms).

Support atypical actions with additional action button text.

3. Use tooltips in every situation.

Context of usage of the pages (forms)

1. Build data-driven forms that match the user's business need. Aggregate the data needed by the user at a given stage of the process or activity, eliminating the need to switch between pages.
2. Separate the data into separate pages if they do not form a coherent whole in the business context.
3. Design dedicated pages that provide the user with the information they need.

Example 1

A manager's dashboard presents statistics and values under his control. This form is meant to provide information about "what needs his attention and action," but taking that action itself doesn't have to be done through this particular form.

Example 2

The employee form contains two contexts:

1. Working time registration - a collection of functions for recording work activity or absenteeism.
2. File - a collection of information and documents for the employee (addresses, contact, salary, loans, Social Security, etc.).

Scope of information presented

1. Remember that everything is information - icon, color, size, alignment - use them in moderation emphasizing only what can help / support the user in the business process being implemented.
2. Select a data set that represents value to the user at the time of the activity.

Object identification

1. It is worth ensuring that relevant information about the supported entity is available at all times.

Example 1 - When handling a credit application, show customer identification data (first name, last name, PESEL, CID, etc.) all the time.

Example 2 - When assigning shipments to a courier's vehicle, show the vehicle data (type, model, registration number, carrier).

Controls

List

1. Use a limited number of columns - horizontal scroll on the list is a big impediment.
2. Maximum number of rows - so that it is possible to display the entire list with header, filter and pagination on one page.
3. If the list will contain a few records (e.g., < 5) resign from pagination (e.g., a list of loan guarantors when there can be no more than 5).
4. Specify the width of the columns relative to the expected content.
5. Use column content alignment:

• texts to the left
• numerical values to the right
• dates to the left

6. Filters - use filter layout to take up as little space as possible.

7. Use short descriptions/abbreviations for filter fields to avoid collapsing lines (define tooltips with full field descriptions).
8. Place actions related to the entire list in the list toolbar.
9. Place record-related actions directly on the record (icon).

10. Use data sorting options. The application designer should know what the list should sort by by default and apply such sorting settings. For more see: Selecting columns and sorting.

Repeater

1. Use a repeater to display a finite number of items so that it is possible to handle them within a single page.
2. Separate repeatable elements in a visible way (containers, separators).

3. For one-line elements, do not use additional separators for repeatable elements.
4. Use the First row as a header option to save space on the form.

Popups (a form opened in a popup window)

1. Place actions docked at the bottom of the form window. So that they are available all the time.
2. For the action that finalizes the desired operation within the popup window, include an additional JS action with a function that closes the popup window.

Example: the SAVE / ACCEPT button in the popup window should cause the window to close.

3. Always refresh the appropriate page element after closing the window, so that changes are immediately visible.

Button

1. When placing several buttons next to each other on a form, use Container (flow) to optimize the spacing between buttons.

2. If you want to place a button aligned "to the right" of any object, use Container (flow) - this will allow you to make the button's position independent of the width of the column of the container on which the button is embedded.

Group

1. Depending on the expected content of the edited fields, modify the default group layout (4-4-4) to make better use of the page space.

DatePicker, masked Textbox

1. Specify width in columns according to expected content.

Numeric textbox

1. Use the spiner option where adding units makes sense

• Field Total number of dependents - use correct
• Field Amount of debt - use incorrectly

See also

Lists

Forms

Menu