Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to create configurable layout templates #3755

Open
docwilmot opened this issue May 4, 2019 · 100 comments

Comments

@docwilmot
Copy link
Contributor

commented May 4, 2019

We should have flexible layouts in core.

Currently to create a new layout, you have to choose a template. Templates are provided in code, in a package with an info file and a tpl file, similar to modules or themes. So to create a new template requires some coding.

This PR allows creating a new template in the UI, by adding an unlimited number of rows, with each row optionally divided into preset columns. Each column a layout region.

There is another issue somewhere, but I cannot find it.

MVP (BLOCKER) TODOs:

  • Rename Columns to Regions everywhere (for consistent terminology)
  • Change Configure link in drop button to Configure regions
  • Change Edit from drop-button; use Configure name instead (edit means db storage is used)
  • Hide & automate row names (b/c they should not appear in the UI anywhere else)
  • Region names should start from 1 and not zero (Numbers should not reset per row.)
  • Region names should default to "Region 1" (region_1), "Region 2" (region_2), "Region 3" (region_3)
  • Make rows draggable to re-order
  • Add a unique icon to use for flexible layouts (can we change the color, maybe?)

ACTONIBLE TODOs:

  • Add ability to re-order rows
  • A single 'Add new row' button at the bottom
  • Dialog title for adding a row should be Add new row or similar
  • Move region names out of fieldset or open by default (b/c they do appear in the manage blocks UI)
  • Field label Change column style should be Number of regions (no style setting here)
  • Remove the Select number of regions option from the Number of regions select list; set the default to 1, and also select the first available option from the region widths.
  • Change text Column style to Column widths (no style setting here)
  • Change ratios to approximate percents in column width options
  • Change text Selected column style to Selected column widths (no style setting here)
  • Default drop-button action for flexible layout should be Configure regions
  • Use more intuitive text for Row width behavior options

NICE-TO-HAVE TODOs:

  • Style human & machine names like we do on the content types page admin/structure/types
  • Hide the Row width behavior field via #ajax
  • Change order of Row width behavior so fluid (most common) comes first, and is default.
  • Put the % widths inside the rendered row examples, remove text below.
  • Page title for Configure regions should use the template name
  • Add Back buttons and Cancel links to multi-step dialogs
  • Style region width selection to remove radios entirely (like we did with layout template selector on Layout settings UI)
  • Make the Number of regions select a set of radios instead, and have them be horizontally aligned next to each other (see mockups)
  • Rename the Region titles fieldset to simply Regions
  • Consider moving the Selected region widths setting into the Regions fieldset, as a description.
  • Move the Row classes, Wrapper tagm and Row width behavior elements into a Style fieldset to match the block confgiration UI.
  • Move the Style fieldset below the Regions section (since it will be used less frequently)
  • Merge icon and name columns on layout template list
  • HOLD: Style bulk operations on layout template list to match admin/content

NEEDS FEEDBACK TODOs:

  • Add a search filter to the layout template list (does this work with VBO filters?)
  • Move layout template list to new admin page admin/structure/layouts/templates & leave the more general "settings" page admin/structure/layouts/settings for general layout settings (like permissions)
  • Decide on language for more intuitive text for Row width behavior options
    • Maximum width for each screen size (adds the 'container-fluid' class)
    • Fixed width for each screen size (adds the 'container' class)
    • Full width of page (no row classes added)
  • Think about how contrib might be able to use this with other grid systems (e.g. https://getuikit.com).

FOLLOW-UP TODOs:

  • Automatically build a matching icon for each flexible layout template

Advocate for this issue: @klonos


PR by @docwilmot: backdrop/backdrop#2646

@BWPanda

This comment has been minimized.

Copy link

commented May 12, 2019

@docwilmot For the benefit of those not wanting/able to read through over 1,000 lines of PR code, could you please describe the feature request in more detail...? :-)

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented May 12, 2019

Reasonable, updated parent issue. (edited)

