Jun 30, 2009
Alex Manchester, from Step Two Designs has a very useful article on when to publish Intranet content in PDF format rather than HTML. I agree with Alex's point that PDF is suboptimal for most content because of several limitations (most of them around the additional overhead in editing and reading the document) but still has its place: like for documents that are distributed for printing.
Too often PDF serves as a crutch for users with limited web content management tools and skills. For many, it is easier to save a MS Word document as a PDF and upload it than to work with HTML (either through a CMS or using an HTML editor). The real cost of using PDF occurs after the content is published when users have to wait for Acrobat to load only to find that the document is not what they are looking for and when the document needs to be updated but the original Word document has been lost. I think the most painful abuse is the case where the company has a wiki and users upload MS Word and PDF files as attachments rather than edit the content in the pages. Doing this degrades your wiki into a poor man's shared drive — and that is very poor.
Jun 29, 2009
During any CMS selection, it is fairly common to look at software products that span a wide range of prices — everywhere from free to several hundred of thousand dollars in up front licensing. Buyers invariably get confused as they consider vastly different pricing models and try to put those numbers in context of the whole project costs. They struggle to force different products into an "apples to apples" comparison. And, all the while, they are told by the vendors that each solution is the really the cheapest in the long run (bring on the tired free puppy analogies).
Content management software feels worse in this regard than other types of software selections. For one, there is no clear market leader in content management software. This means there is no single company to create a "gold standard" for feature/function/price. Secondly, it is not the case that the large vendors are more stable or offer more features than the mid-market and open source providers. In fact, it has been quite the opposite. The household brand names like Interwoven, Vignette, RedDot have all been in pre-acquisition balance-sheet-beautification mode over the past few years. In other words, they have been minimizing engineering investment and milking their customer base for revenue. Even during the Web 2.0 boom, what little engineering money was spent didn't make its way to web content management. With all of the high profile corporate acquisitions of Interwoven, Vignette, and RedDot, high end buyers didn't get the stability they were looking for either. So, the old adage "you get what you pay for" didn't hold up for the high end web content management marketplace. The middle tier of commercial software vendors have been delivering better products with less risk than the upper tier.
"You get what you pay for" didn't really hold up on the free end of the spectrum either. There are many examples of successful implementations built on top of open source software. These solutions were not entirely free. They cost money to implement and customize and many customers purchase support and maintenance but, then again, all content management software (commercial or open source) requires customization and integration work and maintenance can be 20% of licensing cost. My experience is that open source solutions are generally no harder or time consuming to implement than commercial software solutions (and I have implemented plenty of both). The way to reduce the cost of the entire solution is to minimize your customization/integration work by choosing a platform (commercial or open source) that best matches your requirements. It just may be that the closest match is open source.
When talking my clients through a selection, I am often put on the spot with a question like "what additional features do you get when you go with the more expensive products?" A similar question is "what will we get if we spend more?" These are hard questions to answer because there is no single feature that only appears in higher end products. Usually the best I can do counter with an analogous question "is a Porsche Cayman worth the $23,000 extra in price over a Subaru Impreza WRX?[1]" Both have 265HP engines. Both have many of the same features (radio, air conditioning, speedometer, tachometer, airbags...) but they are very different cars. Obviously some people think the Porsche is worth the extra money. But I can't tell you whether it will be worth it to you because it is a personal feel thing. You get in the car and it feels right. You might even find that you like the less expensive car better because of the arrangement of the controls is more intuitive or the shape of the seats fits your back better. Of course, if you don't have $55,000 for a car, you can save yourself time by not looking at Porsches.
Open source software can be the same way. You might find a particular product whose feature list is very similar to a commercial application you are considering; it has versioning, workflow, a powerful content modeling framework, in-context editing, image manipulation, etc. But these features may have been implemented in a slightly different way — not better or worse, just different; and not because of the licensing model but because two different engineering teams implemented the features. I can't predict which alternative will feel right to the prospective user base. They need to experience the products to make the comparison.
The goal of my selection process is to present products that match my client's stated requirements. To use that car analogy a little more, the cars with the right size engine, the right number of seats, and below a certain price. I also look at industry filters like what is happening with the vendor (I have not recommended Vignette, Interwoven, or RedDot over the last three years because it was pretty obvious the direction they were going). Then I provide some exercises to help the client "test drive" each short listed solution and experience its characteristics and feel. We still do have discussions like "is this CMS worth the extra $100,000?" but only after the client gets a true feel for the differences in the products (and the vendors behind them) and maps these differences to the needs of the organization.
Notes
- I dislike car analogies but nobody seems to know very much about bicycles.
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.
