I’m REALLY excited about an idea I had yesterday that, thanks to the previous work of my colleague Tim Owens and his assistance today, I think we may be able to realize as part of A Domain of One’s Own.

We’re working on a couple of projects now where we’ll be rolling A Domain of One’s Own out as part of a course’s curriculum. In each case, the professor has some pretty clear ideas of what he/she would like student to use the space for. We see this as a wonderful opportunity to plant seeds with students — as they learn how to use the space to build something meaningful for the course, hopefully it will spark their imagination in terms of what else they could do in this space.

But, one of the things that has been troubling me as we’ve begun to think about rolling out DoOO more broadly in this context is how we build entryways into the system that aren’t too overwhelming and daunting for students. As we’ve spoken about before (I know we talked about it in this episode of DTLT Today) the complexity  of owning your own domain and Web space is both a blessing and a curse. For some students, the “sky’s the limit” perspective is exhilarating and enticing. For others, it is overwhelming and off-putting.

To that end, in a conversation with one of the instructors I’m working with, art professor Rosemary Jesionowski, she mentioned that during the pilot last year some of her students had been a bit overwhelmed by the possibilities. When you tell students to “go find a theme” in the WordPress repository, they might feel like they then need to sift through the over 2,000 themes that are currently in there – and how do you even start to do that in a meaningful way?

From a support standpoint the complexity is challenging as well. When you’re supporting a class of 25+ students all trying to build an online portfolio with WordPress, and each of them picks a different theme, (some perhaps complex themes with a lot of built-in options or plugin dependencies), it’s difficult to spend limited classtime providing meaningful and useful support.

At the same time, we don’t want to entirely restrict them, either. We don’t want to tell every student to use Twenty Thirteen — and end up with a class in which their portfolios show little individual choice or distinctiveness.

I was struggling with how we could address this, and I remember that last spring Tim had figured out how to automate the installation of some plugins using customized installation packages in Installatron (I can’t find the post in which he speaks about this specifically, but perhaps he’ll share it in the comments).

For those not familiar: A Domain of One’s Own makes use of a script installer called Installatron. It allows our users to quickly and easily install dozens of open-source Web applications by clicking a button and filling out a form. It’s similar to Fantastico and Simple Scripts, if you’ve used those before.

One of the awesome things that Tim discovered was that you can actually customize the installation packages. So, for example, we install Cookies for Comments by default on all WordPress sites in A Domain of One’s Own — making it easier for us to help students fight spam.

I began wondering if it would be possible to create custom WordPress “packages” that students could select when running the installation. Imagine that students in Rosemary’s class choose “Art Porfolio” as their package and they automatically get a set of themes installed in WordPress that we’ve picked because we know they’ll work well for the goals of Rosemary’s assignment. We can also pick themes that are less likely to cause problems right out of the box because of highly-customized options and plugin dependencies.

And speaking of plugins, we can choose a set of plugins that also fit the goals of the assignment: a couple of image gallery choices, a plugin or two for integrating with Twitter, etc.

What does this get us?

First, it creates a somewhat more bounded experience for students encountering A Domain of One’s Own for the first time. Second, it allows us to focus the precious time we have with them in the class on showing them how to install and setup a set of known plugins/features.

My dearest wish is that this approach makes the threshold into the project seem a bit lower — but that it also frames their experience in terms of the possible.  The goal is not that students should feel wholly limited or restricted by the options we give them, but rather that we’ve provided a starting place for exploration that feels a bit less daunting.

And imagine the possibilities? Packages for specific courses, programs, or projects. We can curate sets of themes and plugins that serve as gateways for lots of different types of experiences in WordPress. And, presumably, we can extend this approach to other applications as well.

And the really lovely thing is that thanks to Tim’s help and the awesome support at Installatron, tonight I cracked this nut. I’ve set up my first package where a user, during the installation process, makes a choice that then triggers the installation of a specific set of themes/plugins.

When I’ve got the final code for creating the packages in place, I’ll share it here. In the meantime, I’m looking forward to brainstorming all the ways we could use this approach!