Yesterday I gave a presentation for the Sakai working group on authoring about the work we've been doing on Widgets. I'm including it here as its got some more of the technical details.

I think a major implication of widgets is that it challenges the idea of writing tools as plugins just for one platform (e.g. Moodle, or Sakai) rather than as generic widgets usable in any "container", which can include personal as well as institutionally-offered web spaces. For example, a Moodle course can include things like a chat, voting, and forum widget - which you can then drag off into your personal site.

Perhaps make your own personal "dashboard" out of the widgets you've taken from several different courses you are participating in, originally offered in different LMS's by different organisations.

I'm off to Maastricht next week to take part in a workshop on mashup personal learning environments (MUPPLE) as part of the EC-TEL conference. I'll be presenting a demo of some work we've been doing on integrating widgets into various platforms.

I'll post a link to the paper when I get back, but in the meantime, here is a screenshot to give you an idea of what I'll be showing: spot the Apple Dashboard widgets in this Elgg 1.0 installation!

This is all possible at least partly through the efforts of W3C in coming up with a common Widget specification, but also through many modern platforms such as Elgg, Wordpress and Moodle having a "Widget" concept in their plugin architecture that makes embedding of other bits of web far easier. The combination of these factors made building a generic widget server technology that can serve widgets from existing platforms such as Dashboard, Sidebar, Konfabulator (etc.) into web environments feasible.

We've also extended the widget spec, and enabled stateful collaborative widgets, like the "Natter" synchronous chat widget you see in the image. With no special server-side coding whatsoever - its all Javascript and AJAX calls to standard widget service methods and events.

After MUPPLE I'll be at IMS in Birmingham, quite possibly for a repeat performance, but this time showing this technology being combined with learning design sequences.

More information on MUPPLE here.

Image courtesy of Looking for Fish tacos at ELI 2006, aka CogDog.

Well, I have finally gotten a free minute to get this all down, and get it down I will in hopes that I can drum up some help and support in working through a couple of the issues we’re having with FeedWordPress. So, here goes my state of the union address for FeedWordPress syndicating student work to class blogs on UMW Blogs….

First, FeedWordPress is the real deal, it is a solid interface, not too complicated, works out-of-the-box without cron plugins, and makes syndication a breeze. (D’Arcy overviews it beautifully here). Combine this simple syndication with all the tag and category feeds made available by Donncha’s Sitewide Tags plugin and you got the goods, EDUGLU-o-rama! As the great Mara Scanlon said after we demonstrated the power of FeedWordPress for her Ethics and Literature course today, “This is getting so much easier!” And that it is, she suffered through the days of BDP RSS and the untold issues with WP-Autoblog last year with character and fortitude, and her recognizing this afternoon that the syndication angle is coming together was a morale boost, for she doesn’t compliment ed tech stuff often or lightly.

So, I’m really excited. I can see some real potential and power here, we have over 15 classes using some version of FeedWordPress syndication, and for the most part it works seamlessly, enter one feed for a class tag, and the course blog populates itself, aggregating the student blog posts tagged accordingly. All is good….well, almost good.

Here are some of the issues we have run up against in the last week, in order of gravity:

1) For a few classes we are actually feeding the posts in with comments turned off and the permalink sending the reader back to the original blog. This works well when the feed is first syndicated in FeedWordPress. However, after that the subsequent posts that are pulled in link within the course blog, the permalink no longer send the reader back to the original post on the student’s blog. This sucks! This was a way to allow posts to aggregate in one place, but lead the rest of the class back to the student’s space, particularly useful if the class is subscribing to the course blog feed, for all the feeds will immediately take the reader to the student’s blog, a way to aggregate feeds from a variety of sites off one feed (a kind of tag specific OPML feed for class sites). So, this one is major, and it ain’t working as of now

2) This may be related to number one, but for several feeds that I click on that have been aggregated via FeedWordPress I get the following error:

Fatal error: Call to undefined function wp_insert_category() in /home/umwblogs/public_html/wp-content/mu-plugins/sitewide-tags.php on line 120

Making me think there may be a correlation between the FeedWordpress issues and the Sitewide Tags plugin. Anyone experience anything similar to this?

3) After FeedWordPress is activated and up and running, if you try and create a Link (just a plain old link in the Write–>Link tab) it actually creates a new, malformed feed in FeedWordPress. Bizarre. This doesn’t necessarily hurt anything that I know of, and I stress that I know of.

4) FeedWordPress doesn’t pull in tags from syndicated posts. Not a huge deal for us right now, but it would be useful.

5) The creation of categories from syndicated posts doesn’t work out-of-the-box. You have to actually update the rss-functions.php and rss.php files using the two they provide in the MagpieRSS Upgrade folder that comes with the FeedWordPres plugin (thanks for pointing this out, D’Arcy).

