Updated: Comment #0

Problem/Motivation

The UX team would like to move the "Add custom block" link into the sidebar

Proposed resolution

Screen Shot 2013-09-11 at 7.29.54 PM.png

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

Comments

Priority:Critical» Normal
Status:Active» Needs review
StatusFileSize
new128.77 KB
new119.42 KB
new119.96 KB
new3.27 KB
FAILED: [[SimpleTest]]: [MySQL] 59,176 pass(es), 42 fail(s), and 15 exception(s).
[ View ]

I 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
Screen Shot 2013-09-11 at 8.37.41 PM.png

Collapsed
Screen Shot 2013-09-11 at 8.37.48 PM.png

Expanded, with no block
Screen Shot 2013-09-11 at 8.38.59 PM.png

Status:Needs review» Needs work

The last submitted patch, custom_block-2087211-1.patch, failed testing.

How 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":

v   CUSTOM BLOCK
+ Add new custom block...     <- here
+ my Already Existing Block
+ yet Another Custom Block
v   COMMENT
+ Add new comment block...    <- here
+ Recent comments
v   CONTENT
+ Add new content block...    <- here
+ myCustom Views Block
v   MENU
+ Add new menu block...       <- here
+ Administration
+ Footer
+ Main navigation
+ Tools
+ User account menu
v   SEARCH
+ Search form
v   SHORTCUT
+ Shortcuts
v   SYSTEM
+ Breadcrumbs
+ Main page content
+ Powered by Drupal
+ System Help
v   USER
+ User login
+ Who's new
+ Who's online

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

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

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

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

@klonos

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.

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?

...Can you link the follow up issues to here?

Sorry, I was AFK for a couple of weeks now and I'm trying to catch up with the queue. Which issues again?

Assigned:tim.plunkett» Unassigned

Is 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!