Ready for our Social Software workshop for BCCampus

Brian managed to swing me an invite to co-host his Social Software session at the BCCampus Spring Workshop on Educational Technologies 2006, which will be held at North Island College in beautiful downtown Courtenay BC. (actually, I’ve never been to Courtenay/Comox, so am looking forward to seeing the area – I’m flying in on a Beech 1900D, so that leg of the trip should be interesting).

The session should be fun. Brian and I are going to demo a few concepts of social software (Web 2.0 *gack*) and then turn the reigns over to the participants. We’ll be using as the “hub” to bring together activities like tagging, bookmarking, blogging, and commenting. I really like the approach, especially with a concrete piece of the web bringing it together. It should make the freaky concepts of decentralized social aggregate tag clouds a bit easier to grok.

I spent some time this week pimping the instance of Drupal – opening up the tag clouds, tweaking a few bits here and there, so it should work really nicely as a platform for a workshop – as well as supporting the BCCampus community afterwards.

The tag cloud will be on centre stage for the workshop, so the participants can see how their contributions affect it (hopefully in quasi-realtime).

As always, I’m so totally looking forward to working with Brian (and his planted ringers). This should be a great workshop. I’m also really curious to see what the participants come up with…

Battle of the Drupal Rich Text Editors

This post was triggered by my need to use a few websites that are stuck in Drupal 4.6, and as such they have HTMLArea installed.

For Drupal, there are 3 options to choose from when shopping for a rich text editor to be used in content editing textareas.

  1. FCKEditor
  2. HTMLArea
  3. TinyMCE

Of the three, only TinyMCE has an official 4.7 compatible release.

The first two produce absolutely horrid markup. TinyMCE used to be as spectacularly invalid/nonsemantic as the others, but it’s received a LOT of love recently and its markup is actually pretty decent now.

HTMLArea produces brutal markup. Silly divs inserted for no apparent reason. Really crazy markup that I have to go in and clean up by hand if I want to make sure the code is tight and correct. That defeats the purpose of a rich text editor.

FCKEditor isn’t bad – when was still on Drupal 4.6, that’s what it used. The markup wasn’t hideous, but it wasn’t great either. It was slightly quirky to use, but it worked (mostly).

Then, was moved to our shared Drupal hosting environment, which runs Drupal 4.7 – FCKEditor wasn’t happy, so I dropped in the CVS build of TinyMCE.module. And the markup was much cleaner. And it integrated with Image.module. And a bunch of other nice stuff like providing a full screen editing mode.

None of them, however, cleanly “disable” themselves so I can get to raw code. Several “meta” pages on the sites have PHP code embedded, which is completely obliterated by the rich text editors. Even clicking the “disable rich text editing” link below the textarea isn’t enough because the source text has already been nuked by the javascripts used by the editor. So, I still have to make a round trip to “My Account”, edit it, and disable rich text editing for my account until those pages are edited. I’ve currently left it off by default, and call it into action by hitting the “enable rich text editing” link beneath the textarea. That makes it safe to edit any content in a site without worrying about clobbering stuff that isn’t grokked by the editor, while keeping the fancy schmancy WYSIWYG stuff just a single click away.

Flock is getting closer to Prime Time

I took another look at the current dev. build of Flock, and it’s definitely getting closer to a final release. The quality is noticably better than previous builds – I don’t get the spinning beachball of memory thrashing hell I got before.

There is only one nit I have left to pick with Flock. It’s got the best rich text editor of all of the standalone blog posting apps I’ve tried (and I’ve tried a LOT) – except for the lack of an ability to sort and/or filter categories for application to a post before publishing.

I have a LOT of categories on my blog – I use them more like tags than full-blown taxonomic categories – so reading through an apparently unsorted list of 300 tags can take much longer than writing the post took in the first place.

Once that’s taken care of, I can totally see myself living in Flock. I’m loving the Flickr integration, and the tie-in, and lots of other refinements. Great job, so far!

Camera Collecting

My folks handed down their collection of cameras that has grown on one of the shelves in their house. The collection included some really amazing (to me) cameras, which are completely removed from the digital compose-in-viewfinder-automatic-everything cameras that everyone has now.

The Camera Collection

The budding collection includes:

  • Kodak Vigilant Six – 16, with Verichrome Film
  • Zeiss Ikon Ikonta Kompur Rapid, with GE Lightmeter, both in leather cases
  • Toyoca mini camera, with original packaging, documentation, and leather case
  • Canon Canonet QL17 G-III QL, with flash and leather case
  • Six-20 Brownie
  • Braun Paxette Super II SL, with leather case
  • Sunpak GT3 Flash, in original packaging
  • Olympus Trip 35, in original packaging, with leather carrying pouch case

I have to do some Googling to find out more about these cameras. I absolutely love several of them – the Vigilant, Zeiss Ikon and Brownie are amazing. Actually, they're all amazing. The Canonet has a rangefinder built in. The Braun is incredibly detailed. They are all built like tanks.

I'll be checking out antique shops, garage sales, rummage sales, etc… to try to grow the collection. Now, to find a safe place to display it, without Evan "playing" with them…

Drupal Image Uploading

OK. I think I've just about gotten things closer to "feeling" right for me here. I was just fiddling with the Image and img_assist , and the drupalimage TinyMCE plugin, and finally got them all behaving as expected. Now, I can post an image to the blog while writing an entry, and it goes one step further than what WordPress did.

Drupal will create a completely independent "Image" content node, with full title/description/tag "metadata" and add it to an Image Gallery for later browsing and reuse. It's not just a file slapped in a folder on a server. It's a file slapped in a folder, with a bunch of supporting content and metadata to help organize it. That is so much more powerful/flexible than the straight "upload image" used by other blog apps.

So, I'm using the stock "Image" content type, with the "img_assist" module providing the upload service, and the "drupalimage" TinyMCE plugin providing a handy button right in the WYSIWYG editor to make it easy peasy to add images on the fly.

And, because it ties to the stock "Image" content type, I can also use things like the Image Publishing module to allow iPhoto to upload images directly to my copy(ies) of Drupal, for later use in blog posts and other content.

There are some minor wrinkles to iron out, then I'll roll it out to all of the Drupal sites we're running at work. Should be a handy way for our users to publish images – at least for the ones without Flickr accounts…

Screenshot of Drupal Image Upload: This is a screenshot of the Drupal img_assist image upload form, triggered by the drupalimage plugin for the TinyMCE module.Screenshot of Drupal Image Upload: This is a screenshot of the Drupal img_assist image upload form, triggered by the drupalimage plugin for the TinyMCE module.


Update: The HTMLArea module/editor has a similar image insert/upload utility. That one is even more streamlined, with less emphasis on creating a separate Image node (although that's what it does). Here's the HTMLArea utility, for comparison:

HTMLArea image insert/upload utility: A screenshot of the HTMLArea image insert/upload utility, taken from  - running Drupal 4.6

HTMLArea image insert/upload utility: A screenshot of the HTMLArea image insert/upload utility, taken from – running Drupal 4.6

Update 2: Looks like a bug in img_assist.module, which is adding some well-intentioned spans that are inadvertently borking image display on Mozilla browsers. By commenting out lines 1263 and 1287 of img_assist.module, everything appears to be hunky dory.