All posts by Martha Burtis

Looking (again) to Domain of One’s Own

When I moved into my new position at UMW a year and a half ago, directing the Digital Knowledge Center, I knew that while I was moving out of faculty development  and instructional technology that I would still be working with our Domain of One’s Own project. However, I wasn’t exactly sure what my role in that project would continue to be on a day-to-day basis. A year after the start of the new position, in summer 2015, the Center was actually moved out from under the Division of Teaching and Learning Technologies, moving me further away, organizationally, from the base of operations of DoOO within DTLT. On top of that, a wholesale turnover of my colleagues in DTLT from summer 2015 to summer 2016 has meant that many things have been in flux around here, generally, and, specifically, that’s meant a new consideration of how Domains fits into the work of our larger unit (Teaching, Technology, and Innovation led by Jeff McClurken) as well as how it integrates with my own particular position at the University.

Of course, not surprisingly, as faculty have continued to integrate DoOO into their classes, students have continued to engage with the project in a variety of ways — those students then come to the DKC for assistance from our peer tutors. Consequently, I continue to work with the project as part of my job on day-to-day basis, with a greater emphasis on student development instead of faculty and course development. That shift has been at times rather revelatory for me as I’ve come to see how students (and my tutors) perceive Domain of One’s Own. I can see the project more clearly — or perhaps I should say I can see certain parts of the project more clearly. In particular, I can see first-hand the ways in which the project’s integration in a class can have huge positive impacts on students — and when curricular goals can fall a bit short.

In addition, since I’m the last woman standing from the old DTLT, I tend to have the most historical perspective on the project. This can be helpful when we’re sitting around the offices trying to figure out why something was set up a particular way, but there have also been times when I’ve had to bite my tongue. I really don’t want to turn into the crotchety old woman who regularly cries “That’s not the way we did it in my time!!” It’s been wonderful, though, to see all of my new colleagues take up the reins of DoOO, thinking through critical issues about where the project is heading and how we continue to work with UMW faculty, as well as tackling the daunting task of ethically wrangling the data and information that makes up our faculty’s and students’s experiences of the project.

As it turns out, there’s still plenty of Domain of One’s Own to go around, so I continue to be a part of our strategic conversations about the project, and I continue to be asked to speak about it both here at UMW and elsewhere.

However, to be frank, I’ve done a pretty rotten job of regularly taking time to reflect upon where the project is, how I’m thinking about it currently, and where it’s going. Given how much of my job is still tied up in making sense of Domain of One’s Own, I’m committing myself this semester (and into this summer) to regularly reflecting upon and sharing some of my thinking.

This goal is partly selfish, I admit. I have three upcoming events this spring and summer where I will be talking about DoOO, and I need to commit to this writing and reflection if I have any hope of feeling prepared for those events.

First up, at the end of March, I will be heading up to Keene State University to take part in their spring open education speaker series. My talk is titled “Messy and Chaotic Learning” which is really the only kind of learning I like. 🙂

Then, in June I’ll be keynoting the Domains 2017 conference hosted by the University of Oklahoma. My goal for that talk is to both recap a bit of the origins of DoOO but also to push my thinking it terms of what the project can and should be in the future. I think this is mightily important given the complex, fraught landscape of our moment. Working with students in the DKC, in particular, I worry that their understanding of the project focuses mostly on the pragmatic possibilities of open Web hosting without considering the deeper implications of what DoOO is pushing up against.

Finally, in August I’ll be leading a track of Digital Pedagogy Lab’s Summer Institute. My topic, not surprisingly, is . . .Domain of One’s Own. This will be a week-long opportunity to work with a cohort of (mostly faculty) participants on thinking through the possibilities of Domain of One’s Own in higher education.

This brings me to another project I’ve been deeply involved in for the last year: overseeing a range of activities within our unit aimed at broadening the reach of Domain of One’s Own at UMW starting in fall 2017. This initiative is in many ways a response to the inclusion of Domains in the University’s new strategic plan, but it’s offered us an opportunity to think through our own approaches to how we communicate about the project with the campus community. We’re trying to push ourselves to think about how DoOO reaches outside of classrooms, a challenge that we’ve struggled with since the project launched. I hope to do some reflecting here about that project as well. We have a lot of balls in the air on this front: new approaches to analyzing and assessing student engagement with the project; new ways of introducing the project to incoming students; new extra- and co-curricular programming; new partnerships with other units on campus; new faculty, student , and course development opportunities; and a new, more thoughtful and comprehensive approach to branding and communicating about the project.

