Banner policy

changed the description

assigned to @JobV

All banners dismissals should be saved in the database, not a cookie. For broadcast messages we can record the id/timestamp of the latest broadcast that was dismissed.

@JobV can you post a pic of one of the banners you are talking about? I want to make sure we are on the same page.

Same question as @jschatz1. When I think of banners, I envision this (blue banner at top):

When I think of empty state, I envision this:

@jschatz1 @sarrahvesselov

The new banners are pretty, but annoying, hence this issue.

Gotcha @job, thanks for clarifying.

Never show a banner again after dismissing in any project

Empty states should be used over banners whenever possible, because they are actionable and only applicable before usage.

Never use banners to replace good UI or great empty states

I can agree with these.

In the case of the ugly banners, I would like to phase those out all together. The message for the SSH key really belongs as a notification under your profile and I am sure we can find more intuitive ways to confirm actions than the bright blue banner.

In the case of the ugly banners, I would like to phase those out all together. The message for the SSH key really belongs as a notification under your profile and I am sure we can find more intuitive ways to confirm actions than the bright blue banner.

Right, I think the SSH key should be visible to a new user when they first sign in in some way, because if you want to use SSH, it's the first thing you'll need to do to start using GitLab.

marked this issue as related to gitlab-foss#35660 (moved)

marked this issue as related to gitlab-foss#35741 (moved)

mentioned in issue gitlab-foss#35741 (moved)

changed milestone to %Next 2-3 months in gitlab-foss

I think there are a few different themes coming together in this issue.

Banner types & styling
Banner persistence
Banner display logic

1. Banner types & styles

In the illustrated examples, we have three different types of banners:

Confirmation of success (the blue one)
Warning banners (the orange one)
Promotional banners (the light blue ones)

There are probably other "banners" for instance, the broadcast message banner that admins can send out and maybe others that I can't think of.

We also have the feature promotion banners for EE as default & .com plans which are similar to the light blue promotional banners, but have a white background, such as the one below. cc @hazelyang @sarrahvesselov

2. Banner persistence

As @sytses points out, for many of these banners, we are storing the display state locally in a cookie. This is probably why you have seen the Customize your experience banner about a 100 times @JobV!

3. Banner display logic

In the below example, it's entirely feasible that you could have three banners displaying if there's a broadcast message currently active.

There may be valid reasons to display multiple banners together, but ideally it should be avoided.

One of the first projects I worked on at Skype was called "Dynamic Content" and it was a system to deal with exactly this problem.

It solved a lot of these problems by having a standard banner display unit, which had various properties such as the type of banner, which effectively depicted the colouring (info, warning, error/critical), space for content and customisable images/icons.

We also used the system to limit the number of promotional messages a user could see in a day/week so that they didn't feel they were being bombarded. A lot of our banners weren't that contextual to the UI as the UI was a lot simpler, so this may not be necessary for now.

So I think there are effectively a few things we should be doing with a bannerManager:

Store banner state (dismissed) on the server to prevent duplicate display of banners across multiple computers and migrate local state to server state on first "run"
Define banner types and even consider if some of the success state banners belong in this system or belong at all. When I create a new project and get redirected to the new project page, do we really need to also present a blue banner to confirm as much?
Look to see if we do want to implement any additional logic to prevent banner fatigue

Define banner types and even consider if some of the success state banners belong in this system or belong at all. When I create a new project and get redirected to the new project page, do we really need to also present a blue banner to confirm as much?

I am with you on this @mydigitalself, defining the banner types and appropriate use is key here.

I have already created an issue to address the banner use cases you described above, would love your thoughts there: https://gitlab.com/gitlab-org/gitlab-ce/issues/35741