Oct 25, 2005
Cignex recently announced a new project called Goldegg to help bring Plone to a new level. The project involves over 26 developers from about 17 companies and will be working on all layers of the Plone stack (Plone, Content Management Framework - CMF, and Zope).
This is great news. Plone is already a very solid CMS for building a wide range of we applications from collaborative workspace to e-Commerce site. However, Plone has been struggling with how to will deal with changes in the underlying Zope application server which, with version 3, folds parts of CMF into the core product and makes several other fundamental architectural changes.
The answer, for now, is The Five Project which is a Zope 2 product that allows for the integration of Zope 3 technologies into Zope 2. However, this is a short term solution that will allow Plone developers to gradually incorporate Zope 3's new features. In September, there was a sprint in Vienna, Austria to make CMF use Zope3. Another sprint this week in Fredericksburg, VA will work developing a CMF 2.0 Alpha version. The final sprint will take place November 7-11 will refine how Plone adds Products (modules) on top of the core.
This is also significant because the new project Alfresco is going strong and already offers a compelling feature set on Java technologies which is more familiar than Python for many enterprises. Plone, with its long history and vast install base still has the advantage, but it is good that the community is being proactive about pushing the project forward in such a comprehensive way.
Since Cignex's Munwar Shariff sits on the board of the Plone Foundation, I assume that Goldegg is fully coordinated with the overall Plone project. The next release of Plone (2.2 code named "Ms. Bumblebee") is due out November 11. It will have some of the Plone view components that came out of the Goldegg work..
Oct 24, 2005
If you have been intrigued by the The JCR but feel left out because you are not a Java shop, you might be interested to know that other technologies are getting in the game as well. Henri Bergius, of the Midgard CMS has started working on making Midgard accessible to a JCR via JNI (the Java Native Interface which allows you to execute native, non-java, code from a Java application). There has also been talk about a PHP-170 project to implement a JSR 170 compliant repository in PHP although no code has been submitted.
More recently, Stefane Fermigier has written about an attempt to hook Zope into a JCR by using JPype, a Java-Python bridge. In this blog entry, Stefane makes a good case that the structure of the JCR is very similar to the ZODB because both are node based rather than relational (as in a relational database). Having JCR storage option this would address a common issue with Zope which is that the ZODB is closed and difficult to manage in extreme conditions. My current client has a ZODB which is over 45 GB (That is just text. Images are stored outside.) and is growing at a rate of 2 GB per month (packed). We are working on a prototype to store content in a relational database to get around that limitation. In the elevator, I ran into a former co-worker who works for another company upstairs and they are doing the exact same thing. The ZODB is enticingly easy to build applications on and, in most cases, more than sufficient. However, in extreme cases, alternatives, especially standards compliant ones, are nice to have.
Oct 03, 2005
There was a recent thread on the Bricolage mailing list about using Bricolage to support print as well as web publishing. Given Bricolage's history and focus on publishing magazines and other periodicals, I am not surprised that there were some good anwers. One of the respondents recommended creating presentation templates that write to an XML format that can be imported into Adobe InDesign CS. In InDesign, you can create style sheets where you map incoming XML tags to InDesign layouts. If you don't have Adobe InDesign, another option is to use Apache XML:FOP (pronounced Pho as in the Vietnamese food or Faux as in fake) which stands for Formatting Objects Processor. XML FOP is a very cool technology which takes an XML format and can output to different print formats with an emphasis on PDF.
By using this technique, you can get excellent re-use between your print and web content and you will also be able to leverage Bricolage's powerful workflow functionality.
Sep 21, 2005
A lot of people have been asking for my opinion about the recent events of a group of Mambo developers forking Mambo into a new project Joomla. For those of you who are just hearing the news, the basic story is that Miro International (which originally developed Mambo, donated it to open source, then re-initiated interest and involvement in the project), formed a foundation to manage and own the project. While the tactic of establishing a foundation generally considered a noble and good thing, Miro alienated some key members of the Mambo development community by not giving them a voice in the foundation and being heavy handed in setting the direction. As a result, some key developers exercised their right to fork the code and establish a new project.
The reality of open source is that this type of thing happens from time to time. In the open source content management world, look at the proliferation of Nuke projects that came out of PHP-Nuke. Communities are self forming and self regulating and it takes strong and perceptive leadership to hold them together. This is why we look at very closely at the leadership of a project when selecting open source software. Still, it is a shame that this happened to Mambo because it felt like this project was on a roll. After winning several awards and critical praise for ease of use, and with all the activity on Mambo Forge (a community of module developers), Mambo was getting a lot of attention.
So what happens next? In the short term, we are definitely in "wait and see" mode. Joomla has the buzz and the passion, and (I would say), the leadership. Mambo has the infrastructure and the install base but Miro will probably have to step up their support of the project to replace the momentum lost by the departure of key developers. Companies that jump from Mambo to Joomla will be pleased to know that many of the modules written for Mambo will work on Joomla, at least for now. You can see a list of Joomla compatible modules here. It may be that a lot of the module developers redirect their projects to Joomla if they are loyal to the Joomla group or if they feel like that is where the momentum is.
Tony Byrne, from CMS Watch writes that Joomla will focus on adding new features - a slight deviation from Mambo's focus on simplicity which has served the project well. It will be interesting to see the divergence between these projects.
While I would not count out Mambo or Joomla, if you are looking for an open source LAMP based web CMS, and you were thinking about Mambo, I would also consider eZ publish, TYPO3, or Midgard.
Sep 08, 2005
While catching up on my Blog reading, I noticed this post on CMS Watch which links to an InfoWorld case study of a project that was almost ruined by lack of user testing. I very much agree with Tony Byrne's point that usability is one of the biggest issues in the CMS industry and I am happy that Tony is being so vocal (one article, another article) about defining the problem and challenging the industry to fix it. James Robertson, of Step Two Designs, has also added his respected opinion to the discussion with a fine article on the importance of simplicity in large CMS deployments.
A CMS is one of those applications like a word processor where many users, often non-technical users, need to become proficient with no little or no training to get their job done. Frequently CMS users are under time pressure and, if it is quicker to misuse the tool than to use it properly, the tool will be misused - or, if possible, not used at all. Content Management is a very broad term but I think this applies to everything from this blogging software that I am using right now, to a Web CMS, to a document management application. A CMS user wants to publish what needs to be published with as little overhead as possible. As a matter of personal pride, author's want their content to read well and look good. But other than that, the less time spent with a CMS, the better.
Producing content is also a creative process and content creators don't like to feel like data entry people. CMS users don't like to waste time tagging their content with metadata. They frequently rebel when forced to fill in structured forms and give up the artistic license to determine how their content will be displayed.
But on the other side, are the consumers of the content. They are important users too. They want to be able to find the information they need (which requires good metadata) and get in a format that is accessible to them. The latter requires separation of content and layout so that content can be re-purposed to different formats. As Yair Dembinsky eloquently put it in a post on the CM Professionals mailing list:
Our main focus should be the target audience - how they want to consume the content: In some cases - they want a well written article, and in others they want to be able to retrieve small but relevant chunks of information. Writers and editors must adapt to supply the specific need of their target audience.
So, the CMS is stuck in the middle between the content contributors and managers and the content consumers. Both sides want their jobs to be easier and simpler. Some of the answer lies in automation adding information (metadata) and structuring a content asset for better reuse. But that only takes you so far. We don't want to rely on the system too much to interpret our content and make false assumptions. Workflow helps too by creating an opportunity to divide responsibility between those who create content and those who organize and classify content. However, companies typically under-invest in this area and do not dedicate editors to this task
At the end of the day, the CMS will always be a compromise between the efficiency of creating content and the utility and re-usability of the content. Content Management is a challenging problem. So what can we do to make it better?
One initiative that is just starting a new project on Open Usability called CMS User Interface Guidelines. I hope that this project gets some traction because I think there is a lot of potential here. Unfortunately the cards are somewhat stacked against it because usability is such a nebulous thing and people are more likely to complain about usability than to do something about it. I think success will lie in the ability to set down some common metaphors and idioms that users are familiar with so that they can quickly get their bearings in the application.
Like Microsoft Windows or hate it, there are some conventions that make all Windows applications familiar enough so that a new user does not get totally lost. For example, the File Menu is always on the left, Help is on the right. Ctrl-C is Copy, Ctrl-V is paste (except when you are using Intuit Quicken where they are "Categorize" and "Void". Grrr. How can you people call yourself Intuit!?). Microsoft also achieved high level of adoption for its Office applications Word and Excel by copying the UI functionality of then market leading applications WordPerfect and Lotus 1-2-3. Consistency is the key. An application does not have to be intuitive if all the users are familiar with it. Remember going to a travel agent not so long ago and watching him or her zip around the SAABRE terminal with two character codes?
Another area where things can be improved is the standardization of terminology. Different CMS products have different names for things. For example, in response to another CMS list request for different names for sub-components of content, Tony Byrne of CMS Watch listed the following:
-
Elements
-
Snippets
-
Objects
-
Placeholders
-
Pagelets
-
Styles
-
Chunks
-
Briicks
-
Parts / Fragments
-
Nodes / Fields
-
Components
Standardization in naming, design, and behavior will not only help CMS become easier to learn; it will also create a community that crosses organizational boundaries and includes both developers and users that can work together to solve this very difficult problem.
While standardization will help improve "out-of-the-box" functionality and the underlying framework of the application, in reality, CMS are usually heavily customized to work within the business context (perhaps more than they need to be, but that is another story). This is where the CMS is not a build vs. buy, it is a build vs build AND buy. Most CMS projects spend 2 to 3 times the license cost on integration. To get these customizations right, I would say usability testing is an understatement.
The worst thing you can do is spend a lot of time on gathering abstract requirements and creating abstract designs, then select a product, then do detail design with the users, then implement it, then test it and finally run it through usability testing. Any issues found that late in the process will be too expensive to fix - too expensive because you are at the end of the project and you are out of time and money. When you test this late in the game, you are basically just hoping that the users just rubber stamp what you did. And if that is the case, why test at all?
What I would recommend is have usability testing drive the design rather than validate it. Select a product, install it and show it to the users in its out of the box state. Ask them what is wrong with it. Prioritize a bunch of modification requests, implement them, then show the application to the users again. Repeat this cycle until the benefit of the modification is outweighed by the cost of implementing it. This approach, which, for lack of a better name, I call "change driven development" (a nod to Peter Coad's "Feature Driven Development"), gives business users a chance to experience the default behavior which may not be that bad - especially if not modifying the feature leaves more budget for improving another feature. In
addition to helping business users make better choices in design, involving the users at this stage of the project builds their comfort level and ownership of the application and leads to less complaints after it is deployed.
Business users know their job. They know the tools that they use. But one of the things they have the hardest time with is imagining something new and thinking abstractly. They are too immersed in the concrete of their day to day to think outside of their box. They are even worse at understanding the scope implications of their requests. So the result of waterfall approach to CMS customization is that we force users to think blue sky and, just when they get comfortable, we slam them down with admonitions of scope creep. Then we ask them to test the application for usability and we ignore their feedback. This is a recipe for failure and disappointment.
Aug 31, 2005
Totally off-topic, but if you have ever listened to the radio in Southern California, you have undoubtedly heard mention of a "Sig-Alert" about some traffic accident. In case you ever wondered what "Sig-Alert" stands for, this is what the DOT has to say:
"Sig-Alerts" are unique to Southern California. They came about in the 1940s when the L.A.P.D. got in the habit of alerting a local radio reporter, Loyd Sigmon, of bad car wrecks on city streets. These notifications became known as "Sig-Alerts." Later Mr. Sigmon developed an electronic device that authorities could use to alert the media of disasters. Caltrans latched on to the term "Sig-Alert" and it has come to be known as any traffic incident that will tie up two or more lanes of a freeway for two or more hours.
Aug 22, 2005
The Bricolage Team just announced the release of Bricolage version 1.9.0. I have not yet test driven this release yet but the notes claim that this releases includes the ability to add related media directly within an element. This feature answers a common complaint of Bricolage (and many other CMS) that a user must first upload all binary files and then associate them to an article. There is also an improved preview functionality where the preview page loads in a frame that allows you to work on a template and reload the results more easily. Other new features include: a pluggable authentication system, improved LDAP support, a PHP template burner, and the option to use the HTML WYSIWYG editor Xinha which is an active fork of the now dormant htmlArea3.
Aug 19, 2005
CMS Watch just announced the release of the 8th edition of the CMS Report. The CMS Report is widely regarded as the best, most unbiased research available on the Web CMS (WCM) software market. In addition to reviews of 31 products, the CMS Report also has useful information on approaching a WCM project from software selection techniques to people/process issues. This edition has expanded coverage of open source including a review of OpenCMS by Janus Boye and a review of Plone by yours truly.
Aug 08, 2005
I just read James Robertson's short article "More Users = Simpler CMS.". In it, James puts forth a proposition that if you are deploying a company wide CMS, it should be as simple as possible. This idea runs directly against the CMS buying behavior over the last couple of years where companies rolling out the large CMS implementations were looking for "industrial grade" software that had all the bells and whistles. Cross departmental software selection committees aggregated their feature wish lists to come up with selection criteria that favored products that had (or at least claimed to have) everything. And after all this, companies were surprised to find that the implemented solutions were difficult to use and required more training than was budgeted for.
I think the tide is changing from feature richness to simplicity and usability. A couple of other data points:
-
Salesforce.com like ASP CMS solutions are gaining popularity
-
Oracle's ECM product has been designed for simplicity. In the words of Rich Buchheim, Oracle's senior director of product management: "From the user's perspective it's not different than using a desktop application or file server."
- Leading CMS industry analyst Tony Byrne of CMS Watch sees usability as being one of the most important trends in content management: "In conference rooms around the world, authors are standing up and declaring, 'Our CMS tool sucks!' Many CMS vendors have noted this user backlash and now fall over themselves to tout products as "intuitive," "adaptive," or just plain "easy to use."
In the world of CMS, sometimes less is more. Maybe its the feature that the software does not have that will make it a success.
Aug 05, 2005
I have been reading Plone Live by Michel Pelletier and Munwar Shariff of CIGNEX Technologies and I highly recommend it. Plone Live is one of several professionally published books on Plone. Other books include Andy McKay's The Definitive Guide to Plone, Julie Meloni's Plone Content Management Essentials, and Cameron Cooper's Building Websites With Plone. Plone Live fits into this existing ecosystem by providing information for more advanced Plone developers ready to take Plone to the next level to build highly customized, performant applications.
The introductory sections are noticeably thin but I think that is OK because books like Plone Content Management Essentials and The Definitive Guide to Plone deliver pretty well in this area. You might have seen an earlier blog entry where I was critical of the choice of chapters selected for preview on Amazon. After reading the book, I feel even stronger about that point because these sections are not representative of the book's quality and usefulness. In fact, I would consider donating those chapters as Wiki articles on Plone.org so that the community can maintain and enhance them.
Plone Live starts to deliver its value beginning midway through chapter 2 with a road map of what is where in the Zope Management Interface (ZMI). Because Plone is so customizable and the ZMI is not specifically designed to manage a Plone site, it is easy to get disoriented with all the folders and other objects that need to be manipulated in order to customize and extend Plone.
The best parts of Plone Live are the sections where it discusses security and the comparative benefits of File Based vs. Through the Web (TTW) development. While most books focus primarily on TTW development, Plone Live's authors make the point that this customization method is primarily for rapid prototyping and is no way to build a robust application because of performance and deployment considerations.
The PloneLive website was built as a file based Plone Product and is available for download. There are a number of other downloadable example products available on the website as well. I would like to see a little more information on best practices for developing and debugging File Based applications such as when you need to restart Zope and when you don't, how a team of Plone developers should work together on a Plone project (source control, etc.). However, this is a good start with advice about using Selenium as a function testing tool and other best practices.
Plone Live also covers common integrations such as relational databases, LDAP, Apache, and using WebDAV and XML-RPC to integrate with other architectures. For each of these topics, Plone Live provides step by step instructions that are easy to follow.
Plone Live contains many references to other good resources including books, websites, and extensions. The book is written in a very "open source" way in that it recognizes the value of the community and is inclusive of rather than competitive with other resources. Plone Live also leverages is the open source concept of frequent releases. Plone Live is a Live Book published by Source Beat. For $29.95, you can subscribe to Plone Live for a year and get access to a constantly updated version of the book.
The critical area where Plone Live lacks is in the A to Z index. Plone Live does not have one. If you subscribe to the Plone Live book, I am sure this is not a problem since there is probably search. However, I think it is an issue with the paper version. This is the first Source Beat book that I have read so this might be a format constraint imposed by the publisher.
Based on all this, if you have been playing around with Plone or have been using it for a small work group solution, and you want to get serious, pick up Plone Live. You will be glad you did.