HTML5 has certainly been making the rounds in the news lately. With Apple’s on-going PR campaign against Adobe’s Flash technology, comes mounting misconceptions about what exactly HTML5 is, what it can do, and what it means for end-users.

I hope to clarify several of the most glaring misconceptions over the next few posts. Today I’d like to focus on the most publicized and misunderstood issue of HTML5 video.

HTML5 is not a complete standard

Before we even get into video itself, it is worth noting that for all the publicity HTML5 is getting as the next big thing, it isn’t even final. W3C, the standards body responsible for HTML5, still classifies the HTML5 spec as a “Working Draft” as of this writing.

This means that none of the features are final and are still subject to change. While many browser makers are being pro-active in adding support for the proposed HTML5 features, there is inconsistency in implementation between browsers and level of support.

In other words – HTML5 is not supported in its entirety by any browser currently available.

Why HTML5 video?

One of the biggest areas of growth for Flash has been in delivering video. Flash was probably never best suited to the task, but due to the market penetration the plug-in had across the Internet, it evolved into the defacto standard for delivering web video.

HTML5 seeks to alleviate the web’s reliance on a single plug-in for video by bringing native video support to the browser negating the need for a plug-in. There are many high-profile live implementations of HTML5 video on the web today that target modern browsers and Apple’s mobile devices like YouTube, Vimeo, Time Magazine, NPR, and others.

However, while Apple is aggressively pushing HTML5 video for their iOS devices and modern browsers as an open alternative to Flash, what isn’t open is the video codec Apple has chosen for their implementation.

What is a codec, and why does it matter?

A codec is a method of taking raw audio and video and compressing them into a single file for distribution, and subsequently decompressing the file for playback. Raw video is extremely large, and so codecs serve to produce the best possible size to quality ratio. For web video specifically, this is extremely important.

Several notable browser and smartphone makers like Apple, Google, and Microsoft are currently (or intend to in Microsoft’s case) supporting the popular H.264 codec for HTML5 video. However several other bodies oppose this seemingly ad-hoc choice due to the fact that the H.264 codec is not open source and requires licensing. Organizations like Mozilla and Opera have posed the argument that an open video implementation without an open codec is two steps forward, but one step back.

However, the counter-argument in favour of H.264 generally revolves around the notion that H.264 is already widely adopted, has excellent performance, quality and compression, the licensing terms are clear, and all patent claims against the codec are accounted for. Contrasted to some of the open source alternatives proposed like Theora, it isn’t clear whether or not they may infringe on existing patents, which makes them somewhat risky to use. In addition, both Microsoft and Apple are members of the licensing organization for the codec, which may also explain their preference.

To muddy the waters further, a new video codec called VP8 has recently been acquired by Google and has been released as open-source. Mozilla, Opera, Adobe, and Google, are all pushing for this codec to be considered for HTML5 video via the WebM Project.

So what? Does an open codec matter?

There are valid opinions on either side of this debate. It is logical to want to see an open source codec used in conjunction with an open standard like HTML5. Otherwise every piece of software that plays or authors video intended for the web will need to pay licensing fees for use of the codec. Others consider this a fair price to pay for access to a mature, robust codec with high-quality compression.

Personally, I don’t feel comfortable handing control of such an important piece of the Internet to a private organization. Much like the arguments levied against Adobe’s proprietary Flash technology, trading video locked into Adobe’s Flash is in a way much the same as video locked into MPEG-LA’s codec. Alternatively, browser makers could simply license and build the Flash plug-in into their browsers and achieve the same effect.

If we’re going to go through the effort of converting the Internet away from proprietary video formats, we might as well go all the way.

HTML5 video is not a catch-all solution

While the prospect of an open video format is extremely enticing, there are several cases where it will probably never be used. A prime example is the distribution of broadcast television and film. Currently networks stream their content online and support it with advertisements. Since this video is locked away in a plug-in like Flash or Silverlight, the viewers of these streams are unable to download and re-distribute the content.

HTML5 provides no method of content or copy protection, which means it will probably never be used to distribute this sort of content.

What this means for end-users is the continued use of closed, proprietary technology – whether it be plug-ins like Flash or Silverlight, or platforms like iOS applications.

So while HTML5 video will clearly be a great step forward for web video, it will not fully replace Flash – at least not in this iteration. Therefore while Apple has valid reasons for not supporting Flash on iOS (namely Flash’s notoriously poor performance), it cannot be denied that Flash video will remain a significant source of copyrighted video content on the web until a better solution emerges.

When people think of open source, the things that immediately come to mind are products and tools that many consider to be polar opposites of Microsoft offerings.

