Blue dot tooltip for Issue boards

changed the description

marked this issue as related to #3034

marked this issue as related to #3049 (closed)

Issue for the Tanuki tooltip @victorwu @JobV. I added a quick codepen animation mockup to the description. May be of interest to @dimitrieh, I know we have had similar issues out there for a while.

marked this issue as related to #2735 (closed)

changed milestone to %10.0

@sarrahvesselov : Looks great! When we last spoke, I had thought you meant the Tanuki would be pulsating and right in the nav itself, next to one or more of the menu items. Where are you suggesting the Tanuki should be placed in this design?

Not the GitLab logo itself right? (You can customize the logo, so that wouldn't work in any case?)

Where are you suggesting the Tanuki should be placed in this design?

Nowhere @victorwu, this was simply to show the concept, not placement. The screenshot is from the Codepen Demo I created.

I had thought you meant the Tanuki would be pulsating and right in the nav itself, next to one or more of the menu items.

Correct. I am not 100% sold on this placement which is why I simply coded the concept so we could have more discussion on where this would have the most impact with the least amount of annoyance.

cc/ @dimitrieh @tauriedavis @pedroms @hazelyang @cperessini

Thanks @sarrahvesselov for the clarification. I think that position looks great. Assuming it will have a subtle bounce, I think it will looks really clean and professional.

Right now in your mockup it looks weird because there are 3 Tanukis. But for other on-prem users, they have their own logo for the instance, and the project logo also won't be a Tanuki. So I think it'll look really good.

This seems like a good first iteration.

Throwing out some ideas:

Should the issue board tooltip and service desk tooltip live together? It seems like they could benefit from being displayed in different locations or by targeting different actions.

Examples:

Created an issue and added a milestone? Tell the user how they can manage their milestone using issue boards
Created an issue and added a label with "Support" "Help" etc.? Tell the user how they can manage support requests using service desk.

Will we just be showing these tooltips if a project hasn't set up service desk or has no boards? Probably not necessary to show them if its already set up and actively used.

Right now in your mockup it looks weird because there are 3 Tanukis. But for other on-prem users, they have their own logo for the instance, and the project logo also won't be a Tanuki. So I think it'll look really good.

Also agree here. On GitLab.com the tanuki seems really duplicated. It'll look good for other instances, of course. Do we want to use the tanuki of gitlab.com?

Right now in your mockup it looks weird because there are 3 Tanukis.

This was my very first thought. Most users will not see this replication.

Should the issue board tooltip and service desk tooltip live together? It seems like they could benefit from being displayed in different locations or by targeting different actions.

I think these are both excellent ideas @tauriedavis! Promoting both in one place was a stretch. I really see this feature being used to promote a lot of different areas as you navigate around. The focus, for now, is on promoting Issue Boards and Service Desk in particular. What do you think @victorwu?

Probably not necessary to show them if its already set up and actively used.

Exactly. This is just to educate those that are not already familiar.

Do we want to use the tanuki of gitlab.com?

Open to other suggestion! We could also alter the color. @pedroms had a mockup for the header that used a purple tanuki and it looked great.

Thoughts:

As a user, I'm not sure I'd know what the Tanuki logo represented, say compared to a New tag, or even just a glowing dot. For .com and non-modified self-hosted, the Tanuki would be confused with the main logo, and at any rate, it doesn't look actionable (although that could be solved).
It is better to break out each message into their own notification, so the 3 things above would be separate interactions. Just don't go too far and have 10+ notifications for new users. That's a horrible experience!

it doesn't look actionable

Not sure if you looked at the codepen link in the description, the tanuki moves to let you know it is actionable @markpundsack. This is a common UX pattern:

https://codepen.io/sarrahvesselov/pen/VzeqqN/

It is better to break out each message into their own notification, so the 3 things above would be separate interactions.

See @tauriedavis comment https://gitlab.com/gitlab-org/gitlab-ee/issues/3054#note_36363427

No, I didn't look at the codepen; just the static image. The animation helps.

See @tauriedavis comment https://gitlab.com/gitlab-org/gitlab-ee/issues/3054#note_36363427

Yes, I was agreeing with her. :)

