Introduce "outside in" quick edit pattern to core

The scope of #2753941: [Experimental] Create Outside In module MVP to provide block configuration in Off-Canvas tray and expand site edit mode did not get much sign-off or review. I am not sure what to review here, as there any many missing parts and the "bigger picture" on this one is a bit unclear - as it seems to closely align with the initial overlay scope. Given that this is the key part of "outside in" and the other parts are just making the entry points better - its worth doing a separate call or more hashed out design on that. We should go really MVP here, and for example only allow editing of plain blocks (not also change the way we place blocks, do a manual configuration split, etc.).

The other concepts look good to me, and happy to provide sign-off.

I've outlined my comments in the relevant issues. The larger picture is best captured by yoroy's comment in https://www.drupal.org/node/2729413#comment-11231709. The currently active "official" initiatives have a clear roadmap from 8.2 and 8.3, and sometimes onwards. Given that this part of several strategic initiatives (at least thats how it looked in the Driesnote) it would be good to know what the ideas are beyond this first push (are we expanding to more blocks?).

Considering our Lean UX thinking, what are we trying validate - what is our hypothesis? How can we validate it with this step? Does it accurately reflect the first step of a "outside-in" concept? What is needed for that?

It would be great if the relevant issue or this plan issue could outline in more detail:

• What blocks are to be editable/configurable inline overall, and just in 8.2?
• The screenshots provide a selection of configuration options for the site name blocks (e.g. you can toggle site name visibility but not edit the site name). I imagine this split is based on some principles and done manually?
  • We apply the rule (only visual changes shall be shown) - which I think is a great rule. But why do we then omit settings as site name, or visibility settings? (How are they different?)
  • Do we drop the more "content" type configuration? Such as editing the block/site name title?
  • What is our MVP? I thought it was plain "block config"? That doesn't quite align, with surfacing configuration on site names. If we do special case certain blocks, for validation - why don't we go with a block that will get us much more insights, like a menu?
• Do we still do the "reload" upon clicking advanced, wiping all earlier entered data? This seems like a must-fix.
• Do we still hide the save buttons until an action is made in the tray? (new pattern in core)

Most of these issues are already discussion in the relevant modal issue, they are under discusion and yet to be resolved - understandably so, these are tricky things. We don't have to solve all of them, but it's nice to understand the vision as our discussions so far have been unable to provide adequate answers.

What is our battle plan for making this work for all the "editable" parts of the front-end. That needs a somewhat clear follow-up, or we end up like Quick Edit currently where there it never graduated beyond nodes. Given the criticality for the outside-in concept is being all encompassing on the front-end, I would love to see some ideas/plans.

The place blocks as outlined in this post, is significantly different from the current state (opening in a modal vs. a tray). We don't have a "wizard" like flow yet in the tray design. This is also new, it wasn't in the earlier designs that I've seen (sorry, there have been a lot). Given that we omit the region selector, people are kinda stuck with where they place it - unless they know the Drupal "advanced" way. This seems like a rather arbitrary limitation that would unnecessarily hurt UX. Happy to also include this, but that is different from our current approach - and should either be reviewed or left out of scope. [@webhick you changed the picture from an animation to a pic without the place blocks part, does that mean its now out of scope?]

As mentioned before, most of the concepts are really close - only what is actually in the tray is a little unclear to me.

I really hope more people chime in :) We've been looking at this for months now.

Given that this part of several strategic initiatives (at least thats how it looked in the Driesnote) it would be good to know what the ideas are beyond this first push (are we expanding to more blocks?).

Considering our Lean UX thinking, what are we trying validate

What blocks are to be editable/configurable inline overall, and just in 8.2?

All blocks will be configurable in 8.2 but only the block instance (plugin) configuration.

The screenshots provide a selection of configuration options for the site name blocks (e.g. you can toggle site name visibility but not edit the site name). I imagine this split is based on some principles and done manually?

For the moment it is simply pulling in the additional block instance configuration options declared by the block, but not the visibility settings, in all cases.

We apply the rule (only visual changes shall be shown) - which I think is a great rule. But why do we then omit settings as site name, or visibility settings? (How are they different?)

Visibility settings are something that will require a good deal more discussion and design, mainly because when you bring them into the context of a page they potentially introduce dangerous leaky abstractions, how we handle all of that complexity is really more in the scope of blocks and layouts initiative than this issue.

Do we drop the more "content" type configuration? Such as editing the block/site name title?

I believe that going forward we should move in that direction, but for this initial version, we are focussing on simply providing the hooks to be able to get configuration on to the page.

