Patch sandbox

Problem/Motivation

This is a followup issue for #1535868: Convert all blocks into plugins. The patch in that issue will be committed with a very rough UI, and we intend to iterate on that UI in the Blocks and Layouts initiative. However, if some of the goals of the Blocks and Layouts initiative are not met by the end of the feature completion phase on February 18, there are still numerous issues with the UI that need to be fixed.

Proposed resolution

The Invision prototype is slightly outdated in terms of visual design. The interaction flow is largely accurate to that agreed upon at DrupalCon Portland. The updated visual styling can be found in the issue #2014191: Implement the block-by-theme listing page.

Remaining tasks

In general, tag issues related to the current UI If SCOTCH fails, and unpostpone them on Feb. 18 2013 if they are not resolved, or close them if they are no longer relevant.

Design tasks related to specific forms and interactions

The following list of forms and displays enumerate the components of an acceptable minimal viable product for the Blocks user interface. Design assets should be link from the list item that they relate to. Sub tasks may be associated with the component list item as well.

Comments

I'm unpostponing this... while I'm aware of a number of sub-issues that are trying to attack bits of this problem, I'm not aware of a single place to discuss the overall solution/spec. I'm also not aware of any significant proposals out there to make the ability to add blocks from the library any better. And it's certainly a critical, release-blocking task to get this UI into shape; the current UI is a huge regression from the D7 block UI and that's really saying something. :D

@Dries Thanks for leaving this critical, I agree that we still have much to solve - sadly its an effect of us pushing forth with the assumption that we would solve the UI later on, however that's where we ended up - with little of those original design concepts made by the UX-Team and Spark in core :(

I love how everyone just blazes over "Add block", its quite a drastic behavior change that you go there now to do all "add block" actions. I don't think we can make this a dropbutton, after all there can be dozens of options under this - and that would actually be a common usecase. We should figure out a way to provide a "smart default", so that these custom blocks types are added to the list of available blocks to add, Dries is totally right that requiring a second step to do this would be odd (I dont even get why "Add custom block" is elevated, shouldn't it just be an option in that list?)

Just an idea, why isn't block types not just a tab of blocks? I guess content types, is the odd one in the crowd - but I remember we do that in loads of other fieldable things too? Perhaps that should become the standard?

Improved Block page

I think this needs some more system level thinking. I'd just as well understand "Block types" as "Search block", "Menu display block", "Views block", etc. None of these are managed in the "block types" system, that is only for managing custom block types and custom blocks are just one type of block :) Creating those custom block types is probably even less of a common operation though then managing content types.

So I think it would be great if we could figure out an integrated experience where we could ease people into:

- the blocks you see on the page are block instances
- you can configure these instances or create new instances by configuring "block templates"
- there are fixed structure/behavior block templates that are provided by modules and you can create custom block templates with custom block types
- then you can use those custom block types as any other template by instantiating them as block instances for display

I think a major problem right now is that both block templates and block instances are called blocks, while what the flow actually does is it offers you block templates that can be configured to become blocks for placement and you can expand the templates by creating custom block types.

Block template. Interesting idea. So maybe we have a default block template -- title and body -- that is used whenever I click "Add block". I'm automatically creating an instance of it and there's really no indication in the UI of this magic under the hood. The 80% use case is probably that I want to dump some HTML on the page and I use a block to do that.

So we have 3 flows

Add a block, just use the default template

Add a block, let me choose from existing block instances to reuse one

Add a block, create a new template, then create an instance of that template in the same flow

Flow #1 should be the flow I'm taken through with the most obvious, biggest buttons.
Flow #2 should be an recognizable alternate flow from flow #1, but presented as a non-primary option
Flow #3 should be deemphasized to the point of being a little hidden. We don't want block templates to flourish in a 1-to-1 relationship to block instances.

