CMF Dogbowl: Thoughts on different Portal designs and the CMF
By jshell [ http://cmf.zope.org/PTK/Members/jshell ]
March 1, 2001
I recently joined the CMF team here at Digital Creations, although I've been with Zope and the company since the just-before-Principia days. This document is purely personal at present and reflects my own perceptions on some of the different "Portal" styles on the web and how the Content Management Framework might be applied to cover those situations.
The emphasis here on the CMF is Framework. Before Principia, Digital Creations had many web applications based on Bobo (the ZPublisher component of Zope). These applications did things like publish DBF files on the web, or did discussion boards, or publish relational data. While they were all similar fundamentally (they were all done in Python, made use of persistence, used the Python Object Publisher), they couldn't be combined easily for more custom solutions. One of the things that Principia offered was a Framework for these objects to fit into. That framework allowed them to all have similar management interfaces. It let instances of these objects to be placed together side by side. Common elements like DTML Documents could be abstracted out and used in all of them. Security Management became more unified. Over the years since Principia was introduced and it later became Zope, the uses of the system have changed somewhat from those initial designs. But the idea of the framework offering common services remains a strong part of the design of Zope.
The CMF extends this concept further by providing a Framework for web based content management. New services offered by the framework include things like workflow and membership. For developers, it offers the opportunity to design content objects that are easier to use by people who contribute content to the site in a simpler environment than the standard Zope Management Interface (ZMI). For the developer it also offers the ability to customize and replace central CMF services with specialized ones, while still providing useful default services out of the box.
As I stated above, I'm still new to many of the concepts and designs of the CMF myself. The rest of this document is my attempt to explain my perceptions, pose some questions, and give some starting points on how to use the CMF to implement different solutions. At present, this document only represents my view and not those of Digital Creations.
These are the My Yahoo and My Excite style portals of the world. They are steeped deeply in the concept of syndicated content and massive personalization. Some people see no point to them, others find them invaluable. They center around the concept of the user customizing their "Home page", which usually involves deciding what content boxes are drawn and what goes in them. For example, on my personalized Yahoo page right now, I've got snow reports from various ski resorts, news feeds from five different new sites (business, technology, entertainment, etc), health information, weather information, an eye on air fares to cities I like to visit, TV listings, and stock information. Most of this information is coming from outside resources, but made to fit my layout and content choices. The emphasis of these sites is to easily give the user a personalized page that takes content from around the web and give it to the user in a unified fashion. From there, they go off and do other things that are outside of the scope of this example.
Currently (in the near 1.0 release of the CMF), this would be pretty hard to build with the default tools. The big thing missing right now is syndication. But that one is coming very shortly. However, the design of these types of sites differs greatly from the design of the CMF. A lot of the core services would have to be replaced with a very different style of service. I believe that the design of the CMF makes it possible to implement this style of site using some of its services, but a lot of custom design work would be involved. But there are very few of these sites, and even less that are succeeding. It's doubtful one would want to design this type of site lightly.
What's hard about these sites is basically the amount of effort involved in getting all of the news feeds, making layout customization easy, putting enough hardware behind, and lastly - being able to succesfully compete against "the big guys".
These are much more common throughout the web. They fit less with the more traditional notion of "portal", but fit well into the styling of the CMF - with some customization. Some examples include Wincent.org and Scripting.com. And there's always the infamous Slashdot a style commonly referred to as a "Weblog". The front page of the site includes a large central column with news items and their lead-ins, or just a bunch of paragraphs and links in some cases. The end user might not have any membership usage on the front page, but some sites do offer discussions and other community benefits. Most of the content on the site is done by a small handful of people.
Some common traits on these sites are: you don't have to be logged in to get use of the most common aspect of the site - reading news; Many of these sites offer some sort of membership option, but it often involves being able to post to discussions on articles in a non-anonymous fashion and maybe have some traits watched (how many posts has this person made? etc). Some do offer some degree of personalization when the user is logged in, like being able to track favorites or watch certain topics. The average user can typically only contribute content in discussion groups.
Variations among these sites typically fall into how they deal with discussions. The Weblog format typically has large discussions (on succesful sites) attached directly to the article, while other sites may allow some simple discussions attached directly to the article but offer larger discussion group areas of the site that are loosely attached to the news area.
Lastly, there are the big guys: News.com, ZDNet, InfoWorld, and online newspapers like the Washington Post and the New York Times (and even small town newspapers). These too are news sites, typically with less discussable content and sometimes a higher degree of personalization. These sites depend heavily on workflow for their publishing process, with many contributors doing different jobs along an articles path, such as entering the story, doing the layout, mocking up a graphic, timing the release, and deciding where the story lead may go on the front page or some subsection.
With a little customization (besides the look and feel), the CMF is very useful
for these types of sites. Creating a role of Contributor separate from
Member and setting permissions so that only Contributors can create
new content gives that handful of people an effective content management system
for writing articles and managing the news. A Member can be granted discussion privileges,
and they have a space to store their "Favorites" within the site. If a particular
member shows that they're quite knowledgeable by contributing useful information
to discussions, they can be given the contributor role relatively easily and be
able to write their own articles for the site. This could probably all be done with
the basic PTKDemo tools without too much work.
A big upcoming feature is Topics. These are basically canned queries, similar to "custom views" in some email packages or saved searches from a search tool. In addition to storing Favorites, which are just static links within a site, a member could have a customized topic that might be "Show all NewsItems about the CMF that were posted in the last two weeks". This gets turned into an optimized Catalog query that is always live. This is a powerful personalization feature, and proves even more useful in some other Portal types described below.
There is also an upcoming Zope technology called Presentation Templates that will ease the jobs of people involved with laying out a site or a particular story by letting them use design focused HTML tools more easily with Zope, and letting a Zope integrator tie their HTML in with the actual content of the site without requiring the page to be ripped apart into seperate DTML pieces that the designer can no longer make use of.
Cross reference Zope.org ;). The current Zope.org was actually the scratch pad for what has become the CMF. It is a site that lets almost any member of the community who has joined make their own home page and publish all sorts of content that gets reviewed and published on the site. There are some very specialized content objects such as Software Packages and Releases that befit a community of its nature. Other tools like ZWiki are used to further involve community participation.
Boiled down, these sites are similar to the News Site described above, but usually with a more open policy (by letting members contribute content) and generally with a less news-focused design. Their usage can be for news, how-tos, software releases, project development, and more. A simple Intranet site could also fit in this category, with the community being the employees of a company. I'll discuss this one further down.
Out of the box, this is what can be built, although it might be desirable to build some more focused Content objects that would benefit the community in question. Also, Membership policies might want to be revisited for communities that would require approval of a Member before they're allowed to contribute content.
A key design philosophy for many of Digital Creations products, even before Principia, has been the concept of being able to safely delegate control.
These tend to be very focused sites, like Microsoft's MSDN or Apple's Tech Info Library (TIL). They tend to be huge collections of articles and documentation serving very specific purposes. Some sites exists purely for querying, others might allow discussion on new articles or the ability to rate them (the "did this article answer your question?" scenario). The "members" in this case are similar to the members of the news site - some simple personalization might be offered to let the user find their favorite articles quickly (very useful in large knowledge-based sites so you don't have to keep digging for that article on CSS 2.0), maybe the ability to comment on articles and rate them.
In the design for these sites, you seldom want to have the visitor to the site remembering their password and having to login to gain access to features of the site. The design should be focused at letting the user get answers to their question. Thus, personalization can stand to be a lower priority. The high priority is getting that content into the system easily, and finding content in the system easily. This requires the content to support a common set of meta data to ease indexing and make search results more accurate.
The big factor in making these sites work is getting that content in. The workflow tool might want to be replaced with a dead-simple policy that publishes all content as it comes in, at least during the inevitable bulk-load times. Something that is planned for the CMF but is not in place quite yet is the registration of ParserHandlers, which handle the job of turning incoming data into Portal Content. In sites like these, where there will tend to be long articles, word processors such as Word become prevalent. Some tools are being worked on that can not only extract the content of these documents, but also the meta data so that it can be easily catalogued and found.
Furthermore, WebDAV is also becoming more prevalent in many desktop environments, including the new Mac OS X finder and Eazel. Since Zope already supports WebDAV as well as FTP, this significantly eases the job of getting content into the system, especially when good parsers exist to turn the uploaded data into easily findable portal content that mixes in with the look and feel of the site.
A slightly more advanced design could, for example, keep the native Word document in store alongside the Portal-ified version, allowing people the option to download the content in its native format.
These tend to be more advanced than the Knowledge Management styled public sites. Intranets tend to have highly specialized content, such as a contacts database, project management, communication, and so on. An Intranet is often a desire to link some aggregate sources of information that might already exist within a company (an LDAP directory of employees and contacts, a relational database of inventory) on top of all of the documents that are crucial to all employees (Human Resources documents about web usage policies, time off policies, etcetera) as well as teams and departments and projects.
Corporate Knowledge Management can become crucial, as it's often desirable than if an employee has a question about "What's going on with xxx?", "How do I do xxx", and "Is someone already doing xxx?", they should be able to find the answer without too much difficulty. This requires some degree of resources and a well defined and maintained site as well as a company culture that promotes proper use of the site (keeping information you're responsible for up to date for example, a task that is not always easy).
Some degree of customization can also be important for these sites. It might be useful to give an employee a "start page" that shows a list of tasks assigned to them, a list of documents that might need their review, and maybe some personalized charts and graphs or other "quick links" to content that's specific to that employee and their job description. A software engineer wants different data than someone in the sales department.
Zope has already been effective in many intranet situations due to its ability to work well with aggregate data resources through the use of publicly available tools such as Database Adapters and ZopeLDAP, as well as the occasional totally customized adapter. Combine this with what can be done with a community style site, and you've got a decent Intranet. Add in the ability to easily publish content from tools like Word, and it gets even stronger. And most of this can be done out of the box right now, or in the very near future. From here, one could go on to designing or downloading custom content types and tools like the Tracker or ZWiki and integrating that in. Topics become very helpful for establishing built in dynamic queries for the site that tie aggregate content together, as well as letting the users of the Intranet make their own custom views into the sea of knowledge that exists, while cutting down on the "click and hunt" scenario ("maybe that document is here. No, maybe this is it...").
Copyright 2001