This turns out to be an easy change to make, so I prepared patches in advance, to make it easier to discuss. Screenshots for comparison:

Overlay	Before	After
(none)
Talk
Editor
VisualEditor

(note that VisualEditor overlay already uses 3em)

Change 488478 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/skins/MinervaNeue@master] Change height of all page and overlay headers to 3em

https://gerrit.wikimedia.org/r/488478

Change 488479 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/MobileFrontend@master] Change height of all page and overlay headers to 3em

https://gerrit.wikimedia.org/r/488479

@alexhollender @Volker_E would love your thoughts on this

On skimming only, I agree with @matmarex proposal, we still meet our touch target requirements and unifying the headers is stronger than only reducing VE's toolbar (I started the other way round) as in T209015.
Seems good to go from my perspective!

@ovasileva: This is in Triaged but Future in our backlog but doesn't appear to have a priority.

@alexhollender please design review this when you have a change- it's live on https://reading-web-staging.wmflabs.org/wiki/Special:MobileOptions
I've given Bartosz permission to +2 once you've approved.

Risk of this change is high as it touches all pages. Right now our Overlay headers are tied to the header and I'm not confident changing the header height in one place would impact other headers. Changing the header height would also potentially mean changing the logo image in the header.

We're waiting on some design review from @alexhollender so we want to set the expectation that we need a bit more time on this change. Please ping if this is taking too long.

The most critical point here from my perspective is to make sure overlay height decrease (if we gonna go for a 48px based header) to normal branded header is well addressed.

This will be resolved with T211255

@alexhollender are you adjusting this on read and edit mode or just read mode?

In T215426#5171076, @JTannerWMF wrote:

This will be resolved with T211255

That task is isn't just for VE. This task is for all headers in MobileFrontend.

In T215426#5171082, @JTannerWMF wrote:

@alexhollender are you adjusting this on read and edit mode or just read mode?

My proposal would affect read mode and wikitext edit mode – visual edit mode already uses the proposed header height. See screenshots above: T215426#4931874.

In T215426#4969290, @Jdlrobson wrote:

We're waiting on some design review from @alexhollender so we want to set the expectation that we need a bit more time on this change. Please ping if this is taking too long.

Is there a timeline for this? The change in height is most noticeable when switching editors so we'd like to get it resolved.

Risk of this change is high as it touches all pages. Right now our Overlay headers are tied to the header and I'm not confident changing the header height in one place would impact other headers. Changing the header height would also potentially mean changing the logo image in the header.

Are there logos that are particularly taller than 'Wikipedia', because that logo looks fine at 3em:

The first thing to do is T195795: Use a clearly intended height on MinervaNeue header

Once that's resolved I will talk to Alex about this change and get everything we need.

Looking at this more closely, a 48px header looks small and therefore imbalanced to me.

From the description:

Current height is larger than necessary to support mobile interaction

There is an additional consideration of the visual balance of the page. The header is an anchor of sorts that establishes a certain rhythm for the layout. To illustrate, here is the header at 44px tall:

and instead (in case of fixed headers) takes too much screen space.

Good point. Whether or not we want a consistent height for all headers (including the main site header) seems like a good design question, cc @iamjessklein @RHo @Volker_E. One solution I've seen is for headers to get less tall when they become fixed.

In the editors (VE & MF editor) we have toolbars with full height buttons that have a minimum width of the click target size (48px). In this case if the toolbar was set to a taller height the tools would look vertically stretched, so making the editor toolbars taller does not seem like a good option either.

Personally I think the 48px is acceptable to solve our consistency problem with read mode, edit mode and OOUI dialogs.

I'd also take the Material Design guideline in this context with a grain of salt. In their example it includes the “Page title”. That would translate to the article title in my understanding. If we agree on putting content first, I think the header bar can be sufficient at 48px.

For reference:

current (53px)	proposed (48px)

It will also depend on device resolution, so what looks "thin" on a iPhone XS Max may not be so bad on an iPhone 5.

I agree with this proposal. It actually matches the design T211255 that I currently have for the mobile VE toolbar which looks like this:

Disabled View:

That said, I would maintain the larger size for desktop as this would look very slender in that setting.

I think the option @alexhollender proposes of going up to 56px from 53.6px is preferable to going down to 48px *for the main header*.
Mainly because that the wordmark does look cramped when there is this reduction in white space (perhaps more evident in languages with denser scripts like BNwiki or HEwiki).

48px	56px

It also seems less risky to increase the height slightly than decreasing it, in terms of ensuring the many existing different headers elements are not broken from the change.

I do also support the suggestion to reduce to 48px on scroll so that the point about consistency across toolbar heights in various modes is addressed, but keeping the taller 56px height for the main site header would be better for brand prominence and visual hierarchy.

I do also support the suggestion to reduce to 48px on scroll so that the point about consistency across toolbar heights in various modes is addressed, but keeping the taller 56px height for the main site header would be better for brand prominence and visual hierarchy.

I'm not sure I understand this proposal - the site brand toolbar is not fixed on mobile, so when you scroll it just goes off the page.

Another thing to keep in mind on iOS devices is that there is a shortcut built in to scroll to the top when a user taps on the status bar (https://developer.apple.com/documentation/uikit/uiscrollview/1619421-scrollstotop). Just something to keep in mind with tighter tap targets towards the top of the screen.

In T215426#5384484, @cmadeo wrote:

Another thing to keep in mind on iOS devices is that there is a shortcut built in to scroll to the top when a user taps on the status bar (https://developer.apple.com/documentation/uikit/uiscrollview/1619421-scrollstotop). Just something to keep in mind with tighter tap targets towards the top of the screen.

On iOS web the scroll to top is done by double tapping the collapse address bar, which we can't change the size. The main contention is around the reading toolbar which isn't visible when you are scrolled, so wouldn't interfere with this action.

@Esanders, Ah sorry to clarify this came up in a design review of the editing toolbar, where I could see this applying, likewise the '<back' status bar button when navigating to an app via search.

In T215426#5384376, @Esanders wrote:

I do also support the suggestion to reduce to 48px on scroll so that the point about consistency across toolbar heights in various modes is addressed, but keeping the taller 56px height for the main site header would be better for brand prominence and visual hierarchy.

I'm not sure I understand this proposal - the site brand toolbar is not fixed on mobile, so when you scroll it just goes off the page.

Oh soz, to clarify, I was agreeing with the idea to shrink it down to 48px size when fixed, which is in a future design iteration proposed in the AMC work.

Other consensuses reached/not reached in HotW:

• Fix all overlay headers to be 3em to match editing and simplify code, e.g. Talk overlay, Language overlay
• Leave grey site-header as 3.35em for now, in the absence of a consensus to shrink it.

The overlay fix, is it for the Editing team to fix or Readers Web @Esanders ?

Change 488478 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/skins/MinervaNeue@master] Change height of overlay headers to 3em, keep site header unchanged

https://gerrit.wikimedia.org/r/488478

Change 488479 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/MobileFrontend@master] Change height of overlay headers to 3em

https://gerrit.wikimedia.org/r/488479

I have updated my earlier patches to implement this.

Change 488478 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Change height of overlay headers to 3em, keep site header unchanged

https://gerrit.wikimedia.org/r/488478

Change 488479 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Change height of overlay headers to 3em

https://gerrit.wikimedia.org/r/488479

This appears to have caused a minor regression in the search overlay - the vertical padding is off. It looks like a padding-top: 3em needs updating

Before:

@Jdlrobson The height of that header has not changed, so I don't think that's because of these changes. It might be caused by the icon changes from T229440.

(Fixed in https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/535961)

I guess this is done, we just need to sign off?