Dnn.platform: RFC: Add a Layout Concept to Themes; Skin / !!Layout!! / Panes / Containers / Modules

[jeremy-farrance]

Note: the original idea was put forth in a FB discussion by Sebastian and it is quoted in full in the comments below. - Jeremy

Description of problem

Both custom and commercial skins try to solve this by delivering skin (ascx) files with dozens of variations of Pane layouts. Depending on the version of DNN this can be hard to work with or confusing and often unattractive. Porto does a nice job, but it is not intuitive for new users (people need to 'get it' without having to be shown how it works (at least the majority of the time)). And since DNN 9+ lost the ability to show the names of the Panes in the layout, things have gotten worse in some cases.

Description of solution

I don't have a clear or concise idea on how this should be implemented. One option would be to create something that follows the same patterns we are used to with skins, panes, and containers and remains compatible (things should work as they do now without adding Layouts becoming a requirement OR if you choose to add layouts, your existing Panes and Containers should not require modification). So we would have another folder /layouts that would have things like Layout50.ascx (and therefore Layout50.css). The skin.ascx would allow both Layouts AND Panes to be defined though the premise would be to encourage layout structure using the Layouts.

Though some of this could be done with simple #includes, the key here is to bring this forward to the UI and the content and site managers. When the user is in edit mode they should be able to Add Layouts or maybe if indicated in the Skin, be given a choice between 2 or 3? Maybe via a dropdown?

So in essence, a Layout is a predefined, structured arrangement of Panes. Once a Layout is selected, the normal process of adding Modules in to Panes remains unchanged.

Additional context

There are a lot of ways to approach this. The correct solution needs to focus on enhancing the user experience in DNN while keeping things fairly simple and very "in line" with current theme development processes. Lets not disrupt existing skill sets for what could conceptually be a simple and logical addition to the current system.

It seems like some or many may have previously thought through or even experimented with some variation on this idea. But I could not find it. Hopefully others will have ideas and input?

Affected versions = ALL

Affected browser = ALL

[mitchelsellers]

I think this is a great idea, I don't have a solid solution for it yet, but it is a great concept.

One other thing that could work, is to allow a pane to be "split" by using a standard method. For example if we adopt bootstrap as the UI layout, it would be easy for DNN to dynamically split a 100% width pane into 2 50% columns. etc.

[sleupold]

@Accuraty
Thank you for writing it down :)

[jeremy-farrance]

From a FB discussion, the original comment/idea put forth by Sebastian Leupold:
"I would love to get a "contentPaneLayout" option for skins, you may select in page settings. The layout would get injected on top of the content pane to adds the panes needed for the content of the page. This would eliminate pages with dozens of possible panes in all combinations or multiple skin pages for the different layout to place modules."

I would like to add to that - I think these added Layouts should work just like modules and stack. Which means they also need the ability to be moved Up/Down/Top/Bottom. So in essence (and this might need a re-think), the Layout would be put in to a Pane which is ultimately just a vertical column with expandable, infinite height.

It is also interesting to consider... could a Container be useful and applied as a wrapper around a Layout?

[mitchelsellers]

@Accuraty That pretty much sounds like the concept I was talking about.

I think the key struggle here will be retaining responsive design, when we have no control over the framework being used

[sleupold]

@mitchelsellers that's why I am suggesting the layout to be part of the skin package, which should know how to deal with screen width (depending on using Bootstrap3, Bootstrap4 or any other grid or scheme)

[mitchelsellers]

@sleupold Ah, ok, so it would be fixed, but from the theme designer? That seems like a logcal compromise.

[valadas]

I am against using a css framework (bootstrap or other) within the core, designers should make that choice in their skins. In my opinion if we do need to make columns or some such in the core, then we should use css grid and/or flexbox.

[sleupold]

@valadas please read my previous comment.

[ohine]

We worked with a few community members and built a proof of concept years ago. It was handled completely as a skin, but we could further improve the concept with a few core changes.

The way we went about it was to utilize the recently removed layout mode to trigger the additional ui elements to define custom layouts. These were configured on the fly by adding rows and columns, then saved to the skin folder as a template for reusing the layout elsewhere.

I’d like to take this a step further and also build in the ability to select the base colors used to generate the theme, adjust any headings from 1-6, and a few similar settings on containers as well.

This would greatly improve the usability of building out a site or changing the layout without adding 100s of tiny variations as an entirely new skin or container.

[valadas]

@sleupold

@valadas please read my previous comment.

I was referring to Mitchel comment:

One other thing that could work, is to allow a pane to be "split" by using a standard method. For example if we adopt bootstrap as the UI layout, it would be easy for DNN to dynamically split a 100% width pane into 2 50% columns. etc.

It is easy to use standard css to divide columns, no need to bring a css framework into the platform. That should be the responsibility of the designer to choose his framework of choice.

[jeremy-farrance]

My strong feeling on the matter (as a 12+ year veteran of being a DNN integrator in an all-custom design shop): leave as much as possible to the responsibility of the designer (front-end developer).

[sleupold]

