Improving the usability between "custom block" and "content"

Additional considerations from the Usability Study related to this issue:

- Blocks were thought of as “boxes”.
- Writing it comes first, deciding whether it's a block or not comes second.
- Block content is thought of as a type of content. Did not expect blocks in “structure”.
- Blocks are considered an appearance type for content.

"- Blocks are considered an appearance type for content."

I think "appearance types for content" is key here. Drupalism for it could be to provide a "box" display mode for your content type.

There would appear to be at least one working contrib example of some of the ideas outlined here...

http://drupal.org/project/nodeblock

Cross-linking #430886: Make all blocks fieldable entities. Adding a node reference field to custom blocks would allow this - workflow would be post the node, go to blocks interface, add block, choose a node to reference. With the current blocks UI this might not be an improvement.

Another option would be turn node/add into entity/add and have it as a central routing point to creation of various entities.

We definately need to approach this from the 'central place to go for creating stuff' perspective :)

Regarding usability, I just stumbled over a bug and scrunched it. Poor life ended.

On a more related note, this reminds a bit of http://drupal.org/project/nodeblock, http://drupal.org/project/nodeasblock, and http://drupal.org/project/nodesinblock.

And that said, I'm glad the subjects didn't have to deal with Entity API module.

It does not make sense to discuss this topic on the wonky old grounds of D7. Thinking ahead, we need to consider a fully-fledged entity system in core. FWIW, what we know as node/add becomes add.

Apparently, even the most experienced [Drupal] developers have serious issues when having to architecturally design what becomes a "node" and what becomes an "entity".

If, and only if we want to retain the interface pattern of having a single, unique entry point to "CREATEALLKINDOFSTUFF", then we need to think beyond horizons.

However, I'd call that pattern extremely debatable on its own. Looking back at all of the sites I've built, I'd be very much in favor of dropping that pattern entirely, and replacing it with something entirely new. (Hint: That's the point where UX masters would've to do some epic kung-fu.)

Of the modules @sun linked to, I think http://drupal.org/project/nodeasblock is the closest to the strawman proposal that was discussed at the end of usability testing. (Note: http://groups.drupal.org/node/93499 is a nice page that lets you compare all the "node as block" modules.)

Basically, the proposal was to get rid of custom blocks entirely (or at least make them obsolete), and instead allow any node to be optionally exposed as a block. As a first pass, for example, there might be a "block settings" vertical tab when you are creating or editing a node, in which you could choose to expose it as a block and place it in a region. If you're looking for an example, the Media Gallery module actually does this for gallery nodes (although it doesn't expose the full range of block settings on the node page).

In short, if people go to "add content" when they want to put text in a sidebar, why fight it? Just let them.

***

