Archive for July, 2008
Don’t bypass the CMS
Point 1: Many content management systems (CMS) have templates and pages setup eternal to the CMS as a set of content blocks. It is unfortunately common for a programmer/coder to set content and format in these blocks that are not linked into content modules that are managed with in the CMS.
This is usually done by the programmer because they find it is easier to code these in directly than it is to have to link each and every image, meta data or content block to a CMS object. True – this does often save time up front. however, it almost always is detrimental in the long term. When coded outside of the CMS the site administrators, editors and content managers using the CMS do not have the ability to modify this content. This requires going back to a coder to perform tasks that are intended to be the function of a CMS in the first place. So, please coders – take the time and make it all manageable by your users even if you think it is an easy affair to pass the work on to you.
Point 2: Use the feature sin the CMS rather than bypassing them. Every CMS offers its own code for items such as date formats, meta data and other functions. Programmers often have code snippets or other methods outside of the CMS set that they prefer. However, the use of these non-CMS methods can sometimes lead to long term issues. For example, we recently wanted to change the date format on a site. We went into the CMS and changed the format using the management tools. The date format changed in half of the site in an instant. Then we found the other half had date formatting set external to the CMS. Not only was this bad form not to use the CMS, but it was not setup to use a consistent method.
Point 3: Follow the best practices from the CMS provider. Simply implementing a design in a CMS is not enough. Read through and follow the best practices to enable CMS functionality for the admins, editors and other users. These are just as important a set of audiences as are the visitors to the Web site.
Think this is all silly. Not so. I find that even the best world-class programmer/coder can be light on the longer term management strategies impacted by their decisions. After all, they are not expected to have this as their focus. They are expected to focus on the execution and we need to be sure that managers and strategists are clear on the architecture and best practices to be integrated.
Please correct me if I am wrong.
Why MediaWiki is not the right Wiki product for my clients?
Posted by Dan Katz in Online Marketing Best Practices, Software on July 16, 2008
I have been working with MediaWiki for a couple of years. I even have my own best practices Wiki running on MediaWiki. This experience matched with reviewing most client capabilities has led me to the belief that MediaWiki requires far too much technical awareness to recommend as a platform for clients. I have found applications such as SocialText to be a far more attractive package.
Why not MediaWiki for my clients?
- While a fabulous Open Source package, the benefits of commercial package with its support, product roadmap and dedicated team to fix issues is probably the most important reason to go with an alternate solution.
- My clients are all non-technical and have little if any knowledge of any markup language. Even with the best WYSIWYG and other helpful extensions I have found that the users need to know Wikitext. This really kills the popularity of the Wiki. For example, creating and managing categories is a dog in MediaWiki. My clients expect a far more sophisticated taxonomy solution that is simple for a non-technical user.
- MediaWiki out-of-the-box does not offer features that most clients desire. We then need to install numerous extensions. This is fine. However, we then get into a maintenance cycle that requires upkeep of these extensions. Going with a commercial (or open source alternative) package that has integrated items for this functionality removes this overhead. For example, one of the constants in my clients’ needs is to upload files to articles. MediaWiki without extensions expects you to host files someplace else and to link to them. The preferred method is one where you can browse and upload files easily right when you work on the page.
- MediaWiki templates are a bear. Compared to SocialText or other Wiki products MediaWiki requires a higher level of skills. Others that are available build more off of the more common HTML and CSS skill sets.
So, think I am off base. Please let me know and comment away.
Do clients really want a Wiki in the first place?
Posted by Dan Katz in Online Marketing Best Practices on July 16, 2008
Do clients really want a Wiki in the first place? Wiki technology enables fairly freeform community creation, editing and monitoring of content. In reality, most of the true client desire is for a system in which more control is provided. Certainly, one can make a Wiki a supervised environment. However, when you go down that route there are simply more suitable technologies from the knowledge sharing technology set. Sure a Wiki is cool and people can then say “we have a Wiki”, but is it really the best solution for things such as corporate publishing, internal communications, intranets, extranets and knowledge sharing? Or, are companies simply on a Wiki bandwagon until the next big thing comes along.
