Archive for May, 2006
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 SocialLearning.ca 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 SocialLearning.ca 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 SocialLearning.ca 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…
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.
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 weblogs.ucalgary.ca 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, weblogs.ucalgary.ca 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.
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 del.icio.us tie-in, and lots of other refinements. Great job, so far!
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 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…
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.
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 SocialLearning.ca – 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.
I've been using a cheap mini tripod for a couple of years now. It's small enough that it can be attached to the carrying case for my little point-and-shoot, so I've always got it. I don't use it very often (maybe once a month?) but when I need a more stable shot, it sure comes in handy. It's always with me (well, with my camera) so I never have to say "Crap! I wish I had a little bendy tripod for this!"
Photodoto.com just posted a review of a beanbag tripod (a review of a beanbag?) and it sounds pretty handy. Basically, it's just the same as a normal beanbag, but with the addition of a standard tripod mounting bolt on the top to ensure the camera stays put. I'm not sure how much more useful it would be than the mini bendy tripod, but it would likely be better on uneven surfaces. It might be more of a pain to lug around though. At least it would be a handy projectile to get the attention of a potential subject…
One of the photos in their review shows how handy the beanbag might be. I'm pretty sure I couldn't bend my mini tripod enough to do this:
One of the big reasons I had for making the switch to Drupal is the great "Book" content type. It allows structuring of individual pages into a navigation hierarchy, and generates the "table of contents" and inter/page navigation automatically. I wanted to use it for writing longer articles, and wish I'd had it in place to use for the Interface 2006 ePortfolio background information article .
Initially, I wrote up the background article in a wiki, thinking it might be handy if others were able to edit. But, nobody has, and I think the article is less useful/usable as One Long Page Of Stuff. It would make more sense in smaller, bite-sized pieces that could be individually linked. Smaller granularity, allowing for reuse or something equally wishful.
So, to test out the waters, I just moved a copy of the Interface 2006 ePortfolio background article into a structured book here on my blog.
What's the difference between the two? The wiki page version is theoretically more "open" – others are able to edit it. The Drupal book version is theoretically more usable as a reference – easier to navigate and link to. It's also got comments enabled, so feedback is still pretty easy. Any thoughts on the two approaches?�
ePortfolio Software used in the Faculty of Education Master of Teaching ePortfolio pilot project
Other ePortfolio Software
- Apple iWeb (an extremely easy and powerful website authoring and publishing program which could be an effective part of an ePortfolio authoring system)
- Sample ePortfolio authored in Apple iWeb
- D'Arcy's "live" ePortfolio (blog posts tagged with "Noteworthy" – a blogfolio)
- Elgg (a combination of weblogging, e-portfolios, and social networking)
Related blog posts
- BCEdOnline "Unkeynote" Debriefing – an example of reflecting on, and critiquing a conference session.
- Portfolio vs. Dossier – a blog post describing the conceptional differences
- On Teaching Dossiers – a blog post describing "Teaching Dossiers" and how they are different from ePortfolios
Associations and Articles
- Open Source Portfolio Initiative The Open Source Portfolio Initiative is a group of individuals and organizations collaborating on the development of open source e-portfolio software.
- Educause e-Portfolio Library An extensive collection of papers, articles, PowerPoint presentations, resources, and examples of e-portfolios.
- The Electronic Portfolio Consortium The Electronic Portfolio Consortium is interested in the development of academic e-portfolio software systems and establishing standards for them.
- e-Portfolio Resources from Future Ed. Inc. A series of white papers on digital learning portfolios.
Photograph by D'Arcy Norman
ePortfolios are both individual and community activities. As individuals document their practice, they perform several internal processes to make sense of what they've done. But, these processes can be amplified if a community of peers (and/or mentors or "experts") is a key part of their ePortfolio process. By sharing reflection, and drawing on reflections and suggestions from a person's community of practice, it would be possible to more effectively understand what is being documented, and to better adapt as a result.
For the pilot project, we used Drupal to facilitate sharing of ePortfolios among members of the (small) community of practice. The software was configured such that individuals could determine who could see the content they published, so they could share personal reflections and comments without worrying about being exposed to the entire class (or the entire world, through Google).
Photograph by D'Arcy Norman
Each student (and professor) had their own weblog within the Drupal environment, where they could post any content they wished. If they categorized content as belonging to the "ePortfolio" taxonomy, it would be displayed in a central "ePortfolio" page. This was intended to foster discussion, reflection, review and positive criticism about a student's ePortfolio.
Students could also post content to their weblog that did not pertain directly to their ePortfolio. They could document classroom experiences, share lesson plans, ask questions, or just rant about classroom management challenges. As students shared and commented on the various weblog posts, they would be able to incorporate items from that process into their own ePortfolios, with the ePortfolio becoming a snapshot product of the community process.
Because ePortfolios are used to document and record an individual's practice, they have an archival nature. They form a "permanent record" of a person's activities and progress.
ePortfolios can also have a developmental nature, when the individual (and their peers) review an ePortfolio to create personal development plans, and to adapt future strategies as a result of the documented case studies presented within an ePortfolio.
Boxes in the Basement
Photograph by Penumbra
Pros:
- a personal content management system
- capable of storing nearly any form of medium.
Cons:
- out of sight, out of mind
- not exactly portable or sharable
Ongoing Notebook
Photograph by csb13
Pros:
- portable
- sharable (with small groups)
- easy to use
Cons:
- limited media types
- runs out of pages