Hi Jennifer. Over the past 4 years I've been working with CMS tools in maintaining site templating and content management. I've worked in Stellent but mostly in Percussion. Over the years I've actually taken control of doing the actual implementation and development both the CMS tools I've worked with.
I'm also the interface designer for the project so that allows me a good bit of freedom to figure what can and can not be done, or more how it can be done but with what difficulties. I think that in working with a CMS there are a few factors that would help improve our overall partnership with the tool: content chunking, modular templating, and scripted interactions. Since the primary goal of a CMS is content management, reuse of content and that content's data is quite important. As a UX person I normally approach how I would be using these various chunks of content. How would the display title be presented, where would it be, could it vary, how would it vary, and what would trigger it? One content item's title and description could be used in various sections of the site. It could potentially look different from one section to another. It could serve completely different purposes from one section of a page to another. So figuring out the purpose, the how's, why's, where's, and when's would help in determining how your interface changes but also how a developer would go about implementing it. Is it based on content type, folder, a data field selection in the content type, content id, name, etc..? This would allow for modular templating. A CMS at the basic assigns something to one particular template. It could be an assignment on the folder level or the content type level. It's mostly a one-to-one relationship, a primary template for a content type in the case for Percussion. What I normally allow for are buckets of information to be used in a page. Percussion uses something called "related content". I created a content type called "Bucket". Anyone can put any type of content in this bucket. Depending on what page is calling for this bucket or even where on that page it's being called, the rendering of that bucket of information changes. The content item created can be filtered through various templates depending on the situation that I define. Depending on how robust the CMS is, I guess, you can have one global template but it presents multiple menu systems, logos, and masthead titles depending on which directory the content is being called from. I scripted my "global template", which in Percussion is the wrapper (header, footer, main global nav), to recognize what's what content is calling it and changing accordingly. Essentially it all boils down to you seeing the many uses of the content that's being stored, what those content types do, how it'll change, and their triggers. If you're not the one implementing then you'll need to provide that level of information to the developers to implement. Try to find a reasonable pattern so that the coding doesn't have to be specific. Does content type A's data field XX present in template 1a everywhere but except when it's a content item is in folder FF, then it'lll use template 2b? Developing for a patterned behavior is more efficient that a bunch of one offs as that would take more time and then there would be a lot of code bloat in the templates. Hope that helps, Thai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Posted from the new ixda.org http://www.ixda.org/discuss?post=49455 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... disc...@ixda.org Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
