Problem/Motivation

Due to changes made in #2512456: Implement the new block layout design to emphasize the primary interaction of placing a block the previous action link for creating custom blocks was moved. This however made creating custom blocks non-obvious and the workflow for creating one somewhat convoluted.

The current workflow and UI state (courtesy of larowlan in #233):

  • Visit block layout
  • Click place block next to a region (modal)
  • Click add custom block action link (modal)
  • Redirect to block/add (non modal)
  • Add custom block content entity (non modal)
  • Redirect to place block form (non modal)
  • Save block placement
  • Redirect to block layout, new block highlighted

Note: The buttons on the current page were renamed to "Place block" solely because of the current action button (see #214), so it could also be changed back to "Add block" if it were to be removed.

Proposed resolution

Place the management of custom block content under /admin/content to achieve the following workflow which effectively cuts the number of required steps in half and makes more sense from a content manager's perspective.

  1. Visit Custom blocks (currently Custom block library)
  2. Click add custom block action link
  3. Save block
  4. Redirect to Custom blocks

Place the management of custom block types under /admin/structure to achieve the following workflow which reduces the number of required steps by two and makes more sense from a site-builder's perspective.

  1. Visit Block types
  2. Click add custom block type action link
  3. Save block type
  4. Redirect to Block types

Remaining tasks

Review
Commit

User interface changes

Relocation of two block_content related sections.

API changes

None.

Data model changes

None.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Task: Affects usability; not a bug.
Issue priority Major: Significant regression in user experience (may be critical at core maintainers' discretion). Very high probability that user's will not find module functionality.
Prioritized changes Yes: Usability and UX improvement. Follow-up to recent critical.
Disruption Undetermined, but likely minimal. Unlikely to require changes in contributed modules. No widespread changes. No subsystem changes. No data alteration.

Comments

legolasbo’s picture

Issue summary: View changes
MattA’s picture

Issue summary: View changes

Moving proposals to comments until we get more consensus.

Current options are:

  1. Simply adding a paragraph describing what a custom block is with a link to create one on the block layout page.
  2. Add an action button to the "add block to layout page" (to be clear: the one with all the buttons, not the one with the tabledrag).
  3. Move "custom blocks" to a tab under "admin/content" instead.
legolasbo’s picture

Issue summary: View changes
FileSize
37.49 KB
44.87 KB

Add an action button to the "add block to layout page" (to be clear: the one with all the buttons, not the one with the tabledrag).

This would still leave the "Custom blocks" tab in a really unexpected position on the "Block layout" page since there are no custom_block related actions on that page. I propose moving the tab to the "Add block to layout page" aswel. See attached mockups.

Custom blocks tab removed.

Custom blocks tab added.

MattA’s picture

Hmm, the main drawback with option 2 is from the clicks involved with going through the menu system.

So starting from the home page we get:

  1. Click on 'Structure' from the toolbar.
  2. Click on 'Block layout'.
  3. Click on 'Add block to layout' button.
  4. Click on the 'custom block' tab or button.

Almost right off the bat the workflow takes a weird turn. Why would a new user go to block layout when they want to create a new block? Placement is irrelevant to what they are trying to do. They know it doesn't exist, and therefore cannot be placed. Adding that third click is kind of just pouring salt into the wound.

Maybe we could add it directly to the 'Structure' menu, or even split custom blocks and custom block types. Moving the first to the 'admin/content' path and the second to the 'admin/structure' path?

MattA’s picture

Sigh. You wanna know how old this issue really is?

#1164718: Improving the usability between "custom block" and "content"

MattA’s picture

So I read through the issue above, and we kind of need a maintainer to decide how to proceed.

Using the options mentioned in #43:

  • That issue can either go with option #1 and save the node vs. block philosophy for later by bumping the issue to 9.0.x. -or-
  • That issue can go with option #2. Which, at this point in development, essentially means merging what we have and closing this issue as a duplicate.

Incidentally, that issue also contains our solution:

Without fail, every. single. person who participated in usability testing at UMN went to "Create content" when asked to create a sidebar block.

...means we should almost certainly create something in 'admin/content' heh.

MattA’s picture

Issue summary: View changes

Added beta phase evaluation.

larowlan’s picture

Status: Active » Postponed
larowlan’s picture

Status: Postponed » Active

Blocker is in, thanks everyone for their work so far

nbz’s picture

Could changed wording help improve the issues being addressed?

add custom block >> create new block,
add block/place block >> place existing block

MattA’s picture

Category: Bug report » Task
Issue summary: View changes

Updated the IS, issue category, and beta evaluation since #2512456: Implement the new block layout design to emphasize the primary interaction of placing a block was changed to bring back the old action button.

#10 I don't see how. The primary concern is that the clicks involved are buried in menus and/or other unrelated tasks. The updated issue summary has a complete list of required actions, including their modal/non-modal display state, that shows how absurd it is in practice.

legolasbo’s picture

I've also had a look at the current workflow for creating custom block types, which is the following:

  1. Visit block layout
  2. Click Custom block library tab
  3. Click Types local action link
  4. Click add custom block type action link
  5. Save block type
  6. Redirect to Block types

As @MattA suggested in #4 the current workflow is taking a strange/unexpected turn for both the creation of a custom block and custom block type. By splitting whats currently called the "Custom block library" in two and repositioning the management of both custom blocks and custom block types we could greatly simplify the workflow for both and be more in line with the workflow used throughout core. My suggested approach is the following:

  1. Place the management of custom block content under /admin/content to achieve the following workflow which effectively cuts the number of required steps in half and makes more sense from a content manager's perspective.
    1. Visit Custom blocks (currently Custom block library)
    2. Click add custom block action link
    3. Save block
    4. Redirect to Custom blocks
  2. Place the management of custom block types under /admin/structure to achieve the following workflow which reduces the number of required steps by two and makes more sense from a site-builder's perspective.
    1. Visit Block types
    2. Click add custom block type action link
    3. Save block type
    4. Redirect to Block types
MattA’s picture

Yep, I fully concur with @legolasbo.

I was toying around with it and moved the entire tab to 'admin/content' which would make a lot more sense to normal users. Ideally, Drupal would use a task-based approach to it's menu structure (best for users), instead of categorizing it (which let's be honest, doesn't even work well for developers/site-builders half the time). If that were the case, leaving the 'types' sub-tab there would be ideal, but since it is not, splitting it off to 'Structure' brings it inline with the current menu system.

legolasbo’s picture

Issue summary: View changes
Status: Active » Needs review

Attached patch implements the changes suggested in #12 and contains updated tests aswel.

legolasbo’s picture

FileSize
19 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 98,359 pass(es), 5 fail(s), and 0 exception(s). View

Oops, forgot to attach the patch

Status: Needs review » Needs work

The last submitted patch, 15: improve_workflow_for-2523154-14.patch, failed testing.

legolasbo’s picture

Status: Needs work » Needs review
FileSize
22.79 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 98,378 pass(es). View
3.79 KB
  1. Adjusted 3 missed paths in ConfigTranslationListUiTest.
  2. Removed BlockContentLocalTasksTest.php because the local tasks it tests have been removed.
MattA’s picture

FileSize
18.93 KB
33 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 98,794 pass(es), 3 fail(s), and 1 exception(s). View
  • Removed the action link from the modal, since providing a link to break out like that is terrible design and was probably only temporary to begin with?
  • Added a link to the 'Custom blocks' tab to the menu.
  • Merged in the help text improvements for the block content/type pages that were lost in #2512456. This also fixes a reference to the 'Place blocks' sidebar that was still there.
  • Updated some page titles, since just showing "Add" or "Edit" during the workflow is bad.
  • Since blocks don't have individual 'view' pages, there is no point in providing a link to them in the table. Just use the 'Edit' operation link.
  • Clicking save after creating a new block lead to the customize block placement form and eventually the block layout page. Since that is a totally unexpected behavior now, removed the redirect and its associated test.
  • Added a link the block layout page in the "block created" status message in order to give users more clues as to what to do next since the redirect was removed (not totally sold on this method's effectiveness, so discuss).
  • Visiting the delete confirm page showed ID# breadcrumbs, so added a page title callback.
MattA’s picture

Also wanted to add that I'm not a fan of the 'admin/structure/block-content' path, but it looks like there's already a separate issue that would fix it: #2501691: Change content-types, comment-types, and block-types URLs.

Status: Needs review » Needs work

The last submitted patch, 18: 2523154-18.patch, failed testing.

MattA’s picture

Status: Needs work » Needs review
FileSize
1.87 KB
34.55 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 98,843 pass(es). View

Test fix.

MattA’s picture

Issue tags: +Needs usability review
MattA’s picture

FileSize
34.55 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch 2523154-23.patch. Unable to apply patch. See the log in the details link for more information. View

Just a quick rebase (no actual changes) since #2541416: Block content view is missing the 'default' tag. changed an unrelated line that prevented the previous patch from applying cleanly.

mgifford queued 23: 2523154-23.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 23: 2523154-23.patch, failed testing.

MattA’s picture

Status: Needs work » Needs review
FileSize
35 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 114,184 pass(es). View

Rerolled. Basically just updated !placeholders to :placeholders and some test updates.

MattA’s picture

FileSize
35 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 114,587 pass(es). View
2.88 KB

Two documentation changes, one to prevent a regression from #2493475: Fix online docs references in Help to conform to our standards and another because if we did this right, content authors shouldn't have to know about the underlying fields and stuff.

Bojhan’s picture

Issue tags: -Needs usability review

What needs review here? Feel free to add it again.

MattA’s picture

Since a lot of the pages were moved around, the question was essentially if people would be able to find the right pages for their task and if the workflow was actually better. Although, since the actual forms and UI of the pages has not changed (except for the button in the modal dialog that was removed) I guess this could technically just need a product manager review?

Bojhan’s picture

Nope, this would be perfect for UX review - can you reroll the patch, so I can try it?

MattA’s picture

Issue tags: -Needs reroll
FileSize
34.94 KB
Bojhan’s picture

Version: 8.0.x-dev » 8.1.x-dev
Issue tags: -Needs usability review

This actually matches exactly what we set out to do, so I think this simply needs code review in order to go in.

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

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

yoroy’s picture

Issue tags: +ux-workflow

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.

larowlan’s picture

Code looks good but it does make a major change to UX - want to be sure that UX folks are happy with this.

  1. +++ b/core/modules/block_content/src/BlockContentForm.php
    @@ -194,23 +194,7 @@ public function save(array $form, FormStateInterface $form_state) {
    +      $form_state->setRedirectUrl($block->urlInfo('collection'));
    

    This breaks adding a block content entity and a placement in one step. Not sure we want to do that - UX folks?

  2. +++ /dev/null
    @@ -1,36 +0,0 @@
    - * Modifies the 'Add custom block' local action.
    - */
    -class BlockContentAddLocalAction extends LocalActionDefault {
    -  use UrlGeneratorTrait;
    -
    -  /**
    -   * {@inheritdoc}
    -   */
    -  public function getOptions(RouteMatchInterface $route_match) {
    

    So we're removing this from the 'Place block' dialog. This will mean you can no longer add and place a block in one step. Are we happy with this? UX folks?

cilefen’s picture

Is this a regression? The current behavior is different than "current workflow" in the issue summary.

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.