Ok, that’s it. I’m gonna post a modified version of this on the WPMu forums as well to see if anyone knows anything. The plugin author, Charles Johnson, seems to have been busy with other things and hasn’t upgraded his plugin for WP/Mu 2.6+, and frankly the guys built it out and supported it brilliantly. And once your plugin becomes popular, it must seem like as much as a burden as a service to constantly update and maintain it, I’ve seen it happen with a number of good syndication plugins which makes me nervous. We need to support these folks, and help them develop it out, or contribute accordingly.

So, there it is. FeedWordPress is about as close as we’ve come to realizing the syndication bus in major way, mad props to Andre Malan for turning me onto it again at Norther Voice this past February, and if anyone has any ideas for making it work a bit more consistently don’t be shy.

Oh yeah, one more thing.

The BDP RSS widget Andre Malan created for allowing people to add their feeds to a site via BDP RSS would make even more sense these days for FeedWordPress.

I have been mentioning DSader a lot lately on this blog, and that’s mainly because I have been deep into WordPress Multi-User mode for a couple of weeks now. And between the upgrade to 2.6 and the general overhaul of plugins, themes, etc., I find I’ve devoted no insignificant amount of time to plugin hunting –a truly enjoyable activity. For many of my most valuable WPMu plugins, I continually find I am utilizing DSader’s work. He wrote the following plugins that I can name off the top of my head: Userthemes (a must), Sitewide “Three-in-One” Multi Widget panel, Toggle Admin Menus Sitewide, and the indispensable More Privacy Options, to name a few.

So, there is no question DSader has been a veritable mensch when it comes to sharing with the WPMu community, and I’d like to say thanks. But before I even can he comes out with an updated version of his Sitewide Comment Tracking plugin for WPMu that reminds me just how deeply indebted I am to his work. If you haven’t tested it, I highly recommend it. It tracks the comments you have left on numerous blogs within the WPMu community. So, for example, If I leave comments on various blogs, I can track them from the Comments–>My Comments tab. It provides an awesome interface to quickly scan where you’ve commented and who has responded, an amazingly powerful feature for a controlled, yet deeply distributed architecture like WPMu.

Here’s what it looks like:

DSader's My Recent Comments plugin for WPMu

Think about it, this is an amazing way to let faculty and students know how they can track response to their comments easily, something which isn’t all that easy in the regular blogosphere. So an engineered improvement to make the community potentially more manageable.  And so many of DSader’s plugins are just like that, it’s as if he were programming for UMW, he comes from an educational setting and it’s amazing how many of our needs and desires are met and satisfied by his work

Update: While writing this I received an email from him telling me the Sitewide 3-in-1 Widget panel has been updated, with a bug or two fixed, Is DSader sick or what? What can I say, it’s people like him that make this whole thing so much funner and cooler. Thank you, thank you, thank you!!!

UMW Blogs has got a brand new bag, with no small assistance from Andy “EDU” Rush nation who turned me on to the beautiful theme PrimePress (Andy’s the go to theme guy without a question), along with Serena Epstein an Jerry Slezak who provided the gorgeous header images of the UMW campus. The redesign took a couple of days with some on and off work, and before I get into the details of that, I wanted to take a quick poll. PrimePress offers you two different looks, and I wanted to know which one people preferred.

Here is UMW Blogs with the gray background:

And here it is with the white background:

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Now for the anatomy of the redesign of UMW Blogs. I have to say that a year ago this time I had spent many a long hour trying to get everything working on the front page of UMW Blogs. I blogged the process for creating the front page here, and talked extensively about the elaborate hack to get sitewide tags and a sitwewide archive here.

This time around, my life was significantly easier, and I think that’s a testament to how far the WPMu community has come over the last year. It never ceases to amaze me how folks like Donncha, D Sader, andrea_r, Andre Malan, and Enej Bajgoric, amongst many, many others, have made the creation of a state of the art publishing platform for Mary Washington elegant, simple, and powerful as hell. So, it’s people that have little or nothing to do with UMW that have enabled truly cutting edge publishing possibilities for little money and even less programming know how.

The Home Page

The homepage for the redesign really captures just how much easier things have become, and also point to some necessary re-aligning of plugins, resources, and syndication. For example, the previous version of UMW Blogs front page was almost entirely driven by the BDP RSS plugin for aggregation, in this iteration it has all but disappeared. I am keenly aware that the developer for this awesome plugin hasn’t updated it in over a year, and while it still works swimmingly in version 2.6 (a testament of the solid coding), I’m not sure how much long it can hold out, and I’m afraid its time to move on. That’s were two plugins I have already blogged about recently have allowed me to move on with little or no separation anxiety: Donncha’s Sitewide Tags plugin and D Sader’s “3-in-1″ widget.