The current PRs UI is probably not terribly intuitive though. To create a new template, you go to the settings page for layouts module (not the configuration page for an individual layout), click add new template, give it a unique name, then you'll be directed to an interface similar to the layout drag and drop page (it's based on this, extending the editor renderer). Once you've finished adding all the rows, save, then this new template will be available in the configure page of all layouts. Use as normal.

@herbdool

This comment has been minimized.

Copy link

commented May 12, 2019

I like where it's going.

@jenlampton

This comment has been minimized.

Copy link
Member

commented May 14, 2019

I am so excited about this!!! Feedback follows :)

Layout settings page:
Screen Shot 2019-05-14 at 1 31 45 PM

  • We'll need an icon for the flexible layouts (maybe in a different color?)
  • There is a link Edit and a link Configure, but both of these save to config. Both should use the text Configure. Can we merge the two into the same form? If not, how about Configure regions vs Configure name.
  • These links should be in a drop-button.

Layout builder page:
Screen Shot 2019-05-14 at 1 36 34 PM

  • Status message should read "Layout template saved."
  • Button should read "Save layout template"
  • We should either change the Top region to Content, or start with the same regions as are in all the other core layout templates (header/content/footer).

Add row dialog:
Screen Shot 2019-05-14 at 1 41 17 PM

  • Dialog title should be Add Row instead of Add flexible layout template
  • I would prefer Select row style become two separate questions: Number of columns and Column widths
  • Use percentages for widths, instead of # columns, for the people who don't understand that our layout is a 12 column grid.
  • Change HTML element for row wrapper into Row wrapper tag to match block UI terminology
  • Change Container style label to Row width behavior
  • Change Container-fluid to Maximum width enforced for each screen size
  • Change Container to Fixed width for each screen size
  • Change No container to Always full width of page
  • Change order so fluid (most common) comes first, and is default.

Row / Region naming confusion
Screen Shot 2019-05-14 at 1 53 16 PM

  • The row name is displaying for regions
  • No way to define / change region names yet.
  • What if we added region name fields to the form, and showed a # of them equal to the # of columns selected (in the same way we can show the percentage options for that number of columns). These could be optional, but if left blank then we'd show the row name instead of region name (same behavior as now).

Configure Layout:
Screen Shot 2019-05-14 at 1 58 51 PM

  • Icons missing for selection area (mentioned above already)

Manage blocks:
Screen Shot 2019-05-14 at 1 59 39 PM

  • Nice, here the region names are row name + number. This is a better default than on the Add row page.

Other:

  • Layout description not used, unless I'm missing it?
@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented May 14, 2019

Thanks for the comprehensive review @jenlampton. I agree with all your comments. A couple of replies though:

These links should be in a drop-button.

TBH I'm not sure about the entire administrative UI for this PR, but I'm assuming you dont mind the "links within an icon" motif? But I think dropbuttons might look awful from within the icon.

Use percentages for widths, instead of # columns, for the people who don't understand that our layout is a 12 column grid.

I considered this, but some of the fractions arent integers if you do, like 10:2 = 83.333:16.666. Would we round to 83:17? Is that any more intuitive than 10:2 though?

No way to define / change region names yet.

I considered that, and it can be done, but wondered if it would be necessary, considering the region names arent exposed to the end-user.

Layout description not used, unless I'm missing it?

😄 there is a list at admin/structure/layouts/settings/flexible-templates. I did say the UI needs work. I don't know where to put a link to that.

@jenlampton

This comment has been minimized.

Copy link
Member

commented May 14, 2019

TBH I'm not sure about the entire administrative UI for this PR

Yeah, I saw your comment about that on the main issue, but I don't have any better ideas about where to put this.

But I think dropbuttons might look awful from within the icon.

Oh yeah, I hadn't thought of that...

some of the fractions aren't integers ... Would we round? Is that any more intuitive than 10:2 though?

Rounding is fine, even to the nearest whole number. It is more intuitive than 10:2, but only because 10:2 only has meaning if you know it's an abbreviation of 10/12 : 2/12. Which brings us back to the percentages :)

