Persist frequently used groups and projects in the top navigation across devices

Problem to solve

The top navigation provides quick access to frequently used projects and groups. This feature, however, uses local browser storage and is not persisted anywhere in the database. Users who access GitLab from multiple devices or from different browsers will see different content. Additionally, if the local storage is cleared for any reason, it can never be retrieved. This can be frustrating and confusing to users.

Screen_Shot_2020-10-15_at_4.08.21_PM

Further information

The frequent group and project values are stored in the browser's Local Storage under the keys <username>/frequent-groups and <username>/frequent-projects as a JSON text string.

Since Local Storage is specific to the browser this is why the data isn't consistent between devices.

Proposed solution

Original

Instead of storing the data in Local Storage, it should be persisted as a custom attribute of a user and stored in the database. The page should reference this data when building the list so it can be consistent based on the logged-in user regardless of the device they view it on.

Revised

Upon understanding the potential complications and performance implications that have been discussed in the comments below #254328 (comment 434736699), we are going to divert from the original proposal for the following issues:

  • Improve the empty state for frequently visited links in the Projects/Groups menus #275964 (closed)
  • Add list for "Recently Viewed" in "Your Projects" #275967 (closed)
  • Analytics information for frequently visited links in the Projects/Groups menus #275968 (closed)

We may revisit introducing the list as a "Recently viewed" list as part of work around top navigation consolidation https://gitlab.com/gitlab-org/ux-research/-/issues/1169.

Details & open questions

  1. What is the logic behind "frequency" here? If we store a visit_count or something like that we might be able to use this as a way to merge data.
  2. What should we do with the existing local storage?
    • If possible, we could do something like:
      1. If no user data exists, look for local storage
      2. Add data from local storage (if it exists) to the user data
      3. Delete frequent projects from local storage data
      4. If there is user data and local data that conflict (for example, user signs in on another device after already migrating data from local storage) then we can figure out if there's a way to merge that data. If not, we can probably just ignore and delete it.
  3. Are there any reasons we would want to let the user opt out of this? Or to manually manage their list?
    • We should keep this iteration very small but if there is good reason to allow for users to manually audit their lists we could expose that later.
Edited by Michael Le