Problem/Motivation

Currently the layout settings UI has some problems:

  • Multiple select for all the CSS class options is quite confusing
  • UI is almost unusable in Page Manager (you really have to be careful to not loose already selected CSS class options when selecting new ones) - also see attached scrrenshot
  • Right now it is possible to select multiple CSS classes for a single breakpoint (e.g. .col-sm-6 and .col-sm-3 even though only one value for one of the settings groups would be applicable

Proposed resolution

  • Rework layout settings UI for CSS classes - What about using a single select for each breakpoint and CSS class group. This would only allow one single value per breakpoint and users may see the whole configuration at once. All these select elements may also be displayed in a table or collapsible fieldsets to group relevant options together.

Remaining tasks

  • Discussion about what kind of presentation would solve all needs
  • Propose a patch to Rework layout settings UI

User interface changes

  • Rework of layout settings UI to be able to configure CSS classes better

API changes

Data model changes

Comments

hctom created an issue. See original summary.

hctom’s picture

Issue summary: View changes

I'd appreciate your feedback/discussion on this, so I may start building a patch that solves these UI/UX problems

markhalliwell’s picture

StatusFileSize
new13.23 KB

See: #2784265-10: Refactor module to be plugin based and allow template settings

Suffice it to say, yes, I want to create a dynamic UI (similar to that of what Omega did) to allow easier grid manipulation (via sliders). I was also imagining that each "column" would have a gear icon (like contextual links or something) that would allow additional classes to be added (everything else not related to columns).

markhalliwell’s picture

StatusFileSize
new16.16 KB

Forgot to include the breakpoints toggles:

markhalliwell’s picture

Assigned: Unassigned » markhalliwell

P.S. I was also planning on doing this (eventually) since I'm pretty good with JS. However, if you feel up to starting/implementing it, please just re-assign yourself to the issue so I know not to continue.

markhalliwell’s picture

Title: Rework layout settings UI » Dynamic UI

I went ahead and create the 2834675-dynamic-ui branch (see sidebar and what's new on d.o).

I also went ahead and allowed you to write to the repo (for this new branch only please).

hctom’s picture

Your prototype looks nice, but I am not really sure, if this will be good for all use cases. What about e.g. having a three col layout that should be switched over to stacked (first line full width column, second line half width columns side by side). With this UI you won't be able to get this done, because, I guess, it always keeps the total number of columns fixed to 12, right? I know this is really a special case, but there might be more like unimportant columns that will be hidden completely on smaller breakpoints to make room for other columns.
But if this kind of UI should be used, there need to be one more control to handles the offset (I guessed that the +/- controls in your prototype should only be used for reordering even though you have "Offset" in their name).

I'm really not sure, if there shouldn't be a simple select element driven rework first to get this into the module as fast as possible. And after that, there might be a JavaScript widget thingy (I'd propose the use of Backbone to get it constructed) on top of it, that "only" pulls the right triggers when sliding things around.

I'm looking forward to read your feedback on these objections.

markhalliwell’s picture

StatusFileSize
new37.98 KB
new51.04 KB

I was actually thinking we'd just add the necessary regions to mimic what's shown on the the preview images:

The above is for bricked, but we could easily take out the middle and bottom columns for a "stacked" version as well.

While the "full width" regions are typically col-sm-12, yes, I was imagining that a user could override this when they click the gear to show a modal for advanced options:

edit: don't mind that all the dropdowns are "12", it was just c&p

hctom’s picture

Okay, I'll take some time this evening and just build the "normal" select/checkbox elements version of this (so to say, almost the UI you proposed in your modal, but without the JS and the modal, hehe). When this is done, all the JS magic can be added that leverages/switches these fields.

I will push the changes to the branch you opened and then you can have a look at it.

Just some quick questions/notes before starting:

  • Currently only the whole class options array is alterable. I'd prefer to split this up into several options arrays (each with an own method to retrieve and an own alter hook).
  • Does it make sense to allow altering the number of total columns (as Bootstrap allows you to use other than 12 columns)?
  • Should the sizes array (xs, sm, md, lg) be allowed to be altered? This might be handy when you want to add other breakpoints such as xxs or xl, xxl etc. - or even completely other custom breakpoint identifiers that leverage the mixins for Bootstrap grids
  • Does the layout itself really has to be allowed to get all the region size/offset/push/pull classes?
markhalliwell’s picture

Assigned: markhalliwell » Unassigned
StatusFileSize
new47.54 KB

Currently only the whole class options array is alterable. I'd prefer to split this up into several options arrays (each with an own method to retrieve and an own alter hook).

Yes. Let's go ahead and create specific methods/alters for these. I imagine the current method/alter that exists will be used for "additional classes" or something?

Does it make sense to allow altering the number of total columns (as Bootstrap allows you to use other than 12 columns)?

Should the sizes array (xs, sm, md, lg) be allowed to be altered? This might be handy when you want to add other breakpoints such as xxs or xl, xxl etc. - or even completely other custom breakpoint identifiers that leverage the mixins for Bootstrap grids

For now, let's just work with the defaults. Adding configuration for these should probably be added to https://www.drupal.org/project/bootstrap_core since they're site wide settings and multiple things can use them (e.g. themes, this module, etc.).

Does the layout itself really has to be allowed to get all the region size/offset/push/pull classes?

Yes. In some advanced cases the layout itself may need to be assigned these classes. By default we'd just add row and clearfix.
I was imagining that the entire layout would also have a gear:

---

Keep in mind that this is, essentially, removing the need for all the vertical tabs per region and allowing this entire layout to be configured from the "Layout settings" one.

markhalliwell’s picture

sylus’s picture

Just adding in case is relevant :)

https://www.drupal.org/project/gridstack

markhalliwell’s picture

Yes I saw that module, but it seems to be focus primarily around fields/images/media and has a hard requirement on https://www.drupal.org/project/blazy (also created by same user).

It's unfortunate that the user took the "gridstack" namespace because the library is rather abstract and can be used for anything.