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.
- Update admin menu link labels
- Issue: MISSING
- Menu items
- Block type
- Blocks
- Add block type form. Requires specifying the following:
- Issue: #1795268: Block metadata should use the standard "name" and "description" fields; follow content type form layout as the model
- Fields
- Name
- Description (optional)
- Fields
- Edit block type form
- List of block type instances
- Add block form. Requires specifying:
- Step 1:
- Chose Block type (if more than one exists).
- Step 2, block details form:
- Specify title, fill out fields
- Step 1:
- Edit block form
- List of blocks outside of a theme context
- Issue: MISSING
- Issue: #1871746: Add modal block browser
- Where is the access point? A menu link? I don't see this in the current design.
- This is the page that will list blocks and provide operations for each one like edit and delete
- List of blocks by theme
- Issue: File new issue(s) if needed.
- Tour: #2061679: Add a tour for the improved block admin UI at admin/structure/blocks.
- Place a block interaction.
- Place a block details form.
- Issue: #2055853: [meta] Improve the place block UX; Separate interaction from the create block UX; Improve the existing blocks-by-theme layout
- Fields
- Title
- Pre-populate with the parent block title
- Visibility rules
- Region placement
- Pre-populated if this form was opened because a user associated a block with a region e.g. by drag/drop
- Title
Infrastructure tasks
- #1920862: Rename custom_block.module to block_content.module
- #1926736: Allow block titles to be automatically tied to the underlying object
- #2014189: Add custom block categories
- #1888702: Use configuration selection instead of derivatives for some blocks
- #1875260: Make the block title required and allow it to be hidden
- #1875016: Automatically generate machine names for block plugins
- #1874584: "Block Library" link label is unclear
- #1875780: "Configure block" button text in the Block Library is confusing
- #1950700: Rename "Add block" to "Place block" on the blocks admin page
- #1871772: Convert custom blocks to content entities
- #2062715: [META] Many UI/UX issues with custom blocks.
Comment | File | Size | Author |
---|---|---|---|
#75 | Layout.png | 32.14 KB | yoroy |
#75 | Layout add block.png | 31.37 KB | yoroy |
#42 | block-ui-1875252-42.patch | 11.5 KB | jessebeach |
#36 | Screenshot_3_7_13_12_06_PM.png | 78.04 KB | Gábor Hojtsy |
#36 | Screenshot_3_7_13_12_10_PM.png | 82.37 KB | Gábor Hojtsy |
Comments
Comment #1
webchickI'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.
Comment #2
kattekrab CreditAttribution: kattekrab commentedEDIT: 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?
Comment #3
xjmComment #4
meba CreditAttribution: meba commentedImage one:
Image two:
Comment #5
Dries CreditAttribution: Dries commentedI tried a recent version of this patch. Here is what I found.
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):
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.
Comment #6
Dries CreditAttribution: Dries commentedI'm going to commit #1871772: Convert custom blocks to content entities under the assumption this UX clean-up issue stays 'critical'.
Comment #7
Bojhan CreditAttribution: Bojhan commented@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?)
Comment #8
webchickTracking under Spark.
Comment #9
jessebeach CreditAttribution: jessebeach commented@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".
We could then change the "Block" top level menu item to "Block placement" and "Custom block types" to just "Block types".
Comment #10
jessebeach CreditAttribution: jessebeach commentedMy 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.
Comment #11
Bojhan CreditAttribution: Bojhan commentedJust 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?
Comment #12
jessebeach CreditAttribution: jessebeach commentedThis patch just adjusts some labels.
The 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
Comment #13
Gábor HojtsyI 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.
Comment #14
webchickTagging as something we're working on this sprint.
Comment #15
jessebeach CreditAttribution: jessebeach commentedBlock 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
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.
Comment #16
Bojhan CreditAttribution: Bojhan commented@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?
Comment #17
Gábor HojtsyAgreed with Bojhan!
Comment #18
webchickAd blocks are 100% custom HTML, and are probably at least a 60% use case.
Comment #19
chris_h CreditAttribution: chris_h commentedThinking 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.
Comment #20
Bojhan CreditAttribution: Bojhan commented@jbeach @webchick Lets take this as a topic for the ux hours of tomorrow
Comment #21
andypostMy 90% of use-cases for blocks is actually custom HTML for (image/text, ad/tracking/js-widgets)
Comment #22
David_Rothstein CreditAttribution: David_Rothstein commented@chris_h, for the second half of your comment, see #1164718: Improving the usability between "custom block" and "content" - I think it's related.
Comment #23
jessebeach CreditAttribution: jessebeach commentedI 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.
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.
Comment #24
Gábor HojtsyDavid 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.
Comment #24.0
Gábor HojtsyUpdating issue summary with link to blocks UX issues I'm aware of.
Comment #25
jessebeach CreditAttribution: jessebeach commentedWhat about finessing the information architecture a bit like this?
I'd like to get:
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.
Comment #26
dcmistry CreditAttribution: dcmistry commentedI 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"
Comment #27
Bojhan CreditAttribution: Bojhan commentedI 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.
Comment #28
jessebeach CreditAttribution: jessebeach commentedThis 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.
Comment #29
webchickYeah, unless we just add "edit" to the dropbutton operations on the block placement page, which then could become just "Blocks." Hm.
Comment #30
jessebeach CreditAttribution: jessebeach commentedEditing 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.
Comment #31
webchickWell 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. :)
Comment #32
Gábor HojtsyCustom 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...
Comment #33
hass CreditAttribution: hass commentedThere 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.
Comment #34
tkoleary CreditAttribution: tkoleary commentedHere is a new design prototype for the complete blocks interaction flow.
http://invis.io/AKCKX6BH
There are a few key points to look at:
Comment #35
tkoleary CreditAttribution: tkoleary commentedGood point
Comment #36
Gábor HojtsyI 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.
Comment #37
tkoleary CreditAttribution: tkoleary commented@Gabor Hojtsy,
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.
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.
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?
Yes, I see that there could be scalability issues. Maybe we keep it collapsed by default so it doesn't create too much distraction.
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)
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.
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.
Right, those are also local. I need to re-word to make that clear.
Comment #38
Gábor HojtsySo 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.
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.
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.
Comment #39
tkoleary CreditAttribution: tkoleary commentedPolished 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
Comment #40
webchickMarking needs review to hopefully get some eyeballs on this.
Comment #42
jessebeach CreditAttribution: jessebeach commentedIntermittent patch for others to work from.
Comment #43
lisarex CreditAttribution: lisarex commentedStill 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.
Comment #44
jessebeach CreditAttribution: jessebeach commentedWe 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.
Comment #45
Bojhan CreditAttribution: Bojhan commentedIs the latest patch to be used as demo?
Comment #46
jessebeach CreditAttribution: jessebeach commentedNo, it's still under heavy development. Design input is well appreciated at this point: wireframes, IA and flows.
Comment #47
tkoleary CreditAttribution: tkoleary commentedReposting this prototype because nobody has commented on it except Lisarex (thx lisa).
Prototype is here: http://invis.io/AKCKX6BH
Comment #48
aspilicious CreditAttribution: aspilicious commentedI'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.
Comment #49
andypostCurrently 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
Comment #50
lisarex CreditAttribution: lisarex commented@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.
Comment #51
aspilicious CreditAttribution: aspilicious commentedOk that made a lot more sense :). Thnx! :D
Comment #52
xjmThis 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.
Comment #54
tkoleary CreditAttribution: tkoleary commented@ andypost
Sure.
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.
Comment #55
tkoleary CreditAttribution: tkoleary commentedHm well, while I understand that the approach requires more mental energy here's a few things to consider:
Comment #56
xjm@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.
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.
Comment #57
tkoleary CreditAttribution: tkoleary commentedThat'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.
Comment #58
xjmFiled #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. :)
Comment #58.0
xjmAdd #1926736: Allow block titles to be automatically tied to the underlying object
Comment #58.1
xjmUpdated issue summary.
Comment #58.2
xjm.
Comment #59
xjm#1888702: Use configuration selection instead of derivatives for some blocks is primarily scalability issue, but it also has usability implications.
Comment #59.0
xjmUpdated issue summary.
Comment #60
YesCT CreditAttribution: YesCT commentedhere 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.
Comment #61
YesCT CreditAttribution: YesCT commentedtim 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?
Comment #62
Bojhan CreditAttribution: Bojhan commented@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.
Comment #63
xjmNo, they won't fix the whole workflow, but they'll help.
Comment #64
xjmAnother issue: #1956134: Provide helpful editing links on "admin/structure/block" for deriver blocks (menu, views, block content, etc.)
Comment #65
xjmWRT the pattern on the block library, see also: #1832862: Make views add field scannable
Comment #66
webchickRemoving 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.
Comment #67
tkoleary CreditAttribution: tkoleary commentedsnugug, 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
Comment #68
Gábor Hojtsy@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?
Comment #69
aspilicious CreditAttribution: aspilicious commented1) 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!
Comment #70
tkoleary CreditAttribution: tkoleary commentedaspilicious, 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.
Comment #71
xjmThanks 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):
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.
Edit: Oops, crossposted with Kevin. :)
Comment #72
xjmAlso, for the backend part of this, please whoever works on this feel free to work around (or kill)
PluginUIBase
andBlockPluginUI
. With fire, if necessary.Comment #73
tkoleary CreditAttribution: tkoleary commented@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.
Comment #74
Bojhan CreditAttribution: Bojhan commented@tkoleary pfiew :) Ok, this sounds fine - especially if its in a modal then you don't really lose context.
Comment #75
yoroy CreditAttribution: yoroy commentedI'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.
Comment #76
Gábor Hojtsy@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.
Comment #77
Bojhan CreditAttribution: Bojhan commentedCan 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.
Comment #78
Gábor HojtsyYeah 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?
Comment #79
Bojhan CreditAttribution: Bojhan commented@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.
Comment #80
tkoleary CreditAttribution: tkoleary commented@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:
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"
Comment #80.0
tkoleary CreditAttribution: tkoleary commentedUpdated issue summary.
Comment #81
xtfer CreditAttribution: xtfer commentedI've added #2014191: Implement the block-by-theme listing page to work on the implementation of the work indicated at #67.
Comment #81.0
xtfer CreditAttribution: xtfer commentedUpdated with proposed solution task and some further cross-references
Comment #81.1
jessebeach CreditAttribution: jessebeach commentedadded an issue to the list
Comment #82
sdboyer CreditAttribution: sdboyer commentedgenerally 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.
Comment #82.0
sdboyer CreditAttribution: sdboyer commentedremoved duplicate task
Comment #82.1
jessebeach CreditAttribution: jessebeach commentedadded 2027101
Comment #82.2
jessebeach CreditAttribution: jessebeach commentedAdded 2027131
Comment #82.3
jessebeach CreditAttribution: jessebeach commentedadded 1920862
Comment #82.4
jessebeach CreditAttribution: jessebeach commentededit
Comment #82.5
jessebeach CreditAttribution: jessebeach commentedreorging
Comment #82.6
jessebeach CreditAttribution: jessebeach commentededit
Comment #82.7
jessebeach CreditAttribution: jessebeach commentededit
Comment #82.8
jessebeach CreditAttribution: jessebeach commentededit
Comment #82.9
jessebeach CreditAttribution: jessebeach commentededit
Comment #82.10
jessebeach CreditAttribution: jessebeach commentededit
Comment #82.11
jessebeach CreditAttribution: jessebeach commentededit
Comment #83
xjmClosed #2055053: UI of Blocks management - very confusing... as a duplicate of this issue.
Comment #84
andypostcurrently delete link is default in block listing, supposed to change it in #1995046-2: BlockListController doesn't call parent::getOperations() and so "delete" is the default dropbutton operation
Comment #84.0
andypostedit
Comment #84.1
jessebeach CreditAttribution: jessebeach commentedupdated the invision prototype link: https://projects.invisionapp.com/share/PEGD21X4#/screens/
Comment #85
xjm#2055853: [meta] Improve the place block UX; Separate interaction from the create block UX; Improve the existing blocks-by-theme layout is currently the main issue for this meta.
Comment #85.0
xjmadded #2055853
Comment #86
xjmAdded #2061679: Add a tour for the improved block admin UI at admin/structure/blocks..
Comment #87
xjmAdded #2062715: [META] Many UI/UX issues with custom blocks..
Comment #87.0
xjmUpdated issue summary.
Comment #87.1
xjm.
Comment #87.2
jessebeach CreditAttribution: jessebeach commentedadded a link to sandbox
Comment #88
mradcliffeIf 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?
Comment #89
jessebeach CreditAttribution: jessebeach commentednice 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.
Comment #90
tim.plunkettI'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...
Comment #90.0
tim.plunkettrevised sandboxes