May 31, 2006
I know I am late into the game but I am still trying to figure out the utility of podcasts. For me, the medium does not really work. I guess that is because
- I don't have an iPod
- I take the T to work and like to read during my commute
- My life has lots of interruptions. So when I read, I just get in really small bits at a time - except when I am riding the T
For those of you who can make better use of this medium than I can, Rahel Anne Bailie from Intentional Design recorded this semi-lucid commentary at the Spring Gilbane Conference in San Francisco.
May 30, 2006
James Robertson has written a thought provoking article on workflow and takes a gutsy stance that says that workflow doesn't work. I would have to agree with his points about the origin of the percieved need for workflow to improve quality control and workflow's failure.
My view is that workflow has two (usually conflicting) purposes: to speed things up or to slow things down. James is talking about the latter case where you put in controls to prevent undesirable content from getting published. By adding steps to this process you are deliberatly adding more bottlenecks to publishing. Pretty soon, the sysem is unusable. The other case (speeding things up) is about division of labor. Your process becomes an assembly line where people work efficiently because they are specializing. This only works if people want to specialize and are able to become more efficient by doing one thing (for example, graphics designers and writers). But most knowledge workers don't think of themselves or like to work in this way.
Another accelerating tactic is creating resource pools and workflow can also help with that. The concept here is that you have variable demand for throughput. When you need to produce more, you can draw resources from a shared pool and distribute the load more. Workflows designed to work in this way are role (rather than individual) based so that people share a queue of work. When you bring in extra people, the queue can be worked down faster. This is sort of how call centers work.
So, when designing workflows, think about whether you are trying to speed things up or slow things down. If you are slowing things down, keep things as simple as possible. As yourself if a simple approval would do. If you are trying to speed things up, as yourself an assembly line mentality works in your organization.
May 30, 2006
A recent post to the CM Professionals mailing list recommended a tool by EverAge consulting to write use cases in XML. I was interested because I think use cases are very effective in collecting software requirements and I think the de facto format (MS Word) is a really bad way to store this information. I had to check it out. Just not right then because I had 80 other emails to go through that morning. So I wanted to bookmark it for later reference. And that is where the trouble began...
The link was directly to the Zip file containing the software. I didn't want to bookmark that because the Zip file itself would give me no context (metadata). So visited the website to look for a landing page. Oh, the flashturbation! The site looks like a lava lamp of navigation items and text oozing around as they form on the page. While I appreciate all the work that went into this animation, from the user's perspective, it has the same effect as a slow loading page. Every click, I had to wait several seconds as the page mutated into something usable.
When I finally found the content that I was looking for, it was in a flash movie so I couldn't book mark it there either. So here is the link: http://www.everage.ca. To get to the tool: wait and admire, click on resources, wait and admire, it's the first entry in the little scroll box in the middle of the page. Or go directly here.
While all the Flash does a good job of showcasing EverAge's skills in interactive page design and programming, I think it risks sending the message that EverAge doesn't understand the appropriate use of Flash and its limitations. Web designers are going to go through a new learning curve as they start to use AJAX and other technologies that push the limits of what is a page. The tension between innovation and usability/familiarity will need to re-stabilize as designers and developers try new things and users react. Search and bookmarking are primary considerations. So much of existing internet technology is based on URLs and anchor tags. Take those away and the user's familiar tools quickly lose their potency.
Think of the browser as two things: a traditional browser, and an operating system on which to build dynamic applications. Make your decision early as to what you need it to be and design your interfaces accordingly. My general rule of thumb is to avoid using AJAX or Flash except when you want a user to interact with (rather than just view) the content and do not try to re-invent the browsing experience. Otherwise you will gain little benefit but spend lots of time solving problems that have already been solved with existing best practices (search engine optimization, accessibility compliance, etc.). If you want to improve your content viewing experience, focus your energy on making better content.
May 20, 2006
I am not in the habit of identifying laws of nature or industry, but if I was, Gottlieb's Law would be "A company's success in content management is inversely proportional to the amount of information that is exchanged over email." Email probably has an 80% share of the content management market and that is a huge opportunity for growth of real content management processes and technologies and great opportunity for improvement for companies in managing their content. In fact, the next document management project I do, I want to baseline the number of email attachments before the project starts and not declare success until that number drops dramatically.
If you know me personally, you know that I often rail against email as a collaboration tool. A colleague of mine recently pointed out this blog post just to get my dander up. The desired results were achieved and I was not even soothed by the counter argument blog from the same source. I understand why email is such a tempting tool. That post outlines the reasons nicely: it is easy, universal, accessible, personalizable, reliable, and people just live in their email clients. Even I have to admit, the more you manage, the more you live in your email client. That is why most executives don't even need a computer anymore - just a blackberry to thumb a yes or no wirelessly. I could throw in a stick-it-to-the-man barb in here about adding value but I won't. What I will say is that if you compose the most brilliant text in the world into an email, it will have less impact than if you published it in some more persistent medium such as a blog, wiki, or forum.
The key issue that I have against email is that it compounds the problem of exploding volumes of unmanaged content by creating unnecessary duplicates. If you email a document to 2 people, you now have 3 copies to manage and merge and diff. No one knows which one is the master copy. No one knows which one is the newest copy regardless if someone stupidly added "new" to the file name. Plus, everyone is personally responsible for their piece of the archive. That is too much responsibility. If I accidentally delete the best version (it may or not be the latest version) of a document, there is no way to get it back.
There are lots of other issues I have with email. Many of them stem from a so-called benefit of email that it is a central place and it is in your face. Most people get too much email and are really bad at managing it. Because I monitor lots of open source mailing lists, I consider myself in that group. I constantly miss emails that sift below the scroll. I know that others have the same problem because whenever one of the mailing lists I subscribe to starts to get lively with good (or bad) dialog, there is always someone who complains about volume. What kind of collaboration is that? "Could you all please shut up? I have personal information management problem."
Never to be one to rant without a solution, here are some tips to solve the information management problem. I refuse to believe that the solution lies in building a better email client or integrating into email (other than sending an email notification of some event).
-
See email for what it is: it's a messaging system. Use email to notify someone of something. If your message contains information that you want that group of people to continually refer to, put it somewhere that you all have access to.
-
Publish information over RSS rather than email. I know that the marketing types still love their email newsletters and I know that some people still love getting them. It just feels incongruous to me to get these broadcast publications in the same place I want to get my business correspondence. I don't subscribe to any of them anymore. I am a bloglines junky instead. I also wish that there were two postal services, one to carry birthday cards and bills, and another to catalogs and credit card offers. OK. I know that I am asking for too much here. You can ignore that one. But, if anyone is listening, please stop sending me credit card offers.
-
Allow the user to dictate how they are notified of content (email, digest email, RSS), not how they manage or receive content. Let the user subscribe to be notified when something changes in the repository (See CPS for a good model) but don't allow them to get attachments and take assets to manage "off the grid." Once you do, that document will take on a life of its own outside the system and become a threat to the system's relevance. The system should allow a user to send a link to someone rather than an attachment.
-
This begs another question: offline access. I would suggest looking into a synchronization technology like Microsoft Windows Briefcase. Even as someone who travels a lot, I have grown to depend on the ubiquity of the network.
-
If your team crosses organizational or company boundaries and you communicate enough, consider putting up some sort of shared space to work in rather than stay in the lowest common denominator (email).
-
Experiment with tools that can take some of the burden off of email traffic. Open source is really nice in this area because you can try different things and see what people feel comfortable using. If it looks more complicated or difficult than email, people will use email.
-
Don't be afraid of introducing a new tool. Anything is an improvement over email or nothing. If you are successful in getting people off of the old standby, you can leverage that success in migrating to a more centralized system. If you are good, you will understand what lead to success and apply those lessons to the configuration of the new system.
-
You probably already have tools kicking around your infrastructure. Use them. If they don't work, give some serious thought as to why.
-
Think content first, not documents. If you are publishing something, don't create a document when you don't have to. Too many people default to opening up a word processor or presentation authoring system the moment they have something to say. For example, if you have a collaboration space and you want to put up a phone list of the team, don't write it in a Word document. Create some kind of page instead. Why would you ask someone to download a document and open up an editor just to get a phone number? People will just save local copies and work from that. Then you have to deal with telling everyone that an updated version is available. If your collaborative workspace does not have pages, you have the wrong tool. My rule of thumb is that I only create a document when the content has to exist outside of the system. For example, if I write a statement of work or a white paper, it needs to be in a document.
-
Think "page" or "post". A page is something that is maintained, a post is a snapshot in time. This blog entry is a post. If tomorrow I change my mind and I decide that I love email, I will write another blog post. My profile on this blog is a page. If something about me changes, I will update it. Use forum and blog tools for posts and wikis and WCM tools for pages. Of course, many WCM tools have content types for blogs and news releases and that is OK too.
-
Make it easy for a person to join and leave the conversation. Forums are good in this way.
People were right when they called email the killer app. It is everywhere. It is extremely useful doing what it is good at: sending messages. It is also a victim of its own success and it's overuse, in my opinion, is starting to threaten
its usefulness. I would be very interested in hearing others ideas on this. Just don't email them to me ;).
May 12, 2006
I will be speaking at the Washington DC, Gilbane Conference in June (13-15th). My session will talk about Federal use of (you guessed it) open source content management technologies. Joining me in the session will be Page Glennie from the Department of the Navy. His group had a very successful experience implementing eZ publish. Let me know if there is something you think that I should mention in my talk.
May 12, 2006
My colleague Stephen Walli and Matt Asay from Alfresco had an excellent dialog on Stephe's blog about what it means to be an open source company and how an open source software company should view its users.
To give you a little background on the topic, Matt wrote several posts essentially saying that you get what you pay for and, if you want good software, you need to pay for it otherwise you are essentially cheating the system. We feel that people can contribute back to an open source project in many ways including simply using it and by doing so, testing it, and contributing ideas.
Stephe, Dave Gynn, Matt and I are friends going back prior to Matt's joining Alfresco. These conversations are extremely constructive and I think that it is great that they are happening out in the open. In the commercial software world, you wouldn't see partners debating in public. But that is the beauty of open source. Everything happens out in the open.
May 10, 2006
CMS Watch recently referenced Martin White's EContent Article further disproving the one size fits all vision for content management. It seems the pragmatic "best of breed" approach has beaten the industry sanctioned, monolithic ECM message in almost Gandhi-like fashion ("First they ignore you, then they laugh at you, then they fight you, then you win.") and no one really believes that one CMS implementation can serve everyone. Even if a single CMS product could do it all, customizations and configurations to benefit one group would spoil it for other groups trying to do different things.
So where is the discussion going to go? I think the interesting problems are: a) how to optimize a technology (and process) to solve a finite set of business problems really well; and b) how to share content across a heterogeneous content environment. These are harder, more interesting, problems. Problems that are solved with continuous, incremental improvement and focus on the user - not big bang silver bullets that are more likely to blow up in your face than hit a target.
May 08, 2006
The slides from the my "When Open Source" presentation at the Spring 2006 Gilbane Conference are now posted up on the Gilbane Site. They are published under the Creative Commons 2.5 License so feel free to re-use with attribution.
May 08, 2006
I had this blog post by Jonah Bossewitch bookmarked for quite some time and I figure I should mention it not only for it's brilliant Matrix reference ("Do not try to bend the folder -- that's impossible. Instead, only try to realize the truth. Then you will see that it is not the folder that bends--it is only yourself."), but its mind bending implications for content management.
Most web content management systems, see content as something that can be organized into hierarchical structures. Web sites are frequently represented by sitemaps and navigation which presume everything has a place in a tree. I say this is a vestige of a static web world where the web server merely served up what was on a file system (which is a hierarchical organization of folders and files). If the web were to be organized that way, it would stink. Luckily it isn't. The web is a collection of interconnected nodes. Search engines flatten out the web into topic based lists based on the occurance of words and billion dollar algorithms. Interestingly Google Desktop evokes a devotion similar to TiVo for making a mess of poorly organized content (television is organized by time) accessible and useful. So, it isn't even that we don't understand other people's hierarchical organizational structure, we can't even find things that we file away in our own, custom designed filing system.
The latest trends in tagging and social bookmarking are just other, more intentional, ways to create lists of content on a topic area. Flickr's Tag Cloud is an example of structureless dynamic navigation.
So what open source content management systems are the best for supporting this more evolved view of websites? I would agree with Jonah that Drupal is the most oriented toward tagging. Drupal has no folders, just vocabularies and topics. It makes sense that Drupal would be first to execute this new vision because it is designed to enable a community to post and discuss ideas and news which don't necessarily belong in a single place within an informational tree. Blog software such as Wordpress and Roller deliver this functionality through categories. Sadly, Blogger does not have categories. Perhaps this is over-confidence in the Google search algorithm? Granted, your average not-so-technical knowledge worker may have a hard time breaking out of the desktop metaphor of putting things in representations of physical "places."
Jonah also points out how Plone, which is built on the folder based Zope, has Smart Folders which are really saved searches. This allows you to create dynamic topic based lists without entering the same search criteria every time. I am waiting to see a Plone site whose navigation is all Smart Folders. Incidentally, Smart Folders and ATCTSyndication is a powerful combination that will allow you to create a RSS feed on any search.
While eZ publish is very folder based, it has a nice separation between "object" and "location" that allows an object to exist in more than one locations. Content assets within CPS exist in a placeless repository and are accessible through the site hierarchy through "proxies." This also allows a piece of content to exist in multiple places at once.
If you enjoy this topic you should take the time to read Clay Shirky's long but very good blog post Ontology is Overrated: Categories, Links, and Tags, which inspired Jonah's post. Clay makes some great observations about how Yahoo!s elitist, top down organization of the web ("We understand better than you how the world is organized, because we are trained professionals") is inferior to Google's view that "There is no shelf. There is no file system. The links alone are enough." I would add that dmoz is even more deluded thinking that a web site only belongs in one node of their hierarchy.
It looks like tagging is trumping hierarchies and taxonomy on the big Web. I would be very interested in hearing how these concepts are playing inside of the corporate firewall. If you have a story to tell, please comment here or send me an email. The average corporate intranet is definitely failing to deliver on the promise of being "institutional knowledge at your fingertips." Will tagging and search be the paradigm that saves it?
May 03, 2006
Recently Sebastian Wohlrapp and I published a whitepaper on open source document management systems. If you are looking for a solution in this area, you also might want to add Infrae's Document Library to the list of products to consider. I have not yet tried Document Library but have used their Silva WCM product which does a very good job of versioning and workflow. One thing that caught my eye is their support of the Open Archives Initiative's Protocol for Metadata Harvesting (OAI-PMH) which might become an important standard for companies implementing a distributed/federated content management strategy. Here is a good description from the OAI-PMH Tutorial
The essence of the open archives approach is to enable access to Web-accessible material through interoperable repositories for metadata sharing, publishing and archiving. It arose out of the e-print community, where a growing need for a low-barrier interoperability solution to access across fairly heterogeneous repositories lead to the establishment of the Open Archives Initiative (OAI). The OAI develops and promotes a low-barrier interoperability framework and associated standards, originally to enhance access to e-print archives, but now taking into account access to other digital materials. As it says in the OAI mission statement "The Open Archives Initiative develops and promotes interoperability standards that aim to facilitate the efficient dissemination of content."
If OAI-PMH sounds interesting, you may also want to consider looking at DSpace which is gaining adoption in academic research environments such as MIT.
In addition to OAI-PMH, Document Library does automatic document conversion (using OpenOffice - just like Alfresco), workflow, versioning and other things you would expect from a DMS. In terms of architecture, Document Library is built on the Zope 3 platform and uses the Silva Tramline for rapid upload and download of files.