Building a Domain of One's Own: The Sign-Up

We considered a lot of different options when developing the strategies for signing up for Domain of One's Own. It sounds inconsequential but in contrast to many University-run programs this project was offering something that many didn't have experience in and with first impressions being important we had to consider a lot of different scenarios. When we open it to all students would it be like you receive a gift card with your entry letter for a new domain? Would signups be tied to specific courses or programs? How would we control what could or couldn't be created on their domains? (Ok we didn't ask this, but you can bet others did!). In this post I'll talk a bit about what we envisioned, what we got for the pilot, and where we plan on going for the larger roll-out to all freshman. I'm a big fan of user experiences that seem completely natural. One thing that is advantageous for this project is that buying things online is no longer a mysterious experience. I would estimate most of our students have bought something online, whether that be an MP3, a pair of shoes from Amazon, or a Netflix account. So I wanted the signup process to mirror the aspects of what makes it easy to buy things online. Creating an account, getting a domain and hosting, and getting it all setup should be as fluid as possible. We had to start with deciding who was going to be allowed to signup during our pilot and afterwards. When we pitched the pilot project we wanted the number to be somewhere around 400 students and faculty. We also wanted it to be embedded into the curriculum of at least a few courses. I scratched out the names of faculty who I knew I could call on to work in the pilot either because they had already volunteered or I knew they ran courses that made use of technology like this already (like ds106 and Zach Whalen's Writing through Media course). So we decided we would work with a set of faculty who would run courses using these spaces. Because we have no way of identifying that a student is in a particular course during a signup (I imagine we'd have to tie in pretty closely to Banner to do something like that, which would have been a security nightmare if even possible) we created a signup form that had a single password that we distributed to all faculty involved in the pilot. Could this password be shared to others? Of course it was possible, but we decided trust was more important that heavy security at least for our first go at this. After all, if you have students itching to try and break in to be a part of your project, isn't that actually kind of awesome? We only asked students for a first and last name, email address, and to select the course they were enrolled in from a drop down menu. Once they did that they were taken to a screen that let them type in possibilities for a domain name. We prompted them to consider using part of their name, but ultimately gave them complete control. To accomplish the domain searching aspect we used the DomainsBot API which actually made it pretty simple to have a search field that would show suggestions of only available domains based on what was typed. We were even able to limit it to just the top-level domains our registrar, MediaTemple, supported (.com, .org, .net, .me, or .info). Now this is usually where we'd get the question/concern that surely this opens up a risk of a student registering UMWgirlsXXX.net or something sinister. Well sure, that's a concern I suppose. But there will always be risks when you provide opportunity, the danger is in weighing the risk much more heavily than the opportunity. Could a student use that for nefarious purposes? Yes, but they didn't. Over 200 students ran through the pilot and no one chose something inappropriate. That's not to say it won't happen, next year we could potentially have 1000 students sign up and in 4 years the whole campus will have had the opportunity. Someone will push the boundaries, it will happen. But that's a vital conversation to have with students and one we shouldn't be afraid of. The whole point of the Domain of One's Own project is not just to have students become arbiters of their own digital portfolio or web space or whatever you want to call it. We also want them to think critically about their own digital identity and how the work they do is reflected on the web and associated with them both negatively and positively. The opportunity for abuse then in my eyes is not a reason to reject the project but rather a chance to have these conversations with students and hold them accountable to the choices they make. We don't do enough of that in higher ed. After selecting their domain students were whisked off to a new page where they signed up for hosting. As I mentioned in my post about our panel software Plesk, this was less than ideal. The panel signup was not easily branded and felt like a pretty ugly online store. Although Plesk has an API it was beyond our capability to build anything for the pilot that would take the information we got from students and generate panel accounts automatically without using the online store included in their Customer and Business Manager Add-On. Once they completed the hosting signup they would receive a welcome email, have access to their panel, and once the domain was registered by MediaTemple their site would be live. For a small pilot this was completely manageable. I wasn't entirely happy with it but it worked. I've already got a few ideas for the larger rollout in the fall though that will streamline this process and would have been very useful had I known about them previously. I discovered a piece of software called WHMCS which integrates directly with Plesk and cPanel to handle signups and billing as well as domain registration. Not only could we build an "online store" that was branded to the rest of the site and authenticated against active directory, but we could connect eNom to this for domain registrations that would happen immediately, and it would fire off to Plesk (or more likely cPanel next year) to create hosting. In ~10 minutes not only would a student be able to walk through the entire signup process as a fluid single step, but their site would also be live immediately because the registrations are instantaneous and associated with the correct nameservers out the gate. WHMCS also has a built in knowledgebase and support ticket system that could be used for common questions and troubleshooting. There's a lot to the software and they have a lot of extensions built by third-parties to do some really interesting things. If I were building this again it would be a no brainer to start with them to handle the whole sign-up process. In my final post I plan on talking about a few other software possibilites that extend and build on the panel to make it really shine and some ideas I have for taking it even further.