UI5ers Buzz #57: Recently Used Values History for Smart Controls

Forms are essential part of today’s business applications. The task of filling form data sometimes can be quite boring, especially if you need to do it on regular basis. For plain HTML forms, we have the autocompletion in browsers, but for SAP Fiori applications using SAPUI5 we were missing similar functionality until recently.

We did major improvement in this direction with the Recently Used Values feature available for SmartField and SmartFilterBar filter fields. It is enabled centrally by a parameter in the SAP Fiori launchpad (FLP). The history stores up to 5 values last used.

Yes, it runs only in the context of FLP, so standalone apps would not be able to benefit. The reason is that we use UI2 Personalization service for storing the values of each field. The Personalization service is part of the FLP offering and provides us with standard and secure way of storing data. Keep in mind that the feature is not supported by default for all fields, but only for those annotated with ValueList annotation. If you have some fields that contain personal sensitive data, you can use the IsPotentiallySensitive annotation for them to disable storing of data.

This feature was introduced in version 1.78 of SAPUI5 and since then a lot have happened. For example, we provided the possibility to switch this feature on or off on control level (more about that later in the Technical side section). That’s why I’d recommend using SAPUI5 1.84, moreover it’s a long-term support version.

Edit:

The feature is like normal browser autocomplete feature, so either works on a field if enabled or not. Its behavior doesn’t depend on annotations. It doesn’t take into consideration application business logic, that can be applied to a field. For instance, based on change of the assigned user role, the history should not contain some values, that are not relevant/forbidden for the new user role. So in case there is a chance that at some point in time a field would have values that the user shouldn’t see, then perhaps it’s better not to enable the history there.

To use or not to use

Typical use case would be when a user uses frequently particular application and needs to choose a field value in relatively long list, and especially if the chosen values are the same every time. Don’t use this feature if you have a field with small number of options e.g., True, False and N/A. Especially, if it is a seldom used app and there is probability that the user will choose a different value every time they use the application.

Recently Used Values when enabled for SmartFilterBar

How suggestions are visualized

When focusing the input, a dropdown is opened in case there were previously entered values. On mobile, the dropdown is opened as full-screen dialog. In case no previous history values are stored, on focus in the dropdown will not open. When you start typing, you’ll get filtered suggestions and recommendations, if available.

Suggested values can be part of several groups. If we have stored recently used values, they will appear below the group header title ‘Recently used’, then ‘Others’ which will show the rest of the suggested values. In cases where we have recommended values, as in machine learning scenario, the ‘Recommended’ values come on top, then ‘Recently used’ and last ‘Others’.

In case a value is already in the ‘Recently Used’ list, it will not be duplicated in the ‘Others’ group. If you have value in ‘Recommended’ group and that value that is part of ‘Recently used’ or ‘Others’ then it will be shown only in ‘Recommended’ to avoid multiple instances of the same value.

The Recently Used Values feature is an input support tool for fast keyboard entry. As such it’s not meant to be part of the Value Help Dialog’s result list, but it can be used in the filter fields.

Languages

The initial implementation didn’t take into account what language the application was using. This created a problem when someone was entering values in German, for instance, and then switching the application language to English. Then the user would get a history mixture of both languages. This was not useful for the user. So now, when we store an input value, we store it with the language information and show only values for the chosen application language. This part of the feature is relatively new, since SAPUI5 1.85. Applications using Recently Used Values before that release will have all stored values treated as one entered in English and will be seen when English is chosen as application language.

User settings

When the Recently Used Values feature is enabled via FLP parameter, an option will appear in the user settings menu, else you won’t see this entry in the menu.

FLP user settings menu item

When the user selects this menu item, he/she is presented by a dialog which offers the possibility to switch off the Recently Used Values feature. This setting is on user level, therefore applicable for all applications a user would use. Also, the user can delete all stored entries for all UI5 applications running on this FLP instance. If in the same FLP instance there are applications using other UI technologies like Web Dynpro, their input history will not be affected.

FLP Input History settings menu

Technical side

As mentioned in the beginning, first and foremost you need to have special FLP property to enable the feature. In addition, for SmartField and SmartFilter Bar we’ve introduced historyEnabled property that can switch on and off the feature on SmartField level and on filter field level in the SmartFilterBar. Without the FLP property being set, historyEnabled is meaningless and will not cause any effect. The default value for SmartField depends on what type of control is rendered. If it’s rendered as Input control, the default is true, means you’ll get the values’ history. For ComboBox controls it’s false. For SmartFilterBar filter fields, respectively for MultiInput is true and for MultiComboBox is false. The reason for this difference at first sight is that when enabling this feature on existing applications, ComboBox and MultiComboBox fields might have few options to select from. During the development, we already had this experience and people using the application were not happy. In these cases, from the point of view of visual design, the ‘Recently Used’ gets in the way by visually cluttering the screen, rather than assisting the user.

The historyEnabled property can be overridden using standard means in the XML view definition.

SmartField example: XML View snippet for disabling the feature:

<smartField:SmartField id="idCategory" value="{Category}" historyEnabled="false"> 

Recently Used Values feature disabled for SmartField. No ‘Recently Used’ section

For the SmartFilterBar, we have the historyEnabled property in the ControlConfgiuration object so that it can control individual fields in the SmartFilterBar.

SmartFilterBar example: XML View snippet for disabling the feature:

<smartFilterBar:controlConfiguration>
  <smartFilterBar:ControlConfiguration key="Bukrs" historyEnabled="false" /> 
</smartFilterBar:controlConfiguration>

This configuration will switch off history only for the field with id “Bukrs” with description ‘Company code’. All other filter fields (that have default value ‘on’) in the SmartFilterBar will have the functionality on.

Recently Used Values feature disabled for SmartFilterBar filter field (Company code)

Note that the property doesn’t have effect on custom fields in the SmartFilterBar.

Restrictions

Date objects can’t be stored, as they can’t be serialized and restored back in the proper format. At the moment of creating this article, if SmartField is rendered as Select (having ValueList annotation and autosuggestion is switched off) we will not support it.

For ValueList annotations, if there are defined In/Out parameters, they are not taken into account for ComboBox and MultiComboBox. Another restriction is that the invoking filtering function on the internal input control is not supported. The reason is the design of the internals when Recently Used Values work. We use internal JSON model combining all data sources that need to be displayed in the dropdown. This data model can’t be accessed and manipulated from the outside.

Conclusion

This feature should be used only if necessary and not enabled everywhere, else it could have the reverse effect. Instead of happy users quickly filling out forms, you can have frustrated users that are annoyed with the product they use. So, again, to summarize when it’s recommended to use the feature:

• The user needs to select one or several values out of a larger amount of values.
• The user regularly uses the application.
• It is of high probability that a user selects the same values again and again.

When it’s recommended not to use it:

• The amount of values to choose from is small.
• The user uses the application only from time to time.
• It is highly possible that a user selects a different value each time.

Try out this feature if you think you have a case, as it could help end users. Such small differences in the UI could sometimes mean happy or frustrated user. Your feedback is more than welcome.

Previous post:  UI5ers Buzz #56: New full-stack UI5 sample app featuring CAP + OData V4 + draft mode

Author

Vladimir is a Product Owner in UI5 having 20 years of SAP experience. Current focus is on Smart Controls. Previously was PO for Date and Time controls in UI5. Has background in delivery infrastructure for SAP technologies. In free time often plays around with IoT projects, 3d printing or practice Qi Gong.