Not everyone was totally on board with this plan, so it's worth discussing why. Is there anything that custom blocks currently provide that nodes don't? What value do custom blocks actually have as a separate concept, when they basically just contain content anyway? There's a lot they currently don't have (such as fields - #430886: Make all blocks fieldable entities) which they could have, but which nodes already have and which we would get for free by combining them.

One issue that I remember coming up was that Jen Lampton raised the concern that she wouldn't want many custom blocks to show up in search results like nodes do (for example, blocks containing an advertisement). That's valid, but in my opinion there are in general many types of nodes that you'd want to hide from search results on particular sites, not just content that normally appears in a block. So that could be addressed by adding a more general feature to allow certain kinds of nodes to be excluded from search.

It does not make sense to discuss this topic on the wonky old grounds of D7. Thinking ahead, we need to consider a fully-fledged entity system in core. FWIW, what we know as node/add becomes add.

But if we did this I think the big question would still remain: Once they got to the new "add" page, what would they do next?

Presumably, they'd have to choose what kind of entity to add. So if node and block are separate concepts still, they would need to choose between them at that point, and we'd need a good way to communicate the difference up front.

We have the entity system to finally get rid of the Total Abuse Of Nodes™. A node is an entity that (also) has fields attached to it. Every entity type can have fields attached to it. Removing custom blocks in favor of abusing nodes to become blocks would be totally backwards, to say the least.

Allowing a node to spawn blocks makes only sense if your intention is to get a "teaser block".

I'd highly recommend to re-think the topic and title of this issue. Given entities/fields in D7, you can happily add "taxonomy term" to that list of "block" and "content", and there are many more entity types in contrib as well as in core to come; this list is infinite, it won't ever end.

Apparently, the real issue we're facing is that we introduced an entity system, but we did not define what kind of data is supposed to become a new entity type, when it would make sense to re-use existing entities defined by other modules, and lastly, how we're going to expose and explain all of those entity types to the end-user in the end.

Yes, nodes currently do have a difference to other entities, namely node access, comments, and whatnot. But if we want to discuss this topic for real, then we need to stop thinking about today, and blend ourselves into 2 years from now, when D8 might be close to a release. Nodes will have zero differences to other entity types then.

I think ultimately erasing the concept of block vs. node at all in favour of a meta "Content" entity is what we'd want

By erasing that you also erase the concept of taxonomy terms, products, users, comments, profiles, and everything else.

No, that's not what we want. Pretty much the exact opposite. There's a certain expectation of structure and behavior involved for every entity type that exists. Labeling everything "Content" will confuse everyone. The idea of technically changing Drupal to conform to this over-simplification is utterly wrong. If that would make any sense, then we wouldn't have implemented an entity system, and would've made Everything a Node instead. But we didn't do this, and we didn't do it for very good reasons. Because the concepts, logic, and behavior are different.

The cause for this issue is that we still have a "Create content" link from stone ages. It doesn't list or allow to create blocks or any other kind of entities.

That is the actual, major user interface design problem to resolve.

I'm not at all in favour of having nodes exposed as blocks, at least not instead of custom blocks, it feels like it is just going to add another layer of issues on top of this.

When you create a node, you get taken to node/n and can see it straight away.

If you wanted to create a node to use as a block, then either there will need to be some kind of block settings on the node form, that's going to be nasty with the current blocks system, and/or you'd have to make a dedicated trip to the blocks ui to assign it.

Then it'll need a block display mode (assuming it's not hardcoded to one node type).
The node will still show up on its own unique page.

All nodes have options like published, sticky, menu settings - makes no sense for something that should only appear in a side bar.

These will get search indexed - the results are going to go to the node/n page though.

All this sounds like a custom entity type to me. Would be more into contextual links on regions that take you directly to a block add screen. Which is tricky as well of course but starts to approach some of the other issues with the block ui as well.

Except for the search index issue (which as mentioned above should be solvable) I don't see why any of those things are a problem.

Getting redirected to node/nid after creating block content doesn't seem bad. People weren't confused by that; what confused them was wanting to get that content they just created into a sidebar and not knowing how to do it.

Menu settings/etc are not needed for a lot of block content, but since they're disabled by default that shouldn't be an issue; if you don't need them, you won't use them. And there are lots of situations where they would actually be useful. Media Gallery is a good example (although that's somewhat advanced), or even simpler, what if you want an article teaser in a sidebar on the front page of your site that links to the full article?

Block settings will look ugly on the node form right now, yes (mainly because it will involve vertical tabs within vertical tabs) but perhaps a simplified version (that only let you configure the title/description/region) would make sense, and you use the block interface if you need the rest.

I think a contextual link for adding blocks to a region is a useful idea, but I don't think it will help much with the particular issue we saw here. (People mostly went straight to add content; it didn't really even occur to them to look elsewhere on the page.) Also, the contextual link would become tricky to display if the region doesn't have any blocks in it yet.

So in the usability testing, did people create another basic page, then go straight to the blocks UI? Or did they create the page, get stuck, call the helpdesk, then get sent to the blocks UI, then get annoyed because they had to re-make the content?

If I was making sidebar content (from node/add/block), and I got taken to it being in the middle of the page on its own at a completely different path, I would personally find it a bit odd. The first couple of rounds of usability testing people had major, major issues even locating content that they had previously created, that is as much related to the menu item addition as this though.

