Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Updated: Comment #0
Problem/Motivation
The UX team would like to move the "Add custom block" link into the sidebar
Proposed resolution
Remaining tasks
Figure out if details elements even will support this, or if the ugly CSS hacks are worth it
User interface changes
Yes, screenshots will be provided when available.
API changes
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | custom_block-2087211-1.patch | 3.27 KB | tim.plunkett |
| #1 | Screen Shot 2013-09-11 at 8.37.41 PM.png | 119.96 KB | tim.plunkett |
| #1 | Screen Shot 2013-09-11 at 8.37.48 PM.png | 119.42 KB | tim.plunkett |
| #1 | Screen Shot 2013-09-11 at 8.38.59 PM.png | 128.77 KB | tim.plunkett |
| Screen Shot 2013-09-11 at 7.29.54 PM.png | 21.26 KB | tim.plunkett | |
Comments
Comment #1
tim.plunkettI don't know of any + image we can use, just using the + character for now...
But there are some issues. Because it's a details element, the link is hidden when its collapsed.
Additionally, it looks pretty odd when there are no custom blocks available.
Expanded, with block
Collapsed
Expanded, with no block
Comment #3
klonosHow about adding "+ New..." items as the top-most item for all available categories? Actually because we'd have more vertical space, we could be more "wordy":
Comment #4
tim.plunkettBecause only the custom block UI has the ability to multistep its way from creating a new custom block entity to placing the block to redirect back to the block layout page.
So any other "Add" links would be dead-ends, and I'd rather not do that.
Comment #5
klonosYeah, but the way I understand it these will (or at least I hope that they) eventually evolve to not being dead-ends. Plus there will be contrib that might rely on placing items there. I'm thinking for example the nodeblock module adding a "+ Add a node as a block..." item. There'll be others I'm sure ;)
So anyways, I'm not suggesting that we add entries for those that are not functional at the moment. We should introduce a pattern now for those that work and add additional "+ Add new [xyz] block..." items as more places support redirection back to the block layout page. I'm merely suggesting (especially given the issues you yourself mentioned back in #1) that we take the easy(ier) road instead of trying to figure out how to place and fit a link in the fieldset header.
I would love to have this "duality" of doing things:
1. Some users are used to the way things are done now: create a block from someplace else -> then navigate to the block layout page to place them. This group of users is probably long-time users (btw we are adding "quick-links" for them to be able to do that from where they create the blocks like in #2087219: Allow views blocks to be placed from the Views UI and #2083871: Allow menu blocks to be placed from the menu page for example).
2. New users will most likely expect to initiate the block placing procedure directly from the block layout page through wizard-driven-like actions. That's exactly what we're doing here for the custom blocks, but I suggest we generalize it.
Allowing both these ways would provide better UX IMO because people will be able to do their thing without pogo-sticking around the UI. They will be able to do it from either end and that exactly serves both the above groups of users.
Comment #6
tim.plunkettPatches welcome!
Or in this case, follow-ups welcome. That's out of scope for this issue.
I already discussed having a generic approach with the UX team, but since every other option is currently a dead-end, and isn't worth waiting around for.
Comment #7
klonosWell, not entirely out of scope. The other "+ Add ..." or "+ New ..." links perhaps (and yes they should be in follow-ups - I merely used them in the mockup to paint the whole picture), but still the "Add custom block" action can be a special item below the "CUSTOM BLOCK" category. I realize that even in that case the "Patches welcome!" in your reply covers that too, but honestly if placing the link inside the fieldset header is a walk in the park (which I honestly doubt), then feel free to wait around for that solution.
All in all though... fair enough - I was just brainstorming after the issues you mentioned.
Comment #8
tkoleary CreditAttribution: tkoleary commented@klonos
That is exactly the interaction I had in my first version of the design Tim is working from and ultimately where we need to go. Can you link the follow up issues to here?
Comment #9
klonosSorry, I was AFK for a couple of weeks now and I'm trying to catch up with the queue. Which issues again?
Comment #10
klonosComment #11
tim.plunkettComment #12
dawehnerIs it just me that it is odd to have a common pattern of "add a thing here" established and then start to move away again for single usecases?
Additional seriously, the add new custom block local action is way more prominent!
Comment #25
quietone CreditAttribution: quietone at PreviousNext commentedIt is now 'Add content block' and it does appear on 'Place block'. Therefore, closing as outdated.