Jun 23, 2009
Deane Barker, over at Gadgetopia, has posted slides from his presentation "Just put that in the zip code field". He gave the talk at the Web Content 2009 conference in Chicago. Unfortunately, I was not able to attend the conference and missed seeing Deane present. However, knowing that I am as passionate about this stuff as he is, Deane and I did talk at great length on content modeling during the days leading up to the conference. Oh, the war stories we told. Those conversations inspired me to write this post on pages and objects.
The reason why I find this topic so important (aside from the fact that I am a recovering DBA myself) is that content modeling capability is one of those difficult to change characteristics of a content management system. It is what I call a "load bearing wall" in the customization of a CMS. That is, while it may be possible to remediate a content modeling limitation, all the buttressing required may make such an effort impractical. Content modeling architecture is so difficult to change, in fact, that the products themselves tend to live with what they have and change very little in this area. Products that do change how they model content usually take a while to stabilize as they work out the nuances of how to generate entry forms and validation routines and the appropriate templating syntax to access the elements.
Because of all this, content modeling is a critical part of my CMS selection process. Part of my demo process requires the suppliers to implement a content model specification that is based on the client's own content. Deane's presentation also gives useful tips on what to look for in a CMS. In particular, I look for the ability to support specific data types and structures. Don't know what that means? Then take a few minutes and click through Deane's presentation. Or, better yet, look for an opportunity to see Deane present it live. You might see me there too.
Jun 17, 2009
Back in prehistoric times, I was implementing a custom CMS for a very large computer manufacturer. The data model drew a distinction between "pages" and "objects" and I remember having a difficult time understanding (and then, later, explaining) the difference. At a high level, objects were items of content (like a "product") and pages were containers (like a landing page that lists collections objects). The areas where my simplistic explanation tended to break down were 1) the notion of a detail page that just displayed one object and 2) unmanaged listing pages that just automatically listed objects. These were the cases where you would have pages on the site that do not map to "pages" in the repository. If you were to practice the page/object model in its truest form, you would create a page asset to wrap objects for every page on the site. This didn't make sense when you had a product catalog with thousands of items (objects) in it. Over time, the page content type became less and less used until it was defined as strictly as a tool for building landing (also known as category) pages. That made sense because the site was really about the products and displaying them in lots of different ways. But if this had been a project to build a typical brochure site (where contributors focused on managing things like the "about" page or the "services" page) we may have gone in the other direction and focused on pages. Objects would have diminished to components that could be re-used across pages.
Another way to look at is to ask who owns the pages, the contributor or the display tier? In a page based model the user owns the page. He places the page in a site hierarchy, gives it a URL, and then fills it with content. In the object based model, the contributor feeds in the content and the display tier (the controllers and the views) has the logic to decide what content to show and how to show it. Like I mentioned in my computer manufacturer website story, the object based approach tends to do better with sites that have more content than is practical to manually organize onto pages. In an extreme example, think about if www.google.com was a website that someone had to manage. No matter how many editors they hired, it would be impossible for an editorial staff to manage every single result page. Maybe they could go in and fix the descriptions of a few index entries here and there.
When I look at web content management systems today, I see similar stories to my prehistoric custom web content management system experience. Every web content management system on the market today grew out of some project to build a website and then was abstracted to build more websites. A WCMS is either conceived as a product and then heavily shaped by its earliest customers or it starts life as an in-house project and then is abstracted into something that could be resold. Those initial uses leave their imprint and become part of the product's DNA. That doesn't mean that products are necessarily limited in their use. As it matures, a product runs into diverse range of potential customers that forces it to broaden its capabilities. In the real world, of course, web sites are combination of pages and objects and the contributor needs at least some level of control of both. However, this digital DNA does help determine what problems it solves more naturally (or comfortably, or intuitively) than others. Page based systems need to figure out a clean way to manage "placeless" content and object based systems need to figure out a simple way to manage basic pages. Some of these additions feel more awkward than others.
The only way to really appreciate the difference in approach and its implications for you is by demonstrating the products managing a site like yours with content like yours. I like the scenario approach where you (or the vendor) build a prototype using your content types and then testing it with your typical usage scenarios. It is only then that you will see how well it addresses your balance of objects and pages.
Jun 05, 2009
It was great to catch up with so many friends at the Gilbane conference in San Francisco this week. I spent literally two hours saying goodbye on my way out the door. One question that I found myself frequently answering was the reason for my recent blogging lapse. The short answer is that I have been very busy. But being busy doesn't always keep me from lobbing posts into this blog. In fact, I often find myself more compelled to blog when I am immersed in interesting work.
The truth is that I occasionally use blogging as a procrastination tool. I blog to avoid important tasks (like writing reports and deliverables) that I can't motivate myself to tackle. Blogging helps me warm up my brain and prepare me to really think. I guess when you look at it in that way, I am not procrastinating but preparing; after I publish, I am usually ready to work. So why the lapse? I have been using a better procrastinating tool.
I have taken on some application development work and I have found programming to be a more powerful distraction from my other work. When I get an idea for a blog post, I write it, publish it, and I am done. I am ready move on to that deliverable or report. When I get an idea for how to improve a feature of my application, I get sucked in and have a very difficult time stopping. There is always something more you can do to improve or extend your code. Maybe I will get curious about how something works and start exploring. I blink and 30 minutes have passed. Video games are the same way. That is why I don't allow myself to play video games. But I will never entirely give up programming. Technologists who do rapidly lose their relevance and limit their options.
Based on my small survey (sample size: 1), I would say that, other than video games, coding is the most effective tool for keeping you from important writing work (or any other activity for that matter). Knowing this about myself, I usually take every precaution to avoid programming when I need to write. When I write my reports (in XML), I make sure to hire someone else to do the XSL:FO work for my rendering templates. I deliberately started blogging on Blogger because I knew fiddling with a blogging platform would keep me from blogging. I knew this would happen when I took on this development project but it was so interesting that I couldn't resist.
I am wondering if there is some neurological explanation for this disconnect between programming and writing: that your programming brain suppresses your writing brain. My anecdotal observations seem to suggests others struggle with this too. For example, developers often hate to write documentation. I don't think that is because of poor writing skills. Of course, it also be that documentation happens at the end of the project when developers are burned out. Does anyone else have similar experiences? What is your most dangerous procrastination device?
Jun 03, 2009
Yesterday morning I presented a three hour workshop on selecting a web content management system at the Gilbane Conference in San Francisco. I was told to expect a small audience but the room filled up quite nicely. I ran out of hand-outs but you can download a copy here. Here my slides.
Today I will be presenting in a session on WCM Architectures and Customization. My talk is about architectural patterns in web content management systems and strategies for extending them. Here are the slides.
Jun 01, 2009
While I work with companies from many different industries, most of my clients media and publishing companies. I like working with publishers for many reasons — not the least of which is the fact that this is an industry in transition and it is exciting to see my clients innovating and re-inventing themselves. But the main reason publishers are so interesting to work with is that they, more than any other industry, understand the value of content. It is their business. While you could make the argument that a publisher's key asset is its audience (not the content), it is the content that attracts the audience. Publishers push their organizations to produce content that an audience wants to read and then look for ways to monetize that audience.
Compare that with other types of companies. How many marketing organizations think of their website copy as only a modest improvement over the Latin text that the web designer left behind? Internal content is worse. Updating the intranet is the last priority for the average knowledge worker. People have more gratifying responsibilities than contributing to a web site that nobody wants to read. In most companies, employees are not recognized for their intranet contributions. Take, for example, a knowledge base. If you have a brilliant piece of information, depending on where you work, it may be better to share it with individuals you know and have them "owe you" than to leave it to rot a in a place where nobody will benefit from it.
Companies fool themselves when they think that if the tool makes contributing easy, staff will all of the sudden think contributing content is their number one priority. You might get a slight uptick of activity when you deploy a new publishing system, but after the novelty wears off, people will go back to their old habits. Writing content is hard work no matter how "fun" the tool is to use. Employees will gravitate to work that is either easier to do or more rewarding (that is, things that are measured by their bosses).
Assuming that enterprise content has value and is worth managing, there needs to be someone in the organization responsible for maintaining that value. Enterprise content needs someone to represent the audience and ensure that they are being served. Enterprise content needs a publisher. Pardon the geeky comic book reference but think of Peter Parker's (aka Spiderman) obnoxious boss J. Jonah Jameson (pictured above). He relentlessly pushes his staff to create content that he knows his readers want to read. Granted, nobody wants to work for a jerk like that. But is it any better to work for someone who doesn't care about what you produce?
In the media and publishing world, Clay Shirky theorizes that the role of the publisher is becoming unnecessary. The Internet has solved the journalist's problem of reaching an audience. But that assumes that the journalist wants to become his own publisher. The blogging phenomenon has seen just that. Bloggers (citizen journalists) put up their own websites and invest large amounts of time building and cultivating their audiences. They look at traffic stats; they think about wording for SEO and click through; they tag; they obsess over establishing their personal brand. They didn't do this just because the blogging tools were easy to use. The first generation of blogging tools stunk. But the first generation of bloggers really wanted to publish and they were just happy for the opportunity. Inconveniences and poor usability were not going to hold them back from having their voices on the Web.
Many Enterprise 2.0 advocates predicted the same thing would happen inside the firewall; that employees would self publish with the same zeal on the Intranet as they did on their personal blogs if they had similar tools available to them. It didn't happen — not because they couldn't figure out the tools but because they were too smart about managing their time. They knew that they would gain more during their 9-5 work day from doing other things. They satisfied their inner publisher during nights and weekends at home where they could reach a much larger audience and own their content. If they could get away with it, they would sneak in a post to their personal blog from their cube.
There is only so much you can do to motivate your employees to "want" to publish on your Intranet. You can make it part of their job description; you can recognize their efforts. But you will probably not be able to create the hunger for attention within your firewall that will unleash that entrepreneurial publisher spirit. If they have that spirit within them, it will be expressed on their personal blogs. To get your employees to act like journalists, you need a J. Jonah Jameson type. Maybe not as abrasive, but just as passionate. Have your internal publisher imagine that he is in a circulation war with a competing intranet and that he should do whatever it takes to capture and enthrall subscribers. Just tell him to 86 the cigar; he will never get that approved by HR.
May 28, 2009
I just created an account on a new Department of Energy site called VIBE: Virtual Information Bridge to Energy Efficiency and Renewable Energy. I love the idea. It is a site that provides data on many of the various energy issues and programs that the National Renewable Energy Laboratory (NREL) is working on. The site is even powered by renewable energy!
Another aspect of the site is that it is running on the Java portal platform Liferay. While Liferay is definitely a mature and sophisticated platform, I wonder if using a portal was a good choice for this site. Like many portal-based sites, VIBE does a good job of putting lots of information on one page but struggles when it comes to navigating and organizing content. While there is no shortage of menu items on the VIBE site, many of the pages are empty containers waiting for portlets. If this was a regular content driven site, the navigation could be built up as content was added to the site. I wonder why they just didn't build the site on a more general web application framework.
This experience reminded me of the narrow range of applications that need a true (as in JSR 168 and 286) portal platform. When a business owner asks for a "portal" that presents lots of information from various sources, it doesn't mean that a developer should go and start downloading a portal product. In fact, I would go further to say that unless users need to select their own portal themes and choose portlets on their pages, you should not us a portal product. The reason why I emphasized the word "need" is that most users will not take the time to customize their own portal page. I had the ability to create my own personalized page on VIBE but I didn't want to bother.
I am seeing a general trend of companies replacing portal-based delivery tiers with simpler technologies. One such example is the Jahia web content management platform. They used to be based on Jetspeed 2. Now they just use the Pluto portlet container that allows them to incorporate components that have been implemented as portlets. One of my newspaper clients replaced their portal based delivery tier for a simple, easier to manage JSP based architecture.
Getting back to VIBE, I think their best portal strategy would be to not build a portal but rather provide Google and Facebook gadgets that people can use on the sites that they go to frequently. If a visitor takes any time to customize any portal page, it will probably not be their VIBE page. The bottom line is that due to their aggregating nature, the world actually needs only a few consumer facing portals. Far better to focus on producing great information and making it available on the portals that people are already using.
May 01, 2009
In my technology consulting engagements the first step is to verify that there is some sort of web strategy in place that will help prioritize requirements and define budgetary constraints. If it is not clear how the website(s) fits in with the client's overall business objectives, how are they to determine what capabilities they should be looking for and how much investment they can justify? Stating that the website needs to be more attractive is not enough. You need to know what business activities the websites should support and how. Usually my clients have done most of this work before hiring me, but, when they don't, I need to scramble a bit to help establish enough of a strategy to move forward
The next time I am in a situation where remedial web strategy work is needed, I will insist that the client purchase, read, and apply J. Boye's new report Best Practices for Creating a Web Strategy. In writing the report, Dorthe Jesperson and Peter Nissen interviewed 19 organizations across several industry verticals including manufacturing, healthcare, and government. They also draw on experience from years of working with J. Boye community of practices. The result is a critical resource for developing a successful web strategy — one that attracts budget for critical activities and gives grounds to reject requests that do not align with the company goals.
If you find yourself grappling with these issues, I strongly recommend that you purchase Best Practices for Creating a Web Strategy.
Apr 28, 2009
I often tell my clients that every website needs a "product manager." This is the person who ensures that the website is meeting the needs of the customers (the audience). A product manager understands the customer and prioritizes the enhancements of the technical platform as well as the production and maintenance of the content. The product manager may not have deep technical experience in software architecture, information architecture, writing, or graphic design but needs to bring these disciplines together to create a product that is useful.
I have recently come across two very good articles on product management. The first is Program Manager by Joel Spolsky. He calls the role a "program manager" and narrowly focuses on the discipline of software development. His program manager leads a small team of developers to build an application (or a subset of a large application) by writing a functional specification that defines the product's vision and behavior. The article nicely describes how the product manager communicates with and manages a technical staff.
The second article is Internal CMS Product Management by David Hobbs. In his article, David focuses on the web content management system as the product and the users of that system as the customers. This role is particularly visible during the initial CMS implementation but is important throughout the system's lifetime to keep it relevant and useful. Requirements always change — not just when the business changes but also when it learns and learning is inevitable with a disruption like a new CMS that may streamline processes and create opportunities. People change too and they may need different training and/or encouragement as their responsibilities change. Too many content management systems fail from post deployment neglect. Always budget for continuing maintenance and enhancement of the system. Practicing the advice in Hobbs's article will help you avoid those pitfalls.
But, as I mentioned earlier, I think that the real product is the web site itself — not the content management system. A great CMS is worthless with bad content. We manage content because it is (or should be) valuable to an audience. A CMS doesn't make good content, people make good content. The best a CMS can do is eliminate some of the barriers that prevent users from making good content. There are plenty of other barriers that the CMS can't eliminate: no time, no interest, no incentives, no skills, etc. The product manager needs to address these as well.
I don't think that I am asking too much for a product manager to guide the technology and help content producers create good, well organized content. Wikis are a good example to look to. Wikis that continue to be successful after their novelty wears off usually have an evangelist that is constantly tracking content updates and giving feedback to authors (Is this page redundant? Does the title make sense? Is the information still accurate? Is it findable?). When you really think about it, this is the role of an editor in a media and publishing company. Maybe all companies that manage content (even for internal purposes) should think of themselves as publishers and have editors that push their contributors to produce a worthy product.
Apr 24, 2009
The Web Content Conference in Chicago (June 15-16) is running a special promotion of $100 off the regular registration price. I have spoken at this conference twice and consider it a hidden gem in the content management conference scene. The atmosphere is non-commercial and down to earth, the speakers are exceptional, and the audience is knowledgeable and engaged. If you can get to Chicago this summer and you want to learn about ways to leverage web content, attending this conference is an obvious choice.
Apr 21, 2009
Note: because this report no longer covers the current version of Drupal, it is available for free on Scribd: Drupal for Publishers
Florence, MA (April 21, 2009) -- Content Here is pleased to announce the availability of a new report. Drupal for Publishers, is the first of a new report series called Web Technologies for Publishers. Written for a cross-functional technology selection committee, each report evaluates a technology against the specific requirements of a newspaper, magazine, or broadcast news website. All Content Here reports are written with the customer in mind — distilling a wealth of information from a wide range of sources into a concise, easy to read narrative. Drupal for Publishers has case studies describing Drupal implementations at Fast Company, Lifetime TV, Morris Publishing, Now Public, and The Onion.
The 24 page report is broken down into sections that explain what the different stakeholders (the publisher, the editor, and the developer) need to know about Drupal. The publisher's section contains information about the time to market, availability of talent, cost, and the future of Drupal. the editor's section covers functional aspects such as content entry, workflow, editorial control and general usability. The developer's section discusses extensibility, security, performance, and developer resources.
Drupal for Publishers is priced at $100 for a workgroup license and can be purchased from the Content Here reports store.
About Content Here: Content Here provides professional services and analysis of content technologies, with a deep technology focus. Drawing on real-world implementation experience, Content Here analysts evaluate software from an implementer's point of view to provide technology decision makers with information assets needed to achieve success, save money, and reduce risk.
CONTACT:
Seth Gottlieb, Content Here
Tel: 857.488.4386
E-Mail: info@contenthere.net
