Gutenberg mobile editor: Misaligned Header items

[StefanNieuwenhuis]

The Header in the Gutenberg Editor on Mobile Web doesn't contain sufficient screen estate to align the items nicely.

Steps to reproduce

1. Switch to a mobile viewport (I used Moto G4). Here's a guide on how to do it w/ Chrome Dev Tools.
2. Go to https://wordpress.com/home/<somesiteid>.wordpress.com
3. From the main menu, select Appearance > Themes
4. Activate a different theme and proceed to edit the homepage
5. The items in the header aren't aligned.

Here's a video where the behavior is being reproduced https://www.loom.com/share/6f6eecb26818454891daaaf3753ca3b6.

You can also go straight to https://wordpress.com/page/<somesiteid>.wordpress.com/home to reproduce the behavior.

Notes

Related to #48337 and #47386. See #47386 (comment)

Hint: to prevent the DOM manipulation that adds the Launch button and modifies the Save button, we can do an early return, on smaller screens: https://github.com/Automattic/wp-calypso/blob/trunk/apps/editing-toolkit/editing-toolkit-plugin/editor-site-launch/src/launch-button/index.ts#L24

[deBhal]

This looks to be about having the cutoffs wrong/too small for the adaptive elements in our UI, leading to the elements wrapping around at screen sizes close to the transition points.

The problem is exacerbated by more/longer elements in the bar, for example while auto-saving for a jetpack site, the bar will wrap even at 820 pixel screen-width:

So there are a couple of different fixes to consider:

• decrease the threshold for reducing elements. This is the most obvious fix for the 782px and 600px thresholds, but won't actually address the Moto G4, as that is already using the smallest set of elements.
• add new even smaller UI option, reducing the footprint of one or more of elements in the smallest @media case or reducing the minimum whitespace between elements or switching to a more vertical style.
• stop the bar from wrapping (i.e. change the failure state).

I'm leaning towards making the edit-post-header more responsive, preventing wrapping and allowing more whitespace to be removed as it shrinks.

[simison]

I think for now we should just hide the button on mobile. It's still available in the customer home page.

@razvanpapadopol @ollierozdarz thoughts? What would be a good alternative placement for this in mobile screens, if any?

[deBhal]

@simison : Which button do you mean? The autosaving? That does seem a good target to improve things, but we'll need a lot more.

It's even worse in other languages - check out german, which still doesn't have enough space at 1010px width:

Contrast that with Chinese, which could show every element at half that size:

[ollierozdarz]

I think for now we should just hide the button on mobile. It's still available in the customer home page.

@simison are you talking about the Launch button on mobile? That seems like only element there that could possibly be removed/hidden without affecting the core functionality of the toolbar (saving/previewing/publishing) - although I'd hate to see launch rates decline because of it.

The difficult thing is that I believe we stack plugins in the toolbar (i.e. Jetpack), so this will become an issue as more plugins are installed regardless?

Have we ever tested using icons for things like 'preview' on mobile? We could always introduce another 'bar', but that would be three bars stacked and take up a lot of the real estate.

[simison]

@ollierozdarz yeah, I meant Launch button on mobile can be hidden because it's still better than the broken header. If there's an alternative that we can implement after hiding, great! :-)

The difficult thing is that I believe we stack plugins in the toolbar (i.e. Jetpack), so this will become an issue as more plugins are installed regardless?

There was a core issue previously (that got since fixed) where plugins would get stacked even when there wasn't space, but they're since getting hidden in the three dots menu.

@alshakero @roo2 let's hide the launch button for now as a fix.

[creativecoder]

Note that this is a problem at various screen sizes, not just mobile:

< 382px

600-728px

782-824px

And as pointed out above, it varies by language and can happen an larger screen sizes with added buttons (autosave) and/or plugin menus.

---

Here's a draft PR that hides the Launch button for small screens, but it doesn't help with screen widths above 480px.

Selectively hiding/showing the button based on screen width across a large range of sizes seems error prone and not maintainable... I think we're going to need some other (smarter) collapsing behavior, but I'm not sure what, yet.

[kwight]

This is a visual problem that, while pretty ugly, doesn't affect a user's ability to use anything here. Dropping this to normal priority.

[razvanpapadopol]

Once the Launch button is removed from the editor header, can we retest this issue in all the cases (page, post, draft, etc)?

Check out a couple examples of a published page:

• Mobile landscape (640px)

• Some viewport 601px wide