First of all, I think that this might be overthinking the grid. The way I see it, it is a more structured RTE that is editor friendly. Being editor friendly also means not have to know details about responsiveness, and having the content render predictably.

However, if you do want to have more complex renderings, I would create a row config for each type of rendering. So you could have a "3-col-stacked" and a "3-col-custom". You could then use your own custom gridrenderer where you know about these types of row configurations.

In the razor file, the row will have a name property, telling you which rowconfiguration was selected.

Hi Lee

Thanks for the feedback - some very good points! This is v1 of Grid Layouts so posts like this are most welcome.

One thing we discussed up until release (which also got changed a few time just before release), was where in the markup to do settings and styles configuration. Here are a few reasons for why we went the way we did:

• We decided on creating grid rows that wrap your entire content to enable full-widt manipulation, ie. target both framework containers and framework rows. And grid cells to make it possible to target specific content elements.

• To make Grid Layouts framework agnostic - seperating grid elements from framework elements

• Make it more flexible while developing ie. changing configuration and even renderer doesn't completely break content rendering as the framework scaffolding is still in place.

We discussed these things quite a bit, because there are a lot of nice helper classes in bootstrap that are very usefull but ultimately did not want Grid Layouts to become a bootstrap 3 website builder. It is more about making a greater connection between content rendered on the website and what the editor sees in the backend.

It is still possible to do a lot of the things you mention ie. by wrapping the Grid Layout areas in your own CSS, maybe extending helper classes, and then target whatever elements you want. Or by making new renderers that are customized for the specific area. It is after all just a partial view :) It requires a different approach, you have to get in to the Grid way of thinking (not unlike Tron).

Not super in-depth answers to your question but more of an explanation of why it is as it is atm. Would love if this could be the start of a discussion on specific problems that needs solving. A lot of people have starting adopting the Grid so there are bound to be some great, creative solutions and ideas on how to use Grid Layouts.

rune

I produced a "responsive.cshtml" to replace the bootstrap ones. However, you do end up with simple things being nested 6 divs down, which produces a lot of redundant HTML.  Maybe I need to re-engineer the partial.

Craig

@Morten

Hmmmm... I'd have to disagree about it just being a structured RTE. If that was the case it wouldn't render in bootstrap/frameworks to begin with. It clearly shows sections of the site, and you can create custom grid property editors which really make it a site builder - And that's how editors will see it too.

My main issue is what I have outlined below.

@Run

Thanks for you answer. And I fully understand why you didn't make it a bootstrap builder.

I suppose what I'm getting at, really, without creating your own custom row renderers you can't really use it for medium to complex adaptive sites (Irrelevant of the framework, all frameworks have similar overrides with push, pull, offset etc... etc...).

Maybe it was just me. But when it came out, I was so wow'd by how it worked and the layout in the back office. I didn't really think 'how will I implement that in the front end'.

Are there examples anywhere of creating a custom row renderer? Showing a situation as I explain above? Picking out a specific row, and adding custom styles to a col.

Please don't think I'm having a moan at what you have done. It's great and I REALLY want to use it, but I just need to understand how much extra work is involved in us using the grid in a real world way.

As with most people, we can't compromise how the site works/lay's out on mobile devices just to make the back office experience nicer for the editor.

Grid Property Editors

IMO... It seems to me, that apart from this issue I am having in wrapping my head around using the grid properly. Grid Property editors are key to making the grid work for most companies.

It would be great to have a section on the new our.umbraco dedicated to these grid property editors. So people can have a place to get common grid property editors like sliders, accordions or other common things people come up with.

As well as being a great add on, it would help people learn how to make them themselves by looking at what others have done.

@craig

What you have mentioned is one of my worries. Having a really complex/loaded view with tons of 'ifs' and 'elses'. I was hoping for a better solution.

Maybe calling/rendering a specific row partial by an ID or name. So everything is nicely separated. Similar to how they are doing it with Archetype in this post.

In the current iteration of the Grid, I do believe it's best to think of it as the successor of the Rich Text Editor in a world gone Responsive/Adaptive (where RTEs really, really doesn't work). That was what we designed it to be for a v1. So it does come with limitations in its current form, but I agree we shouldn't settle.

So think of the grid in 7.2 as the beginning and lets make this discussion into what would make it awesome rather than talk about the current limitations and compromises we'd eventually have to make.

lets make this discussion into what would make it awesome rather than talk about the current limitations and compromises we'd eventually have to make.

