Page 1 of 3

Ideas for approach to infinite levels system

Posted: Thu Jan 08, 2009 8:44 pm
by allspiritseve
Ok, just wanted to share a project I'm working on, and see if you guys had any ideas for how to approach it. Basically, I'm revamping my company's CMS. We want to have infinite levels of content. We currently have two levels, tabs + pages.

Basically what we want is:
  • A clean urls system where each section of a URL corresponds to a handler/resource. (ie, REST or Konstrukt)
  • Content-specific handlers that know how to get the content they need and what to do with it.
  • A tree of content that can be organized according to each client's specific needs.
  • "Pages" that can be constructed from many different parts, using many different content types.
  • Capability for unique meta data to be kept for every page.
  • Separation of content and location, so the same content can be used in many different places.
Essentially I'm looking for help on how to make this as flexible as possible. I was thinking first of all of having a Document object that held the page title, meta data, and handler, and was essentially the "location" in the system. (maybe it should be called Location?). This entity would be relatively hidden to the user, as they would browse to a location and add content there-- so they think they are adding a page, but in reality they're adding a page AND a location.

The really tricky part is what to do from here. Using the url, I can locate a final handler for the location. This handler needs content to work on-- if the user added a page, then a single page needs to be attached to that handler. I may want more content though-- for example, a list of Posts from a blog. The user should be able to specify what blog these posts come from, and how many posts. In that case, I wouldn't want to attach every post to the handler, I'd want to attach the blog. This content can get multileveled, too.

Say, for example, I want to feature some articles on my home page. I'd have a location, with a page attached to it. Attached to the page would be a featurebox, with any number of content attached to it. The way I'm thinking right now, I will limit each location/Document to 1 item of content to be attached to it. If it's only one, the handler will know what type of content that refers to, and fetch it. if it's 1, and the handler is a PageController, it fetches a page with id 1. If it's 1, and the handler is a BlogController, it fetches a blog with id 1. That means I need relations between content.

Originally I was going to have an EAV system to deal with all these content relations, but I've moved away from that in the last 6 months. That means I need a relation table that not only tracks ids, but which table they are from, to have type-agnostic relations such as with a featurebox. I feel like aggregate items, such as a blog view or featurebox, deserve their own handlers even if they aren't the only thing on the page. Does that mean I need another table for content => handler pairs?

I'd really like some feedback about this. Am I approaching it right? I'd like to hone in on the domain and really define these classes well, so any of you DDD aficionados out there, speak up!

Cory

Edit: Thanks pickle!

Re: Ideas for approach to infinite levels system

Posted: Thu Jan 08, 2009 10:35 pm
by allspiritseve
Well, just writing that post really made me thing about this more clearly.

Basically, I have 4 main groups of content right now: Pages, Blogs, Galleries, and Articles (Article Systems? What is a group of articles called? A column? collection? anthology? Are articles outdated and to be replaced by pages and blog posts? They seem to me to be differentiated by duration of relevancy... a page is always relevant, an article is probably relevant from a couple of months to a couple of years, and a blog post is outdated as soon as the next post is made).

Here's how I envision things working:
A user logs in, and hits Browse Content.
They are presented with content groups, in context by their location. Very similar to a file browser in your favorite OS. Pages are unique because there isn't a concept of a "collection" of pages and adding a page automatically adds a page view-- so to the user, all they need to do is add a page.

A user clicks on a Page, and is shown a detail view-- that page is now the "context" and any children of that page are shown. Click on the page to edit, or click on a child page to go to a new context.
OR
A user clicks on a Blog, and is now in the Blog editing context. They can add a new post, edit a previous post, tweak the default views. They can also add a blog view, which is a specific representation of a certain subsection of posts (first 5 with tag X, etc) anywhere in the site they want. Attach it to the homepage? Sure! Make a list of recommended posts, favorite posts, worst posts, etc.
OR
A user clicks on a Gallery, and is now in the gallery editing context. They can add an image, place it in multiple galleries, modify the image title, description, alt tag information. They can also remove images from a gallery and delete images. Same thing applies as with Blog views... specific representations of a subset of a gallery or galleries can be made, and placed anywhere.

Or a user can add a new page, blog, gallery, or article.

I think it can work. Now... how to put all that in code.

Re: Ideas for approach to infinite levels system