I ... wondered if it would be necessary, considering the region names arent exposed to the end-user.

I noted that as a problem as well. But if we make the region names visible (and hide the row names) to match all the other layout templates, then people will want to change the region names.

We could even kill the row names entirely, and use a random hash or something instead. Nobody will care what those are since they don't appear in the UI anywhere.

there is a list at admin/structure/layouts/settings/flexible-templates

Ooh! I missed that. Checking it out...

@herbdool

This comment has been minimized.

Copy link

commented May 15, 2019

What if in addition to the ratio we have a visual showing the column widths? Regardless I agree it should be two dependent dropdowns: number of columns and column widths.

@jenlampton

This comment has been minimized.

Copy link
Member

commented May 15, 2019

Maybe we could have a tiny example row? I was thinking about automatic thumbnails of the layouts - but that seems complicated...

@klonos

This comment has been minimized.

Copy link
Member

commented May 15, 2019

Thanks for doing the first round @jenlampton ...you beat me to it 🙂 ...very thorough 👍 ...here I go now 😅

  • We should either change the Top region to Content, or start with the same regions as are in all the other core layout templates (header/top/content/bottom/footer).

Renaming it to Content seems reasonable. Lets please keep things simple; 3 rows are enough to start with; people will be able add as many as they please now 🙂

  • Change Container style label to Row width behavior
  • Change Container-fluid to Maximum width enforced for each screen size
  • Change Container to Fixed width for each screen size
  • Change No container to Always full width of page
  • Change order so fluid (most common) comes first, and is default.

I say yes to this, but perhaps include the more "technical" versions of these things in brackets:

  • Maximum width enforced for each screen size (container-fluid)
  • Fixed width for each screen size (container)
  • Always full width of page (no container)
  • Row width behavior (container style)
  • These links should be in a drop-button.

TBH I'm not sure about the entire administrative UI for this PR, but I'm assuming you dont mind the "links within an icon" motif? But I think dropbuttons might look awful from within the icon.

Yeah, I saw your comment about that on the main issue, but I don't have any better ideas about where to put this.

I think that it's high time we switched from the tile listing to a table here. This would allow us to place the links in dropdown menus, within an "Operations" column (which is a common UI pattern we use elsewhere). It would also allow for a search/filter section at the top, which people could use to search the list of templates; and we could have filters like a select for 1/2/3 column layouts etc (I think that the D8 Layout Builder allows that too ...or maybe I am thinking Panelizer?).

...we can leave the template selection when editing/creating layouts still be a tile listing; that's fine.

Layout description not used, unless I'm missing it?

😄 there is a list at admin/structure/layouts/settings/flexible-templates. I did say the UI needs work. I don't know where to put a link to that.

See my comment above. Having a table would allow showing the description there (as well as allow for a column with a list of which layout each template is being used in).

  • There is a link Edit and a link Configure, but both of these save to config. Both should use the text Configure. Can we merge the two into the same form? If not, how about Configure regions vs Configure name.