What is our MVP? I thought it was plain "block config"? That doesn't quite align, with surfacing configuration on site names.

Site name has been removed from the MVP.

If we do special case certain blocks, for validation - why don't we go with a block that will get us much more insights, like a menu?

We are not special casing certain blocks just yet. That would be great, but we don't have the bandwidth to get that in in the next three weeks.

Do we still do the "reload" upon clicking advanced, wiping all earlier entered data? This seems like a must-fix.

We should approach this just as we do in quick-edit. If the form is dirty present a warning modal (in this case the "modal" can appear inline at the bottom of the tray)

Do we still hide the save buttons until an action is made in the tray? (new pattern in core)

No, Cheppers testing showed that users were confused by that so we took it out for the time being. My personal view is that the confusion arose because of the *position* of the buttons on the top bar, which has also been changed.

Incidentally the pattern of showing the save only on a dirty form is *not* new to core. It's the pattern we use in quick-edit.

@Bojhan

Additional answers.

What is our battle plan for making this work for all the "editable" parts of the front-end. ...I would love to see some ideas/plans.

This does give the user the ability to trigger editing of *anything* on the front end, since it provides editability for the configuration settings of every block. It does not give the user the ability to edit *all of the configuration* of every block. But the foothold of having the tray open up gives us a pathway to presenting more related configuration for that block.

In initial discussions with Ted Bowman and Tim Plunkett there are some tricky form API issues to navigate before we can bring those other types of configuration in, but that is more a technical than a UI issue.

As far as how the various configuration options coming from different forms present themselves in the tray, I have ideas, some of which you have already seen, but it's a design constraint that is going to take a lot of thinking from all of us and I'd love to see any design ideas you might have.

The place blocks as outlined in this post, is significantly different from the current state (opening in a modal vs. a tray). We don't have a "wizard" like flow yet in the tray design.

In this particular case there is no need for a "wizard flow" though we may need one in other cases where the user may want to "go back" to a previous step. Here the act of selecting a block temporarily "places" it on the page and switches to the configure form giving the user the opportunity to immediately preview and configure it. If the user clicks "cancel" in the configuration step, the block is removed, the tray reverts to the block list, and the user can try a different block.

There's no need for "save and continue" or "go back" here because, apart from selecting the block, there's no configuration the user has made that will be lost.

Given that we omit the region selector, people are kinda stuck with where they place it - unless they know the Drupal "advanced" way. This seems like a rather arbitrary limitation that would unnecessarily hurt UX.

I don't follow your logic here. All of the regions have drop zones, so the user can alway just change their mind, remove it and drop it elsewhere, which is a trivial action. There is an also issue to add the region selector to the block config form (which would be defaulted to the region they started from). Does that solve your problem?

As mentioned before, most of the concepts are really close - only what is actually in the tray is a little unclear to me.

I *think* Angies comment clarifies this but let me know if you have more questions.

I really hope more people chime in :) We've been looking at this for months now.

Agreed.

The title of this issue says 'preview-first', but I don't see anything about adding actual previewing in the issue summary - everything is about directly editing configuration on the live site from the front-end. That gives you a chance to see changes immediately, but it's the opposite of preview.

I have a few overall comments on the plan. The one high-level thing that really struck me while reviewing the experimental prototype was just how confusing Outside In vs. Quick Edit was. The summary has two contradictory points:

Then, if this functionality tests well once it's in the hands of more users, the eventual plan would be to replace the current Quick Edit module's functionality with this new project, and mark the old one as deprecated for BC.

That's down a ways in the summary. I think it should be in the proposed resolution. But then:

Re-designing Quick Edit for content entities

is listed as "Not in scope". That seems like mostly the same thing to me.

I actually think the end goal for the stable module needs to be to replace Quick Edit entirely. I see that there is #2781583: Reconcile the many forms of editing and configuring stuff (and address potentially redundant contextual links) but that is a much broader scope (and therefore more difficult to resolve) than the specific problem of Quick Edit vs. Outside In. Resolving that usability issue does not need to block the commit of the experimental module, but it was actually frustrating for me (even though I know how Quick Edit works!) so documenting it here. Others also commented about this on the prototype issue.

Overall, the design and behavior of Outside In is much more intuitive than Quick Edit currently is -- basically, it's what I've always thought Quick Edit should be like.

So, for me, one of the "Must have" issues would be:
"Make quick editing for content entities look and behave the same as Outside In"
and:
"Deprecate Quick Edit in favor of Outside In, and replace it in the Standard profile for new installs".

Also, in the same vein:

Because this proposed change doesn't make changes to the Quick Edit or Place Block module directly, I don't believe sign-off by those subsystem maintainers is required.

