Closed rlnorthcutt closed 4 years ago
I'm curious what @balsama thinks about this. If it was successful it'd likely be requested to be added to Lightning. Would we want to curb that and get them involved now instead? Would there be an overlap with existing tools like the "Text" block? We determined already that our "Basic Block" from DF 3.x was redundant to the "Text" block.
👋 Yeah, as @rlnorthcutt says, the LB UX initiative identified this. And DAT is working on those items this quarter.
It's not 100% clear what things are on the plate for this quarter, what their priorities are, and (related) which will actually get done.
But "add primitive block types" is definitely in the DAT backlog. I agree it makes sense to work on it there to avoid the duplication and possible conflicts @brantwynn points out.
Ok. Well, lets keep moving along here like normal, and when we are looking at actively working on this issue we can check with DAT to see what their status is. Additionally, @webchick knows about this.
Either DAT gets to it first and we inherit it, or we get to it first and can provide a solution they can adopt/alter as needed. Appreciate the cross team communication 😃
During the UX research and Cohesion workshop, we identified this as a poor approach for content creators. If SAs need to add something like this, they can use the custom text/html block as needed.
The LB UX initiative has identified that we might want to support "primitive" components like Adobe and others do (headings, block quotes, etc). While that is not the ideal way to build all content, it would be really handy when trying to "flesh out" a page.
I think we should create a new block type ("Element"?) that gives us some of this functionality:
This is kind of like how we can choose the element/style of a field in Views. This also means that I can add "elements" to a page without adding multiple block types... and it is limited to the elements we want to support.