Firefox vs Internet Explorer
Linux vs Windows
Apache vs IIS
PHP vs ASP.NET
MySQL vs MS SQL
Open Office vs Microsoft Office

If you run an organization that heavily relies on Microsoft technologies like Windows Server and Microsoft SQL, you may immediately assume this means you’re out of luck unless you’re willing to invest in open source web infrastructure – the most popular of which is known as the “LAMP” (Linux, Apache, MySQL, PHP) stack.

Luckily this is no longer true. Microsoft has made a concerted effort to support PHP on Windows Server and Internet Information Services (IIS). While PHP has always been able to run on IIS, the performance and stability was widely considered to be poor and as such, Windows was generally avoided as a viable server environment for PHP applications.

However, as of last year, Microsoft has begun official support for PHP on the Windows Server platform and is publishing official PHP extensions to natively support Microsoft SQL as well. This support has made the Windows Server environment a viable platform for popular open source CMS tools like Drupal, Joomla and WordPress.

In fact, if you visit the PHP microsite on http://iis.net, you’ll find easy install tools to get PHP running on IIS along with bundles of popular open source projects.

Support doesn’t end there – Microsoft is also addressing scaling and compatibility concerns by publishing a URL rewriter which is compatible with Apache’s popular mod_rewrite and a caching engine.

This move of support from Microsoft is a powerful indicator of how strong and successful the open source movement has been across the web. Microsoft could no longer afford to ignore the prevalence of PHP and rising popularity of open source tools in the enterprise space.

Many open-source advocates may dismiss this support as a “if you can’t beat ‘em, join ‘em” move on Microsoft’s part, and I think that’s sadly missing the point. Regardless of Microsoft’s intentions in throwing support behind PHP and popular open-source web applications, the key point to take away from this is that Microsoft has dropped several barriers companies have faced in the past when looking to leverage these technologies.

I don’t really blame people, though. Drupal probably isn’t for them, and drupal.org and most Drupal advocates are doing a terrible job of setting expectations. So much so that I feel this trend of pushing Drupal onto everyone for everything is hurting Drupal’s reputation and perception.

Drupal is NOT in any way, shape or form a turnkey solution. You cannot download and install the package from drupal.org and get anything resembling a functional, maintainable website. Drupal is NOT a content management system, it’s a content management platform.

To most people that distinction is meaningless and does not adjust expectations. All one has to do is count how many times a day people ask on Twitter whether they should choose “WordPress, Joomla or Drupal” to recognize where people’s expectations are when talking about Drupal.

When first installing Drupal 6.x, most people quickly realize:

• It has no WYSIWYG
• It does not generate search engine friendly URLs
• It has no media management
• Does not produce image galleries or embed video
• Has a confusing, cryptic admin interface that doesn’t distinguish itself from the user-facing site

To a user expecting something like WordPress, Drupal looks like complete and utter garbage, and they’re quick to express this point of view on blogs, twitter, message boards, Facebook, LinkedIn and in comments on posts like this.

Drupal is designed this way intentionally (as counter-intuitive as this may seem). No two websites are the same, and so Drupal tries to make as few assumptions about what kind of site you’re trying to make as possible. Upon installing Drupal, the expectation is that the user then proceeds to head over to http://drupal.org/project/Modules, browse the buffet of functionality and proceed to “build your own content management system”… but no one tells the user that.

With the right amount of patience, research and experience, Drupal has the capability to produce massive, complex, highly customized site management tools for any size organization. This is the main reason many web shops are shifting their business toward providing professional Drupal services. In a nutshell, it lets developers build very customized sites for clients quickly and at lower costs.

There is much debate happening within the Drupal community about whether or not the current approach of shipping the core product with as little as possible is the correct one or not. Some feel shipping with a WYSIWYG and a more concrete set of metaphors is necessary for Drupal’s wide adoption while others feel this takes away from Drupal’s core strengths.

Whichever side of the fence you currently sit on, I think we can all agree that the current state of the messaging to new users sets errant expectations and new users may look upon the tool more favourably if they come into it with the expectation that upon installing Drupal, their job is only starting.

Acquia, Drupal founder Dries Buytaert‘s commercial venture, is betting on their Drupal 7 based hosted service,Drupal Gardens, to start changing perceptions by demonstrating what a “productised” implementation of Drupal can do. Whether Gardens will help or hurt the cause remains to be seen as the product is in invite-only beta as of this writing, and Drupal 7 itself has not reached a stable release yet.

Even still, Drupal isn’t for everyone or every site, and that’s OK – I’m a big believer in selecting the right tool for the job. If you’ve found yourself in a position where you’re unsure about whether or not your organization is suited to jumping on the Drupal bandwagon, check out our literature on open source software, and/or give us a shout.

