Curated content for content, computing, and digital experience professionsals

Day: March 25, 2009

Happy Birthday to the Wiki!

The first wiki, WikiWikiWeb, was created 14 years ago today, by Ward Cunningham. Since then, the wiki has become one of the most widely deployed collaboration tools available. One might even call the wiki the catalyst of the Social Software movement.

Why is the wiki so popular? There are several reasons, including ease of use, structured navigation, and the ability to track changes to wiki pages and roll back to previous versions. The democratic nature of the format, in which anyone who has access can edit the wiki, is undoubtedly a major contributor to its success as well.

The primary reason for the wiki’s success is its flexibility. Wikis have been used for everything from collaboratively authoring a document, to managing a project, to establishing a corporate knowledge base. We are seeing the same phenomenon today in Twitter, which is being used in ways that its creators never imagined.

So, at age 14, what has the wiki taught us? That collaboration tools should be designed for flexible, yet intuitive, use. Complexity is kryptonite to collaboration. Let’s remember that before we build and deploy enterprise collaboration software.

Tweeting XBRL

Over the last few months, I have become acquainted with the wonders of the 140 character “tweet”. For those of you who are not “tweets”, I am referring to the combination of instant message and social networking that has converged at www.twitter.com. In essence, twitter asks “peeps” a simple question, What are you doing right now? In 140 spaces, you can communicate what you are thinking or what you have just read on the web.  Long URL’s are easily truncated leaving enough space to communicate simple messages.  If you find people that are doing or reading about interesting things, you can follow their “tweets”.

In efforts to keep up on XBRL, I use Yahoo and Google key word alerts as well as selected RSS feeds from the SEC and others. I have found, however, that this system falls short of the daily updates the people using www.twitter.com are providing for me. Its amazing how effective a 140 character message can be in sending you directly to fresh web content relevant to your interests. To improve my “hit” rate, I’ve added a few Tweet favorite tools such as tweetdeck (www.tweetdeck.com), TwitScoop, WeFollow, and MrTweet. Join up and send me a note. I’d love to follow you!

In The End, it’s Mostly About Content.

As the world of technology makes literally breathtaking strides, the world of automation finds itself increasingly focused on the technology. Indeed, in many areas of popular culture, the technology becomes an end in itself, conferring the patina of success on projects that are techno-heavy, never mind that they may not meet their objectives particularly well. This despite the pronoucements of virtually every management authority since the 60’s that technology and automation are different and the latter is the most important to success of the organization.

Nowhere is the tendency to focus on technology itself, to the detriment of meeting functional goals, more pronounced than in the general area referred to as “conent management” or CM, and in no part of CM has this tendency more clouded the picture than in the relationship of its semantic components; “Content” and “Management.” In today’s CM world, the focus on Management means that software and technology takes center stage with an implicit assumption that if one just adheres to the proper technological dictums and acquires the most powerful CM software, the effort will be successful. When efforts so constructed fail to meet their objectives, the further implicit assumption is that the technology… or the technology selection… or the technology governance… or the technology infrastructure has failed. In many cases while some of these may be true, they are not the reason for the failure.

Often, the cause of failure (or marginal performance) is the other side of the CM terminology; the content being created, managed and delivered.  Look closely at many automation environments and you will see a high-performance management and delivery environment being fed by virtually uncontrolled content raw material. If “you are what you eat”, so too is a content management and information delivery environment. In fact, failure at the delivery end is more often than not a failure to develop usable content instead of a failure of management and delivery technology. So why, with all the tools at our command, do we not address the content creation portions of our information life cycles?

I don’t claim to know all the answers, but have formed some impressions over the years:

FIRST: Content creation and its unwashed masses of authors,  providers and editors has traditionally been viewed as outside the confines of automation planning and development; indeed often as a detriment to automation rather than an integral part of the overall process. With that mentality, the system developers often stay completely away from content creation.

SECOND:  The world of software products and vendors, especially those in the management and delivery space, would rather spend more money on their systems in an attempt to make them resistant to the vagaries of uncontrolled content, of course at higher fees for their products. The world of content creation, if it can be called that, is still controlled by the folks in Renton, to their own corporate and marketing ends.

THIRD:  In most automation projects involving content, the primary resource is the IT group that, while highly capable in many cases, does not understand the world of content over which it does not itself have control. The result is usually a focus on the IT itself while the content creation groups in the organization find themselves outside with their noses pressed against the glass… until they are called in to be told what will be expected of them. The resulting fight often virtually dooms the project as it had originally need conceived.

So what should we do differently?

While every project is unique, here are some thoughts that might help:

FIRST: Understand that technology cannot fully make up for the absence of content designed and structured to meet the functional needs on the table.  Indeed, if it came to a choice between good content and high-performance management resources, content can be delivered with a surprisingly low level of technology while no amount of technology can make up for AWOL content.

SECOND: Accept the premise that well-designed content, fully capable of supporting the functional objectives of the project, should be the first order of business in any major project. With this, acknowledge that the content creators, while they may be less controlled and sometimes not easy to work with, are a critical component in the success of any project based on their output. In many content creation environments, negotiation between what would work best and what can be provided will result in a set of compromises that gets the best possible content within the constraints in place. That done, technology can be applied to optimize the life cycle flow of the content. Note that in this construction, the technology is a secondary factor, supporting but not defining the strategic direction of the project.

THIRD: Despite what you may hear from the software industry and its sales force, understand that in the term “content management”, content is the most important component and just buying more technology will not make up for its lack. From this understanding, you will be able to create a balance that accords both content and technology their rightfully important places in the overall effort.

Regards, Barry

Welcome Neal Hannon

In case you missed yesterday’s announcement, I am happy to announce that Neal Hannon has joined us as Senior Consultant, XBRL Strategies. XBRL has been coming for a while, but with mandatory XBRL reporting requirements now kicking in, companies really need to get serious both with reporting requirements and internal use of XBRL. XBRL requires more than XML expertise, and Neal’s financial background and involvement in XBRL provide deep domain expertise, and are a great complement to our existing XML strengths. Neal will be working with Bill as part of the XML Practice. Neal’s bio is posted at:

Neal’s email is: neal@gilbane.com and his phone extension is 155.

Welcome Neal!