If they did get to the blocks UI by themselves quickly, then it'd be feasible to do this with a fieldable block with a node reference on it - the block displays the node in a display mode - and you wouldn't need to decide beforehand when creating a node whether it should create a block or not. The standard profile could create a block bundle with the node reference configured already - but internally we wouldn't be hard coding block module into node module (or vice versa).

...or even simpler, what if you want an article teaser in a sidebar on the front page of your site that links to the full article?

How would menu settings be useful for that?

OK that's more or less what I guessed.

So say the node/add/block form had some subset of the blocks UI embedded in it (which feels like the exact opposite of where the blocks UI itself should go, it is already fractured all over the place), then what stops them missing that the first time? People miss it with menu settings too (and menu settings are equally cryptic about where things will show up).

Then on top this is going to need a meaningful preview of the block showing up - but that preview would need to respect block visibility, which is probably specifically not going to have the block show up on same page as the node its derived from.

I was recently pointed to an interesting module that seems to address some of the UI challenges people had around adding content to regions of the page (and which therefore might be somewhat relevant for this issue):

http://drupal.org/project/hotblocks

Also, to belatedly answer this:

...or even simpler, what if you want an article teaser in a sidebar on the front page of your site that links to the full article?

How would menu settings be useful for that?

What I meant was that suppose you have an article that appears in the menu structure of your site (and therefore needs to use the menu settings). But you additionally want to make a teaser of that article appear in your site's sidebar, on other pages.

@webchick wrote:

I'm not advocating for "everything as a node". I'm advocating for "Why have a false dichotomy between primary and secondary content?" The inconsistent UX between blocks and nodes (no preview function, no revisions, no ability to upload files, etc.) has long plagued Drupal, and for absolutely
no good reason. Let's keep block module the API for modules to expose their data as "stuff that shows up on admin/structure/block" and make node one of
those modules that lets the user do that with its data, using an opt-in setting.

So, if I understand you correctly, you are suggesting that Block.module become basically an appearance module, the thing that allows you to grab onto content (be it user generated, or generated by a module), and then to select visibility settings for that content.

This means that Node.module can choose to expose a UI to modify the visibility settings for a piece of content created, User.module can choose to expose a UI to add visibility settings, and Foo.module can do the same.

Instead of thinking of this issue as a 'nodes as blocks' issue, it is really a 'kill blocks' issue. Then any entity, or any module at all, can use the Block.module API, and possibly part of the Block.module UI, to allow users to choose visibility settings and to position their 'content'.

This would allow me, the user, to place advertisement nodes (or 'AdEntities if created), in the desired region of a product landing page; to place the user profile of a author of an article in the desired region of the article page; to place my foos all over my bar pages.

Bojhan and yours truly outline our approach for a basic Pages and Components paradigm here: Core Context UX: Page & Component library. Long post, even longer discussion but very relevant to this.

OK, here is my world view:

1. The stuff that hook_block_view() returns (i.e. the subject and body) is content. It is useful for modules to be able to provide content to the CMS in this way.
2. Block module is an optional mechanism for putting blocks into regions, and configuring visibility and related bits. This part is configuration.

How much of all this depends on Context initiative? Right now ux team is under the assumption that most of it is and thus not working on further designs. If there's Context-independent plumbing to agree on we definately should.

If we wanted to make custom blocks (from block module) into entities per #430886: Make all blocks fieldable entities that could start whenever (although would be easier when more entity patches have landed). Doing that would not affect the actual block API (in terms of hook_block() or regions) at all. It also wouldn't be affected by wscci that much - at least not compared to any other rendering of stuff.

Changes to hook_block() itself, making all blocks entities etc. are going to have more risk of conflicting with wscci work.

The twittersphere pointed me here. Once again I missed the memo. :-)

