# Feature DREAM-5 - Streamline autocompleter behavior for balance between performance and UX
Project: Stream Design System
Status: specified
URL: https://community.openproject.org/work_packages/DREAM-5
## Planning
| Attribute | Value |
| --- | --- |
| Date | |
| Priority | Medium |
| Target versions | Wish List |
| Sprint | |
| Backlog bucket | |
| Votes | |
| List | |
| Roadmap | |
| Relevance | |
## OPEN POINTS / FEEDBACK
_No work packages_
## Features and Chunks
_No work packages_
## Bugs and other work packages
_No work packages_
## Technical Details
| Attribute | Value |
| --- | --- |
| Module | Modules and project features / Search, Frontend components and Primer design system |
| Feature Flag | |
| Requires doc change | No |
| Enterprise plan | |
## Details
| Attribute | Value |
| --- | --- |
| Pull preview | |
| Mockups | |
| Accessibility | No |
## People
| Attribute | Value |
| --- | --- |
| Assignee | |
| Accountable | |
| Product manager | |
| Developers | |
| Designer | Parimal Satyal |
| Ordered by | |
| Signed off by | |
| Interest by | |
## Estimates and progress
| Attribute | Value |
| --- | --- |
| PD (min) | |
| PD (max) | |
| Work | 0h |
| Labor costs | |
## Description
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 fail to scale for all instances
3. The assignee / responsible / other user-based filters
We currently either load a magical number of items (1000 currently), but don't give a hint that these are not all results, or we load all items which is very slow.
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). Taking a look at the project autocompleter it is already perceivable that the frontend runs into performance bottlenecks.
- 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.
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".
This is how it would look in other places:
**Global search:**