Gutenberg: Mobile UI for moving blocks, switching type, and formatting

[designsimply]

Steps to reproduce:

1. Go to https://wordpress.github.io/gutenberg/ using an Android device.
2. Tap on a content block to select it.
3. Try to move the block to a new location.

Result: the options to move a block seem to be hidden off-left. (14s) I expected to be able to drag and drop the content blocks from an edit mode of some sort, as https://github.com/WordPress/gutenberg/issues/38 suggests.

Tested with Chrome on a Pixel with Android 7.1.1.

[jasmussen]

Mobile is very important to the editor project, but hasn't been a focus quite yet. No reason that can't change. Here's a very early draft for how the block and inline level formatting controls, as well as the type switcher and block move controls could work on mobile:

[jasmussen]

I took the liberty of renaming the ticket, to make it our canonical "consider mobile UI" ticket.

Mockup:

Edit: Updated to show the latest mockup.

[diegoliv]

@jasmussen great prototypes! I think that the first one is better, for two main reasons:

1. The first one takes less screen space than the second one, so you can see more of your content and less UI. This is critical on mobile.

2. When you have the controls at the bottom of the screen on mobile, the user is more confortable to do everything with one hand. Take a look at this article about bottom "navigation" (https://uxplanet.org/perfect-bottom-navigation-for-mobile-app-effabbb98c0f) and this one about how users hold mobile devices (http://www.uxmatters.com/mt/archives/2013/02/how-do-users-really-hold-mobile-devices.php).

By the way, keeping the formatting options "attached" to the keyboard feels more intuitive.

[jasmussen]

Great thoughts @diegoliv. I do completely agree with having navigation bottom-side when possible, which is why that was my first instinct also. However @afraithe reminded me that it isn't actually possible to know when the soft-keyboard is open on mobile, and so we can't actually calculate where to place the bottom toolbar. To put it differently, if we added position: fixed; bottom: 0; to the toolbar, it would be covered by the keyboard when that popped up.

If we were building an app it would be a different thing of course :D

If new developments have happened in the mobile CSS space, would be cool to revisit this, but I think sadly we're stuck with a top-bound toolbar for now.

[hypest]

Hey @jasmussen, thx for the mobile mocks! May I ask, do I read it correctly that the block/inline formatting options only appear when text is already selected?

[jasmussen]

May I ask, do I read it correctly that the block/inline formatting options only appear when text is already selected?

Something to explore when we get to this point, probably. Alternatively they could be grayed out.

[nheagy]

@jasmussen This looks great!

However @afraithe reminded me that it isn't actually possible to know when the soft-keyboard is open on mobile, and so we can't actually calculate where to place the bottom toolbar

I'd love to make sure this is (still) true. Seems the problem is iOS Safari wasn't always adjusting the viewport correctly. I'd love to find out if that's been fixed… maybe I'll make an attempt at it.

[jasmussen]

I'd love to find out if that's been fixed… maybe I'll make an attempt at it.

😍 There's a 🌟 emoji in it for you!

[sirbrillig]

However @afraithe reminded me that it isn't actually possible to know when the soft-keyboard is open on mobile, and so we can't actually calculate where to place the bottom toolbar

@nheagy the last time I worked on this, the first challenge was that Android Chrome and Mobile Safari behave differently:

• On Android, when the keyboard slides up it collapses the viewport height to the remaining available screen height, which actually is helpful because a fixed-bottom element will appear just above the keyboard.
• On iOS, when the keyboard slides up it covers the viewport, meaning that in order to position an element above the keyboard, it must be absolutely positioned at the right place on the page. This means that it is necessary to determine the height of the keyboard. Since iOS now supports different keyboards, and the native above-keyboard tools may or may not be present, this is quite a lot of guess work (there are some hacks which make it possible but they are not pretty and could break at any time).

Secondly, as Joen said, it's quite hard to determine if the device has the keyboard shown at all. There are also cases when the keyboard is "shown" but it is not actually visible, such as when an external bluetooth keyboard is being used.

All of which is to say that I think it's still a good idea in the current state of the web to use top-fixed elements whenever possible.

[shaunandrews]

Made a few GIF's walking through typing and adding a new block on mobile:

[anna-harrison]

A summary of where TinyMCE is headed with mobile capability (and what we learned from making Textbox.io, a fully accessible, professional quality text editor for mobile)

[jasmussen]

Closing this in favor of individual tickets: https://github.com/WordPress/gutenberg/labels/%5BComponent%5D%20Mobile