Posted: Thu Jan 08, 2009 11:06 pm
by Christopher
For the simple CMSs, I often need the kind of deep hierarchy for organization that you are asking for. I think REST is useful to a point, but also think that the reason REST is not that widely used is that it is cumbersome to implement complexity and brittle because links to a resource are scattered. I tend to use REST to get halfway and then use stored data.

Probably the most common thing I have been doing lately is treading the URL like a DataSource find() where you request by key. Then for most content I treat at template file like a database record by using named blocks. I can use the same interface whether the data is in a database or files -- just different Models. You can then put a lot of the descriptive data that would be in the REST URL into data fields connected with the content. That makes changes happen in one place and gives users easy control over the attributes of a "page." I tend to use str_replace(() style templates for this because the are considerably more secure than PHP templates.

Re: Ideas for approach to infinite levels system

Posted: Thu Jan 08, 2009 11:26 pm
by allspiritseve
arborint wrote:For the simple CMSs, I often need the kind of deep hierarchy for organization that you are asking for. I think REST is useful to a point, but also think that the reason REST is not that widely used is that it is cumbersome to implement complexity and brittle because links to a resource are scattered. I tend to use REST to get halfway and then use stored data.
Assuming I'm reading the hidden implication correctly, you do something else for the "advanced" CMSs? Or do you mean "simple CMS" as compared to "advanced Application"?

I am not committed fully to REST ideals.. I will definitely be using the session at key points, as we discussed with Skeleton's paginator re: sorting. I think it works well with the notion that a user could drop a content item anywhere in the hierarchy, though.

One thing I'm trying to figure out right now is how explicit I want to get with my relations. Posts obviously have a very strict relationship to Blogs, but the relationship between FeatureBoxes and Pages, for example, are more ambiguous.

Re: Ideas for approach to infinite levels system

Posted: Fri Jan 09, 2009 12:50 am
by Christopher
allspiritseve wrote:Assuming I'm reading the hidden implication correctly, you do something else for the "advanced" CMSs? Or do you mean "simple CMS" as compared to "advanced Application"?
By "small" I guess I meant not a general purpose CMS like the many projects around. Maybe custom or special-purpose might be a better description.
allspiritseve wrote:One thing I'm trying to figure out right now is how explicit I want to get with my relations. Posts obviously have a very strict relationship to Blogs, but the relationship between FeatureBoxes and Pages, for example, are more ambiguous.
Posts to Blogs is a many to one relationship. FeatureBoxes to Pages sounds like a many to many relationship.

Re: Ideas for approach to infinite levels system

Posted: Fri Jan 09, 2009 1:51 am
by matthijs
It might not be a direct answer to your question, but it might be an idea to get the naming nailed first. Would make the discussion more clear as well. What exactly do you mean with a Page? From what I read in your post, you share it in content. But maybe you shouldn't? Maybe you should share Page under the presentation side.

Content:
- blog posts
- photogalleries
- articles
- custom/other?

Presentation:
- pages
- sections?

Metadata:
- tags
- categories

So within the CMS you would create content (blog posts, articles, photos) and then as a separate task put that content in the presentation layer (pages, sections). So visiting yoursite/aboutus means you visit the page aboutus. Within the page aboutus you pull in the article "about us", or a list of articles about the members of your company, or both, and/or some photo's, etc.

It might seem trivial, but one of the main issues I have working with different CMS systems is that each and every one has a different naming scheme and that reflects in how it is set up, how flexible the system really is, etc
I think that building the URL scheme is part of the presentation layer and should ideally be separate from the content. That's one reason I like how Wordpress works, as you can go in the system, write Posts, Pages and upload Media (photo's, etc) and after you have done that you can go to the settings and change around the permalink structure (have urls based on date, on category, etc). But as you see here, Wordpress has Pages as pieces of content. It works in 90% of the cases, but ideally I would put Pages under presentation instead of content. But I can understand that would make it more complex (considering Wordpress started as a simple blog system)

The whole point of a good CMS is to separate the content from the presentation. That's not easy and the reason why so many struggle with it and so many systems get it wrong

Re: Ideas for approach to infinite levels system

Posted: Fri Jan 09, 2009 10:31 am
by allspiritseve
The reason I have "page" as content is because it is already currently a piece of content in our CMS. As I said before, pages are unique because there is no distinction between "page" (content) and a display of a page... whereas you might have "blog" and "post" content, but different views that display that content.