Finally, my goal to write about these talks and projects this spring serves another purpose. Since last November, I’ve been floundering a bit, trying to figure out how my professional life and goals intersect with the many challenges that we’re facing in our country. There are days when the two seem wholly divorced, and I know that’s neither an accurate perception or a healthy one. Since the idea of Domain of One’s Own was born, I’ve believed in it because, for me, it represents a kind of infusion of agency into our schools that is so often missing. And, I believe that agency is one of the things that we all must find a way to build and hold onto right now. In fact, it’s arguable that helping students find agency for themselves has always been at the heart of what we’re doing. Right now, perhaps more than ever, I want to be involved in projects that build, promote, and explore learner agency, and I can’t think of a better way for me to re-engage with my work then considering these issues through the lens of Domain of One’s Own.

Imperfect Offerings

Next week, I’m headed to Coventry University with Jesse Stommel to participate in Expo 16: University Remixed hosted by the Disruptive Media Learning Lab. For the last six weeks or so, Jesse and I had been regularly talking with the folks at DMLL about the event and planning how we could most meaningfully contribute to their program. The event is designed to bring together people to talk about the future of higher education, with a few featured voices as well as opportunities for the participants to work together on creative responses to a set of critical questions around the topic.

I was asked, in particular, to present at the end of the day in some sort of summative fashion. Knowing that it would be difficult for me to adequately circulate and capture the wide-range of voices and ideas that were likely to be generated on the day of the event, I suggested that I try to pull together a sampling of media responses to the same questions that people would be grappling with. I wanted to gather some of that media on the day of the event — perhaps short videos, audio, captioned photos of the participants. But I also wanted to “seed” the conversation by inviting our larger community of colleagues in higher education to submit their own responses via the Web. Jesse was also planning on working with Sean Michael Morris to have the final #digped chat this week also intersect with the same set of critical questions. All in all, I was very excited about the opportunity to spend the days right up to the event soliciting and sharing responses, with a focussed in-person collection of ideas at the Expo itself.

On Tuesday afternoon, Jesse and I were putting our final touches on how the online part of this conversation was going to unfold. I was planning on a “soft launch” for the Web site I’d built to collect responses on Wednesday morning; Jesse was planning on introducing the topic for #digped sometime later Wednesday afternoon.

On Tuesday night, the US election results unfolded.

On Wednesday morning at 7:30 I messaged Jesse and asked him how we could we possibly put out a call to our reeling community, asking them to submit media responses to questions about the Future of Higher Ed and to participate in an online chat about the same topic. There was a good chance that the responses we would receive, colored by so much heartache, fear, and anger (all valid and appropriate emotional reactions), would not serve to advance any kind of constructive conversation between now and next week. But, even more importantly, it felt tone-deaf and callous to try to pivot a conversation away from the very raw, human, and necessary processing that was happening in our networks.

Our friends at Coventry have been very understanding about our need to put those plans for this week on the back burner. Jesse and Sean have issued a quiet but passionate request to the #digped community to dig deep and figure out how we can continue the critical conversations in that space as we all move forward.

I’m very much looking forward to our trip next week. I still think the questions we will be asking are important ones, and I’m looking forward to witnessing the work of the Expo participants in grappling with the answers. I also know that our colleagues in the UK have been reeling from their own experiences with Brexit over the past few months, and I want to be in conversation right now with as many people as possible who are struggling to determine how we teach, learn, and lead in times of great uncertainty.

Which I think will likely be the actual theme of my talk next week: How do we teach, learn, and lead in times of great uncertainty? I’m sure I will be inspired by the conversation and responses that the Expo participants generate next week. In the meantime, I’m going to be grappling with this question myself. I welcome any thoughts anyone has.

Photo Credit: Crackled, rawdonfox, Flickr, CC by 2.0

Refactoring Domain of One’s Own (and everything else)

