wpmuedudev
In response to some conversations we had at Open Ed, Andre Malan, with some help from Jimbo, has set up dev.wpmued.org. The site aggregates feeds of people doing development of Wordpress in education, including YOURS TRULY. Go subscribe! And participate! And read Andre’s post for some background!
Blackboard has a feature called Course Merge that lets instructors teaching more than one section of a course merge the sections into a single roster and course space. It turns out, though, that in Blackboard 8, if a professor has more than 25 or so courses alive in the system (which can easily happen when lab subsections of a large lecture course are listed separately), the Merge tool breaks. In particular, the list of courses to select as parent/child courses of the merge gets broken up into multiple pages. You’ve got to check the boxes next to the courses you want merged and hit Submit to complete the process. But (O! miracle of UI design) the Submit button only appears on the last page, making it impossible to merge courses on any pages but the very last one.
I’ll pause to say that this bug means that the people who most need to merge their courses – the ones who have big classes with lots of subsections – are the most likely to be unable to do so. Yikes.
So here’s an ugly but functional workaround. I’ve cobbled together the information in the HTML form element on the final step of the merge process into a single form. The value attributes in the input tags have be replaced with the unique identifiers for the classes to be merged, which you can find by viewing the source of the course list. You’ll also need to change the URL in the form tag to point to the absolute location of your Blackboard installation. Save the file to your local disk. As long as the HTML file is run in a browser that is logged into Blackboard as a user with the permission to do the merge, selecting the radio button and clicking submit on the local file will successfully submit the form and complete the merge.
Here’s the code:
[sourcecode language=”html”]
[/sourcecode]
Ding ding ding. Soup’s on. And by soup I mean version 0.2 of BuddyPressActivity, a MediaWiki extension I wrote.
Read more about it, and get the code, over at the CUNY Academic Commons dev blog.
On Thursday afternoon of this year’s Open Ed conference, a challenging contrast began to emerge between the approaches to student writing being espoused by the various speakers. First was Gardner Campbell and Jim Groom, who delivered a talk titled No Digital Facelifts: Thinking the Unthinkable About Open Educational Experiences. (This and other links go to Ustream recordings of the talks – they’re well worth your time, if you weren’t able to attend in person.) Gardner’s message echoed some of the familiar strains in Jim’s talk from the previous day, putting forth the idea that instead of herding students together into a single platform of our choosing, we should be giving them the tools and knowledge to be creators and curators of their own digital identity. (See this post at bavatuesdays for some of Jim’s thoughts on “a domain of one’s own”.) Gardner pushed this line of thinking a step further, suggesting that students literally become the sys admins of their own web space. Not only should students be able to move outside of the institutional platforms to develop their digital selves, the argument goes, but they should be free to choose and maintain whatever platform they’d like, without the different but perhaps equally cumbersome constraints of free/commercial platforms (like wordpress.com and others).
Now, before I start talking about where the tension arose, I should point out that while there’s something very right about this idea of Gardner’s, there’s something arbitrary about it as well. He suggests that we conceptualize something like cPanel as a meta-framework for the construction of identity. But why stop there? If cPanel > wordpress.com because of cPanel’s additional freedom to maneuver, doesn’t it follow that it’d be better to give each student a virtual machine with a bare OS on it? Or maybe for them to build their own kernel from assembly code, which would truly provide the most software freedom? The obvious reason is that at some point the tradeoff is no longer worth it: what you gain in freedom by dropping down a level of abstraction is not worth the extra effort you’d need to master the medium. And I’d argue that as time goes by, and software both advances to higher levels of abstraction from the raw code and at the same time becomes more useful, the calculus of determining the ideal level of abstraction is constantly in flux. To echo a discussion from this year’s THATCamp: while it might be the case that most students would benefit from learning some HTML and some basic programming today, it’s likely that there will come a point at which it’ll no longer worth the trouble; this, in much the same way that you don’t need to know assembly code to qualify as a computer geek (in most circles?!). A GUI like cPanel might be the right meta-framework for most students today, but we should constantly be reassessing this conclusion.
OK, so back to Thursday afternoon’s tension. The session following Gardner and Jim’s was led by John Maxwell and was titled Thinkubator: Wiki as CMS/LMS. (Actually, sandwiched between the two was a fricking awesome demo by Grant Potter of some work he’s doing with virtual worlds – but I’ll gloss over it for the purposes of this post.) John has been doing amazing things with the wiki, related to his research, to organizations he’s been involved with, and – most germane here – to his courses. He conceptualizes the wiki as a place where students – especially graduate students – learn to work in the way that scholars work. (John, I’m going to fill in some points you left unsaid here, so please tell me if I’m borking.) While it’s of course true that individual scholars maintain their own voices and perspectives, there is also a voice that emerges from a community of scholars who are writing about the same things, publishing in the same journals, editing and reviewing each other’s work, teaching in the same departments, etc. In one of the best one-liners of the conference, John pointed out that students get practice in developing this kind of communal space in kindergarten and in graduate seminars – but not in between. Multi-authored wikis are, by their very nature, communal spaces. Thus, when students do their work on a wiki, they are learning the sociology of group work and of their discipline at the same time that they’re learning the subject matter of the course.
So here’s the tension (which John himself articulates very clearly in his own reflection on the talk). The Campbell/Groom angle is that students are better served by stewarding their own spaces: emphasis on the individual voice. The Maxwell angle is that students learn about how scholarship functions by authoring together in a space like a wiki: emphasis on the communal voice.
There is a sense in which the tension might be fundamental, going to the heart of what we want our students gain from our classes. If the point of education is to shape students’ individual agency – to make them sys admins of their own souls (?) – then it makes perfect sense to make them sys admins of their online selves. If the point of education is to develop the next generation of scholars (or, if we want to take the point further, the next generation of society members), then the wiki approach might be more sensible. Insofar as there is a real conflict here, it might run even deeper than the purpose of education, but to the purpose of knowledge production itself: is it more important to foster and encourage each individual’s idiosyncratic “truth” scheme or our collective movement toward Truth?
From a practical point of view, the tension is probably not so stark. A student with a developed voice and identity is more likely to be able to step back and envision his or her place in communal spaces; and someone who is comfortable participating in shared knowledge development will be better equipped to develop his or her own particular point of view. But the contrast with respect to educational technology policy remains. A wiki setup like Maxwell’s is homogeneous and centralized, while the Campbell/Groom arrangement is various and distributed. I wonder how much of this is a technological accident, though, and to what extent the phenomenal qualities of Maxwell’s method can be superimposed on the Campbell/Groom architecture. What I mean, very roughly, is that we might envision a new generation of software whose underlying infrastructure is essentially distributed and customizable – respecting the agency of individual student-sysadmins – while communal spaces, rich with the versioning and community feature of wikis, can emerge at the higher levels of abstraction. I’m not smart enough to envision what this might look like in detail, but in theory it might preserve some of the educational advantages of each approach.
What do you think? Is there really a tension between the two approaches? Does the underlying technological model you choose for classroom work rule out certain rhetorical models, or does it just make some a little harder to attain?
A recent project of mine has been to improve the “Choose from the most popular tags” button that’s built into the Wordpress edit post screen. The default behavior is to find the most frequently used tags from the current blog. My goal is to add a link that lets you select from frequently used tags across the entire Wordpress MU installation. It’s an idea that Matt Gold gave me. Aside from being kind of gimmicky and neat, such a feature might facilitate the emergence of a more unified folksonomy in a community. In other words, the ability to see what tags other people are using for their posts makes it more likely that I’ll use the same tags that you use when we post about similar things. In this way, we can avoid having people tagging their posts “Wordpress”, “WP”, “Wrdprss” as if these were different things.
It looks like the developer of Simple Tags is going to be working this sort of functionality into an upcoming version, but it’s not nearly as fun to just use someone else’s version if you can hack one out yourself.
Sitewide Tag Suggestion
I got it working through a series of hacks and plugins. I’ll describe some of the details below, enough so that you should be able to get a similar setup on your own system. A caveat: I can only attest to the setup (I’ll call it Sitewide Tag Suggestions, or STS) on WPMU 2.8.2, the sandbox version I’m running. The only production version I’ve got access to – the CUNY Academic Commons – is running a version of 2.7. Between 2.7 and 2.8 there were pretty significant changes to the way that the admin AJAX works, and I haven’t yet figured out how to make these changes stick on 2.7. (Moreover, I’m wary of sinking a bunch of time into retrofitting an outdated version of WPMU.)
STS starts off with the plugin WordPress MU Sitewide Tags, which I blogged about recently. Conceptually, the idea is simple. Sitewide Tags creates a blog that aggregates all posts from across the installation. From the tags blog one can then collect tags that reflect all sitewide activity. To make STS work, then, one simply has to duplicate the core WP tag suggester, altering it to pull the most popular tags from the tags blog, rather than from the current blog.
I managed to get some of the key functionality into a standalone plugin. You can download the plugin here. A quick rundown of this plugin’s contents:
STS has two more parts, one of which could probably be moved into the plugin proper, and one of which probably has to remain a core hack. I’ll cover them in turn.
tagCloud2 sends an AJAX request to the server with the action name ‘get-tagcloud2’ (can you tell that there was a lot of cutting and pasting from the core?). The code for the AJAX response is put into wp-admin/admin-ajax.php. It’s basically a copy of the get-tagcloud function already in admin-ajax.php. That means you should copy everything between case 'get-tagcloud' : and break; roughly lines 568-600, making the following changes:
I am well aware that there are ways to add ajax responses in plugins, i.e. without hacking the core, but for the life of me I couldn’t get it to work. I imagine part of the problem is that back in tagCloud2, I’m replicating the core’s ajax syntax, while a plugin’s syntax has to be more explicit about where’s it’s sending its requests. (That’s what wp_ajax_ is for, I think.) So I’m chalking this one up to my own ineptitude and the fact that I have no idea how to work computers.
Finally, you’ve got to add some markup to the edit post page itself so that STS can actually be used. It’s possible of course to use WP’s hooks to add fields to the edit post page, but I really wanted to include the link right underneath the core “Choose from the most used tags” link. So I put the link in a core file, wp-admin/edit-form-advanced.php. Right after the code for the most used tags link, I added my own:
[sourcecode language=”php”]
[/sourcecode]
Be sure that each instance of tagcloud is changed to reflect the new ajax call (in my case, tagcloud2).
I think that STS has some potential to be really cool, especially if used in a community that is large enough for rich folksonomies to emerge. If you’ve got any suggestions about how to make it better, or how to fix any of my stupid errors, please don’t hesitate to leave a comment!
Inspired by some of the blog posts that have recently come through my reader on the topic of classroom blogging, I thought I’d throw my hat in the ring. In particular, I wanted to respond to some of the concerns raised in the comments to Mark Sample’s post regarding the “hub and spoke” method, where students maintain individual blogs that are linked through the teacher’s hub blog. Can this model work with a large number of students?
Over the course of several semesters using such a model in Intro to Philosophy and Intro to Ethics classes, I’ve hit on a couple of techniques that have made it easier to deal with somewhere between 60 and 70 students (from two sections of the same course) blogging roughly twice per week. Here are some thoughts, in no particular order.
Groups – On the right hand side of http://boonebgorges.wordpress.com, you’ll find a link to the blog of each student in the class. The links are organized into groups of five or six students each. The students’ first assignment at the beginning of the semester is to register for a wordpress.com blog and to email me its URL. As these URLs land in my inbox, I number them 1-7 (in sections of 35 or so students, seven seemed like the right number of groups). The blogroll is then split into groups, using Wordpress’s link categories.
In practice, the groups serve several purposes. First, membership in a group give individual students a more focused and manageable reading load. That’s because the syllabus requires students to read only the blog entries of their group members. As the semester progresses and students get to know each other, their blog reading (as evidenced by, among other things, the scope of their commenting) increases dramatically, but this is self-motivated rather than required. Second, focused groups mean that each student has a guaranteed audience. If all students were assigned to read all blogs, then only the most popular blogs (or those appearing first in an alphabetical list!) would get regular readers and commenters. Groups make sure things are more spread out. Third, dividing the class into blog groups provides ready-made groups for in-class work as well. I’ve found that the camaraderie that forms in a blog group (see these comments for an example of what I mean) translates very nicely into in-class work, and vice versa.
“In the blogs” and classroom integration – When my students first started blogging a few years ago, I would make a habit of finding a few posts that caught my eye before most class sessions to discuss with the class. Bringing the blogs to the center of the classroom experience does a couple of things: it highlights good student work (I try to talk about everyone’s blog at least once per term), it creates the impression that the blogs really are a crucial part of the class, it’s a good way to revisit issues that went either unexplained or underexplained in the previous session, and it makes future blog posts better when blog authors believe that their work might be discussed in class.
Since I was going through the process of picking out and making notes about interesting posts anyway, I figured I might as well make my notes available to students before class. So I started writing “In the blogs” posts, digests of what caught my eye that day, and a brief description of why. I’d generally try to post this at least twelve hours before the class session where the posts would be discussed. After a few weeks of doing this, I noticed that many students had actually read the posts that I blogged about (though I didn’t require it). Comment counts on those posts also tended to be a bit higher.
Near the beginning of the term, I deliberately overdid it with In the blogs, in order to give students the sense that the blogs were really significant intellectual spaces and important to the class. See, for example, digests from the beginning, the middle, and the end of the semester.
RSS and grading – The purpose of the blogs in these classes is to give the students a space for reflection that they take seriously (publicness does this) but that is low-stakes enough to allow for risk-taking and experimentation. Thus my pass-fail grading: if the blog post is on time, and demonstrates even a modicum of thought, you get full credit. The happy byproduct of this arrangement is that a close reading of every blog entry and comment is not necessary. Early in the semester I try to read every post relatively carefully and comment on most of them – largely so that I can model the kind of thoughtful but not-too-formal commenting that I’d like the students to adopt – but as the term progresses the community generally takes care of itself pretty well. By the end of the semester, I hunt and peck my way through the blogs at my leisure, much like the students do.
I used Google Reader to keep track of the students’ blogs, so that at the end of each blog grading period (every two or three weeks, I think), I could scan back through the feeds to see that they were on time. Comments work in a similar way: I subscribed to the comment feed of each blog, and at the end of every grading period would scroll through the comment feeds, keeping a tally of comment authors (this makes comment counting a bit more time-consuming than post counting).
Requiring such prolific blogging with so many students is not for the faint of heart (or, perhaps, for those with a 5-4 load), but I’ve found that some of these techniques – and especially the general rule that doing a lot of work early in the semester means that a self-sustaining community will develop – make the job much more manageable.
Open Ed 09 just ended, and I’ve got lots of things to blog about. Here’s a quick one that came out of a conversation that I had this morning with some of the guys from UBC’s Office of Learning Technologies (Enej, Michael, and Alex, if I’m remembering correctly).
The conversation started off as a show-off session of the different things we were doing with the combinations of WPMu, BuddyPress, MediaWiki, and so on. After some oohing and aahing (that’s what I was doing, at least), we turned to the question of why we – groups of people doing such complementary stuff – aren’t in better contact with each other. Finished, polished stuff is pretty easy to share, through outlets like the WordPress plugin pages. Only sharing the big stuff, though, means only helping each other a fraction of what we could. After all, things that have been formally released are bound not to need as much input from the community as unfinished, rough code. Moreover, arguably, our days are consumed as much by the small hacks and workarounds as they are by the big plugin projects.
cc licensed flickr photo shared by Stevie Rocco | Drinking this coffee got me giddy about sharing code
Communication about code is a hard thing. On one end of the spectrum is internal communication. The gang at OLT keeps internal notes of the small hacks they do on their system, as do we at the CUNY Academic Commons. On the other end is end-user documentation, meant for a broad and largely non-technical audience. The kind of communication that’s missing here is the stuff in the middle, between groups doing similar sorts of work.
What are some good ways to get this kind of sharing moving? What we’re trying to do at the Academic Commons is to keep a development blog. The success of this strategy is limited by a couple factors, though. First, other people have to know where the blog is, and add its feed to their readers, to glean any benefits. Second, a dev blog is only as good as what you post to it, and I for one have a real tendency to think that lots of things are simply too small to bother with. As a result, only the big things tend to get posted – but then we run up against the problem I mention above.
So here’s a rule that I’m setting for myself: If an issue/hack/workaround/patch/spitshine takes more than two hours for me to figure out, I’m going to blog about it. The more I put out there – even if I think that it’s not all that significant – the more likely someone else is to find it and make use of it.
Another BuddyPress plugin for you. This one makes sure that you don’t get multiple versions of the same comment in your activity streams when a comment is edited. Sounds like a small thing, but it was kind of a bear to program. Anyway, check it out at the CUNY Academic Commons Dev Blog.
Cross-posted at the CUNY Academic Commons Development blog
Sitewide Tags is a cool plugin by Donncha O Caoimh that pulls blog posts from all over a WordPress Multi-User installation – like the one here on the CUNY Academic Commons – into a supplementary catch-all blog. The power of this plugin is that, with all sitewide blog posts aggregated into one place, you can begin to see the kinds of topics and trends that emerge from the community of bloggers. More specifically, Sitewide Tags allows you to create a tag cloud that reflects blogging activity across the entire community. (See the tag cloud at Wordpress.com for a sense of what this looks like.)
I’ve got Sitewide Tags up and running here on the Commons – see our tag cloud (scroll down the page) and our aggregated blog. Getting things running seamlessly took a bit of tinkering though, and I thought it might be useful to share some of the tinkering here.
Read on for more of this (unexpectedly!) long process.
I just released an extension for MediaWiki that publishes wiki edits to the various activity streams native to BuddyPress. You can learn more about this bit of extreme coolness at the CUNY Academic Commons Dev Blog.