Thanks. @sarrahvesselov : Could we limit it to just boards and service desk for now. Since that's our present goal.

How about we show it by default for users. And once they've dismissed it, it never shows again. In particular, we show it for a given user for the first time they visit any project's page (and thus see a project's navigation). So it's not dependent on projects or boards. But dependent on users.

Could we limit it to just boards and service desk for now. Since that's our present goal

Sure, I was not suggesting otherwise. Both @tauriedavis suggestions are focused solely on Issue Boards and Service Desk @victorwu, it is just a different implementation. Are you saying you want to stick with the tanuki (or whatever it eventually becomes) on the navigation list?

It seems like they could benefit from being displayed in different locations or by targeting different actions.

I agree with her assessment here.

added feature proposal label

changed the description

added frontend label

added Deliverable label

I see that you updated the description @victorwu - Are we sure we want this repetition in the UI? Also, are you suggesting we use a cartoon version of the Tanuki?

"Dismissing" for a user means over all possible projects in the GitLab instance. As long as the user has dismissed it once ever in any project, it counts for the entire project. This ensures that the user only ever dismisses a Tanuki once.

The tanuki could potentially be used to promote/educate on many different items and areas. Are you proposing that dismissing one tanuki essentially disables all of them? Or they just never see that particular 'tip' again?

@sarrahvesselov . Feel free to update the description, update the design, and add the assets, etc. That's just the most updated version per the feedback so far.

I think we are missing a final image. We can use the Tanuki if we don't have a better idea. (What I have in the description is just an emoji to make it easy to make the mockup.)

I'm proposing that all the Tanukis are handled independently. I think that's the easiest way to create it as a first iteration. So if you dismiss one, it's just for that particular one.

I'm proposing that all the Tanukis are handled independently. I think that's the easiest way to create it as a first iteration. So if you dismiss one, it's just for that particular one.

Thanks for clarifying @victorwu, we are on the same page then.

I disagree with having two tanukis so close together in the UI. I also agree with comments stating we should not lump both tips together. I would suggest that we add a tanuki tip (or whatever UI convention we go with) in the nav to highlight Service Desk.

We can place another tip somewhere else to highlight boards. Perhaps as @tauriedavis suggested here:

Created an issue and added a milestone? Tell the user how they can manage their milestone using issue boards.

@sarrahvesselov : For the purpose of a simple design with the Tanuki-in-nav idea, we can consider doing:

Always show only at most one bouncing Tanuki in the nav, at a time.
Show the highest precedence Tanuki that you (as the user) have not dismissed yet.
The precedence order after this issue would be:
- Service desk
- Boards
In the future we could add more Tanukis in different nav elements.
For brand new users, they would see a steady stream of Tanukis as they use GitLab.
For ongoing users, each time they upgrade to a newer version, they'll see a handful of new ones during the course of that version (however many we release).

This would solve the Tanuki-overwhelming problem.

I don't disagree with adding other onboarding flows / designs. But I think if we just limit to bouncing-Tanuki-in-nav for this iteration, we'd be able to get some good feedback and capture more users, and just focus on the efficacy of this one feature.

Always show only at most one bouncing Tanuki in the nav, at a time.

Yes!

Show the highest precedence Tanuki that you (as the user) have not dismissed yet.

The precedence order after this issue would be:

Service desk

Boards

Yes!

In the future we could add more Tanukis in different nav elements.

For brand new users, they would see a steady stream of Tanukis as they use GitLab.

For ongoing users, each time they upgrade to a newer version, they'll see a handful of new ones during the course of that version (however many we release).

Yes. Yes. Yes. Thanks @victorwu!

@dimitrieh @hazelyang Do either of you have some ideas on the design for this? I would love to hear other ideas for the Tanuki and even the content of the tip that pops up.

i will try to see to this issue :)

assigned to @dimitrieh

changed the description

Thanks @dimitrieh . If you have any changes, please update the description (including removing any text/images that do not align with your changes).

assigned to @victorwu

changed the description

assigned to @ClemMakesApps

@sarrahvesselov @victorwu @tauriedavis looking at this issue I think this may require a bit more conversation before implementation as it is the introduction of yet another onboarding/explanation paradigm. I feel this is becoming a bit of a mess.