It’s been over a year since I wrote in this space. There are lots of reasons for that. Most significantly, the last 12 months have seen enormous change in the division that I’ve worked in here at UMW, Teaching and Learning Technologies. If you follow me on social media, you know all about the changes. Suffice it to say, I spent the first part of this period of change largely grieving the departure of many people who I consider friends in addition to treasured colleagues. Luckily, I’ve spent the second half of this transition welcoming a new group of wonderful people to the University. Change is hard and sucks; change is good and valuable.

Also luckily, there have been a few people who haven’t left; I’m so grateful for their support and friendship over the last year or so.

In addition to all the upheaval in DTLT, I actually don’t work in DTLT anymore. No, I didn’t leave; we just made some changes in the organization of our unit and I report directly to the Special Assistant to the Provost for Teaching, Technology, and Innovation (aka Jeff McClurken). This allows me to work more closely in parallel with DTLT, and it allows me to explore the Digital Knowledge Center’s mission of supporting student engagement with innovative technologies alongside DTLT’s mission to support faculty.

You could say that my entire year has been a year of refactoring.

But I’ve also been working on another kind of refactoring project, namely to take the code that Tim Owens and I wrote mostly back in spring of 2014 to manage the UMW Domain of One’s Own Web site. At the time, we were working fast and furiously to build out as many features as we could imagine for that site. We wanted to push ourselves and, in doing so, to push our colleagues’ imaginations as they thought about how the project could be managed, presented, and interpreted.

In order to work as quickly as possible (we seriously wrote most of the code in a few days), we built all of our custom functionality in a WordPress child theme.

But before I go any further, let me back up and explain a bit how the structure of UMW Domain of One’s Own site actually works.

When you visit you are viewing a WordPress site. If you’re a UMW community member, you can sign-in to that site to first set up your domain and hosting and then manage the created account.

WordPress, however, acts mostly as a front-end for all of the other various integrations that we need to make happen. In brief:

  1. Through the use of a WordPress plugin, we’re able to integrate this site with our University’s Central Authentication System (CAS), allowing for single-sign on into Domain of One’s Own.
  2. Through API calls to our client management system (WHMCS) we are able to redirect new users after they login to a checkout system for choosing and registering their domain as well as setting up their Web hosting.
  3. Through API calls to our hosting server’s software (WHM/cPanel) we are able to redirect returning users to the cPanel interface. With the integration of Installatron (a script installer and utility for open-source applications) users can then be “passed-through” to the admin interface for various applications they install (without having to authenticate beyond CAS).

    We are also able to build a migration tool that allows users to easily request an EPP code and backup when it’s time for them to leave Domain of One’s Own (generally within six months of graduating).

  4. Through API calls to our domain registrar (Enom) we are able to  check the domain verification status of a user’s domain and prompt them to verify if they haven’t already done so.
  5. Through custom code that we’ve written for Installatron, we can capture information about every installation that is completed on Domain of One’s Own and store that in a custom content type in WordPress, allowing us to build a directory of installed sites across the DoOO ecosystem that are “linked” to the user who created them.
  6. Through the WordPress plugin, FeedWordPress, we’re also able to capture syndication information about any installed applications that are RSS-enabled and we can begin to syndicate new content onto the main DoOO site, thereby creating an archive and central hub of user-created content.
  7. Through other WP plugins we can build on top of all the information about users, sites, and posts that we are capturing, allowing us to potentially build rich interfaces for discovering the work of our Domain of One’s Own users.

But all of that is really nothing new. The code to make all of that happen was more or less completed by summer of 2014. In the ensuing years, however, we’ve had to neglect some of that code. With people leaving and my being pulled in different directions, keeping that code up-to-date has been difficult. All of our core functionality continues to work, but some of the bells and whistles have had to get turned off, particularly in the last 9-12 months.

This summer, however, signifies DTLT becoming fully staffed again, with new people who are eager to dive into the project and to think about what the next version of the DoOO site might look like — and how it could function.

To that end, I’ve spent the better part of the last 2 weeks refactoring code, specifically taking what had been a lot of custom functionality in a child theme and turning it all into a DoOO plugin. The child theme approach allowed us to work quickly back in 2014, but it wasn’t really sustainable. We were essentially locked into the parent theme we’d chosen, and it turned out that parent theme wasn’t the easiest to customize.

