Background

We know from numerous usability test results over the years that users, particularly new users, have a huge reliance on previews to accomplish site building and content authoring tasks. In the University of Minnesota 2015 study of Drupal 8, some of the critical UX issues identified were:

Dependence on previews led to inefficiency. "Until I saw them, I was never sure if I did the right thing." The inability to see the work in a realtime preview was frustrating.
"Order of operations are backwards! For example, dependencies and prerequisites for structuring taxonomy/content/etc. are reverse from the way users conceptualize it. (e.g. creating terms before adding a field for terms) "I have to go to the Block page and abstractly add a block."
Wayfinding, or clues on how to get started, were lacking. Task-based headings and navigation — verbs — would have been more helpful than the nouns presented. "This is a jambled-up hardware store with no wayfinding. I have to go through every aisle looking for electrical outlets.
"Drupal uses weird words for everything. Compared to Wordpress, "You don't have to figure out how to place your block inside your view inside your region inside your homepage." "If all you use is Drupal, you're not going to be able to make any other kind of website."

Together, these make for a monumental mental model problem for new users, which causes Drupal to be perceived as frustrating and difficult to use. Fixing these critical UX issues is necessary in order to start addressing the stigma Drupal has around its usability.

Goal

A solution which helps address each of these, at least in part, is turning Drupal outside-in (basic examples, more advanced example); that is, for all visible areas of the website, provide a way to quickly edit and/or configure it, directly from the front-end, without requiring users to break context, move to the back-end of their site, trawl through Drupal's admin IA searching for obscure terminology to change a certain part of the page, often with no ability to immediately see what effect the change has unless a user has two browser windows open simultaneously.
Here's a proposed prototype of the functionality, which has been through several rounds of feedback during the weekly Drupal UX team meetings, as well as adjusted based on feedback from Cheppers usability testing (click image to see video).

Invoking Quick Edit option invokes 'Edit mode'. Now clicking on anything on the page opens a sidebar on the right side with configuration options.

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.

Proposal roadmap

Required sign-off before commit

Owner Status Description
Product manager
@Dries (since @webchick is the initiative coordinator)
Initial signoff This initiative was proposed by Dries: Turning Drupal outside-in, Handling context in "outside-in" , Examples of how to make Drupal "outside-in"
Framework manager
@alexpott, @effulgentsia, and/or @catch
Initial signoff @effulgentsia in #2753941-162: [Experimental] Create Outside In module MVP to provide block configuration in Off-Canvas tray and expand site edit mode. Final signoff depends on code review of the final module.
Release manager
@catch and/or @xjm
Initial signoff @xjm in #2753941-226: [Experimental] Create Outside In module MVP to provide block configuration in Off-Canvas tray and expand site edit mode. Final signoff depends on completion of the roadmap and technical debt discovered while the module is experimental.
Sub-system maintainers
Quick Edit subsystem maintainer (@Wim Leers or @nod_)
Pending Pending approval of list of follow-ups.
Usability topic maintainers
(@yoroy and/or @Bojhan)
Initial signoff @Bojhan signed off on the plan in #34. Final signoff depends on full usability review, iteration, and testing.
Accessibility topic maintainers
(@mgifford, @andrewmacpherson, and/or @jessebeach)
Pending Pending a full accessibility review.

Required before stable release

For this module to become a stable part of Drupal core, all of the "Must-have" and most "Should-have" followups should be completed before the beta phase for 8.4.0.

Must-have

Should-have

Could-have

Not in scope

Team and resources

This team is from Acquia's Office of the CTO, and funded full-time for development.

Process and where to find it

Issue tag: Outside-In
Where we work: We are using the existing #ux channel on drupal.slack.com (get an automatic invite here), as well as the existing semi-weekly Drupal UX Team meetings for interim reviews of progress. (What time is that in my time zone?)
Plan for the code: We plan to propose this improvement as a new experimental module for Drupal 8.2, an approach which has sign-off from @yoroy and @Bojhan (UX Topic Maintainers), as well as @Dries (Drupal Product Manager).

Related work

Existing core features

Place Block module already exists.
Contextual links already exist.
Quick Edit module already exists.
This feature begins to weave them together into a more holistic outside-in editing experience.

Open core issues

(See issues in proposed roadmap.)

Contributed projects

None that we are aware of.

Comments

webchick created an issue. See original summary.

webchick’s picture

Issue summary: View changes
webchick’s picture

Issue summary: View changes
webchick’s picture

Issue summary: View changes
FileSize
24.41 KB
Bojhan’s picture

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.

webchick’s picture

The proposed roadmap does not have changing of the way we place blocks, nor the configuration split. The screenshots in the issue summary are accurate.

webchick’s picture

Also, could you please elaborate on what you mean by "bigger picture"? There's some detail under "Background" as well as several links to blog posts which provide even more bigger picture stuff. I'm also not sure what you mean by missing parts. If you have specific concerns with items the roadmap, it would be great to know them.

webchick’s picture

Issue summary: View changes
FileSize
184.7 KB

This might be one problem. Clarifying the scope of this issue.

webchick’s picture

Issue summary: View changes

And one more.

Bojhan’s picture

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.

webchick’s picture