@jessebeach I am not sure I follow, the 80% usecase isn't adding a block with custom HTML? It's adding a block like a view, or a block exposed by a module like menu, site elements, etc? To me actually adding a block with custom HTML is only a small usecase? I imagine the actual common workflow will be 3) new one, 2) existing one 1) custom block?

Thinking of recent sites and training I've done for editors, the sorts of things they'd like to add and place through this interface include:

1. a branded image/text call to action to the sidebar of my page/content type/section
2. a curated list of related content to the sidebar of my page
3. homepage block content, consisting of titles, body content and images
4. an advert to all inner pages
5. a tracking code to all pages
6. a secondary menu to all inner pages
7. a table of events sorted by created date on a section page or content page

Thoughts:
1. custom blocks are content and so should have a listing at admin/content/block
2. custom blocks are content and so should appear at node/add (this should be renamed)
3. views blocks should be able to be created through this interface (eg add block -> add views block)
4. menu blocks should should be able to be created through this interface (eg add block -> add menu block)

This means there should somewhere be an page that, similar to the current node/add, is a place where all content can be added - eg content/add. This should combine the current node/add, block/add, and also include other types of blocks that can be added - eg not limited to but including menu blocks and views blocks.

The first is much like the existing Blocks admin path. The active tab is the Bartik theme tab. The content of the form is a table of regions and blocks in those regions.

The second depicts a new secondary tab on the Blocks admin path. The tab is labeled "Block list" and it contains a list of all the block instances in the system. The primary button at the top of the page is labeled "Add block". Adding a block creates a new block instance from one of the block templates. Out of the box, the only block template is the Basic block.

The third depicts another new secondary tab on the Blocks admin path. The tab is labeled "Block templates" and it contains a list of all the block templates in the system. The primary button at the top of the page is labeled "Add block template".

What I'm trying to do in these mockups is tease apart of the flows of block creation and block placement. Currently, we conflate these two flows.

The Balsamic mockup files are included in a zip if anyone wants to iterate on them.

I am wondering "A list of all blocks. Not the instances, but the blocks themselves." - what is the use of this page, I imagine the 80% case is just placing it in a theme. You cant do anything with the blocks themselves right? So the only real case where you use blocks is in blocks placement, so perhaps the top level "Blocks" is not needed.

Editing a block on the placement page would present a challenge, because one would be editing the prototype of the block in the context of an instance. There would be two choices then, configure the instance or edit the block.

I really think we need a list of blocks, perhaps with a table column that lists that block's placed instances, so an admin, who might choose to edit a block, will know that that block drives N instances.

Custom block instances already have a "Edit" and a "Configure block" actions separately, where you can use Edit to edit the block content entity used to provide the content and configure where you can edit the block config entity used to provide placement and titling. Same applies for menu blocks for example, you have an "Edit menu" and a "Configure block". I guess it makes more sense to be separate for menus, because people assume the menu comes from somewhere else, while the custom block is already a block...

I personally like the blocks and layouts separation for block instance creation and placement. I'm a bit confused by the block types screen for adding blocks:

What is the limit for what is a block type and what is not?! I mean the current "Add block" (AKA block library) screen has numerous blocks and many of them are configurable. Would this now group those blocks based on some higher level "type", like "menu" and "views", instead of listing each menu block and each views block?

From the blocks screen I find it odd that you go into the place action and land on a "Configure..." page. Also if I come from the layout page it says configure not place, goes to the same thing.

On the configure screen, I find it odd that you have a local settings area, but visibility would also be local settings, no? Also, you have a summary of global settings, but what does that display? What would that display for a menu block or a view block? All the filters and display types used in the view? What if the body if full HTML (a JS tracking code or analytics widget)?

While this side view of the underlying object is interesting, we don't see this elsewhere. Eg. entity reference module is in core, and that does not provide a side-view of the referenced entity. Maybe image module comes closer which displays a small thumbnail if possible I think. In other words, if we can make this a pattern that works for us elsewhere, that would be good. Otherwise it looks pretty out of place to me :/