Yes, lets please just merge the edit and configure forms into one, with the name/description fields being at the top of the region management UI (a-la #475). No need to have people jump into another form to simply rename a layout template.

Some other suggestions:

  • Move the "Only templates that are selected here will be available when configuring layouts." message at the top of the page in /admin/structure/layouts/settings. As it is now, as more layouts get added, this text gets pushed down, outside the viewport.

  • We shouldn't call them "flexible"; I'd prefer "custom" instead. Later on, perhaps we can allow core layout templates to be edited too; they would have an "overridden" state, and a "revert" action.

  • "Deleting the template will affect any layouts using this template." this confirmation dialog could use a list of layouts using it. If not used anywhere, is there any point in having a confirmation dialog? ...we could say "This tamplate was not used in any layout" in the confirmation message.

  • (follow-up to the previous point) What happens to layouts that were using a custom template when that template gets deleted? Do we switch them to another template? ...if so, perhaps have the user choose another template as part of the deletion workflow? Either that, or disallow deleting custom templates while they are being used.

  • Canceling a custom layout template deletion redirects to /admin/structure/layouts/settings instead of /admin/structure/layouts/settings/flexible-templates ...which is not a bad thing at all, if we decide to turn that into a table and include the operations drop-downs there.

  • When clicking the "Add row above" action, the drop-down is hidden behind the row (happens momentarily):

    Untitled
  • Nothing happens visually when you remove a row (either existing, or newly-added). You see the effect of the deletion only after saving the layout template.

  • The name of the layout template used for each layout in /admin/structure/layouts is a link. It currently leads to the configure layout form for each layout. Now I think that perhaps it makes sense to make it point to the edit page of that template.

That's it for now. Loving this ❤️ ...so much so, that I am tempted to set the milestone to 1.14 😄

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented May 15, 2019

Lets please keep things simple; 3 rows are enough to start with; people will be able add as many as they please now

Agreed, plus, once you've added new rows, they wont be necessarily at the "top" or "bottom" any more!

Maximum width enforced for each screen size (container-fluid)
Fixed width for each screen size (container)
Always full width of page (no container)
Row width behavior (container style)

I think these are too verbose, and still unclear; how about:

  • Fixed width (container)
  • Full width with margin (container-fluid)
  • Full width without margin (no container)
  • Row width behavior (container style)

I think that it's high time we switched from the tile listing to a table here

That would work nicely, especially if it mimics the layout list in appearance, but it would be a big change, would like to hear thoughts on that!

Yes, lets please just merge the edit and configure forms into one

I dont like this though, this UI borrows from the Editor renderer which builds the drag and drop block page for layouts: an initial page to create the layout and a separate page to configure it. And yes it matches other areas in core where you define a thing with its machine name, then you go somewhere else to configure it (menus, Views, etc). Plus, did I mention I dont like it? I think it would look awkward.

We shouldn't call them "flexible"; I'd prefer "custom" instead

I considered that, and I also dont really like "flexible" but "custom" is taken: thats what you'd call templates you make and store in /layouts, like custom themes or modules.

What happens to layouts that were using a custom template when that template gets deleted?

Good point; could swap them to whatever "Default layout" is using, or Moscone.

Nothing happens visually when you remove a row (either existing, or newly-added). You see the effect of the deletion only after saving the layout template.

Missed that. Fixable.

@olafgrabienski

This comment has been minimized.

Copy link

commented May 15, 2019

Wow, I also like the PR!

(My test page: http://2646.backdrop.backdrop.qa.backdropcms.org/test-page)

I've only one question at the moment: While adding rows to a test layout, I was wondering if I can reorder them, and it doesn't seem to be possible. Is that by design?

@jenlampton

This comment has been minimized.

Copy link
Member

commented May 15, 2019

Lets please keep things simple; 3 rows are enough to start with ... Agreed, plus, once you've added new rows, they wont be necessarily at the "top" or "bottom" any more!

👍

I think these are too verbose, and still unclear; how about:
Full width with margin (container-fluid)
Full width without margin (no container)

These options are less clear; a margin can be anything! I'd much rather have an accurate but verbose description that people will understand, than something that's too short and ends up cryptic.

  • Maximum width for each screen size (adds the 'container-fluid' class)
  • Fixed width for each screen size (adds the 'container' class)
  • Full width of page (no row classes added)

it's high time we switched from the tile listing to a table ... This would allow us to place the links in dropdown menus, within an "Operations" column

But we already have a table. and making "Which templates are allowed?" question into a giant table makes it hard to tell that it's even a question anymore.

we can leave the template selection when editing/creating layouts still be a tile listing

We can leave the template selection for enabling/disabling layout-templates too.

The tiles on the settings page are intended for one purpose: to enable/disable the layouts allowed, and to give people a visual cue (the tile) as to which is which. I think we should leave this interface as-is, and move all the other layout-template related things to the layout-template listing page, the one that's a table.

(That includes moving the action link Add flexible layout template -- or whatever we decide to call it -- to that page too)

lets please just merge the edit and configure forms into one

I have the same hesitation about this as I do with #475. It would only be an improvement with a simple layout. The same way that is only an improvement when you menu is less than 50 links long. When you have a complex layout, or a very long menu, you don't want those other settings on the same page, or in the same form.

Move the "Only templates that are selected here will be available when configuring layouts." message at the top of the page in /admin/structure/layouts/settings

This change isn't necessary if we use the existing layout-template table UI for everything this form element wasn't intended to do.

We shouldn't call them "flexible"; I'd prefer "custom" instead. ... I considered that, and I also dont really like "flexible" but "custom" is taken: thats what you'd call templates you make and store in /layouts, like custom themes or modules.

I agree with @docwilmot, having another namespace conflict for layouts would be a bad idea. * For WordPress these are called Divi Layouts. Can we steal that name?

  • This issue title calls them configurable layout templates. Would that work?

Now I think that perhaps it makes sense to make it point to the edit page of that template.

I disagree. I don't think we should take a tool people might have already been using and change it to do something else. It would be better to add another link.

What happens to layouts that were using a custom template when that template gets deleted?

Can we check and see if a layout-template is in use, and throw an error instead? I expect that this would be a mistake or an oversight 99% of the time. I'd prefer that we make people actively change their layout-template before they are allowed delete one that's in use.

I was wondering if I can reorder them, and it doesn't seem to be possible. Is that by design?

I expect this can be added, but it's probably not easy!


There's a bunch of great feedback in this issue already, but I want to stop us from having too many more good ideas until we get a round 2 of the PR. Otherwise, there will be too much to keep track of in these comments. (Maybe we can create a todo-list of changes in the parent issue?)

@klonos

This comment has been minimized.

Copy link
Member

commented May 15, 2019

But we already have a table. and making "Which templates are allowed?" question into a giant table makes it hard to tell that it's even a question anymore.

No it won't; we'll gray the disabled ones out, and move them to the bottom of the table; same as we do with the views listing for example 😉

These options are less clear; a margin can be anything! I'd much rather have an accurate but verbose description that people will understand, than something that's too short and ends up cryptic.

  • Maximum width for each screen size (adds the 'container-fluid' class)
  • Fixed width for each screen size (adds the 'container' class)
  • Full width of page (no row classes added)

There's a bunch of great feedback in this issue already, but I want to stop us from having too many more good ideas until we get a round 2 of the PR. Otherwise, there will be too much to keep track of in these comments. (Maybe we can create a todo-list of changes in the parent issue?)

Yes, I will go through all comments and make a tasks/ideas list in the issue summary. For the ones that we don't have consensus, I'll add a "Decide if ..." prefix 😉

@jenlampton

This comment has been minimized.

Copy link
Member

commented May 15, 2019

I will go through all comments and make a tasks/ideas list in the issue summary

Perfect, thank you!

For the ones that we don't have consensus, I'll add a "Decide if ..." prefix 😉

"needs more feedback" maybe? :)

we'll gray the disabled ones out, and move them to the bottom of the table; same as we do with the views listing for example

I think my resistance to this idea is that right now we only have one layout setting: "Which layout templates?" ...but the current page is a layout settings page (and not a layout template list) because we were anticipating having more settings for layouts. Especially as we start to expand layouts to match more of what panels provided.

Where do the other setting questions go, if we remove the layout settings form and replace it with a layout template list? Or do we remove the form now, but add it back later, when we have more layout settings?

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented May 31, 2019

The layout templates settings page admin/structure/layouts/settings, with a table instead of icons.
Still WIP, and havent sorted out default checked checkboxes for enabled templates:

Layout settings   PR 2646 backdrop backdrop testing site

@klonos

This comment has been minimized.

Copy link
Member

commented May 31, 2019

Looking good @docwilmot 👍 ...as always ❤️ you work!

Thoughts/ideas following...

@klonos

This comment has been minimized.

Copy link
Member

commented May 31, 2019

Screen Shot 2019-06-01 at 12 25 45 am

  • the page title could use the template name, so I know what I'm editing.

  • we could get rid of the 2 "add row above/below" actions from each dropbutton, and instead add "+ Add row" buttons; something like this perhaps:

    Screen Shot 2019-06-01 at 1 03 10 am

    ...this would also make the "Configure" operation the default. So win.

@klonos

This comment has been minimized.

Copy link
Member

commented May 31, 2019

...back to the layout settings page (layout template table):

  • we have removed the container/border from the bulk operations in the rest of the UI, we should do the same here

  • we could use a search filter

  • "Configure" should be the default operation for user-created templates

  • I don't see the point in having the layout icon be a separate column. Merge with "Name"

  • Make human names bold, and add machine names in a separate row. Like we do in the Views listing page

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented May 31, 2019

Thanks for the feedback. Not sure I like the 2nd screenshot in #3755 (comment), will see what everyone thinks, but it seems a bit more complicated than I'd like.

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented May 31, 2019

But I've just realised a serious weakness of my current UI: you cant edit column names in a row! 😮

@jenlampton

This comment has been minimized.

Copy link
Member

commented Jun 16, 2019

@docwilmot I've unchecked some of the previously-checked items on the master (top) list because they weren't working for me in the sandbox, but it occurs to me that you might have a more recent iteration that contains those changes... If so, I promise to re-check all the boxes when I can test it :)

