This evaluation really comes down to a definition of the task you desire. I have found that WordPress is the ideal selection for any blog. I have also found it to be an excellent choice for a small to medium Web site. Why? In two words, elegant simplicity.

On the setup side, WordPress is so simply to install, create themes, add enhancements that it is easy to get an excellent site up and running in a very short time. Then on the administration side, the user experience is an excellent one for those who are not familiar with technology. I have been able to bring luddites up to speed in WordPress post, page and comment management in mere minutes.

Drupal I have found to be more suitable to larger Web sites that require a greater level of development for custom applications, multiple themes, multiple languages and other aspects you would expect of a full bore content management system. For a blog or small Web site I find it to be overkill and adds a level of complication that adds too great an expense to sites that so not require custom applications.

This difference is apparent in the extensions to WordPress and Drupal. Drupal features a large set of modules to extend features. WordPress appears to offer many more. The difference comes not just in volume, but types. Drupal has a set that is clearly more technical in nature than WordPress. Also, a good number of the modules are seen as jumping off points for custom development. This is far different from the WordPress plug-ins that are targeted to the Web site maintainer who has little if any programming knowledge.

And this comes to the real difference I see with these two platforms. Drupal is clearly targeted first and foremost to code lovers and developers. This is readily apparent in the language used on the Drupal site, its blog postings and in general. Development discussions on the site are highly technical and constantly refer to a mix of PHO, JavaScript and JQuery as minimal requirements for Drupal development.

WordPress on the other hand has a greater balance between the average Joe that wants to have a blog/site and the developer. Surfing to wordpress.org you find that this is tailored much more to the layman than Drupal.org. WordPress also has a broad commercial path to get started via wordpress.com. Then when you do dive into development, you find that with minimal PHP skills you can customize and modify themes.

I find that this separate target of hard core a developer (Drupal) to the general population (WordPress) is clearly evident in area of theme management. In Drupal, the themes are all managed external to the Drupal interface. You compile and create the various layouts on the backend (as you do in WordPress) and then must manage these from the back end. In WordPress, you have access to theme templates form within the interface for modifications. This distinction is key. There are two levels of expectations here. In Drupal there is the expectations that the framework will usually require far more coding and management than should be permitted via the interface. WordPress on the other hand considers the possibility of editing templates to be something that should be permitted to the administrations right from its graphical shell.

Again, this comes back to suitability of task. I would not want a large scale site with numerous complex templates to be accessible by any old administrator – hence Drupal. However, if I have a small site where the admin, maintainer and developer are likely the same person and the theme is straight forward then the interface access is reasonable.

Here are some other side-by-side comparison.

Editing Interface

I hate the Drupal editing interface. The listing of pages without any management options means it takes me a long time to find and then adjust content. The content listing and editing options in WordPress are simply far more elegant than anything offered in the Drupal core or via any add on modules I have found. For this interface reason along I prefer WordPress.

Comments

WordPress has focused for years on its comment moderation capabilities. They are top notch. Drupal’s are rudimentary at best. Having now used both, I would have to eliminate Drupal as a blogging option for a site that expected high comment volume. Drupal is a fine technical solution. Drupal is simply not up to the task when it comes to the associated workflow.

Simplicity of Free Themes and Theme Design

WordPress and Drupal take a few minutes to install. Getting started with adding a free theme for WordPress takes a few minutes to find tens of thousands of items to get started. Drupal then takes quite a bit to customize even free themes. This difference real comes to the forefront with my experimentations. I can transfer an existing site with drop down menus and a couple of area designs to WordPress in half a day. The same effort took me (and an experienced Drupal developer) a week.

Media Library

WordPress offers a simple but elegant media library. And a couple of plug-ins really push it to an even better solution. Drupal’s media management is barebones. Media is considered a node or content element just like any other item such as a page or post. This is excellent when you want to develop a larger application on top of the framework. However, it falls short for a simple site.

Plug-Ins

WordPress offers not just one plug-in for everything imaginable – there must be three or four. The modules that extend Drupal are simply not as varied and there are less options for each task. More to the point, adding, testing and tweaking just seems to be so much faster and easier in WordPress than the developer focused interface offered via Drupal.

Here are some other articles for thought

