EUI titling

[snide]

@elastic/eui-design

There's been feedback on how we handle titling in EUI, so here's an issue to get some slants in.

Currently how it exists (as provided originally from Marketing)

• There are three sizes (32,24,16). They are always true black (#000), which sets them off a bit from our text color which is a tad lighter.
• Roboto Light (300) is used in all cases (this was at the request of @Adrian-J and is followed on elast.co).
• App titles are always present, and live outside of page panels and are 32px.
• Page titles live within the panels, and are 24px.

Typical complaints

• The smallest title is the same as base font size, making it barely a title.
• People subjectively don't like the light font weight.
• Because the 16px small title doesn't work as a sub page head, people tend to reuse the page head sizing (24px) multiple times, not providing enough hierarchy definition.
• App titles might not be necessary. We show it in breadcrumbs...etc.
• Page titles aren't defined enough, it feels "floaty".
• Horizontal rules can be added if needed.

Example of current implementation

Other ways it's been handled in various forms

Design requirements

• App titles could be optional, but it would need to be replaced with a better signifier of what app you are in other than our current breadcrumbs.
• Titles need to read top to bottom, left to right.
• Our titling needs to work everywhere. We don't change how we do titling app by app. You can't not show the app title in one place, but show it in another. If titles need to live outside panels to show hierarchy or app level buttoning, then that's something we need to be consistent with everywhere.

[cjcenizal]

I found that bumping the Title font-weight to regular did the trick in terms of increasing the titles' readability.

[formgeist]

Here's a few comments about the styling;

There are three sizes (32,24,16)

I think the sizes work nicely, especially as proposed for App titles always to be present in the largest size.

They are always true black (#000), which sets them off a bit from our text color which is a tad lighter.

IMO #000000 never works great on screen on white/light background. I would like to propose to use #404040 (from the K7 palette) instead. Or to be even more radical, change/add our black to not be full black.

Roboto Light (300) is used in all cases (this was at the request of @Adrian-J and is followed on elast.co).

I like CJ's proposal to change it to regular (400) instead of using the light (300).

Just putting it out there, I'm not entirely convinced that Roboto is the right font-family to go with. It also doesn't seem to be on brand, where we're using Open Sans on elastic.co.

A radical suggestion would be to do like i.e. Github and default to the user's system/OS, so on Mac it's SF and on Windows it's Segoe UI. I think the only problem becomes using Ubuntu on Ubuntu, which strays quite a way from the other two, but we can still use a default fallback without having to load in/add a font-family to the dependencies. All families have a monospaced variant, which we need for code examples. Just a thought 🙂

[gjones]

I've been playing around with the size 32 title being 400 weight, in my opinion, if we do that then #000 is a little intense, I like @formgeist's suggestion on #404040.

[Michalwo]

#404040 is very close to #3f3f3f which is or was in the Kibana palette.
Also, do we use #444444 anywhere?

[snide]

This is our gray pallette. The values can be changed, but you can't ADD values. I'm going to be really strict on this. Every new color we add has a large cost to theming / complexity.

$euiColorEmptyShade: #FFF !default;
$euiColorLightestShade: #F5F5F5 !default;
$euiColorLightShade: #D9D9D9 !default;
$euiColorMediumShade: #999 !default;
$euiColorDarkShade: #666 !default;
$euiColorDarkestShade: #3F3F3F !default;
$euiColorFullShade: #000 !default;

[snide]

I've thought about using a slight background on page titles to call them out a bit more. No border, just a slight shade. You could only have one of these per "panel"

[formgeist]

Re: the shade of grey #404040, I'm not sure from which palette I got that from, because it's clearly #3f3f3f in the K7 palette 🤔 Anyways, my suggestion still stands to make the text not use full black #000, but use a darker shade.

@snide Re: a background shade for the titles, I'm not too keen on the look and feel. To me suddenly there's too many "bands" of shades in the page layout with the header, background, panel etc. I feel like without it it's more clean and subtle, more focus on the content.

[formgeist]

@snide Did you delete the comment about switching the font family to SF?

[snide]

Hmm. Must have. But yes, I'm OK with going with system fonts personally. San Francisco and Roboto are so similar it's barely noticeable. As we're more of a "tool" than anything, I think it makes sense to adapt to the OS.

Where I differ is I tend to side with @Adrian-J on the font-weights. I think thick weights on large fonts tends to look pretty heavy and overbearing. I do however thing we need a better 3rd level heading (possibly bumping up to 18px rather than 16px).

Where I like "bolding" works well is on anything 16px or below.

How I could see that working as a whole then...

h1 / 32px / 300
h2 / 24px / 300
h3 / 18px / 300
h4 / 16px / 500
p / 12-16px / 400

Bolded titles

To me this is just too heavy.

[formgeist]

The above example is definitely too heavy, but is that 400 or 500/600? I would love to see it all with system-ui perhaps in a branch to test it out.

[Adrian-J]

There's a good reason why we use light font for titles. Most pages in Kibana don't need a very prominent title, when you add big font, dark color and regular or bold weight it overpowers the entire page. My assumption is that people know what they clicked and we don't need a title that will stand out as much.

I really like this example: https://user-images.githubusercontent.com/324519/32515203-427c38d4-c3b4-11e7-940c-07928f6f71f8.png

I dislike this one: https://user-images.githubusercontent.com/324519/32523539-91895c88-c3d0-11e7-8508-8f01a4138b5f.png

Not a fan of this one either: https://user-images.githubusercontent.com/324519/32455823-4bd420ae-c2d8-11e7-8ba4-977ef2e2df8b.png

[cjcenizal]

To be honest, 300 weight is hard for me to read. I have an unusually large amount of floaters in my eyes which creates a lot of visual noise in my sight. The light weight reduces each letter to a series of a lines (I'm exaggerating a bit but I'm trying to explain my difficulty), making me have to focus just a bit harder to read titles at that weight. When the weight is 400, suddenly letters look like letters again and I'm able to read the title easily. It's much easier on my eyes.

[Adrian-J]

@cjcenizal I'm fine with switching to 400, but we'd need to make some changes. Smaller font, potentially changing it from black to grey. We'd probably have to get away from the 16/24/32 rule and use 26-28pt for titles.

[cjcenizal]

Thanks for the empathy, @Adrian-J. I don't really have any opinion on sizes, I think they're all equally easy for me to read.

[snide]

Tomorrow I'll set aside some time to demo some of our options during the meeting. I'll also walk everyone through how to make adjustments yourself (it's like 3 lines of code) so you can play around on your own.

[formgeist]

I've created an issue around the choice of fonts, suggesting to switch to system fonts, in #124 - just felt it was a separate conversation, not only related to titling.

[cjcenizal]

Re: removing the H1 title from some pages, like for the Watches page, I think the breadcrumbs provide sufficient context:

[formgeist]

@cjcenizal I'm opposed to removing the Page title. I think we should commit to have it in there always, it's gives a clear statement to the hierarchy of the page and its content. I don't think the breadcrumb is enough cue IMO. Having the title also gives a nice big title to the entire area with the subnavigation on the left having a clear parent.

Another question; what does it show when I click "Management" in the breadcrumb? Is it Elasticsearch > Data sources?

[cjcenizal]

Thanks @formgeist, I 100% agree with the principle of a universally present and universally styled title. I think breadcrumbs-only are certainly less than ideal. Given how varied our apps are in Kibana and X-Pack (and considering third-party plugin developers will be building who-knows-what), I just think we may find the need to compromise this ideal and support a variety of layouts with titles in different places and the only reliable source of context I can think of would be the breadcrumbs... but we'll see. 😄

what does it show when I click "Management" in the breadcrumb? Is it Elasticsearch > Data sources?

Yes, I imagine it would open the first available section by default. If we changed the order so that Kibana was first, then I think it would be Kibana > Index patterns.

[snide]

I played a bit with adjusting some of the whitespace between the layout elements and titles while chatting with @gjones to try and get back some of the lost space.

In general, I think we should always have titling above the panels whenever we use a sidenav. Remember that a very large problem we have in current Kibana is that very often we're using breadcrumbs alone for titling. Think through the below example with a discover page. If we removed the title here, the title in the breadcrumb would be the last (not the first) item of the breadcrumb.

While I do agree it can sometimes be considered wasteful of space, I'd rather be wasteful of space then confuse context. Pages within Discover and dashboard need this kind of hierarchy, because their side navs start becoming menus for inner content, and not just apps.

I view navigation as a top to bottom, left to right affair.

Clicking something up top tells me anything below may change. Clicking something on the left tells me anything on the right can change. What I don't like about skipping headers when side navs exist is that there's no context for what the side nav represents.

When it's there it relates the navigation to the content. This is a menu for management. This is a menu for this specific saved search ...etc.

It also consistently gives engineers space for actions that are top level against the title. Sometimes sections won't have that (like management) and that's OK. Others will. I don't want to get too hung up on one page not looking as good because it doesn't need the layout elements the other pages do. What's important is that EVERY page is flexible enough to add them should the need arise and there's a clear pattern to follow.

[cjcenizal]

Thanks for the insightful and well-reasoned explanation @snide! Sounds good to me.

[Michalwo]

@snide Thanks for the thorough explanation. Sounds good to me too.