Patch sandbox

#2058321-36: Move the 'place block' UI into the block listing
Sandbox on simplytest.me

#2062439-33: Provide listing of custom block entities
Sandbox on simplytest.me

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

See the task list below.

Invision prototype: https://projects.invisionapp.com/share/PEGD21X4#/screens/

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.

Issues tagged If SCOTCH fails.

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.

Infrastructure tasks

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

Status: Postponed » Active

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

Will start linking sub-issues I know about in a sec.

kattekrab’s picture

EDIT: Aaah - soo apparently I can't submit ANY forms at all. Looking into that now. But it's probably not related to this issue. Sorry :/

Just failed to add a block. Possibly I missed something though - so happy to be given some clues before having another go at this.

Here's a screencast. http://www.screenr.com/XyK7
Unfortunately sound didn't work, so you miss out on my inane commentary.

But here's what I did.

Go to structure
Go to blocks
Click on +Block Library button
Click on +Add custom block button
Fill in form, select region, SAVE

No info message

Go to block listing
Can't see new block.

Did I miss something?

xjm’s picture

Issue tags: +Block plugins
meba’s picture

FileSize
154.52 KB
103.04 KB

Image one:
D8
Image two:
D8

Dries’s picture

I tried a recent version of this patch. Here is what I found.

custom-block-types-or-block-types.jpg

adding-a-new-block.jpg

So I created a new block type called 'Quote', using the newly added datetime module (yay!). Here is what it looks likes (doesn't really matter for the rest of this comment):

quote-block-type.jpg

But when I want to create a new instance of my quote block, I couldn't figure out where to go. Eventually I figured it out, but it wasn't intuitive at all.

add-custom-block.jpg

add-custom-block-2.jpg

Dries’s picture

I'm going to commit #1871772: Convert custom blocks to content entities under the assumption this UX clean-up issue stays 'critical'.

Bojhan’s picture

@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?)

webchick’s picture

Issue tags: +Spark

Tracking under Spark.

jessebeach’s picture

FileSize
40.68 KB
164.49 KB

@Bohjan, it's a bright, sunny day. My fingers are feeling nimble. Let's see what we can do to improve the UI.

In #contrib chat the other day, I made this analogy.

content : content types :: blocks : block types

What we have here is "Add block type" which is similar to "Add content type". On the content side, maybe we have something like "Place block".

Screenshot showing the current Add block button. There is a comment next to it that suggests the label be changed to Place block.

We could then change the "Block" top level menu item to "Block placement" and "Custom block types" to just "Block types".

Screenshot showing the current block placement form. The toolbar menu is open and the Block link has a comment next to it that suggests the label be changed to Block placement. The Custom block types menu link has the word custom crossed out, suggesting the label be changed to just Block types.

jessebeach’s picture

My comment is really just echoing what @Dries and @meba pointed out already. I'll put together a patch with this input and get this rolling. We can iterate as we go.

Bojhan’s picture

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?

jessebeach’s picture

Status: Active » Needs work
FileSize
7.12 KB
133.85 KB
56.54 KB

This patch just adjusts some labels.

A screenshot of the Blocks UI. The admin menu link labels and buttons labels have been changed so that instances of Add and Place. All instances of the word custom have been removed.

The block placement form

Screenshot of the current block placement form.

Comments embedded in the image above:

"I may want to add a block, but we should really encourage reuse here, not creation"

"I don't feel like I'm SELECTING on this screen. The labels need to reflect that I am picking something. It's fine if I'm asked to configure it after that."

"These elements are really filters, we should give the standard filter UI treatment above the list"

Improved Block page

Gábor Hojtsy’s picture

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.

webchick’s picture

Issue tags: +sprint

Tagging as something we're working on this sprint.

jessebeach’s picture

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

  1. Add a block, just use the default template
  2. Add a block, let me choose from existing block instances to reuse one
  3. 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.

Bojhan’s picture

@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?

Gábor Hojtsy’s picture

Agreed with Bojhan!

webchick’s picture

Ad blocks are 100% custom HTML, and are probably at least a 60% use case.

chris_h’s picture

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.

Bojhan’s picture

@jbeach @webchick Lets take this as a topic for the ux hours of tomorrow

andypost’s picture

My 90% of use-cases for blocks is actually custom HTML for (image/text, ad/tracking/js-widgets)

David_Rothstein’s picture

@chris_h, for the second half of your comment, see #1164718: Improving the usability between "custom block" and "content" - I think it's related.

jessebeach’s picture

I put together some wireframes to help visualize this discussion.

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.

Drupal block UI, the Bartik theme secondary tab

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".

Drupal block UI, the new block template list secondary tab

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.

Gábor Hojtsy’s picture

David Rothstein also posted in #663946: Merge "List links" page into "Edit menu" page that he believes the disconnect between object labels and their blocks titles is confusing. See #1926736: Allow block titles to be automatically tied to the underlying object which I just opened for that to track. Adding to above issue summary.

Gábor Hojtsy’s picture

Issue summary: View changes

Updating issue summary with link to blocks UX issues I'm aware of.

jessebeach’s picture

FileSize
116.78 KB

What about finessing the information architecture a bit like this?

I'd like to get:

  1. A list of all blocks. Not the instances, but the blocks themselves.
  2. A list of blocks by theme. Block instances in this case.
  3. A list of block types.

Under an IA like this, a user might not have permission to add block types, but the user could create new blocks from existing types and place instances of those types.

Screen shot of the admin menu with the Structure menu open. Under it, there is a Blocks menu that itself has two sub items. These sub items are Block placement and Block types.

dcmistry’s picture

I agree with the 3 categories for IA. However, I am not sure if "Block placements" correspond well to list of blocks (by theme). One not so well thought suggestion may be "Blocks by theme"

Bojhan’s picture

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.

jessebeach’s picture

You cant do anything with the blocks themselves right?

This is a good point. A custom block can be edited. So it is true that without any custom blocks, there would be nothing to do with the list of system blocks from Views, Menus and other modules.

But, once you have created even one custom block, you need a form that lists that block so you can edit it.

webchick’s picture

Yeah, unless we just add "edit" to the dropbutton operations on the block placement page, which then could become just "Blocks." Hm.

jessebeach’s picture

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.

webchick’s picture

Well I'm not sure they necessarily know that just cos it's on a different page. :)

We could also have "configure this block", "edit all copies of this block" operations, or similar. Not saying we should, but we could. :)

Gábor Hojtsy’s picture

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...

hass’s picture

There is also a need to port the UI changes that have been made for nodes in #1751606: Move published status checkbox next to "Save" to the blocks UI.

tkoleary’s picture

Here is a new design prototype for the complete blocks interaction flow.

http://invis.io/AKCKX6BH

There are a few key points to look at:

  • There is a design for how to access blocks from the fron end, an important interaction that did not exist before.
  • The problem of blocks instances is dealt with by changing the mental model to blocks, global settings, blocks, local settings
  • There is a picker for layouts which did not exist before
  • Underlying markup for the blocks (now layout) UI is divs instead of a table so that it can eventually grow into a full abstraction of a layout in D8 contrib
tkoleary’s picture

There is also a need to port the UI changes that have been made for nodes in #1751606: Move published status checkbox next to "Save" to the blocks UI.

Good point

Gábor Hojtsy’s picture

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:

Screenshot_3_7_13_12_06_PM.png

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.

Screenshot_3_7_13_12_10_PM.png

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.

tkoleary’s picture

@Gabor Hojtsy,

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?

Right, those are also local. I need to re-word to make that clear.

Gábor Hojtsy’s picture

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.

tkoleary’s picture

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.

Prototype is here: http://invis.io/AKCKX6BH

webchick’s picture

Status: Needs work » Needs review

Marking needs review to hopefully get some eyeballs on this.

Status: Needs review » Needs work

The last submitted patch, block-ui-1875252-11.patch, failed testing.