Refactoring the code into a plugin has focussed on a few primary goals:

  1. Creating Shortcodes: What had been a whole series of custom theme templates had to get turned into a library of shortcodes that can be dropped into pages as needed. My goal (before I leave for a month at the end of this week!) is to be able to turn the plugin and the shortcode library over to my colleagues in DTLT so that they can begin to work on building out a new DoOO site in a theme of their choosing.
  2. Commenting & Documenting: When Tim and I wrote the original code back in 2014 we were working so quickly that we spent almost no time diligently commenting our code. As a result, I’ve had to spent quite a bit of time unraveling some PHP spaghetti. As I go, I’ve been trying to be much more mindful of documenting the code for future developers.
  3. Generalizing what I can: We had lots of stuff hard-coded into our templates and functions file that I’ve pulled out into a config file, allowing us to more easily change these variables when it comes time to move off or our development server and into production. (In the back of my mind I’ve also been wondering if this plugin project needs to be turned into a repository where it’s possible for a group of DoOO adopters to collaborate on building a fully generalized plugin for creating DoOO project sites. )

There are some things I’m not going to get to. My WP plugin architecture is, frankly, pitiful. I’m not doing anything fancy to the structure of the code and files. And don’t even talk to be about object-oriented plugin development. It isn’t happening this go round. I’m just trying to make sure that the functions are grouped conceptually and can be easily worked with. There are likely to be a few features I won’t get to this summer, too, but hopefully we can pick those off over the course of the fall semester.

I may write one more post where I outline the various shortcodes that I’ve developed. It would serve as a useful document, I think, for my colleagues, and it might be interesting for developers at other schools who are undertaking Domain of One’s Own projects. In the meantime, it’s been pretty great to spend a few weeks with my head deep under the code hood of DoOO. My current job (which I still love) doesn’t afford me this opportunities as much, and this work reminds me of another aspect of what I love about developing environments for teaching and learning in an open source world.

Image Credit: refactoring by Daniel on Flickr (CC By 2.0)



Why Every EdTech Group Needs a DKC

The Digital Knowledge Center has now existed at UMW for about four months, and it’s kept me pretty busy. As a result,  I’ve been pretty rotten about posting updates about its progress. Over break, I worked on a status report, and I’ll be trying to share some of the data and numbers from our first (half) semester of being open soon.

Today though, I’m trying to tackle a topic that I’ve been mulling over more or less since the Center opened: Why I think every edtech group should have a student support organization like the DKC.

There’s a long history of how we ended up where we are with our Center, and there’s a lot of unpacking that I’m still doing about why we may have resisted this idea for quite some time. I’ve decided to save that for another post — partly because it would make this (already ridiculously long) post epically long, and partly because I’m interested in addressing some of the reasons for resisting a DKC separately. I’m really interested, in fact, on hearing from colleagues at other institutions about their perceptions of how student support should or could (or does) work within their own edtech groups.

So, putting aside that history and those interesting questions, I’m going to focus solely on why I think the DKC has quickly become an integral part of our unit and how other edtech groups (who don’t have something similar) might benefit.

I. The DKC is a critical safety net for DTLT. 

Our primary mission in DTLT At UMW is faculty development, and the resulting course development that grows out of those faculty relationships. Of course, you can’t have faculty and course development without resulting student development. Each of those courses results in a whole new group of students who need support, assistance, and mentoring.  For years, we’ve addressed that resulting student support in a catch-as-catch-can way.

Generally, student support has happened through class visits, after which we invite students to contact us by email if there are questions. Email is great for answering quick “How do I login, again?” questions, but it’s terrible for the deeper “How can I use my domain to build out a personal digital identity for myself?” questions. The truly stumped students (or the ones seeking deeper engagement and guidance) would come to our offices, and we’d do our best to give them what they needed.