I think part of the issue here is that while to a new user "it's no the page, so it's content, duh" seems natural, it's not actually true in any meaningful sense. The majority of what shows up on the page is not unique to that page content, at least not on 99% of the sites I've worked on. Most of it is ad blocks, views, custom functionality blocks, etc. If you want to change one of those chunks (for lack of a more abstract term), then are those changes specific to that page? General to any page using a similar layout (for some definition of similar)? Site-wide? How do you decide which is which?

These are the sorts of questions that the discussion linked from #22 is trying to wrestle with, as it's not an easy question. In a sense, part of the problem is that Drupal is too powerful to work with such a simplistic "every page is edit-in-place content" UI model. That would actually be more confusing, because so much of what appears on a page is not a single item of content.

The approach that WSCCI has been intending to take is that a Block is a plugin. That is, it is a Logic Object, not a Content Object. One instance of a Logic Object could be "display this Content Object here", certainly, and that needs to not suck the way custom blocks suck today. However, to say that the hard-coded "who's online" block is "content" the same way that an event node is content is simply flat out wrong, and to try and put that mental model onto users, even if it is their first naive knee-jerk reaction, is doing them a gross disservice.

Rather, we want to try and build an accurate and useful mental model that they can learn from using the system without having to reach for a copy of Drupal for Dummies, not assume that their first knee-jerk assumption must be right and try to shoe-horn a round peg into that square hole. (As the saying goes, the only intuitive interface is the nipple. Everything else is learned.)

Since it's quite easy to build a page in Drupal that contains no unique data objects of any kind at all, we shouldn't mislead users by pretending that "everything is a data object (content)".

The approach that WSCCI has been intending to take is that a Block is a plugin. That is, it is a Logic Object, not a Content Object. One instance of a Logic Object could be "display this Content Object here", ...

This is the model I have in mind for "blocks" but we need to be careful about vocabulary. The Block should be a plugin but the instance of the block should be an entity. The Block plugin is used as an entity bundle to create "block types". The instance of the block could also respect the WSCCI context system

This gives a ton of flexibility and turns the block instance into content. Modules like OG can be used to have the block respect the group. It also makes the interface very familiar to users and site builders.

This is the basic pattern I used in the bean module. http://drupal.org/project/bean.

Since the instances of the a block are entities, they can be easily associated to nodes that represent a page and placement can be controlled on the theme layer. This pattern worked every well for us on energy.gov in building on pages and instances of blocks using the bean module and the block reference module.

Until the discussion about what a Block is really finished, I'm getting the ball rolling with turning custom blocks into entities which is something that we all seem to agree on. #430886: Make all blocks fieldable entities

Crell, I left you a Druplicon message in IRC pointing you here :)

You don't *build* mental models, you uncover them by observing people. They are not "right" or "wrong". If you want the implementation model (what you are describing) to expose its functionality in a way that makes sense to the mental model people bring to it, you look for a concept model that maps user expectations to how the system actually works. That's where the basic Pages & Components idea comes in. It's the central idea for how stuff (excuse the jargon by now) can be but on pages.

"Accurate", "right" or "wrong" or "for dummies" are hardly useful criteria for finding how to "bridge" mental and implementation models.

---

Moshe's comment made me think there are moveable parts in blocks system that could be improved independent of WSCCI. From my limited understanding of things, I'm not sure you responded to that at?

This issue is really just about custom blocks (i.e. the kind you create at admin/structure/block/add), not blocks in general.

In particular, during usability testing, when we told people to write a paragraph of text and put it in the right sidebar of their site, everyone went to "Add content" to do it (and consequently got very lost), whereas no one tried to create a custom block. The scope of this issue is figuring out how to solve that problem. Since (I think?) everyone does agree that custom blocks are "content" (given that they contain user-generated paragraphs of text), we shouldn't have to worry about the rest of that debate here. Hopefully :)

So. The original (and hopefully simplest) proposal to solve this issue is to allow the node module to expose its content as blocks. As far as I can see, this is envisioned by the Core Context UX: Page & Component library designs also, since it mentions nodes as one of the things that you can choose from when you add a "component" to the page. (And as Everett pointed out, this is not actually limited to nodes, either; if we want to allow user profiles to appear in sidebars, they could be exposed as blocks - or in the future, "components" - also; although this would presumably be a separate issue.)

