Feature management

Configuration

Disabling unwanted features is possible in projects, but adding more to this list is not recommended. Disabled features may adversely impact the the System Usability Scale, since it may lead to an unexpected and inconsistent user experience. Admin users cannot disable features at the instance or group levels, as they do not know what functionality end users may need.

Discovery moments

Feature discovery moments are notices presented in the UI that inform a user of additional features. These could be features available in higher tiers, or free features that unlock significant value to a user.

Highlighting higher tier features

Higher tier features should be easy to identify from the rest of the interface. Consider using the following badge to highlight them:

TODO:

Replace badge image with live example or link once the new variant has been added to GitLab UI. Create an issue

Specification

• Component name: GlBadge
• Variant: Tier
• Size: MD
• Icon: 16

How to use

• Ensure there is a clear connection between the badge and the feature being highlighted. For example, place the badge next to the name of the feature.
• When using the icon only badge, use a tooltip to display the tier name.
• Tier badge should only be displayed if the active plan is lower than that of the feature. For example if the active plan is Ultimate, and the related feature is also Ultimate, there is no need to display the tier badge.
• For trials, the tier badge should always be displayed.

Behaviour

• Links to tiers details.
• Can be removed from the UI via group or instance level settings.

TODO:

Add links to the documentation. Create an issue

Highlighting feature versions

Experiment and Beta features are subject to legal terms, which must be displayed next to the settings to enable said feature. Use the following UI text:

Number of features	Group setting	User setting
Single	When you enable this feature, you accept the GitLab Testing Agreement.	Subject to the GitLab Testing Agreement.
Multiple	When you enable any of these features, you accept the GitLab Testing Agreement.	These features are subject to the GitLab Testing Agreement.

Similar to higher tier features, feature versions like Experiment and Beta should be easily identifiable, using a badge with an explanation in a popover:

Experiment	Beta
What's an Experiment? An Experiment is not yet production-ready, but is released for initial testing and feedback during development. Experiments: Might be unstable or cause data loss. Are not supported and might not be documented. Could be changed or removed at any time. Are subject to the GitLab Testing Agreement.	What's a Beta feature? A Beta feature is not yet production-ready, but is ready for testing and unlikely to change significantly before it's released. Beta features: Have a low risk of data loss, but might still be unstable. Are supported on a commercially-reasonable effort basis. Have a near complete user experience. Are subject to the GitLab Testing Agreement.

TODO:

Replace badges with live example or link once a dedicated component has been added to GitLab UI. Create an issue

Specification

• Component name: GlBadge
• Variant: neutral
• Size: md or sm

How to use

• Ensure there is a clear connection between the badge and the feature being highlighted. For example, place the badge next to the name of the feature.
• When placing the badge, consider the available space and opt for a small badge if needed. The badge can be displayed either before or after the user interacts with the feature.
• When the feature becomes Generally Available, make sure the badge is removed.

Visibility

Feature visibility is dependent on a user's permissions or subscription levels, and on which features they've chosen to enable.

When to hide a feature

• A feature is hidden when the user shouldn't have access to it due to a lack of permissions. Hiding the feature is recommended because the user doesn't need to be aware of the functionality, and there is no UI that would allow them to obtain access. For example, we should hide the delete branch button if the user's role does not allow deletion of branches.

When to keep a feature visible

• When the user has access to a feature but it's not currently enabled. In this scenario, a feature may be visible but disabled. When a feature is disabled, there should be an explanation for why it's disabled, or controls that allow a user to enable or request access to the feature.
• When child-level settings are enabled from a parent level. In this scenario, a feature may be disabled or replaced with a read-only equivalent. There should be text explaining that the setting is configured at the parent level.
• Avoid using a tooltip to explain why an element is disabled as keyboard users can't move focus to the trigger to reveal the message. Exposing the message in the UI is preferred. For example, instead of disabling the merge button on a merge request with outstanding approvals, the button is replaced with copy to explain the state, Merge blocked: all required approvals must be given.