Yep, the block placement stuff has been moved over to #2739079: Reduce visual clutter of Place Block module (sorry, it's not easy to edit a video :\), so is out of scope for this issue. Since Place Blocks module is already in core, we are not planning to work on those revisions until after the August 5 feature cut-off for 8.2, which gives some time to discuss them more.

The reason the site name block in the prototype only shows toggles, vs. something more useful like actually editing the site name, is because our initial thought was for the sidebar to be programmatic and just show the block settings that are unique to that block, which unfortunately that's all the settings the branding block gives us. :\

Site logo, site name, and site slogan

However, when we dug in here, the per-block settings are actually mostly useless, and not just in the branding block; for example, for menu blocks you wouldn't get the actual menu to customize (which is the 80%+ case), you'd "Initial menu level" and "Maximum number of menu levels to display", thus pushing right into content authors' faces these obscure advanced options. :P

We also briefly explored something like a #short_form = true property on form elements, set by the module author, and looping through and showing those. But that also doesn't work, because custom modules may have set properties such as #access further up the tree, and the text field element would not necessarily know.

So the MVP proposal in the roadmap above actually is to start with menu blocks, by implementing a custom "short form" that is more task-focused specifically for that block (basically, the existing menu edit form), and which also gets pulled into the "full" configuration form wholesale, making both the sidebar and the advanced view more useful at the same time. Once we have that pattern established once, we can then take it to all of the other blocks (e.g. Branding = actually edit the site name, slogan, etc. right there, in addition to toggling settings on/off). But we need to shoot for an MVP for 8.2 feature freeze, since time is rather short. (We can continue expanding to more blocks during beta.)

Fair point about wanting to see more of the long-term vision of how this pattern works when applied to more blocks, as well as things like Views, etc. We can work some more on that. Any use cases in particular that would be interesting to see mocked up? I'll also ask Kevin to elaborate on some of the thinking behind the design-specific questions.

tkoleary’s picture

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.

tkoleary’s picture

@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.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

catch’s picture

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.

webchick’s picture

Issue summary: View changes

Attempting to update the issue summary with all of the follow-ups I know about to-date.

webchick’s picture

Title: Introduce "outside in," preview-first UI pattern to core » Introduce "outside in" quick edit pattern to core

And touché.

webchick’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
FileSize
144.6 KB
99.06 KB

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!

xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes

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.)

xjm’s picture

Issue summary: View changes

@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.

xjm’s picture

Issue summary: View changes
xjm’s picture

Version: 8.3.x-dev » 8.2.x-dev
xjm’s picture

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.

xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes

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.)

xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes

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.

Bojhan’s picture

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

xjm’s picture

Issue summary: View changes
Issue tags: -Needs usability review

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!

xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
yoroy’s picture

@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 :-)

webchick’s picture

Issue summary: View changes

Adding various follow-ups to the issue summary.

xjm’s picture

Issue summary: View changes

MOAR followups.

xjm’s picture

Issue summary: View changes

And clarifying one could-have point.

xjm’s picture

Issue summary: View changes

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

xjm’s picture

Issue summary: View changes

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.

xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
webchick’s picture

Issue tags: +sprint

Just as an update: we had our team planning meeting earlier today and put together a rough list of priorities for the next 3 weeks prior to RC1, which you can see with issues tagged 'Outside-in' and 'sprint'.

In general, before RC we're planning next to focus on:

  • Discussing and hopefully resolving several of the outstanding "must-have" design questions.
  • 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.
  • Finalizing the JavaScript architecture, which should in turn provide a solid base for attacking outstanding accessibility issues.
xjm’s picture

Issue summary: View changes

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

xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
xjm’s picture

Issue summary: View changes
Bojhan’s picture

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.

nod_’s picture

Issue summary: View changes
xjm’s picture

Component: quickedit.module » outside_in.module
xjm’s picture

Issue summary: View changes
larowlan’s picture

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

Wim Leers’s picture

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.

Wim Leers’s picture

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. 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.

webchick’s picture

Issue tags: +Drupal core ideas

Hi there! This is an issue that we'd ideally like to move to the new "Drupal core ideas" queue when/if #2785735: [policy, no patch] Agile process for bigger changes in core (Part A: Ideation) goes through (hoping for the next week or two). If you could read that issue and provide your thoughts on that, that would be great!

webchick’s picture

Project: Drupal core » Drupal core ideas
Version: 8.2.x-dev »
Component: outside_in.module » Plan

Doing that. :)

aspilicious’s picture

Issue summary: View changes
Gábor Hojtsy’s picture

Component: Plan » Active Initiative

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

xjm’s picture

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!

xjm’s picture

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.

tkoleary’s picture

Issue summary: View changes
webchick’s picture

Issue summary: View changes

Adding a new must-have to the list, which is #2853208: [META] Determine best method ensure consistent theming of Off Canvas Tray. Required to determine how other themes/contrib modules will integrate with Settings Tray.

dmsmidt’s picture

Component: Active Initiative » Idea
Issue summary: View changes
tedbow’s picture

Issue summary: View changes

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: Outside-in Accessibility: Improve tabbing to a "could have".

tedbow’s picture

Issue summary: View changes
yoroy’s picture

Component: Idea » Proposed Plan

At the very least this is a proposed plan :)