I suppose we don't actually have to get rid of custom blocks as part of this issue. If we wind up allowing nodes to be exposed as blocks, though, it seems to me like they're so similar that there is no point in keeping "custom blocks" around in core any more (they could still exist in contrib, of course).

It's important to bear in mind that simply turning a node into a block is not a sufficient answer.

Most users usually want 1) a different, possibly shorter title on the block, 2) a dedicated/custom "teaser" text, and 3) possibly a link to a or "the" content page.

In other words, there is a very good reason for why modules like Teaser Block & Co exist.

Let's make sure that we account for the different business logic around content pages (nodes) and content blocks. The underlying business logic is what ultimately makes the difference between entity types.

I think if we do this we'd also have to add a new view mode to node entities (which would be used when the node is displayed in a block). That would allow most of the things you're talking about, although perhaps not all of them?

Node-as-block is not the answer. It's nice and simple, but that doesn't make it a good answer. Nodes are "primary content". They have their own display page. Do you really want every custom block to also show up on its own node/nid page? I don't. :-) Do you want to have the option of displaying any of 50,000 nodes on a site in a block? The UI for that scares me even more than the architecture does, which is quite a lot.

I think the point about showing user profiles in the sidebar is valid. What you have there is a data object (user) that you present in a given way (a rectangle on the side of the page). It's classic separation of content and presentation, which even after almost 20 years is still critically important yet no one understands how important until they've worked with it for a while. :-) I run into that with clients all the time, especially those coming from a design-time CMS or Dreamweaver templates. It does take a mental jump to realize that you're not editing a page, you're editing a pool of data and then defining rules for displaying that data ON a page.

If that's not people's expectation coming in, then we need to improve our ability to guide them to that expectation.

Blocks should not be entities, at all. Not even instances. An instance of a block is like an instance of a View. It's configuration. It has a machine name, not a serial ID.

custom blocks, I agree, could be implemented as their own entity type, as those are content. They're distinct from a node, I believe, as nodes are "primary site content"; Taxonomy terms are "metadata about primary site content"; custom blocks are "secondary content". Even though all three are entities, they're distinct types of entities.

We could also in the UI allow for easy creation of a custom block entity data object and the creation of a block logic object to display it; that's fine, but let's not confuse the two things internally. One of the big pushes in Drupal 8 is to untangle all of the shortcuts that have now wrapped around our necks. Let's not add more such shortcuts at the same time. :-)

Sure. Autocomplete field on node titles/nids. Panels has had it for years. And as an alternate UI, "Expose this content as a block" on the node settings, and a list of regions to assign it to when it's checked.

Exactly. And the "expose this content as a block" checkbox pattern has been used in contrib also (Webform and Media Gallery are a couple examples of modules that do this for their nodes).

custom blocks, I agree, could be implemented as their own entity type, as those are content. They're distinct from a node, I believe, as nodes are "primary site content" ..... custom blocks are "secondary content".

I think the big issue here is that many people do not see this distinction between primary and secondary content clearly at all. There are an awful lot of pages out there where it's not obvious what (if anything) is the primary content. Also, things that are "secondary" when displayed on one page could very well have a use case for being "primary" when displayed on a different page. Some of the sites/mockups @webchick mentioned in earlier comments here are good examples of that.

Webchick: OK, so to be clear, you just suggested building a single standard "entity view" page callback (or rather, displayable block) that applies for every entity type, and conditionally enabling it in the menu/router system. That would, by extension, allow a site admin to disable the very existence of user/X pages and node/X pages. Or, maybe, do so per-bundle. And potentially greatly increase the number of node_load() operations per page (which are non-cheap, especially with per-field sql storage).

There may be something there, honestly. But let's be clear about what we're suggesting. :-)

Similarly, it means that a custom block would show up in search results as its own "thing". Yet it wouldn't have a corresponding page to link to. So what would the search system do with it?