We currently have banners, alert boxes, panels, different panels with illustrations, empty states, perhaps toasts (don't know if these are in already), and with this we would introduce toggle-able tooltips on special hero icons...

just an example of another onboarding paradigm (although a little invading). Inbox by google uses this: example

Let's document each paradigm, see which is used for what.. and lean down. Throw away as much as possible and focus the attention of the user, instead of diluting it across many different kinds of "alerts".

Another possibility here could be for example to have a special todo item pop-up, with text and a actionable button on it to test out the new feature... basically treating the todos as a notification manager.

I wonder if sufficient discussion has happened here to validate that this is actually the correct way to go.

Still if we would ignore all that and purely look at how to implement this close to the intended idea described above in the description I would agree with mark here: https://gitlab.com/gitlab-org/gitlab-ee/issues/3054#note_36377107 and we should simplify as much as possible here.

I see no reason to duplicate the tanuki icon and to use it for this feature :). We just need to say to the user: "Hey there is something new here!" Perhaps with an explanation.. but again perhaps that explanation should be covered by any of the already existing paradigms already in the application...

Also the actionable "dont show me again" link shouldn't be necessary imo. When the user clicks, it should just be deactivated after dismissing the pop-up or going to a different view, similar to how slack does it.

https://gitlab.com/gitlab-org/gitlab-ce/issues/25341 already has some of this designed in some way:

Although to lean this down, i don't think this needs the counter in there.. that would only confuse it with places such as the assigned issues/mr's and todo indicators. . So just the dot.

In that sense, as the color red is not used yet.. it may be an option to go with that.. as to indicate "new things".

This can be seen in other services as well: dribbble or android notification badges

Lastly.. i don't think the bouncing animation is necessary. It sort of forces users to act upon it.. as it distracts.. even when they do not want to or do not have time for it right this moment. Let's cut that out as well. In that sense I think the "red" color again is enough as it is not used anywhere else.. and with the dot it stays relatively small.. making not much of an invading impact on the users experience.

So with this we arrive at something like:

or

These badges.. work the best if combined with icons.. so in this sense we would need icons for the sub nav items as well..

So for the explanation.. i think that could be covered on the page itself with a explanation panel.. or we should get rid of those.. and replace them with the same paradigm we are introducing here.

as said before, this may need extra discussion or we are just introducing another one off paradigm here...

thoughts?

Thanks @dimitrieh for the discussion. Let's proceed with the existing design as spec-ed out. We can tweak the bouncing (or lack of bouncing) and the image/tanuki/icon as development proceeds. But let's proceed with the general design of drawing attention to the nav item and an inline dropdown.

This is a design iteration (as with everything we do). So if it is not well-received, we will try other things. (Like the "what's new" design.)

This is the highest issue in Discussion for 10.0. So it should not be slowed down at this point. cc @ClemMakesApps .

@victorwu i do not intend to slow it down . Merely make us aware of the current situation and find the simplest way to implement this. Please read above my explanation as in how we can/should simplify, resulting the in the design at the bottom of my comment: https://gitlab.com/gitlab-org/gitlab-ee/issues/3054#note_37055584

I appreciate your concerns @dimitrieh and have created an issue in the design repo for us to review and discuss these concerns. You can get the ball rolling here: https://gitlab.com/gitlab-org/gitlab-design/issues/38

I see no reason to duplicate the tanuki icon and to use it for this feature

Fine with me. Whatever we choose, I would like it to have personality. It should be recognizable as a helpful feature in order for it not to be confused with regular notifications. Your example using the circle resembles a notification missing a # and could be dismissed as a UI bug.

When the user clicks, it should just be deactivated after dismissing the pop-up or going to a different view, similar to how slack does it.

This sounds good.

Lastly.. i don't think the bouncing animation is necessary. It sort of forces users to act upon it.. as it distracts.. even when they do not want to or do not have time for it right this moment.

I disagree here. The purpose of this feature is to bring attention to the feature. The purpose is to distract the user in order to help them understand how they can improve their workflow. To go back to my first point, we don't want the user to dismiss this as just another notification. Giving the notification a personality, letting users know that it is there to assist them, can help forge a relationship that transcends the minor annoyance. This is a common experience in many applications. As @victorwu pointed out, if it is not well received, we can look at other options.

