Implement a drag & drop model for building layouts

[Bojhan]

A big part of Drupal's UX flaws is its inability to provide a great experience for some of the core site building concepts. I have raised this concern many times, and we even outlined it as a strategy for Drupal 8.

Given that Backdrop seems to focus on this sitebuilder type of audience, I'd love for this to happen. Clearly its a big effort, but in terms of UX it will set it apart. From my point of view, improving UX by removing a bunch of stuff - does very little if you leave the core concepts intact, that is what most people will care about.

The actual model could be rather simple, you need to decide between either real live or abstracted view of "a display". This display can then be configured, by pulling items (blocks, fields, menu's, etc.) on top of it. The tricky part is making this a cohesive experience across data models.

I wouldn't mind helping with the interaction design and research, but the biggest problem is and has been resources.

[quicksketch]

Considering the size of the project and the tremendous leap this takes us forward, I'd like to merge this tomorrow during our weekly code sprints. The number of issues this solves purely fixing things is significant: appearance of breadcrumbs, the positioning of the columns in the footer and triptych in Bartik, and making our front-end responsive. Not to mention the potential for future gains and the features it adds.

Right now with so many people merely curious but not actually involved in Backdrop, I'd love to include this as soon as possible so that it'll be there to meet people's curiosity, as well as just to get more user-testing on the whole thing. Our automated tests are fairly comprehensive. We need actual users to weed out the edge-cases that we haven't encountered yet.

[ghost]

Not sure if this is related to Layout, but as soon as I setup a new site based on the PR branch, I had problems with Admin Bar: first it was overlapping the top of the page, then I clicked Home link to refresh and it disappeared altogether...

[ghost]

I did some brief testing and noticed the following:

• Looks weird when blocks with no title (e.g. Header) have their 'Title type' set to 'Default title'. I know this is the way blocks used to work, but I recommend instead either removing 'Default title' option from blocks with no title (and setting to 'Hidden' by default), or displaying a block's default title next to the 'Title type' field (and mentioning that it's empty).
• When clicking 'Add block', looking at the block list, adding one, then clicking 'Add block' again, the block list has changed order. This seems random and should be made consistent.
• Is it possible to have a yellow warning/message stating that the layout must be saved before changes will take effect (similar to content type fields: Changes made in this table will not be saved until the form is submitted.)? Currently there's no indication that newly-added blocks need further saving (using 'Save layout' button).
• After clicking 'Configure block' in the contextual links, the layout page loads but the configure popup takes another good three seconds to appear, making me wonder what's going on...
• After clicking 'Configure block' in the contextual links, if you close the configure popup and try to go back (browser Back button), it reloads the same layout page (with a different URL). You have to click Back a second time to go back to where you clicked the contextual link. URLs are /admin/structure/layouts/manage/default?destination=node# (after closing popup) and /admin/structure/layouts/manage/default?destination=node#configure-block:d32383b6-5429-4206-a45b-91ce014678b5 (after clicking Back the first time).

Hope that helps.

[quicksketch]

Thanks @BWPanda! All very helpful feedback. I've seen most of this behavior and we should address all of it.

After clicking 'Configure block' in the contextual links, the layout page loads but the configure popup takes another good three seconds to appear, making me wonder what's going on...

This is the only one I haven't seen. Perhaps it's just a matter of the JS loading completely so that the dialog may be opened? Which browser is this in?

Some of these we might move into the followup issue (#345). Are there any of these (or others) that you think are show-stoppers?

[quicksketch]

Not sure if this is related to Layout, but as soon as I setup a new site based on the PR branch, I had problems with Admin Bar: first it was overlapping the top of the page, then I clicked Home link to refresh and it disappeared altogether...

Ahh, you're right. There seems to be something with the most recent merge after Admin Bar was renamed. I'll look into this one right away.

[quicksketch]

Looks weird when blocks with no title (e.g. Header) have their 'Title type' set to 'Default title'. I know this is the way blocks used to work, but I recommend instead either removing 'Default title' option from blocks with no title (and setting to 'Hidden' by default), or displaying a block's default title next to the 'Title type' field (and mentioning that it's empty).

I was trying to figure this one out, but unfortunately it's currently a little hard to handle. hook_block_view() returns both the title and the content together, so in order to get the title (or know if a block has a title), you'd have to render the entire block. In some cases this isn't even possible, for example if a block requires a node context and uses that in its title, we won't know what node will be used until the block is displayed on the front-end.

An alternative to getting the actual title is potentially adding another key into hook_block_info(), like "has title". This would let Layout module know that a block usually has a title. In the event another module modified this behavior, it'd have to hook_block_info_alter() the block as well. Then we could pursue the No Title/Custom Title options, and remove "Default title" for such blocks.