As above, while the Quick Edit maintainer's signoff is not required for an experimental prototype in #2753941: [Experimental] Create Outside In module MVP to provide block configuration in Off-Canvas tray and expand site edit mode, the signoff should be included for this overall plan if the plan does indeed include deprecating the original version of Quick Edit. So, I'm adding that to the summary.

I'm still processing many other specific points of review and will comment again later with what I think is missing from the roadmap; this specific point though seems like it would need more signoff than just mine.

Thanks for consolidating the known followups so far!

Also removed this from "Not in scope":

Per our new agile core development process, Information Architecture/Nomenclature and other changes to spec itself (until it's in, then open season again!)

(It's not in scope for the experimental prototype, but it should in scope for getting to a stable release, which is what this issue is for.)

@andrewmacpherson and @Wim Leers gave some feedback about accessibility that I'm not sure has been addressed in the initial prototype, so I am adding links to the summary here. That feedback should ideally have its own issues (as should any other comments from the prototype issue that were not incorporated). When we add experimental modules, we should clearly define what's out of scope for the first step by adding it to the later roadmap.

Related to #20. On #2782803: Rename Outside-in module to "Settings Tray" in the UI and in comments, @cilefen and @davidhernandez pointed out that the label "Outside In" is very much a Drupalism and does not describe what the module does. We can rescope that issue to be about what the name of the stable module should actually be (and not discuss it here), but David also pointed out that the module seems conceptually related to Quick Edit, Contextual Links, and Toolbar. @webchick also mentioned that she was unsure which component to file these issues against. In my ideal future, Contextual, Quick Edit, and Outside In would all be merged into a single component with a single, responsive, integrated user experience.

Adding a number of followup issues to the roadmap based on my assessment of their importance. (Someone from the initiative team should probably confirm the must vs. should for this and other forthcoming followups, but it is a start.)

After discussing with @webchick yesterday, I filed #2783509: Outside In's "Edit" toggle lets you do just about everything except edit your content for the usability problem described in #20, and am updating the summary to clarify WRT Quick Edit in general.

Also consolidating the two lists of signoffs. I think there may also be usability signoff already? If so let's update.

There is, consider it signed off. Lets get this in :)

Moving around some issues to "Must" and "Should" have based on feedback from @tkoleary, and adding @Bojhan's signoff to the summary. (Individual issues will still need usability review as we iterate on the design but we will tag them on a case by case basis, so I think we can remove the tag here.) Thanks!

@Bojhan has followed this a lot closer than I did, I'm just really happy to see that sidebar slide into view when I click a thing! Lots of design details to reconcile with this new pattern but overall really promising. Hope to see this land for 8.2, see you in the follow ups :-)

MOAR followups.

And clarifying one could-have point.

Oopsie, moving place block issue to the "not in scope" section.

Adding an explicit statement about the timeline for completing followups. Using our rule of thumb of "two minors", if the prototype is ready in time to be included in 8.2.0-beta2, we'd want to have most of the followup work completed by 8.4.0-beta1 for the module to remain in core.

@webchick and I discussed earlier that if/when Outside In is validated as a paradigm for Drupal core, there might be a followup initiative to more wholly integrate the user experience for Outside In, Toolbar, Quick Edit, Contextual Links, Place Block, etc., but that would potentially take longer than a year to resolve and would be out of scope for this experimental module itself. The part that we must do in order for this module to become stable is to ensure at a minimum that the overall user experience does not regress when it is enabled with other stable modules. There are specific "must-" and "should-have" followups for that and we will add more as needed.

And adding the final batch of followups from @tedbow and @tim.plunkett to the summary.

I would personally focus on:

• Polishing up the look/feel/interactions so it "feels" impressive out of the box. This will involve investigating the proper way to style the sidebar in a theme-independent way.

Any wins there have a major impact on perception.

<plug class="shameless">Child issue #2786195: Deleted block is not removed from the block list is ready for review</plug>

Then, if this functionality tests well once it’s in the hands of more users, the eventual plan would be to replace the current Quick Edit module’s functionality with this new project

Isn't this confusing Quick Edit with Contextual Links?

Quick Edit is for editing content, not for editing configuration. Outside In AFAICT is all about configuration. Quick Edit is triggered via Contextual Links. Quick Edit works in-place. Outside In doesn't; it slides in a configuration form.
That being said, I think it's fair to dismiss what I just wrote as merely being "today's practical reality", we should definitely aspire to unifying all that.

In my ideal future, Contextual, Quick Edit, and Outside In would all be merged into a single component with a single, responsive, integrated user experience.

So +100 to this!

Finalizing the JavaScript architecture, which should in turn provide a solid base for attacking outstanding accessibility issues.

This seems unrealistic and unreasonable. I don't think it'll be possible to finalize the architecture in 3 weeks, from the current PoC quality state it is in.

In other words: I think Outside In is simply the logical next step after Quick Edit: more intuitive, in-place editing of configuration, not only of content. For most configuration, that requires a form in a sidebar, because there's nothing visible to manipulate directly. But for some configuration (e.g. site name), direct manipulation like Quick Edit's should be possible.

Finally, I want to note that one major reason Quick Edit didn't tackle configuration still exists: because the configuration system doesn't have built-in validation. For that, we have #2164373: [META] Untie config validation from form validation — enables validatable Recipes, decoupled admin UIs …. The reason Outside In currently does not have that as a hard blocker, is because it doesn't ever provide direct manipulation, it always uses a form. So it is able to reuse the validation logic in the existing config forms.

With the module in core, its hard to say this is not an active initiative.

Yep, agreed that this is an active initiative. The "Active initiative" component was not added until after this module, but our signoffs are documented in the summary.

@catch, @cilefen, @Cottser, @alexpott, @effulgentsia, and I checked on the status of this initiative yesterday, and I also briefly reacquainted myself with the scope in the summary. It has progressed a lot in the past four months! However, based on outstanding work like the high-level usability issue described in #2781583: Reconcile the many forms of editing and configuring stuff (and address potentially redundant contextual links), the needed accessibility improvements, etc., this module is still in alpha.

That said, it is my understanding that #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it is currently a priority for 8.3.0, since that change will involve API additions to stable core (and therefore can only happen in minor releases). Completing that prior to 8.3.0-alpha1 on February 1 will allow Settings Tray (as an experimental module in itself) to progress to beta anytime during 8.3.x's beta, RC, or patch phases.

Are there any other issues on the roadmap that would need to touch stable core? There is #2784593: Outside In: Move toolbar CSS changes into the toolbar module, but that should obviously only happen in the forward development branch once Settings Tray reaches RC in the active branch.

As a reminder, we need to plan to complete all the "Must have" issues and most of the "Should have" by 8.4.0-beta1 in August 2017.

Great work everyone!

Oh, I forgot to mention that @catch raised a question about the potential disruption between this initiative and the Workflow Initiative, but I confirmed that this is covered on the roadmap by the first point under "Should":

Explore compatibility with #2732081: WI: Phase G2: Full-site preview with Workspace UI.

Adding a new accessibility issue: #2863222: Contextual Accessibility: Announcement broken after enabling editing mode a second time

Move #2784567: List "Quick edit" before "Configure" in contextual links while in Edit mode to a must have.
Talked to @dmsmidt who was working on that issue.

Fixing the link order makes tabbing with a screenreader much better so this moves #2784569: Settings Tray Accessibility: Improve tabbing to a "could have".

At the very least this is a proposed plan :)