Also relatively minor, but we found previously that a checkbox that you check to *remove* something is not a good pattern. Eg. in the usability testing for multilingual, the "Hide language selector" checkbox people usually understood as "Show language selector" and they checked it to show, when it meant the opposite. Doing a positive operation to check the checkbox to hide the title seems odd. In #1875260: Make the block title required and allow it to be hidden we are working with adding a positively worded checkbox too.

What is the limit for what is a block type and what is not?! I mean the current "Add block" (AKA block library) screen has numerous blocks and many of them are configurable.

This *only* shows links to modules where a user action creates a block, menus and views are the only ones in core I know of. I guess there is an implication here that if a module developer has a user defined block then now need to specify that it shows up here. The advantage of this for the user is that it gives them a central location where they can create any type of block whereas the current system is fractured and extremely confusing.
The distinction between "Block types" (which we might call "Module block types") and "Custom block types" is that the user can "customize" custom block types by adding fields, whereas they cannot customize module generated blocks.

Would this now group those blocks based on some higher level "type", like "menu" and "views", instead of listing each menu block and each views block?

No, they will only be filtered as they now are. The "menu" and "view" links here simply jump the user to menus and views UI.

From the blocks screen I find it odd that you go into the place action and land on a "Configure..." page. Also if I come from the layout page it says configure not place, goes to the same thing.

That is a good point, I'm not sure how to fix it though since the same form is used for placing and configuring, and configuring a local instance after it has been placed. Any ideas?

Also, you have a summary of global settings, but what does that display? What would that display for a menu block or a view block?

Yes, I see that there could be scalability issues. Maybe we keep it collapsed by default so it doesn't create too much distraction.

What if the body if full HTML (a JS tracking code or analytics widget)?

Interesting you say this. Angie actually suggested a live preview which might answer that question. Perhaps there's a middle ground where we display what wysiwyg would show (but not editable)

Maybe image module comes closer which displays a small thumbnail if possible I think. In other words, if we can make this a pattern that works for us elsewhere, that would be good. Otherwise it looks pretty out of place to me :/

I agree that this should be something that can be extended. I can see value in many other places, notably fields, where a similar global/local pattern is equally confusing to site builders.

Also relatively minor, but we found previously that a checkbox that you check to *remove* something is not a good pattern.

Good point, changing to positive "Display for site visitors" with checkbox checked by default. Also I think I need to add description "Changes will not affect the block name" since the title will initially copy the name but title changes will not flow upstream.

On the configure screen, I find it odd that you have a local settings area, but visibility would also be local settings, no?

This *only* shows links to modules where a user action creates a block, menus and views are the only ones in core I know of. I guess there is an implication here that if a module developer has a user defined block then now need to specify that it shows up here. The advantage of this for the user is that it gives them a central location where they can create any type of block whereas the current system is fractured and extremely confusing.

So Menu and Views means here that you'd be directed out to create a menu or view. Core also exposes blocks from aggregator categories (and maybe feeds?) for example, but apart from that I'm not sure there are other places where you can create things that automatically become blocks. But then Views can be used to create anything (even flat "menus"). I'm afraid of this because we send out the user to create a menu (or even worse a view), and then we don't know when if they ever will come back. Creating a view with a block is not necessarily trivial. You need to add a block display, configure, etc. It might be an hour or more before you have that block you wanted to create and then you can place it. But by that time where you came from is pretty much lost.

From the blocks screen I find it odd that you go into the place action and land on a "Configure..." page. Also if I come from the layout page it says configure not place, goes to the same thing.

That is a good point, I'm not sure how to fix it though since the same form is used for placing and configuring, and configuring a local instance after it has been placed. Any ideas?

Well, theoretically we can expose the same form under different paths with different titles, but that might not be a great solution. Not sure that would make it easier to understand how things work. Also it would possibly expose multiple contextual actions on blocks, etc.