On the other hand, I'm very flexible, and I am definitely trying to nail down the naming. I think there is an underlying concept behind the display of a page, a blog, a blog post, an article, etc., which I think should be called document. Every piece of content that potentially could go on its own page deserves a document. For example, you may have the same code taking a variable from the URI and showing different blog posts. Our SEO guy wants the capability to edit specific keywords, titles, and descriptions for each of those blog posts.

Can you think of a better name for "page" content? I feel like one should pick between a page, an article, and a blog post in terms of how dated the content is. The content on the home page doesn't seem to fit as an article, does it?

In general, I would like my clients to understand the difference between content and presentation of that content. Even so, I would also like specific content to automatically add a display when the content is added (adding a page, adding a blog post, etc.). On top of that, I want more displays to be able to be added, especially with things like blog posts.

Sorry, I'm writing this quickly before class, but I hope I don't come off as defending my naming decisions. I really am trying to just give you an overview of my reasoning so you can tell me if you think another naming scheme would work better. I am completely open to new ways of interpreting this domain. Thanks for your feedback, and I will be back to read it more in-depth after class.

Re: Ideas for approach to infinite levels system

Posted: Fri Jan 09, 2009 10:33 am
by allspiritseve
matthijs wrote:The whole point of a good CMS is to separate the content from the presentation. That's not easy and the reason why so many struggle with it and so many systems get it wrong
What, in your opinion, would be "getting it right"?

Edit: Ok, I'm back. I've been thinking about the content/presentation separation. My original goal had been to keep them together when I could (creating a page, for instance) but allowing separation as well (creating a new view on an existing blog, for instance). Do you think it would be better to COMPLETELY separate them? E.g. you create a blog, write your first post, and then add a blog view on the home page that links to a post view for each post? If this CMS were entirely for developers, I'd have no problem with that, but since it's used by clients I think some handholding needs to take place. That doesn't mean they can't have the option for more flexibility, just that things are dumbed down on the front end. I've been planning for quite some time now to keep locations and content separate, but I want the client's interaction with the CMS to be as natural as possible.

Re: Ideas for approach to infinite levels system

Posted: Fri Jan 09, 2009 6:32 pm
by josh
allspiritseve wrote:What is a group of articles called? A column? collection? anthology? Are articles outdated and to be replaced by pages and blog posts?
In Ne8's design I ended up on "volume" ( as in a volume of encyclopedias ), at first I chose publication but volume is even more abstract to me, plus more down to earth sounding.

Re: Ideas for approach to infinite levels system

Posted: Fri Jan 09, 2009 7:55 pm
by allspiritseve
jshpro2 wrote:In Ne8's design I ended up on "volume" ( as in a volume of encyclopedias ), at first I chose publication but volume is even more abstract to me, plus more down to earth sounding.
There's another idea. The only thing about volume is, it feels "complete" to me, rather than something you'd add an article to once in a while.

Re: Ideas for approach to infinite levels system

Posted: Fri Jan 09, 2009 8:39 pm
by allspiritseve
arborint wrote:Posts to Blogs is a many to one relationship. FeatureBoxes to Pages sounds like a many to many relationship.
I actually meant in terms of what the FeatureBoxes contain... they can contain Pages, BlogPosts, Articles, Images, etc... a situation where I could have tables like featured_pages, featured_posts, featured_articles, featured_images... or just featured_content and have a field that contains which table the child_id key references. I think if the latter is to work, then there have to be "feature templates" for each content type, so that they can be displayed in a small amount of space.
matthijs wrote:It might seem trivial, but one of the main issues I have working with different CMS systems is that each and every one has a different naming scheme and that reflects in how it is set up, how flexible the system really is, etc
I think that building the URL scheme is part of the presentation layer and should ideally be separate from the content. That's one reason I like how Wordpress works, as you can go in the system, write Posts, Pages and upload Media (photo's, etc) and after you have done that you can go to the settings and change around the permalink structure (have urls based on date, on category, etc). But as you see here, Wordpress has Pages as pieces of content. It works in 90% of the cases, but ideally I would put Pages under presentation instead of content. But I can understand that would make it more complex (considering Wordpress started as a simple blog system)

