Create/append search should prefer items starting with typed text

[barmac]

Problem you would like to solve

I was surprised to discover that I have to scroll the menu to find End Event after typing "en", even though it's the only element which starts with "en". IMO it should be on top of the list.

Screen.Recording.2023-02-09.at.10.50.08.mov

Proposed solution

If an item starts with the searched text, it should appear on top.

Alternatives considered

Leave it as is.

Additional context

No response

[nikku]

CC @smbea I found the same thing, trying to search for ter (Terminiate End Event).

[smbea]

Makes a lot of sense

[smbea]

Will assign to me so I can look at this

[smbea]

I wonder what should happen regarding the groups (namely templates group). Let's say we have a popup menu like:

"Rule template" would be prioritized given that it starts with "rule". Would we prioritize the whole group or prioritize it within its group? Another option would be to omit the groups during search

[nikku]

Good question. Maybe it makes sense to look at this in a more holistic manner; consider group names, too, and consider display (with group headers or not)?

An (simple) alternative would be to only match from the start of a token; from what I understand this is what @barmac stumbled upon. en should match End rather than went.

One assumption I have (not tested) is that re-ordering elements in the search results will confuse me.

[nikku]

CC @YanaSegal. Maybe you have some general UX insights to share.

[smbea]

Me and @YanaSegal discussed this topic yesterday and ended up discussing how the search could work in a more general aspect.

• Search by "starts with" or "contains strict term". For example:
  • If you search for "en":
    • "end event" will match
    • "start event" would not match
  • If you search for "end": "error end event" will also match
• Search by group name too
• Keep groups during search and do not re-order entries. Instead, re-order groups by relevance of search results
  • Prioritization order would be: label > description > group

With this discussion, the capability of collapsing/expanding groups also came up. I created a separate issue for this: bpmn-io/diagram-js#764

[nikku]

Depends on camunda/camunda-bpmn-js#393 to be released and incorporated.

[nikku]

Unfortunately not fully addressed via #4711 (yet):

(Fails with Event as a search term, expected to prioritize Event-based Gateway over other search results).

[nikku]

I looked into this again, via bpmn-io/diagram-js#953. First I thought that it would be unexpected that we still group search results (while the results are actually in a chaotic order). However #3439 (comment) backed up that we want to:

• Still have items grouped
• Show most relevant group first

➡️ This is what we do today, and will ship, cf. bpmn-io/diagram-js#953.

[nikku]

CC @lmbateman regarding #3439 (comment) and #3439 (comment).