[ghost]

After clicking 'Configure block' in the contextual links, the layout page loads but the configure popup takes another good three seconds to appear, making me wonder what's going on...

This is the only one I haven't seen. Perhaps it's just a matter of the JS loading completely so that the dialog may be opened? Which browser is this in?

This happens for me in Firefox 33.0 running on Linux, but I also just tested in Google Chrome 38.0.2125.104 (also on Linux) and the same happens...

Are there any of these (or others) that you think are show-stoppers?

I think the order of the 'Add block' list (2nd bullet point above) should be addressed before merge. PR code note here: https://github.com/backdrop/backdrop/pull/483#discussion_r18949907

[quicksketch]

Excellent, thanks @BWPanda. I've got Admin Bar fixed, the list of blocks fixed, and merged with 1.x (we had some conflicts in the update hooks since last week). I'll update the PR shortly.

[quicksketch]

Okay PR updated with:

• Fixes admin_bar merge.
• Merges with 1.x, updating the hook_update_N() numberings.
• Fixes the order of blocks so they're always the same.
• Fixes the Back button issue when opening a block form from a contextual link.

Does not yet fix the slow loading of the block form, add a warning message when modifying a layout, or adjust the block title settings.

[klonos]

So exciting people can test B&L now!!! Thanx for all the hard work guys.

[ghost]

Does not yet fix the slow loading of the block form, add a warning message when modifying a layout, or adjust the block title settings.

Block title setting certainly aren't necessary for launch, just an idea I had while testing. Others should comment on the necessity of the other ideas though.

[ghost]

Not directly related to the new Layout feature, but just posted some ideas for improved 'Add new [custom] block' form here: https://github.com/backdrop/backdrop-issues/issues/362

[ghost]

Ok, did some more testing on recent PR. Notes:

• The more I look at it, the less I like the 'Title type' field (as it currently is); see above for my gripes with it. One extra thing I noticed however is the 'Title type' at the top of the 'Edit layout' screen. What is this title for? Turns out it's for setting the Page Title, which is halfway down the Layout!
• Not sure that I like the ability to edit custom blocks when adding them to a layout... You can edit the block description (admin name) and body, but not title (you can add custom title, but not change original title like with body field). Also, when adding the same custom block to multiple regions, it's not obvious that editing the block's content will also change it in the other regions too. I recommend leaving the editing of custom blocks to the blocks page only.
• The order of the block list no longer changes between adding blocks (which is good), but the order still seems random (it looks like it's ordered by the implementing module's name, but that isn't shown anywhere).
• Adding multiple 'main page content' blocks to default view and saving then displays error that you can't have more than one (good), but the block is still there. We have to manually remove it. It seems a better idea to automatically remove it, and have the error serve to explain why it was removed.
• Probably just a CSS issue, but when the sidebar is empty (either no visible blocks, or no blocks at all), the sidebar region still takes up space, whereas it'd be better if the main content area expanded to fill the page width.

[ghost]

BTW, that last bullet point is referring to the frontpage, not the layout editing page.

[quicksketch]

The more I look at it, the less I like the 'Title type' field (as it currently is);

@jenlampton has had a lot of things to say about the Title options as well. We don't want to make it a block, because it isn't moveable (and probably shouldn't be). Her suggestion was to put an edit link next to the title, similar to what we do for blocks. Then the title settings would open in a modal, like a block.

Not sure that I like the ability to edit custom blocks when adding them to a layout...

I agree on this one too. We'll need to think about it. One of our followup tasks is adding "Custom text" blocks that save into config and are not entities at all. These would be per-block and not globally available. 9/10 times, I'd probably use these instead of Block entities anyway.

The order of the block list no longer changes between adding blocks (which is good), but the order still seems random

Yeah, let's leave the order of blocks to the followup, where we'll add the filter box and a dropdown categories filter (similar to views).

It seems a better idea to automatically remove it, and have the error serve to explain why it was removed.

Not sure about this. I don't think it's going to be common to try this in the first place unless you were actually trying to break something (good job on the attempt :wink:), but since we don't show the error until they save the page, which one would we remove? The first one or the newly added one?

Probably just a CSS issue, but when the sidebar is empty (either no visible blocks, or no blocks at all), the sidebar region still takes up space

This was actually an intentional change. Collapsible regions can often be a confusing concept and can increase the variability of the page. e.g. users may expect a max-width of 600px for the left column for both images and text, but suddenly when a block is removed, it fills the entire width, which can make readability difficult. We kept the collapsing columns for the Bartik layout (for compatibility), but for the two-column layout and others we'll add in the future, they will probably not collapse if empty. If you wanted a page with a single column and no blocks, it'd be up to you to set a different layout for that particular path.

[quicksketch]

I just updated the PR again. Now the message for "You have unsaved changes" shows up immediately after adding or modifying a block.

[jenlampton]

Some feedback for layouts - first woohoo! happy dance ... and then some more valuable feedback.

1) We need to clean up the edit layout DragonDrop(tm) interface, see https://github.com/backdrop/backdrop-issues/issues/373

2) Fix up header block text "Contains elements typically contained..." should be "Contains elements typical of a site header including..."