• Consider using Drupal and WordPress. WordPress for the blog and Drupal for the application side of a Web site. This appears to be in use by companies such as The Bivings Group –See http://www.bivingsreport.com/2009/integrating-tweetbacks-into-your-wordpress-blog/
• An Apples versus Tanks analogy – http://www.elithecomputerguy.com/content/drupal-vs-wordpress-blogging-comparing-apples-tanks
• A kind of funny video version http://blip.tv/file/829821
• An article also about suitability but brings into the fact that the Drupal arena does not focus on marketing of its own efforts in a manner that encourages broader appeal. http://graduallythensuddenly.com/2008/05/04/wordpress-drupal-irrelevant/
• Here is one that has found a clear reason why Drupal may have an advantage over WordPress http://www.danmyers.name/wp/2009/02/drupal-vs-wordpress-why-i%E2%80%99m-having-second-thoughts/. Then again I have used a WordPress plug-in for two years that fixed the problem he has been having without ever having to do any programming
• Here is a side by side list of features http://mydrupal.com/drupal-vs-wordpress. I do not agree with the bulleted list of statements. One I find funny is this one. It says to choose WordPress “If you want ease of use and Navigation…” Okay, is this not one of the basic all time requirements of everything that has to do with any sort of Web site.
• A nice balanced evaluation is at http://www.thesitewizard.com/general/wordpress-vs-drupal-vs-expression-engine.shtml
• Some fun as folks snipe at each other on the Drupal site at http://drupal.org/node/257065. One person claims that WordPress has a “less active development community.” Personally, I have found this to be the reverse. I have found far more global WordCamps and help with WordPress than I have found from Drupal and its more limited meetings. In fact the tone is entirely different. The WordPress folks have been generally welcoming to newbies and encourages exploration by neophytes. My forays into Drupal have been met by cold responses that I should improve my PHP and CSS before I ask questions. Kind of like a family response WordPress) versus a clique (Drupal)
• A nice simple evaluation and balanced perspective from a developer who does not mind getting into the down and dirty of things http://www.webdesignstuff.com/web/designers/03/2009/drupal-vs-wordpress/

Then again I have had no problems with Vista other than the inability to run a couple of games that I never expected would run under Vista.

The only thing I have noticed so far is that Windows 7 works fine on some older hardware that failed to support Vista. This could be good news when Windows 7 is finally released if they do not bloat the product any further.

1. It is clear that even my completely unknown and haphazard blog is immediately noticed by those who monitor on their focused topics. Kudos to Atlassian for solid proactive monitoring and marketing efforts.
2. There appears to be solid agreement outside of the world of the techno geek that platforms other than MediaWiki are easier for the end user.

Two folks have contacted me to supplement my original review with products they find useful – Mindtouch Deki and Atlassian Confluence.  Both of these products clearly target the same market as Socialtext to provide a more usable and supported environment then MediaWiki. Both products seem to offer solutions worthy of investigation for those considering Wiki products.

Here are some things I noticed.

• MindTouch’s offering of a free & open source version and source code as well as a free personal Wiki hosting is a great marketing win.
• MindTouch’s marketing clearly to people who tend towards the open source spectrum.  The easy to use free hosting also is very inviting to those who want to get started quickly with experimenting and need a simple quick solution to get running.
• Altlassian has a taken an alternative voice and is focused on IT audiences.  It’s Wiki offering is clearly packaged as one solution of many they offer to enterprise workgroups.  And while they offer similar hosted and license options as others, the marketing focus on features bespeaks their expectation of readers’ familiarity with why one would want a Wiki. Atlassian’s free 30 day evaluation (rather than offering any free personal hosting option) supports this IT focus as well.

Lessons learned: 

1. There are many many options potentially better than MediaWiki.
2. The marketers are targeting their message to different organizations to provide differentiation via message for a product set that is rapidly becoming a commodity.

Technorati Tags: MediaWiki

However, for those cases an ASP managed service is called upon, I do not find the paid services of WordPress.com (or other WordPress MU based services) to be up to snuff. The lack of the ability to edit the theme files lead me to require an alternate solution.  Sure, WordPress.com allows for CSS editing that may be applied to the available templates.  However, this is simply insufficient to create the robust solutions I find my clients need. 

This lack of template editing in WordPress.com leads me to recommend the services from TypePad.  TypePad provides unfettered access to create, modify or add template files as well as any number of CSS files.  This has enabled us to do things like switch out the comments engine or add forms via third-party solutions. 

P.S.: If installing your own blog software or in need of a simple CMS for your own server I still recommend WordPress. 

Agree, disagree? 

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 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.

In its day Microsoft FrontPage set the standard for an easy to use Web site, application and page design software. Dreamweaver and other packages may have been preferred by us geeks. FrontPage held (and still does) the preference for the masses. Its initial release certainly brought Web sites within the reach of anyone who could use Microsoft Word. I know folks who have sworn by FrontPage for years – and they have never seen a single line of HTML code. (And I am glad they never looked; the code was never very clean).

Microsoft Expression Web is a major upgrade as the replacement for FrontPage and reveals many more technical aspects than FrontPage did. This may in fact discourage widespread adoption by previous FrontPage users. No matter. With this package, Microsoft is certainly going full bore to compete with the Adobe Creative Suite and move away from its lighter weight FrontPage predecessor. Reviewers do not see this as a Macromedia or Photoshop killer. However, the package is clearly targeted to the Web newbies and literati and will eat into the market for those not tied to Adobe. .

Adobe based designers will likely never switch to this suite. However, it will attract those who prefer Microsoft’s’ end-to-end integration across the Office/Server line. The biggest fault of this tool/product line appears to be that it comes from Microsoft. I expect that the vocal anti-Microsoft crowd will not be able to overcome the ease of acquisition and acceptance for product integration the majority of computer users have with Microsoft products.

My first impressions with this product are positive. It places a set of Web 2.0 features into the hands of the masses without the need to learn code. Once the plug-ins become more available the functionality will come to rival that available via its Adobe competition. I do not think I will switch from Dreamweaver. But, I would consider recommending the package to those without a brand preference.

Check out the products here: http://www.microsoft.com/Expression/

A thorough review will be posted soon.