Drupal For Universities Consortium — Interested? Come to the table!

As initially stated in an earlier post — https://btopro.wordpress.com/2009/06/07/how-to-follow-with-such-incredible-momentum/ — there is growing interest for Drupal in Higher Education and a body of some kind to help with the direction we all take.  The goal of a Consortium (as I see it) isn’t to create a physical product, cost money, or resources in order to get going.  I see the point of such a body is to create a set of standards for how Drupal can and should be deployed in Higher Education.  I’ve deemed the group Drupal for Universities instead of Drupal in Higher Education because of the unique scenarios that we all face in the University sector as a result of our scale and scope.  This isn’t to say that College’s can’t join in, it’s just that the focus will be steered by Larger Universities with a collection of Colleges.

Here are some groups that have expressed interest thus far and I hope to talk to in greater detail with — Arizona State , BYU, Madison Wisconsin, SUNY Empire, PSU (duh).  I also know of several other big schools that are using Drupal who I think would be great to talk to in more detail including VT, MSU, MIT, PIT, CMU just to name a few.  Now is the time to organize and I think some virtual sessions along with the occasional physical one could be of huge benefit to us all.  Currently, there are user groups at many universities which all need to mobilize and get everyone talking about what they’re doing locally.  Here’s some common trends to universities that I think we can standardize on via Drupal:

  • Webroot or Drupal folder organized similarly to how we’ve got things — all virtual, pointing to either a drupal5, drupal6, or drupal7 folder.  This way we can support more then one Drupal version while looking like they’re all coming from the same place (/courses/abc123 — is drupal5 while /courses/new456 — is drupal6)
  • Common Infrastructure starting at Drupal6 with a Virtual Hosting environment not being required but definitely facilitating resource sharing.
  • One site that is capable of scaling and controlling the other sites within that setup (hopefully with expanded functionality to what we currently have available)
  • Naming conventions and best practices for managing scalability issues
  • A common base of modules that everyone agrees are essential to serving education (Views, CCK, WYZIWIG API, Outline Designer, etc)
  • An optional set of modules that most agree are good to have and document what they can be best used for to serve our “clients” (IDs, students, instructors, etc)
  • A website that is a common resource for everyone.  Using the information in https://elearning.psu.edu/drupalineducation/ as a launch pad but then taking the documentation / resource to where ever the Consortium takes it.
  • Resources for how to help grow Drupal user groups locally and how to help others help themselves

There are a multitude of reasons why this could be so helpful to so many but ideally there would be a suite of modules that could be agreed upon need to be created to help foster Drupal in the educational sector and that those projects could be worked on collaboratively across university lines.  I can only develop and maintain so many in a vacuum and I’m sure many out there also have these potential issues going forward to create and maintain essentially proprietary pieces of an open source project.  This can help us avoid the pitfalls of current, closed source LMS / CMS that are embedded into many universities (many names, all closed, all huge).

Grassroots is how this movement is going to take off and it’s how it is currently!  Please, if you feel passionately about Drupal and it’s usage in Higher Ed, pass this link on.  Not just to give me traffic but to drive traffic to this idea and get others on board!  If you’re interested please leave a comment below, re-post / like to it, tweet it.  Grassroots is the best way to spread a movement that has been largely grassroots in it’s spread and popularity.

Advertisements

Moodlemoot

Preface — This is as it’s happening, raw reaction to MoodleMoot and presentations there in.  I am trying to gain more experience / knowledge with Moodle to make an informed decision about whether or not they do things that we should be investigating.  This could be particularly harsh, you have been warned 😉

This will be on going but thus far from MoodMoot I’m unimpressed with Moodle.  Now, I didn’t like Moodle coming into things having played with it a little bit.  But after seeing others walk through how to modify aspects of Moodle sites (all of which look the same minus minor color alterations and logo graphics) I can securely say that I’m horrified of this product.  Mile long pages of settings to change text?  PHYSICAL .php files laying all over the place?  Discussions of how to submit bug tickets about the gradebook and other components mid-semester / during usage?!

WHAT!?  Are you kidding me!?  This can’t be a serious way people work.  Common slams on Drupal:

  • Usability
  • Complexity
  • Security

My new and improved list of common slams on Moodle:

  • EVERYTHING LOOKS THE SAME
  • Complexity through lack of usability — this is like looking at Drupal 4 branch in terms of what things mean and do
  • Form and function — .php files laying around instead of having everything be modular; example: to change a status message generated by moodle.php, I need to go to moodle.php in an admin menu and physically edit the mile of options (ummm….String Replace Drupal module to do this that’s 1 very small page)

Wow… more to come as this keeps going on but I’d like to dig my eyes out at the thought of people moving to this.  There’s no way this product is mature enough for me to mess with it.

How to follow with such incredible momentum

Drupal Camp Wisconsin came to an end today.  I’ve been here 4 days and have probably spoken during official meetings, unofficial meetings, and presenting at DrupalCamp for around 32 hours.  It’s been a very long, very fun, and very critical 4 day stint here in Madison.  I’ve been able to talk to so many people about so many good ideas as well as share with them the solutions that we’re crafting both in terms of module usage and our infrastructure stuff.  Here’s some of the critical take-aways:

  • Madison has A LOT of the same CMS culture, problems, enthusiasm, and need for leadership and direction that we have
  • Madison has a great network of people, all willing to work together and share ideas
  • Everyone was very interested in all of my projects, especially the infrastructure management tools / information architecture that I’m building
  • Madison’s going to be getting copies of my IA to play with, hopefully we can standardize on it or on parts of it to help foster collaboration futther
  • We discussed and agreed on the idea I proposed of a track of Drupalcamps, specifically geared towards major universities
  • The seeds of the Drupal in High Education Consortium were planted and look to have Penn State and Madison as it’s first two member organizations