@klonos

This comment has been minimized.

Copy link
Member

commented Jun 16, 2019

I dislike all the recent suggestions, especially the ones with links on the right. It makes the UI feel cluttered and overwhelming.

Awww 😞 ... 😄 ...but I said "quick mockups - think pretty +/- buttons instead". Perhaps I should actually finish my mockups if I want to "sell" my ideas 🙂

@klonos

This comment has been minimized.

Copy link
Member

commented Jun 16, 2019

...if we are going with the single submit button at the bottom for adding rows, can we at least move it to the right (left in RTL), so that it has a distance from the other submit buttons in the form?

@jenlampton

This comment has been minimized.

Copy link
Member

commented Jun 16, 2019

@klonos

This comment has been minimized.

Copy link
Member

commented Jun 16, 2019

I guess that we do have a pattern where such a button is to the left:

Screen Shot 2019-06-16 at 11 29 32 am

...the only difference there is that there is something in between to separate that button from the main submit buttons in the from.

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented Jun 18, 2019

I've got most of the important stuff done. Sandbox will surely need rebuiding after all tthese changes, but rushing off to work now.

@klonos

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

Absolutely loving this!! ❤️:

Screen Shot 2019-06-20 at 5 22 59 am

@olafgrabienski

This comment has been minimized.

