I was looking at Kevin Jump's great local gov package (thank you Kevin), nice to see a more complex structure at work. I'm wondering if anything's changed in the site structure concepts for v.7 since 4.11 (my last). Haven't really seen anything about it on U.tv. This now old post still brings up a lot of questions, although I've tried to go by it:
Kevin's kit certainly goes at least one step farther than just separating out a site settings doc type and content node. In the complexity of Kevin's kit (and governments in general) it makes sense but is this part of a newer general philosophy on site structure, or just a mutation necessary for complex organisms?
Back in the day, it seemed the general advice was to create separate doc types for most things and not use inheritance so much ('if you think you might need a new doc type, you probably do').
Maybe just adding on Kevin's RootDocType, and group the other most common content bits?
Not really sure why I like the feeling of having that RootDocType there but somehow it seems natural.
I suppose adding any extra tabs at all might seem superfluous to editors in daily use if it's just one tab only for main content. Generally, to keep it simple for editors, I have liked to make the process of filling out a content node flow from top to bottom, just like the published page is likely to be: pageName; headline; image; caption; lead; bodyText; references...
What's the current philosophy of our fearless leaders? Anything new?
When you see the package in action and think about how feature and program rich a government entitiy is, see how he's got the tabs working in the content pages, and think about how large a govt site is likely to grow into, it is a thoughtful, flexible structure and makes good sense.
Also, at the moment, in the RootDocType there is just the UmbracoNaviHide but it is a fine place to put things just for us, leaving SiteSettings more open for other admins/editors.
It feels like good knowledge and a step on the path of that old Umbraco saying, 'a job well begun is half done'.
glad you like it - the structure in the kit is the result of several iterations of big site developments, its trying to strike the balance controlling the inevitable growth of content needs without restricting it with to many requirements.
to answer your original question i think the answer is no, nothing has changed much between 4.11 / 7 in terms of structure. the only significant change is the concept of container types, that make it easier to have large node lists under one folder.
The never to be mentioned umbraco 5 had mutli-doctype inheritance which would enabled you to create multiple doctypes, (say one for content, one for metadata) and then inherit them both in a new doctype - this certainly would have helped simplify a couple of scenarios, but it has (yet) to appear in the post v5 world.
there are a couple of doctype mixin type projects that allow you to create this sort of effect. but it's not true inheritance.
i think Inheritance is the best way to guard against mass changes later on, as well as the Root DocType, in the starter-kit that is what the master template is trying to do with site design, you never know when something has to be added to every page. it something I would consider even on small sites.
Its a balance though, you can end up with overly generic doctypes and tryting to shoe horn everything into them - So i am not against one having one off doctypes when needed you need to be not afriad to mix where needed.
I had no clue about the List View, thanks. I look at the way you've done this kit and it reminds me of normalizing a database, which seems like a very good thing to me.
However, the job of training people also seems like it would be a bit more daunting than if everything is on one tab. But maybe when an organization has this complex requirements, they also have better editors.
Have I also missed a way to limit users to certain doc types in Umbraco? Seems like putting things like Section Homepage in front of the average user could be detrimental to a meticulously crafted responsive design. Just setting a user's starting node doesn't seem constrained enough and a single content channel seems constrained too much.
New concepts for site structure?
I was looking at Kevin Jump's great local gov package (thank you Kevin), nice to see a more complex structure at work. I'm wondering if anything's changed in the site structure concepts for v.7 since 4.11 (my last). Haven't really seen anything about it on U.tv. This now old post still brings up a lot of questions, although I've tried to go by it:
http://cultiv.nl/blog/tip-of-the-week-the-ultimate-site-structure-setup
Kevin's kit certainly goes at least one step farther than just separating out a site settings doc type and content node. In the complexity of Kevin's kit (and governments in general) it makes sense but is this part of a newer general philosophy on site structure, or just a mutation necessary for complex organisms?
Back in the day, it seemed the general advice was to create separate doc types for most things and not use inheritance so much ('if you think you might need a new doc type, you probably do').
Maybe just adding on Kevin's RootDocType, and group the other most common content bits?
RootDocType
- Content
- Contact Page
- Content Page
- Home Page
- SiteSettings
Not really sure why I like the feeling of having that RootDocType there but somehow it seems natural.
I suppose adding any extra tabs at all might seem superfluous to editors in daily use if it's just one tab only for main content. Generally, to keep it simple for editors, I have liked to make the process of filling out a content node flow from top to bottom, just like the published page is likely to be: pageName; headline; image; caption; lead; bodyText; references...
What's the current philosophy of our fearless leaders? Anything new?
Occurs to me that some of you may not have seen Kevin's package. The structure is:
RootDocType
- Content
-- Components
--- ServiceAlert
-- Page
--- Contact Page
--- Content page
--- Event Item
--- Landing Page
---- Venu Landing Page
--- Section Homepage
---- Homepage
- SiteSettings
-- Service Alert Folder
When you see the package in action and think about how feature and program rich a government entitiy is, see how he's got the tabs working in the content pages, and think about how large a govt site is likely to grow into, it is a thoughtful, flexible structure and makes good sense.
Also, at the moment, in the RootDocType there is just the UmbracoNaviHide but it is a fine place to put things just for us, leaving SiteSettings more open for other admins/editors.
It feels like good knowledge and a step on the path of that old Umbraco saying, 'a job well begun is half done'.
Hi
glad you like it - the structure in the kit is the result of several iterations of big site developments, its trying to strike the balance controlling the inevitable growth of content needs without restricting it with to many requirements.
to answer your original question i think the answer is no, nothing has changed much between 4.11 / 7 in terms of structure. the only significant change is the concept of container types, that make it easier to have large node lists under one folder.
The never to be mentioned umbraco 5 had mutli-doctype inheritance which would enabled you to create multiple doctypes, (say one for content, one for metadata) and then inherit them both in a new doctype - this certainly would have helped simplify a couple of scenarios, but it has (yet) to appear in the post v5 world.
there are a couple of doctype mixin type projects that allow you to create this sort of effect. but it's not true inheritance.
i think Inheritance is the best way to guard against mass changes later on, as well as the Root DocType, in the starter-kit that is what the master template is trying to do with site design, you never know when something has to be added to every page. it something I would consider even on small sites.
Its a balance though, you can end up with overly generic doctypes and tryting to shoe horn everything into them - So i am not against one having one off doctypes when needed you need to be not afriad to mix where needed.
I had no clue about the List View, thanks. I look at the way you've done this kit and it reminds me of normalizing a database, which seems like a very good thing to me.
However, the job of training people also seems like it would be a bit more daunting than if everything is on one tab. But maybe when an organization has this complex requirements, they also have better editors.
Have I also missed a way to limit users to certain doc types in Umbraco? Seems like putting things like Section Homepage in front of the average user could be detrimental to a meticulously crafted responsive design. Just setting a user's starting node doesn't seem constrained enough and a single content channel seems constrained too much.
Thanks again for the kit, brilliant work.
is working on a reply...