I’m working with a partner working through a couple of UAT related items at a client. One of the “pain points” has to do with use of the Multi-select combo box. The users are finding it cumbersome to sift through the result set in the multi-select combo, even as they supply multiple characters of the string.
The outcome they are trying to achieve is to associate one (or more) broker names to apply to the case.
For example, a user might know that the entry starts with “Ace”, but the resulting selections pull every entry containing “ace”. The user typically select 4 or 5 entries from the list.
We understand the architectural principle is that the search criteria (“Starts with”, “equals”, etc.) happens server side, at the data page level and the component is responsible for the rendering only.
Applying additional filtering criteria on the Data Page source to further narrow the result set will help speed up the user selections to a certain extent. Has anyone else faced a similar challenge? If so, how did you approach it?
How many records of broker names are there in the database? In the example you gave the one that starts with “Ace” is the first item. Is that coincidence?
I was on the call with Di where the customer reviewed the item above. It is a coincidence that Ace is the first in Di’s list. The customer would start typing, say M, and anything with an M comes up in the list. When it is a single select, when they type M, they go to the M’s; however, if they pause too long in their typing the next letter, the single select then goes to that starting letter instead of using as a second letter (So if they type M then e with a pause. The single filter will go to the first E in the list.). Customer sees different behavior for single and multiple select. Would like a way to have the option to have the multi select use “starts with” instead of contains. (for the single select, they’d like to know why the pause causes a “redo” on the search).
Thanks, Kate, for the clarification on the “pause in typing the letter” part of the behavior we saw this morning. (“Ace” was just an example. )
As Kate points out, they are really looking for a “starts with” option on the search. I’ve shared this post with the partner team - hopefully they can supply the details on how many records they are getting back.
If you’re sourcing your DP from a report def, create a new report def with the search term as a param - and update the filter logic to be “starts with”
Nice one Anthony, that is indeed a good alternative! Another alternative for such a big amount of possible references is the Advanced Search & Select default pattern for data references. With the approach provided by Anthony you could also apply elastic search capabilities (on datapage level) as another advancement of the search. I know this is especially useful in case users do not know exact names and there are many possible records.
Advanced Use Cases for Search and Select Pattern is also a very interesting post related to more advanced search & select use cases. Especially the date range requirement (Use Case 2 in the referred article) implementation is interesting for your requirement to do a “contains“ filter condition.
Response from the client as to the usability of the suggestion above.
Using a table with a search field that applies begins with logic—partially addresses the selection issue. While it works reasonably well when selecting values for the first time, it introduces new challenges when users need to edit previously selected values:
The table does not automatically display pre-selected values.
Users must manually search for each previously selected value to deselect it.
They then must perform additional searches to select new values.
This significantly increases the number of clicks and the overall time required.
Additionally, incorporating several such tables into the Index UI creates layout and usability concerns. Given that the RDM index screen typically includes 15–20 fields, adding multiple tables (3–4) takes up substantial screen space. This results in excessive scrolling and makes the UI appear cluttered and cumbersome for business users.
Because of the above considerations, the posted suggestion does not sufficiently meet our business needs, and it introduces new usability obstacles that may hinder the end-to-end indexing workflow.
You can try adding the starts with logic into the datapage with a data transform that calls a parameterized datapage (report definition based) with a parameter fetched from pySearchPageName that is used in the filter logic of the report as “starts with“. This only works with a Search & Select pattern. If this does not give an improved experience, i think there is no real option at the moment. I can not imagine this is a make or break feature for the client, although i understand it can be annoying. You should raise a feedback anyhow, can you let me know the feedback ID so i can follow and vote.
This is the config of the data reference field search & select field in constellation, using the search wrapper data page and Employee ID as parameter (starts with):
)