Copy link

commented Jun 19, 2019

Wow, and reordering rows works now! Didn't test thoroughly yet, but looks goood at first sight.

@klonos

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

Wow, and reordering rows works now!

...aha! I did not realize that. Perhaps it'd be a better indication that this is the case, if there were crosshair drag handlers on the left of each row (right on RTL)? As implemented currently, the cursor changes to a crosshair when you hover over regions (which is why I missed it) - not when hovering over the row. This may give the false impression that regions can be moved around.

@klonos

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

...perhaps we should be using some text-overflow: ellipsis; on the regions:

Screen Shot 2019-06-20 at 5 35 24 am

Screen Shot 2019-06-20 at 6 42 57 am

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented Jun 20, 2019

At this stage, I need to bikeshed all remaining issues, unfortunately.

Add a unique icon to use for flexible layouts (can we change the color, maybe?)

Will need a designer person to handle this

Default drop-button action for flexible layout should be Configure regions

Not sure I agree; the default for other templates will be enable/disable, so why be different?

Use more intuitive text for Row width behavior options

Already discussed, not settled

Style bulk operations on layout template list to match admin/content

Not sure what this is asking for sorry

Style human & machine names like we do on the content types page admin/structure/types

Not sure what this is asking for sorry

Merge icon and name columns on layout template list