Between these two plugins I can have the 10 most recent posts, a sitewide tag cloud, and an archive in my front page sidebar (these features would have been impossible for me last year, and now it is as two plugins and a customizable widget). Moreover, Donncha’s Sitewide Tag goodness powers, the Recent Posts, Tags, and Archives pages of UMW Blogs that I will get to in more detail below.

As I mentioned already, PrimePress is the theme, and the header images are homegrown.  The login is a little bit of PHP code Patrick Murray-John whipped up, and you can download it here and drop it into your sidebar should you need it.

Finally, the blog for the UMW Blogs homepage blog will be the site we use for the feature articles that chronicle and share the activity, cool blogs, and course projects that are happening throughout the UMW community.

Courses, Support, and Contact Pages

The Courses page is pretty straightforward, and it is going to be a directory of courses being hosted on UMW Blogs, and it will be up nd running by Monday.  I have some idea of how I am going to feed this stuff in, but for the most part it will be relatively traditional directory of courses being taught around campus using this publishing platform, but I have some more thinking to do here–any recommendations?

The Support pages are awesome, and this marks for me one of the most significant leaps forward over the last year. namely, the Bliki has arrived people! And that is thanks to the awesome work of Brian Lamb’s UBC rat pack of developers like Andre Malan and Enej Bajgoric. The are working on integrating MediaWiki and WPMu as a kind of symbiotic distributed publishing framework, which Brian talked about in a screencast here. The fruit of this syndication rich framework has made my life a million times easier thank to Enej’s plugin Wiki Inc, which basically take an article from a MediaWIki installation and republishes it seanlessly on a WordPress page.  So all the documentation for UMW Blogs done in MediaWiki can now effortlessly be pulled into a page on the home blog for UMW Blogs. So the pages for support like the FAQ, WordPress Guide, and “10 Ideas for Using UMW Blogs” are all MediaWiki articles posing as blog pages—bliki bling bling!

Wiki Inc Plugin for WordPress

And then there is the Embed MediaWiki Sections plugin that allows you to copy and paste a section of a wiki article into a blog post or page, kinda like YouTube embedding for MediaWiki content. I played with this one a bit earlier this Summer, but haven’t got back to it yet.  Not sure if all the bugs are out, but I’m convinced this  will make things insanely interesting for the holy grail of the Bliki, which is just another name for a distributed publishing framework that can be collaborative, simple, and polished all at the same time.

The Contact page is the Dagon Design Secure Form Mailer plugin inserted in a page, simple, secure, and customizable.

News, Sitewide Tags, and Archives

The the News tab on the Front page links to the UMW News Blog, which is actually a separate blog from the home blog  http://news.umwblogs.org) which gives it its own feed, and a separate way to pull in the RSS feed in the home page sidebar. The trick to making it integrate seamlessly is just dressing it up in the same theme with the same widgets and hacked the navigation menu to match that on the homepage of UMW Blogs. Simple.

The Sitewide Tags tab also links out to another blog, which is actual the blog which is automatically created through Donncha’s Sitewide Feeds plugin I mentioned earlier. This site changes the game in my mind, and it provides everything from sitewide posts, tags, categories, and archives in one fell swoop. It rules, and I simply dressed this site up in the same theme as the home page, and hacked the navigation menu accordingly.  Moreover, if you go to the front page of the tags.umwblogs.org blog you’ll see th most recent post, which on the front page has been substituted with featured blogs. The Tags tab is just a page on the tags.umwblogs.org blog that has a Simple Tags tag cloud running, which will by default collect all the tags from around UMW Blogs, as well as provide a working feed for each tag (major possibilities here!).

The Sitewide Archives tab does much of the same thing, but this is just using a hacked version of the archive template for PrimePress that will allow people to search all of UWM Blogs, see posts archived by month (or day or year), as well as the last 100 posts that have come through the system.

And voila! That’s it! All the hacking and kludging I had to do last year has been replaced by clean and elegant solutions that make this years model a step up indeed.  We couldn;t have done it without the community, so a big thanks to all of you making WPMu about as bitchin a publishing engine as I’ve seen.

Now, the semester is poised to start, and it’s time to make this baby sing with 1500 new blogs.  Let’s get ‘em!

I have been meaning to use David Benini’s Plugins List plugin (I love plugins about plugins–the meta-plugin!) which simply allows you to include a list of all the plugins you are using on your site. Simple, yet potentially very useful for others, and a way to give a shout out for all the hardworking folks out there who are truly responsible for making WordPress as great as it is (yep, I’m creeping back to the state of ecstatic fanboy!).

And while it won’t list the MultiUser plugins running on the bava, it will list all the standard plugins, and that may help some of you upgrading to WPMu 2.6 get an idea of what will fly, for all of these have been tested and work well with the beta 1 of WPMu 2.6. As you will probably notice, I don’t use all of these plugins, but many of them are also for UMW Blogs testing, as you can see UMW Blogs is the real deal! We don’t half step when it comes to plugins! Whose better than UMW Blogs, name me one blogging service…just one, damn it!!!

