The Legal Department

Tag: edtech

Today I migrated Blogs@Baruch, the 10k user WordPress installation I manage, to a new server. Our previous server was unable to handle the system’s activity. We had been in a Jumpbox environment, which our colleagues at the Baruch Computing and Technology Center had directed us towards a few years back out of concerns about the resources available to manage a LAMP stack alongside the dozens of other virtual environments the school manages. Problem was, Jumpbox only supports 32-bit lamp environments, which max out at 4 gb of ram… simply not enough for the amount of traffic and usage that we get, especially given the propensity of certain processes in WordPress to eat up a ton of ram. We were getting to the point where the server needed to be rebooted almost daily over the past month in order to clear out processes that were locking things up. My comrade-in-arms Tom Harbison and I were on constant alert, interrupting family dinners, story time with our children, and, most horrifyingly, college basketball games to get the site back online and verify that no damage had been done. As a colleague told me, “that’s just no way to live.”

Moving to a more robust server became necessary if our system was going to continue to grow and evolve in response to community need, which is becoming ever more intense. We began discussions in mid-winter about where we’d move Blogs@Baruch. Our choices were to host externally, perhaps with Cast Iron Coding (where our cousin UMW Blogs is hosted) or with a host like Softlayer (where another CUNY WordPress install is hosted); or to ask BCTC to build and deploy a new server for us. Both decisions were feasible, yet both had costs and benefits. Hosting outside would give us total control over the environment, though at a monetary cost that might be difficult to maintain down the road. It would also require making outside systems interact with CUNY systems… let’s just say that has been a problem in the past. Hosting at the College would get us in-house support, but also make us dependent upon an IT department which has a specific set of pressures upon it to keep the systems of the college running, to be responsive to the needs of users here and also the demands of CUNY central administration.

In the end, we decided to continue to host Blogs@Baruch at the College, for a few reasons. The most important is that Mikhail Gershovich, Tom and I very much see this project and the others at CUNY like it as efforts not only to foster certain pedagogical and communicative opportunities for members of our community, but also as tools in a larger battle to push our university and others in a particular direction in their approaches to supporting educational and information technology. It may very well have been easier to go to outside hosting: we could have moved more swiftly, wouldn’t have had to address the same security concerns, and could have bypassed bureaucracy altogether. But if one of our goals is to encourage the broader adoption of free and open source software within higher education, then taking the easy way through risks limiting the potential impact of our experiment. I’m proud that our College values this project and has given it support in tough economic times. That support isn’t only monetary, but also the valuable and highly in-demand time of our CIO Arthur Downing and his staff at BCTC. This project is as much theirs as ours, a point they’ve articulated through their support for this migration. We think the extent to which the system is homegrown adds to its vitality, and makes it a strong model for what open university publishing platforms can be with just a few of the right people saying “yes.”

It’s fitting that this migration happened on the Day of the Digital Humanities, when many of my colleagues at the intersection of humanities and technology across the world are sharing details and reflections about their workdays. In the course of my week — often in the course of a day — I visit classes and help students with projects, consult with faculty about assignment and course design, oversee the work and writing of graduate student fellows, build WordPress themes, research plugins, help develop programs and workshops, speak with staff members about their use of social media, advise projects elsewhere at CUNY, and occasionally write, present, or teach a class. Through this all, I must make sure the platform that propels much of my work remains viable and growing. This last bit is the least familiar to me of my tasks: though I administer a system I’m no system administrator, and I often need help. It’s ultimately much easier for me to call Phil or John or Patrick in the building next door than to dig through forums or to push my friends and connections for free advice (or to get on their calendars for the paid version).

Managing a platform like this has complicated my understandings of both university information technology and open source software deployment. Yes, much of the fetishization of security in IT comes from a fear of litigation, from uncertainty and doubt about the motives of users, and from a proprietary mindset that weighs the cost and risk of every moving bit. We should push back against that culture. But security isn’t always only about these things; it’s also about ensuring the stability, functionality, and sustainability of a system so that its users can reap the most benefits. That sometimes may mean denying users the ability to do certain things on the system, or at least channeling them into a process that helps them do those things in a way that doesn’t risk compromising stability (especially if they’re expecting and relying upon stability). Conversely, it also means going to bat for users with the powers that be and expanding a system’s capabilities so that we can all ultimately do more.