jessebeach’s picture

FileSize
11.5 KB

Intermittent patch for others to work from.

lisarex’s picture

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.

jessebeach’s picture

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.

Bojhan’s picture

Is the latest patch to be used as demo?

jessebeach’s picture

No, it's still under heavy development. Design input is well appreciated at this point: wireframes, IA and flows.

tkoleary’s picture

Reposting this prototype because nobody has commented on it except Lisarex (thx lisa).

Prototype is here: http://invis.io/AKCKX6BH

aspilicious’s picture

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.

Great job btw, I bet lots of work has gone into this.

andypost’s picture

Currently Layouts menu item has different purpose but proposed implementation looks much more useful and could be used for #1841584: Add and configure master displays

@aspilicious by pressing Shift key you can highlight a active/clickable areas and horizontal scroll helps to navigate the slides.

@tkoleary please explain a proposed way to use the prototype

lisarex’s picture

@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.

aspilicious’s picture

Ok that made a lot more sense :). Thnx! :D

xjm’s picture

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.

tkoleary’s picture

@ andypost

@tkoleary please explain a proposed way to use the prototype

Sure.

  • 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.

tkoleary’s picture

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 :)
xjm’s picture

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

@aspilicious is an active D8 contributor, so I'm quite sure he was referring to the D8 interface elements. He means the seven theme, not D7.

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 :)

It does make it harder though for contributors to identify specific, scoped changes they can put in a patch. :) And since Ember isn't included in core, I can see how that throws contributors off.

tkoleary’s picture

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.

xjm’s picture

Filed #1950700: Rename "Add block" to "Place block" on the blocks admin page. It's a first step that we can get in now to start iterating. :)

xjm’s picture

xjm’s picture

Issue summary: View changes

Updated issue summary.

xjm’s picture

Issue summary: View changes

.

xjm’s picture

#1888702: Use configuration selection instead of derivatives for some blocks is primarily scalability issue, but it also has usability implications.

xjm’s picture

Issue summary: View changes

Updated issue summary.

YesCT’s picture

here are issues I opened as a result of trying to use blocks for the first time, in #13 and #14 in #1948884-13: Create configuration schemas for block and custom_block modules
I still need to read through this and some other block issues.
I'll take responsibility for marking any of these duplicates.. as I do that.
I found #1871746: Add modal block browser and #1888702: Use configuration selection instead of derivatives for some blocks but they are not quite the same as those.
Some parts might overlap. I opened these as individual issues instead of a bigger "blocks didn't make sense to me" issue. I'm hoping that having some of these suggestions split out might make it easier to get some of the things in that might have more wider agreement on.
It might be that these need to be postponed on some "figure out block infrastructure" issue that I dont understand.

YesCT’s picture

tim showed me http://screencast.com/t/WeSsuC5Mh (from #47) in irc.
And it addresses many of the things I opened issues for in #60.

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?

Bojhan’s picture

@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.

xjm’s picture

@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.

No, they won't fix the whole workflow, but they'll help.

xjm’s picture

xjm’s picture

WRT the pattern on the block library, see also: #1832862: Make views add field scannable

webchick’s picture

Issue tags: -sprint, -Spark

Removing this from the Spark tracker. We've tried to push this along as far as we can, but we need to focus on our own bugs.

tkoleary’s picture

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

-Kevin

Gábor Hojtsy’s picture

@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?

aspilicious’s picture

1) Looks great and very very simple :)
2) It's not clear to me if you can choose a category for your custom block, or if all the custom blocks will be part of a "custom block category"

Regarding the filter. I would filter on block name and hide empty categories.
Other than that, great job!

tkoleary’s picture

aspilicious, Gábor Hojtsy

" I would filter on block name and hide empty categories."

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.

The "add category" function should not be part of the MVP.

xjm’s picture

Thanks Kevin and Bojhan!

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

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

  2. 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.

  3. 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.)

  4. 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.

Edit: Oops, crossposted with Kevin. :)

xjm’s picture