• 404 Notifier (v. 1.2a ) by Alex King.
• Add RSS (v. 1.5 ) by Dan Cameron.
• aggr (v. 1.1 ) by Carlo Perassi.
• Akismet (v. 2.1.6 ) by Matt Mullenweg.
• BBpress Latest Discussions (v. 0.9 ) by Atsutane Shirane.
• BDP RSS Aggregator (v. 0.6.2 ) by Bryan Palmer (bryan@ozpolitics.info).
• BDP RSS Aggregator Widgets (v. 0.0.1 ) by Bryan Palmer (bryan@ozpolitics.info).
• BM Custom Login (v. 1.3 ) by Ben Gillbanks.
• cforms (v. 8.5.2 ) by Oliver Seidel.
• Code Markup (v. 1.3 ) by Bennett McElwee.
• Dagon Design Form Mailer (v. 5.33 ) by Dagon Design.
• Daiko's Video Widget (v. 2.0.7 ) by Rune Fjellheim.
• DivShare Uploader (v. 1.0 ) by DivShare.
• Easy Admin Color Schemes (v. 2.4 ) by James Dimick.
• Exec-PHP (v. 4.8 ) by Sören Weber.
• FeedWordPress (v. 0.993 ) by Charles Johnson.
• FireStats (v. 1.4.0-dev ) by Omry Yadan.
• Flickr Photo Gallery (v. 0.98.2 ) by Joe Tan.
• flickrRSS (v. 4.0 ) by Dave Kellam.
• Google Maps Quicktag (v. 1.0.1 ) by Daniel Denk.
• Inline Tag Thing (v. 1.2 ) by Christine From The Internet.
• Last.fm widget - New style (v. 1.0 ) by James Wilson.
• Netflix (v. 3.0 ) by Albert Banks.
• Netflix Widget (v. 1.0 ) by Chris Stanley.
• Photo Dropper (v. 1.0.5 ) by Photodropper.
• Plugins list (v. 0.2.01 ) by Davide Benini.
• podPress (v. 8.8 ) by Dan Kuykendall (Seek3r).
• Quotes Collection (v. 1.1.4 ) by Srini G.
• RichComments! (v. 0.1 ) by Stefano Verna.
• Samsarin PHP Widget (v. 1.3.2 ) by Chris Pettitt.
• Search Everything (v. 4.7 ) by Dan Cameron.
• ShareThis (v. 2.1 ) by ShareThis and Crowd Favorite (crowdfavorite.com).
• Sidebar Add to BDP Widget (v. 1.1 ) by Andre Malan.
• Sidebar Author Registration. (v. 1.1 ) by D. Sader.
• Simple Forum (v. 2.1 ) by Andy Staines.
• SimplePie for Wordpress (v. 1.2 ) by Ryan Parman and Geoffrey Sneddon.
• Simple Tagging (v. 1.7 ) by Amaury BALMER.
• Simple Tags (v. 1.5.7 ) by Amaury BALMER.
• Spam Karma 2 (v. 2.2 r3 ) by dr Dave.
• Subscribe2 (v. 4.8 ) by Matthew Robinson.
• Subscribe2 Debug (v. 4.8 ) by Matthew Robinson.
• Subscribe2 Uninstaller (v. 4.8 ) by Matthew Robinson.
• Subscribe To Comments (v. 2.1.2 ) by Mark Jaquith.
• TagThis (v. 0.9.2 ) by Anirudh Sanjeev.
• The Author Description Widget (v. 1.0 ) by Mohammed Suleiman Khan.
• Theme Switcher (v. 0.5 ) by Ryan Boren.
• Top Level Categories (v. 1.0.1 ) by Filipe Fortes.
• Twitter Tools (v. 1.2b1 ) by Alex King.
• Viper's Video Quicktags (v. 5.4.4 ) by Viper007Bond.
• WordPress.com Stats (v. 1.2.2 ) by Andy Skelton.
• WordPress Database Backup (v. 1.7 ) by Scott Merrill.
• WordPress Mobile Edition (v. 2.1a ) by Alex King.
• wordTube (v. 1.60 ) by Alex Rabe & Alakhnor.
• WP-Autoblog (v. 1.0 ) by Elliott Back.
• WP-Cron (v. 1.3 ) by Scott Merrill.
• WP-FLV (v. 0.2 ) by Roel Meurders.
• WP-o-Matic (v. 1.0RC4-6 ) by Guillermo Rauch.
• WP-Polls (v. 2.31 ) by Lester 'GaMerZ' Chan.
• WP-Polls Widget (v. 2.31 ) by Lester 'GaMerZ' Chan.
• WP-PostRatings (v. 1.31 ) by Lester 'GaMerZ' Chan.
• WP-PostRatings Widget (v. 1.31 ) by Lester 'GaMerZ' Chan.
• WP-Sticky (v. 1.31 ) by Lester 'GaMerZ' Chan.
• WP 2.3 Related Posts (v. 0.51 ) by Denis,PaoPao.
• WP Ajax Edit Comments (v. 2.1.1.3 ) by Ronald Huereca.
• wpLicense (v. 0.9 ) by Nathan R. Yergler .
• Yahoo! Shortcuts (Beta) (v. 0.962 ) by Crowd Favorite and the Yahoo! Shortcuts Team.
• Youtube Favorites Plugin/Widget (v. 1.0 ) by Ozh.