I am voting as well to make this a skinning option, i.e. a feature to be provided by the skin designer, If it is file based, admins may remove a layout or clone an existing one, as needed. But if every page author would be able to create a pane layout dynamically, each page would look differently and might not properly adjust to browser width.

[OllyHodgson]

As a point of reference, DNN Evoq has something like this already. It take the form of a module, called "Grids". You add it to a page and it carves that content pane into a preset number of smaller content panes. You can add modules to those as normal. As long as you're using Bootstrap 3 (or your theme defines compatible classes) it's responsive - adjusting to suit the screen size.

It's a bit limited and doesn't have much in the way of configuration. As a proof of concept though, it gives content editors the ability to layout a page in much more interesting ways than would previously have been possible.

If skin developers could provide templates for such a module, I suspect it'd go a long way towards answering this requirement.

[jeremy-farrance]

I do think getting "Layouts" implemented as both a skinobject and a module (think DDRMenu) gives us a great deal of flexibility. Sounds like the only thing missing is the UI and permissions... so we can admin/config who can change the layouts and also which layouts are available/visible to that page.

[sleupold]

I would expect layouts to be part of the skin package - provided by the skin designer but easy to customize. Most admins don't want page editors to define any layout themselves - this may look awkward and may interfere with responsibility of the skin. But if the skin designer provides a sample and the layouts are just files in the skin folder (or layouts subfolder), it should be easy to customize and much easier to handle than current skin variant or skin files with dozens of panes included.
In my idea, layouts would just be an additional selection on the "Themes" PersonaBar extension and in page settings.

[valadas]

There appears to be a general agreement that this should be a responsibility of the theme, we do not want to enforce a specific framework at the platform level and we don't want to break existing themes. With all that in mind, does someone have plans to build a new theme with that functionality ?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Timo-Breumelhof]

Ok, here's my take on this.
I look at this a bit differently TBH (If I misunderstand the issue please et me know)
IMO we already have this built in as in essence an ascx is a layout.
I solve the layout issue by building all of my skin with includes (head, panes footer etc.) and just create separate ascx files, with a different "panes" include for each layout.

I do find it an issue that setting the page layout (read ascx) is not easy enough to access in the CP in these kind of scenarios

What I would really like though is Pane settings.
The main purpose would be to change the class of a pane and / or data attributes.
This way you could allow an admin to select a width, background color etc. for a pane.
When these settings would be available/editable through webapi, users could even create custom links/ drop downs etc, to interface with it.
It would make DNN even more flexible and easy to manage IMO.
After creating a lot of DNN skins, this would be second on my wish-list for changes (regarding themes / manageability of layout) after "a direct container selector in the module actions".
Third would be skin settings BTW. :-)

[jeremy-farrance]

I really love the Pane Settings idea, that would be very useful and I can see that it would fit with what we already have in place. But it seems like it solves very different problems from what is presented here. It still doesn't solve the existing problem of "layouts." There has to be a way for Theme (AND Content) Designers to have flexible layout options without the Theme designer/developer having to either 10 different skins or worse, one skins with rows and rows of Panes in all kinds of layout variations (the vast majority of which don't get used on many pages).

Again, repeating from the original post above, the important thing here is to give Roles based access to these features in the DNN UI. I don't want to lose site of that. Its one thing to implement this kind of thing for Theme designers/developers in a way that doesn't break things and is useful, but ultimately it has be available to the Content and Site Manager users.

Additional opinion: I think we should take a liberal and open-minded look at other CMSes as well as the popular site builders (Wix, Squarespace, etc.). There is always low hanging fruit and it would be nice to get ANY of these features or ideas in place in the near term while working towards a goal (even if slightly vague so far). And don't get me wrong, I realize how hard it is to predict where Bootstrap or any useful framework will be on the "cool-kids popularity lists" as the months and years go by - but we need to take a few steps forward soon.

[Timo-Breumelhof]

"I really love the Pane Settings idea, that would be very useful and I can see that it would fit with what we already have in place. But it seems like it solves very different problems from what is presented here. It still doesn't solve the existing problem of "layouts." There has to be a way for Theme (AND Content) Designers to have flexible layout options without the Theme designer/developer having to either 10 different skins or worse, one skins with rows and rows of Panes in all kinds of layout variations (the vast majority of which don't get used on many pages)." I'm sorry, but I don't see the difference between having "10 layouts" and 10 ascx files? Maybe I'm missing something (I mean the end result, not the interface)?

BTW, my Panes settings idea would be to create as an example "a skin with 5 panes and let the admin decide what classes and width each of them gets". If these would be accessible via webapi, one could create a dropdown (at the top of ascx for instace) that sets them all to a certain value and thus layout. Or we could create a Skin object for it.

[jeremy-farrance]

Have you used Porto or other commercial themes? They tend to build in dozens and dozens of layout options by include row after row of variations that mostly sit there unused. Example:

[Timo-Breumelhof]

@Accuraty ok, maybe it's good if I show you how I improved on that. Ping me if you are interested :-)

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[jeremy-farrance]

I do think this concept is valuable, has merit, etc. But obviously with available interest and resources, maybe we can come back to it after we get to v10 or a .NET Core version of DNN? Cheers!