What if the body if full HTML (a JS tracking code or analytics widget)?

Interesting you say this. Angie actually suggested a live preview which might answer that question. Perhaps there's a middle ground where we display what wysiwyg would show (but not editable)

Yeah whether a live preview works or not depends on what was in the block. It is probably a common use case to put in google analytics kind of tracking code, and live previewing that will not display anything (it will be odd to the user that they forgot to configure it?!), but then most other blocks actually display something useful that would be fun to see previewed. Then some blocks depend on context, eg. the node author block in core displays the author for the node on the page. There will be no node on the admin page, so no useful preview. This can be a can of worms.

Polished up many of the ineractions here post some discussion with rest of Spark team, Dries and xjm. Still need to add a tertiary level of filtering to blocks page (feeds/categories etc.) and take a stab at solving the preview issue.

Still getting my head around this and I've left some comments for Kevin in the invision prototype. the prototype is a definite improvement over what I saw last week (particularly the IA)

Few things

1. Block page description says "A block is a container for any type of content that can be..." could that be simplified as "A block is content that can be..."? I got pretty confused figuring our the difference between a Block type and Block instance, at first.

2. How would I know to reuse blocks in the Blocks page (it seems a lot clearer in the Layout) "Add Block" is such a prominent call to action that it seems like it's going to be common for folks to create new ones rather than reuse them.

3. I like that after I create a block I'm able to place it right away but I'd expect some sort of warning or prompt to say that is what's going on.

We should continue to iterate on the design, but I'm postponing development work, at least for myself, pending changes to the plugin/block architecture in relation to themes. I'm having a really hard time grokking the current architecture and I just can't seem to make headway. EclipseGC mentions that there are improvements in the pipeline, so I'd rather wait for those before putting more effort in here.

I'm not used to this kind of tools and I'm confused how I can use them in a sane way. For example whats the best way to navigate through these screens. I tried with the arrow keys but the numeric order seems not the way to go. The amount of "non core" visual elements in this proposal makes it hard to review. It would be easier if we could start from a look that matches seven a bit more. I'm a bit overwhelmed will all the visual goodies.

Next week we are going to discuss this at our drupal UX weekend. I'll let them review your proposal. And maybe we are going to create our own wireframes.

@aspilicious Try clicking through the linked screens (as andypost says, the shift key will reveal the linked 'hotspots') and take it in. Then, add comments, replying to existing comments if they're relevant, or creating new ones. To enable comments, hit the c key (or there's a on/off toggle in the lower right). Note that this prototype probably wont' be around forever so if you have anything you want preserved in the history of Drupal, add it to the issue queue, but generally it's easier to understand feedback when they're in context, so that's why Invision is so useful.

The amount of "non core" visual elements in this proposal makes it hard to review. It would be easier if we could start from a look that matches seven a bit more. I'm a bit overwhelmed will all the visual goodies.

This is really great feedback actually, and something I've struggled with for this and other prototypes. I have difficulty in my head "seeing" these prototypes as part of core for the same reason. However, I'd also say that the goal isn't to make core look exactly like this, but to explain the big picture of how the workflow might work.

It's important to understand that there's no code here. What you see is just big jpegs strung together with image map links.

Not every interaction is linked. In fact the flow is pretty linear because every fork introduces another set of images that need to be maintained (there are already more than 60 in this prototype for instance).

To navigate through the interaction, periodically press the shift key to highlight what links/buttons can be followed.