ShareThis

This post will detail how to create an aggregator site wherein people can simply add their feeds to a site and have their content automatically re-published. This example is specifically for WordPress and/or WordPress Multi-User. It depends upon three plugins, so download them ahead of time from the links below:

1) Oz Politics’s BDP RSS Aggregator

2) Andre Malan’s Add RSS extension widget for BDP RSS

3) Charles Johnson’s Feed WordPress plugin

Here’s how (and note that all the images below link to larger versions for your viewing pleasure):

Setting up BDP RSS

First you need to install, activate and setup the aggregator plugin BDP RSS. I will leave the installation and activation of this plugin to you, because it is the same as installing any other. However, the setup may benefit from some detailing. Once you have installed and activated BDP RSS, go to the Manage tab and find and click on the RSS Feeds subtab. You will then be taken to the space for managing feeds with this plugin. Which will look like the following:

This is pretty straighforward, you add feeds here, and poll them to pull all the newst conenct (which happens automatically based on the time you set). Andre Malan’s Add RSS Extension for BDP RSS actually automates this process from the front page of the blog, but more on this shortly.

If you scroll down a bit, you will be taken to the “Output formats” section of this page, this is where you control the output of the feeds you are aggregating, and this is the portion of this plugin that needs some explaining.

Once a number of feeds have been added, click on the edit button of the output formats (of which you can have several, but for this functionality you will only use one output format with the id 1). Once you click on the edit button you will be taken to a configuration page with a lot of options that can be overwhelming, so let’s take a look at them in some detail:

Here is where you an name the output format and decide how you want the aggregated feeds to be listed, whether chronologically, alphabetically, etc. Additionally, You have the choice to select only certain feeds, or to list all feeds, for truly automating this function so you don;t have to keep coming back to this page, I would just leave the radio box checked with the default of “List all sites.” After this you will see a series of other options below for how many post, how characters to display, in addition to other settings. The XHTML formatting for list presentation shown below is for custom formatting, but I never mess with this.

The XHTML tags to retain in this re-posting is something I do use, and you can see the options I select below:

After this, you get to a series of custom options for archiving, caching, or creating a feed of your aggregated feeds (an OPML feed). I will ignore the archiving and caching options, and focus on the “RSS feed from list” option you will need to create a feed of your feeds. Also, they don’t make this clear, but once you create an overarching feed, it will have the following url:

http://yourdomain.org/?bdprssfeed=1 (with the number being the ID of the Output format)

For example, the feed of all the aggregated posts on Reading Capital would be as follows:

http://readingcapital.org/?bdprssfeed=1

After you check the box for allowing an RSS feed to be provided for the list, then you can save your changes and you should be done with setting up BDP RSS.

Setting Up FeedWordPress

Now that we have set up BDP RSS, we can now install and activate FeedWordPress, which will actually syndicate the feeds that are being added into BDP RSS. The setup for this will actually take the feed for the list of feeds we created in BDP RSS, and simply republish these feeds within, for this example, Reading Capital. So, for our example, take http://readingcapital.org/?bdprssfeed=1 and go to the Syndicate tab in your WordPress backend.

You add the url for the feed (http://readingcapital.org/?bdprssfeed=1) in the “Add new syndicated site” text field, and click on the syndicate button, which will then test and preview the feed to make sure it works, after that click on the “Use this feed” button.

Once you have done this, you need to set up the publishing options for the feed under the Syndication–>Options tab. Below are the settings I am using, you have numerous choces, and you can choose what works for you, but I prefer to turn off comments on the aggregation site, and make the permalink link back to the original post on the author’s blog.

Once you have set these options and saved them, you need to go back to the main syndication page, check the radio box of your feed, and click on “Update Checked Links” –which is you follow my settings in the Options above will happen automatically from now on.

3) Allowing Users to Add their RSS feeds from the Front page

Finally, install Andre Malan Add RSS extension plugin for BDP RSS (follow his instructions for installation) and go to the design–>Widgets section of your backend, and drag the widget into the sidebar. After that, as people add their feed on the front page of your blog, it will automatically be inserted into the BDP RSS list of feeds, which i turn will be run through FeedWordPress and re-published on the blog. Genius? Yeah, it is, isn’t it! And it’s all Andre Malan, so kudos to him!

