Content
View differences
Updated by Parimal Satyal almost 4 years ago
Currently, most of the autocompleters will try to load as many items as possible to give the impression of being able to scroll through all values and filter them easily.
There are a few exceptions where this often becomes a pitfall:
1. The ID filter for work packages. Potentially, a huge list of work packages is to be returned
2. The project list. In 12.2, this is implemented to load _all_ projects in order to show the correct hierarchy. This again might to scale for all instances
3. The assignee / responsible / other user-based filters
With the exception of 2., we load a magical number of items (1000 currently) , but don't give a hint that these are not all results. When filtering, only the matched items are loaded.
There are multiple options to discuss:
* A) Load a small set of default items to show (e.g., 20 - 50), and add a hint that more items are available to the bottom of the autocompleter
* B) Truly load all pages, but improve performance of API calls with signalling. Frontend-wise, this is easy to implement but this will still have its limits due to the sheer number of options available for some autocompleters (such as users on community, with over 60k values)
* C) Load no default values at all until the user has entered anything. This might not feel good for common values such as status, type, priorities, where a low number of options are to be expected.
### UX Proposition
From a user's perspective, the goal with auto-complete is of course to get to the desired item within the first few results. Ideally the first one, but it's easy to scroll down to the 4th or 5th. Failing to find the right result, a user is more likely to adjust her search terms than to scroll endlessly; it's somewhat more efficient unless the search is terribly slow (which will not be the case if we load a smaller number).
I think the best solution is A; we load a smaller number of results like we do for Add Existing. However, we also add information about how many results we are displayed, out of how many total. at the end, like so:
<figure class="image op-uc-figure"><div op-uc-figure" style="width:50%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/34761/content"></div></figure> src="/api/v3/attachments/34092/content"></div></figure>
This uses an existing style (the same we use to tell the user "This work package belongs to <Project>. Open this work package in that project".
Of course, 15 is sort of an arbitrary that is perhaps between "not too much to be able to scan, but still enough to get a variety if I can't find what I want in the first few results". results". It could easily also be 10.
This is how it would look in other places:
**Global search:**
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/34760/content"></div></figure> src="/api/v3/attachments/34093/content"></div></figure>
**Work package relations:**
<figure class="image op-uc-figure" style="width:75%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/34759/content"></div></figure> src="/api/v3/attachments/34094/content"></div></figure>
**Add Existing in Team Planner:**
<figure class="image op-uc-figure" style="width:75%;"><div style="width:50%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/34758/content"></div></figure> src="/api/v3/attachments/34095/content"></div></figure>
There are a few exceptions where this often becomes a pitfall:
1. The ID filter for work packages. Potentially, a huge list of work packages is to be returned
2. The project list. In 12.2, this is implemented to load _all_ projects in order to show the correct hierarchy. This again might to scale for all instances
3. The assignee / responsible / other user-based filters
With the exception of 2., we load a magical number of items (1000 currently) , but don't give a hint that these are not all results. When filtering, only the matched items are loaded.
There are multiple options to discuss:
* A) Load a small set of default items to show (e.g., 20 - 50), and add a hint that more items are available to the bottom of the autocompleter
* B) Truly load all pages, but improve performance of API calls with signalling. Frontend-wise, this is easy to implement but this will still have its limits due to the sheer number of options available for some autocompleters (such as users on community, with over 60k values)
* C) Load no default values at all until the user has entered anything. This might not feel good for common values such as status, type, priorities, where a low number of options are to be expected.
### UX Proposition
From a user's perspective, the goal with auto-complete is of course to get to the desired item within the first few results. Ideally the first one, but it's easy to scroll down to the 4th or 5th. Failing to find the right result, a user is more likely to adjust her search terms than to scroll endlessly; it's somewhat more efficient unless the search is terribly slow (which will not be the case if we load a smaller number).
I think the best solution is A; we load a smaller number of results like we do for Add Existing. However, we also add information about how many results we are displayed, out of how many total.
<figure class="image op-uc-figure"><div
This is how it would look in other places:
**Global search:**
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/34760/content"></div></figure>
**Work package relations:**
<figure class="image op-uc-figure" style="width:75%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/34759/content"></div></figure>
**Add Existing in Team Planner:**
<figure class="image op-uc-figure" style="width:75%;"><div