Add a sidebar toggle into the toolbar and close button into sidebar

[JeffersonBledsoe]

This PR adds a settings icon into the toolbar to open and close the sidebar, and a 'Close' icon in the sidebar to make it clear that it can be hidden and how. The current handle at the edge of the settings draw isn't particularly clear and gets missed or be difficult to press by some users, particularly on mobile where screens are smaller and may have curved glass preventing clicks. This change is very similar to the Quanta design.

Todo:

• Replace 'close' icon with 'tab.svg'
• Discuss removing the existing toggle to show/ hide it due to it's various issues (will break user workflow though)
• The button is being re-rendered by the Pluggable, causing the screen-reader to not output things correctly because the DOM node is being recreated
• Move it to behind an experimental feature toggle
• The sidebar should always start closed

Closes #3910

[netlify]

✅ Deploy Preview for volto ready!

Name	Link
🔨 Latest commit	bf2b582
🔍 Latest deploy log	https://app.netlify.com/sites/volto/deploys/639c683a320b8200084854e0
😎 Deploy Preview	https://deploy-preview-3912--volto.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[cypress]

3 failed tests on run #7235 ↗︎

3

456

20

0

0

Details:

Merge branch 'master' into settings-icon-in-toolbar
Project: Volto	Commit: bf2b582bf0
Status: Failed	Duration: 07:09 💡
Started: Jul 26, 2024 1:58 AM	Ended: Jul 26, 2024 2:05 AM

  core/blocks/blocks-image.js • 1 failed test • Core Blocks 14.x

View Output Video

Test		Artifacts
Blocks Tests > Add image block		Screenshots Video

  core/blocks/blocks-image.js • 1 failed test • Core Blocks 16.x

View Output Video

Test		Artifacts
Blocks Tests > Add image block		Screenshots Video

  minimal/blocks-image.js • 1 failed test • Project Generator

View Output Video

Test		Artifacts
Blocks Tests > Add image block		Screenshots Video

Review all test suite changes for PR #3912 ↗︎

[JeffersonBledsoe]

@tiberiuichim I'm running into Pluggable problems again. I need the plug dependency so that the component is correctly re-rendered when the sidebar is opened/ closed, but it seems that this causes the pluggable to re-order the plugs and so the button gets moved to above the undo/ redo. Is it possible to force the Plug to be in a certain position, or is this entirely up to the Pluggable?

[tiberiuichim]

@JeffersonBledsoe you can pass an order to the Plug

[netlify]

✅ Deploy Preview for plone-components canceled.

Name	Link
🔨 Latest commit	286677b
🔍 Latest deploy log	https://app.netlify.com/sites/plone-components/deploys/67209b7c790c220008d6a63f

[djay]

I think the only difference to the quanta design is in quanta this how you open the page settings only since the blocks vs page tabs are gone.
To make it closer you could make this button switch to the page settings

[djay]

I think I was wrong before when I said the toolbar settings icon should open the page settings only. The quanta design is a bit hard to work out the intention.

Throughout the design in figma the toolbar settings is highlighted when the block settings or the page settings is open. So I think @albertcasado did mean for it relate to the sidebar in general rather than the page settings only.

I really like the design with no tabs. It's cleaner and more mobile friendly saving space.

But with no tabs, what action shows the page settings when a block settings are shown?

The ways I can think of that are consistent with the figma design are

1. clicking the toolbar settings toggles between block and page settings rather than open/close. Close icon on either settings is the only way to hide the sidebar.
   • if the sidebar is closed then the toolbar settings should open the sidebar and switch to page settings.
   • your aria label is going to have to switch between "open page settings", "switch to block settings", "switch to page settings"?
2. OR clicking the toolbar settings always opens page settings and never toggles. but also happens to indicate if the sidebar is open as well?
3. OR - The toolbar settings is a toggle to open/close the sidebar and you have to do something like unselect a block to show the page settings?

but how these all work in with ARIA I'm not sure.
Of those options I think 1 is the more logical choice and it's not incompatible with keeping the tabs for now and it's not incompatible with clicking off a block to switch to page settings either.

EDIT: I think this design for the block/page settings resolves things nicely - collective/volto-hydra#152. the toolbar settings button is a simple toggle for displaying the sidebar and there is an obvious way to get to the page settings even if a block is selected and without the tabs or layout. But the settings button would work the same keeping the tabs and layout so they can be treated seperate.

[JeffersonBledsoe]

CC @Wagner3UB I know you're working on some sidebar stuff so just thought you might want to take a look over this incase it changes your work

[Wagner3UB]

@JeffersonBledsoe I have some personal opinions about this new behavior:

• First of all, I don't agree with the "always start close" behavior. We are entering the edit section of the site, and I expected to see some "tools" to change and customize things, which is a well-known behavior and has always been there. Why do I need to take another action to do something that was already available? In my opinion, we shouldn't "clean up" this view but rather show how it works right away. Adding another step creates the feeling that we're not fully inside the "edit page" yet.

• I'm not a fan of placing the action button on the left toolbar. I would suggest that a labeled icon attached to the right sidebar would work better. When clicked, the icon disappears, and by clicking the "X" inside the sidebar, the icon reappears. However, I am aware that this could create some accessibility issues, such as "how do I navigate there using the keyboard?"

It will be something similar to this:

[JeffersonBledsoe]

@Wagner3UB Agreed on both points! I think there is some differing opinion on these still though across the community. As this is behind a feature flag to start with, what do you think about having configuration options for both of the points you raised? E.g:

config.experimental.sidebarButton = {
  position: 'toolbar' // Could also be 'floating'
  defaultOpenState: 'open' // Could also be 'closed'

[djay]

I think open by default and having some new floating settings button can be added later if people really find they need it.
One of the main motivations behind this change is that it's currently unusable on mobile.
You can't have the sidebar open by default on mobile and you really don't want a floating element blocking editing on mobile either.
These are how quanta looks on mobile. The settings button makes sense in toolbar on mobile. yes you can have different things on mobile and desktop but also we can just make desktop more similar to mobile and have the sidebar open next to the toolbar on the left if this is really a problem.

I personally don't think it's going to be a problem in practice to have a button that looks like a settings button result in opening the settings even if where it opens is further away. It's still obvious. and it's way more obvious than whats there now.
As for opening it by default I think the same holds. It's still obvious this gets you to the settings.
But it might be a good idea to have the sidebar open to the state it was on the last edit. ie set a cookie. but again this can be added later if it really is needed

[JeffersonBledsoe]

This PR now MOSTLY is feature-flag only. It does refactor the sidebar to be controlled by a reducer now rather than it controlling itself, however this should make it easier to control other ways in the future should we need it (e.g. open/ close via the keyboard) I've introduced the following feature flags:

    sidebarCloseButton: false,
    sidebarToggleButton: {
      position: false, // Can also be 'toolbar' or 'floating'
    },

The sidebarCloseButton flag has been introduced so integrators can experiment with improving the mobile experience without introducing the open/ close toggle button as it was discussed at the Salamina sprint that the close button could be a useful feature on it's own.
The sidebar toggle button has been moved behind theconfig.experimental.sidebarToggleButton?.position flag. The This currently only supports 'toolbar' as shown in this PR, however the designers and developers I talked to at the sprint mostly preferred having a button next to the sidebar as they felt it was more logical that the thing it was next to was the thing it controlled.