I'm currently trying to get my head around structuring a site where all content is made of elements (tiles) of varying sizes both in width and height. The sites design consists of two content areas: a left sidebar and a right content area. Screenshot:
The screenshot above displays a textpage with five elements in the main content area and two elements in the left sidebar. However, this content can be made totally different by the administrator in Umbraco simply by changing the order of the elements and/or changing width and/or height of the elements.
Essentially, two textpages can have the exact same content elements if needed.
At the moment I am controlling which elements should be displayed on a textpage by selecting them in a Multi-Node Tree Picker. This way the editor can freely move the order of elements as they wish.
Though, when it comes to structuring the creation of these elements, I am a bit split. I want it to be as user-friendly as possible for the editor. I've come up with two structures so far:
First one is where there's a Content elements and a Sidebar elements folder under each textpage where the admin can create the elements needed for the textpage:
What I don't like about this is duplicate content. The Content elements and Sidebar elements folders is created (via event hookup) whenever a new textpage is created and if an element needs to be on another textpage, it needs to be copied. What I do like is that it's user friendly and easy to get an overview of which elements belongs to which textpage.
Second structure is having a single Content elements folder in the content tree with an Elements folder and a Sidebar elements folder (naming convention might need a change here, though) and have all elements in these folders:
What I don't like about this, is that the folders will contain a lot og elements over time which can be very confusing for the editor to keep track of. There's no overview of which element belongs to which textpage. What I do like is the separation of concern: there will be no duplicate content and any textpage can contain any element.
So, the million bucks question here is: how would you structure this? :-) I have tried adding sub-folders to the Elements folder in my last screenshot to structure the elements by their width, i.e.: 1/3 elements, 2/3 elements, Half width elements, Full width elements etc, but as you are able to change the width on the element itself, this will be confusing as an element which is in the Full width elements folder can then be changed to 1/3 width.
Don't know if any of this makes any sense at all ;-) If not, please let me know and I will try to elaborate.
I think you should consider creating a "Content elements" sektion in your node tree. I must admit that personally I'm not to keen on the idea of mixing Content nodes with element nodes like it seems you're doing in the above.
The above solution makes it harder to reuse the content elements across the site and that means you would have to copy an element from one place in the structure to another if you want to reuse it somewhere.
I know that having the content centralized has some issues as well since it's currently not possible to limit the access to different folders etc. in such a section. But I think that if you make a proper IA and make sure that it's possible to create folders for the elements then the editors have a chance to create some kind of meaningfull structure. And in my experience that makes sense to most editors and it does not take them that long to get used to their new workflow.
I really think you should consider this approach since the other approach can easily get bloated over time.
If you at any time need to make the site multilingual you can either create language folders in the content elements section or you can create language tabs on the elements dependent on how many properties the elments consists of.
I hope this makes sense to you and that you can use some of it :)
I agree with Jan - the team I work in manages several large(ish) sites that have content elements grouped as per your "Plan B" idea.
Overall the sites work well and as Jan suggests it is how well the IA is structured that determines how well the admin people can administer the site. The ability to click on a selected node within the multi node picker aids tracking down the location - the one thing to add icing to the cake would be the ability to click on the selected item and be taken to the actual node for editing. Maybe a feature worth suggesting (thinking out loud here).
As you have detailed, you tried grouping the elements by size / position but felt that wasn't quit right. Are the elements able to be grouped by topic, ie do they cover different topics, date ranges, etc that might provide logical groupings ?
Content structure advice
Hi all,
I'm currently trying to get my head around structuring a site where all content is made of elements (tiles) of varying sizes both in width and height. The sites design consists of two content areas: a left sidebar and a right content area. Screenshot:
The screenshot above displays a textpage with five elements in the main content area and two elements in the left sidebar. However, this content can be made totally different by the administrator in Umbraco simply by changing the order of the elements and/or changing width and/or height of the elements.
Essentially, two textpages can have the exact same content elements if needed.
At the moment I am controlling which elements should be displayed on a textpage by selecting them in a Multi-Node Tree Picker. This way the editor can freely move the order of elements as they wish.
Though, when it comes to structuring the creation of these elements, I am a bit split. I want it to be as user-friendly as possible for the editor. I've come up with two structures so far:
First one is where there's a Content elements and a Sidebar elements folder under each textpage where the admin can create the elements needed for the textpage:
What I don't like about this is duplicate content. The Content elements and Sidebar elements folders is created (via event hookup) whenever a new textpage is created and if an element needs to be on another textpage, it needs to be copied. What I do like is that it's user friendly and easy to get an overview of which elements belongs to which textpage.
Second structure is having a single Content elements folder in the content tree with an Elements folder and a Sidebar elements folder (naming convention might need a change here, though) and have all elements in these folders:
What I don't like about this, is that the folders will contain a lot og elements over time which can be very confusing for the editor to keep track of. There's no overview of which element belongs to which textpage. What I do like is the separation of concern: there will be no duplicate content and any textpage can contain any element.
So, the million bucks question here is: how would you structure this? :-) I have tried adding sub-folders to the Elements folder in my last screenshot to structure the elements by their width, i.e.: 1/3 elements, 2/3 elements, Half width elements, Full width elements etc, but as you are able to change the width on the element itself, this will be confusing as an element which is in the Full width elements folder can then be changed to 1/3 width.
Don't know if any of this makes any sense at all ;-) If not, please let me know and I will try to elaborate.
Any inputs are greatly appreciated!
Thanks in advance.
Hi Bo
I think you should consider creating a "Content elements" sektion in your node tree. I must admit that personally I'm not to keen on the idea of mixing Content nodes with element nodes like it seems you're doing in the above.
The above solution makes it harder to reuse the content elements across the site and that means you would have to copy an element from one place in the structure to another if you want to reuse it somewhere.
I know that having the content centralized has some issues as well since it's currently not possible to limit the access to different folders etc. in such a section. But I think that if you make a proper IA and make sure that it's possible to create folders for the elements then the editors have a chance to create some kind of meaningfull structure. And in my experience that makes sense to most editors and it does not take them that long to get used to their new workflow.
I really think you should consider this approach since the other approach can easily get bloated over time.
If you at any time need to make the site multilingual you can either create language folders in the content elements section or you can create language tabs on the elements dependent on how many properties the elments consists of.
I hope this makes sense to you and that you can use some of it :)
Best Regards
/Jan
Hi Bo
I agree with Jan - the team I work in manages several large(ish) sites that have content elements grouped as per your "Plan B" idea.
Overall the sites work well and as Jan suggests it is how well the IA is structured that determines how well the admin people can administer the site. The ability to click on a selected node within the multi node picker aids tracking down the location - the one thing to add icing to the cake would be the ability to click on the selected item and be taken to the actual node for editing. Maybe a feature worth suggesting (thinking out loud here).
As you have detailed, you tried grouping the elements by size / position but felt that wasn't quit right. Are the elements able to be grouped by topic, ie do they cover different topics, date ranges, etc that might provide logical groupings ?
Best wishes, Nigel
is working on a reply...