The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Stage | Foundations |
Maturity | Minimal |
Last reviewed | 2024-08-23 |
Thanks for visiting this direction page on the Notifications category in GitLab. This page belongs to the Personal productivity group within the Foundations Stage and is maintained by Jeff Tucker.
This direction page is a work in progress, and everyone can contribute:
People using GitLab can guide work throughout the entire DevSecOps lifecycle — from planning, to development, verification, and ultimately delivery. Having all of these capabilities within a single tool is powerful and efficient, yet requires users to stay up-to-date on changes and discussion happening across many parts of the product.
GitLab to-dos are the product experience intended to address this need. However they were designed to adhere to the GTD model: the only "notifications" we surfaced within GitLab were actionable tasks for the user. Our research has found that deciding what's actionable is a very personal, subjective question that varies by person — what some users find actionable, others find as noise, and vice versa. Instead, users want more visibility into their notifications so they can decide which they need to act on.
In contrast, email notifications provide an exhaustive set of notifications for nearly every event that happens in GitLab. Some GitLab users have abandoned to-dos entirely in favor of email notifications, as this gives a more thorough way to stay up-to-date. While this gives them more visibility into events occuring in their projects, they must spend significant time each day processing their email inbox to avoid missing an update. Additionally, they are required to jump between email and GitLab as they triage and take action on notifications.
We want users to stay up-to-date within GitLab more efficiently than they could via any other tool. We will do this by:
The way each person uses the current email notification system and To-Do List features are highly personal. Our goal is to create a notification system that people can trust, and that's flexible enough to accomodate these many different ways of working.
The current To-Do List is used primarily by internal GitLab team members, but not by external customers. There are also issues with retention on the current To-Do List. With these improvement efforts, our focus is to increase customer usage and retention, and we are prioritizing efforts that will aid that longer-term goal. However, we will do our best to minimize the impact on internal users as we make these improvements, so as not to disrupt existing workflows.
To begin, we will focus on the Delaney (Development Team Lead) and Parker (Product Manager) personas, as these are the two personas whose workflows will be most impacted by these changes. See Target Audience to learn how we will expand to support other personas.
Our key initiatives will include:
Introduce GitLab notifications center
Users need a simpler, more efficient way to stay up-to-date on work happening in GitLab. We will add a native notifications center to the platform, and allow people to triage, manage and action notifications within the product. We are currently designing this experience and will add more details once we have validated these designs.
Team leads want to be notified of all comments in a discussion so they can take action even when they're not explicitly mentioned. Currently, GitLab only creates todos to review a comment when you are directly mentioned. This drives team leads rely on email notifications, which leaves them bouncing back and forth between GitLab and their email inbox.
GitLab users should be able to keep up with conversations within GitLab. We will introduce additional web notifications for replies to discussions you've participated in, and improve the behavior for automatically resolving notifications to work better with discussion threads.
Provide fine-grained control for web notifications
Introducing more notifications into GitLab risks creating a new problem: making noise that distracts users from focusing on creating software. The types of notifications that users care about vary from person to person, so we need to provide tooling that allows users to tailor their notifications to exactly what they need to remain productive.
Quickly review a large volume of notifications
Even with support for customizing notifications, people can still end up with a large inbox of notifications to review. We want to provide ways for users to quickly review a large volume of notifications. We are considering ideas like:
Internal framework for notifications
Currently, email notifications and to-dos are managed by completely separate systems. As we seek to gain parity between these channels, we need a way for teams to surface new notifications without having to do so in two places. This framework will enable teams to maintain the content and logic for their notifications without needing to deal with the underlying notification infrastructure.
We are working to track how these improvements impact people as we iteratively add them into GitLab. We will periodically conduct UX Scorecards to assess the experiences. We are also working to create a baseline metric for this experience that we can track over time.
Problem validation
We have audited previous research, user comments, and internal explorations to understand the core challenges and opportunities in this space. We are now conducting light-weight user research to validate the key themes we uncovered before moving forward to address them.
Initial design discovery
We have designed an initial full notification workflow. We are continuing to refine this design, and to assess how we can iteratively introduce these proposed features into GitLab.
See our roadmap in GitLab.
Watch our latest kickoff video to see our plans for the current milestone.
Notifications are used by all users, so our long-term vision must accomodate a variety of needs. In order to make progress, we will focus on a subset of personas that have a pressing need to remain up-to-date with work happening in GitLab:
Once we have created an experience that they love, we will broaden our focus to other people that use GitLab daily. We see the following personas as being our key targets in this second phase:
While Notifications doesn't represent a competitive category, the core user experience of GitLab will impact how well GitLab performs in the market. We take inspiration from others in the field that are delivering exceptional notification experiences.
GitHub
GitHub introduced their current notifications experience in 2020. They received significant praise for this upon launch, and we continue to hear requests from customers to bring an equivalent experience to GitLab. There are a few key details that we've noted as being particularly impactful:
Linear
The founder and original designer of Linear had years of experience as a designer before starting Linear, so it's no surprise their product is beautifully and thoughtfully designed. The inbox view is a core part of the Linear workflow, so it is a mature feature packed with innovative details:
GitDock
Built by GitLab Team Member Marcel van Remmerden, GitDock is a MacOS/Windows/Linux app that displays all your GitLab activities in one place. Instead of the GitLab typical project- or group-centric approach, it collects all your information from a user-centric perspective.
GitLight
GitLight is an open-source tool for managing notifications from GitHub and GitLab in a single interface. Like GitDock, this tool is building on top of the concepts offered by GitLab to create new experiences. It has some advanced concepts that make it stand out:
Honorable mentions
Notification experiences are not unique to developer tools — they're a common feature in collaboration software. We're looking beyond tools in our space to see how other domains are solving this problem as well.