Truthfully, however, the projects we manage have taken us, the faculty we work with, and the students in those courses into deeper and deeper waters. Course visits were great for getting things rolling. Email was fine for the quick how-to question. Stopping by our office was fine, if we could carve out the time for those deeper, important conversations. But often our time was eaten up by the deeper, important conversations we were having with faculty who were diving into those deeper waters. In short, we were becoming victims of our own successes. Each new innovative project we embarked on with a faculty member resulted in perhaps dozens of students needing more hands-on assistance, and, frankly, we just couldn’t scale.

The DKC has quickly become our primary channel for offering student support on projects we’re involved with, and since it’s positioned within our group  we get to determine how that student support happens.

II. The DKC is a safety net for our faculty. 

When you’re working with a faculty member who is new to a system like Domain of One’s Own, it’s only natural that they’re going to ask you what kind of support their students can expect to get. We have a strong history in DTLT of asking our faculty to also grapple with the technologies they choose to use in their courses (the Domain of One’s Own Faculty Initiative is a great example of this), but it’s understandable that they’re nervous about being able to single-handedly answer all of their students’ questions.

In the past, we did our best to fill in this gap ourselves, but (see above) scalability was becoming an issue. It’s now an amazing thing to be able to tell faculty, “Yes! We can offer support to your students. There is a place they can come for help.”

III. The DKC is a safety net for students

This is probably the most obvious positive outcome of having a Digital Knowledge Center: as our reputation grows, more and more students at UMW will know there is a place they can come for help. When they tackle a new digital project that has them worried about their ability to complete it, the DKC is a place they can come for assistance. If they’re preparing to graduate and working on their personal domain as a resource to send to future employers, the DKC is a place they can come for guidance. If they have an idea for a personal technology project they’d like to tackle and they’re not sure how to begin, the DKC is a place they can come for inspiration.

IV. The DKC clarifies our jobs. 

In the past, when our approach to student support was often so ad hoc, within DTLT we could find ourselves constantly pulled in different directions. On a fundamental level, you could say that we’re in the business of developing certain kinds of technical and digital literacies at our University. “Faculty development,” however, is a bit different than “course development” which is a lot different from “student development.” They require different approaches, different skills, different commitments of time, and different rhythms and patterns of work.

The DKC takes the subset of student support off of all our individual plates and formalizes it. My job, as director of the DKC, is to develop that plan for formalization, and to constantly work to improve upon it. By doing so, I believe that I’m freeing up some of my colleagues’ time and energy to focus on other areas in which we work. I think this small maneuver has proved to have enormous impacts on all of us. Something (student support) which used to be difficult to mange and troublesome to wrap our collective heads around, is more or less taken care of.

In some ways, student support is the easiest subset of our tasks to clarify and formalize. We have a pretty good sense of what kind of support students will be looking for because we’re more often than not involved in the development of the course activities those students are tackling. Faculty and course development is less predictable.  It’s where the story starts not where it ends. Interestingly, however, formalizing our approach to student support through the DKC has given us opportunities to enact similar formal structures with our work with faculty.

An example of this is the Assignment Prospectus that we try to develop for critical digital assignments that are happening in a given semester. The Prospectus is usually drafted by someone in DTLT, after working with a faculty member on a course. It outlines the boundaries and requirements of a particular assignment so that the DKC tutors have a point of reference when students come in for assistance.

Developing that Prospectus creates a check-point for DTLT staff and faculty that didn’t exist before. In the past, we wouldn’t necessarily have asked faculty to engage in such a formal conversation with us about describing an assignment. Since we worked together on the development, all of that knowledge was tacitly understood. Now, however, there is a good reason why we need to formalize these descriptions: it’s hugely helpful to our tutors and to the students who seek assistance in the Center. Not surprisingly, those formal conversations can result in surprising insight. They can push a faculty colleague to get just a little more specific about their objectives. They can unearth a misunderstanding about a particular milestone. They can clarify a use of technology that previously was assumed to be clear but was actually a bit murky.

V. The DKC connects us with students.

Working at a University, it’s always frustrated me in the past that I often felt disconnected from our students. In retrospect, I think that what I sensed was, to students, we were mysterious “tech” people who dove into a class for a session or two. Sure, we were reachable by email, but once you’re responding to student inquiries via email, you’ve moved into a pretty transactional relationship. They ask a question; you’re the “tech person” who answers it.