As an example of what we are going for here, please take a look at the way Asana does this same thing. The tips are easy to dismiss and help new users understand what they can do within the application.

I'll try to be as brief and direct as possible:

Design specifics: I like the “fox” emoji for its personality, it makes me want to click on it On the other hand, it departs from our iconography style and might be “too much”. I've never seen such a visually strong indicator for feature discovery, but it might just work! Who knows, I think we need to have it implemented somehow (maybe a prototype). For some helpful guidelines, take a look at Material Design's: https://material.io/guidelines/growth-communications/feature-discovery.html
Problem: “Issue Boards and Service Desk are under-utilized features. Many users do not know they are there or how they could benefit their workflow.” Maybe I missed something, but have we done some research to conclude this? If so, can someone share the link please? We definitely need some kind of feature discovery pattern(s) to enhance GitLab's UX, but I'm concerned if we're solving the right problem. Some questions:
- Have we found that most users have the need to use those features but simply can't find them? If so, the proposed solution seems to fit this problem of discoverability.
- Have we found that most users don't understand those features or see the need for them? If so, some of the solutions suggested by @tauriedavis seem to fit this problem of understanding the benefit. “Feature discovery prompts have more impact when they are presented to the right users at contextually relevant moments. When presented to the wrong user at the wrong time, they can be intrusive and annoying.” source

Please don't take me wrong, I'm sure many people in this discussion have thought about this in depth, but it's hard to make good contributions/help move the discussion forward without this kind of problem context.

thanks @pedroms.

When presented to the wrong user at the wrong time, they can be intrusive and annoying.

This is my main worry :) Although i have checked out asana and see what @sarrahvesselov means. And i think it could work.. or rather that we need such a paradigm to help users discover, if we find such problems. My other concern is that we don't want different visual element shouting over each other for attention.. or that we bloat our UI with too many elements doing sort of the same thing, hence https://gitlab.com/gitlab-org/gitlab-design/issues/38 (thanks @sarrahvesselov )

Asana's implementation:

For some helpful guidelines, take a look at Material Design's: https://material.io/guidelines/growth-communications/feature-discovery.html

This is actually really nice! Thanks!

Alright I came up with the following, which is sort makes use of components already existing in gitlab, like the toggle-able tooltips, of which this becomes an extension of, in combination with the special pulsating dot (which is the simplest form and universal animation).

I think the user still needs to acknowledge he/she has read the message and should dismiss it.. as the user can easily do not read the message.. as the message will pop-up from mouse over instead of clicking.

So a mouse-over tooltip/ rather than toggle-able, but with clickable area's, resulting in:

https://codepen.io/strages/pen/KvmNrO

and

or with image:

I think this design strikes a nice balance

cc: @ClemMakesApps

added UX ready and removed UX labels

updated issue description

For now with the version without an image, as that is the simplest form, and is a bit more readable perhaps.. Although I like the sneak peak that the image gives.

changed the description

mentioned in commit gitlab-design@71b04900

Maybe I missed something, but have we done some research to conclude this? If so, can someone share the link please?

These are all valid questions @pedroms, thank you for raising them. @victorwu should be able to give you more insight here.

“Feature discovery prompts have more impact when they are presented to the right users at contextually relevant moments. When presented to the wrong user at the wrong time, they can be intrusive and annoying.”

