Enable the ability to group templates

[rpkoller]

Is your feature request related to a problem? Please describe

When selecting a template in the element template chooser for a larger list of 60 or 90 templates the cognitive load for new users in particular is rather high orienting and finding the desired template.

Describe the solution you'd like

It would be helpful to introduce some sort of optional grouping functionality to enable the ability to group templates based on to defined criteria in the list (for example semantically or based on mutual providers).

Group 1 Template 2 Template 6 Template 9 Group 2 Template 3 Template 5 Template 10

The groups shouldn't be selectable by the mouse or keyboard focus. That way the list would be structured and easier to digest and with the search box on top you are able to narrow the selection down even further.

Describe alternatives you considered

Only show a subset of elements initially, and indicate there is more available if you search (https://github.com/bpmn-io/element-template-chooser/issues/5#issuecomment-1076125238).

[barmac]

Hi, thanks for creating this issue. While I generally like the idea of grouping templates, it may require some changes in the templates infrastructure to enable this.

@nikku do you want to add anything here?

[nikku]

I assume you have a case of 60+ templates at hand, right?

How are these named / ordered / grouped at the moment. Could you share a screenshot?

Generally speaking with huge amounts of templates the existing chooser UX will have a couple of issues; it cannot be the sole solution for template discovery. Grouping is one way to improve discovery / separate data in bigger data sets, a fully functional search is another one to drill down / limit search.

What to go for really depends on your domain; hence I'm interested in it :).

[nikku]

CC @currandwyer

[jurgenhaas]

Let me jump in here, as the issue comes out of the Drupal integration work.

Here is an example list of 185 templates which is what we have on a basic Drupal installation:

camunda.template.json

We generate this list dynamically and we could easily add extra properties like group or tag to each of the templates. The list builder could then utilize such a property to turn those into the groups that @rpkoller asked for.

[nikku]

What I was asking specifically for is:

• How are these templates structured, i.e. which groups / categories do you envision?
• How are they displayed right now (using the chooser)?
• How do you plan to make these templates discoverable? Outside the core modeling experience I suppose?

[jurgenhaas]

Currently, the templates are a plain list which is sorted alphabetically:

In this screenshot, only one template (Entity: set field value) has a description. Our plan is to add descriptions to all templates, which will then make that list even larger.

Which groups we want to use, is not decided yet. One likely option is to group them by provider, i.e. each of the templates is provided by so called Drupal modules, that a Drupal sites builder can install. Grouping the templates by module, that provides it, might be a good option.

[nikku]

They can easily be filtered via search, right?

[jurgenhaas]

Yes.

[nikku]

So how do you envision your users to discover / use 60+ bindings? Is it search first? Or is it sectioning? Search already works as of today, and it works nicely.

[jurgenhaas]

Your're right, search already works nicely, and I thought that would be sufficient. The point @rpkoller brought up about cognitive load has been an aspect I wasn't aware of and that's what this issue is all about, I guess.

[nikku]

I agree to the cognitive load part.

One way to improve there (without introducing grouping) is to be able to display only a sub-set of choices (i.e. favorites) + indicate there is more, if you search.

We'll look into this issue and see how we can resolve it; showing 60+ templates initially to scroll though shall not be the solution we want to end up with.

[rpkoller]

about the cognitive load part there are two problems manifesting in the screenshot @jurgenhaas provided. the pattern used for signifying that a template belongs to a group is by using a prefix in the name. in the example it is Form field:. Since the list is sorted alphabetically that entails that you have all templates with the form field prefix in a row. but the problem is in the first step a user wants for example all template for form field. if the user is at that point in the list then the only interest is which template for form fields i need. for that the user has to scan each title. problem is due to the prefixing that it is a bit like groundhog day meaning the user has to scan >11 characters each time to get to the actual tasks at hand. there is an article/study by the nngroup about front loading ux copy https://www.nngroup.com/articles/first-2-words-a-signal-for-scanning/ (cuz sighted users scan with their eyes while screen reader users scan with their ears - for both it is cumbersome). on the other hand. me as a user if i see hey there are certain tasks belonging to a certain context in that case form fields while the rest doesnt have any prefix at all. that makes me think and i become uncertain, insecure and frozen. are those other unprefixed templates universally useable or are they just not properly labeled - what the possible pitfalls might be?
about the idea to display a subset first. if a user is using favorites mainly aka a small subset of templates all the time that could be fine. but on the other hand as soon as i want to browse the other available templates that entails an extra click. once or twice that is fine but in the long run cumbersome. and still for the case if you just want to browser through the list of available options providing context in the form of grouping templates by provider or in any other significant form would be helpful. cuz you also have no real idea in the context of the aforementioned "is a template universally useable or not". it might be the case that you have templates only suitable for a certain context but its templates are at position 12,25, 43, 67 - scattered across the alphabetical list. just based on the title impossible to figure out. therefor i still think providing context in the form of some sort of group visualisation might be beneficial in many scenarios in addition to the already in place search functionality enabling to narrow down the list.

[nikku]

Thanks @rpkoller. Your input is appreciated.

So given https://github.com/bpmn-io/element-template-chooser/issues/5#issuecomment-1076097257, how would grouping look like? As I understand from your comments you'd group around Form field, Edit, and so forth and only have later parts of the template name represented in the item definition?

As we're in plain HTML a lot of things are possible; what would help is a little UI mock maybe to showcase what you envision. Can be rough; of course.

[currandwyer]

Groups, tags, and categories are definitely on the radar. I really appreciate all of you bringing it up. Our plan for now will be to learn more about how the component is being used as the functionality grows, and design our implementation of groups organically around that usage. We would start with the lightest touch implementation necessary for the current use case, and scale up from there.

The questions are: groups, categories, and tags of what? A card sorting exercise would be probably be most useful to think through this, but I would appreciate any opinions you have. Here's what I very loosely have in mind:

• Categories could be used to distinguish between the first-order types of element templates - for example, Generic BPMN could be one category. These categories live on the same plane of information as the other items in the list
• Groups could be used to organize similar types of element templates, for example your entity and form fields, or perhaps different operations performed against the same API. Such groups would expand into a second layer of information hierarchy in the list. (Smaller distinctions still are to be navigated within the properties panel itself)
• Tags then provide more context, like email or banking, and are mainly useful for search and filtering

Do these early stage ideas seem sensible?

[rpkoller]

@currandwyer i completely agree with you that it is a reasonable and wise step to first learn how the component is actually used and which needs and requirements result from that. directly in bpmn and camunda it is sort of controlled but already with an implementation in ECA within Drupal you got the case for example that you have a way higher number of elements added to the list. i think "think out loud" user tests (just provide several tasks within bpmn and let people record a screen cast and talk out loud what they think while solving the tasks) might be a useful and insightful tool to get an idea how people think, what their stepping stones are in the experience and what works and so forth - in the context of the element template chooser but also in other parts of bpmn and its user experience. about your suggestion/question how to categorise things. groups, categories and tags are all taxonomies basically. i see only two potential problems if you go that granular with all three without any user tests upfront. the first problem i answer from my personal perspective with my user hat on. i have a hard time to distinguish category and group semantically the boundary is quite fuzzy. one by the name " without any context given what different purpose a category and a group has, by just the name i am unable to determine whats the actual difference is between the two" and it feels a bit overcomplicating things making categorisation too granular. and introducing tags makes things even more granular. and lets say you have those three vocabularies in place you run into another problem. if you take for example the mockup from the other issue you've posted

you have the element component already containing the icon, the title, the description and the external link icon. the group title probably wont be inside the component but category will or the other way around. and then tags have to be visible as well. and you know users if the number of assignable tags wont be limited to one or two it might be overwhelming and even if limited actual browsing the list might be cognitively more challenging. the only chance is that you directly search for category group or tag names (if possible) aside the plain element title. sounds challenging. introducing those three vocabularies is well intentioned but probably too much. would it perhaps the more reasonable choice to "only" introduce groups? provide a default set of groups bpmn ships with (those groups could be found based on card sort exercises for example like you suggested) and make it optional if someone is implementing bpmn in their own solution to either discard those default groups and use their own or extend the default number of groups with their own. if then at a later point there is still the need for more granular extra vocabularies like tags or categories then those might be still introduced the functionality would be already in place.

@nikku and about a possible implementation / mockup. here is for example how a select list for timezones looks like in drupal it uses the optgroup element for the group labels. groups arent selectable when you navigate by keyboard. and downside is that you are not able to jump to the group when you type the group name (but it isnt an actual search field like in bpmn with an unordered list but an actual select field with its options so that is probably a browser limitation). and if you take the drupal screenshot into context what i wrote in my reply to @currandwyer before i would envision the following. lets say we only have a single vocabulary (group or category however you wanna call it). then add those group labels as separators like in the drupal screenshot. the elements belonging to the group i wouldnt indent necessarily (makes it a bit harder to read imho). and sort the elements within a group alphabetical. if you enter the name of the group in the search field the elements belonging to that group should be shown in the search results as well as all other elements containing the string from other groups. but in case that there are elements from a group as well as elements from other groups containing the search string group elements should be visually indicated. probably prepended in the element component markup otherwise you have the groundhog day problem again for screenreader users -visually it might be represented as some sort of badge (box with rounded edges and dedicated background-color. the only other problem i see with the grouping is the html5 markup. there is no real semantic proper way. for select fields you have the optgroup option. but there isnt anything comparable for ul and ol . the only thing i found is the nested way found here as tagged answer https://stackoverflow.com/questions/6457199/unordered-list-in-html5-with-a-list-group-name . there is another discussion in here: https://stackoverflow.com/questions/2958272/is-there-a-way-to-group-li-elements. but i've checked the former answer by scurker against the validator.w3.org and there was no complaint against the nesting solution. so that might be viable.

[nikku]

@rpkoller What I'm thinking right now that a basic grouping (as you suggest) could be a great first step.

What about something along those lines (like your screen, just fitting a little better into our updated chooser design):

(Not yet incorporated: Icons you see on @currandwyer's sketches).

---

Technically speaking you'd be able to attach a category = { id, name } to your element template definitions; you can choose the category name arbitrarily.

[rpkoller]

yep i like when nothing is indented in your mockup. but it would be mandatory to visually highlight/signify that in for example your screenshot SendGrid templates and REST templates have a different role than the rest of the elements in the list. The only indication at the moment is that the two don't have a description. Problem is that regular element titles also are bold already so it is difficult to highlight the role of group by making the group titles bold here. one idea coming to mind perhaps add a background color for the liof group elements? or maybe anyone has another idea how to visually let groups titles stand out and signify the start of a new section of elements. and for people who have to rely on screen readers in some situations or some all the time it would be helpful to extend the group label with a pattern by prefixing the group label by a visually hidden span. A complete arbitrary example:

<li class="bpp-element-template-chooser__group">
<span class="visually-hidden">Group for </span>
<span class="bpp-element-template-chooser__group-title">REST templates</span>
</li>

I've added a visually hidden span with something like group for or you could also name it group of that way when a user is going through the list it is immediately noticed that this element is a group instead of a regular task/element and that the following belong to the aforementioned group. if you append the group label instead as a suffix to the group title it could be missed or makes quick scanning for groups harder (cuz the complete line has to be scanned before realizing it is a group).

but on the other hand it could be thought about to reword the tasks/elements as soon as group feature lands. cuz if you take a look at your mockup. imagine you scan with your eyes or your ears. you have sendgrid templates as the group title. now you know until you reach the next group label that all upcoming elements belong to the context sendgrid templates but now the next two titles say sendgrid email template task and sendgrid email task what they actually do i dont know. i have to read the description. similar with the next block of tasks. all tasks start with REST connector and even after those two words i am not entirely sure what the task is about - i have to read the description.

edit/addendum: forgot one detail to take into consideration for the task titles within a group. if the user has a short working memory and is using an assistive device it "could" be the case that the user already forgot when just scrolling and browsing the list of templates in which group he or she currently is and to which group a element belongs. might be worth a thought to add a visually hidden span at the end of a element title with "(group name)"

about the technical implementation you've mentioned in regards of the element template definition i dont consider myself qualified to provide an informed opinion/feedback ;) but it sounds reasonable and handy to be able to choose and assign a category name arbitrarily. but i guess @jurgenhaas would be suited to provide some feedback in regards of using bpmn.io in another framework. guess his perspective might be insightful in the context of the technical aspect of this issue.

[jurgenhaas]

Yes, providing category = { id, name } for each template is perfect for us, I'm already working on this.

[nikku]

Basic grouping (cf. https://github.com/bpmn-io/element-template-chooser/issues/5#issuecomment-1079752288) released with v0.0.4.

[jurgenhaas]

You folks are spectacular! We've updated our Drupal integration with the latest release from here and not only groups are working but also the keyboard navigation in Firefox. Here is how it looks like:

Thank you!!!

[rpkoller]

@nikku was able to test 0.0.4 within the drupal implementation in eca now. great work! i would only have one nitpick in regards of the readability. i even personally have a hard time to distinguish inbetween a group and templates. in the screenshot jürgen linked the group has a greyish color (#6F7584) bold text while templates have a dark/black regular text. group titles are rather hard to spot with that styling. i'Ve simply replaced the group color with black in the devtools that way the difference between group and template is more apparent. (disclaimer: it doesnt have to be black just wanted to demonstrate a more dark color for the group might be a beneficial choice - perhaps a slight top padding for group names as well?)

[nikku]

I apprechiate you feedback, again. We'll iterate on it; in the mean time you can do a simple style override on your end to ensure it looks as expected for you.

[jurgenhaas]

Yes, we can do that. We just want to keep overwrites at our end to a minimum, for better maintainability in the long run ;-)