We’ve had some wonderful students work for us off and on for years, but we were never able to really capitalize on their time and skills. (Note: That’s why in addition to having a DKC, every edtech group needs to invest in a full-time director of a DKC. 🙂 It takes a person to devote herself full-time to making the most out of the great students you have.)

Currently, the DKC is attached to our offices, and it’s difficult for me to describe the change I think its presence has brought to our offices. We always have students around, and they are amazing, competent, inquisitive students. They bring ideas to us. They challenge the ideas we bring to them. They come up with new topics on which we should be offering tutorials. They tell us when something we’re doing or trying to explain doesn’t make sense. They come up with ways for us to reach out to other students that we would never have thought of. As director, I want them to feel invested in this Center to the degree that they want to come to me with their newest, greatest idea of what we should do next.

(I also want none of them to ever, ever graduate. 🙂 )

I can’t prove this yet, but I believe that growing this new extension of DTLT in the DKC will, ultimately, allow us to reach students in ways we had never before considered. Our tutors are, in a way, student ambassadors for us. They’re a part of our staff that we never really had before, and we didn’t even know we were missing.

VI. The DKC can be a model for the rest of campus

I try to talk a lot with the students who work in the DKC about the concept of modeling, and I think the Center can play a valuable role in serving as a model for others on campus when it comes to thinking about how we use technology in our lives at UMW.

The first example of how we model is best illustrated by the kind of tutorial that  many tutors probably fear the most, but I think are our opportunity to shine the brightest: it is inevitable, when you provide support on a wide range of technologies, systems, and tools that have a seemingly endless combination of options and possibilities that a student is going to come into the Center occasionally and ask for help on something that her tutor knows nothing about. As I said, I suspect that some (if not all!) of the DKC tutors dread these situations — which is, frankly, entirely understandable. (Many, many years ago, I worked as a writing tutor at Mary Washington College, and I still remember that feeling in the pit of my stomach when a student would ask for advice on a writing topic in which I felt out of my depth. )

As frightening as these moments can be, they are truly the ones that define us as a Center and as tutors. We need to understand that we will never have all the answers, and the students who come to visit us need to see us as these vulnerable, fallible creatures. After they realize that we’re not ridiculous fonts of all knowledge having to do with all things technology, they then need to witness us figuring it out.

I can’t tell you how many times in my career at Mary Washington a student has proclaimed to me that they’re just “not tech savvy” or they “don’t do technology.” I completely understand where those statements come from, and I believe it is part of my life’s work to help as many of those students get past that myth about themselves. One way the Center does this is by  having tutors sit in front of those students who are “not tech savvy” and show them

a) it’s OKAY to not know the answer and

b) how to find answers.

I believe it is a very powerful moment when a student sees that what makes the DKC tutors special is NOT that they know everything but that they trust themselves to figure it out. I want us to have lots and lots of those moments.

The second way in which the DKC can serve as a model is by approaching every interaction with a student as a teachable moment. I mentioned earlier that when you’re doing tech support via email (as DTLT has often done in the past), it’s difficult to move beyond the transactional: a student asks a question, you provide the answer, and there is little opportunity for deep elucidation or discussion of the implications of that problem. In the DKC, I want us to always strive to move beyond the transactional. Every question a student asks is a teachable moment, an opportunity to talk about what the questions represent, what the answer signifies, and in what direction those questions and answers take us next.

We ALL need to do a better job of talking about technology in these ways, because it’s when we shift our perspective like this that we gain an appreciation and understanding for technology not as merely a tool for transactions and efficiencies but as platforms and foundations for changing how we teach, learn, think, and know at the University.

Featured Image Credit: Safety Net by Rob on Flickr (CC BY-NC-SA 2.0)

UMW’s New Digital Knowledge Center (and my new job)

It’s been months since I’ve posted anything on this site, but this time I can honestly say I think I have a pretty good excuse.

Photo Credit: Andy Rush
The one-of-a-kind ITCC Photo Credit: Andy Rush

This summer, DTLT relocated to a brand-new building, UMW’s Information & Technology Convergence Center. I attended my first meeting about this building in spring of 2008, so it’s fair to say that the opening of this space has been a LONG time coming.