The whole point of a good CMS is to separate the content from the presentation. That's not easy and the reason why so many struggle with it and so many systems get it wrong
I've almost gone full circle with this... now I'm torn as to whether content types really should be separated from their presentation. I've been thinking about, say, a collection of blog posts as a presentation of the underlying model. But what if that collection is a resource in itself, as REST would have it? I don't know how that would change the flexibility of the url scheme... You could always think of a url based on date or category as a query on a collection. I will also always have separate fields for each content type that are used solely for the urls. They may be auto-generated based on the page title, or some similar item, but then we always have the option to go back and edit that url name to make it more SEO friendly or whatever. Another thing this protects against is having different urls for the same content. I only recently found out that can get you banned from search engines.

I am very interested to see your opinion on this. What would you see as the disadvantages? I'm trying to balance developer flexibility and freedom with ease of use and simplicity for clients. Keep in mind I'd still like the flexibility to change "handlers" for a given content type... just not as a client feature.

Re: Ideas for approach to infinite levels system

Posted: Sat Jan 10, 2009 1:07 am
by Christopher
allspiritseve wrote:I actually meant in terms of what the FeatureBoxes contain... they can contain Pages, BlogPosts, Articles, Images, etc... a situation where I could have tables like featured_pages, featured_posts, featured_articles, featured_images... or just featured_content and have a field that contains which table the child_id key references. I think if the latter is to work, then there have to be "feature templates" for each content type, so that they can be displayed in a small amount of space.
I am not sure I am following this very well. For me there are two separate problems. One is to specify where the "page" is within the site. The second is to specify the blocks/partials/boxes within the page. That's why I was saying that the box to page relationship is many to many. A specific box, like the latest blog post or the shopping cart, can be on many pages. And a page can have many of these boxes.

Re: Ideas for approach to infinite levels system

Posted: Sat Jan 10, 2009 3:09 am
by matthijs
Sorry to respond so late, busy and timezone differences..
allspiritseve wrote:As I said before, pages are unique because there is no distinction between "page" (content) and a display of a page... whereas you might have "blog" and "post" content, but different views that display that content.
Well, if you don't make the distinction between a "page" as content and a "page" as presentation, then that's your choice and that might be ok. But, if you decide at some point in time that a "page" (yoursite/about-us) should also be able to contain other pieces of content, it might start to get confusing. Like, write a "page" in the CMS. And then add a list of blog posts to that page. Does that page (content + presentation) now contain other pieces of content? And which pieces of content can contain other pieces?

I am not saying you can't pick "page" as a piece of your content. All I'm saying is you have to define the terms right up front so you have clear what is content and what is presentation.

If I look at for example textpattern, there's only one piece of content "article". And then there are many pieces of presentation: 1) "section": that's the first part in the URL, say mysite/articles. 2) "page", that's basically a main template, including header+footer. 3) "form": this is a kind of smaller block in which for example you loop through the latest 10 articles in a certain category. A "page" can contain more references to "forms". Why they picked "forms" is confusing I think.

Wordpress has two pieces of (written) content: "page" and "post". The difference being that the latter is something posted in a timeline, where as a page is not related to a time. The presentation layer in Wordpress is called "templates". In those, you can call all types of content (pages and posts) in different ways

Expression engine has a content type of "weblogs". But in this case "weblogs" are more then chronological posts, they can also be used as pages or articles, not really being blog posts. So that's very confusing.

Joomla has again a different naming scheme and way to get content and presentation mixed together. I can't remember exactly which one. But it was very very, very confusing. Maybe my therapist made me forget it :)
allspiritseve wrote:Do you think it would be better to COMPLETELY separate them? E.g. you create a blog, write your first post, and then add a blog view on the home page that links to a post view for each post? If this CMS were entirely for developers, I'd have no problem with that, but since it's used by clients I think some handholding needs to take place. That doesn't mean they can't have the option for more flexibility, just that things are dumbed down on the front end. I've been planning for quite some time now to keep locations and content separate, but I want the client's interaction with the CMS to be as natural as possible.
Yes, you are right. The complete separation is the best for flexibility. However, giving all that flexibility to clients them selves can be too much to ask. However, what you could do I think, is build the CMS in a way that you have by default a complete separation. But then, use the "templates", to get the content in the presentation layer. Now, depending on the client, you give them control to those templates or not. So for a non-technical client you would create the templates yourself and you tell the client: "Create a page and it will automatically display on your site and in your navigation menu on the left. Create a news post and it will automatically be displayed on the news page". Say you have a more technical client, you could give them access to the template section. And in that template section they could build different templates in which they make calls for different types of content. How those templates look (php, smarty, etc) again is a choice you make.

