Toolbar

[wordpress-mobile]

Toolbar

[koke]

@marecar3 thanks, I think that's all I need for now.

@hypest let's wait to hear from Thomas, but I think the collapsable buttons could wait for the beta?

[SergioEstevao]

I started to look at this task and at the moment I'm planning to break this on the following tasks:

• Make the format bar code (format-toolbar) compatible with React Native
• Implement Buttons with text only
• Implement Buttons using an image and or SVG
• Link Button/Toolbar actions to Aztec RN
• Pin the toolbar to the bottom of the screen, on top of the virtual keyboard

[hypest]

👋 @marecar3 , good point. Let's update and close the one in the Gutenberg repo and update and work off this one here only. WDYT?

[hypest]

Feel free to @marecar3 , sure! Thanks!

[koke]

@iamthomasbishop can you update this issue with a better mockup of the toolbar? The one I could find had a black background that I had to remove but it looks odd. Also, can you confirm that the requirements I added for the UI in the description are accurate?

[koke]

Thanks, updated the description with those 😄

[marecar3]

@koke Updated. Keyboard toggle is now included in the existing estimation.
Please, let me know if there should be more adjustments to the estimation list.

[marecar3]

Hey @koke, I have added one more section in the estimation. It's Toolbar Style as toolbar buttons and toolbar itself doesn't implement the latest style provided by @iamthomasbishop.

[koke]

@marecar3 I moved the task list to the issue description, please make sure to do any new updates there so it shows on the issue summary:

[hypest]

Heads up, I went ahead and updated your list #55 (comment) @SergioEstevao to reflect current status

[marecar3]

Hey, @hypest @koke is this one WordPress/gutenberg#8989 redundant?

[marecar3]

@hypest should I take on me updating and closing that one?

[iamthomasbishop]

Here's the current iteration for the toolbar:

Documentation sounds right, other than this part:

When the keyboard is visible, the toolbar has a button at the end to

Should that be "When the keyboard is visible, the toolbar should show a button that allows to toggle/hide the keyboard."?

[marecar3]

Hey @koke, @iamthomasbishop,

Currently, we are presenting header toolbar (marked with blue color on the attached screenshot) in the Gutenberg app. Should we remove it from the UI and do we have some future plans for it? Thans.

[marecar3]

Slot/Fill pattern with Toolbar

Estimation : 1 week

• Fix : is block focused logic on Android platform
• Implement Slot/Fill "portal" pattern in gutenberg mobile
• Test Slot/Fill pattern with existing InlineToolbar
• Create Toolbar container with Format Toolbar Slot and Heading Toolbar Slot on top of the screen
• Test Slot/Fill pattern with Format Toolbar Slot and existing Format Toolbar

Context (Consumer, Provider) pattern with Toolbar

Estimation : 3 days

• Provide isSelected logic to Toolbar level

Toolbar Style

Estimation : 2 days

• Implement toolbar button style by specs
• Implement toolbar style by specs

Keyboard with Toolbar

Estimation : 4 days

• Move Toolbar to the bottom of the screen and make it keyboard sticky
• Create Keyboard control with the corresponding Slot
• Implement keyboard toggle functionality

Tests

Estimation : 3 days

• Make proper tests

Subtasks

• Create Inserter control with corresponding Slot
• Create Undo/Redo Toolbar controls with corresponding Slot
• Create Block type control with corresponding Slot
• Create Alignment control with corresonding Slot

[marecar3]

Hey @koke,

I have made a list above. However, I didn't find a task for Create Block type control with the corresponding Slot and Create Keyboard control with the corresponding Slot. I can make those if you want?

[iamthomasbishop]

Regarding your earlier question:

Currently, we are presenting header toolbar (marked with blue color on the attached screenshot) in the Gutenberg app. Should we remove it from the UI and do we have some future plans for it?

The intention is to show these controls in the Quick Toolbar, which would be attached to the bottom edge or above the keyboard. Using the Heading block as an example, it would look something like this:

• Inserter
• undo/redo
• block type (block type icon w/ dropdown for transform)
• block variation (h1, h2, etc)
• primary block controls (alignment, bold/italic, etc)
• keyboard toggle

The only controls that will be attached – visually – to the block itself are the inline tools (up/down, settings aka inspector, and •••. That looks like this:

[koke]

@iamthomasbishop for the dropdown buttons (heading, text alignment) I didn't see how they would look in the designs. I'm assuming something like this (from Ulysses), showing options in the keyboard area?

[koke]

@marecar3 thanks! There's no need to create issues for those yet, we can account for them as part of this issue.

• Create Block type control: we're not doing this as part of the alpha, and maybe not even the beta, so no need to account for this one yet
• Keyboard toggle: is this one included in the existing estimations?

[hypest]

The design calls for a condensed button for the headings, for example. Like, just use a single toolbar button with a dropdown to change the heading size. I'd say that is should be fine to do that in more than one steps: in step one, just put the 3 heading buttons in the toolbar. Step two: condense them to one. I expect the second step to be non-trivial. cc @marecar3

[koke]

Thanks, good catch

[iamthomasbishop]

@koke to answer your question above – I haven't provided a dropdown component design yet because I assumed (maybe wrongly) that we wouldn't implement this for a while. It sounds like that is the case, but I will start preparing some mockups for this.

Fwiw, my first thought was that for a quick i1, we could use something along the lines of either bottom sheets, action sheets, or popovers (aka menus). I will explore this further.

[koke]

I imagined something like that, although another approach to considering is expanding the options in place inside the toolbar, a sort of horizontal accordion

[iamthomasbishop]

That too was on the list of considerations, but I'd like to see if we can find an existing pattern or component to utilize. I thought about doing something like this, but I'm not sure I like this approach over the others mentioned previously.

[marecar3]

Thanks, @koke, I will do that.