So, that’s where we are with Blogs@Baruch: we’ve just expanded the system’s capability so that it can do what it already does better and faster, and so that we can see if it can also do some new things. It’s also where I am in my work as an educational technologist: mediating between the growing needs of an exploding community of users and the capabilities and demands of an institutional structure that sometimes gets us and sometimes doesn’t. And it’s where I am in my thinking as a digital humanist: wondering every day how emerging technologies are helping and forcing us to rethink the work — all of the work– that we do in the university.

I recently completed a significant upgrade to Blogs@Baruch, and I thought I’d blog my hacks and some of the thinking behind them for teh Google to index.

The goal of the upgrade was to get BuddyPress up and running, which will create additional avenues for social publishing and networking around academic interests across the College. The upgrade included two new WordPress child themes, one that uses bp-default (for the home site and all BuddyPress functionality) and one that uses TwentyTen (a new default theme).

if ( is_user_logged_in() )

Since we’re rolling BuddyPress into a system that’s been active for almost two years already, and which has more than four thousand users, I was hesitant to just automatically give everybody public profiles or to make the member list publicly visible. The following simple argument came in very handy in these cases:

<?php if ( is_user_logged_in() ) : ?>
<?php else : ?>
<?php endif; ?>

I snaked this code through functions in a number of places:

in header of the BP child theme to hide the Members list (by excluding the page id for the Members page in the “else” statement)

I also hide the BP admin bar for logged out users (which is an option built into BP)… So if you’re a visitor to the site, BuddyPress won’t be visible to you.

Logged out:

Logged in:

This is the way we’re going to keep it for now, and I think such a structure reflects our sense of BuddyPress primarily as a tool for the community to get to know itself a little better. Rumor has it that some more granular privacy control will be coming down the pike in future versions of BuddyPress, and we’ll revisit this issue as appropriate.

bp-custom.php etc.

Every BuddyPress install should have a bp-custom.php file located in wp-content/plugins/ which houses customizations. I used this file to change the order of the tabs on Profile pages, and to insert additional menus on the BuddyPress admin bar.

One of the great challenges I’ve had is the fact that one of my good buddies and partners in pizza-eating crime has become one of the top BuddyPress/WordPress developers around, and Boone’s on my IM rolls. I’m often faced with the dilemma of taking an hour to figure something out, or bothering him and getting some code in about 3 minutes. He helped me with code for the tab order:

And, with Boone’s help, I made a change to my wp-config.php file so that Profile (rather than the Activity Stream) became the default component loaded when you visited a member’s page. (I located this line of code just beneath the “/* That’s all, stop editing! Happy blogging. */” comment, as it didn’t work when I put it at the end of the wp-config.php file).

These changes are intended to prioritize Profiles. We want our users to share information about themselves and to use Boone’s Custom Profile Filters to connect with others at the College with similar interests. While the CUNY Academic Commons, for which that plugin was written, hopes to connect CUNYs across campuses, we want do this on a more local scale. When all of our incoming students get their Blogs@Baruch accounts next week, they will be asked to fill out their profiles and to begin exploring.

New Default Theme

I also used the upgrade opportunity to create a new default theme for sites created on Blogs@Baruch, a child of TwentyTen which features some Baruch College and CUNY branding/linking and altered css. Aided by this tutorial, I swapped out the built-in header images that ship with TwentyTen for images taken from Baruch College’s library of photographs. Here’s the code for that, placed into the theme’s functions.php file:

This new theme is sharper than what previously loaded, and TwentyTen is customizable enough that I think a lot of our users will just keep it as their primary theme.

Bye Bye Userthemes

