The UI should be able to autogenerate menus, forms, tables and so on according to the current user’s credentials (role).

It will have to cache data marked as cacheable and update it when it receives the invalidate data event.

The main screen can contain a console like window that will display the status of the requests, errors and other useful things. This window is user configurable and can be hidden or displayed.

1.1. Applications

All applications should be independently deployable as modules in the main UI frame. They should include description, menu entry and so on in order to inform the main UI frame about the app.

1.1.1. UI repository

In order to test and avoid duplicate components, a UI has to be created to display the UI components with examples and test data.

1.1.2. Theme

Passed as a global variabile

1.2. Validations

All user inputs must be validated before submitting any form. The data is also validated in the backend and errors or messages will be returned. All errors and warnings must be displayed to the user.

1.3. Dependencies

Some fields might be dependent on other’s behavior. Callbacks should be implemented between components. For example, certain fields should be hidden for invalid or selected options in the same form or API requests made after a specific field is filled.

1.4. Translations

All translatable fields should be easily translatable. This means a button must be placed near or in the context menu in order to open a translation maintenance for that specific field.

The translation UI must contain navigation in the entity tree. For example, if you want to edit a field in a child entity, you should be able to see its parent also.

1.5. Tooltips and labels

Tooltips should be generated from code comments. Tooltips are language dependent. All fields and screen components should be able to display tooltips or help.

Drop down items should have tooltips and help.

Could be user role dependent.

Has context menu item that sends to translation (user role dependent).

1.6. Notes on screen

The user should be able to save its own notes and instructions for any screen entity. Those notes should be displayed as tooltips on hover when certain settings are activated.

1.7. Drop downs


  • getId from name
  • cache
  • gets its settings from the backend (example: default value)
  • populated from API or in code
  • the API returns only the options for the user role
  • can select null option
  • searchable
  • options display according to the user role

1.8. Search help

Where searches are needed, filtering criteria has to be flexible.

Filtering can be added, configured and saved where needed.

Filtering table

undo and redo actions

transaction steps

1.8.1. Where used

This functionality allows the user to find where a specific entity is used (or can be used) in the system as data or as a child in another entity.

1.8.2. Maintenance table

For enums, their translations will be maintained inside the system maintenance tables.

1.9. Reports and listings

1.9.1. Data viewer

The user should be able to create and export simple reports directly from the database tables or information provided by the APIs. Since the report viewer has access to data definitions, it natively allows Drill down and drill-across searches.

You can generate a report from any system screen. The lists are based on information from the windows. The reports are usually based on summarized information based on reports views.

1.9.2. Graph / Charts

The data can be displayed in several ways. A graph relationship will be useful for the manufacturing modules in order to display the relationships between components and the exploded product view (OLAP).




1.9.3. Data export

All report outputs can be previewed on screen before printing or generating files in several standard formats (e.g. Excel, HTML, XML, Word and PDF).

1.10. Tables

The user should be able to filter table data with search helps and by defining column filtering entries (where, between, order by comparators, list of options, properties, custom “SQL”).

The table columns should be user customizable: order, display, custom queries etc.

Data should be loaded all or with lazy loading. Also, pagination should be used for large tables.

Filtering can be done by selecting options in drop downs.

Data on tables should be able to be aggregated with SQL commands (SUM, MAX and other SQL commands) or through the API. Aggregating data means running the query without the skip/take pagination.

Tables should display total records count and displayed records count and configurable, totals and other column statistics.

Tables should have a toolbar for configs, filtering, refresh etc.

1.11. Tree view

Entities should be displayed either in tables or in a logical tree view.

Lazy loading must be provided for tree view.







15 CSS Tree View Examples Code Snippet

1.12. Exploded view

This is a graphical representation of the entities. It is especially useful for manufacturing.




1.13. Navigation

If you click (or right click menu) an icon for a field you should be able to navigate to that entity and see its table, attributes etc.

1.14. Context menu

This is a menu populated according to the user role. It’s shown on right click or from another button press (menu).

It can contain:

  • navigation items (go to entity definition, translation, table or configuration)
  • configuration for displaying
  • information and help about the field / element

1.15. Saving user preferences

The user should be able to save its preferences, queries, filters, default pages, favorites, notes on screen, favorite entities.

Favorites should have categories.