Doable, but necessary? (least difficult point)

Hide the Column style/widths field via #ajax

Not sure what this is asking for sorry

Consider moving the Number of columns setting into the fieldset, as a description.

Not sure what this is asking for sorry

Add Back buttons and Cancel links to multi-step dialogs

Need some advice here.

  • When adding a new row, we start with region widths dialog, so there will need to be a cancel button on the region widths dialog
  • then we move to the row config dialog. Should there be a cancel there, or a back? If cancel, should it reload the region widths dialog or just close the dialog?
  • When configuring an existing row, we start with the row config dialog. A cancel button should be there now, I'd say
  • then if you want to change the region widths as part of your configuring, you load the region widths dialog. In this process then, should there be a cancel button there, or a back button (see first point). And should that button go back to the configure dialog or close?
  • should we have both a cancel and a back button anywhere?
@stpaultim

This comment has been minimized.

Copy link
Member

commented Jun 23, 2019

This feels like a bug and I don't think I saw it addressed above:

When I click on "Disable" for any layout, custom or standard, it just takes me from admin/structure/layouts/settings TO admin/structure/layouts/. Nothing else seems to happen. No error message.

Layout_settings___PR_2646_backdrop_backdrop_testing_site

ALSO: When I use the checkbox and click "execute" it says that "At least one template must be enabled."

Layout_settings___PR_2646_backdrop_backdrop_testing_site

@stpaultim

This comment has been minimized.

Copy link
Member

commented Jun 23, 2019

By the way, I got my first real look at this today and am very impressed. Excellent work.

One other comment. I was confused by the "0" shown below. It would appear that the default region names are not showing up. If a user edits and changes the region name from "content" to something else, then the new region name shows up. But "content" never shows up, instead we just see "0."

Tim_s_Layout___PR_2646_backdrop_backdrop_testing_site

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented Jun 25, 2019

@stpaultim thanks for checking. The bulk operations doesnt work, youre right. The table was a "radical" idea at the time, so I just put something together to start and forgot about it. Most things on that table probably dont work.

Right now in a holding pattern till @jenlampton and @klonos clarify the recommendations above before I finish this off.

Thanks.

@jenlampton

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

Default drop-button action for flexible layout should be Configure regions

Not sure I agree; the default for other templates will be enable/disable, so why be different?

Drop-buttons are intended to be built so that the most-commonly used item will appear in the button, with all the less-commonly used items buried in the drop-down. For layouts that re not flexible, the most commonly used item is also the only item: "disable" when enabled, and "enable" when disabled. For a flexible layout, the most commonly used item will be Configure regions.

A good example of this change-in-drop-button-action-priority can be found on the Views listing. For enabled views the most common action is Configure but for disabled views it's Enable.

@jenlampton

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

Use more intuitive text for Row width behavior options

Already discussed, not settled

We know what we have there is not good enough for release, so let's choose something else that is, even if we know it's not perfect yet.

Why don't we start with these:
Maximum width for each screen size (adds the 'container-fluid' row class)
Fixed width for each screen size (adds the 'container' row class)
Always full width of page (no row classes added)

We can try it for a while and change it after we know how it feels.

@jenlampton

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

Style bulk operations on layout template list to match admin/content

The top of the admin/content page shows views exposed filters on a white background, with a gray border and rounded corners. Bulk operations are below, on the gray background.

Screen Shot 2019-07-05 at 4 36 16 PM

I think this page looks fine now as it is, but if we decide to add search or filters on here maybe we should revisit?

@jenlampton

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

Style human & machine names like we do on the content types page admin/structure/types

Our "Gold Standard" for displaying a Human name + Machine is as it's done on the content types page:
Screen Shot 2019-07-05 at 4 24 09 PM

We have an issue to add a theme function for this but it's not in yet...

