I was catching up on my blog reading and noticed a few announcements about Bluenog's new integrated suite offering ICE. I knew that Bluenog was a preferred US Hippo CMS integrator (before Hippo opened a U.S. office) and it made me wonder if their platform was based on Hippo (despite the fact of not mentioning it). Sure enough, Bluenog CMS is a direct fork of Hippo. Hippo's permissive Apache 2.0 open source license allows this but I think that it is considered standard practice to at least mention where the code came from. While the UI is most clearly Hippo with a simple logo swap, Hippo is mentioned nowhere in the literature. It took some digging to find the list of open software included in the full Bluenog ICE suite. The Bluenog product itself is not open source (license). The only downloads available are the compiled JARs and to get that, I needed to fill out a registration form.
Meanwhile Hippo B.V., makers of Hippo CMS, continues their work on their re-write of Hippo. While the wiki has not seen much change, there seems to be a steady flow of source code commits.
Increasingly, I am finding that clients prefer a slide deck (i.e. MS Powerpoint) as a deliverable rather than a regular document. The reality is that many people don't really read documents and would rather their consultants not waste the time writing words that will not be read. As a consultant, I usually find myself having mixed feelings. On the one hand, I don't like the idea of typing prose into a vacuum (and contribute to the tangle of content that they may have hired me to solve). On the other hand, at the end of the project, I normally have a lot to say and it is difficult to squeeze all this information into a slide deck that can be left behind and stand on its own. The resulting product tends to look like an epic novel is coffee-table book format - or like the slides in this You Tube clip.
Slides were meant to accompany a presentation and the best presenters only use them for visual cues to complement what they say. Slides written in this philosophy leave too much to interpretation without the presenters explanation. When my deliverable is a slide presentation I get around this limitation by packing a lot of explanation in the speakers notes. Recently, I have gone so far as to make foot notes in the slide that reference points I make in the speakers notes. The result is this strange hybrid that I am not quite sure how to characterize. It is essentially a document-like narrative organized around bold themes. People can just browse through the themes and drill into topics that are of interest. However, I suspect that few readers actually do this.
Sites like SlideShare ask slides to stand on their own and, therefore, seem to favor wordy slides. The ones with just pictures leave the reader in the dark imagining what the presentation must have been about. I have felt the compulsion to write presentation slides for a SlideShare reader and wonder if other presenters think this way too. In the extreme, I could see a presentation turn into a group reading of paragraphs of narrative. I hope that it does not come to that.
A few weeks ago Deane Barker from Blend Interactive wrote a thought provoking post about content management as a practice. Deane and I started talking about this idea in June when we were in Chicago for Web Content 2008. I understand why Deane took a few weeks to write up a post. This is a big idea that lots of people have struggled with. To summarize, it is not that hard to build a team of people who understand how to implement a specific platform and translate requirements into configuration and customization of that solution. It is harder to build a team of people who understand the foundational concepts in the abstract (that is, not tied to any vendor's implementation) and know how different implementations perform in different situations. (that is probably an overly brief summary. You should definitely read Deane's post and the follow up comments).
To understand content management at this level you need to experience lots of different products, tease out concepts and patterns, and do a lot of comparative thinking. This is hard to do because it takes a certain kind of curiosity that I find surprisingly rare and certainly expensive to cultivate. Most people stop looking when they see something that works. They find it frustrating and risky to ignore familiar concepts to look at a problem from a fresh perspective. They dread the steep initial incline of a learning curve. They only suffer suffer through in the hope of flatter pitches ahead. Few have an insatiable need to challenge and be challenged. The instant the learning curve starts to level-off, they are looking for another one to run up against. They like the feeling of being dropped into a totally unfamiliar place and finding their way. You can't carry too many (TADD: Technical Attention Deficit Disorder) people like this on staff because nothing gets done the same way twice. To build a successful content management practice (that balances predictability with innovation), you need both types of people. You need some people that are constantly searching and challenging and you need others plowing ahead on well traveled paths. I don't know what that perfect balance is and there are plenty of companies that do very well by picking a repeatable solution and getting very good at efficiently implementing it. You can try to supplement your own exploration by buying research but I feel that most industry analysts don't go deep enough into the solutions to really understand them and have useful things to say. I think most of what you get is some quick (often misguided) observations and some unsupported theories presented as trends.
To take the conversation one step further, I would go on to say that "content management" is too broad and ill-defined to base a discrete consulting practice. "Content" is a squishy term - really no more descriptive than the word "stuff." Every software application manages some kind of data that (depending on the perspective) could be considered "content." Even within the accepted segment of content management, the different disciplines of web content management, digital asset management, digital records management, and document management have so little common ground. Ever sit through a discussion with a DITA evangelist and a marketing communications person whose idea of content is a press release written in Word?
I think the biggest issue is that content management (in of itself) is not a business problem. Media companies need help creating rich content experiences for their audiences. Consulting companies need to improve the way they collaborate to produce and re-use deliverables. Manufacturing companies need to organize and bundle specifications for their products and the supporting end-user documentation. Marketing organizations need a destination to point their various campaigns. All companies need at least a few pages on the web to communicate to the market what they do. Content is just a common thread through these different business problems that it takes different skills and approaches to solve. As content management professionals we should not get so distracted by the fact that there is "content" involved that we lose focus on the business goals that are to be achieved. This is where industry specialization is important. I think it is more important for a consultant to understand best operational practices for a specific industry than generalized practices in content management. There may be commonalities in how technical documentation and news articles are managed but how much does that really matter to the customer who is only concerned with their manuals or publications?
What really hammered point home for me was at a wedding last weekend. I am used to getting blank stares when I say that I "help companies select and leverage content technologies." This time I said "I help media and publishing companies select and leverage technologies to manage the content of their websites." Everyone instantly got it and I had some great conversations with people who either worked in media businesses or were just interested consumers of media. I could have said that "I help select and leverage technologies for e-commerce companies to make their websites more effective selling tools. That is also true. It is OK to specialize in more than one thing (I also work in the high-tech and entertainment industries). The key is to focus on the customer's higher level business objectives, not a set of capabilities that defines a software market segment. Yes, an understanding of workflow as a foundational concept is useful but even more important is to understand the different editorial processes that happen within a news organization.
I think this is a fascinating topic and I hope the discussion continues. Please comment here, on Deane's blog, FriendFeed, Delicious. You name it.
In response to customer and market demand for a detailed analysis of Intranet 2.0 tools (Web 2.0 tools used on the corporate intranet) used, considered and deployed by global organizations, Prescient Digiatl Media is preparing a comprehensive report on the topic, based in part on the findings of the following study. Targeted primarily to organizations that currently have a corporate intranet and/or portal, and are considering and/or have deployed Intranet 2.0 tools.
The following survey takes approximately 10 minutes to complete. Respondents who complete the survey will be eligible to win $400 (a random email address will be drawn from all responses to the survey). All respondents will also receive a full copy of the results at no cost. Please provide your contact information in order to receive the survey results.
Only totals and summary statistics will be published. Your personal information and answers will be held confidential, and will not be shared with any outside partner or company.
Please take 10 minutes to take the Intranet 2.0 Global Survey and you’ll get a copy of the full results including the good, bad and learned lessons.
I am looking forward to seeing the results of this study. From what I have seen personally, employee-oriented communities have failed to sustain the levels of social and collaborative energy that their consumer-oriented inspirations have achieved. I would love to see what the market as a whole is doing.
A few weeks ago I wrote a post introducing two new Mac Subversion clients: Cornerstone and Versions. After the free trials expired I chose Cornerstone and have been pretty happy with it. I tend to use Cornerstone as a file browser when I am working with a straight text editor (like TextMate). From there I can browse around my working copy, open files, and see changes against the most recent from the repository. The user interface is very clean and presents useful information clearly. When I am working in Eclipse, it is hard to resist the convenience of Subclipse.
Interestingly, the main reason why I switched from TextWrangler to TextMate was its project browsing functionality. Now Cornerstone plays that role for me - at least for anything I have in source control, which is everything. However, I have gotten used to TextMate so I think I will stick with it.
For a while, I struggled with Cornerstone's performance. It seemed to consistently hang as it tried to scan the file system for changes. This was resolved by changing a preferences setting: Preferences -> Working Copy -> Refresh Working Copy = "Manually." Now it only checks the working copies when I ask it to (with command-r).
One thing you may notice in the screen shot above is that it shows Cornerstone looking at the source code from my website. A lot of people ask me what web content management system I use. Well, the answer is none. Because my website is so small and I am comfortable with source control, HTML, and FTP, I really don't need one. My website as 13 pages. A web content management system is like a web page factory. You don't build a factory to produce 13 units. Of course, that may change when I hire that flashy marketing executive with the wafer-thin laptop.
I use Transmit as my FTP client. It has a nice little feature called "Drop Send" that allows you to drag a file onto the Transmit icon in your doc (from Cornerstone or your Finder) and it automatically puts it in the right place (thanks for the tip dizzytree). If you want an all-in-one alternative to the TextMate/Transmit/Cornerstone combo, you might try Coda, which seems to do it all like Adobe Dreamweaver (without the WYSIWYG but $300 cheaper). The latest version of Coda (1.5) has a SVN client.
This spring Janus Boye, in conjunction with Welchman Consulting, is launching a new U.S. peer to the Denmark "jboye" conference series. jboye09 will take place in Philadelphia May 5th through May 7th. There is not much on the site yet but you can submit your email address to receive notifications.
Your company has a perfectly good wiki but your (otherwise intelligent) co-workers insist on emailing you Microsoft Word documents to review. Your gentle guidance has been ignored. Your snarky comments have been equally ineffective. What do you do? I suggest the following method. Try it (at your own risk) and let me know how it works.
A co-worker has sent you and four or five other colleagues a MS Word document that summarizes some research that he did. The document contains some simple headings and paragraphs. You have a lot of ideas and feedback to give but, rather than give it all at once, you trickle it out and have your co-worker feel the pain of merging your edits.
Draft 1: Re-Format. Don't really change anything, just format the heck out of the document. Change the styles around. Send it back with a cryptic filename like [irrelevant name]_[your middle name]_final.doc. Mail it with a note saying that it looks good and you had some slight wording changes. Leave it up to your co-worker to figure out that nothing has really changed.
Draft 2: Re-Organize. A day after the first draft, take the original document you received and re-organize it. Re-order the sections and a few sentences here and there. Make sure that you turn on "track changes" so that the whole document is a multi-hued mosaic of change notifications. Name it [original filename]_new.doc. Send it with a note saying that you discussed it with another colleague and got some new ideas but "it is really coming along!"
Draft 3: Edit. This is the version where you provide your real feedback. Start with your Draft 1. Make your edits. Name it [original filename].doc. Send it with a note saying how excited you are about this project and have been "thinking about it non-stop." Schedule a meeting to go over it and ask that your colleague send out a merged final draft for everyone's review. During the meeting, walk through everyone's feedback. By this time, your colleague is probably totally fried and is ready for a new way of working. At the end of the meeting, innocently say something like "you know, this might have been easier if we had worked in the wiki."
This method works even better if you have a co-conspiritor working with you doing the same thing. During the process, watch out for signs of mental instability or fragility and remove all sharp objects from the office. Make sure that the Employee Assistance Program posters are visible and well placed.
All humor aside, sometimes the only way to change people's ingrained behavior is to offer an alternative that is substantially easier. It has to be a big improvement because old habits are hard to break. Starting to use a wiki can be hard for people accustomed to Microsoft Word. They will initially get frustrated and resort to what they know. If you can't eliminate the learning curve of a wiki, you can expose the inefficiency of collaborating without one. The next time they launch Word, they will remember their painful experience and think twice.
My career spans across the domains of a software developer and a knowledge worker. I participate in software development projects and I also do the things that your typical knowledge worker does: communicate information through reports, presentations, and other knowledge assets. One thing I have noticed from this perspective is that software development has been improving from the adoption of open source tools, behaviors, and practices while most knowledge workers live in the comparative stone ages of siloed working habits. As someone who loves living out in the country and working with people from around the world (and is also trying to reduce his carbon footprint), I look forward to the day when knowledge workers start to harness the techniques that distributed open source development teams have used to effectively produce quality software. Here are some places to start.
__Using Mailing Lists and IRC.__Mailing lists (and sometimes IRC) are the core channel of communication within open source development teams. Point to point emails (and, shudder, phone calls) are discouraged because they lead to duplicate communication and there is no centralized record of what was said. IRC is preferable to point to point instant messaging for the same reason. Frequently once there is a critical mass of substance on a topic, a wiki page (mentioned later) will be used to capture and organize the idea as it develops.Especially in the world of IRC, it is important to include some social value (i.e. fun) in the dialog. Otherwise, the people who have all the answers have little benefit in participating. I have worked on projects where everyone worked within arms reach of each other, listened to music on their headphones but constantly communicated over chat. I liked this way of working because if you had a complex thought in your head that would unravel if you were interrupted, you could ignore the conversation and catch up when you got to a good stopping place. I realized the secondary benefit much later: when the team was broken up and staffed on other projects, the conversation kept on going even though people were spread all over the world.
__Using Wikis.__Most open source projects use wikis for documentation. Wikis have a number of advantages over Office/Sharepoint: they stress information over formatting; they have excellent history and version comparison; they encourage referencing information (through links) over duplication (copy/paste); there is no local copy to synchronize; and they don't require special client-side tools to contribute. Every time I open a word processor, I challenge myself whether this needs to be a "document." My general rule of thumb is that I only do it for proposals, deliverables, and contracts where the audience needs their own local copy.
__Managing Vision and Tasks.__Even though I have worked on several software projects that wound up going nowhere, I have to say that an even higher percentage of knowledge work is wasted. You could argue that the act of knowledge work leads to learning which creates knowledge. But running around in circles without any results is demoralizing. I like developing software systems because you see tangible results. I wish knowledge work was more results oriented. The better managed software projects maintain a road map which communicates an overall vision of what is going be achieved broken down into milestones. Gantt charts just don't capture the "why" like a road map does. I think knowledge work could benefit from the same understanding. People should be responsible for mapping their individual activities to a shared set of goals and priorities.Open source projects rely heavily on issue tracking systems to manage work. Bugs and enhancement ideas all go into the issue tracking system where they are prioritized and assigned. If you have an idea for a new feature, you create an issue, assign it to yourself and start working. Maybe someone else shares your interest and starts to collaborate with you. In distributed teams, where you can't see people working, you need other ways to keep track of what people are doing - not just if you are given the role of "project manager." An issue tracking system would be a good way to achieve this.
__Holding Sprints.__Open source projects have long understood that effective collaboration depends on communication and trust, which are most efficiently achieved through face to face interaction. For this reason, many open source projects hold sprints (also known as hackathons) where people work closely together (as in 2 to a computer) and mix hard work with an equal balance of socializing and play. In a typical office setting, people need to rush home at quitting time to attend to their home life. If they normally work from home and travel to a sprint, they are more likely to hang out after work and get to know their colleagues.I think the sprint technique could have huge potential in knowledge work. It would get people together to share information and it would create networks for people to use in solving future problems. One big thing about software sprints is that they are centered around solving a specific problem or accomplishing a goal. I think that knowledge workers would really respond well to this sense of purpose.
Componentizing.Good developers know how to break down their software into re-usable components and reuse them. Most knowledge workers live by copy/paste (or Save As). Copy/paste not only creates redundancy that is hard to manage, it also frequently inserts unwanted content into your document. If you want to re-use something as it is, try to reference it. Granted, software has the advantage of build processes that assemble the appropriate parts to produce a cohesive product. Technical documentation (in XML) is often built like software. Most other stuff (particularly anything written in an Office (Microsoft or Open) is not.A while back I produced a coding standards document for my company. I based it on the Sun Microsystems' Java Coding Standards. Rather than copy the whole thing and then edit the parts I wanted to change, I referenced the original and created a small addendum document that discussed where we were deviating from Sun's standards. While this does not create a polished deliverable, it conveyed the necessary information which is what I was trying to do in the first place.
__Designating a Committer.__In large open source projects, lots of developers submit their code to a small team of committers who review everything before committing it to the source code repository. Knowledge workers are constantly creating assets and dumping them into places where they are often never read. Sometimes these assets are never reviewed but are randomly discovered. Then it is up to the reader to determine if the information is valid. Because of this, most companies are swimming in information of wide ranging quality and accuracy. Search technology vendors claim the answer is in sophisticated retrieval systems. I would argue that more attention to the review and categorization of information at the intake end is needed. The committer for knowledge work would be a subject matter expert with librarian skills. This committer would know about what has already been done, be able to judge quality, and see opportunities to create shared resources. In open source projects, the committer is a position of status earned by climbing up through a meritocracy. The analogous knowledge worker position in most companies is really low on the totem pole. Peo
ple who move up the latter in the knowledge world tend to drift away from the content and their distance leads to neglect.
I don't think these practices should be that difficult to adopt but they are rare outside of software development. The obstacles are probably mostly based on culture. Old habits are difficult to break. I think another issue is that knowledge assets are commonly thought of as a by-product of the work rather than the purpose of the work (like software is). Therefore, there is less urgency in addressing the quality of the assets. But if institutional knowledge is a priority of the organization, the assets themselves need greater attention and investment.
I was reading this post on the definition of a blog and it got me thinking of a conversation that I have with many of my clients. Often companies that are interested in replacing their content management systems have resorted to an intermediate solution of side-stepping their difficult to use, rigid web content management system by using a blogging platform to power a section of their site. They are attracted to the immediacy and ease of use of the blogging platform and conclude that they love blogging. But what do they really love? And could they achieve the same results on their WCM platform?
If you really break it down, a blog could be seen as a website design that can be implemented by most WCM platforms: short-form articles with immediate publishing (no workflow) organized chronologically on the site with an alternative XML (RSS) view and some interactive features like commenting. There is also trackback and pings but most companies don't even know what those things are. What WCM platform can't do that? Probably yours. And the reason is not the technology. It is just that you have designed your implementation around processes that you hate: complicated workflows, overly elaborate content models, lots of metadata, periodic publishing, etc. You may have gone too far down the path with your current WCM platform to introduce the simplicity that you love about the blogs. If you are replacing your core WCM platform, you may consider including a blog-post-like article in your implementation design. You may call it a blog. You may not. It doesn't really matter.
What if you like this blog-like behavior so much that you realize that you can get by without all the features of your classic WCM platform (navigation management, page composition, template selection, multi-step workflows, versioning, etc.)? In that case, a blogging platform may be all you need. Many of the blogging platforms on the market are building in foundational WCM capabilities and are becoming lightweight web content management systems themselves. While not as feature rich as the incumbent WCM platforms, they are typically easy to use and are certainly cheap enough.
So, if you find yourself in the position of happily blogging but want to replace your onerous WCM platform, you should consider the following options:
Use a blogging tool to power your whole website. This sounds crazy and may well be but just the act of considering the idea will force you through the exercise of discussing your requirements. It is easier to understand the importance of a requirement if you think through removing it. The discussion can also lead to creative new ideas. I liken this to Edward de Bono's creativity exercise where you put forth a crazy idea and you discuss why it would be good and why it wouldn't work and then try to harvest the good aspects of the crazy idea. If you are familiar with this exercise you know that the proposition of "the plane lands upside down" led to the tilting nose of the Concorde that allowed pilots to see the runway better.
Design your new WCM platform and website to be more blog-like. Base your simplicity and usability bars on a blog and only introduce complexity where you absolutely need it. Do not destroy the freedom, spontaneity and casualness that made blogging so fun. You may find that you could get away with a less expensive CMS than you thought you needed.
Fix your old WCM platform. Use what blogging taught you about content production and use it to refactor your existing CMS implementation. Simplify your content structure. Streamline your workflows. Hide features that clutter the UI. You might find that the WCM platform you have doesn't have to be as bad as you made it. You could even continue to use the blogging platform contribution interface and feed content into your main CMS.
Recently I have been helping a client establish standards for software development and configuration management. The developers are all very excited about instituting practices like unit testing, code reviews, and continuous integration but there is concern whether the pressure and pace of development would allow for taking the time to things right. Despite the fact that management brought me in to establish these practices, there is doubt as to whether the business could abstain from setting unrealistic expectations that force hurried work.
So the big question is - does doing things the "right" way take longer and jeopardize short term deadlines? I think the conventional wisdom is that process investment starts to pay off toward the end of the project or in subsequence releases of the system. But when is the break even point? I have heard lots of claims but very little hard data - mainly because it is impossible to compare different projects because no two projects are alike. I think the only way to get evidence that is even close to conclusive is to do a study like the following.
Take a large group of under graduate computer science majors and randomly assign them to three independent classes taught by the same professor. The course work for the semester is a series of software development projects to build an application where each project builds on the previous project. Each class gets the same projects. None of the classes has visibility as to what the next project will be or what the other classes are doing. All students track time spent on the projects. The different classes are instructed as follows:
Class A is given very aggressive deadlines and is graded solely on how well the application meets the requirements.
Class B is given less aggressive deadlines and is graded on development standards (unit tests, configuration management, and code structure and style) as well as the application's satisfaction of the requirements.
Class C is given the same deadlines as Class B but is only graded on the same criteria as Class A.
At the end of the test, you compare the time spent by the three classes and the overall quality of the three applications (defect rate, adherence to the requirements, etc.)
If widely considered best practices in software development are as effective as believed, Class B will end the semester with the best software and the least stress. Class A will be totally stressed and their application will be barely hanging together. I would guess that Class C starts the semester off breezing through and enjoying their free time but has to do a bit of cramming in the end.