Moved #2863222: Contextual Accessibility: Announcement broken after enabling editing mode a second time to a should have because this is an existing with the Contextual module not Settings Tray.
I tested and confirmed this existing without Settings Tray enabled and using Contextual module edit mode.

Here is an update on remaining Must-Have issues.

1. #2761985: Refine/finalize design to discoverable Quick Edit feature: All the must-have points inside this issue have been implemented. For that reason I would like to move it to should-have. Asked for feedback from UX team.
2. #2732443: Finalize the behavior for triggering view/edit/build modes from the toolbar (and fix the "disappearing toolbar") Probably needs feedback from UX team. Created separate issue from known remaining issue: #2877088: When in Edit mode Inform the user when they are configuring something that changes more than the current page
3. #2781575: Determine ideal field order and visibility for "quick edit" blocks in off canvas tray patch in progress needs reroll
4. Messaging user related: all probably rely on #77245: Provide a common API for displaying JavaScript messages which is "close"
   • #2773601: Display "You are now in edit mode" prompt when user enters edit mode should be easy after #77245
   • #2785047: In Outside In mode, form validation messages should appear in the off-canvas tray, not the main page also relies on #77245 but needs reroll for other portions

So 7 remaining Must-Have issues issues all are pretty close.

Lets review this during the UX meeting?

@Bojhan sounds great I will be at the UX meeting next Tuesday

Separated remaining and completed items into different sections in the summary

Removing Full test coverage from remaining tasks. The module has test coverage for relevant classes.
It also has extensive Javascript testing for the new off-canvas dialog OffCanvasTest.php
And for the block editing functionality OutsideInBlockFormTest.php