For the time being, this request is to add the machine name in parens next to the human readable name, so on the http://2646.backdrop.backdrop.qa.backdropcms.org/admin/structure/layouts/settings page the name for the Drops Layer Layout template would be displayed Drops Layer (Machine name: drops_layer)

@jenlampton

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

Merge icon and name columns on layout template list

Doable, but necessary? (least difficult point)

Necessary, no. Improvement, yes.

We need to remove the column heading 'Icon', and if possible, squish that column so it's the appropriate width (so the Name is right next to it's icon) -- this will help improve the experience of scanning the page. It's usually easiest to do both these things by moving the icon into the other table cell.

@jenlampton

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

Hide the Column style/widths field via #ajax

This looks like it has been done already -- or at least -- the need for it has gone away. The Region widths selector is really slick now. 👍

Screen Shot 2019-07-05 at 4 46 29 PM

@jenlampton

This comment has been minimized.

Copy link
Member

commented Jul 6, 2019

Consider moving the Number of columns setting into the fieldset, as a description.

The text from the Selected region widths form element could be moved (as a #description) into the Regions fieldset, along with where the region names are defined.

For example:
Screen Shot 2019-07-05 at 5 05 54 PM

@jenlampton

This comment has been minimized.

Copy link
Member

commented Jul 6, 2019

Add Back buttons and Cancel links to multi-step dialogs

When adding a new row, we start with region widths dialog, so there will need to be a cancel button on the region widths dialog ... then we move to the row config dialog. Should there be a cancel there, or a back? If cancel, should it reload the region widths dialog or just close the dialog?

A Cancel link should cancel the whole thing and close the dialog. We could add a Back button too, that would go back to the region widths dialog.

When configuring an existing row, we start with the row config dialog. A cancel button should be there now, I'd say

Sounds good.

then if you want to change the region widths as part of your configuring, you [click on the link to] load the region widths dialog. In this process then, should there be a cancel button there, or a back button (see first point).

Interesting. I think the problem here is that the button on this dialog reads "Continue" as though it were in a sequence. If it were to read "Save region widths" then both the Save button and the Cancel link could return the user to the row config dialog. No need for a back button here.

should we have both a cancel and a back button anywhere?

Maybe we should try it with only Cancel links and see how that feels before we add Back buttons?

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented Jul 7, 2019

Mostly done with the todos

Consider moving the Selected region widths setting into the Regions fieldset, as a description.

I've left this off for now. I dont think it works well with the collapsible fieldsets.

Decide on language for more intuitive text for Row width behavior options

I've trimmed the text a bit, since it was too long and the resulting select element was extending outside of the fieldset and dialog width.

@stpaultim

This comment has been minimized.

Copy link
Member

commented Jul 7, 2019

@docwilmot - Are you aware that the latest sandbox is not working. I'm getting errors when I visit the settings page - admin/structure/layouts/settings

I'm pretty sure that I was able to use it yesterday.

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented Jul 7, 2019

I suspect I saved a dpm() in there somewhere. Out getting some exercise, will check later.

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented Jul 7, 2019

The settings table is working now.
But I've removed the operations fieldset in favor of a submit button as I dont think operations would work in this context. We cant add any other actions to operations apart from enable and disable because those are the only actions that would be applicable to any group of templates. For example you cant select all the do "Configure rows" or "Delete", so in the end it would do excatly the same thing as a submit button. Except with an extra click

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2019

I think I've got all important the code written now. Now I'll do cleanup and move the flexible template.inc code to admin.inc where it belongs, and then write tests. Got 2 months to get that done! I think this might make it.

@docwilmot

This comment has been minimized.

Copy link
Contributor Author

commented Jul 10, 2019

Last commit was more of a major renovation than a cleanup. Sandbox will need rebooting.

I'm thinking though before merging everything into admin.inc would be good to have a "code concept review" from @quicksketch. This PR, I'm just thinking, sort of abuses the Layout class in some ways, and would be good to get the concept vetted, and maybe ideas of any other way it should could be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.