Share This

So, in an attempt to galvanize my mania to its most chaotically productive for Faculty Academy 2008, I’ll go on with this e-portfolio madness, as promised. However, the comments on part 1 are already making me wonder whether this post shouldn’t be written by D’Arcy, Chris, Phaedral, or Cole (or perhaps all of them)?

That acknowledged, I want to particularly note Chris and Phaedral’s comments about the importance of each individual controlling the sequential nature of their portfolio, giving them full control over this nuanced space for extensive creativity, expression, and order. I couldn’t agree with either of them more, and hopefully some of what I suggest below will point in that direction, but by no means put to rest the challenges and demands of such important caveats, and one can only hope for meaningful serendipity.

Ok, no more backsliding, avanti! The examples below will be centered around the work we have been doing at UMW with WordPress Multi-User (much of what I discus below can surely be done with Drupal and Movable Type —and probably several other applications I don’t know about), but this is my blog and I ain’t going to talk about those hippie applications anymore, ya hear?

Good.

An Example of a blogfolio?

Robert Lynne, a graduating Art major at UMW, will be my example for this post. I hope he can forgive me constantly harassing him, but his blogfolio (to quote D’Arcy) is a model of at least one way you can imagine the portfolio logic working. Rob has used his blog for several classes, an Art History course, an Art Studio course, a Sculpture course, as well as a Poetry Workshop course. He has had his blog for the 2007/2008 academic year, and the space demonstrates some of the questions of creative control, sequence, and serendipity that I mentioned earlier in regards to Chris and Phaedral’s concerns.

In his blogfolio he chronicled his trip to NYC, helped shape a manifesto, blogged for classes, sang songs, and even had time to heckle yours truly. All of this was an on-going stream of ideas and thoughts that framed a process, being an art major he also had a lot of completed work to present to his audience, and this is where the use of pages on his blog became the space for what many might understand as a more traditional portfolio. He has a page dedicated to his paintings, sculptures, final thesis presentation, as well as a more focused about page. In these pages he controls the sequence, presentation, and obviously decides what goes in and what is left out. The space captures a fascinating part of both his creative process and experience throughout the year, but italso quickly became a space for him to represent the products of that process. He controls his space, he can delete my comments, delete his blog, or export the contents and take them somewhere else. In fact, there is no reason why he couldn’t have done all of this on Blogger or WordPress.com. That said, I think the major reason he started it (but it probably was not the logic that ultimately drove it) was the fact that he was asked to blog for at least three different courses this academic year. Not all of which were in his discipline. I think the major reason his work branched out beyond the classes was that there was an audience, the UMW culture encouraged it, and he found it useful (at least to some degree) to frame his work and experience.

The Name of the Game is Spam-like Aggregation

The reason why blogs can be understood as more powerful, dynamic, and complex portfolio system is because of their Houdini like RSS ability. It really all revolves around the syndication infrastructure which makes all the difference, it affords flexibility, dispels the myth of a monolithic system, and allow for the more complex levels of filtering of content I will outline below. But for a portfolio system to work (and I think I feel the term portfolio falling apart right about now but bear with me) it has to be more than that. It has to be a space where people post there ideas for class, react to topics more informally, add resources about various issues they are thinking through (course related or not), and frame the academic work that they are amassing through their career as learners more generally. This is not a technological issue at all, this is a cultural one, and we have begun to see the beginnings of this at UMW (Roblog being an excellent example), but it is by no means ubiquitous, and there is much, much work to be done in terms of fostering the community to think about these elements together in a more orchestrated fashion.

One of the things about blogs more generally that have made this cultural leap a bit easier is that they are excellent at pulling together all the various online spaces a person may occupy and they are inherently open. Both of which allow for updates from Twitter or Facebook; embedding videos from YouTube or images from Flickr; providing extensibility for a wide range of multimedia and traditional site design. All of which forms a platform that is inviting for its protean ability to incorporate various media and one’s distributed presence into one, simple space. This is key, and it is beautifully illustrated by an imagie engineered by Tom Woodward, which once I am able to annoy him enough to post it will be below as a big, beautiful illustration of this profound point, but geared to all you visual learners.
[ Imagine an image of an Octopus here with many loosely joined Web 2.0 tools ]

So, while Roblog is an excellent example, how does this make sense across a larger campus, and can you create both a culture and harness a simple enough technology process so that Roblog (and hundreds of other students) can easily blog for three or even six different courses during the year, while at the same keep it all on spaces they control yet share it as need be with the appropriate class. That is where the questions of filtering, aggregation, and a little bit of spam-blogging emerge.

Let me outline how this might at our current stage of development.

