Page 2 of 3
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 10:01 am
by josh
I would agree, but also point out treating content like a model, and then treating presentation as a separate layer although less intuitive is more powerful. If you let the user preview the content in multiple formats in the edit page it wouldn't need to be explained either. Problem with embedding presentation markup into content is obvious
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 10:05 am
by allspiritseve
jshpro2 wrote:I would agree, but also point out treating content like a model, and then treating presentation as a separate layer although less intuitive is more powerful. If you let the user preview the content in multiple formats in the edit page it wouldn't need to be explained either.
Is it possible to do both?
jshpro2 wrote:Problem with embedding presentation markup into content is obvious
What do you mean by "presentation markup"? I assume you're not talking about <strong></strong>?
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 1:11 pm
by matthijs
allspiritseve wrote: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.
Now that I read this post of yours I understand better were you want to go.
What you say here is why I talked about deciding what level of freedom and difficulty you want to hand to your clients. If you want a system that's easy for non-technical clients, then the system should be able to support that. Then that means that you build the templates and the structure first (which template is going to be used in what situation, and what content is pulled into each template, etc), so that the client only has to go in after that and create the content ("write newsitem", "write article").
allspiritseve wrote: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?
Yes, I think you are right to think that. Most would see a "page" as exactly that, a webpage, like any webpage they visit on the internet. The thing is, that they want to create these "pages" easily. Fair enough. Log in, go to "add page", fill in some text and click "publish". But the difficulty now is often, they want to start doing more then that. They want to put other pieces of content on that page. They want to list a few news items below that article. Etc etc. Now how you do that, that's the biggest difficulty.
Make it restrictive, and it is easy to use. Make it flexible, and it gets very difficult to use fast.
Maybe for a real non-tech client it should be like:
- log in
- create page, write, click publish
(the page appears automatically on the site and in the navigation, in the way you prepared everything)
A somewhat more experienced client would want to do:
- login
- upload few pictures (=content)
- write article (=content)
- write news items (=content)
- create page (=presentation)
- decide what goes into that page (this article first, and then a list of these news items)
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 1:25 pm
by allspiritseve
Exactly. I would like to tailer to both types of clients, while also giving us as developers total freedom Essentially I want to make a CMS for developers, that makes no assumptions and can be overwridden easily in the code. On top of that, I want to provide a user experience that I can cater to the client's skill level. Even infinite levels, for example, won't be given to every client. Some of them may only need one level of pages. Some may need two, like our existing CMS (probably the majority of the sites we do). Some, those are restrictive, and the client is savvy enough to be in control of organizing their content. The thing is, I need a different approach to each of them. What works for infinite levels would be very confusing to someone who can only edit one level of pages.
Now, another question. Say a user logs in, and wants to create a blog. They pick the location, give the blog a name, make their first post, and hit publish. If a blog display, a blog archive display, and a blog post display are created, would you consider those "pages"? Is page, to you, an underlying concept that applies equally to blog, archives, posts, as it does to normal content pages? Should the user be creating a page, and then adding a blog to that page? Now, I know we're all developers, but how do you think a client would think about it?
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 1:31 pm
by josh
allspiritseve wrote:Is it possible to do both?
Both what? Ideally you want your content in semantic form, its less intuitive but its for the client's own good. To me its an acceptable usability trade off.
What do you mean by "presentation markup"? I assume you're not talking about <strong></strong>?
<strong> would be semantic, <b> would be presentation. Basically for instance instead of embeding an image tag you define related image types. Images themselves are content types, with their own fields. There is a BLOB type field and user's can place white/black list on mimetypes for each content type they choose to define. It might not be an end user setting up a content type, it might be an "architect" I hire to work with the client for example ( at least this is my plan ). After I find out the "patterns" of how my system is used, I'll make pre-packaged schemas and market each "system" to a different niche. For instance a book store e-commerce system might have a lot more granularity in the schema around the books, than it would for the help area. An IT site might have an elaborate help system but only a simple e-commerce system, basically my "architects" will all/most of the configuring and get billed, or pay to be able to get the module turned on so that they can architect their own system
allspiritseve wrote:If a blog display, a blog archive display, and a blog post display are created, would you consider those "pages"? Is page, to you, an underlying concept that applies equally to blog, archives, posts, as it does to normal content pages? Should the user be creating a page, and then adding a blog to that page? Now, I know we're all developers, but how do you think a client would think about it?
Use the world view. List view, Grid view, Full View... the view is not dependent on the layout or parent page so I would just leave these extraneous nouns out totally. Just say Preview: and show them the different areas, I'd label them as what they are. If the front page and search results page use the same template partial there's no need to preview that partial twice just because its called from 2 places.
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 1:40 pm
by allspiritseve
jshpro2 wrote:Both what? Ideally you want your content in semantic form, its less intuitive but its for the client's own good. To me its an acceptable usability trade off.
Allow clients to add content in a semantic form, and have the presentation automatically created for them. But still leave the possibility for a developer to go in there and modify the presentation.
jshpro2 wrote:<strong> would be semantic, <b> would be presentation. Basically for instance instead of embeding an image tag you define related image types. Images themselves are content types, with their own fields.
Ah, I see what you mean. Yes, I definitely want to keep images out of the content as much as possible. Have you seen the "notes" feature on facebook? If you add an image, it gives you layout options for where that image could go. I thought that was really cool, and allowed me design flexibility without ever touching a lick of html.
jshpro2 wrote:After I find out the "patterns" of how my system is used, I'll make pre-packaged schemas and market each "system" to a different niche. For instance a book store e-commerce system might have a lot more granularity in the schema around the books, than it would for the help area. An IT site might have an elaborate help system but only a simple e-commerce system, basically my "architects" will all/most of the configuring and get billed, or pay to be able to get the module turned on so that they can architect their own system
That sounds very similar to what I want to do. Currently we hack our page editor for most content, but I would prefer very specific content items like books. That's why I was originally leaning towards EAV, so content items like that could be easily generated and used without touching the db.
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 1:42 pm
by allspiritseve
jshpro2 wrote:Use the world view. List view, Grid view, Full View... the view is not dependent on the layout or parent page so I would just leave these extraneous nouns out totally. Just say Preview: and show them the different areas, I'd label them as what they are. If the front page and search results page use the same template partial there's no need to preview that partial twice just because its called from 2 places.
Could you elaborate on this? What is the "world view"?
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 1:45 pm
by Christopher
I am not following this conversation that closely, but would it be possible to create "tags" that would LazyLoad helpers -- like [image foo.jpg] would load an "image" helper and call $this->helper->image('foo.jpg); ? This sounds like a template system problem more than a CMS problem, but maybe I am missing the point here.
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 1:50 pm
by allspiritseve
arborint wrote:I am not following this conversation that closely, but would it be possible to create "tags" that would LazyLoad helpers -- like [image foo.jpg] would load an "image" helper and call $this->helper->image('foo.jpg); ? This sounds like a template system problem more than a CMS problem, but maybe I am missing the point here.
Well, sure, but when you get into image titles, descriptions, links, alt tags, etc., it becomes less feasible to manage the image inside of a text box. Instead of treating it as "part of the page", I'd like to make it a separate content that is attached to a page in the same way a textbox would be.
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 1:51 pm
by josh
You could have tags but they wouldnt be "image" tags theyd be "content" tags. "image" would be a content type with fields, the fields might be title, creation date, updated date, exif data, binary image, etc.. ), basically your image is more than the file, its an entity modeled in the domain, and the users should be able to store facts about the entity.
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 2:10 pm
by Christopher
So are you saying that [content foo] might show an image with caption, and [content bar] might show a textbox ?
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 2:18 pm
by allspiritseve
arborint wrote:So are you saying that [content foo] might show an image with caption, and [content bar] might show a textbox ?
No, that part would be hidden from the user. Imagine a template like this:
Code: Select all
<div id="page">
<div class="right-column"><?php echo $image->render(); ?></div>
<h1><?php echo $title; ?></h1>
<p><?php echo $body; />
</div>
Now, the client would be presented with a text box and a textarea for the page content, and maybe an upload box, a text box, and a textarea for the image. No html is needed, and each form element is only concerned with the content type it's meant for. Basically, it's separating the page formatting and layout from the content entering. Situations like an inline image, on the other hand, may require less separation.
Re: Ideas for approach to infinite levels system
Posted: Sat Jan 10, 2009 4:17 pm
by josh
Well content wouldn't show anything, content would basically be the model, then users would have to define views...
Basically if the "default view" for an image was a template that included the caption, then yes a caption would show up along with the image. Perhaps another view would output the image at a different size, or apply different markup to the caption, etc..
The key point is that
metadata can be associated with the image, wether or not its used in a so called view scrip is irrelevant, its there for semantics, the admin panel would allow searching, etc... prepopulate fields with exif data, etc.. ( I've thought this out ). I plan to also do the same with video, etc.. and even write an ajax video editor in jquery

( ffmpeg / flvtool timecode injecting - on GNU linux).
Re: Ideas for approach to infinite levels system
Posted: Sun Jan 11, 2009 11:42 pm
by allspiritseve
What would you call a content/handler pair? (A handler is essentially the name of a Controller+View class... the Presenter in Model/Presenter).
I'm considering having a node/entity/resource that I can attach a location, content_id, name, and a handler. Thus, the routing would work like this:
- Using location, find resource with specific name
Get handler from resource
instantiate handler
pass in content_id, along with any url params
give handler control of page
The hard thing with trying to find a home for these is that not all resources have a location or a name (a featurebox, for example, is attached to a page and is not directly accessible from a url). Other times, resources have a location and a name but no content_id. There may even be situations where a resource doesn't need a handler... can't tell yet. I guess I haven't done much infrastructure work so its hard to visualize all this, especially when they're pseudo-domain concepts.
Re: Ideas for approach to infinite levels system
Posted: Mon Jan 12, 2009 8:42 am
by josh
Node's, see ezpublish. think of them like hard links but theyre not ( not recursive ). See wordpress permalink's URL templating / permalinks. Looking at something like that for routing, most of this stuff would be in the "advanced" tabs, etc... or used by my staff only to create new packages. Basically what I'm going to do is create different platforms targeted at different industries / sizes of business. See SAP