Blocks overview pages lacks context, overwhelms new users

sub

Guiding principle:

We're working towards a 'component library' to offer a more unified model of how to handle and configure all the items that live on your page:

Couple of things at play here that we'll have to design and build for:
- blocks page does not look like how it will be used: lacking the live preview ux
- how do you find, configure and create new components?
- how do you add them to a page.

Initial post of the issue is sparse, we either use this one to track the meta 'redesign the pages + blocks" discussion or fine-tune the problem definition :)

Huh. Components. Now there's a potentially good name for blocks. probably not as non-techincal as "boxes though, but I digress.

Drag-and-drop is a great idea, but has lots of problems. It's easy with wordpress, since there's almost universally just one side-bar. With drupal, there's bajillions of regions, and on any table-less design, there's no way of knowing where the side-bar is. This makes the wordpress method (drag-and-drop in a site layout analogue) difficult.

Actual live previewing would be very cool, but there's so many potential problems, like some blocks have no content except on specific pages. Blocks like that would need some kind of dummy content.

Definitely like yoroy's diagram 2 - having all content and content lists in two block types (single item, views) would be very cool. I wish that feeds did that already...

If we mark the regions as "first sidebar" and all.. then as soon as the user visits the blocks page he will know what blocks mean.

Related issue: #1164712: Users expect to preview blocks before saving changes

Regarding drag and drop and live preview, we do basically already have that on the Dashboard (and it already does deal with the "dummy content" issue in some ways; I believe it renders it with "(empty)" as the block content).

@2, I think you need to add context to the list of things to design and build for - since we will have context in core in D8 this would be prudent to design for - e.g. you can't really have a live preview without knowing what the context is. This rather depends on the approach you are outlining here - are you saying blocks have their context set as they do now (per block, on the actual block config form) or do blocks inherit their context from the "page" - in which case this becomes a page builder that you add components to.

#6: correct, context is missing there. I actually have a short screencast that extends this diagram to the question about where the *page* context could be administrered:

http://www.youtube.com/watch?v=7VOkLzD3yDs

(And context lives in each component as well, so we'd need to accomodate for tweaking it on component level as well. Any UI we dream up here almost immediately pushes beyond what core can do though. Need to focus on 'make possible' first, 'implement' second.)

Major changes along these lines are in progress at http://drupal.org/sandbox/eclipsegc/1441840

Is there a Drupal core issue associated with that sandbox? If not, there is nothing to mark this as a duplicate of.

I would say this issue might actually be a good one to use as a meta-issue for that, given the designs already posted/discussed above (although I guess there's been more work on designs since those were posted).

Hi David, thanks for your input on the issues I updated yesterday. I got carried away with closing old issues and you're right that an issue can't be a duplicate until there's another core issue that more specifically matches the concerns addressed. I'll revisit these when Blocks Everywhere is further along.

No problem! I didn't mean to pick on you there by the way.. just when I noticed a couple of them I decided to look at all of them :)

I agree it's possible some of them could be closed eventually, but yes, it's too early for that now.

Marking a duplicate of #2055853: [meta] Improve the place block UX; Separate interaction from the create block UX; Improve the existing blocks-by-theme layout, if I've missed something feel free to re-open.