I am in 100% agreement on this @pedroms but @victorwu felt this was beyond the scope of this issue at the moment (see https://gitlab.com/gitlab-org/gitlab-ee/issues/3054#note_36487816)

Is this something we want to save as a cookie or in localstorage? I'm thinking cookie but just want to double check

@ClemMakesApps imo we need this to be tied to the user account.. as we don't want to repeat such hints for users who have already dismissed them.. even when they login to a different computer. So yes this prob needs a little backend

@DouweM I think this is actually quite important to do with the other banners as well, which are dismissible (they keep popping up! ).

I spoke with @dimitrieh and he said he wanted us to show one red dot at a time. @victorwu do you have a preference to a specific order of which feature to highlight first?

I am not crazy about using red (spoke to @dimitrieh about this ). Any other thoughts on this feature @pedroms @hazelyang @cperessini?

@ClemMakesApps @dimitrieh : The specs for how and when the tanuki/dot/icon should show is spec-ed out in the issue description. Please review and go ahead and update the description so that we always have the SSOT.

Please please please always review the description first so that we can minimize confusion and not have to re-discuss ideas that we already have.

@ClemMakesApps : I think FE storage is totally fine. If that's easiest to build, let's update the description to specify that the "state" of the tanukis is only up to the device / browser you are using. I think that's fine and is consistent with other places in GitLab.

@pedroms : Regarding usage:

Maybe changing the color would help reduce the problem with it looking like a notification. I agree with Sarah that red is typically used to symbolize a notification. Using a different color could solve this.

Changed the color to orange:

https://codepen.io/anon/pen/brWveP

Also, we should be using 8px grid design system moving forward so the dot here is reduced to 8px.

I had the same idea @tauriedavis.

For placement I think we can center it vertically in the row and give it 16px left margin from the text. We are using a soft grid instead of hard, right? (article for reference, under the Two methods section)

Talked with @cperessini about hard vs. soft grids in slack. We discussed:

Elements are using a hard grid, so they are designed in multiples of 8. We don't strictly follow a hard grid because character length changes (ex. List vs. Boards), and we do allow for padding/margins to be based on the element itself, rather than the container.

So for this example, the dot itself should be a multiple of 8px, like our other elements. And the margin can be based from the text it is next to and should also be a multiple of 8px. (So for example, Chris' suggestion of 16p would work great).

Not meaning to intentionally introduce yet another color, but I think blue makes the most sense as it's an informational notice, not a warning (orange), danger (red). I wouldn't mind green as it hints to success and “good stuff”

I was thinking blue originally, as well. But I wasn't sure it would stand out next to the purple as well so I went with orange, which is our $orange-500 color.

But we do label our blue buttons as info buttons, so I like your idea.

Here is $blue-500 which does look nice and stands out

https://codepen.io/anon/pen/brWveP

I think blue might stand out as the icon will be pulsating and it's in a clear and high-visibility area.

Edit: just saw your comment update with the mockup. Looks great to me! @dimitrieh WDYT?

For now with the version without an image, as that is the simplest form, and is a bit more readable perhaps.. Although I like the sneak peak that the image gives.

I really like the preview as well @dimitrieh. It makes it feel more like a helper and less like a tooltip. We can look at doing this in a future iteration

@ClemMakesApps : I think FE storage is totally fine. If that's easiest to build, let's update the description to specify that the "state" of the tanukis is only up to the device / browser you are using. I think that's fine and is consistent with other places in GitLab.

@victorwu @ClemMakesApps I very much disagree with this. As i have stated my preference here: https://gitlab.com/gitlab-org/gitlab-ee/issues/3054#note_37166651 . Imo this is creating UX debt in the long run, unless of course we actually follow up on this in the next iteration.

We are instructing a user, not the device they are on. Therefore if a user logs in on another device, they should not again be annoyed by notifications/UI that they already dismissed on another device.

Please reconsider :)

@pedroms @tauriedavis @sarrahvesselov @cperessini thanks for weighing in here! much appreciated! Let's go with blue in that case!

I'll update the description with the details mentioned!

changed the description

I added the part about storage in the description as:

State can be stored with FE data, but is preferred to be stored on the user.. so it persists across devices (otherwise creating UX debt )

mentioned in commit gitlab-design@02e0e54f

@dimitrieh @ClemMakesApps : Many of our similar banners/notifications are using FE storage only. As we've allocated FE resources initially for this feature here, we'll implement that version initially here with only FE storage. That is the scope the product and engineering team assigned the development resources for.

If there is additional capacity at the end of this iteration (or in future ones), we should address those BE storage conditions separately with BE resources. Updating description accordingly.

changed title from Tanuki tooltip for Issue boards and Service desk to Blue dot tooltip for Issue boards and Service desk

changed the description

I really wanted to use CSS to do this but ran into a few hiccups. Going to follow @jschatz1's recommendation and use popover.js for this

Did some more investigation into popover.js, and I think we maybe able to do CSS instead

@dimitrieh, are we using font awesome for the thumbsup? Or are we using our own svg icons?

@ClemMakesApps I used font-awesome in my example ;) However.. let's ask @hazelyang if she has a custom thumbs up icon ready to go