Moving our offices was complicated enough; in addition, DTLT played a pretty large role in helping the building get up and running (and, honestly, we’re still getting some stuff up and running). None of us were really sure what the move would be like and how the new building was going to shake out in the first few months. In the end, I’m glad we didn’t try to imagine what it would be like, because I’m not sure anything would have prepared us for how complex and exhausting the move would be — and how exciting and rewarding. I think it’s fair to say that generally people around campus love the Convergence Center, and we’re thrilled to be just one of the occupants of the building.

The Information Desk (otherwise known as how I spent the first three weeks of the semester) Photo Credit: the amazing Lauren Brumfield
The Information Desk (otherwise known as how I spent the first three weeks of the semester) Photo Credit: the amazing Lauren Brumfield

To make things more complicated for me, personally, the day before classes started we finalized a plan for me to move into a new position at the University running a new center.

The Digital Knowledge Center is a place for UMW students to get peer tutoring on digital projects, and it’s another project that has been many years in the imagining and making. It was originally a QEP proposal that Jeff McClurken and I along with several others worked on in spring 2011. It wasn’t chosen as our University’s QEP, but it is gratifying that three years later our administration believed enough in the idea to find the funding to make it happen.

The Center came about too late for us to work it formally into the design of the new ITCC, but my gracious colleagues agreed to “sacrifice” a planned conference room attached to our office suite so that we could have a physical space for the DKC. The room presents some challenges (particularly sound control when multiple tutorials are happening at once), but I can’t complain. We have a home. 🙂


Not the most thrilling picture, but the sign makes us official!
Not the most thrilling picture, but the sign makes us official!

I was also INCREDIBLY lucky to hire six amazing students to start as the first cohort of tutors in the DKC this fall. Several of them started as aides at the ITCC’s Information Desk and then decided to move into the Center when I was ready to start hiring. All of them have taken various classes with Zach Whalen, Jeff McClurken, and Jim Groom over the years, and they come with strong existing technology skills, but,  more importantly, with a natural curiosity for learning new things and and the instincts for helping others to use technology.

I’ve felt, perhaps more than ever before, like I’m building the airplane while in flight this semester. Ideally, we would have finalized the details of the Center last spring and I would have spent this summer developing a training curriculum, hiring and training tutors, and generally, preparing to administer and manage the Center. I have strong type A tendencies, and the drawback is that sometimes I want to organize, administer, and prepare more than is healthy. The lesson this fall for me has been that in the chaos of the building opening, switching jobs, and trying to get the Center running, I’ve still managed to land in a place where I think we’re on a solid road to offering a great new service to students — and have lucked into finding a great group of students to begin this journey with me. I’m not sure that it could have turned out much better if I HAD had the luxury of months of preparation and planning.

The tutors started working on September 29th, so we’re just finishing up the fourth operational week of the Center. For the first three weeks I was relatively quiet about the new service, wanting to give the tutors some time to get trained on a few things that they were unfamiliar with. During that time, I worked with my colleagues in DTLT to reach out to faculty whom they were working with to extend targeted invitations for students to come in for tutoring on specific projects. But after a few weeks of watching the tutors begin to offer the service to this bounded group, I realized that I was being over-protective. There was no real reason to avoid announcing the Center more broadly.

It is the end of the day, so everyone is gone. The tutors have decorated for Halloween, which explains the spiderwebs.
It is the end of the day, so everyone is gone. The tutors have decorated for Halloween, which explains the spiderwebs.

So this Monday I sent out an email to all UMW faculty, inviting them to share information about the Center with their students. Next week it will get announced more broadly to all students in a campus newsletter. Tutorials have been gradually picking up, and just this week (after talking with the tutors) we added two new tutorial  “types” for Zotero and Google Drive.

One thing that the switch to this new position means for me is that I’m basically moving away from the role of faculty development almost entirely, focusing instead on the student support that comes AFTER that development. It’s a bit jarring to realize what a big change that represents for me and the work that I do, but I’m also incredibly excited about what it means for DTLT more generally to be able to tell faculty that, yes, we do have a place for their students to come and get help — and to believe that we can scale that service to meet the needs of the faculty we work with.