Also there are no hover effects or js interactions (remember it's just images)

Just to clarify the "layouts", because in D8 there are multiple layouts there can be no single "blocks UI", what you get instead is a blocks UI for each layout, which ultimately aught to display an abstraction of the layout, not a table. That's why the UI is called "layout".
Additionaly I am proposing that we alter the markup of the blocks (now layout) Ui from table to divs so that when contrib want's to build a solution for creating the "layout abstraction" all they will need to do is apply new classes to the divs.

The amount of "non core" visual elements in this proposal makes it hard to review. It would be easier if we could start from a look that matches seven a bit more. I'm a bit overwhelmed will all the visual goodies.

Hm well, while I understand that the approach requires more mental energy here's a few things to consider:

The design is for D8, not D7 and many things have already changed there including toolbar and contextual links

The design is not speculative, it maps directly to Ember admin theme which has a D7 and D8 branch

I *could* map the prototypes directly to the new seven style guide but that is so different from current seven that it would be equally as disconcerting.

If I were to take the above approach it would require re-creating literally thousands of individual vector image files (assuming I do this to all of my prototypes (including blocks, layouts, breakpoints, toolbar, responsive preview, wysiwyg, field UI, Dashboard, content creation, Menus, overlay, Views, etc.).

Ultimately the reason I keep putting in the "visual goodies" is in the hopes that the more people see them the more they will be inspired to actually make them a reality :)

That's a good point. In the past Angie has asked if I could call out elements of the designs that are part of the "northstar" or ideal vision of the UI. I can do something similar with theme elements from Ember that diverge from Seven. Going forward there will be fewer of these since ry5n's work and mine are actually converging and borrowing elements from one another.

I have some nits in that when making a block, it has a 'title' (which is clearer to me than description), but later in other screens it is referred to as a 'name'.
Let just make sure if we are going to call it a block name that we use name everywhere
and if we are going to call it a placement title, we call it title everywhere.

I didn't yet see if I could test out the deleting stuff.

What are the next steps here? do we have to get a sign off on the layouts idea and the use of the placement wording?
Is someone already coding up some patch to test?

@YesCT What this needs is a holistic approach to solving this problem, because as it stands - using the iterative method of opening loads and loads of issues will not do much. We need to know how we are going to fix it, and so far I have not seen the solution even in #47. For example, how do we deal with derivatives, several themes, what is the correct workflow - just labeling changes wont fix that.

@YesCT What this needs is a holistic approach to solving this problem, because as it stands - using the iterative method of opening loads and loads of issues will not do much. We need to know how we are going to fix it, and so far I have not seen the solution even in #47. For example, how do we deal with derivatives, several themes, what is the correct workflow - just labeling changes wont fix that.

snugug, sdboyer, xjm, effulgentsia, eclipsegc, jessebeach and myself spent significant time in Portland talking and sketching this out. Here is the resulting design prototype for a minimally viable solution. http://invis.io/6AESEWGY

Again, press shift key in invision to see clickable areas and remember that this is just a series of static images and there's no code.

Also apologies for this being in Ember theme and not Seven, in the interest of speed I built it from existing fireworks files. For fonts colors icons etc. refer to seventy_eight https://drupal.org/sandbox/ry5n/1932040

@tkoleary: there are no visual states for the filter. Would that filter items under each category (thereby making some categories possibly empty?). Would it filter category names only? How should that work?

Yes, I think that's the right approach. We need to add back an "all" button to the right of the filter autocomplete so the user can restore them though.

Discussed with Bojhan earlier today. I passed the design file to him and he's revising to add Seven theme styling. Custom blocks will have their own category (Bojhan is also mapping out all of the categories).

We also discussed a "New" category which would always be at the top and contain any newly created blocks. This would be cleared after a period of time or on a form submit of the blocks page.

There are a few things in the prototype that are not clear or outside the MVP (based on our discussion in Portland):

The filter and accordion should work exactly like the modules page filter does, matching individual block names and hiding empty categories.

The "Add category" functionality isn't part of the minimum we need to do. To start, we agreed that the categories would just be per block plugin (so that some categories would have only one item, but most block derivatives would be grouped by their plugin, e.g. menus, views, etc.). Block categorization is a separate problem and something we can solve later.

We talked about drag-and-drop or click-and-place for the block pills, but as we talked through it, we realized that it was actually a pretty complicated problem to solve in terms of what fields should be set through the main blocks page vs. inherited as defaults. There are also some dependencies. So, for the MVP, clicking a pill should open the block instance configuration form. Later, we can explore other options (like a modal rather than a separate page, or inline setting of the title and region, or etc.)

Drag-and-drop can also be added after the initial patch if desired.

So, the most important next step is to create the left-side "Place block" browser, grouped by block plugin, and get rid of the separate form for that part. We can iterate from there to improve the UX further.

"for the MVP, clicking a pill should open the block instance configuration form. Later, we can explore other options (like a modal rather than a separate page, or inline setting of the title and region, or etc.)"

That's right. I have that in my design, but it didn't get updated properly in the prototype. Fixing now.

Agree on add category.

IMO drag/drop may not be necessary at all. Esp since drop would trigger a modal which is strange.

One thing that worried me about the invision prototype is that it didn't fit on my laptop screen :) My version explores using modals for browsing the list of blocks. Fun to see we had the same idea of applying the modules page pattern for how each block is listed within it's region.

@yoroy: that looks in some ways similar to the current MVP suggestion but in many more ways similar to tkoleary's prior suggestions where the list of blocks and placement of blocks to layouts were separate things. Depending on how we consider this, solving the UI problem may be needed in 3.5 weeks, given eg. @xjm's note above of classes to remove and rework. Those would definitely be considerable API changes. So one of our major goals with the design was to limit it to the minimum needed to make sense of the current multi-level system and be possible to implement in the remaining 3.5 weeks.

Can we please not use the label MVP here. I think if you ask any user this is not MVP, it is not within what they would consider the minimally viable/desirable product. They expect a whole lot more, I think the term we ought to use here is UCLWI (Users can live with it). MVP also implies its a first stab, it is not its the final design proposal before release.

@yoroy has a good point that @tkoleary his design depends on a very wide screen. As I started putting this into the new core styling, I found this too - it also doesn't scale very nicely to longer block titles. Having a separate button, with a modal does allow for far greater surface area but still keeps it in context. I am not sure, @tkoleary could you provide some feedback.

Yeah I was not aware of the full set of acronyms I could use. I could also have said UAWSCSPBAF (user acceptable with a set of changes still possible before API freeze). That maybe highlights the set of constraints I am looking at. If we are to move (back) to a modal, how would that be different from how it works now? What kind of improvements would it offer then?

@Gábor That is the question, ideally the browsing of blocks is done in line as designed by Kevin - but its also a little tricky with the additional information in the table that there is space for this. The real trick is trying to keep it as close to the context as possible, the modal is a slight departure but not as big of an departe as the current interaction. This would probably be UAWSCSPBAF. But I would like Kevin's feedback before doing anything here.

My view is that the drawer is a big improvement to both the usability and the scalability of this UI.

I think the issue that Bojhan raises can be handled with a few small changes to the interaction pattern:

The user opens the drawer to place a block and the block table drops columns (if needed)

Focus anywhere outside the drawer automatically collapses it

Placing a block automatically collapses the drawer

BTW

MVP: A Minimum Viable Product has just those features that allow the product to be deployed, and no more. (See wikipedia: http://en.wikipedia.org/wiki/Minimum_viable_product). IMHO this is actually quita a bit *more* than an MVP but it covers our purpose which is "Ensure that the Blocks UI in D8 is at least as usable as the one in D7"

i'm not sure i like "Block Description" as a column name, though. as far as i can think, the only reason we'd use that term is because the custom block interface decided to call the corresponding field "description". but custom blocks are an aberration, the exception and not the norm, and we're in trouble if we let them dictate the rest of the blocks interface. that data is populated from an annotation property named 'admin_label'. i'm VERY fine with not calling it that, but 'description' just isn't accurate for pretty much everything other than custom blocks. @YesCT pointed out in #61 that 'name' is used elsewhere - that's also got flaws, but i think it's better. plus, it's consistent.