Go to the Block layout page (admin/structure/block).
Click on a block name in the "Place blocks" area, choose a region, and submit.
You will see both:
I kind of appreciate having a visual representation of where my block ended up, but this particular visual representation is very confusing to me, because it is the same visual representation that says "you have made a change and it hasn't been saved". So, based on what I see on the screen, I do not know whether the block has really been saved or not.
My suggestion would be to have it show up in the list in green, indicating "HERE I AM" but also "This has been saved unless you drag it around or something".
Also on admin/structure/block -- if I use the select list "Region" on a block to move a block from, say, the Header region to Primary menu region, it shows up in the Primary menu list but it is *NOT* yellow, and there is no "You have unsaved changes" message. So I don't really know that I have to save the changes. But if I just go back to admin/structure/block, my block has not been disabled.
I am only seeing the yellow highlighting and the "You have unsaved changes" if I do the move/disable operation by dragging the block around.
When you add a block and it has been saved, make it show up in the block list in green instead of yellow.
When you use the Select list to change the block region, make it show up in the new region in yellow and make sure there is a "changes need to be saved" message at the top. Basically, it should behave the same as if you dragged the block from one region to another instead of using the Select list to change the region, and it currently doesn't.
Color representations of changes in the Block layout, and whether they need to be saved, will be more intuitive.
None.
| Issue category | Bug because the UI is very confusing as it is |
|---|---|
| Issue priority | Normal because it still works, at least if you ignore the colors and messages and save the page no matter what. |
| Unfrozen changes | Unfrozen because it only changes CSS and/or markup. |
| Prioritized changes | The main goal of this issue is usability, so it is a prioritized change |
| Disruption | Not disruptive. Change is limited to the CSS and/or markup in the Ajax on the Block layout admin page. |
| Comment | File | Size | Author |
|---|---|---|---|
| #28 | last_placed_block_-2396937-28.patch | 2.26 KB | subhojit777 |
| #24 | last_placed_block_-2396937-23.patch | 2.27 KB | legolasbo |
| #24 | interdiff-20-23.txt | 960 bytes | legolasbo |
| #11 | last_placed_block-2396937-11.patch | 2.21 KB | vj |
| #9 | last_placed_block_-2396937-9.patch | 2.16 KB | legolasbo |
Comments
Comment #1
jhodgdonOh gracious, it gets worse.
If I go to admin/structure/block and use the select list "Region" to move a block from, say, Header to -none-, it shows up in the Disabled list but it is *NOT* yellow, so I don't really know that I have to save the changes. But if I just go back to admin/structure/block, my block has not been disabled.
I am only seeing the yellow highlighting and the "You have unsaved changes" if I do the move/disable operation by dragging.
Comment #2
tim.plunkettThe highlighting of a newly *added* block was done in #2078951: Highlight the row of block that was just placed.
It also scrolls it into view.
I don't remember any real discussion about the color choice, I think I just mimicked tabledrag. Which is exactly your point, it is conflating two different things (recently-added-and-saved, and yet-to-be-saved).
Comment #3
jhedstromIf the fix is to change a few colors, this could probably be knocked out very quickly.
Comment #4
jhodgdonThat would be good. I'll update the summary with a proposed resolution.
Probably this is just Normal, although I think it's pretty confusing.
Comment #5
tim.plunkettIn light of #2512456: Implement the new block layout design to emphasize the primary interaction of placing a block, I think the color is the only remaining confusing part.
Comment #6
Bojhan commentedAgreed, lets fix the color part.
Comment #7
lewisnymanI seems like the success color would be more suitable? We have a class for that ;-)
color-successComment #8
legolasboI will be working on this today.
Comment #9
legolasboAttached patch implements the proposed resolution.
Comment #10
legolasboComment #11
vj commented@legolasbo,
I have tested your patch. Your patch works nice and resolves both the issues. But found a small issue please check attached screenshot (last_updated_block_patch_issue.PNG).
I have fixed this please check patch.
Thanks,
Vj
Comment #12
legolasbo@Vj,
Thanks for reviewing and updating the patch. I've reviewed your changes and I'm happy with them, but we need someone else to RTBC it.
Comment #13
dawehnerI think some screenshots to describe the changed would be nice.
I like the general idea of the issue. Highlighting better what actually happened is a great step! I personally was not sure multiple times whether the block was actually saved already.
Comment #14
legolasboWorking on adding some screenshots.
Comment #15
legolasboUpdated issue summary with before/after screenshots
Comment #16
legolasboComment #17
legolasboComment #18
lewisnymanI manually tested this patch. I'm really happy with the UI changes here and the cohesion between the messaging color and the block color. See screenshot 4.
This seems good to go. I'm assuming we need to add so much code so we can split the logic of the last placed block and a successfully place block. Can someone else varify this?
Comment #19
nod_Some nitpick
var updateLastPlaced = function (table, rowObject)With our standards it should be:
var updateLastPlaced = function ($table, rowObject)There is an extra pair of
//as well.Other than that it's good to go.
Comment #20
vj commented@nod_
I have updated the patch as per suggestion Let me know if anything else we have missed.
Comment #21
legolasboAttached patch updates the
tablevariables to$tableto be in line with coding standards.I'm aware of the scope creep, but i prefer consistency over reviewability in this case.
Comment #22
nod_A bit too much, scope creep is not our friend.
Can you just change it in the new function? Later on we'll run a tool to catch most of the unprefixed jQuery variables, this one will show up, no worries.
Comment #23
legolasbo@nod_,
Ok limited renames to just the function.
Comment #24
legolasbo*facepalm* I've uploaded the same patch/interdiff as before. This is the correct one.
Comment #25
nod_All good. :)
Thanks!
Comment #27
legolasboThis needs a reroll, which is why I am tagging it novice.
Comment #28
subhojit777Comment #29
legolasboBack to RTBC since this was just a plain reroll.
Comment #32
emma.mariaI noticed this was knocked back to Needs Review whilst looking through open Novice CSS issues. The patch is green I'm putting it back to RTBC.
Comment #33
alexpottCommitted 1842da2 and pushed to 8.0.x. Thanks!
Thanks for adding the beta evaluation to the issue summary.