Usability issues with 8.16 implementation of issue filter

1. Can’t multi-select labels with mouse, can only do it by typing - attempting to do it via mouse unexpectedly clears currently selected label filter

2. To clear selected label have to select the text, delete it, then hit enter - was previously one click

3. Not obvious you can type to search for label

4. Search is fuzzy, e.g “cu” brings up discussion and documentation before it brings up customer

5. Visual display of selected labels is text only (i.e. no visual colour representation of label)

6. Once label is typed in search field, clicking back in search field doesn’t display all top-level filter options, only labels - have to press space to get all other options

added ~19492 label

mentioned in issue #25913 (moved)

1. Can’t multi-select labels with mouse, can only do it by typing - attempting to do it via mouse unexpectedly clears currently selected label filter

New design model emphasizes that user should treat each label as separate. Not clear if dropdown should contain multiple selections anymore. Pending feedback and further UX analysis.

2. To clear selected label have to select the text, delete it, then hit enter - was previously one click

Will be addressed in https://gitlab.com/gitlab-org/gitlab-ce/issues/26652

3. Not obvious you can type to search for label

Currently the design displays "Keep typing". Let's get feedback to verify if this is a problem.

4. Search is fuzzy, e.g “cu” brings up discussion and documentation before it brings up customer

This may not be a huge problem. I think it should be a lower priority problem to solve.

5. Visual display of selected labels is text only (i.e. no visual colour representation of label)

Will be addressed in https://gitlab.com/gitlab-org/gitlab-ce/issues/26652

6. Once label is typed in search field, clicking back in search field doesn’t display all top-level filter options, only labels - have to press space to get all other options

Similar to the first point. Again, I think this goes back to the original UX design. Perhaps need a separate discussion.

@sarahod : Let us know if you can help us in terms of testing / verification with real users so that we can verify these problems, whether in production, within a small group of testers, etc.

@ClemMakesApps @cperessini: @mydigitalself, a new product manager, brought up these good points. Thankfully I think #26652 (closed) solves some of them already. As for multi-label select, I think that's a huge one. Can you folks comment on that? I think that's pretty fundamental to the design.

I think the UI design is moving away from multi select because typing is faster than clicking. I think having the dropdowns be selectable using just the keyboard will help alleviate this need.

Based on my testing when I was doing the first iteration, the backend doesn't do a search of the users when the search term is less than 2 characters. This is probably for performance but I foresee an issue being created because of this

@ClemMakesApps there's still a multi-select user experience regardless if it's visual with mouse or via the keyboard.

Right now, in fact, the default is almost multi-select because of the point I made in 6.

So just try and complete some real world tasks for yourself in both the existing experience and the experience on staging:

1. Find an issue labelled customer & customer+ & platform
2. Find an issue labelled customer assigned to Job
3. Find an issue labelled customer & platform assigned to Job
4. Find an issue labelled platform in 8.16 milestone

As a separate point, I'm also curious as to why we even need the "type" prefix - for example why can't I just type "cust" and we'd show Customer Customer+ and General Custard (user). We could perhaps think about this for the future?

@mydigitalself I think I'll defer to @awhildy team on the decision for multi select.

As for the magic search you mentioned (without type prefixes), is a great idea but I don't think it fits with the UI proposed for the filtered search. In addition, it would pretty much be a purely backend implementation (which my understanding is that they are preoccupied with other tasks)

I'd like to add one more thought about filters.
I've already created an issue about that: #22921 (closed).
Situations, when I want to find issues created by / assigned to me, come very often.
Current implementation does not let me filter issues quickly.

My proposal is:

1. When I type author in the filter bar, there should be my nickname by default (maybe with different font color like placeholder). So I just press Enter key and get my nickname put as selected: author:@blackst0ne. Example: author:@blackst0ne (bold text is the text I typed, the rest is autosuggestion by the filter bar). So as soon as the filter bar recognizes the command I'm typing (author), it starts suggesting filter by my nickname.
2. When I type author in the filter bar and get the dropdown menu with available usernames, the first username should be mine.

When I type author in the filter bar and get the dropdown menu with available usernames, the first username should be mine.

Ok, this proposal is already up: #26765 (closed)

The filter bar is unusable without keyboard for now.

Example:

1. Click to the filter bar and choose, say, milestone in the appeared filters dropdown menu.
2. Click to any milestone in the appeared milestones dropdown menu.
3. When the filters are done (everything is chosen), you can't make filtration by your mouse - there's no any button for Filter!. You have to press Enter key.

@victor just to confirm: I can definitely help in terms of testing and I'm looking into this now for you, so I can get you some user feedback asap.

Great thanks @sarahod for heading this up.

mentioned in issue #26882 (closed)

@mydigitalself: Regarding multi select - we eventually plan to get to the point where we can be even more powerful than multiselect due to boolean operations (such as labeled customer or labeled customer+ and in 8.16 but not assigned to Job. In this state, you need each token individually called out in the search bar to make the relationships clear. I see adding the ability to add a second option from the label dropdown (for example), as a potential nice shortcut, but it would simply be a shortcut to add a unique token to the query with mouse instead of keyboard. While I think it could probably work, we'd want to confirm it doesn't add confusion to the overall flow (that it is clear what will happen when you multiselect in the dropdown). At this point, though, I don't think that it is the top priority for this feature. I'd rather make the whole process of adding tokens smoother first before adding shortcuts like these.

Thanks for all the feedback here! Great things that we need to consider.

@mydigitalself @victorwu: I'm pretty confused that this and https://gitlab.com/gitlab-org/gitlab-ce/issues/25913 both seem to have the characteristics of a meta issue for the new search bar.

Ideally, we'd have separate issues for each point, and link to them from one place, so that we can point people to a single issue for multi select, a single issue for searching without type prefixes, etc. And then there would be an issue to track all of those other issues, in which we keep the description updated. Can we do that, please? (I don't care which issue we pick, or how we do it.)

@smcgivern I filed this as very specific set of issues with the current implementation that's shipping vs the future vision and overall design. My perspective is that the version shipping in 8.16 is a step backwards in functionality and usability and that anything that can be done to fix these issues ahead of that release would be welcome.

@mydigitalself sure, I understand that, and this isn't meant as a criticism. But even so, it is much better to have one issue per topic. In this thread, there are a bunch of different things to fix - some of which will be quick to do, and some of which will take longer - and if we ask someone to work on this issue, it's not very clear what we're expecting them to do.

The other issue also contains problems with the current implementation (like #26840 (closed) and #26841 (closed)), but they are linked to, so we can tackle them separately. I'm fine with having one meta issue for this, but I don't really understand the need for two of them here, and I think the conversations within this issue would have been better served by being in separate issues for the individual topics. We can't undo that now, but I'd like to not continue with a discussion in this issue that touches on a bunch of things with varying timelines

@smcgivern + @mydigitalself : Good points. I'll fix everything (combine, close issues as appropriate) after we've chatted today in our scheduling meeting and decided on next steps.

mentioned in issue #26945 (closed)

@mydigitalself : I moved your points to https://gitlab.com/gitlab-org/gitlab-ce/issues/25913. I left out two of the points, since they will be solved in https://gitlab.com/gitlab-org/gitlab-ce/issues/26652

closed

mentioned in issue #27286 (moved)

mentioned in issue ux-research#1 (closed)