I hope that now as things begin to settle down I’ll be sharing the work of the Center — and what starting a new service like this entails — in this space. Stay tuned.

Sort of a logo, but not.
Sort of a logo, but not.

Remote Comments Plugin (a FWP “AddOn”)

A long time ago, I blogged about some code I had written for ds106 that made it possible to show how many comments had been left on a post that was being syndicated (via FeedWordPress) from elsewhere. The code was pretty simple — it was based on the fact that some feeds (including ones originating from WordPress) pass a parameter called “wfw:commentRSS” which contains the RSS feed of the comments on an individual post. FWP stores this as a custom field for each syndicated post. So, it’s pretty easy to grab that RSS feed URL, fetch the feed, and then count the number of items in it.

When I came up with this technique back in 2011 I implemented it by editing the theme for ds106. Eventually, however, we removed the code. I seem to remember we thought it was impacting performance on the site. Depending on how many posts were displayed on the home page, that was a lot of RSS retrieval that needed to be done before the page could be displayed.

This week, Jim asked me if I could put the code on the site being used for the (awesome, new) Digital Scholars Initiative at UMW. I went ahead and did it, and in doing so I thought perhaps it was time to return to this code and see if I could improve it. Continue reading Remote Comments Plugin (a FWP “AddOn”)

Visualizing & Exposing Domain of One’s Own Activity

Now that Tim and I have successfully built a site at that aggregates the activity of the project, I’ve been focussing my efforts recently on what we can do to visualize and expose that activity. Every site that is created (as long as it uses Installatron to install a Web application) on the server as well as much of the content on those sites (as long as the content is available via RSS feed) is being pulled into the WordPress install that runs Community. That means currently we have information about 800 sites and almost 3000 pieces of content from those sites. For sites, we ask users to self-report the course they’re building it for as well as their “status” (student, faculty, staff). From the course data, we’re able to glean instructor and department. We’re also tagging sites with semester information. Content from these sites is similarly tagged with course, instructor, department, and semester information.

That’s a lot of content to play with, and it’s been fun to develop tools to allow users to explore all of the information.  Continue reading Visualizing & Exposing Domain of One’s Own Activity

A Few Models of Teaching in Domain of One’s Own

A few weeks ago, I blogged about the current status of UMW’s Domain of One’s Own project and this prompted UMW’s own Mark Snyder to respond on Twitter:

Which was very nice except that I didn’t really think my post did much to describe ways that faculty could use DoOO in their classes — it was more a rundown of our successes and challenges in getting the project up and running over the last six months. So, I told Mark that I would try and do a post that dealt more specifically with how Domain of One’s Own is being used by faculty in actual classes.

This one is for you Mark — never say I never do anything for you!

Continue reading A Few Models of Teaching in Domain of One’s Own

A Tribute to the Bullpen

Last week, Jim and I presented in Richmond at Open VCU about the experience of teaching #ds106. It was a lot of fun — but talking about #ds106 with Jim is always a lot of fun. We prepared a different kind of presentation, in which we examined the course/community through three different lenses of openness, and we used it as an opportunity to circle through a number of ideas while looking through those various lenses. You can find the presentation here, though I’m told the audio leaves a bit to be desired.  We’ll just have to do it again at some point. 🙂

During the Q&A Jeff Nugent of VCU’s Center for Teaching Excellence asked a question about how other schools can push forward with the “community design process” that we described as being so critical to the success of #ds106. It’s a good question, and it echoes questions I hear a lot when I speak to others about the successes that we’ve enjoyed at UMW with our work in DTLT. Jeff’s question was specific to a particular aspect of #ds106 that we had brought up in the presentation — the notion that the “course” wasn’t designed by a single person nor was the design process even led by a single person — and my response was what I often say to similar questions which is that a) we’ve enjoyed tremendous success in DTLT over the last decade with projects we’ve worked on and developed, and b) I’m incredibly proud of that work we’ve done, but c) I can honestly say we absolutely never sit down and engineer our project design. Our approach is organic and messy — the projects that have become huge successes have all percolated up naturally through our community, our shared interests, and our individual passions. I spoke to this a bit in my recent post about organic project development.

Continue reading A Tribute to the Bullpen