3) Configure Block "Title type" options should be Default, Custom, None. No need to repeat the word "title".

4) Text on admin listing page. "used on all paths without a specific layout" should be "used on all paths unless otherwise specified"

5) When you navigate to the "Create new layout" page and then Cancel, validation fires and you are required to fill out all the fields.

6) When you have filled out all the fields, and then cancel, the form is cleared but you are left on the same page. You should be returned to the list of layouts.

7) When editing a layout, both "Save layout" button and the "Cancel" button should return the viewer to the list of layouts.

8) When editing the layout "settings" and you hit "Save" you should be returned to the layout page.

9) When creating a new layout, the content from the default layout gets copied into the new layout. But sometimes the same block gets placed more than once (I have header twice and main menu three times, but powerd by backdrop only once). This happens for layouts with and without a context. I can't figure out why this is happening, but it happens consistently.

10) Changes to the Create new layout form.

• "Layout title" should be "Layout name".
• Layout order should be intuitive: 1 then 2 then 3/3/4

11) Conditions are missing when editing the default "Administrative layout". I wanted to change the admin layout to be 2 columns. But after doing so I instantly realized that I had a column on my layout-editing-layout, and wanted to add a condition for "not THIS path" but I can't :(

12) Layout listing page: "Path and layout" should be "Layout and Path"

[ghost]

Not sure if this got lost above, but:

• Allow default layouts to be reset/reverted

[quicksketch]

Thanks all.

9) When creating a new layout, the content from the default layout gets copied into the new layout. But sometimes the same block gets placed more than once (I have header twice and main menu three times, but powerd by backdrop only once). This happens for layouts with and without a context. I can't figure out why this is happening, but it happens consistently.

This looks like it's actually because editing a block puts a duplicate UUID in the region for that block. Once the duplicate UUIDs are in the default layout, they show up when cloning as each block is reassigned new UUIDs.

4) Text on admin listing page. "used on all paths without a specific layout" should be "used on all paths unless otherwise specified"

I'm not sure about this new text. It makes it sound like you can "otherwise specify" certain paths that wouldn't use the default layout. But there's no place to specify a list of paths, you just have to make new layouts at those paths.

All the other feedback is great and I'll work on implementing it. Thanks @BWPanda for the last update too, sounds like a good idea to be able to revert the defaults as well.

[quicksketch]

11) Conditions are missing when editing the default "Administrative layout". I wanted to change the admin layout to be 2 columns. But after doing so I instantly realized that I had a column on my layout-editing-layout, and wanted to add a condition for "not THIS path" but I can't :(

You can't put conditions on a default layout, because there would be nothing onto which you could fallback after the default. Instead, if you wanted to put a layout one everything except for one path, you'd duplicate the default, and put it at that path and change as needed. Due to the needs of different paths providing different contexts, you can't use a layout at more than one path.

[quicksketch]

Okay, updated the PR again with all recommendations from @jenlampton (except those noted in my last two comments). It looks like the ability to "Revert" a layout has gone completely missing. Though the code is all there, layouts modified are never marked as having been so. I'll take a look at this some time this weekend.

[quicksketch]

Alright, the last fix we have here is to make it so that default layouts are revertible. All the code was already in place, we just weren't updating the "storage" flag when saving. Once that was added, the reverting functionality reappeared and worked correctly.

[quicksketch]

@jenlampton and I have been reviewing this (and demoing) at Pacific Northwest Drupal Summit and HTML5 Developer Conference. Our PR looks in good shape and we haven't had any serious issues in the past 5 days. Let's get this merged and continue in the followup issue, and add more new issues as necessary (which has already begun).

[quicksketch]

I've merged in https://github.com/backdrop/backdrop/pull/483. Yay!! 6 months of effort and it's a great start. Let's start creating and handling followup issues in #345. Thanks everyone for their amazing contributions and input on this!

[klonos]

Great work everybody. Thanx.

...now lets try to break it. "Kicking the tires" is the expression I believe ;)