I think Wordpress does this pretty well. However, it is by default a blogging system. So even though it can be used as a cms and does in many ways perform better then most "real" cms systems I've seen (even expensive ones), it's main focus remains on the blogging part.

So the ideal CMS for me would have:

1. Content:
- articles / posts
- media (images, movies, files)

1b. Content meta:
- tags
- categories

2. Presentation
- pages / templates / urls

So starting from scratch, you go into the system and start adding content (articles, posts, images, files). Then you go to presentation and start building the presentation: pages of the site. Or sections of the URL (yoursite/about-us). Each page can contain different kinds of content. Say on the homepage you pull in an article "home intro" and a list of "latest news summeries" and a "home picture".

Or these steps can be reversed. First build up the way the presentation would work and after that add content.

Of course this added flexibility has the drawback that it takes a bit more work before you have your first webpage online. It's two steps instead of one. But, you can always decide who has to do that presentation step: you or the client. If the client is non-technical, you can "prepare" the templates and presentation (how the URLs are build up), before the client comes in and start writing content.

Re: Ideas for approach to infinite levels system

Posted: Sat Jan 10, 2009 8:54 am
by allspiritseve
arborint wrote:I am not sure I am following this very well. For me there are two separate problems. One is to specify where the "page" is within the site. The second is to specify the blocks/partials/boxes within the page. That's why I was saying that the box to page relationship is many to many. A specific box, like the latest blog post or the shopping cart, can be on many pages. And a page can have many of these boxes.
Right, but in that specific box, I can feature any content from any other part of the site (ideally).

Re: Ideas for approach to infinite levels system

Posted: Sat Jan 10, 2009 9:37 am
by allspiritseve
matthijs wrote:Sorry to respond so late, busy and timezone differences..
No worries
matthijs wrote:Well, if you don't make the distinction between a "page" as content and a "page" as presentation, then that's your choice and that might be ok. But, if you decide at some point in time that a "page" (yoursite/about-us) should also be able to contain other pieces of content, it might start to get confusing. Like, write a "page" in the CMS. And then add a list of blog posts to that page. Does that page (content + presentation) now contain other pieces of content? And which pieces of content can contain other pieces?
As I envision it now, a page can contain just about any other type of content. Only some of that content can contain other content: a FeatureBox, for example, can have many types of content attached to it. An image, though, probably doesn't have anything attached to it). I don't know how deep I want to go, but three levels of content (Page -> FeatureBox - > Featured Item) should cover most cases. Does that make my "page" more content or presentation to you? I still envision it containing text content.
matthijs wrote:So starting from scratch, you go into the system and start adding content (articles, posts, images, files). Then you go to presentation and start building the presentation: pages of the site. Or sections of the URL (yoursite/about-us). Each page can contain different kinds of content. Say on the homepage you pull in an article "home intro" and a list of "latest news summeries" and a "home picture".

Or these steps can be reversed. First build up the way the presentation would work and after that add content.

Of course this added flexibility has the drawback that it takes a bit more work before you have your first webpage online. It's two steps instead of one. But, you can always decide who has to do that presentation step: you or the client. If the client is non-technical, you can "prepare" the templates and presentation (how the URLs are build up), before the client comes in and start writing content.
What if you go into the system and add content, and the system automatically builds a presentation for you? By creating a page (content), a page (presentation) is automatically generated and live (unless you uncheck "publish"). Now, lets say you want to have an image on that page, and a feature box. You go in and edit the page (presentation) and add the new content.

Here's my reasoning for this setup. I did a usability study about a month ago for my senior thesis. I had 10 students test our existing CMS, take a survey, and then I improved the CMS. I had them do the same tasks again, and take another survey. I then compared the two surveys (unfortunately I didn't have a significant difference, but 8 out of 10 preferred the revised version... the other two just REALLY didn't like the revised version).

One thing a majority of them had problems with (these are high school 11th and 12th years) was that they didn't feel like the admin area had any connection to the website. Sure, we could probably teach them how to decide whether to edit a page (content) or a page (presentation). But the whole point of my study, and of my intentions with this new CMS, is to make things intuitive for users. We shouldn't have to spend hours teaching them how to use the system, it should be fairly self-explanatory. I guess that's what I meant by handholding.

That being said-- I can see in this discussion, using page in such an abiguous manner makes it hard to talk about. I am completely open to new, more intuitive naming styles-- but my hunch is that clients, when given the term "page", think about content+presentation as a single item. Does anyone disagree?