Building a Domain of One's Own: Plugins, Add-ons, and Plans

In this final post I wanted to take a look at some of the plugins and extensions that are currently out there that we're thinking of using to build a better interface for users as well as some ideas of what could make the project even better. I've mentioned quite a bit in the previous posts about how it's important that the tools we use have an open architecture that allows third-parties to build on top of it. It's so nice to find solutions to problems that maybe a small handful of people had but match up with your goals and when those people are able to pull together an extension to fix the issue rather than wait for an official supported solution from a larger corporation everyone wins. Here are just a few things I've found in the past few months that I think can nicely support the project and extend its capabilities.Installatron is a piece of software that replaces the built-in automated application solution of Plesk or cPanel. Why would you want to do that? Well, in our case while the Plesk Application Vault is nice to have, the functionality is limited in a few ways and annoying in a few others. By default an application wants to install itself in a subfolder which has led to the majority of students accidentally installing a blog at mydomain.com/wordpress instead of the root of their site. There's also no easy way to ensure these applications remain up-to-date. Installatron has a great interface and keeps an updated list of over 100 open-source applications. Admins can force updates on software installs but users can also choose to allow Installatron to keep their software up-to-date automatically either by small security release or with every major release. After testing it for a day on our server I made the decision to immediately roll this out on our install because it was so refreshing over the default application installer and the license was only $25. They also have an option to convert existing installs to their system so you don't have to run both application installers simultaneously and confuse users. Other well-known application installers to look at would be SimpleScripts and Fantastico. Handling support has always been a question mark for us. As a department primarily tasked with working with faculty to integrate technology how could we support students with such a large project as this? Certainly we could off-load that to the Helpdesk but the transfer of knowledge usually results in two departments continually bouncing tickets back and forth and the end-user suffers from increased support time. For the pilot we installed MediaWiki and set it up as a support wiki where we hosted tutorials and a few screencasts on some of the more popular scenarios that students would need training on. The advantage of a wiki like this is that using a plugin like Wiki Embed allows you to create pages on a blog that are populated by a wiki page and the links are automatically created. That's what's driving this support page which is a Wordpress page on the site feeding in the support wiki dynamically. Any information changed in the wiki would automatically be changed anywhere it is embedded. I also setup a GetSatisfaction page for support tickets but that got basically no use in the entire fall semester (most folks opt to contact via email when they run into problems). WHMCS has an option for using a knowledgebase and support ticket system that's built in to their software as well. The advantage there would be keeping track of the support requests centrally and localized to each user but I'm not convinced students and faculty would opt to use it over email as they've done in the past. Backup is another thing I'm thinking more about in the coming months. It's something that's really poorly supported by Plesk with only the option to back your site up to an FTP server or on your account (essentially duplicating the space you use). cPanel has a lot of nice backup utilities that allow for automated backups, user-initiated restorations, as well as backing up off-site to S3 storage. That last option interests me a lot because the idea of scalable storage like S3 being used for keeping all this data replicated without large costs is appealing. MediaTemple's backup service is also lacking in this regard because it requires manual snapshot backups. We have 5 rolling backups available to us but the weak link there is the requirement that I log in and initiate a backup which I rarely remember to do. In the next few months we'll be looking at better ways of automating this on the server level as well as exposing via extensions better ways for users to do their own backups and restorations. This also has the benefit of making migrations away from our server as easy as possible which is a major goal in the coming months as graduates begin to question "what's next" with their space (for the time being we will be renewing all pilot users for another year so nothing will expire while we continue to build this out). That last bit about migrations is a really important one. What good is a Domain of One's Own if it's just another silo for stored user content that gets lost when the student graduates? From the very beginning we've upheld the belief that by using these standard platforms we could provide an easy transition for students so that we weren't burdening them with a golden carrot that they would pay dearly for once they left the walled garden of University services (in stark contrast to the ePortfolio systems many institutions so readily adopt at a massive cost both to the institution and the student that might want to use it beyond their tenure at the school). My hope is that we can partner with a hosting company that might be interested in offering an extremely discounted rate to our students since we'll have ~1000 each year graduating with these web spaces and many will likely want to continue using them. Could we setup an architecture where we could also do this ourselves, working with the alumni department to provide a continued hosting option for years to come? That's a possibility as well. The architecture of these systems makes it easy to migrate and move the data which is the important part. Now we just have to come up with a workflow and provide those options. My hope is that in reading this series of posts if you work anywhere in the realm of education whether it be higher ed, K-12, public or private, that you're stimulated by these ideas and now believe them to no longer be beyond your grasp. As with most things that we do at UMW we've bootstrapped the building of this program in a way that's made it low cost and attainable. But most of all it's important. It's extremely important for students to navigate these spaces and understand the options that exist out there. To inspire students to build their own reflection of their online identity in a space they control and maintain rather than outsource it to Facebook, LinkedIn, or whatever comes next. It's an exciting renaissance of the web and I couldn't be more pleased with where we've gone in the pilot so far as well as where we're headed. Are you game to join us?