Also, for the backend part of this, please whoever works on this feel free to work around (or kill) PluginUIBase and BlockPluginUI. With fire, if necessary.

tkoleary’s picture

@xjm, @bojhan

"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.

Bojhan’s picture

@tkoleary pfiew :) Ok, this sounds fine - especially if its in a modal then you don't really lose context.

yoroy’s picture

FileSize
31.37 KB
32.14 KB

I've been sitting on a couple ideas around this as well. Here's a quick screencast. I think there are many similarities: http://www.youtube.com/watch?v=emBJriydtvQ

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.

Gábor Hojtsy’s picture

@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.

Bojhan’s picture

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.

Gábor Hojtsy’s picture

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?

Bojhan’s picture

@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.

tkoleary’s picture

@bojhan @Gábor Hojtsy

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"

tkoleary’s picture

Issue summary: View changes

Updated issue summary.

xtfer’s picture

I've added #2014191: Implement the block-by-theme listing page to work on the implementation of the work indicated at #67.

xtfer’s picture

Issue summary: View changes

Updated with proposed solution task and some further cross-references

jessebeach’s picture

Issue summary: View changes

added an issue to the list

sdboyer’s picture

generally speaking, i'm a big, big fan this.

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.

also, noting #2022897: Shift responsibility for creating unique config id/machine name off of (views) block plugins and onto BlockFormController and #2025649: Add title-related methods to BlockPluginInterface to help clarify and resolve many issues here because they're gonna shift some of the underlying APIs here in a way that should help make all of these flows more sane and standardized across different types of blocks.

sdboyer’s picture

Issue summary: View changes

removed duplicate task

jessebeach’s picture

Issue summary: View changes

added 2027101

jessebeach’s picture

Issue summary: View changes

Added 2027131

jessebeach’s picture

Issue summary: View changes

added 1920862

jessebeach’s picture

Issue summary: View changes

edit

jessebeach’s picture

Issue summary: View changes

reorging

jessebeach’s picture

Issue summary: View changes

edit

jessebeach’s picture

Issue summary: View changes

edit

jessebeach’s picture

Issue summary: View changes

edit

jessebeach’s picture

Issue summary: View changes

edit

jessebeach’s picture

Issue summary: View changes

edit

jessebeach’s picture

Issue summary: View changes

edit

xjm’s picture

Closed #2055053: UI of Blocks management - very confusing... as a duplicate of this issue.

andypost’s picture

andypost’s picture

Issue summary: View changes

edit

jessebeach’s picture

Issue summary: View changes
xjm’s picture

xjm’s picture

Issue summary: View changes

added #2055853

xjm’s picture

xjm’s picture

xjm’s picture

Issue summary: View changes

Updated issue summary.

xjm’s picture

Issue summary: View changes

.

jessebeach’s picture

Issue summary: View changes

added a link to sandbox

mradcliffe’s picture

If a contributed block provides a lot of configuration, then the dialog window is too large, and the save button is not accessible by mouse. The title is also obscured.

When I try to scroll to find the bottom of the dialog, the dialog snaps back.

Is there a follow-up issue for this?

jessebeach’s picture

nice catch. Let's take care of that in an existing issue: #2067263: Drupal dialog placement must take displacing viewport elements, like the Toolbar, into account when calculating placement. Essentially don't let the Drupal dialog become inaccessible to clicks.

tim.plunkett’s picture

Status: Needs work » Closed (duplicate)
Issue tags: -revisit before beta, -If SCOTCH fails

I'd like to think that if we achieve the goals of #2055853: [meta] Improve the place block UX; Separate interaction from the create block UX; Improve the existing blocks-by-theme layout, then the whole block UI is shippable.
We've already gutted the block plugin UI, and are now tweaking the workflows.
That issue was also originally opened as an action item, but I've turned it into a meta and have many child issues.

Please follow along on https://drupal.org/project/issues/search/drupal?issue_tags=Block+UI+over...

tim.plunkett’s picture

Issue summary: View changes

revised sandboxes