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-6and.col-sm-3even 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
| Comment | File | Size | Author |
|---|
Comments
Comment #2
hctomI'd appreciate your feedback/discussion on this, so I may start building a patch that solves these UI/UX problems
Comment #3
markhalliwellSee: #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).
Comment #4
markhalliwellForgot to include the breakpoints toggles:
Comment #5
markhalliwellP.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.
Comment #6
markhalliwellI went ahead and create the
2834675-dynamic-uibranch (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).
Comment #7
hctomYour 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.
Comment #8
markhalliwellI 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
Comment #9
hctomOkay, 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:
Comment #10
markhalliwellYes. 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?
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.).
Yes. In some advanced cases the layout itself may need to be assigned these classes. By default we'd just add
rowandclearfix.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.
Comment #11
markhalliwellComment #12
markhalliwellPossible solutions:
gridstack.js
https://github.com/troolee/gridstack.js
https://github.com/troolee/gridstack.js/tree/develop/doc
https://jsfiddle.net/xlaptop2001/of7syvwx/
jQuery GridManager
https://github.com/neokoenig/jQuery-gridmanager/
http://neokoenig.github.io/jQuery-gridmanager/demo/simple.html
(note: not sure about this one, it seems to imply content editing)
Comment #13
sylus commentedJust adding in case is relevant :)
https://www.drupal.org/project/gridstack
Comment #14
markhalliwellYes 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.