Create Notification functionality for ongoing product education

[erzhtor]

Potentially, we could create a list of core features/functionalities that our product(s) provide to the users and show users periodically "Tips and Tricks" on randomly picked features that the user hasn't yet tried (we can store to user's settings what user has already tried and not yet). Maybe some popup-like UI.

Follow-up on PD 31 doc

[github-actions[bot]]

Heads up @muratsu @rrhyne @jjinnii @ryankscott - the "team/growth-and-integrations" label was applied to this issue.

[sourcegraph-bot-2]

Heads up @muratsu @a-bergevin - the "team/growth" label was applied to this issue.

[a-bergevin]

Originally this issue was just about "tips & tricks" but I'd like to do some research more generally around a generalized UI approach to ongoing feature introduction. When a user is new this space could be used as a key part of onboarding, but could also be used to show: tips & tricks, announce new feature releases, etc. Copying below some context from the Cloud team on a similar issue they had in Jira, but need to close out with their pivot to a new focus area.

[a-bergevin]

Description As we get closer to public and private code for users on Sourcegraph Cloud, we need to intuitively surface the system status related to code host connection status and repository sync status.

Our general problem statement here is:

For developers using Sourcegraph Cloud as an individual, we need to give them confidence that their search results will reflect their current, up-to-date code base, while also making it easy to identify when things have gone wrong and giving them a path to fix issues. We also need to surface when users don't have any code host connections or repositories, and encourage them to create those connections and add their code.

However, we have to think about this systematically, and there's a couple of other challenges we have to consider:

For organization admins on Sourcegraph Cloud, we need to surface system status as it relates to their organization alongside their own personal code. The same goals that apply to a user adding their own code host connections and repositories apply here.

For organization members on Sourcegraph Cloud who aren't admins, we need to surface system status as it relates to that organization alongside their own personal code. These users share the same goals around building confidence and surfacing when things have gone wrong, but the users may not always have permissions that give them an action they can take in response.

Sourcegraph Server shares the same needs around confidence and actionable next steps, but at a global instance level rather than at the user or organization-in-multi-tenant-environment level. In the future, it may also be possible for "organizations" in a Server install to have their own code host connections and repositories. (This would essentially reflect Cloud as an instance.)

While exploring this problem space, I identified a general set of notification categories:

Onboarding: Steps to take after signing up

Global alerts: Things that affect the entire Sourcegraph instance, like external URL configuration, licensing, version updates, site config issues.

Background status: Things that affect the experience of using Sourcegraph, but are more self-contained in a given context.

Search status: Specific inline information related to a given search.

(Does not exist today) Product updates: Announcing new features, feedback requests, etc.

Very generally, our onboarding, global alerts, and search status notifications are well-categorized and work effectively. We are missing the ability to share product updates, but this problem and context is distinct from the need to surface system status.

Server already has a basic "Code host status" UI for visualizing system status that works at the global instance level. For reference: This UI is fairly effective at surfacing sync status at the instance level, and is well-contained. Based on the immediate problem statements, my sense is we should avoid making a more comprehensive notification system or trying to combine multiple types of notifications in one place, and instead, iterate on the current "Code host status" UI to meet the shared needs between different types of users on Cloud and Server.

Proposal The design of the "Code host status" element is a good starting point to iterate and better align with the concept of "Sync status," and then surface distinct status points:

On Cloud:

For the user's own repositories

For organizations the user is a member of

For organizations the user is an admin for

On Server:

For the instance as a whole

This will align nicely with the information architecture: the user has code host connections and repositories, and each organization has code host connections and repositories, and each action the user can take in response will take them to the specific relevant product area.

Here's a list of cost host and repo statuses:

https://www.figma.com/file/0567AnXEpQTzQXkgs7AzEh/Notifications-System?node-id=423%3A5

And here's a breadboard-fidelity visualization of how these different states might be represented:

https://www.figma.com/file/0567AnXEpQTzQXkgs7AzEh/Notifications-System?node-id=423%3A6

This would be triggered using a similar status indicator as we use today in the menu: Then, we would also update the respository settings view to reflect status (index, cloning, reachability) in a single view:

This approach would give us coverage for all kinds of status events, give our users immediate confidence at all times, and adapt seamlessly for both Cloud and Enterprise. It also gives us a few extra touchpoints to encourage users to connect with code hosts and add their repositories, and for rolling out Cloud GA, a way to permanently surface the new features to existing users.

(TBD)

Onboarding implications This approach has a slight overlap with the "Get started" element, which contains the "Add repositories" item. My instinct is that this is probably fine, as they're in different contexts (onboarding vs. status), and they don't compete with each other.

[a-bergevin]

Another issue on this topic (old) https://github.com/sourcegraph/sourcegraph/issues/16510

[a-bergevin]

Interesting pre-release announcement I ran into on Gitlab