- πͺπΈSpain penyaskito Seville π, Spain πͺπΈ, UTC+2 πͺπΊ
Found this while working on the dashboard initiative, where we face a similar problem (#3351705).
So hopefully in the future the scenarios that need to be solvable are:
1. Editing the layout for a given content type.
2. Editing the layout for a specific entity.
3. Editing the layout for a dashboard.We considered creating our own block specialization, so we could define specific plugin blocks that are designed specificly for a dashboard. But at the end we should expect people to create views blocks, or reuse their blocks for the dashboards. So that specialization is not the first option, at least for now.
If dashboards get traction, I'd expect more blocks being added to core/contrib/custom with the dashboard in mind, which might make this experience of editing the layout for a given content type or an specific entity even worse.
- π¬π§United Kingdom catch
A major problem here is #3043330-95: Reduce the number of field blocks created for entities (possibly to zero) β .
- πΊπΈUnited States robbt
I looked at this at the DrupalCon usability review event and I don't think there has been an agreed upon solution even if everyone recognizes that this is a usability issue with Layout Builder.
My suggestion would be to differentiate between Content Fields and Content Metadata Fields
This seems like a cleaner distinction than hiding certain fields under "More" which was rejected as a solution.
I think if we differentiated them into Content Fields and Content Metadata Fields
Content Fields
Body
Image
Title
Content Metadata Fields
Authored by
Authored on
Changed
Comments
Comments
Content type
Default revision
Default translation
ID
Language
Links
Menu link
Promoted to front page
Published
Revision create time
Revision ID
Revision log message
Revision translation affected
Revision user
Sticky at top of lists
TagsMaybe Tags and Comments and Links could be considered Content fields vs. Metadata but certainly most of these aren't typical things that someone would want add to a layout display and so hiding them would reduce cognitive load and overwhelm that was identified by testing.
- π¬π§United Kingdom catch
I think we're are very close to an agreed solution to reduce the sheer number of blocks in β¨ Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points Active . Once that issue is done, there could still end up being lots of blocks to choose from but it would be from a much lower starting point.