Finally, I’ve done away Userthemes on Blogs@Baruch. The last two WP upgrades have required hacks to keep the plugin only half-working (I’ve never been able to turn off Userthemes on blogs… once you go Userthemes you’ll never go back!). It’s such an important part of what we do on the system that I wanted to cease relying on such an unstable plugin. Instead, with Tom Harbison’s help, we copied all of our custom themes into the theme library and renamed their folders to the site id for which they were intended. We didn’t activate these themes site wide, but rather went one by one through the blogs, editing the template, stylesheet, and theme settings for each. Not the perfect solution, but it feels more stable than relying on Userthemes.

Those are the hacks that I remember. I’m sure there are a few that I missed.

Jim Groom and Brian Lamb recently asked me and some of my fellow CUNYs to reflect on how we’ve “designed or conceptualized” the publishing platforms we oversee, with a focus on the role of networked collaboration in public higher education. The question is a big one, and it spurred me to think about the roots of my work as an educational technologist, an #alt-ac that emerged for me rather incidentally out of the work I was doing while training to become a historian at the CUNY Graduate Center, and which has led to Blogs@Baruch.

See, a myth is out there that one day the Reverend Jim Groom wandered into the University of Mary Washington from the wilds and revolutionized open source university-based personal publishing when he launched UMWBlogs in 2007. But this is only part of the story. Jim cut his teeth as an educational technologist in the same accidental way I did; we were both graduate students preparing for traditional academic careers. Our paths converged in 2004 when we met as Instructional Technology Fellows at the CUNY Honors College (which is now the Macaulay Honors College). I had already worked for four years at the New Media Lab, with the American Social History Project/Center for Media and Learning, building Virtual New York City, and had taught history at Baruch. My work with ASHP taught me much about collaboration and the power and necessity of networks when doing new kinds of intellectual work in a discipline, and my teaching at Baruch had introduced me to the challenges and rewards of teaching at a public institution with an incredibly diverse and unique student body. Even before doing work as an instructional technologist, then, I had learned the catalytic value of connective networks and the pedagogical rewards of working in a “non-traditional” classroom setting.

As ITFs (a group of graduate students who are now overseen by the great Joseph Ugoretz, who unfortunately came on-board after Jim and I had moved on) our job was to work with faculty members who were teaching in the College’s core curriculum to make smart use of the laptops every student was given by integrating technology into pedagogy and cross-campus events. As Fellows, we met every couple of weeks to discuss our work and share ideas, and while many Fellows saw these meetings as a burdensome distraction from their much more important doctoral work, I always saw in them an opportunity to think collaboratively through methods and pedagogies that were in circulation but were not very present throughout much of CUNY. Those exchanges with Jim, Zach Davis, Jeff Drouin, Wendy Williams, Emily Pugh and others were very much the foundation of the work I’m now doing. They helped shape my sense that teaching with technology was about exploring and embracing new possibilities rather than reinforcing existing structures. They showed me that there was as much to learn from breaking down and reflecting upon the processes by which we produce knowledge as there was in using technology to engage deeply with content. They sharpened my understanding of experiential learning, and got me to focus more on nurturing sustained engagement than meeting the heavy coverage that’s always expected of teachers of history. They also taught me that doing this kind of work while in constant conversation with others is really the only way to do it, for if you’re doing it right you should be raising more questions than you’re answering. Many spaces in higher education — especially those that revolve around making sense and use of new technologies — would benefit from increased dialogue, reflection, and collaboration. Being part of a network that exists within and beyond our home institutions foregrounds those qualities in our work.

I remember the specific ITF meeting in Spring 2005 where Jim shared a maps project he had done on WordPress with a class at Hunter College, and excitedly riffed on the pedagogical possibilities of self-publishing on the open web. It wasn’t until that Summer when I started to play with WordPress on my own that I saw what had gotten him so excited. I’ve mused before that the edtech revolution started not in the classroom, but in the baby blogosphere. In February 2005, Zach Davis and his wife launched a blog (using Movable Type, if I recall correctly) about their young daughter; in March 2005, Jim and Mikhail Gershovich launched blogs to document the lives of their young sons; I followed suit a couple of months later with my own baby blog. I can’t speak for the other blogfathers, but in my case blogging about my child served multiple purposes: it was a needed distraction from my dissertation research that also pleased far-away grandparents; it spurred me to explore presenting a wide range of media online; and it lulled me into my first tentative steps towards real hacking. I knew HTML and CSS and had built sites using Dreamweaver and Fireworks and Flash, but I was no hacker and was never much interested in code. But by blogging and making movies and art about my child I came to see more clearly the power of the lowered barriers to self-publishing provided by a software like WordPress. And that I was doing this in concert with other like-minded academic geek dads made me feel as though my efforts were part of some larger trajectory.

