Improve workflow for creating custom blocks

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.

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?

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

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

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.

Added beta phase evaluation.

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.

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.

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

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.

Test fix.

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.

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

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.

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?