Thanks for capturing this issue @Volker_E. As you indicated there are several strategies to make toolbars fit better in a restricted space. I tried to explore several options on how to both compact options when there is little room, as well as for options to expand them:

We may select a few of these strategies. Some may be applied automatically, and others can be applied based on the specifications of the creators of each toolbar. For example, marking a label as optional can result in the label being removed when there is little room for the toolbar.

VE Mobile is currently using context-sensitive toolbars, similar to Google Docs mobile, such that when the document is not focused you see navigation and document-level tools:

When the document is focused, you get editing tools, and also an extra 'done' tool that de-focuses the surface and returns to the document-level tools (this can also be achieved by hiding the keyboard, but many users won't think to use this tool):

Another trick GDocs mobile uses is an additional bottom toolbar - but last time we checked that wasn't possible to implement reliably across Android and iOS.

In T175953#3617522, @Esanders wrote:

VE Mobile is currently using context-sensitive toolbars, similar to Google Docs mobile, such that when the document is not focused you see navigation and document-level tools

Could we show a different context menu if text is selected? Is this useful/possible?

Example with expanded panel as scrollable grid

"temlplate" :)

In which direction is it scrollable ?

In T175953#3709889, @TheDJ wrote:

"temlplate" :)

Oops! Fixed.

In which direction is it scrollable ?

I did not think this through 😛

@Pginer-WMF What is the difference between the two Expand as panel menus in F9621720?

On scrollable with mobile: Please remember that nesting the same direction directly inside views is often a difficult touch UI interaction. So if you have a vertical scrolling page, you generally shouldn't put vertical scrolling elements in it, but horizontal scrolling. Nesting of scrolling in the same direction is generally bad (by default Android didn't even support it until recently I think).

In T175953#3729112, @TheDJ wrote:

On scrollable with mobile: Please remember that nesting the same direction directly inside views is often a difficult touch UI interaction. So if you have a vertical scrolling page, you generally shouldn't put vertical scrolling elements in it, but horizontal scrolling. Nesting of scrolling in the same direction is generally bad (by default Android didn't even support it until recently I think).

Interesting! Thanks for the tip

I am working on some prototypes for this, issues like this and others should surface once we can test these ideas.

In T175953#3709552, @Prtksxna wrote:

In T175953#3617522, @Esanders wrote:

VE Mobile is currently using context-sensitive toolbars, similar to Google Docs mobile, such that when the document is not focused you see navigation and document-level tools

Could we show a different context menu if text is selected? Is this useful/possible?

Yes, although you should note that most of our text tools are currently available on empty selections too (e.g. bold/italic will make what you type next bold, link will insert a new link with text equal to the link target). That said having them available on empty selections is probably not critical.

In T175953#3617522, @Esanders wrote:

Another trick GDocs mobile uses is an additional bottom toolbar - but last time we checked that wasn't possible to implement reliably across Android and iOS.

To clarify: I meant a bottom toolbar that is visible when the keyboard is open. When the keyboard is closed it is fairly easy to attach a bottom toolbar.

Also the last time we checked was probably over a year ago, and these APIs change quite frequently, so it might be worth looking into again.

In T175953#3728584, @Prtksxna wrote:

@Pginer-WMF What is the difference between the two Expand as panel menus in F9621720?

The difference was about keeping the options in context or as a separate dialog/panel/view. One approach keeps the context connected and the user in-place, while the other requires navigation but allows the separate view to make better use of space.

In T175953#3733559, @Esanders wrote:

In T175953#3617522, @Esanders wrote:

Another trick GDocs mobile uses is an additional bottom toolbar - but last time we checked that wasn't possible to implement reliably across Android and iOS.

To clarify: I meant a bottom toolbar that is visible when the keyboard is open. When the keyboard is closed it is fairly easy to attach a bottom toolbar.

Also the last time we checked was probably over a year ago, and these APIs change quite frequently, so it might be worth looking into again.

Being able to use the bottom area that the keyboard occupies when the user does not need to input text seems a good approach to keep the focus on content (the viewport is not moving, jumping or covered by other elements). So I think that could be a good approach to explore independently on the position of their main entry points. For example, the list of items to insert can be shown as a card at the bottom that replaces the keyboard, even if the toolbar with the action to insert is shown on top.

Having said that, the approach would benefit from having the controls at the bottom of the viewport, closer where the menus show. I did a test of bottom placement but unfortunatelly it worked only well on Android but not iOS. I hope that now it is possible to support and, in any case, it would be good to prototype to verify the idea is a good one for when it becomes technically possible.

In T175953#3737169, @Pginer-WMF wrote:

Having said that, the approach would benefit from having the controls at the bottom of the viewport, closer where the menus show. I did a test of bottom placement but unfortunatelly it worked only well on Android but not iOS. I hope that now it is possible to support and, in any case, it would be good to prototype to verify the idea is a good one for when it becomes technically possible.

Sadly it seems that, as Ed said, we cannot put things at the bottom of the viewport, because for browser security reasons we're not told whether or not the keyboard is shown:

Works without keyboard	Hidden with

I have been working on some prototypes to test the options we are coming up with. They are responsive, so do see them on both desktop and mobile to changes. Unfortunately, some of them will need to be refreshed if you just resized your window as they rely on JavaScript (and I am lazy).

Let us keep the discussion about the options here on Phabricator, but use Github issues to point out errors in the implementation of the ideas or if more prototypes need to be made.

In T175953#3737654, @Jdforrester-WMF wrote:

Sadly it seems that, as Ed said, we cannot put things at the bottom of the viewport, because for browser security reasons we're not told whether or not the keyboard is shown:

<aside>
I think in iOS the keyboard opens on top of the webpage, whereas in Android the keyboard forces the window to shrink (triggering a resize event too (T162127)). So while there is no API for keyboard visibility on either, at least on Android position:fixed;bottom:0; suffices.
</aside>

In T175953#3776737, @Prtksxna wrote:

I have been working on some prototypes to test the options we are coming up with.

I am sorry the prototypes weren't actually working when I posted that message. @Pginer-WMF pointed it out to me on Hangouts, and I have fixed it now. Sorry for the confusion.

We should go with the hardest use case as demo foundation – 320px.
Some of the prototypes seem not to be laid out for that.

In T175953#3822185, @Volker_E wrote:

We should go with the hardest use case as demo foundation – 320px.
Some of the prototypes seem not to be laid out for that.

Thanks for taking a look! Yes the prototypes might have issues. BTW - Did you refresh the page after coming to that size?

Could you please list the prototypes that were broken at 320 and would better communicate the concept if they weren't?