UI - Best Practices

Plan the overall UI prior to development

Description:

Outline the UI layout, visualize all the pages and components required, prior to development.

This way, we can avoid common pitfalls on a best-effort basis. This also ensures that UI best practices are implemented in a preventative manner rather than "fixes" later on.
Not only that, by knowing all the required pages and components upfront, app developers would also be aware of the required forms, lists, processes, app components needed in order to match the UI features required.

Solution: 

• You can draw a sitemap, or utilize UX planning tools (e.g., Figma, Penpot, equivalent tools).
• Alternatively, you can also quickly experiment in Joget via a POC. This provides interactive visual feedback to stakeholders.

UI as first line of defence - Permission Rules

Description:

When configuring permissions for your various pages/components, UI is essentially the "top layer" of your application.
We can use the "onion layer" analogy, where UI is the outer layer, which then serves the contents of your created Forms, Lists, Processes to the client-side browser.

What this also means if, let's say, if a user is not allowed to view a particular CRUD menu, this also means we are certain that this user cannot access the List associated with this CRUD menu.

In other words, it would be redundant to assign permissions on the "lower layers" if the same permission rules are already applied on the UI layer.

On the same note, it also means we should configure permission rules on the UI layer first, and only if granularity is required, then only consider applying permission rules on Forms, Lists, Processes.

Solution: 

• Remove redundant permission rules.
  If the "outer layer(s)" already have adequate permissions, it is not required to add permission on the "lower layers" of app components.
• Apply permission rules conservatively.
  Only if the UI is unable to granularly control permissions to your requirements, only then apply permission rules on the lower layer.

Implement permission rules for UI only in the last stages of app development 

Description:

If permission rules are implemented at too early stages of the app development phase, this may hinder your ability to efficiently test the app. 

When changes are applied to a Joget app, those changes are immediately applied and reflected at runtime.
This allows developers to quickly reference the UI at runtime in the DEV environment to confirm various components have been configured correctly.

If permissions are already in place while many components are still absent, this not only forces developers to tediously test from various simulated role accounts; it also increases the likelihood of configuration errors since permission rules need to be constantly updated for every new component added to the app.

Solution: 

• Only implement permission rules once the app has achieved MVP or equivalent milestone(s).

Caution on assigning permission to UI category(s)

Description:

In most cases, it is perfectly fine to assign permission rules on the UI category level, in order to achieve granular permission control.

However, do keep in mind custom BeanShell scripts or plugins used in this area, especially when setting permissions to a very high number of UI categories.

When creating multiple permission rules on the UI, Joget optimizes performance by only considering the first correct rule that applies to a user, and no longer computing the remaining permission rules.
However, this optimization is not applied for UI categories.

If, let's say, you have used a custom script on 50 UI categories, this forces Joget to also iterate through all 50 UI categories per page load request, in order to compute which categories are authorized to a user.
Depending on the performance of custom implementation, this can severely penalize overall app responsiveness, and this time penalty is incurred by end users.

Solution: 

• When assigning permission rules on UI category level, ensure that custom implementations are well optimized. Consider caching mechanisms if available.
• Factorize to permission roles if possible.

Enable list count feature only when necessary

Description:

This applies to all list-related UI menus, like CRUD, list inbox, list, etc. 
These UI menus have the ability to toggle on displaying the total number of records on lists conveniently within the app's navigation bar.

However, do keep in mind that these list counts are calculated on a per-page load request.
Meaning, if you enable the list count feature on 10 CRUDs, Joget is essentially retrieving the count of 10 lists every time.

If the associated lists contain complex queries that take considerable time to process or contain a very high number of records, this can significantly impact overall app responsiveness, and this time penalty is incurred by end users.

Solution: 

• Only enable the "list count" feature when necessary.
• Only enable the "list count" feature if the list does not contain heavy queries, or is not expected to contain a very high number of records.

Always fill in the menu ID of your UI menus

Description:

By default, for any UI menus that do not have a menu ID, Joget will auto-generate a UUID for such menus.
This UUID will be visible within the end user's browser URL, to represent the page link.

However, doing so can present maintenance and debugging challenges to app developers.
Without filling in a meaningful ID value, it takes extra effort to discern what URL corresponds to which UI menu.
Not only that, any logging info and analysis data from APM will also show this UUID, which can add difficulty to triage any issues and slow down remediation efforts. 

Solution: 

• Always fill in a meaningful name for the menu ID of all UI menus in your apps.
• Treat menu IDs as unique identifiers.
  Do not reuse the same menu ID for different menus.
  If Joget finds multiple UI menus with the same menu ID, as a safeguard, Joget will only use the first result it finds.

Use menu caching where possible

Description:

All UI menus can be cached to reduce resource-intensive server/database operations.

A good example of such a use case is a dashboard-like report that contains a lot of aggregated data and charts that only display data for a specific data range on a weekly basis.
Since this data is expected not to change until another week has passed, there is no need to constantly retrieve data from the database, which will only display the same exact weekly dataset. 

However, do take note that you should only enable menu caching on non-time-sensitive menus.
An example of an unsuitable scenario would be a List Inbox. List inboxes are typically expected by end users to always display all the current pending task assignments without delay.

Solution: 

• See the KB below on how to implement caching for UI menus:
  Performance Improvement with UI Caching

Segregate UIs by roles

Description:

In real-world business use cases, it is common to develop apps that cater to many roles in an organization. Different roles commonly also have separate menus that they have access to. 

If the number of roles is high or the number of UI menus created is high, the UI will start to feel "heavy" for app developers to maintain & keep track of permission control. Very large UIs may also increase the likelihood of configuration errors, as the UI Builder will start to feel overwhelmingly cluttered.
In severe cases of extremely large UIs, it may impact end users' browser performance as we are forcing end users to render lots of UI content.

Solution: 

• For large UI implementations, split UIs by roles. There are several benefits, not limited to:
  • Improved performance, as Joget does not need to process a single heavy UI for effectively only a few menus available for specific roles.
  • Streamlined permission control
  • Reduced possible development errors for UI changes.
    In cases where a configuration error is found, debugging is easier to pinpoint the source of the issue, and the "bug" is confined only to a specific UI without possibly affecting functions for other roles.

Use the new Theme Builder

Description:

The Theme Builder is a brand new feature, exclusive to Joget DX 9, that centralizes all visual-related configurations into a "theme" app component.

This new builder allows deeper customizations on the base UI and even down to granular individual UI components.
It also has greater granularity of adjustments for UI components, which can reduce the amount of low-code effort to manually write CSS.

Solution: 

• Use the new Theme Builder to allow a greater level of customization to your app's look-and-feel.
  This will also effectively "consolidate" all visual modifications to a single Theme component.