By Fall 2005, I was ready to roll WordPress into my support for courses. I had worked for two years with a faculty member, Roz Bernstein, whose pedagogy was proto-edupunk in that she always required her students, after studying a particular art form, to produce work of their own in that form. We had previously done a project where students crafted PowerPoint presentations inspired by the movie Capturing the Friedmans about their own families, and the students had come up with some fantastic creative work (work that I still use today to challenge arguments that there’s no such thing as a good PowerPoint). So when her students were studying collage, they were tasked with making collages of their own and to write about their creations. We scanned the collages and shared them along with the notes via a WordPress blog. This process opened up second and third layers of dialogue, as students commented on each others’ work asynchronously and then reflected upon the process in classroom discussions (including a memorable discussion of what was gained and loss by the process of digitization). I’ve often said that Baruch students are among the most interesting college students in the world, and none of them realize this. Their stories are so rich and varied that assignments which urge them to mine their pasts to find the raw materials with which to create and reflect are invariably rewarding. Maker assignments done here that encourage students to bring what they already know to what they’re learning are successful time and time again.

After a few additional projects at the Honors College I joined the Bernard L. Schwartz Communication Institute in 2006 as a CUNY Writing Fellow. Mikhail, the Director of the Institute (who I had first learned of through his baby blog), wanted to bolster support for “computer-mediated instruction,” and had talked me into leaving the Honors College. The opportunity to see what could be accomplished with these tools in a non-honors setting appealed to me, as did the opportunity to get experience with WAC/WID theory. Finally, I was interested in seeing if we could expand support for open-source applications at the College. Mikhail gave me the freedom to develop some faculty development initiatives around teaching with blogs, and we ultimately supported 10-12 different course blogs per semester (on single installations of WordPress) between Fall 2006 and Spring 2008. We worked with English, Law, Sociology, Anthropology, and Journalism course, and we did everything from small, project-based assignments, to research paper scaffolding, to collaborative research using a wiki, to creating a news blog of student reporting about New York. And I started blogging about my work at Cac.ophony.org.

Those two years of work as a Writing Fellow, while I was finishing my dissertation, really drove home the extent to which we were working on something that was new to our campus and University, something that was needed because it connected the intellectual/academic work that students were doing in school with the digital literacy that they were developing only outside of the curriculum, and which they would need wherever their careers took them. I continued to stay in touch with Jim and learned from the way he distilled his network through a political and pedagogical prism to which I was sympathetic, a perspective which had in-part been forged by professional experiences at CUNY supporting teaching, learning, and scholarship with technology. I followed with great interest as his experimentation led to UMWBlogs, and discussed with Mikhail the opportunity to systematize and scale up what we had been doing up until then only on a piecemeal basis.

Blogs@Baruch evolved out of these discussions, and has very much depended upon the interplay between a broader network of teachers, learners and scholars out on the interwebs and the unique community we continue to engage with at Baruch College. A significant part of my job is to mediate this interplay, to bring ideas and inspiration mined from my expanding network and to try find a place for them within the curriculum at Baruch, and to then to share back my reflections on the results. We’re getting ready to roll BuddyPress out on Blogs@Baruch this Fall. Our goal in doing so is to congeal a platform that already has more than 4000 users into an academic publishing network. We hope doing this will make more explicit the fundamental fact that what’s happening on small corners of our system is connected both to other developments around this school and around CUNY, and also to a broader community within higher education of people finding their footing on the open web, and using that footing to launch themselves forward. Baruch students and faculty have much to learn from these connections, and also much to give.