I'm concerned this will turn into a conversion completely about backoffice grid features and add ons. Which is great, but missing the main point of me posting this.

I think the backoffice grid you have in v7.2+ is great so far. My only thoughts on that were a place for people to put common grid property editors (Sliders etc...) and make the row/cell options a bit more elegant than just having to input raw JSON.

But the issue is then, and I suspect a lot of others is how we deal with the front end for 'real world' websites. I'm just throwing it out there to see what people have done to deal with this.

Simple example:

@helper renderRow(dynamic row, bool singleColumn){
    <div @RenderElementAttributes(row)>
        @Umbraco.If(singleColumn, "<div class='container'>")
        <div class="row clearfix">
            @if (row.name == "Widget 1-1-1-1")
            {
                <h1>@row.name</h1>
                <!--Do magic-->
                @Html.Partial("Widget 1-1-1-1", (object)row)
            }
            else
            {
                foreach (var area in row.areas)
                 {
                     <div class="[email protected] column">
                         <div @RenderElementAttributes(area)>
                             @foreach (var control in area.controls)
                             {
                                 if (control != null && control.editor != null && control.editor.view != null)
                                 {
                                     <text>@Html.Partial("grid/editors/base", (object) control)</text>
                                 }
                             }
                         </div>
                     </div>
                 }
            }
        </div>
        @Umbraco.If(singleColumn, "</div>")
    </div>
}

And the you could render your custom widget in the Widget 1-1-1-1.cshtml file:

@inherits UmbracoViewPage<dynamic>
<div>
    <h2>Custom render</h2>
    <p>@Model.name</p>
</div>

Of course this can all be made nicer with more intelligent helpers etc., but it proves the concept.

Thanks. That's a starting point as an idea.

I didn't think that called a partial with a space in it's filename worked? Looks like we need an alias to go along with the name (Like we have on templates, doctypes)?

Hi Lee,

I just started a project that will have ~150 pages built out using the grid across ~7 different "page types". I'm running into some similar problems that you mentioned around wanting "col-md-4 col-sm-6" type of classes "sometimes" - I'm currently using Morten's example/approach.  At the end of the day, the content authors need to know at least "a little" about how column's wrap at different resolutions - i dont see any way around that and will "solve" it via training at launch.

Also agree on a repository of examples for custom grid editors - I have some property editor experience and it took me about half a day to ramp up on how to write a custom grid editor - examples would have cut that in half I think as the existing ones are a bit basic.  The "macro" approach linked above is "the other right way" of doing things IMO - the "core" custom grid editor approach in the official documentation is "my right way".  Currently, I have built 4 grid property editors in under a day including a slider - the project calls for 10 in total with some pretty advanced ones around content relation.  If you're attending uWestFest I can share some examples with you there.

Was hoping to see some examples in Per's Grid talk at UK Fest but that video doesn't seem to be online (not sure how far he went into custom stuff as I wasnt there).

Regards,
Matt 

