Skip to content
Snippets Groups Projects
New issue look: Off

Improve user filter autocomplete experience

    • Closed (moved) Issue created by Winnie Hellmann @winh

    Summary

    In the issuable search bar when typing in a username (author or assignee), the user needs to wait for a server response for each keystroke in the worst case. Instead we could instantly display users that were included in earlier server responses. Since requests are usually narrowing down the users being requested, there is a high chance we have requested the desired user already.

    Steps to reproduce

    Note: This is best reproducible if you throttle network connection in dev tools of browser.

    • add author / assignee filter on issue page
    • type something that matches people already displayed in the dropdown

    What is the current behavior?

    Need to wait until dropdown is filtered. The delay is almost one second for GPRS but still noticeable (around 200ms) on good network connection (DSL + Wifi).

    What is the expected behavior?

    Already known users matching the search criteria should be immediately shown.

    Screenshots

    Searching for adam with network connection throttled to GPRS:

    autcomplete-delay

    The Adams that were already present initially should be shown immediately.

    Possible fixes

    • cache users on frontend
    • display cached users that match search criteria immediately (display spinner to signalize that data may be incomplete)
    • make server request
    • update cache and dropdown

    Designs

      Child items ...

      2. Activity

      • Winnie Hellmann
        Winnie Hellmann @winh ·
        Author Developer

        @cperessini Does this make sense to you?

        The caching would also improve the situation where you pick assignee and author and whatever comes last was already suggested earlier.

      • Victor Wu changed milestone to %Backlog

        changed milestone to %Backlog

      • Victor Wu
        Victor Wu @victorwu ·
        Reporter

        @winh : If we work on this, would we get it for the search bar, as well as description boxes all at once?

        Do you know if this changes any existing logic? I'm not even sure how it populates the dropdown right now, and how those results are determined with the fuzzy match. I imagine if we spit out FE cached results first, the difference in results would not be notice-able at all, but the instant speed would be amazing.

      • Winnie Hellmann
        Winnie Hellmann @winh ·
        Author Developer

        would we get it for the search bar, as well as description boxes all at once?

        @victorwu Good idea! :thumbsup: With description boxes you mean Markdown fields, right? This will not work out of the box for both (as @kushalpandya and I just realized, both implementations are completely independent) but shouldn't be too hard to adopt.

        Do you know if this changes any existing logic?

        Currently it is:

        • open dropdown (for the first time)

        • autocompletion endpoint is requested

        • when response is received, dropdown is filled

        • user types something

        • autocompletion endpoint is requested

        • when response is received, dropdown is filled

        I would change it to:

        • open dropdown (for the first time)

        • autocompletion endpoint is requested

        • when response is received, dropdown is filled

        • response is stored in cache

        • user types something

        • autocompletion endpoint is requested

        • users from cache are loaded

        • when response is received, dropdown is filled

        • response is stored in cache

        So after the same waiting time, the existing logic kicks in. Just during the waiting time, results are already displayed.

        how those results are determined with the fuzzy match

        I don't know either but I also wouldn't rebuilt the backend logic on frontend because of simplicity and speed. I would just loop over the existing cached users and check if either display name or username contains exactly the entered text. This would work for typically cases and for spelling mistakes the backend logic is there to help a little later.

      • Victor Wu
        Victor Wu @victorwu ·
        Reporter

        Sounds good @winh . If / when we schedule this, should we also refactor the code to make sure we have one place to do all the logic so we are not repeating ourselves. So far I count three places where we have similar behavior.

        • The issues / mrs list search bar + issue board search bar (and the add issues modal in the issue board).
        • Multiple assignees dropdown.
        • GFM boxes across GitLab (issue/mr/snippet descriptions and comments)
      • Winnie Hellmann
        Winnie Hellmann @winh ·
        Author Developer

        @victorwu The Markdown autocompletion has a different design, so I am not sure how much sense it makes to use the same implementation (unless we change the design):

        Screen_Shot_2017-05-25_at_19.27.22

        Screen_Shot_2017-05-25_at_19.27.49

        The assignee dropdown is very old as far as I can tell and has some collected technical debt. It also has a slightly different design than the search bar dropdown because the dropdown include the input field:

        Screen_Shot_2017-05-25_at_19.38.59

        Having said all that, in my opinion it would be great to have a single implementation for user dropdowns but I'm not sure it is worth the effort.

        @ClemMakesApps Maybe you can add your thoughts here?

      • username-removed-408677
        username-removed-408677 @ClemMakesApps ·
        Maintainer

        Currently, the API endpoint for the 2nd and 3rd images posted by @winh share the same API call.

        The first image (comment autocomplete) is a different endpoint because it includes adding groups to the results.

        I'm sure there are a few ways we can improve the code shared between these but I don't think it's worth the effort at this time as we have a lot of other places with a lot more technical debt

      • Chris Peressini
        Chris Peressini @cperessini ·
        Developer

        @winh this sounds really good. If I'm understanding the following correctly:

        - open dropdown (for the first time)

- autocompletion endpoint is requested

- when response is received, dropdown is filled

- response is stored in cache

- user types something

- autocompletion endpoint is requested

- users from cache are loaded

- when response is received, dropdown is filled

- response is stored in cache

        We only show cached results once the user starts typing, but not when the dropdown opens for the first time, right? I think that'll be good.

        We should still show a spinner below the cached results to indicate that more results are being loaded.

      • Winnie Hellmann
        Winnie Hellmann @winh ·
        Author Developer

        We only show cached results once the user starts typing
        We should still show a spinner below the cached results

        @cperessini Yes, exactly, that was my intention. :smiley:

      • Winnie Hellmann
        Winnie Hellmann @winh ·
        Author Developer

        It would be similar to #22921 (closed). Instead of only showing the current user immediately, it would show every user that has been in the dropdown earlier (only if matching the search criteria of course).

      • Chris Peressini
        Chris Peressini @cperessini ·
        Developer

        Sounds great @winh!

      • Jacob Schatz
        Jacob Schatz @jschatz1 ·
        Maintainer

        @victorwu will schedule when ready.

      • Jacob Schatz removed frontend label

        removed frontend label

      • Felipe Artur moved to gitlab#10099

        moved to gitlab#10099

      • Felipe Artur
        Felipe Artur @felipe_artur ·
        Maintainer

        Hey! :wave:

        GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

        If you have any questions about all of this, please ask them in our dedicated FAQ issue.

        https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

        You can also find more information here:

        Frequently Asked Questions

        For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

        What will we do with the repository names?

        https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

        Why rename gitlab-ce to gitlab-foss?

        Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

        I created a merge requests for CE, and this got closed. What do I need to do?

        You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

        How does the licensing work in this new setup?

        Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

        Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

        No. Merge requests submitted to this project will be closed automatically.

        Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

        Yes.

        How will this affect users of GitLab CE using Omnibus?

        No changes will be necessary, as the packages built remain the same.

        How will this affect users of GitLab CE that build from source?

        Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

        Where can I see a timeline of the remaining steps?

        https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

        Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

        Yes, these changes will be synced to gitlab-foss automatically, several times per day.

      • Felipe Artur locked this issue

        locked this issue

      Please register or sign in to reply