This has lead a few of us to use terms like “momentum” when describing what this relationship has at this point in time.  We both were able to relate to one another’s problems and agree that we (and probably other universities) can benefit greatly from collaboration in this area.  This is my action plan at the moment as to what to do with all this “momentum” that’s been drummed up:

  • Attend the Drupalcamp in Pittsburgh and get in touch with the universities forming it to meet with them and have a similar show-and-tell like we just had with Madison
  • Form the Drupal user’s group in the Centre County / Penn State area and begin meeting like they did out here
  • Begin planning for a Drupal in Higher Education consortium and come up with some ideas for what our action plan is (most likely a base level flavor of D6 standardization in tool set)
  • Get in touch with MSU, ASU, VT, PIT, CMU, and anyone else I can find contacts that I have and look into similar meetings
  • Begin planning for a DrupalCampPSU event

The idea of the consortium isn’t to say “YOU ALL WILL USE THIS STUFF IN DRUPAL” and standardize EVERYTHING we use; but, because of the problems faced by major universities (lots of students, lots of colleges, lots of decentralization, lots of funding cuts, lots of need for “free” solutions, lots of Drupal interest).  For all these reasons I propose that we standardize on a set of modules that enable the infrastructure component that we are currently using.  A few modules / ideas right now that I think would be good to standardize on based on our discussions this week as well as my own feelings on where to take things:

  • Views / CCK – really, who doesn’t use them anyway but also some types / views could be built out through collaboration to meet common needs
  • Infrastructure management – what the course manager will become, allows us to grow and expand quickly as well as possibly share resources (fast!)
  • Some base Roles that we can all agree on based on our contexts being similar (staff, faculty, student, admin, instructor, etc)
  • Aggregator and some other feed related modules (possibly feed api) so that we can syndicate and share our content in common ways
  • WYZIWIG API – Not that it HAS to be used but all of us have to make Drupal more usable from a staff perspective.  Editor type doesn’t matter, frame work for it does
  • CiviCRM or at least some implementation of handling staff bios / student profiles.  A lot of sites need to store data to this end and it would be good to agree loosly there

Again, the goal of these discussions is to come up with a framework of best practices for all of us to follow and not a strict specification.  This would get too close to forced adoption systems and closed source projects that have driven us to Drupal in the first place. I need to stress this as much as possible because I don’t want this to fail and I don’t want it to surcome to the same issues and be hated as so many closed source implementations are in higher education / large corporations.

Those that follow the best practices as closely as possible will benefit each other the most as we can share information and resources a lot easier but there’s nothing saying you NEED to follow it to the letter.  For example, you want to use Organic Groups and we don’t standardize on that in our package / best practices? Go for it!  As long as the IA driving it is the same then the individual sites don’t matter.  So, in closing, the attack plan would be:

  • Standardize on a common Information Architecture based on the idea of one site that can control all the others and loosely knits them together
  • Come up with a group of recommended modules and identify their best usage
  • Standardize on a few other things like roles and module sets

“HELLO WISCONSINNNNnnn”

Sorry, had to say it at some point.  Very excited because tomorrow I’ll be in Madison talking to the U. of Wisconsin about Drupal and the work I’ve been up to over the last 3 years now.  I can already tell it’s going to be a tiring yet fruitful trip as it’s two days of talks followed by two days of DrupalCamp WI (which I’ll hopefully also be talking at sessions).

My big push while there is not only to see what kind of resource and information sharing we can do, but also get the prospect of a Drupal in Higher Education Consortium out on the table.  I’ve been talking to some major universities over the past year and after Drupalcon DC 09, really was about to identify a few who fit into one of three groups:  Interested in going out direction, going a similar direction, or completely divergent.  I’m happy to say most seemed to be either interested in going our way or are already working towards a similar end goal.

From talking shop with others I know that Pitt and VT are very interested in using Drupal and have started to create some sites.  Arizona State University and a few others that I’ve talked to or read about informally also seem to be developing either systems or modules that align very well with the Course Manager module that I have sitting in the wings.  Course Manager is really like the controller for our Drupal sites and it loosely stitches them together into a CMS-light architecture.  ASU’s work seemed to be in a similar direction so it would be great to meet up with them in the future.

For now though, my focus is WI and figuring out what they’ve got rolling and what we can get rolling.  The fact that Bill Fitzgerald will be out there too also seems to indicate to me their level of seriousness in going towards some more complex Drupal solutions.  Bill’s got more of the consultation side of the equation, started the Drupal in Education group, is the maintainer of the DrupalED distro, and also wrote the book, so he’s got SOOOMME street cred ;).  I think I’ve peaked their interest because I’m doing so much work that’s intended to help all of us and have been so active in the community the last year.  The goal of being open has been to foster collaboration and communication so if more relationships like the one we’re (hopefully) forging with WI happen, giving everything I do away (and spending countless hours writing it that way in the first place!) has all been worth it :).

Hope to see you at Drupalcamp WI, should be around 100 people and hopefully you’ll see me there unable to shut up!