nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Content Mgmt Process Templates

nithinbose

Hi All,

We are starting a new project with TeamSite. I was looking for any templates for requirements capture, content architecture and taxonomy.
Will be greatly obliged if you could forward me any document you have.

Thanks in advance,
Nithin

Find more posts tagged with

Comments

Migrateduser

I have these things but the are proprietery. One suggestion I can make - use XML to document your requirements. You can use the DCT format for your XML, but replace inlines with entities. You can add attributes that Interwoven doesn't support, then use one XSL for viewing the requirements, another for generating the real DCTs.

nithinbose

Thanks a lot.

Thats a pretty cool way of capturing DCT requirements. We shall surely give it a try.

Any best practices on Content Audit and architecture?

~ Nithin

Migrateduser

> Any best practices on Content Audit and architecture?

Not really sure what you mean there, but if you are concerned about audit trail, I would certainly say replace SubmitTask with an ExternalTask that assembles better submit comments - who approved, when, what their comments were, etc. - and uses iwsubmit, OpenAPI or ContentServices instead of the default, which historically inserts pretty useless submit comments. On architecture, personally I steer away from Perl, use generate XML for transformation with XSL, use integration branching, one workarea per branch, etc. There are tons of concerns in this area and I'm not sure exactly what you're looking for. Focus on the foundation instead of the immediate deliverables.

nithinbose

Thanks Jimmy.

I was looking for templates to capture requirements on what kinds of content need to be supported by TeamSite, their frequency of change and the process involved with them. This would serve as a reference to derive DCT and workflow requirements. We have a slightly dated template, just wanted to find out if experts in the field had more to add to it.

One workarea per branch brings up an interesting point. If we intend to use TS for managing and versioning of code and content, are you suggesting we use one branch per lifecycle(Integratio, QA, Production?)

Thanks,
Nithin

Migrateduser

Sorry, I'm not following, probably a terminology thing. My experience is that if you put multiple workareas on a branch (even if one is just an admin branch used for regeneration), you generally end up with submit conflicts, locking issues, content synchronization issues, data/code duplication (maintaining the DCT and TPL code in all workareas on the branch), integrating with applications (how to determine which workarea CCI links should point to), etc. I think I remember reading somewhere that newer Interwoven products even dictate that only one workarea exist per branch or per user or something. Anyway there are additional concerns when there are multiple workareas on a branch, and in my experience they are generally just created for political reasons (I have seen very few cases where multiple workareas on a branch made any real sense, and then multiple branches made more sense than multiple workareas). Of course that's mostly for content development - if you're developing applications each developer may need their own sandbox.

I definitely wouldn't use one workarea for dev, QA and prod. I like to deploy content to QA environments that exactly mimic production because if you QA against a workarea QA is invalid because that environment does not replicate production. I would also suggest dev, QA and prod CMS instances. If you can't justify the hardware/licenses then I would probably go with branches for each environment. It's really hard to say without knowing your requirements - I wish IW would publish more best practices info on this subject (but then they couldn't ream their customers for services).

nithinbose

Thanks for your help.

I do agree with the point you made about branching and workarea setup. That is the approach we are mostly leaning towards, as we cannot get one CMS instance per environment.

Nithin