When an approver is reviewing a change to a previously approved asset, Hippo CMSdefaults to a version compare view. Adds, changes, and deletes are highlighted by color and strikethrough (see screenshot).
The concept reminds me of source code control system commit emails that highlight changes to code whenever anyone checks anything in (click on screenshot for a larger view). I do a lot of web development team mentorship and I have come to rely commit emails.
They allow me to quickly determine if there are any material changes that I need to dig into and saves me loads of time (in the case of the screenshot example, no important changes have been made). I am wondering if the Hippo implementation adds excerpts of changes in their workflow notification emails. That would be convenient.
I really like the Hippo team's pragmatic approach to enhancing Hippo CMS. Rather than adding lots of a new "checklist" features (that make the product more complicated), they tend to focus on refining and streamlining functionality that customers probably already use. It is that "make it suck less" philosophy that makes software continuously better for the users but tends not to get recognized by most analysts and buyers.
There is a great Reddit thread on The Onion's migration from Drupal to Django.The Onion was one of the companies that I interviewed for the Drupal for Publishers report. One of the things I mention in the report is that The Onion was running on an early version (4.7) of Drupal. The Onion was one of the first high traffic sites to adopt Drupal and the team had to hack the Drupal core to achieve the scalability that they needed. While versions 5 and 6 of Drupal made substantial performance improvements, The Onion's version was too far forked to cleanly upgrade.
Still, The Onion benefited greatly from using Drupal. They were able to minimize up-front costs by leveraging Drupal's native functionality and adapt the solution as their needs changed. Scalability was a challenge but it was a manageable one. Even though forking the code base was not ideal, it was a better alternative than running into a brick wall and having to migrate under duress. The Drupal community also benefited from the exposure and learning that came from The Onion using Drupal. Everybody won &mdash how often can you say that?
I can understand the choice of Django 1.1 (current) over a hacked version of Drupal 4.7. Having built sites in both Drupal and Django, I can also see the appeal of using a Django over Drupal 6.16 (current). Django is a more programming-oriented framework and The Onion has programmers. Django is designed to be as straightforward and "Pythonic" as possible. Drupal tries to make it possible to get things done without writing any code at all; and if you can avoid writing code in Drupal, you should. As a programming framework, Drupal has more indirection and asserts more control over the developer. The Onion's staff of programmers clearly appreciate the programmatic control that Django affords and they are quite happy with their decision.
After hearing all this news about status.net, I took a few moments to connect my Identi.ca account with my Twitter account. I am not at all sure what good that did but I figured it couldn't hurt. While I was there, I got to thinking what is so special about a microblog? And I came to the conclusion — nothing. You can think of a microblog as a title-only blog (entries with no bodies). What is new there? Subscriptions have already been handled quite well by RSS. What makes Twitter (and Facebook) so important is not the ability to post 140 character messages. It's not even really the API or mobile integration. What makes Twitter/Facebook important is that they are used by so many of the people that you want to reach. There are plenty of failed status-oriented services that have had the technology but, either through bad timing or other missteps, failed to build an audience.
I wonder how attempts at internal microblogs are working out. I haven't heard any success stories and I doubt if any survive past the initial novelty phase. If there are urges to microblog within the enterprise, employees could satisfy them with the internal blogging infrastructure that has been idle in most organizations. If there is any internal application for the microblog it is aggregating what employees are tweeting out on Twitter. But, depending on the staff, I don't know how interesting that would be either.
I think that the microblog is going to fail as a category of software. There just isn't a big enough market of buyers that can build a sustainable microblogging community. I can't think of existing sites with large audiences investing to buy or build a microblogging capability. If you were CNN, would you rather have a reader tweet a story link on Twitter (where it could be re-tweeted by millions of users) or on your CNN own microblog community? The only purpose I see for status.net is just in case Twitter kills itself (by running out of money or ruining the service). I seem to remember a lot of people threatening to defect to Identi.ca and FriendFeed when Twitter was going through its problems. But that didn't happen. How long can the status.net's and Identi.ca's of the world sustain the energy and motivation to be an understudy behind a healthy actor?
I know the argument that suggests that distributed communication services will eventually win like how the open, distributed web was destined to eventually beat out then popular online services like AOL, Compuserve, and Prodigy. But I don't think this is the same. If I am missing the point here, please enlighten me. I would love to see competition in this sector if it makes sense. I just don't see it.
The other day I was trying to describe to a client how content management systems are different. My audience was not familiar with some of the core features of a CMS so my examples were too abstract to get my points across. However, they were familiar with Microsoft Office so I used that as an analogy. They found it quite useful so I thought I would repeat it here.
The Microsoft Office Analogy of Web Content Management Systems
Imagine your boss wants you to "put down a few thoughts" on a topic to share electronically with a group. You might choose to create a Word document, a PowerPoint presentation, an Excel work book, or maybe even an Outlook email message and then start typing out a list. Because you just want to capture some ideas and your boss was so vague about the format, it doesn't really matter what you choose. Your boss asked for ideas, not a deliverable. Let's say you choose PowerPoint because you have a nice looking master template and you figure a few bullet points would look nice in big text on one slide. It doesn't hurt that you are really comfortable with using PowerPoint.
So you show your boss the PowerPoint deck and he wants you to elaborate more. You have used terms that need to be defined and he wants you to support your points with some background information. This "few thoughts" is starting to sound like a memo or a report. Now PowerPoint is not looking so good. What do you do? You can start to overload PowerPoint's features to make it work like a word processor; or bail out and copy/paste everything into Microsoft Word. You will probably make this decision based on how familiar you are with PowerPoint vs. Word, how particular your boss is going to be about the format, and how long this document will live. If you make the wrong decision, fighting the technology will start to dominate the time you spend on this project. Every change will risk blowing up the whole document.
Strengths and Weaknesses
Like all analogies, this had its strengths and weaknesses:
Analogy Strengths
Many companies choose a CMS for arbitrary reasons without really understanding their requirements. When requirements are vague (like "we just want a simple website"), all options look equally viable.
Stakeholders often have tacit but very specific requirements. e.g. "I will know it when I see it."
If you really know a technology, you can force it on a problem by overloading features and redefining the problem. For example, while the MS Word user sees a bunch of paragraphs, the PowerPoint user sees a series of vertically arranged left-aligned text boxes. However, eventually these solutions tend to become unstable, especially if they need to get supported by different people.
You need to know when to swap tools. If you do it too late, you waste too much time misusing the old technology and you have more content to move over.
Analogy Weaknesses
My client immediately wanted to know which CMSs were like Word and which CMSs were like PowerPoint. You don't want to go too far with this analogy because a CMS is more than a document editor.
The switching costs from one CMS to another is much much greater that from one document format to another. If this was a CMS implementation, you want to ask your boss to clarify where this project is going before you pick your tool.
While not perfect, I think this analogy did its job of making people think about CMS selection in terms that they can relate to. They can now visualize themselves misusing the wrong tool to get the results they want and living in constant fear that one more hack is going to bring the whole site down. They are now thinking about their website in terms of a development roadmap that will be influenced by different stakeholders over time. They can relate to how people have a difficult time expressing requirements that they know tacitly and can apply familiar skills to get clarification. As long as I can keep them from over identifying the website with a MS Office document, I think I am going to be OK.
is a useful book of how to use your computer more efficiently. One of the several tips that I have adopted is to use one text editor (in my case, TextMate) for all text oriented work. The idea behind this is that when you work in one tool, you get to know it really well and can take advantage of all its nifty time saving features. Most software users, however, only use a tiny fraction of the useful features supported by the software.
I had gradually been moving in this direction for a while. At first, I just used a text editor to program in dynamic languages (Javascript, Python, PHP, Perl, SQL), do HTML/XML markup, and edit large data files. About 6 months ago, I got so fed up with Eclipse's clunkiness that I started to write Java in TextMate. Since reading the chapter in the book, though, I have started to use TextMate as a blogging tool. This was a big step for me because I was quite happy with Red Sweater's MarsEdit software. Yes I know that MarsEdit gives you the option to edit posts in TextMate but I decided to go all in. I have not yet been able to get TextMate hooked up as my email editor. I always thought programmers that did everything in EMACS were silly. But since making the change, I have found a lot of powerful keyboard shortcuts and macros. My one hold-out is that I still use Oxygen for editing my DocBook documents.
My successful experience caused me to question whether there was any merit to the "One CMS to rule them all" ECM (Enterprise Content Management) vision that I have been battling over the past 7 years (a battle that I won, by the way, but I am not gloating). Would there be any benefit of having a knowledge worker getting to be a true expert in one tool? Then I came to senses and realized two key differences:
Web Content Management is about managing semi-structured data, Enterprise Content Management is about managing metadata. A WCMS primarily helps a user edit and and assemble reusable, structured content. In a document-oriented ECM system, most of the documents are binary files that are edited using tools like MS Word. These ECM systems are used primarily for creating metadata, organizing, and managing permissions. Furthermore, most people organize their documents on a file system metaphor. Web content organization tends to be much more fluid and rule based. Your website is not a file system. You will fail at web content management if you think that a website is a bunch of MS Word documents saved as HTML. Because there is so little functional overlap, one tool doesn't make sense.
CMS users don't define them selves as CMS users. Programmers, at least the good ones, care about their craft and take pride in how they work. They read books and blogs to continually hone their skills. They love their tools and treasure knowledge of obscure little tricks. Good designers tend to be the same way. Your average content contributor may be similarly inspired about their profession, but if they are, they don't usually consider using a computer program as part of that quest. For them the computer software is a necessary evil. They are looking for intuitive tools that require no learning. They tend not to invest the time to achieve expertise. If I were to equate using a computer to driving a car, the average computer user drives around in 1st gear or reverse all day long. They discover a way to get the car to move and then leave it at that.
There is a direct relationship between specialization and intuitiveness of software. When the software designer knows exactly what the user will use the software for, he can be very explicit in the user interface. For example, when creating a blogging tool, the software designer can put in a big button that says "CREATE BLOG ENTRY." A designer of a more generalized, multi-functional tool requires more compromise and negotiation with the user. The user needs to learn how to access lots of basic capabilities and string them together to get the result that he wants. Just look at the UNIX command line and piping together commands. TextMate is a little of both, the designer of TextMate knows that the user is going to want to enter text and save files. That is why the program opens with a big area to type in. But the designer doesn't know whether the user will be wanting to post this block of text to a blog or compile the text into executable software or hundreds of other options. This is why those functions need to be buried under cryptic key sequences like "control-command-p" (that's post to blog) or "command-r" (that is compile and run). If a CMS was written for someone that wanted to be a CMS expert, it would probably look something like a command line Sabre terminal. And this is why all purpose tools fail for content managers.
Chief Google Economist, Hal Varian, has an interesting post about online and offline newspaper economics on the Google Public Policy blog. Most of the ideas will be familiar if you read Clay Shirky: cross-subsidization of the news; specialized sites drawing away ad revenue; relative cost of production.
One point that I have been hearing less about was that online news consumption tends to be mostly from work while offline newspapers are read at home on leisure time. In itself, this is not a huge insight; all of my news clients know that they get most of their traffic during the workday. What I had not thought about was that reading time at work is significantly more compressed than at home. The article gives statistics of 70 seconds per day online vs. 25 minutes offline — and advertisers pay for a premium for that longer attention span. The article predicts some good news for newspaper publishers: tablets (like the iPad) and other mobile devices (like the Kindle) will increase the at home consumption of the news and lengthen time spent reading. This should even out the disparity between online and offline advertising revenue. I think the accuracy of this prediction will depend on a) whether advertising formats can effectively adapt to and leverage the strengths of mobile devices and b) the advertisers opinion of the value of online advertising changes. As for the latter, advertisers seem to illogically value the immeasurable benefit of print advertising over the more measurable benefit of online advertising. That is, they probably assume print advertising is more effective than it actually is because there are no statistics to limit the perceived value. There are some great posts about how online advertising is undervalued.. Until this attitude changes, it will be difficult for newspapers to burn their boats.
Recently it occurred to me that video and (to some extent audio) has become a less important requirement for most of my web content management clients these days. If I were to extrapolate the interest trend I was seeing back in 2004, I would expect to see the web resemble billions of tiny television stations. But that hasn't happened. While video and audio remain important for companies in the business of developing and/or distributing multi-media content (primarily for entertainment), multi-media has not achieved ubiquity as a medium for communication. Instead, the focus is still heavily weighted towards text and images. There are some obvious explanations for this trend. Services like YouTube, Vimeo, and BrightCove are taking care of video hosting so my clients don't have to worry about it. Also, companies have realized that, other than the large file sizes, video is just not so special that deserves so much special concern and attention.
But I think that there are larger forces at work. I experience issues with video both as a content consumer and a content management professional. As a content consumer, I don't like how video takes control over my experience of the information. Unlike text, you can't scan video for the little bit information that you want. You have to sit back and wait for the video to get to the point. This is great for entertainment (suspense!) but less so for information exchange. Take, for example, this video (below) where the spokesman just spurts out technical information about a computer. It would be so much better just to have a spec sheet so you could scan right to the part of the specification you want. For a while it seemed like all companies were looking to make their websites more "dynamic" by leveraging multi-media. Customers may have reacted positively at first to the novelty of seeing moving pictures but I think this has played out.
As a content management professional, my issue with video is that it breaks a key principle of content management: the separation between content and format. In video and audio, the information is inseparable from the format. Yes, you can transcode into different encodings and file formats, but reorganizing and editing audio and video is difficult to automate. As a result, video and audio content gets stale and out of date because it is too expensive to change. If you want to change the information, you need to re-produce the whole thing.
There are some things that belong in audio and video, like a recording of some performance or something that you need motion to understand. But in most cases, the production and maintenance effort that multi-media requires introduces an unnecessary barrier between the information source and consumer. This obstacle stands out even more in the social web that tries to blur the line between author and audience. In the social web, video is most successful when it is short, entertaining, and performance-oriented. It is less effective for basic information exchange. The best uses of video I have seen for information exchange is on some news sites where visitors are invited to upload short videos of their eye-witness account. In these cases, the video needs to be authentic (no need to edit!) and shows something that cannot be captured in text and still images. But information about that event is more accessible in plain text.
I am sure that there are people in the video field that have different experiences with the medium. If you have any insights, please leave a comment or send me an email.
The Open Source Way is a great resource for developers who want to start their own open source project. It is a wiki of lessons learned and best practices gathered primarily from experiences working on the RedHat and Fedora projects. One page that I find particularly interesting is "How to tell if a FLOSS project is doomed to FAIL." The format assigns "fail points" for common (and uncommonly stupid) mistakes that project leads make. Making a few of these mistakes doesn't doom your project but making lots of them definitely stacks the odds against you.
While it was written from the perspective of a Linux library developer, the list also contains useful information for other types of open source projects. I was hoping to add some content around project leadership but I was discouraged to see that I was not able to create an account or contribute to the discussion page (FAIL!). Here is what I would have added:
There is no road map showing planned improvements to the software
The project leader(s) is(/are) not transparent about decisions [ +5 points of fail ]
There are no guidelines for contributing to the project [ +20 points of fail ]
The project does not have a way to attract and incorporate new contributors [ +10 points of fail ]
The project does not have a system for recognizing/rewarding contributions [ +5 points of fail ]
It just occurred to me that my recent quotes on Fierce Content Management make me sound like the Statler and Waldorf of the content management industry. I really don't mean to sound so negative but, from where I sit, software company acquisitions are nearly always bad news. My clients are software customers and my job is to help them be better software customers by making better technology decisions. Mainstream software analysts, who are mainly speaking to the vendors, spin acquisitions in terms of what it means to competitors. They talk about how the acquisition changes the landscape and competitive dynamics. Mainstream analysts get pretty excited by mergers and acquisitions. It means that there is movement that needs to be understood and explained. It means that they get to re-answer the question that their software vendor and investor customers always ask "who is the best company in the market and why."
The software customer has a different question: "which one of these products is the best for me right now and in the foreseeable future." Market dominance plays a role but customers should be more concerned about their requirements and that the vendor will stick around and continue to focus on what matters to the customer. Customers should care less about who acquired who (today and yesterday) and about more who is at risk of getting acquired tomorrow. Acquisition adds uncertainty and risk that a customer would do best to avoid.
The dirty little secret about software company acquisitions is that, in most cases, they have nothing to do with technology. When one software company buys another, it is usually buying customers. Implicit in the transaction is the understanding that the customers are worth something and the acquiring company __can more effectively make a profit from them__.
An acquired CMS customer is valuable because switching costs are really high. To switch to another product, a customer would need to rebuild its web site, migrate its content, and retrain its people. Unless the product is totally doomed, the customer will probably stick around and pay support and maintenance for a for a while. The acquiring company can increase profitability by cutting down on product development, support, and sales. Most of these cut-backs directly affect the customer. The vision for the product will get cloudy. Enhancements will come out slower. Technical support and professional services will be less knowledgeable. Market-share will gradually decline. In some cases, the product will be totally retired in favor of an alternative offering by the same company. If there is an option of terminating support and maintenance, it is probably a good idea to exercise that option because the value of the service is likely to decline steadily.
The sad thing is that this dynamic is practically built into the traditional software company business model. A typical software company burns through investments to first build a product and then build a customer base. At a certain point, the growth trajectory will flatten (or decline) and investors will want to move their money into another growth opportunity. Some companies will be satisfied by having achieved a sustainable business. Others will cash out by being acquired. Others will look to grow by acquiring steady (but declining) revenue streams. The scariest companies to deal with are the acquiring companies — what I call "portfolio companies" that buy up products for their customers and then decide what to do with the technology. When you are a customer of one of these companies the future of the software you bought is vulnerable to the shifting attention of the vendor. If the vendor decides to keep the product around, it means they can successfully drain revenue from you. If the vendor gives you a "migration plan," it means that they have another product that is in an earlier stage of the same destiny. Neither case is good.
Around thirteen years ago, I helped build a prototype for a custom CRM system that ran on an object database (ObjectStore). The idea isn't quite as crazy as it sounds. The data was extremely hierarchical with parent companies and subsidiaries and divisions and then people assigned to the individual divisions. It was the kind of data model where nearly every query had several recursive joins and there were concerns about performance. Also, the team was really curious about object databases so it was a pretty cool project.
One thing that I learned during that project is that (at least back then) the object database market was doomed. The problem was that when you said "database," people heard "tables of information." When you said "data" people wanted to bring the database administrator (DBA) into the discussion. An object database, which has no tables and was alien to most DBAs, broke those two key assumptions and created an atmosphere of fear, uncertainty and doubt. The DBA, who built a career on SQL, didn't want to be responsible for something unfamiliar. The ObjectStore sales guy told me that he was only successful when the internal object database champion positioned the product as a "permanent object cache" rather than a database. By hiding the word "data," projects were able to fly under the DBA radar.
Fast forward to the present and it feels like the same conflict is happening over NoSQL databases. All the same dynamics seem to be here. Programmers love the idea of breaking out of old-fashioned tables for their non-tabular data. Programmers also like the idea of data that is as distributed as their applications are. Many DBAs are fearful of the technology. Will this marginalize their skills? Will they be on the hook when the thing blows up?
I don't know if NoSQL databases will suffer the same fate as object databases did back in the 90's but the landscape seems to have shifted since then. The biggest change is that DBAs are less powerful than they used to be. It used to be that if you were working on any application that was even remotely related to data, you had to have at least a slice of the DBA's time allocated to your project. Now, unless the application/business is very data centric (like accounting, ERP, CRM, etc.), there may not even be a DBA in the picture. This trend is a result of two innovations. First, is object relational mapping (ORM) technology where schemas and queries are automatically generated based on the code that the programmer writes. With ORM, you work in an object model and the data model follows. This takes the data model out of the DBA's hands. The second innovation is cheap databases. When databases were expensive, they were centrally managed and tightly controlled. To get access to a database, you needed to involve the database group. Now, with free databases, the database becomes just another component in the application. The database group doesn't get involved.
Now that the database is a decision made by the programmer, I think non-relational databases have a better chance of adoption. Writing non-SQL queries to modify data is less daunting for a programmer who is accustomed to working in different programming languages. Still, the programmer needs good tools to browse and modify data because he doesn't want to write code for everything. Successful NoSQL databases will have administration tools. The JCR has the JCR Explorer. CMIS has a cool Adobe Air-based explorer. Both of these cases are repository standards that sit above a (relational or non-relational) database but they were critical for adoption. CouchDB has an administration client called Futon but most of the other NoSQL databases just support an API. You also want to have the data accessible to reporting and business intelligence tools. I think that a proliferation of administration/inspection/reporting tools will be a good signal that NoSQL is taking off.
Another potential advantage is the trend toward distributed applications which breaks the model of having a centralized database service. Oracle spent so much marketing force building up their database as being the centralized information repository to rule the enterprise. In this world of distributed services talking through open APIs, that monolithic image looks primitive. What is more important is minimal latency, fault tolerance, and the ability to scale to very large data sets. A large centralized (and generalized) resource is at a disadvantage along all three of these dimensions. When you start talking about lots of independent databases, the homogeneity of data persistence becomes less of a concern. It's not like you are going to be integrating these services with SQL. If you did, your integration would be very brittle because these agilely-developed services are in a constant state of evolution. You just need to have strong, stable APIs to push and pull data in the necessary formats.
The geeky programmer in me (that loved working on that CRM project) is rooting for NoSQL databases. The recovering DBA in me cringes at the thought of battling data corruption with inferior, unfamiliar tools. In a perfect world, there will be room for both technologies: relational databases for relational data that needs to be centrally managed as an enterprise asset; NoSQL databases for data that doesn't naturally fit into a relational database schema or has volumes that would strain traditional database technology.