Thanks To Andre Malan’s widgets BDP RSS Add Feed and Add Sidebar User, it is getting simpler all the time, but we still have to make a couple of more jumps. I’ll outline them all below.

Leap of faith, I’m a professor and I ask my 25 student to get blogs (whether on UMW Blogs or elsewhere, it doesn’t matter) and once the do to come back to my course blog and add their RSS feeds. This is made easy with Andre’s Add Feed widget, for I can easily limit who adds a feed by the blogging community. So, once the student set up their space they can drop the feed in in the text field on the sidebar. Easy enough. But wha if they are using their blog for three diferent classes, a film hobby, and to document their Buffy the Vampire Slayer obsession? Well, then they could do one of two things, create a category for my class on their blog, lets call it bmoviemania, and if they are using WordPress (not sure how other blogging platforms handle category feeds) they can just add the RSS feed for that category like so:

http://myblog.com/category/bmoviemania/feed

Thereafter, everything they category as bmoviemania will be fed out to the course blog, keeping their Buffy posts and biology labs out of the b movie class blog (thanks goodness!). They could also do the same thing with a tag on wordpress, it would look like this:

http://myblog.com/tag/bmoviemania/feed

Now, we have a pretty straightforward method of taking these student blogs post for a specific course category or tag, and feeding them into an aggregated course blog. Now how does the aggregated course blog work? Well, it is much easier than it was a semester ago, but there is a little more automation that we need. (Warning: It gets a bit technical for the next few lines! But this information is not essential to the overall logic, so don’t let it throw you off, it is me calling or help ) The feed, once entered by the student, is immediately fed into the BDPRSS aggregator, this would need to be activated and the widget in the sidebar as soon as the professor creates this blog (any ideas Andre?).

Moreover, all the feeds that are fed into the BDP RSS aggregator would then have to be treated as an overall OPML which in turn is placed in the FeedWordPress plugin which actually taking all the posts from the respective student blogs and post them on this course blog (with the permalink pointing back to the students blog). Another automation needs to occur here, FeedWordPress needs to be automatically populated with the OPML feed from BDP RSS: http://bmoviecourse.com?bdprssfeed=1 The suffix will always be the same for this code, but the log domain, depending on the course will change.

So, save for two small bits of automation, we have a self-service aggregated course blog for aggregation, that allows all of the students responses, interaction, and posts to remain within their own space, while still capturing the logic of the course. A beautiful example of this is Gardner Campbell’s Rock/Soul Progressive course from Spring 2008. One additional benefit would be an automatically generated blogroll from the list of students who entered their feed, possibly drawn from the URLs in BDP RSS.

Sorry for the programmistan talk, I hope feedistan isn’t reading, but the larger point is that individuals now have their own space that they can grab the feed for, and even drill down and determine a feed for any given class with tags or categories, and then add it to a course aggregated blog.

But why all the talk about course blogs and aggregated such and such when this is about portfilios? Well, because I believe that this process is part and parcel of the archive/raw material that will ultimately populate this portolio. And as we saw with Roblog, the process is often just as relevant and important as the “product.” This is also where the importance of community and the push for students to have their own space and create within their own Personal Learning Environment (their I said it), but alow it to be fed and captured within an aggregated course blog navigates liminal space between the increasingly irrelevant LMSs, and the free-for-all hippie PLEs

Also, think about what just happened with the course blog for a second. What was outlined there is now the basis of a publishing framework for an individual’s portfolio that pulls from his/her blog archive of posts and class materials in a way that, like the course blog, they have the option to further tag or categorize the work in their personal archives that deal with all sorts of subjects, topics, experiences, and projects from their experience, and allow them to feed it into a site that reflects them in some way outside of the more conventional ideas of a blog (this would be available for UMW Bloggers and those who self-hosted—not free, hosted solutions like wp.com, Blogger, etc.). Now some might be saying but why? The blog is them? And Roblog is an excellent example of this, so I don’t necessarily disagree, yet the overarching archie blog may not be where they want to frame their work as a photographer, present lab work, field work, films, music, poetry, or business case study. The idea here is that anyone can choose how the fed out the relevant categories, that let’s say are tagged with portfolio, and these spaces become more elegant and malleable presentation spaces for for particalar elements of their work wherein they control the sequence, aestheitc, and in many ways the experience of the visitor.

In many ways the is the aggregation/syndication infrastructure brought down to the human scale. yet, if you have students adding feeds to course blogs, why couldn’t they do the same to directories, aggregated discipline channels, a Blogging platform hompage, or what have you. The fact that the syndication architecture is brought down to the atomic level of the individual, makes for the power of the site to scale more globally. More than that, the community will have a good sense of what it is they are doing and why!

I’ll end here because it’s three am, and a man’s gotta sleep, but sometime tomorrow look for part 3 of This ain’t yo mama’s e-portfolio

