Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mobile UI for moving blocks, switching type, and formatting #44

Closed
designsimply opened this issue Feb 9, 2017 · 12 comments
Closed

Mobile UI for moving blocks, switching type, and formatting #44

designsimply opened this issue Feb 9, 2017 · 12 comments
Labels
[Type] Question Questions about the design or development of the editor.

Comments

@designsimply
Copy link
Member

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 #38 suggests.

Tested with Chrome on a Pixel with Android 7.1.1.

@jasmussen
Copy link
Contributor

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:

mobile

@jasmussen jasmussen changed the title Cannot move blocks using Android 7.1.1 Mobile UI for moving blocks, switching type, and formatting Feb 14, 2017
@jasmussen
Copy link
Contributor

jasmussen commented Feb 14, 2017

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.

@jasmussen jasmussen added the [Type] Question Questions about the design or development of the editor. label Feb 14, 2017
@diegoliv
Copy link

@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
Copy link
Contributor

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
Copy link
Contributor

hypest commented Feb 15, 2017

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
Copy link
Contributor

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
Copy link

nheagy commented Feb 15, 2017

@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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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

gutenberg mobile typing

gutenberg mobile block adding

@anna-harrison
Copy link

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Question Questions about the design or development of the editor.
Projects
None yet
Development

No branches or pull requests

8 participants