http://groups.drupal.org/node/199938 is the design thread: has the latest user stories for how to let people put stuff on pages.

http://drupal.org/node/430886#comment-5442598 and onward is the latest on the code architecture challenges.

Go check them out :)

Similarly, it means that a custom block would show up in search results as its own "thing". Yet it wouldn't have a corresponding page to link to. So what would the search system do with it?

Right, if we had an "is it primary content" setting, we'd have to always link that setting to the search settings, which would get complicated. Even worse, what would happen on the admin/content page?

I don't see why we need that setting for this issue at all, actually. So what if Drupal creates a URL for every piece of content, even things you don't care about having a URL for? URLs are free, and there are an infinite number of them :) If you don't need it for your site, you just don't link to it from anywhere.

This already happens all the time with nodes in my experience (if you have a type of content that is only intended to appear in a View, the full page version of it might not make sense, so you just don't link to it). Not to mention taxonomy terms, where the full page view is used even less frequently.

Also, in #430886-167: Make all blocks fieldable entities, @DjebbZ pointed out that for web services purposes it is very useful for each piece of content to have a URL associated with it.

I disagree that "meh, extra URLs don't hurt" is a convincing argument. It's true up to a point, certainly. I've never known of a site that breaks badly as a result of having "image nodes" public.

That said, as long as we're refactoring these systems, do you really want every feed node to show up in Google? Google will find it. :-) I'm working on a project right now where I'll be generating probably hundreds of feed nodes. I don't really want those in a site search, or Google search, or to have to think about theming it lest someone stumble across that page and see a broken page, etc.

OK, for nodes that's not as big an issue. But do we want to mandate that every single Commerce product sku have its own page? Should core really hard code that assumption?

That seems like a huge step backward to me, especially at a time when Eaton's snowman initiative is trying to make even the default node and taxonomy listing pages removable (as they should be).

The framework parts of Drupal should not mandate the existence of application-level pages.

Addendum: Everything I just said applies to web services, too. Just because a data object exists doesn't mean I *want* it to be available in JSON format to everyone with "access content" permission. That's a terrible assumption to hard code into the core system. It should be easy to set that up if I want, but it should not be required.

> Right, if we had an "is it primary content" setting, we'd have to always link that setting to the search settings, which would get complicated. Even worse, what would happen on the admin/content page?

Make it a node table flag, analogous to 'status'.

For brownie points, have a concept of 'viewable path', which would mean that in admin/content, the block-ish node for 'product page landing header text' would know that to 'see' it you need to go to '/products'. Eh that's probably crack though -- I don't know, I'm bunged up with cold today :(

To clarify, I'm not saying that it's a bad idea to get rid of the behavior that all nodes are forced to be accessible at node/X... just that I don't see it as a requirement for this issue.

In other words, forcing custom-blocks-as-nodes to have a URL (compared to the current situation where custom blocks are forced not to have a URL) doesn't seem like a regression that matters too much, and in some cases it wouldn't even be considered a regression. Compare that to forcing them to appear in search results (discussed above), which would be a lot worse and therefore would need to be fixed here.

Thanks David_Rothstein for pointing me here. Very interesting discussion.

I see good points in many suggestions. Can I add my own ? Yes I can :)

Differentiating primary content and secondary content is a mistake IMO. When you write in the admin UI, you write content. You only care about the content type : page, article, event, product, etc. Some of them are meant to have their their own node/123 page, some are meant to be used by Views or other modules. This is the result of the UMN study and it totally make sense to me. To translate this to Drupal words, we need, as webchick said, a "Content" entity that can encompass functionality of both blocks and nodes.

Many here have pointed the differences and similarities between them. We want content stored as entity, because entity should be our unique way of representing common content (text with links and images blablabla) in Drupal. We want content to be fieldable. To support revision. Free integration with all core systems, and contrib like Rules and Views, and many others. We don't want all of them to have comments. To have a public URL (more on this later). To appear in search results. To be reachable by web services in JSON or any other format. To have menu settings. Or promotion to front page.

