Page layouts

Topics: Administration
Aug 18, 2013 at 8:42 PM
Perhaps a stupid question as I don't know the full history on design decisions here...

The layouts / widget templates seem like a pretty powerful tool to do things, but the interface for working with these seems archaic. It is by far the most glaring reason I can't subject my content authors to Orchard (event though I'd love to force them to...).

Is there any plan for rectifying this?

My desire from a workflow perspective would be something along the lines of what Sitefinity does for page editing (Whch I think they nailed from a workflow perspective). Essentially:
  1. Page properties drop content field.
  2. Each page has an implicit layer.
  3. HTML Widget introduced to replace Page content field.
  4. Editing this layer is a more inline affair. Widgets can be drag and dropped for ordering.
I'm just starting to look at Orchard, so I don't even know if I'm asking for the moon here... I also realize that this makes Pages a 'special' content type, which may be what you are avoiding going this route, but it makes sense from a web CMS perspective for that to be the case I think...

I'm just curious if some sort of UI changes are on the roadmap to be redone at some point. It seems the basic architecture would support this kind of workflow, though of course it would require a large outlay of effort to accomplish.
Aug 21, 2013 at 6:30 AM
Hi,

I also work a lot with Sitefinity. Indeed, constructing page is easy from there, but I think Orchard uses a different concept for this.
So I came accross a theme in WordPress that has this layout builder.

Image

That looks pretty nice and I wonder if it would be difficult to create such a plugin.

Anyway, would be nice to have some more flexibility regarding dynamic pages.
Developer
Aug 21, 2013 at 10:36 AM
Not exactly this but you may want to look at the modules Contrib.Widgets and Content Widgets.
Aug 21, 2013 at 7:10 PM
Edited Aug 21, 2013 at 7:11 PM
Piedone, I don't think those hit the point I'm trying to hit... Admittedly, I'm spoiled by Sitefinity's simple content editing interface, and I'm looking to see if it would be POSSIBLE to build Orchard function along those lines.