As far as I can tell there is not another module in core that has this much functional javascript testing. This is probably because a lot of the other Javascript heavy modules in core such as QuickEdit and Contextaul were developed before Javascript testing was added to core or at least before it was mandatory.

Added 2 more Should Haves

• #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it
• #2826722: Add a 'fence' around settings tray with aggressive CSS reset.

Assume this is concerned an Active Initiative because it has an experimental module in core.

Move #2781575: Determine ideal field order and visibility for "quick edit" blocks in off canvas tray to completed. I have marked it as outdated because the 2 remaining issue have been separated out to their own issues.

#2882729: In off-canvas block form hide Title input unless it will be displayed and change label to Block Title - Added a must have
#2888567: Add links to relevant off-canvas block forms to blocks to link to related configuration - added a should have. This could be done after the module is stable and will be an ongoing for any new blocks that get added to core.

Moved 2 more completed issue from remaining to completed in the summary!
#2761985: Refine/finalize design to discoverable Quick Edit feature
#2732443: Finalize the behavior for triggering view/edit/build modes from the toolbar (and fix the "disappearing toolbar")

1. Adding #2844261: Allow dialog links to specify a renderer in addition to a dialog type as a should have
2 .adding #2893937: Complete Handbook documentation for Settings Tray module as must have

Moving exploring #2732081: WI: Phase G2: Full-site preview with Workspace UI into completed. It looks like the using something that come down from the top of the page because it needs to be conceptually different from configuring things on the current site/workspace.

There is currently no code on the issue just concepts.

It could be explored later if there should be different positions covered in the off-canvas tray. Also the work here on #2844261: Allow dialog links to specify a renderer in addition to a dialog type would make it easier for that issue to current dialog system but use a different renderer.

I posted some feedback on the translations form issue (which I shared in person with Ted before, but should have posted publicly earlier). In short, I think not having that feature at the start is better then needing to support a half-baked feature for years. In detail at #2815709-19: Settings tray conceptually incompatible with configuration overrides such as translations.

Added #2784569: Settings Tray Accessibility: Improve tabbing and #2896143: Unintentional animation of the body while Settings Tray is installed as known accessibility problems.

A broader, more general question: "Outside in" is an overall design principle for the Drupal user experience. Settings Tray is one feature that uses this principle to bring "the thing" and "editing the thing" closer to eachother.

With Settings Tray close to getting finished, I'd like to start thinking about what's next for making Drupal work more Outside in.

One thing that comes to mind is that we should look into simplefying and standardising the different "in-place" edit modes and interactions. There's a lot of dashed borders and pencils and "+" icons fighting for atttention in our current setup.

Another thing would be the work being done for the layout builder?

(not all to be discussed here, but putting this here as this seems to be the "Outside in meta" :)

One thing that comes to mind is that we should look into simplefying and standardising the different "in-place" edit modes and interactions. There's a lot of dashed borders and pencils and "+" icons fighting for atttention in our current setup.

IOW: harmonize the Contextual Links, Quick Edit and Settings Tray modules. +1 to that!

#2784495: Normalize block place and outside-in experiences already exists for the harmonisation bit :)

Added the documentation issue to the summary.

Moved completed items in the summary

Updating summary to reflect that some of the must haves will be easier after #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it which is RTBC

Regarding

Thorough code review on final module.

from the summary. I am looking at other modules that went from experimental to stable to determine how to create this issue.

Moving #2784569: Settings Tray Accessibility: Improve tabbing to could have because in the issue it was determined by @dmsmidt that #2784567: List "Quick edit" before "Configure" in contextual links while in Edit mode

actually fixes the most pressing concerns.

And @Wim Leers noted

As far as tabbing is concerned, I think the Settings Tray module actually meets the accessibility gate! There's room for improvement, but overall, it works fine.

I broke out #2915759: :focus is is hard to see for links in the off-canvas dialog from this issue because it could be addressed by solely CSS.

Also broke out #2915762: Return to tab position when exiting dialog opened from contextual link it is yet to be determined if this is Settings Tray specific problem or a general contextual links problem.

Moved #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it to completed!!!!!

Also worthy of note here, I have created a patch for #2784935: Use Backbone for client-side state management
It is Needs Review but all tests passing.

Would be useful to know where to begin testing for this for accessibility. Having a few places where this has been added in this patch that we can quickly get to and evaluate how well it works in various assistive technology would be quite important.

@mgifford which part are you referring to?

The setting tray module has been marked stable. This issue was tracking accessibility issues #2928409: [META] Accessibility issues for Settings Tray and all the "must-haves" were completed.