As anyone who has developed a Drupal site with devel module‘s query logging on can tell you, a Drupal implementation can quickly get out of control when it comes to hammering the database. Personally, I’ve seen Drupal run well over 300 queries to render a single page. In a hosting setup where the bottlenecks exist at the memory usage and MySQL levels (which refers to nearly all non-dedicated hosting packages), this can quickly become a problem.

I’ve summarized a series of simple setup and configuration tips behind the jump that can help any site running Drupal 6.x improve performance and the subsequent user experience as a result.

1 – Disable Re-Building of Theme Registry

When a Drupal implementation is under development, themers and/or developers will often enable an option that forces Drupal to rebuild the theme registry on every page load. This registry tells Drupal what template files and overrides exist in the theme’s directory. This is a very costly operation and would cause noticeable slow down on any production website. It is important to disable this option upon going live. Under Administer > Appearance choose the Configure option for your theme and scroll to the bottom of the page. Make sure the option named “Rebuild theme registry on every page.” is disabled.

2 – Enable Page and Block Cache

Another simple option to enable is Drupal’s caching engine (Administer > Configuration > Performance). When enabled, Drupal will render the page and associated blocks once, and then save that result in the database. This can drastically reduce the number of database calls run on a page since the results are pre-rendered.

A point to consider about caching is that the more interactive the site is, the less effective the cache may be. Especially if complex permissions are at play, Drupal won’t be able to effectively cache since most of the page content may change depending on the permissions of the currently logged in user.

Drupal’s caching engine is most effective for anonymous visitors – if your site is mostly “read only” and doesn’t have visitors logging in, caching can make a dramatic improvement in site load speed.

3 – Increase Cache Lifetime

An option for some sites may be to increase the cache lifetime. This determines how long Drupal will hold onto a cached result before it will re-generate the page. If you have frequently changing content, you may want to set the cache lifetime to only 5 minutes, but if your content doesn’t change often, an acceptable value may be several hours.

On high-traffic sites, the less often Drupal has to re-generate pages, the better.

4 – Optimize JavaScript and CSS Files

Also in the Performance settings is an option to optimize both JavaScript and CSS files. When enabled, Drupal will consolidate all CSS and JS files included on each page into a single file, and compress the code by removing whitespace. This will reduce the overall file size and improve page load speeds.

5 – Disable Un-used Modules

Due to the staggering array of available contrib modules listed on Drupal.org, it’s common to download and install dozens of modules to test out and see if they meet your site’s needs. In the process of doing this, it’s easy to forget to uninstall the modules you don’t end up using. Additionally, the default install of Drupal comes with a minimum number of modules pre-enabled. Again, if your site isn’t using it, there’s no reason to keep it enabled.

Drupal will fire callbacks for all enabled modules which may come with their own database queries. Be sure to take the time to clean out your enabled modules list before going live with a site.

6 – Configure Cron to Run

One thing that’s easy to overlook is setting up Drupal’s cron tasks to run. Most web hosts provide a way to configure “scheduled tasks” or “cron jobs” in the hosting panel. Drupal’s cron.php fires updates for RSS aggregators, launches the search indexer, and any tasks defined in installed modules. In addition, it will perform some basic maintenance tasks like deleting temporary files and clearing logs.

The Drupal installation guide covers cron in detail with several methods for configuring it.

7 – Disable CCK Content Permissions

While this tip technically falls under tip 5, I figure it’s important enough to be explicitly outlined. The CCK module comes with several sub-modules. One of which is “Content Permissions”. This enables site administrators to set permissions on a per-field basis. Unless your site absolutely needs per-field permissions, this is a no-brainer to disable.

The less permission checks your site has to run the better!

8 – Disable Database Logging

Again, another one that technically falls under tip 5, but I feel is especially important is disabling the database logging module. This module will log a wide variety of actions performed on the site to the database. If you’re the only administrator, this module’s usefulness is greatly reduced and should be turned off. Alternatively, you can enable the syslog module which ships with core instead. This will write the more technical log entries to the server’s standard log on the file system and save the database queries.

9 – Use a Third Party Comment System

This one isn’t necessarily Drupal specific, but an easy way to off-load quite a bit of processing on a popular site. Since Drupal’s caching system is far more effective when only serving to anonymous users, if the only reason you have user registration enabled is to allow them to write comments, you may consider off-loading that task to a free third party service like Intense Debate or Disqus. A small clip of javascript is all you need to include into your template (or include it via a block), to embed a robust comment system into your site. Also, if your visitors read other sites that use Intense Debate or Disqus and already have an account (or use OpenID), they’ll already have an account to comment on your site.

