1

So at present, the system I'm developing has a multi-select list that categorises users by their group. For example, the select list options looked like this:

  • Administrators
    • John Smith
    • Jane Smith
  • Finance Team
    • Jordan Smith
    • Jeremiah Smith
    • Joe Smith

And the selected options allowed for a whole category as well as individual users, such as: "Administrators", "Jordan Smith", "Joe Smith".

The problem is, the system has now evolved so that users can have multiple groups. So rather than just being a member of Administrators or Finance Team, they could be a member of both.

The select list needs to still allow for the selection of both individual users and whole groups. I could replicate the individual users across multiple groups, so that they appear twice in the list, but then I'm concerned it will confuse the end-user as if they use the typeahead, the user will appear multiple times under different categories.

  • Are you forced to use multi-select list or can this be solved in some other way? – locationunknown Aug 9 at 9:25
  • 1
    @locationunknown, another way is perfectly fine. It's just that I'd been using a multi select so far. – Slepton Aug 9 at 9:33
1

I'd suggest changing the controls. Rather than a multi-select with repeating users, which truly would create confusion, go for a tab-based or sectional approach to separate out the different user groups.

That would not only help the user visualize the screen better, it would also be less grueling when the user count rises leading to an unending scrollbar.

The approach shown below seems much cleaner to me. However, this doesn't necessarily have to be the only approach

Tab approach to separate out each user group

0

It's my idea. Obviously it's only draft, which after improvement will prove to be a sensible application:

It will be useful sooner or later to filter by groups as ranges (which can be combined)

enter image description here __

0

Have you talked to the developer about de-duplicating typeahead results? It doesn't seem unrealistic to detect if the result is a different instance of the same record, and only show one.

Honestly, I'd start there before introducing unconventional form interactions.

  • The data isn't duplicated. It comes back in the form of { firstname: 'John', lastname: 'Smith', groups: ['Finance', 'Sales'] } – Slepton Aug 12 at 8:33
  • Even better. Since it's a single record that's being split on the front-end, type-ahead should be able to run on the single-source list that's feeding into the front-end, instead of the split up list made by the front-end. – Ben Paddock Aug 12 at 16:01
  • I'm afraid you've lost me. Previously, users were only part of one group. So it was as simple as having a categorized select list, where you can select both the group and the users below it. Now however, with users being in multiple groups, when you start typing a user's name, they could come up under multiple groups, which will be confusing for the end user. – Slepton Aug 13 at 9:38
  • But the source of that list does not have duplicates. It's one person (John Smith), who has then been replicated and put into two groups on the front-end. But an array exists of just the unique individuals. Your type-ahead should be able to run the search on that source array, not the content on the front-end, and display the unique results from the source array. – Ben Paddock Aug 13 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.