Jan 13, 2012
If you read Content Here through RSS or just follow links to individual articles, you may have missed my new publications page. In addition to listing some articles that I have published on other sites, the publications page now includes reports that I used to sell here at Content Here. I have not kept these reports up to date with the technologies that they cover but the background information and selection strategies are still very relevant. They are posted up on Scribd where they are free to read. You may find the following reports particularly interesting.
-
This was Content Here's first report. It reviewed 7 open source Java web content management systems (Alfresco, Apache Lenya, Daisy, Hippo, Jahia, Magnolia, and OpenCms). While the individual product reviews are all out of date, the first 20 pages of the 173 page report contain useful information on the rise of open source content management and how evaluating open source platforms is different from commercial platforms
-
This is the Alfresco review from Open Source Web Content Management in Java but updated to version 3.1 which was released in April of 2009.
-
This is my most recent report. It was published in 2009 and covers Drupal 6.10. The interesting thing about this format is that it reviewed Drupal from the perspective of a publisher. The report is broken up into 3 sections: "what the publisher needs to know," "what the editor needs to know," and "what the developer needs to know." I think that much of the general commentary is still very relevant.
Jan 10, 2012
I have been doing a lot of work in digital asset management (DAM) over the past several months. One thing that strikes me about digital asset management software is that a majority of the market focuses on solving the problem of organizing and finding digital assets rather than the problem of producing assets. This is understandable. After all, digital assets (like images, videos, and audio recordings) pose a real problem for organizations. Digital assets are bulky (take a lot of storage), hard to find (at least without metadata), and expensive to produce (you need software, skills, and most importantly, taste to develop these things). Without a digital asset management system, these valuable assets get lost in a chaos of local and shared folder structures with no identifiers other than arbitrarily assigned file names.
The promise of alleviating the pain of losing and duplicating digital assets is compelling and has driven growth in the DAM segment of content technologies. DAM also nicely complements Web Content Management (WCM) because digital assets are so often used in web publishing. In fact, you see lots of WCM platforms integrating with DAM software or adding light DAM capabilities (basically a folder structure of assets with searchable metadata) to their solutions.
But what of the other side of management? The DAM market is considerably weaker in solving the problem of managing the production of digital assets. Products that were designed as digital libraries typically lack robust functionality for workflow, versioning, and managing the raw materials that are required to generate digital assets (filters, fonts, effects, etc.). This type of functionality is critical for large marketing departments within global organizations that are constantly producing, localizing, and publishing digital assets such as videos, images, banner ads, and flash movies. This was the business problem I was trying to solve.
After some research, I found two products that excel in managing digital asset production: ADAM and Vyre (I am looking forward to seeing Vyre's new Creative Workflow product). I shied away from Documentum for other reasons. Adobe CQ DAM probably has the most promise for digital asset production because of its upcoming integration with the market-dominating Creative Suite (Bridge and Drive in particular). That said, when you buy CQ DAM today, you are getting more of a platform than a DAM application. The "Press Center" application, which Adobe demos as its DAM, is essentially a website (built on CQ WCM) for browsing digital assets. The building blocks for digital asset production (versioning, workflows, triggers, etc.) are all there, but it takes a lot of services work to build a digital asset production management system. Look for some changes in the upcoming 5.5 release.
Another interesting technology in this area is Saepio MarketPort. The best way to describe MarketPort is that it is like those websites that allow you to build your own greeting card, photo-book, T-Shirt, or mug. You select a template and then input text and images to fill the placeholders. But instead of creating a T-Shirt or mug, you are creating a marketing asset like a flyer or banner advertisement. This is great for franchise or distributed companies that want to empower their subsidiaries with self-service creation of marketing assets. But it is very different from the creative workflow that I was discussing earlier.
There is also a category of software called Marketing Resource Management (MRM) but I found that market to be fragmented and poorly defined. The products that claim to be part of the MRM segment do very different things. Some focus on planning and reporting. Others focus on project management. The content repository functionality in these products tends to be on the weak side. Plus, they tend to require large amounts of implementation work to deploy.
The DAM (and MRM) market is broad and can be confusing. The good news is that if you are just looking for a system that will centralize the storage of digital assets and allow users to easily organize, find, re-use, and repurpose existing assets, there are a lot of viable options. You can focus your selection on aspects such as usability and price. But if you are looking for a platform to coordinate a large team of digital asset producers, the market gets a lot thinner. When evaluating DAM products, make sure that you know what scenarios you are trying to support. Demonstrations of search, renditioning, and cropping are compelling; but do they do not fully address the needs of a large, specialized production team.
Jan 03, 2012
Happy New Year!
2012 is going to be a big year for me. Starting in January, I will be a full time employee of a new business unit of Lionbridge called Global Marketing Operations (GMO). The best way to describe GMO is that it is a service that helps global companies execute their global content strategy. We take great content that marketers and designers produce and make it available to the intended audiences. This includes:
-
preparing and instrumenting content for publication in the customer’s content delivery systems (web content management, email campaign management, advertising, etc.)
-
Operating those delivery systems.
-
Localizing (translating and adapting) content for local markets.
-
Helping customers understand the effectiveness of their marketing campaigns.
GMO becomes the arms and legs of the marketing organization to close the gap between strategy and results. My new title within Lionbridge will be Global Marketing Operations Solutions Manager. In the near term, I will be optimizing tools and processes to help scale the offering as well as working with GMO clients to help them maximize the value they get from the service.
I have been working in content management for over 15 years. Over that time, I have come to realize that technology is usually not what prevents companies from being successful with content. Yes, better tools increase efficiency. But that doesn’t mean having the right tools will lead to success. In fact, I have been noticing that many compelling CMS features are under-utilized. The capabilities are there; the capable people to use them are not (or they just don’t have the time).
With the emergence of content strategy as a main-stream discipline and the pressure on marketers to show quantitative results, this execution gap will only widen and become more visible. And that’s why this opportunity with Lionbridge GMO is so exciting to me. This is where I can have the most impact in helping companies be more successful with content.
In practical terms, some things are going to change and others will stay the same.
First, the changes....
-
I will no longer be accepting consulting projects through Content Here. Lionbridge offers a Global Digital Benchmark and I will lead the internal component of that offering. I will also consult with GMO clients and prospects to evaluate their tools and processes.
-
I will write and speak more on the operations, process, and analytics of content management.
But these things will stay the same....
-
I will continue to post to this blog and tweet. Some posts will be re-posted on GMO blog.
-
I will continue to track the content management software industry. Lionbridge and its clients need to stay up to date with the latest technology developments that improve efficiency and increase reach.
-
I will continue to be vendor neutral. The success of GMO will depend on being able to help customers regardless of their platform. When it comes to choosing a new platform, Lionbridge is aligned with the customer. We want to choose the most suitable technology because we will be using it.
-
I will continue to attend content management conferences and engage with the content management community. I have great relationships in this community and I think that my work at Lionbridge will provide insights that we all can learn from. I also look forward to connecting my clients to trusted companies and practitioners that provide tools and services that Lionbridge does not offer.
As you can see, I am pretty excited by this new chapter in my career. With that, I will wrap this up by wishing everyone a very happy, productive, and rewarding new year.
Nov 14, 2011
Jack Templin just sent me this excellent article called How to be the 10X programmer. A 10X programmer is a single person who has the effectiveness of 10 programmers. While this at first sounds like an impossible or at least unsustainable model of one super hero doing more work than a team, it is reasonable when you think of one person having the effect of increasing the productivity of everyone around him. That is, the productivity increase is not limited to his/her own output. Here is the kernel of the argument.
The 10X programmer is hypersensitive to problems. Solving a problem that costs other programmers a minute of waiting will gain a lot more than a minute for any programmer who then encounters that problem later. This is because of flow).
...
Importantly, the 10X programmer fixes the problems that knock her out of flow. Fixing problems - even "trivial ones - , leaving documentation so people can understand faster, keeping a database of common problems, and so forth, all potentially make a much larger difference because of flow than just a few minutes it takes to fix them.
I feel like I have worked around people like this and have had fleeting episodes when I have added that value. The true challenge is that the 10X programmer quickly becomes a bottleneck because he/she is the pivot point through which many decisions get made. The temptation to fill up his/her time with meetings is too great. Also, there is the question of compensation. Can the employer really afford to pay these programmers what they are truly worth?
What is probably more realistic is to establish a culture where everyone on the team thinks like this. I love the Pragmatic Programmer books because they help inspire you to do great work that makes you and your peers more productive. Maybe you don't get a full team of 10X programmers but a team of 5X programmers is nothing to complain about.
Nov 10, 2011
Robert Cringely has an interesting article predicting the return of Java as a core language for the web: The second coming of Java. The flow of his argument is that Java is much faster than interpreted languages (such as Ruby, PHP, and Python) but performance hasn't mattered because the primary bottleneck has been disk I/O. Without the practical performance downside, Ruby, Python, and PHP have been attractive because of their easy learning curves.
The game changer, according to Cringely is that the disk i/o problem is getting solved with technologies like solid state drives. To qoute:
Yeah, but there’s a problem looming for Ruby and Rails (Python, Groovy, etc.) and it is that web frameworks based on interpreted, dynamic languages only exist at all because disks are just so damned slow. What happens to these frameworks when disks get faster or disappear entirely?
Interesting argument. But I think that in order to bring back the real appeal, Java frameworks need to start practicing some of the philosophies that the newer web frameworks embrace (like convention over configuration). Java developers need to get more pragmatic and stop building Hammer Factory Factory Factories.
Personally, I think the big thing is going to be newer JVM languages (like Scala). That is, if Oracle doesn't get too greedy.
Sep 28, 2011
A couple of days ago I posted how "going social" will be difficult for most companies. Then, what do you know, I get a real-life example. Just now, I saw this tweet from Bonnie Smalley, A.K.A. Bonniezilla, formerly the voice of "Comcast Cares".
Last week she was saying:
"Dear Comcast: Thanks for dropping my prescription coverage. That was real nice of you."
If you don't remember Bonnie, she was the one who responded to you on Twitter when you were complaining about Comcast service. Now a guy named Bill Gerth has the job. Before Bonnie, there was Frank Eliason. Comcast Cares (whether it is Frank or Bonnie or Bill) cannot do much about any issues but it puts a human face on the company and probably defuses some frustration. The Comcast Cares crew seems genuinely concerned about the trouble you are experiencing. I think that Comcast was a pioneer in this area.
I don't pretend to know the details of what is happening between Bonnie and her former employer. But I do know this: something happened to turn the former spokesperson into just another customer who sees Comcast as a lifeless corporate entity. The very opposite of what the Comcast Cares program is trying to achieve.
Ironic isn't it
Sep 26, 2011
Thank you Deb Lavoy for writing that Social Business blog that I have been meaning to write (Social Business Doesn't Mean What You Think It Does, Neither Does Enterprise 2.0). Procrastination pays! Deb did a better job than I could have done explaining that social business goes deeper than what we call "culture" as defined by the "corporate values" poster that you would see in a lunch area. You need to go below this surface culture right down to core attitudes about people and business.
Anything social is about people and their connections. To be authentic in social business, your business has revolve around people. You can't fake it. You can't talk about people as "resources" and then turn around expect them to feel like they are members of a community. Treat someone like a resource and he will behave like a resource. He will not invest his personal identity to advocate for an organization. He will save his personality and creativity for whatever community treats him like a person. That may include friendships he has formed at work but not to the organization itself.
The difference between my imaginary article and Deb's real one is a slight change in emphasis. I don't think Social Business will transform all companies. I don't think it is possible to run every business like a social business (although I would like to see every business try). The companies that don't go social will not necessarily just shrivel up and die. However, if one of their direct competitors makes the leap they will be operating at a distinct disadvantage.
Any business that has wide disparity in pay and privilege will have a hard time becoming a social business. People at the top who prosper from the exploitation of the bottom become a faces of the company that are easy to resent. Aggressive management that drives performance through reward/fear (the "coffee is for closers" culture) is an obstacle to social business; so are rigid roles and repetitive tasks that stifle individual expression. Anything that makes employees grumble to their peers after work will inhibit social business success. What people say over beers is what they will want say if you try to make them social. If you are frustrated by their silence. Consider that they are just being polite: "if you don't have anything nice to say, don't say it."
Does every business need these anti-social practices? I don't know; but the ones that do have them think they need them. Remember the testimonies defending executive pay during the financial crisis hearings? As managers, haven't we all experienced passing down pressure received from above? Anti-social business behavior is always justified by a need to be competitive and survive. If the customers only care about price (and not service, innovation, and connection) and the owners only care about growth and profits (like investors and shareholders do), the necessity of anti-social business behavior might be difficult to argue with. But if the company operates in an industry that values the human element of business (as in what humans can offer: ideas, problem solving, listening, trust, relationships, etc.), long-range competitiveness may depend on the ability to transform into a social business.
Sep 20, 2011
When building websites, I always recommend developing the home page last because the purpose of the homepage is to highlight content within the site. You need build out the site so you have something to highlight before you build the homepage. Over the past year, I have started to realize that the same advice holds true for design. In fact, I now feel even stronger about that rule for design. Here are four reasons why.
-
A homepage wireframe doesn't tell a whole lot.
Wireframes are helpful to express content structure and site functionality. When I look at a wireframe, I see a content model (what elements make up a particular type of content) and features (how the visitor interacts with the content — commenting, voting, sharing, related links, etc.). The home page is more of a summary. You don't see that level of detail. The things that matter to a homepage (branding elements like font, imagery and palette) are not even captured in a wireframe. Talk about those things near then end of the project because you can make sweeping visual changes by editing a few lines of a style sheet.
-
The biggest functionality decisions are in the inner pages of the site.
Although you may think you have scoped the project during your requirements phase, the devil is in the details. How the functionality works will have huge implications on project cost. The sooner you have those conversations, the sooner you will be able to adjust budget and scope so you can spend resources cost-effectively. Leave those decisions to the end and everyone gets surprised ... in a bad way.
-
Internal audiences care more about the home page than external audiences do
Let's face it, if your site is like most sites, most of your traffic is coming from search engines and link sharing (Twitter, Facebook, etc.). If you have something worthy of your audience's attention, Google is going to know about it and take your visitors directly there. The homepage doesn't do much more than give a visitor something to look at when he doesn't know where to go. The homepage is more about corporate vanity than serving audiences.
-
It is easy to get bogged down in political issues that have nothing to do with the functionality of the site.
While there is very little functional substance on the homepage, that doesn't mean people can't argue about it. If the homepage is treated as a symbol for what is important to an organization (which it often is), a design session will quickly degrade into a turf battle. Your designer will try to mediate, but there is no way he will be able to settle such a fundamental argument. Don't waste time arguing in the beginning of the project when there is so much productive work to be done.
Unfortunately, I regularly meet resistance from designers who habitually begin with the homepage. I understand the temptation. On the surface, a homepage wireframe seems easy and uncontroversial. It is just a bunch of blocks on the page that stakeholders can privately fill with their imagination; there are no assertions on how major site features behave. But, from a technical design perspective, we don't learn anything from the homepage wireframe. We can't start thinking about content structure and end-user functionality that will have major implications in scope and planning. The longer we delay that work, the greater project risk.
Sep 14, 2011
Tom Wentworth, from Ektron, has written an inspirational article on Forbes called "http://www.forbes.com/sites/ciocentral/2011/08/30/context-will-drive-the-future-of-web-content-management/". The article describes a very legitimate strategy for achieving a goal that CMS customers all want: serving their audiences with the right content, at the right time, and in the right format. The strategy, which uses visitor context (location and device) to infer intent and other preferences, is something that a CMS can help with. Content management systems have been introducing increasingly sophisticated profiling and presentation functionality to implement elaborate display logic. Content management systems have always been able to capture the metadata and other configuration that drives this logic.
The right CMS will give you the capability. But that is only part (and a really small one) of what is needed to be successful in this strategy. The bigger, harder part is designing, implementing, and testing the rules behind this logic. How would you treat a visitor differently if you knew his context? The fact is that you still don't know the visitor and what he wants. Context may give you a clue or a hint, but you can't be sure. You can only make assumptions and these assumptions may be very wrong.
These assumptions are like any stereotype. Sometimes they are accurate and you look like you have some kind of sixth sense. But when they are wrong, you better be prepared for damage control because you can look like an idiot and frustrate people. Success with a context-based strategy, or any other personalization depends on 1) knowing the likelihood of being wrong, 2) knowing when you were actually wrong, and 3) recovering from a mistake.
Let's take these elements in a concrete example. Let's say you work for a movie theater company and have a theory that the mobile visitors to your website only want to see showtimes and directions. One of your customers sees a help wanted sign at one of the theaters with a link for information on how to apply. This young applicant's only computer is a smart phone (an increasingly common phenomenon). He goes to the website and is redirected to a mini-site that only has show times and directions. He can't get to the desktop version of the site with job information. You just lost a job applicant and embarrassed yourself.
Running through the tests.... You might think it was a reasonable assumption to only show certain information to mobile users, but if you were not absolutely sure, you could have put a link to the full site and suppressed the redirect logic. How would you know about this incident? Are you tracking clicks on that "desktop version" link? Was there a place to leave feedback? Or will that incident only be seen as a bounce in your traffic report? If you figured out what happened, what are you going to do about it? Do you have the resources to correct mistaken assumptions and continually improve the behavior of the site(s)?
I really like Tom and what he has done at Ektron since he joined. In particular, Tom has helped focus Ektron and elevate the discussion about serving audiences. Buyers should definitely listen to these ideas but be aware that supporting context-aware visitor experiences adds cost to the initial implementation and ongoing maintenance. There is more logic to test before you launch the new site; but the real effort is after deployment when you have to constantly test and tune the logic as you see it respond to real users. You have to accept that context-driven logic has the potential to worsen visitor experience and be prepared to make corrections. This means having a team with the time and skills to monitor and adjust the logic. If you have access to that talent, you should be able to use context information to help deliver great visitor experiences.
Aug 29, 2011
I just published my CMS Selection Workshop handout on Scribd. The handout contains:
Enjoy!
CMS Selection Handout