Now we have the very basic implimentation of Responsive Panels in 7.x-3.x we have to refine this and make it actually work properly and that means having some configuration.
I have come up with an idea of how this can work (by work I mean be reasonable UX). There are lots of ways to make it work, but making it usable is the most important goal, so as to not confuse the hell out of everyone.
At a rough estimate there are 142 layout variations (I will call these "options") for the 13 Gpanel and Panels Layout Plugins. This is a LOT of stuff to manhandle into a UI.
Here is my basic idea, but first open up the attached screenshot in another tab, this will make much more sense:
1) Select the column count of the panel (e.g. two col, three col etc)
2) Select the Device Orientation (e.g. tablet landscape)
3) Select the layout option
You will see that for two column layouts there are only 2 options, however for the 3, 4, 5 and 6 column layouts there are progressively more options - this is very cool and allows us a huge variety of layouts.
In theory this sounds really easy, in practice its still a lot of UI to grasp all at once, so I have utilized evil collapsible fieldsets to hide stuff until you need it.
I have also NOT included any options for the Standard or Smartphone Portrait breakpoints - it just doesn't make sense to because the Standard layout will always take the default layout option and Smartphone Portrait will always display any panel layout in one column (all panes stacked). It doesn't have to be like this, however we have to trade complexity for usability at some point, so not including edge-case-like options means these things are removed from the UI, and we make sensible default decisions instead.
I have attached a screenshot of the first iteration of the this idea, please give feedback and some ideas on this, I think this can work, but if you have a better idea I would love to hear it.
| Comment | File | Size | Author |
|---|---|---|---|
| at-panels-ui-test-1.png | 192.5 KB | Jeff Burnz |
Comments
Comment #0.0
Jeff Burnz commentedUpdated issue summary.
Comment #0.1
Jeff Burnz commentedUpdated issue summary.
Comment #0.2
Jeff Burnz commentedUpdated issue summary.
Comment #0.3
Jeff Burnz commentedUpdated issue summary.
Comment #0.4
Jeff Burnz commentedUpdated issue summary.
Comment #1
jthomasbailey commentedSeems logical enough
Comment #2
andypostI think a different approach
1) device orientation - this could be at variant selection
2.1) layout and column count - panels already have layout but I think having configure option could be useful
2.2) panels' flexible layout editor approach could be used for choosing column count
Comment #3
Jeff Burnz commentedandypost - sounds like you think this is in Panels - which is an ideal approach if the entire layout is handled by Panels, we're not at that point yet, and probably won't be in the core theme for D7.
Right how the theme handles layout and media queries, Panels is merely a way to use the layouts supplied by the theme, but the actual responsive CSS is generated by the theme in reaction to 1) your breakpoints and 2) the layout option you select. It would be cool to pass this stuff back from a configuration screen in Panels, but again, only if if the entire layout is handled by Panels, aka Panels Everywhere-esque type approach.
Comment #4
andypostI suppose in case of panels (not panels everywhere) the layout is a layout for panel placed within main region of theme. I call it panels-layout plugin and think this has own number of regions inside to place panels content.
So another approach - we can have a number of settings per panels-region and pane - a style-plugin (in terms of panels) with some settings that could be translated to responsive CSS rules. But primary panel layout currently has no settings just a number of rows|columns and I think we could add the setting for layout plugin to produce a CSS rules
Comment #5
Jeff Burnz commentedAh, but you are forgetting about Gpanels and that they are handled by the the same settings and CSS, not everyone wants to use Panels, and I am not wanting to build two approaches, the latter of which you describe sounds like a lot of UX issues if not a mountain of code to make it work. Not really interested in going there at this stage, one day yes, but I tend to think Panels itself will evolve to include these types of features natively (robust mobile dev support).
Comment #6
Jeff Burnz commentedThis just went into 7.x-3.x, so the big commit has been made. Marking as fixed, the initial implementation is done.
Comment #7.0
(not verified) commentedUpdated issue summary.