Featuring: Biology Lab portfolios at UMW & an experiment with an English course using portfolios for anonymous assessment? Who knew?

Share This

Matt Kane resurfaced on Bristol’s underscore mailing list  with this intriguing snippet, after some travels around the middle-east: ” … discovered N95s (not mine) cannot be taken into Syria”.

I asked for the backstory, which goes like this:

Quite a palaver. Got the train from Istanbul to Syria (amazing trip!). At the border they didn’t search the bags of “westerners” but asked us all to show our phones and cameras. They glanced at them all quickly, checking the brand (”Nikon, ok. SonyEricsson, ok”). One guy had an N95 and they led him off the train. His sister informed us that they’d said it wasn’t allowed in Syria, and that if she knew her brother he’d not give it up without a fight. Despite being on contract, he argued with them for an hour and a half, even calling the embassies in Damascus and Ankara. In the end he gave it up, with a promise that they’d send it on to the airport from where he was leaving. A few days later we’re chatting with a barman and spot his phone - an N95, and yes, he got it in Syria! A few days after that we found out the full story from our hotel owner in Damascus. Apparently the CIA gave a load of bugged N95s to high-ranking Kurdish officials in Iraq, many of which were then smuggled into Syria and given as gifts to various shady characters. After the Hezbollah guy was assassinated in Damascus a few months ago, the Syrians set about trying to root out spies, which led to this ban on bringing N95s into the country. Apparently.

This is the first I’ve heard of it, but searching throws up a few references to rigged N95s as “spy phones”.

Somewhat-unrelated aside: I don’t believe the relevant functionality is exposed in the N95’s widget APIs yet. I had trouble making it vibrate, let alone self-destruct after this message. But at least widget/gadget/app security is getting some attention lately. It can’t be too long before “spy widgets” on your phone become a real concern, particularly since the exposure of phone APIs to 3rd party apps is such a creative combination. I should be clear that AFAIK, Nokia’s N95 widget platform is free of such vulnerabilities currently, and any “spy phone” mischief so far has been achieved through other kinds of interference. But it does make me glad to see a Widgets 1.0: Digital Signature spec moving along at W3C…

This week sees another milestone in W3C's effort to standardize the use of Widgets across platforms with the release of the Widgets v1.0 working draft documents. The specification aims to offer a single way of creating and distributing widgets on a range of platforms.

The current scope of the W3C work is set out in the Requirements document. W3C defines Widgets simply as:

mall client-side Web applications for displaying and updating remote data, that are packaged in a way to allow a single download and installation on a client machine, mobile phone, or mobile Internet device. Typical examples of widgets include clocks, CPU gauges, sticky notes, battery-life indicators, games, and those that make use of Web services, like weather forecasters, news readers, email checkers, photo albums and currency converters.

Another document, the Widget Landscape sets out the lay of the land in terms of what Widget platforms are out there, and how they approach the different aspects of Widget functionality.

The specification is targeting platforms such as Apple Dashboard, Microsoft Sidebar, Yahoo! Konfabulator, and mobile platforms such as WidSets. Web widgets, such as Google Gadgets, are not currently in scope, although when you dig into the details of the specification, its obvious that web widgets can potentially be developed in a similar manner.

After requirements, the first specification document is Packaging and Configuration which defines the zip-based format used to package the content of a Widget, the structure of the XML configuration document that goes inside it, and other aspects such as discovery and internationalization.

A surprising omission at this stage is the API specification. All Widget container platforms supply an API, typically accessed via JavaScript, that offers the Widget a way of storing and retrieving preferences, calling remote services, and executing various kinds of commands. Presumably this will be released next; currently there is only an Editor's Draft of "APIs and Events". Currently a developer of a Widget needs to make different API calls based on where the Widget is deployed to do very basic things like save and retrieve user settings.

Another aspect of a Widget API is extended features, especially in the case of web Widgets. The Google OpenSocial API is an example of an extended Widget API - in this case to enable Widgets to access things like friends lists and status information. Another is the widget collaboration API we developed here as part of our EU TenCompetence project, that enable things like activity-based chat and voting widgets to be developed using the draft W3C specification. (More on that in another post sometime).

Overall I think there is some great work going on in this W3C group, with a very practical focus that is based on taking a consensus view of "what is" rather than a more purist "what should be" approach (which has characterised some of the W3C's other recent work). I hope that once this spec is finalized the focus will move onto taking a similar approach to web widgets, for which there is an even more pressing need for interoperability. Our own work has shown that, with a few minor modifications (e.g. the addition to the API of a proxy method for safe tunneling of external Web API calls around cross-site script access restrictions), exactly the same model of packaging, manifest and API can also work within a web framework.

For more information on this and related activities, also check out the rest of the Web Application Formats Working Group pages.