Over on his blog, Tim is talking about some very exciting work we’re doing with Domain of One’s Own right now, and he’s inspired me to add my own post to the conversation. Tim’s outlined beautifully some of the initial steps we’re taking to build a community space around Domain of One’s Own — a space that can capture information about the various installations that our users are doing in the system, and display that information in ways that allow us to easily filter and expose the work that’s happening. I truly believe we’ve only just begun to imagine what we could do with a space like this, and I can’t say how exciting it is to be working on this with Tim right now.

What I want to talk about specifically is the approach we’ve taken to Domain of One’s Own and how the work we’re doing is informed by that approach.

Since coming back full-time this summer and taking on a sort of project manager role for Domain of One’s Own, I’ve found an increasing sense of anxiety growing on my part about the initiative. Now, I’m naturally a pretty anxious person, so rather than overreacting to it and letting it spin out of control, I’ve been examining that anxiety and trying to understand it. What it came down to was my sense that we had more and more people coming on board the project, signing up for domains and hosting, and doing installs — but we had no particularly elegant or seamless way of understanding what they were doing. Part of this is a feature of the technologies that we’ve put together to run Domain of One’s Own.

Users sign up using a system called WHMCS (which is a very powerful tool for administering the accounts they need to register/manage domains and sign up for hosting). Upon signing up, they are then provisioned an account in cPanel, allowing them to go in and actually administer their hosting space. Finally, when they do a script install, they use a tool called Installatron — which has already proved to be a versatile system that allows us to customize software installations according to our particular institutional needs.

Within WHMCS we can create client accounts and then keep track of when they actually go in and register for a domain/hosting. But the reporting tools are pretty limited, in part because they’re designed to be used by a commercial hosting company (many of them  focus on projected revenue, for example, which simply isn’t relevant to us). It’s also hard to associate and track any metadata with those users (are they faculty or staff? what’s their class year? are they using the system for a class they’re taking?). We had kludged together an approach to monitoring this data using some custom fields in WHMCS, but then it proved difficult to run any reports that showed us that data — much less keep that data up-to-date.

On the other end of the process, when a user actually installed software in their space (using Installatron), information was being captured (and stored) but it wasn’t being exposed anywhere for us to see — at least not in any meaningful way. And we couldn’t associate any additional data with those installations to help us understand what they were being used for.

We were syndicating content from WordPress sites across the system using FeedWordPress, but that was a very limited way of looking at and understanding the activity of the space.

I felt like the train was leaving the station (with users signing up every day and installing new things) but we were losing the opportunity to track it once it was gone. And, meanwhile, I was anticipating the day when someone was going to come to me and say, “So, what exactly IS going on with Domain of One’s Own?” I knew I’d be able to pull together some general data about signups and installations, but I wouldn’t be able to contextualize it any meaningful way — and, perhaps more importantly, we’d have lost the opportunity to witness the work in a way that allowed us to highlight and share the exciting things students and faculty were doing. And I also knew that this problem would only be compounded every semester, as more users and classes and programs started to make use of the project.

Now, you may be reading this right now and thinking, “Yeah, Martha. You SHOULD have been anxious.” And you may also be reading this and thinking, “Wait. You launched this project and didn’t really have a plan for monitoring all of this?”

To which I would say: “Maybe. And: Yep.”

The thing is I can honestly say that if Tim and I had sat down in July and tried to imagine and then engineer the system that we’re building right now, we would have

a) only been able to understand it in abstract terms
b) had little ability to implement the idea (in part because of the abstractness or our understanding) and
c) gotten a lot wrong.

As with other projects we’ve taken on (UMW Blogs, ds106), we really needed to live the project before we could understand the project — and before we could make the project better. Perhaps programmers would call this an agile approach. Or perhaps smarter folks would say we’re idiots for not having more forethought.

But I don’t feel like an idiot today. I feel like by letting this project emerge in an organic way, we can let it become what it needs to become — and then we can constantly iterate upon it by building things on top of it that

a) make it better and
b) help us understand it better.

It really is like building the airplane while it’s in flight.

Sometimes, in edtech (or educational IT) I think we actually plan too much and we try to engineer our projects and systems too tightly. I’m not advocating for a completely irresponsible approach to tech innovation in education, but I am advocating for a more natural and organic approach to the project lifecycle.