I may not be exact or reach consensus about what's different or not between nodes and blocks. Let's make this list exhaustive and accurate. Then, make everything that don't have to be here, an option at the content-type level. Don't want this content to appear in search result ? Untick a checkbox. Want public URLs ? Tick the corresponding box. And so on. If the underlying code and architecture is designed properly, it means less code to load for unticked options, and less database queries (or less complex ones, with less joins). For instance, no public URL means no need to use the various path tables.

What if one want to display a node in its own page, but a "teaser" version in a sidebar ? Build modes fit very well, as they're just display configuration of the same data.

This would solve IMO the usability AND developer problem about "blocks as secondary content". Just leave nodes for what they're good at : allowing user to create types of content, add fields, and WYSIWYG their content.

Then, as Crell suggested, use "blocks" (or whatever name we give them) as plugins for displaying content in sidebar or other regions, with visibility settings.

This could use an issue summary to get it going again. Maybe that will help move the discussion here towards a resolution so we can begin to implement a fix.

Although to a large extent, I think the debate boils down to only this: "Do we think there is a significant, meaningful distinction between 'primary' and 'secondary' content"?

1. If there isn't (if there is enough of a gray area between them) then it makes sense to have one type of entity used for both, as I and several others have been proposing.
2. If there is (and if the distinction between custom blocks and nodes makes sense to preserve), then we need to come up with some other kind of solution to this usability problem.

updating issue queue

I read this issue before, but I did not expect I would run into a related problem :). See #1686124: Block language settings not respected: it turned out I cannot make my blocks restricted to certain content languages only, unless and until I enable the UI language detection and selection. OK, blocks, including custom ones, are part of structure, but now I have to remember that it means they are part of the user interface! This is not that logical in my view :).

Moving this to task, some of the solutions here might be a feature request - but the problem identified is not a feature request. Moving this to normal, purely for threshold reasons, the actual usability criticality would still be major bordering critical.

If it's major, it should be major :) And since it's a basic site building task which people in usability testing couldn't complete without lots of help, I think it is.

At this point, it's too late to remove the concept of custom blocks from Drupal 8 core. Which is nice, because essentially most of the issues people raised in the above comments were about that :)

But it should still be possible to allow nodes to expose their content as blocks, so that someone creating "content" and then later making a decision about whether it should appear in a sidebar can still choose to expose it there. And that is the main goal anyway. If we keep custom blocks around, then there will just be more than one way to do similar things. (And those "in the know" who don't want URLs, appearances in search results, or other things that come along with nodes can just go ahead and continue using custom blocks.)

As far as I can see, that's the main proposal on the table here. I think there was a counter-proposal involving a more general "Add" screen where you could choose between nodes and blocks from there. To me that seems like a lot of choices (and I expect people will often choose wrong). Though I'll also point out it's not really at odds with the above proposal, so if it seems like a good idea, it would in fact be possible to do both.

I think this will be handled by #1920862: Rename custom_block.module to block_content.module

Unless I'm missing something, that issue is just a straight rename. This is about a functional usability issue.

+1 for moving the custom blocks library as a tab "blocks" to the /admin/content tabs (between Content and Files). Much better usability and - not coincidentally - the way it already works when you use the bean module.

Updated issue summary as suggested. I hope this will be helpful without throttling ideas!

Moving to the correct component.

Just unassigning issues that haven't been developed for a bit in the D8 queue.

There is coming to be less and less that intrinsically distinguishes nodes from blocks. Treating them as distinct concepts rather than as display options of the single concept of "content" doubtless adds complexity to our codebase as well as confusion to the user experience. Imagine if we had the same flexibility with content that we have with Views to arbitrarily add page or block displays. That would eliminate so many special case scenarios for editorial workflow and revisioning, access control, etc.

#2862564: Move Custom block library to Content looks like a duplicate or is quite similar.

Believe this will be covered in #3318110: [meta] Reorganize Block items in the administration menu but postponing until then.

Most of the issues from the meta were resolved. More importantly moving custom block library to under content and renaming to just block content.

If still more to be done please reopen.