Here is the thumbs up icon I see in her icon directory:

thanks @tauriedavis ! let's use that one

added it to the description

changed the description

@dimitrieh : The scope of this issue is both issue boards and service desk. Could you also provide a mockup for the service desk tooltip / dropdown UI. (Or at least just specify the text that will go if it's identical to the issue board design.)

This was specified in the original description. I think you may have hidden it in one of the description updates. (Totally fine btw.) But please make sure the latest is specified in the description now. Thanks!

cc @ClemMakesApps

mentioned in issue #3049 (closed)

@victorwu updated description with the following designs:

However, I still think the image preview sneak peak, gives it a bit more pop. wdyt?

@hazelyang would you think illustrations would work better here?

changed the description

The screenshots look a little heavy to me but I like the idea of having illustrations there

The designs do not show the tooltip for the flyout menus. Eg:

Can we minimize scope and not show the tooltip for the flyout menu? @victorwu @dimitrieh

@ClemMakesApps I think it's fine to only have it on the normal menu, not the fly out menu. Also as there can always only be 1 dot visible.

I think it's fine to only have it on the normal menu, not the fly out menu. Also as there can always only be 1 dot visible.

Yes, currently I have it in a WIP MR and the next dot (when user clicks don't show this again) appears after a page reload, so we aren't overly distracting the user with blue dots

mentioned in commit gitlab-design@ec3c0d3c

The screenshots look a little heavy to me but I like the idea of having illustrations there

@hazelyang see if you have time available for this or have any illustration lying around which could be reused for this!

will assign you temporarily

assigned to @hazelyang

I think it's better to have a background in the illustration to separate the text part and graphic part in this case. The current style doesn't work well in color background, so I changed the graphic style.

Boards	Service Desk

PNG: graphic-boards graphic-service-desk

Love it @hazelyang!

@ClemMakesApps : My mistake for not better planning of this issue and https://gitlab.com/gitlab-org/gitlab-ee/issues/3049.

Can we do the following:

Change the scope of this issue to be just the issue boards's tooltip.
If you've already done work on the Service desk part, could we hide it? So the code is ready to go.
I'll create a separate ticket to add the service desk part.
Once https://gitlab.com/gitlab-org/gitlab-ee/issues/3049 is merged, that separate ticket can be worked on.
That separate ticket can be 10.0 Stretch .

Does that work?

@hazelyang : The graphics look super.

@ClemMakesApps : Is it okay if we squeeze the graphics into this issue? Or should we scope that into separate issues?

Sounds good, we can add the graphics @victorwu

I think it's better to have a background in the illustration to separate the text part and graphic part in this case. The current style doesn't work well in color background, so I changed the graphic style.

Should we keep with PNG or use SVG?

mentioned in issue #3212

changed title from Blue dot tooltip for Issue boards and Service desk to Blue dot tooltip for Issue boards

changed the description

@ClemMakesApps : I've updated the description here. Let's limit the scope of this one to just boards. And then adding service desk in https://gitlab.com/gitlab-org/gitlab-ee/issues/3212.

So I guess this can be a CE issue technically. But that might get confusing. Feel free to move to CE if you want.

Yeah, I'll move it to CE.

Also, I'm not certain if this is too picky of a scenario, but I figured I'd just mention it. Should we be showing the feature highlight when nobody is logged in? I currently have it displaying regardless of whether a user is authenticated or not @victorwu @dimitrieh

@ClemMakesApps : I think that's totally fine.

I love the graphics on this @hazelyang!

removed EE Premium label

removed milestone

mentioned in commit gitlab-design@df8d3255

Blue dot tooltip for Issue boards

Resources

Description

Proposal

Design

Design

Designs

Child items ...

Activity

Admin message

Admin message

Blue dot tooltip for Issue boards

Resources

Description

Proposal

Design

Design

Relates to

Activity