I'm in the middle to end of building a smallish ecommerce site using the grid for a few three column pages.  I wanted to offer the grid approach to give the editors flexibility as the site is supposed to be cloned with other front ends. However, the interface is so cluttered I think I'm going to be asked to ditch it and provide static entry points for text and images. There is also still the problem already described of not having tight enough control of the responsive side. Applying classes to inner or outer divs (and you can't be sure which div gets it) isn't a great solution for non-techy editors I feel.  Looking forward to the evolution of the grid though. Just not too happy with the current interface.

Cheers,

Craig

@Craig: Any chance you can elaborate on how you find the interface cluttered? It would be a great help.

@Niels: Every chance. Just need to get some screenshots together and hide the brand name as it's embargoed till end of March ;)

Craig

The About Us page below is a 3 column grid layout:-

The UI for this looks like this:-

What it doesn't show you is the mouseover reveal for the settings which can be quite confusing with columns being close together. Once the settings icon is clicked then the editor is faced with adding a class to a div as here:-

It is quite undiscoverable for the editor to know what class to apply and to where. At the very least I would suggest replacing the class text box with a style dropdown in a similar vain to the RTE, where you could assign a stylesheet and have it's pseudo class names appear for selection.

The other thing that's not helping is that there's no way (that I'm aware of) to collapse the left hand Content pane which takes up a lot of room and would seriously improve the UI in this regard.

Hope this helps ;)

Craig

One more thing (which I might have mentioned elsewhere)... There doesn't seem to be a way to change between already configured base layouts once chosen (i.e. change from 3 cols to 2), without deleting the whole page and starting again. Not a problem for a standalone page, but if it has children, you'd lose the lot:(

Cheers,

Craig

@Craig100

What it doesn't show you is the mouseover reveal for the settings which can be quite confusing with columns being close together

Not sure that there is a way around this and if you swap to a full screen type of view (your last point) this becomes less of an issue.

It is quite undiscoverable for the editor to know what class to apply and to where. At the very least I would suggest replacing the class text box with a style dropdown in a similar vain to the RTE, where you could assign a stylesheet and have it's pseudo class names appear for selection.

You can actually do this yourself as the settings and styles are configurable through the data type you setup - you could configure the class as a radio button list:
https://our.umbraco.org/documentation/using-umbraco/backoffice-overview/property-editors/built-in-property-editors-v7/Grid-Layout#Configuringacustomsettingorstyle

Giving authors access to such classes is not the right approach IMO though and too confusing for them.  I think a better appraoch is to create a custom row called "desktop 3 col, tablet 2 col, mobile 1 col" which behaves "as it sounds" - you would need to modify the standard views that the grid uses to render on the client side but it should be <10 lines to do that.  Then just explain to the author how things stack in a grid view instead of trying to explain what col-md-3 vs col-sm-6 means.

The other thing that's not helping is that there's no way (that I'm aware of) to collapse the left hand Content pane which takes up a lot of room and would seriously improve the UI in this regard.

Agreed on this one.  I actually added some custom code to 7.2.2 that allows me to double click the tab (Content in your case) to hide the tree and give you a wider editing experience.  Will try to package it up for re-use bit its a bit clunky once you start clicking on other things like developer/settings/users (need to hit browser refresh).

@Matt,

I was commenting on the "out of the box" set up for the average editor/developer. Not everyone has the time, skills or desire to interfere with the UI.

Giving authors access to such classes is not the right approach IMO though and too confusing for them.

Not at all, it works very nicely in the RTE. You don't give them class names to apply, you give them sensible descriptions which apply the real class in the background. My About Us page has a grey box around it. That could only be put in place by adding a class in the grid layout. Ok it could have been coded in but then the editor loses flexibility.

At least we agree on the need for a method to collapse the left hand window, which I'm sure you could do yourself. But then you could build your own car if you put your mind to it ;)

Craig

With the new DocType Grid Editor and Nested Content from Matt & Lee. It makes the grid much more usable from a backend perspective, but I'm still stumped with how rigid the front end is.

As per my original post that started this discussion and from what @craig100 has mentioned. I'm trying to figure out a suitable way that we can adjust/manage the bootstrap classes. Having them all col-md just isn't a good responsive experience.

Would love to hear how everyone else is getting around it.

I am very new to the grid and 7.2... I love the DocType Grid Editor and Nested Content... Very interested to see where this conversations ends up going. @Matt, would love to see some blog posts/educational material on your approaches... sounds like you are pretty far out on the leading edge with real world application of this stuff!

Hey @Lee these were my thoughts when I first started working with the grid. Not sure if you saw it.

http://issues.umbraco.org/issue/U4-6439

It mainly is discussing the waste of space and interface and not so much the front end output.

Since then I have started bending the grid to my will but I have hit the same issues as you when it comes to allowing the editors to specify layout flow. It is possible to add in your own grid editor settings but its limited.

In general the concept is awesome and it solves a load of problems but like everything adds some new ones too.

Well one suggestion I made was to have a style dropdown like we do in the RTE so editors don't have to be given a list of classes they have to type in, they just pick one. The current site I'm working on requires editors to set full width background colours. They're only editors and know nothing of classes, etc. The current interface is a bit tricky for them.

Craig

Hi Craig

This video http://umbraco.tv/videos/umbraco-v7/implementor/fundamentals/grid-layouts/settings-and-styles/ shows how to make your own settings and styles. The tutorial shows how to make a radio button list where the editor can choose a background color for a row. This can also be applied to cells.

Hope this can give you some inspiration

/rune

My main concern with the grid is how it will eventually lead to a whole new ecosystem of property editors of it truly takes off, which I fear means that less property editors will be created for regular doctype editing.

Don't get me wrong, I think the grid concept is great, I'm just worried it'll spread the layer of umbraco package devs thinner.

Hi Rune,

Hadn't seen that particular video. Looks just what I thought was lacking. That's great.

Thanks,

Craig

Hi I was just wondering how people are tackling layouts where you need full width? i.e. instead of nesting in the boostrap container class having a 50% 50% kind of layout that breaks out of the bootstrap convention or needs fluid dimensions?

That has been our biggest limitation so far. I'm trying to nut out a homepage layout which uses stock bootstrap grid and dimensions with some break out boxes.

I was thinking of using the row name as per Morten's suggestion but by that stage it is too late.

My other thought was a custom grid editor but would love some suggestions or to hear if anyone has achieved this kind of effect?

Thanks :)

I do it within the custom grid editors I've written for things like a full width image or slider by doing the following at the start of the control to get you "out" of the container: @Umbraco.If(true, "")

and then I do my full-width stuff and then I "re-create" the original div layout via: @Umbraco.If(true, "

I've found being able to set the device specific css class names, eg col-xs 6, col-lg-3 at grid config time, details here:

http://tooorangey.co.uk/posts/evolution-of-the-grid/

and here:

http://issues.umbraco.org/issue/U4-6585

to save alot of effort, for editors not having to remember to apply them to each cell on each row, and to avoid the other option of having to have lots of if row.name == "Product Row" to add these device specific classes in the framework file.

I have been trying to implement the grid, but somehow the Model.sections does not contain the right focalPoint values no matter how I do it?

I cant figure out where to fix this? I tried multiple ways of accessing the images in the media partialview in hope that I could use the Image ID for a raw lookup for the correct focalPoints and then call the ImageCropper directly using the named sizes like banner, highrise, thumbnail etc.

but if the focalPoint values arent there it doesnt really make any sense.

I tried to debug the values in the Model.Control loop in the Bootstrap/Fanoe view... also wrong there... where does Model.sections get populated and WHY arent the right focalPoint values used?

Am I doing this wrong somehow? is there a better approach using Grid and Imagecropper?

I don't use the Grid myself, but while aiding the development of Archetype, I've had loads of fun implementing support for Upload and ImageCropper - some of which was tackling the lack of stored focalPoint values.

In short, before you spend too much time pulling your hair out in frustration... maybe the Grid simply does not support ImageCropper? If so, you may be able to use a media picker (with crops on the media) instead.

I know it's not much help but it may be the best approach in order to preserve one or two hairs on your head :)

I was just having this issue and solved it by simply removing the 'container' div from the Bootstrap3.cshtml file.

I commented out the following lines

@if (Model != null && Model.sections != null)
{
    var oneColumn = ((System.Collections.ICollection)Model.sections).Count == 1;

    <div class="umb-grid">
        @if (oneColumn)
        {
            foreach (var section in Model.sections) {
                <div class="grid-section">
                    @foreach (var row in section.rows) {
                        @renderRow(row, true);
                    }
                </div>
            }   
        }else { 
            @*<div class="container"><-- THIS ONE *@
                <div class="row clearfix">
                    @foreach (var s in Model.sections) {
                        <div class="grid-section">
                            <div class="[email protected] column">
                                @foreach (var row in s.rows) {
                                    @renderRow(row, false);
                                }
                            </div>
                        </div>
                    }
                </div>
            @*</div><-- THIS ONE *@   
        }
    </div>
}

@helper renderRow(dynamic row, bool singleColumn){
    <div @RenderElementAttributes(row)>
        @*@Umbraco.If(singleColumn, "<div class='container'>")<-- THIS ONE *@
        <div class="row clearfix">
            @foreach ( var area in row.areas ) {
            <div class="[email protected] column">
                <div @RenderElementAttributes(area)>
                    @foreach (var control in area.controls) {
                        if (control !=null && control.editor != null && control.editor.view != null ) {
                            <text>@Html.Partial("grid/editors/base", (object)control)</text>
                        }
                    }
                </div>
            </div>}
        </div>
        @*@Umbraco.If(singleColumn, "</div>")<-- THIS ONE *@
    </div>
}

Now, in my page template I can do the following and everything responds the way I expect it to.

<div class="col-sm-9">
  @CurrentPage.GetGridHtml("bodyText")
</div>

I'm only ever using a 'One Column' layout because I'm using the Grids within my static HTML so all I ever need to render are various row configurations.

Hope this helps others too

Dependant on your use case you could also just set the boolean to false in the following for oneColumn

         @if (oneColumn)
    {
        foreach (var section in Model.sections) {
            <div class="grid-section">
                @foreach (var row in section.rows) {
                    @renderRow(row, false);
                }
            </div>
        }   
    }

is working on a reply...