I’m preparing to roll BuddyPress out on Blogs@Baruch later this month, and I’ve grown a little concerned about the implications of doing so. I thought I’d write up some of my concerns and see if the Internets has anything wise to say about them.

Our goal in using BuddyPress is to try to draw out and congeal an academic publishing network out of the various work that’s being done across the system. We hope to give students a platform to track their work over their careers at the College, to make connections with students with similar interests, and to cultivate a profile in a space they’re somewhat familiar with that we can support and that they can build as they desire. But I’m anxious about a few things.

First, we already have more than four thousand users on Blogs@Baruch, and the vast majority of those accounts were created for course-based blogging. I’m uneasy about turning on profile pages for users who never used the system for that purpose, without their knowledge. My current plan is to send an email out to all users when we turn on BP with instructions about granular control of profile pages. But, as far as I know, that control can only be so granular: with BuddyPress Profile Privacy you can set privacy on a field-by-field basis, but you can’t lock a whole profile page down. I’m hoping Jeff Sayre’s Privacy Component, which apparently is nearing a second beta, can help solve this problem. We’ll be registering incoming first year students for Freshman Seminar and instructing them on how to use the system beginning in August, and we’ll keep Profile pages set to “open” for new users from that point forward (we’ll be updating our woeful Terms of Service as well). I think it might make sense though to lock-down already existing accounts and outreach to those users with details about BuddyPress’s purpose and instructions on how to manage their profile privacy. I’m uncertain about this, though, both the ethics and how I’d manage this technically.

Second, I’d like for the primary engine of Blogs@Baruch to continue to be course-based blogging. BuddyPress, however, elevates the social networking function to equivalence with the blogging functionality of a WP-MS installation. We’re not building ePortfolios like our friends at Macaulay and don’t have the resources to closely support the development of profiles on a system as big as ours. And I certainly want to avoid the creepy treehouse factor, which is an issue with incoming Freshman. I just want students to use BuddyPress@Baruch to connect with each other around interests and academic work. So there are a few spots where I’d like to make some choices or changes that could nurture that understanding; for instance, I don’t think I’ll have a link to the members directory from the front page (but have it publicly accessible via internal links); I’ll hide the BuddyPress admin bar for logged out users; and, I’d like to hack BuddyPress so that upon log in, instead of landing at the front page of the home blog, users land at the Dashboard for their primary blog. Any other ideas?

Third, I have to revisit our registration process. In most classes, we use DDImportUsers to bulk register new users. Our most technologically capable faculty members can handle the intimidating two-step of a “self-registration” and the addition of Andre Malan’s “Add User to Blog” widget. Now, with BuddyPress functionality turned on, registration can become more complicated and require more information, which is fine for self-registering users but potentially problematic for those who are bulk-added. The bulk process also only creates new accounts, which I’ve been struggling with for some time; existing users need to be added to new sites individually, and to do so you need both a username and an email address (if I had my druthers, the DDImportUsers plugin would be able to check a list of newusernames|newemailaddress against the user_email field in the wp_users table and if a email address exists, add the user with that address to the individual site… and then to go on to register all the new users).

As the system grows, this is becoming a bigger problem since every semester a higher percentage of Baruch students have accounts on the system and find their way into new classes that use it. In an older version of WPMu you were able to add users to individual blogs simply with an email address, which was preferable because the cross-referencing is a pain. But that pain is balanced on the other side by the agita that would be caused if nervous first-time blogfessors are made to manage a multi-step registration process. In the past, I’ve taken the pain on in exchange for the benefit of drawing more users onto the system, and it’s been a good trade. I’m not sure yet how BuddyPress fits into this equation and how it will impact my overarching goal of easing the registration process, but wanted to get the issue out there. In the long term we’re looking at LDAP integration, but we’re not there yet. One solution is BP Group Blogs; but that creates additional steps in the registration process and we still want to make things as sleek and streamlined as possible.

These are my concerns for now, and I’m sure there’ll be more to come… any feedback, questions, and exchanges from out there in the wild are welcome and greatly appreciated.