After poking around a bit, and understanding a bit more of the idea behind content types and such (I think), I'd modify my idea to something more like this I think:
  1. Every addressable content type gets an implicit layer (I'm not sure how the layering system works, if having hundreds of layers, but only a handful of applicable ones to any given type, would be a performance issue or not). This way, "Page" is not special in any way, and a layer applied to a blog's URL for instance would allow for adding other widgets around the blog post list for that blog, etc.
  2. Page drops the content field, and becomes essentially a metadata holder for a layout, providing just a URL, etc. Actual EDITING of the CONTENT of the page is actually editing the implicit layer for that page, where a user can add widgets of any given type (Like HTML Widget, etc.). This basically creates TWO edit forms for every content type: The current one (Content type properties, e.g. Page info, Blog info, etc.), and a new one that allows for editing the implicit layer for that content type.
  3. The current "Layers" editing screen gets relegated to editing just "global" / "shared" layers, and not the implicit ones for a given content type (I wouldn't even show them here, or make them optionally viewable, etc.).
  4. Having a way to have a special kind of widget that can be added to a layer that will create zones that can then contain widgets would be nice too. This would allow content authors to create add pre-defined sub-zones to content zones. Essentially a developer would create predefined widgets that specify the HTML to wrap a dynamic zone, and a developer can choose to add a "three column" or "2 column" or "66% / 33%" widget to an existing layout zone, and the layer editor would pick this widget up and allow for adding widgets to these new zones.
This is a Sitefinity thing, and you can see how they do it... which I THINK is doable with your current architecture in theory, and would add a TON of capability for content authors. It also allows us poor developers to predefine some things for content authors that may not be technically oriented, so they can easily layout a page layer without needing to know HTML, AND would allow them to drop widgets into ares they otherwise wouldn't be able to.

This is very close in idea to plompd's "Amazing Layout Constructor", but can be used on a per layer basis. To start, just doing code-defined layout widgets would be fine, without having to have a UI to edit the layout widget's settings, etc.

Issues:
  1. There appear to have to be two types of layers here though: the layer for a unique item (e.g. each page has its own layer, each blog has its own layer, etc.) and layer that should be shared by contained types (e.g. blog posts you wouldn't want to specify the same layer for every single one every time, you'd want it to either inherit from the individual blog layer, OR be able to specify a shared layer for all blog posts in a given blog, etc.). I don't think this is insurmountable, and I think the functionality is already there to DO this (e.g. using the url /blogs/myblog/* for wrapping all posts of a given blog?), I just don't know how you would do the UI for it.
I'd assume the "containable" part could be leveraged to have a "edit layer for this blog post" and a "edit layer for all X blog posts" button so you can handle both cases for containable items... but then I don't really know exactly what the limitations are there.
  1. Search. For instance, an HTML widget in a layer for a given page should be indexed at the PAGE's URL, not it's own. In fact, I'm not even sure that an HTML widget should be addressable at all, but I don't know what the architecture says about that... This gets even more complicated when I have a PAGE that I am defining a layer for that has two widgets for two different types... e.g. when I have a blog list widget on a given page, and document list widget or something on the same page, the SEARCH would want to return the URL slug for the blog, or the URL slug for the document list widget, when it should PROBABLY return the URL for the containing Page instead. This may be an existing issue in general with content types, and I haven't played with search to know what the functionality is here...
==

Thoughts? I believe all of the PARTS are there to do this, and it would add a metric ton of usability to Orchard (which of course, means there's a lot of work to be done to do it...). Am I missing anything that would be a major concern here? Good idea, bad idea?
Coordinator
Aug 21, 2013 at 7:45 PM
We have plans and design ideas for doing something like this. The current widgets behavior will still make sense, as they provide rules based positioning for content. But we now people also want placed content capabilities per content item, edit their own layout per content item, and all of this drag & drop.
Aug 21, 2013 at 8:02 PM
@i8beef: nice wrap-up. I think it could work indeed.
@sebastienros: is there any way we could contribute/review/comment on the plans and design ideas for this feature?
Coordinator
Aug 21, 2013 at 8:10 PM
I will post a design/feature proposal on this forum as it's done for most major module which require feedback or approval. I am also organizing informal skype chats with people concerned on specific subjects, before doing these proposals. If you are among them we can do that.

I have already talked about this module with Bertrand, Sipke, and maybe Nick/Ylan but I am not sure anymore.
Aug 21, 2013 at 8:13 PM
That would be great.
I had a dutch chat with Sipke and we briefly discussed this, so I think he could be the guy ;)
Aug 21, 2013 at 8:26 PM
I am willing to throw my hat into the ring to work on this as well if help is desired. I firmly believe Orchard is the best platform for my personal future needs, and am willing to put in some elbow grease.

If nothing else, I would love to be in on the design phase / commentary phase as well.
Coordinator
Aug 22, 2013 at 3:14 AM
I built an implementation of something close to what Sitefinity has for a customer. It still needs some work but it's already being used successfully on large public-facing sites. The customer is willing to make the module public, but these things take time.
Aug 22, 2013 at 3:45 PM
I thought of another possible issue with my proposed design:
  1. Drafting / publishing workflow. Because Layers would take a direct role in the content editing process at this point, some sort of mechanism for having "draft" layers would need to be implemented, and on publish, all widgets would need to be published as well. This way, someone could edit the Layer for a page, edit the various widgets they might want to change and save those as drafts, add new widgets, etc., but until a user publishes the current work it probably shouldn't show up in the actual site. This would require a layer itself to have a draft state.
Bertrand, would you be willing to give a few more details on your implementation?
Coordinator
Aug 22, 2013 at 8:14 PM
Edited Aug 22, 2013 at 10:22 PM
Using actual layers for each content item sounds crazy and goes way beyond what layers were designed for.

My design adds the idea of a template that has a layout (rows and columns that you can arrange and nest any way you want, using a simple grid system) and elements placed inside this layout. Those elements can be parts and fields, but they can also be simpler things such as images, text, links or containers. Think of it as super-placement, from the admin, where you can place all kinds of shapes around the whole layout, in a wysiwyg fashion.

When you edit an item that has dynamic layout, you get a live preview of what the item is going to look like on the front-end.
Aug 23, 2013 at 6:34 PM
The design I'm proposing in this thread. As I had said in the OP, I do not know the history or intents here, and was simply proposing a way to use the existing architecture to create a more content author friendly UI. If it is indeed crazy, I'd love to hear your input on why that is crazy...

I'm having a hard time understanding what you're describing exactly... guess I'd have to see a video of it or something to get an idea of what exactly it does and does not do.

I'm picturing something like this for dynamic layouts (I may be using the terminology wrong, so bear with me):

A user edits a layer. In that layer, they add a "dynamic zone" widget to a given zone. Upon returning to the layer editor, new zones defined by this widget are now available for placement of other widgets, etc. For example, let's say I have a "3 column zone widget". I would edit the layer I want it in, and add this widget to the layer zone I want. Then, when I go back and edit that layer again, I will have three new zones into which I can add content items, widgets, etc.

The preference would be for a new layer editor in this case with drag / dropping these things into zones on an actual page so content authors can see exactly what they are doing instead of having to just know what each zone is. Of course that part could come later.

Again, don't even know if that's possible. I'm just putting ideas out there.
Coordinator
Aug 23, 2013 at 7:40 PM
Edited Aug 23, 2013 at 7:41 PM
On every page you display, you will have to evaluate the rules for all layers. If you have one layer per page, and 100,000 pages, your site is not going to respond this century. It's much more rational to attach that widget information to the content item. This way, only a few real layers, plus the pseudo-layer attached to the current page, have to be evaluated. Layers have never been designed to be per-page, despite the horrible "create new layer for this item" feature that somebody whose name I shall not utter thought would be nice, to the point that it should be on by default. Thinking of which... https://orchard.codeplex.com/workitem/20041

But thanks for contributing, and keep it coming, this is good stuff.
Aug 25, 2013 at 5:27 PM
Well yes, in it's current implementation. That's why I was implying some sort of flag that says "Only use this for this content item", which would eliminate having to process the layer for everything (i.e., instead of pulling ALL layers and processing, pull all layers not eplicitely marked as belonging to a single content item unless it is the CURRENT content item).

Essentially I think it's close to the pseudo-layer idea you have there... I just thought it could be accomplished with the existing layers architecture if a switch was put in to specify two types of layers: ones belonging to a single content item, and global ones. That way you could keep the same editor, etc., between everything and not have to create a whole new layer functionality to accomplish this.
Coordinator
Aug 25, 2013 at 11:53 PM
It should not be accomplished with the existing layers architecture. Adding an ad-hoc flag would only be bending the feature into doing something it wasn't meant for, it would add strong coupling between features that don't have to be coupled, and there is no point as there is a better design, which is to attach what belongs to a content item, onto that content item. Not to mention the big changes you would have to make to the widget module to make it ignore all those new layers from the back-end.