This is a very long entry. Don't say I didn't warn you.
On both the videoblogging group and the Show in a Box (SIAB) working group the question of How do we best present video on the internet? has come up multiple times over the past 3-5 months. It is a vital question for the average videoblogger who wants to improve his or her site and especially for groups like Show in a Box which are trying to create software and designs that help present videos in their best light.
However, the discussions on those lists are mixing together three separate issues to answer the question of how to best present video on blogs. I will outline the three issues below and attempt to explain why it is important to solve these separately.
I have just updated the Embed QuickTime plugin that allows you to post QuickTime easily to webpages. The biggest change is that the plugin now comes with 'share' code giving your visitors Copy & Paste code for posting your videos to their own sites. Yes, like YouTube without the ugly Flash. Additionally the Metadata plugin is now included in the download and you no longer have to download it separately to start using the advanced settings.
The Drupal 6 module and the Wordpress plugin have been updated in the same go.
To celebrate I give you a birdie you can share:
Today I received an e-mail from a user of the Embed QuickTime plugin who was having problems embedding video streams from his Second Life music performances on his blog. Specifically, his stream was opening in the stand-alone QuickTime Player rather than being embedded. It turns out you can't directly embed a video stream. The solution was to create a reference movie pointing to the streaming video and embed the reference movie on the site.
A step by step guide:
The result will be a thumbnail on your website that flips into an embedded QuickTime playing the streaming video when clicked.
Yesterday I wrote my first ever Wordpress plugin and overall it was not a pleasant experience. I have been working almost daily with Drupal for a year now and there some things the Wordpress team can learn from the Drupal developers when it comes to helping newcomers.
Wordpress does have documentation for how to write a plugin, but it is very well hidden. I bookmarked it so I don't have have to hunt for it again. Using a wiki for all documentation of Wordpress may allow for a maximum of flexibility when writing, but Drupal's collection of "handbooks" makes for a more pleasant reading experience. Drupal's API reference also comes with 6 example modules that demonstrate different parts of the system. I used these extensively when I began developing for Drupal and I missed them for Wordpress and this is something I would strongly recommend that the Wordpress community creates.
My plugin had to do two things. First it had to insert two javascript files whenever a blog post is being shown, secondly it had to insert a code generator on the page where you write new blog posts. Wordpress' way of handling both of these seem clunky and hack-ish compared to Drupal (I did make the exact same plugin as a Drupal module earlier this month).
In both scenarios you insert markup directly onto the page. In the former case by using the wp_head hook to insert the <script> elements, unlike Drupal that has functions included specifically for inserting javascript and CSS. Not a great problem in a simple plugin, but a potential annoyance when you can never be sure that your javascript file is only included once.
The latter caused more frustrations. Wordpress handles changes to the Write page in the same way—you insert raw HTML onto the page. I found it next to impossible to make the look and feel of my added HTML match whatever else was on that page. This is especially true when you use an admin theme that is not Wordpress' default one. I was able to make my code generator match the default Wordpress admin look, but then it does not look very good on Brittany's blog where she uses a different admin theme. On the other hand Drupal has a powerful Form API used to manipulate all HTML forms. For my Drupal module I simply used that to add my form elements. Using the API ensures that my form will always match the current theme, no matter what that is.
I am sure it is a deliberate decision from the Wordpress developers to have plugin developers insert their raw HTML everywhere instead of having built-in functions and APIs. The learning curve is not as steep and there is more immediate flexibility. However at the same time it becomes harder for users to evaluate the code in a given plugin—it is simply harder to decipher how a plugin does what it does and that's a Bad Thing. At the end of the day it's a matter of trade-offs and I strongly prefers Drupal's approach, even if it takes slightly longer to learn how to get started (at the very least because Drupal has excellent documentation to get me started).
There is however no excuse for Wordpress' disorganized documentation. Drupal's API reference is built directly from the comments in the code and in conjunction with the handbooks the result is a very thorough documentation. The code base in Wordpress has only a fraction of the code comments and I imagine that would make it impossible to make a “Wordpress API Reference”. This is sorely needed as many of the functions are undocumented.
After making my Embed QuickTime jQuery plugin into a Drupal module I've continued and translated it into a Wordpress plugin. As the Drupal module it has these features:
Go ahead and download the plugin. Install it by unzipping the file and uploading the folder to your wp-content/plugins folder. Activate it on the Plugins page and you should now see the code generator when you go to write a blogpost. The plugin has only been tested with Wordpress 2.3.1 and the default theme.
This is the personal website of Andreas Haugstrup Pedersen: commentary on media, communication, culture and technology. Read more»