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.
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.
Passed as a global variabile
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.
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.
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
- 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
- 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.
undo and redo actions
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).
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.
1.12. Exploded view
This is a graphical representation of the entities. It is especially useful for manufacturing.
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.