As of this writing, there is a published module to add Disqus support as well.

“With each Drupal implementation our team impresses me more,” says Fenix Founder Jennifer MacKinnon, “and this project was no exception. The speed and sophistication with which we can deploy an enterprise class environment, complete with a complex feature-set and numerous custom components is exciting and we are happy to be able to offer this level of service, quality and professional capability to our clients.”

“Gennum Corp is a great company and we have enjoyed working directly with their team to see Phase 1 of this initiative to completion. Our two teams worked hard, but more importantly worked well together, mutually ensuring the success of this project.”

Adds Leanne Labelle, co-Founder of Fenix Solutions “Open source solutions are being more and more widely accepted, particularly by large, and international, organizations. Companies seek us out because of our Drupal and open source experience, passion and capabilities. The benefits of open source solutions are compelling and we are seeing a noticeable shift in thinking, resulting in the demand for our kind of offering deployed on open source software. It’s exciting for us to be leading this charge.”

We tip our hat to the community at large and, on occasion, contribute some Drupal goodies ourselves!

See the new NHRC Web site.

There are many factors to consider when selecting a Content Management Solution. Obviously the first question you should be asking yourself is “do I need a content management solution?”

At the very least, if you have content that requires updating on a regular basis, then the answer is yes. And, with the emergence of Web 2.0, social marketing, online communities and online business automation, most of you are likely doing a whole lot more (or what to do a whole lot more) with your website than simple content updates. Choosing the right CMS can not only make the tedious task of publishing content to your website easier, it can also become the platform on which you can unify and integrate all aspects of your online business.

So, you need a CMS. Where to start? In order to make the right decision you have to consider a number of key criteria including what type of functionality you need both now and in future. Ask yourself the following questions to start:

What type of content will you be managing? Do you require dynamic content? (i.e. News, Events)
What type of site updates do you need to undertake routinely (content, layout)?
Is there user generated content? Does it require moderation? (i.e. Discussion Boards, Blogs)
Do you need to manage multiple databases? (i.e. product catalogs, mailing lists)
Do you need/want a blog, RSS feeds, e-newsletter, other social marketing tools?
Do you have an external database that you need to connect to?
Do you require a secure area for member/client access? (i.e. Extranet, Channel, Intranet)
Do you need personalized content?
Do you need to integrate forms/leads/data into a 3^rd party application (i.e. Sales Force)?
Do you need business automation?
Would you like to unify your web environments?
Do you need to manage an online community?

Once you’ve answered these questions, presumably you have scoped out what features/functionality you require from your CMS. If you’ve answered yes or maybe to most of these, then you no longer need only a CMS. You require a platform on which a CMS sits that is customized to allow for additional functionality (rarely does an “out-of –the-box” CMS do everything listed above).

The next set of questions helps you determine which type of content management solution is right for you. There are a number of different options available. We have categorized them into 4 types:

1) Single feature content management solution: these solutions are generally tailored to serve a very specific need – like publishing an image gallery, blog, podcast, forum, etc. (i.e. WordPress)

2) Off the Shelf solutions: a collection of functionality generally tailored to serve a particular industry. This category is wide and includes products that are inexpensive (i.e. Ektron, Marqui, Contribute) to more robust, but pricier products (RedDot, Sharepoint, Team Site). Proprietary solutions from individual web technology companies also fall into this category.

3) Open Source content management solution: Similar to “off the shelf”, but have the added benefit of low (or no) up front cost, and the ability to custom tailor the features and functionality (i.e. Drupal, Joomla, Plone)

4) Custom CMS solutions: commonly built on web application frameworks (such as Ruby on Rails, CakePHP, Django) and provide total flexibility since the application will be customized specifically for your organization. Obviously, these are the most cost intensive options.

Single purpose solutions are typically used when publishing a specific type of content. These solutions are typically used for blogs and give the user a WYSIWG through which they can update content and allows for content categorization as well. These solutions are typically low cost or free and are fairly easy to setup and maintain. A common pitfall with using these systems is that they operate in a silo – if you add more single purpose systems to your website down the line, they commonly don’t know how to talk to each other which often forces your users to remember multiple usernames and passwords to access the different sections of your website.

Off the shelf solutions can provide more features such as dynamic content, password protected areas, unique user content and more. These tends to be a great industry specific solution and are a good fit for small organizations that are looking for a dynamic website, a user friendly interface and do not expect to require more customized features. These tend to come with a monthly or annual fee and could require software installs on your organization’s network.