Determine ideal field order and visibility for "quick edit" blocks in off canvas tray

I think we definitely need to put some thought into (a) what is exposed and (b) how it is organized/ordered/etc. Couple of specific things I noticed related to this while testing the patch:

Also, the problem of what is shown vs. not also exposes some existing usability bugs in core, where I want to change things but cannot for reasons that are obscure from an end user perspective.

For Outside In, it would be great if we had a way to surface important messages like that into this interaction as well. But I am at a loss on how we would do so.

Sort of related, but probably its own scope: #2782891: The Page Title block's title behaves in a confusing way with Settings Tray and the Help block incorrectly has Settings Tray styling

Another specific issue: #2782927: Block description does not belong in Outside In sidebar; make it part of the sidebar title instead?.

I would suggest three (hopefully) simple changes to make this better

1. Change the template to re write the markup of fieldsets as summary/details elements
2. Add the jquery UI accordion classes to all summary/details elements so that only one is open at a time
3. Set all of the details to collapsed on first load

Even if we can't implement it exactly that way, whatever solution gets us to "everything is closed on load and all panels have accordion behavior" will do.

As far as order is concerned the form items that come first should always be the ones that relate to the 'content' of the block. The user understands 'content' as what is printed on the screen. In the case of the branding block, that's the logo, site name and site slogan. The order of these should match their order in the rendered html.

It would be nice to actually be able to pair each text field with it's corresponding toggle checkbox, but barring that we can at least put the 'toggle branding elements' fieldset immediately after site details.

As for the "advanced" link, if a details pane adds configuration from a form other than the block configuration form, it should have it's own advanced options link and that link should probably be labeled to refer to the form eg. 'Advanced menu options'

To the comment in #5, there are many things we could do with the menu form, but ideally we don't want to take users away from the page unless absolutely neccesary. "add link", and even "edit" on the links do that. Until we have a way to click and add or edit the link text in place I think we should remove them and have only "advanced menu options"

For clarity, I've reworded the description to propose what "done" will look like, using the standard template and some of @tkoleary's previous comments to try to flesh it out.

Please do edit the description if any of it doesn't make sense, or is contrary to the UX guidelines.

Changing to feature request since this is about optimizing the experience rather than fixing a usability bug. The module is usable in int's current state.

Ok. so starting a patch to address these issues.

. Rewrite block quickedit markup as summary/details, not fieldsets.

Now there are no fieldsets in the Settings Tray block forms. I think the only fieldset were Visibility Settings which are not being show in these forms.
The other items we are adding use details.

Add jQuery UI accordion classes to all those summary/details.

Do we actually have add classes for this. I think the accordion functionality is just built into our details field elements. We are getting accordion functionality now.

3. Set accordion state to collapsed on first load.

We are leaving some of the accordion state to open on some of the details because we explicitly adding elements we want to expose on the menu and branding blocks
so when you edit a Menu block you see the menu items automatically which is what you probably want to edit.
Also with Branding we are leaving site name and slogan details open because this is likely what the user wants to edit.

Re-order fields across potentially several different modules (at least within core, using weighting?) From #9: "the form items that come first should always be the ones that relate to the 'content' of the block. The user understands 'content' as what is printed on the screen."

This has been done. The menu and branding blocks are the only blocks currently where we are adding extra form elements that relate to "content" of the block.
The only form elements that are before this are for the label of the block.

Pair each text field with its toggle checkbox.

I am assuming this means for the Branding block? This has not been done.

Identify and remove any items in core that don't belong here, and implement functionality to add multiple "Advanced X options" links to take the user elsewhere instead.

In this patch I have added a "Advanced menu options" link to the menu block. I did not add it this link for the Branding block because usually this is edit on the "Basic site settings" but the other settings on the form really don't relate to anything on the Branding block. I also changed "Advanced Options" to "Advanced block options" so this is clearer.

The other block in core that I thought would make sense to add an advanced link to would be the "Search Block" to link to /admin/config/search. Right now we don't have an "SearchOffCanvasForm" class so it just uses the regular SearchBlock class. We could add SearchOffCanvasForm to add the advanced link but that seems like a lot of trouble.

What if we added a new property in the annotations for blocks, advance_link link this:

advanced_link = (
 *    route =  'entity.search_page.collection',
 *    title = @Translation('Advance search options')
 *   )

Then any block that simple needed to make a link to advanced options could add it here.
In this module we could alter the plugin definition of SearchBlock in outside_in_block_alter like are doing for forms. The move it to SearchBlock when the module is stable.

Ok this patch adds Off-Canvas form for the search block. This just adds a link to the search documentation page

It also changes the way the block label text field behaves.
In an effort simplify the forms it not does not display the field if field if "Display title" is not checked. This way if the title of the block is not currently being show when you open the off-canvas for you won't see the title of the first.

I think this helps a lot with blocks such as branding, menu, and tab where you are not likely to show the title. Then you can focus on the other options on the form such as the menu items.

ok would help if uploaded the patch

Needs re-roll because of #2862625: Rename offcanvas to two words in code and comments. and other recent commits

Re-rolled.

@Jo Fitzgerald thanks for the reroll! Looks good except a couple small things related to #2862625: Rename offcanvas to two words in code and comments. which was committed since my last patch in #19

1. +++ b/core/modules/outside_in/outside_in.module
   @@ -142,6 +143,10 @@ function outside_in_block_alter(&$definitions) {
   +    $definitions['search_form_block']['forms']['offcanvas'] = SearchBlockOffCanvasForm::class;
   

   'offcanvas' should be 'off_canvas'

2. +++ b/core/modules/outside_in/src/Form/OffCanvasPluginFormBase.php
   @@ -0,0 +1,47 @@
   + * Classes extending this most be registered as the 'offcanvas' form handler for
   

   'offcanvas' should be 'off_canvas'

I think I found all these but you can check and make sure "offcanvas"(all lower, no - or _ ) doesn't appear anywhere in the patch.

Also tagging with "Needs tests" because new functionality in this patch doesn't have tests and they is why there was fail from 2 problems mentioned here.

Changes made as per comment #23.

Setting state to "Needs work" for further testing of new functionality added in patch.

@Yogesh Pawar yep reroll look good. Thanks!

This issue still needs

1. Review of the basic functionality
2. Test for new functionality

Re-roll of #24 because of #2785135: Rename protected property SystemMenuOffCanvasForm::$entity to $menu

I have extracted out the title input portion of this patch to #2882729: In off-canvas block form hide Title input unless it will be displayed and change label to Block Title

Probably the other portions of the this patch should be grouped into other issues

Created follow up #2888567: Add links to relevant off-canvas block forms to blocks to link to related configuration

Marking as because all tasks in this issue are either in the module now or have their own issue.

see #2882729: In off-canvas block form hide Title input unless it will be displayed and change label to Block Title

Changing to new settings_tray.module component. @drpal thanks for script help!