Each piece of content (however we might end up defining that) should be stored [WardsWiki:OnceAndOnlyOnce "once and only once"]




The other items seem right, and are oriented toward user function. This one seems like a technical design criterion, and I'm not sure this solution will work right for users for a couple of reasons.

I'm not sure this is the right way to manage a publishing function. It's a common use case to collaborate on a document within a workgroup, and then to publish it to a more public (organization-wide) or all-public site. Once that happens, the document becomes part of a different conversation. It's not clear that the revision/comment history of the public document should be the same as the revision/comment history of the document under development. Another way to put this -- when an evolving document changes context, when does/should it become a different document?

It's also not clear that content-based privilege levels is the most user-friendly and administrator-friendly way to manage access. It's fairly intuitive to think that a set of content is private within a given group. It's harder to give administrators dozens of privacy level choices with thousands of pages, and expect them to be able to manage correctly without mistakes or bottlenecks.

Traditional document management systems provide fine-grained access control, at the cost of a heavyweight administration, management, and user processes. Enterprise wiki may want a different set of compromises.

To provide wiki-speed editing, and the kind of easy administration you'd want with an enterprise wiki system, different design patterns might be warranted.

Would love to hear more thoughts on this. AdinaLevin
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki