Neither Locked Out Nor Locked In

I want to make sure before I begin that I extend my thanks to both Reclaim Hosting and the University of Oklahoma for organizing this event and for including me in it. Domain of One’s Own is a project that has consumed a large amount of my professional life for the last four or five years (and a large part of my heart and imagination for probably another 5 years before that), and building it back in the day with Jim and Tim at UMW was truly one of the most rewarding professional experiences I can ever hope to have. Moreover, seeing it flourish and grow and develop at institutions like the University of Oklahoma under the leadership of people like Adam Croom has been fascinating and humbling and richly instructive. I learn much more from DoOO and all of you who are involved in it than I can ever hope to contribute back to it.

As I’ve prepared for this talk I’ve been abundantly aware that I’m speaking to an audience that is different than ones I usually address about Domain of One’s Own. I would be lying if I didn’t tell you that this fact has been a source of some amount of stress for me — okay a lot of stress. There are people in this room whom I consider mentors and who’ve inspired me professionally for many years. Moreover, many of you have been involved in Domain of One’s Own for as long as, or almost as long as, UMW and I have been. You don’t need me to make the case for why Domains matters — presumably you wouldn’t be attending a conference titled Domains 2017 if you weren’t already convinced this project matters.

While I was thinking about what I could bring to the table here that would be new, I kept coming back to this nagging feeling I’ve had that we’re at an inflection point in this project. At UMW, we’re now four years into Domains. While I’m proud of what we’ve accomplished and hopeful about where we’re going, I also know that I increasingly find myself trying to understand Domains more deeply, particularly within the current cultural, political, and technical moment that’s happening right now — a moment that feels quite different from when this project began.

As you all know, I’m sure, the title Domain of One’s own comes from a long essay published by Virginia Woolf in 1929.

In A Room of One’s Own Woolf explores and defines what a woman in early 20th Century England needed to become writer — resources and a space of her own. When the idea of Domains was first born, back in 2007, it seemed fitting for us to suggest that a domain is what a student in the 21st century needed in order to be a digital citizen — a domain and space of her own.

Like me, Woolf also struggled with how to approach the topic at hand. Faced with the general topic of “Women and Fiction” she realized that there was no single, straightforward approach to take, she needed to somehow consider the topic from multiple angles, in an inextricable mix. And like me, she felt unsure that she would be able to provide a pat conclusion — a nugget of pure truth — that her audience could take away.

The title of my talk, “Neither Locked Out Nor Locked In,” comes from Woolf’s essay as well and I chose it because it captures a tension that I believe is inherent in a project like Domain of One’s Own.

How do we create a space within our schools (with all their political, technical, and institutional realities) that truly embodies a spirit of self-determination and agency for our students.

How do we free our students from the shackles of corporate and commercial Web spaces without creating some new kind of shackle?

And, how do web build a platform for the practical, valuable, discernible activities of building on the Web while also grappling to understand the Web on which we build in deep and discerning ways?

For me, the answer lies in pushing beyond the pragmatic and practical goals of the project where we often begin and end. And, like Woolf in a Room of One’s Own, I want to spend my time here dwelling on the the inextricable, in this case, why we in higher education must teach our communities to grapple with the Web in these deep and discerning ways — how the Web, and our culture, and our systems of education are bound up with each other and why they demand a particular responsibility of us.

And like Woolf I hold out no hope to myself or you that I will deliver a nugget of pure truth by the end of these 45 minutes. I expect I will raise more questions than I will answer and I will provoke more debate than I will resolve, but I hope that I will lay bear my thinking in such a way that you will find that provocation useful and that it will lead you somewhere useful.

ePortfolios

I’d like to start from a simple place, the place where, in fact, Domain of One’s Own at Mary Washington finally got off the ground at in spring of 2012. That spring marked the end of my participation in a working group on ePortfolios.

The charge for the group had been handed down by our Provost who, I believe, had attended some kind of higher education conference where he heard that ePortfolios were the “next big thing” and he was certain that we should be “doing them.”  Needless to say with such a strong and compelling charge our work was rich, nuanced, and valuable.

No, in fact we had spent close to 12 months simply circling around the issue of what an ePortfolio actually was and why we would want a system for creating them.

The teaching faculty in the room thought that they would like students to create an ePortfolio so they a could see a reflection of growth and development at the culmination of a course.

The faculty in the room who sometimes wore administrative hats wanted to see an ePortfolio system that would allow them to assess the work of a group of students within a particular academic discipline or program.

The College of Education faculty and administrators needed an ePortfolio because of increasing demands from the Commonwealth of Virginia to demonstrate students’ and graduates’ competencies.

Other administrators in the room wanted an ePortfolio system that would allow them to demonstrate our excellence as a University.

Oh, and some people also thought that perhaps it would benefit a student to have an online presence that they could create, develop, and take with them when they graduated from UMW.

At the time I liked to joke that if you had a meeting with 10 people about ePortfolios at UMW, you would walk away from that meeting with 13 different definitions.

It was, not surprisingly, a kind of frustrating 12 months.

My job, as the representative from teaching and learning technologies was to try and help translate the various needs of the participants of the working group into some kind of set of requirements, to research what tools and technologies could be tested or piloted to meet those needs, and to help facilitate those tests and pilots.

At the final meeting of that group, sometimes in spring of 2012, it became clear that while we had learned a whole lot about what ePortfolios might mean to us at an institution we were no closer to understanding how we could possibly settle on a solution that would meet the many disparate needs that had been expressed. In fact, it seemed ludicrous to try and buy or build a system that could do all these things since the very ethos of the “things” themselves seemed to be at odds: how does one give a student an individually-controlled space for reflection and growth while simultaneously using that space for institutionally controlled assessment and collection of data.

One theme that kept emerging again and again was the fact that many (but not all) of the kinds of things that we wanted to accomplish with ePortfolios we were already doing in other spaces. Namely, we were five years into our institutional WordPress blogging platform and we had begun to see students use this, sometimes unprompted, as a space for them to build out an online portfolio of their work at UMW.

At that final meeting while we talked around the topic of ePortfolios yet again, one administrator in the room asked, “given our current systems and expertise and resources, what could we do right now that would get at some of these goals?”

It was obvious that what we could do now was take the energy and excitement that was around UMW Blogs and push it further — give students their own spaces and more freedom.

A few other pieces fell into place: our CIO said that sure he could put some money to a pilot that did something like this. And the provost who had initially brought together the group to talk about ePortfolios? Well, he resigned.

Trojan Horses, Useful Symbiosis, and Considering the Pragmatic

Jim Groom has talked periodically about ePortfolios being a Trojan Horse that allowed us to pilot Domain of One’s Own at UMW. That sounds in some ways more dastardly and deliberate than I think what we intended.

I like to think that there was a kind of useful symbiosis that occurred. There was a conversation circling around a set of perceived needs and there were passionate, creative people at the school ready to push into some new territories. The confluence of these needs and this push allowed us to pilot Domain of One’s Own with a specific goal of helping students build out digital portfolios of their work. While that wasn’t the only goal we had, it was a useful goal to pin the pilot upon.

So why am I telling you this story? Perhaps because I imagine some parts of it might sound familiar to you: institutional mandates pushed from far above your pay grade. Working groups representing disparate needs and views trying to find common ground. Many hours of hard work on a project that is summarily dropped with changes in staffing and administration. These are challenges we all face (and will continue to face) at our institutions because this is how our institutions work. Part of what we need to do is find ways to create remarkable things out of these obstacles, and sometimes the Trojan Horse (or useful symbiosis) is the way to go.

But the other reason I’m telling you this story is because the Trojan Horse approach to launching DoOO at UMW represents a kind of pragmatism that I think we need to consider and unpack. On the one hand, attaching our project’s goals to a defined institutional need allowed us to move forward. We were able to secure both resources and support from important stakeholders by suggesting that Domains was a way to address some of the goals of the ePortfolio working group. If nothing else it was a way to demonstrate that something had come out of that year and a half of work.

The goal we were hitching our wagon to was also one that could be understood in pragmatic terms. Students should have a Web space in which they could publish their (best) academic work and they should be able to control that space and take it with them. In doing so, they would learn technology skills that were real and marketable. For a project, this is a clear goal with a clear set of objectives in terms of both student learning and student outcomes or products. It is fairly easy to talk to administrators about. It resonates with parents. It intersects with employers expressed needs. It is in many ways a win.

And, for the last four years at UMW it has been the primary way that we talk about and understand Domain of One’s Own. I suspect that at many of your schools it is a familiar message as well.

Bear with me as I now read you a long list of phrases:

  • create a digital presence
  • install popular open source applications
  • create your personal online presence
  • control your content
  • design and create a meaningful and vibrant digital presence
  • cultivate a digital profile for [your] academic and professional work
  • administer [your] own websites
  • build your own space online
  • develop rich personal teaching-learning environments
  • install many different applications for web publishing, community building, information management
  • [design] sites to house course resources
  • [gather] and [make] publicly available content
  • learn basic web hosting skills
  • create a beautiful website, a personal ePortfolio, or a blog

That was not actually a list I wrote — I’ve cribbed these from various Domains sites at some of our universities. And lest you think I’m picking on anyone here, the language we use at UMW is included in the list I just read.

Now perhaps your sitting there thinking about the list I just read and saying “Wait a minute. What’s wrong with those goals? They sounded perfectly good and appropriate and reasonable and honest goals for DoOO!”

In fact there is nothing surprising or inherently wrong about describing the activities of DoOO using any of this language — language that I would label “pragmatic.” DoOO is about building Web sites, creating a digital presence, learning basic Web skills, and sharing public content.

Just by doing all of these things, Domain of One’s Own is unique and special. I’ve spoken before and at length about the critical role that I think our Domains projects can play by providing students with open Web space upon which they can build and enact a digital identity for themselves. Prior to these projects at our schools this was a missing link in our technology chain of offerings. In fact, over the last two decades we have pushed students more and more into commercial, locked-down, proprietary systems that are divorced from the real world of the Web and frankly DoOo was a long time coming.

All that said, I believe we have to push beyond pragmatism now. I think it’s time for us to expect more of our Domains projects.

This past spring, I had the pleasure of speaking at Keene State College about Domain of One’s Own, and in that talk I laid out four key components of Domain of One’s Own that have recently helped me frame the activity of the project: Naming, Building, Breaking, and Knowing.

I believe there are opportunities with each of these to push beyond the pragmatic goals of Domain of One’s Own into deeper more reflective and more critical territory, and I’d like to talk through the first three (naming, building, breaking) fairly quickly. And then spend a longer time with you paying particular attention to the last one: knowing.

The Naming of Things

As we all know, the very first step in signing up for Domain of One’s Own is choosing a domain name. At UMW we have few restrictions on the choice of name and we offer suggestions to help guide students.

An overarching value we try to embrace when we talk about the domain choice is one of agency: participants should be able determine for themselves how they wish to be known and found on the Web. Our goal in this first step is for the naming to represent a moment of taking ownership: a consideration of what a thing is through its naming.

We should not rush through this conversation, suggesting that it is merely about the practical necessity of choosing an address for our Web site. Consider the heft of choosing a name in so many of our cultures and traditions. Certain religions believe that a name is an alternate representation of a living breathing person, or that names can be used to summon gods and to cast out spirits. In modern times, consider the weight new parents give to the choosing of a child’s name. Heck, I know people who have spent months picking out their vanity plates, which is a kind of naming in and of itself.

For our students, choosing a domain name is the opportunity for them to call something into existence, and the weight they assign to that act can help them to understand, ultimately, the importance of what they choose to create. Students who spend little or no time on this choice may see little or no value to what they place at that name; students who choose a name that is deeply reflective of who they are and what they would like to become may be more likely to see their domain as a kind of inhabitable space for them online.

The Building of Things

In addition to the domain name, the other fundamental component of Domains is the space we provide on an open source LAMP web server. We choose the LAMP stack because it is inherently open and portable. It is in this space that our students enact the most obviously practical goal of DoOO: building Web sites.

The building of sites is absolutely the core activity of Domain of One’s Own. When the project first started one of the things I would frequently say when talking to students about the web was that I wanted them to realize that the web was not something that happened to them but they were happening to. And I still believe this is an important message for our students to hear to and understand.

As I’ve already said this goal of Domain of One’s Own is enticing, resonant, and meaningful to so many of our students and faculty. They can wrap their heads around what it might mean to build something of their own at a domain they’ve named, and they can imagine how what they build might impact them beyond their time at UMW. And when I tell them that WordPress actually powers 25-30% of the Web, well that only makes the activities we’re asking them to engage in that much more tangible and relevant.

The Breaking of Things

It is impossible to work within these spaces and not, at some point, encounter breakage. I, myself, have broken Domain of One’s Own in the most awesome, spectacular, dramatic, and heart-stopping ways. 

When I’m talking to administrators or technologists or faculty who are new to the project this aspect is the part that terrifies them most. What about when things go wrong? What will I do? What will our students do?

Last summer someone posed this question to me at the Digital Pedagogy Lab Institute: “What do you tell my administrators when they ask what happens if something goes wrong?” And I rather flippantly replied, “You tell them, good. It broke.”

My answer was flippant, but the truth is for those of us who live within Domains, we know that the breaking and fixing of things is where the most learning can occur.

Framing breaking in a way that learning occurs however can be challenging. There’s a temptation (I still fight it) to simply swoop in and fix something for a student or a faculty member because it’s easier for me to do that than for me to teach them how to do it.

At UMW, I direct the Digital Knowledge Center, a peer tutoring center for digital projects and assignments and one of the values we try to embody is not just helping students fix problems but helping them understand why things broke in the first place. To be cliche, every moment in which we walk a student through a fix is a deeply teachable moment — a moment not just to provide step by step instructions but to narrate for them what each step means. When we bring meaning to the breaking and the fixing we are pushing beyond the boundaries of the merely practical.

What do students really learn when they learn how to fix the things they’ve broken on their domain? They learn a bit about how their site actually works. About the interplay perhaps between script files and databases. About how DNS functions (hopefully once they learn this they will teach it to me, because dammit if I know). Perhaps they will learn something about how a hacker can gain access to Web sites and why there is a burden on those of us who create on the Web to also secure what we create.

BUT —  from there they can extrapolate this to the larger Web they live on. They learn that for all its power the Web can be an exceedingly delicate space where a single misplaced semicolon can bring down an entire online resource and where a single missed security update can bring an online service to a halt. They learn that the Web isn’t magical but rather carved out of code that is as fallible as the humans who write it.

The Knowing of Things

When we start down these paths — these more complex paths and conversations about what it means to name and to build and to break and to fix, we come to a far richer place than just a space where students can build beautiful, rich, powerful Web sites. We are in the territory now of not just naming or building or even breaking but the territory of knowing the Web.

So I’m a word person and “know” (like all words) is actually an interesting word.

If you go to Merriam Webster (everyone’s favorite dictionary these days because they know how to do Twitter so well), you’ll get a fairly straightforward definition:

  • to perceive directly, have direct cognition of
  • to have understanding of
  • to recognize the nature of

I would argue that the most important goal of DoOO is to help students know the Web according to these definitions — we want our students to have an understanding of how the Web works, and we need to think about how we teach Domain of One’s Own so that this is achievable.

I want to talk now about a few lessons that I think we can impart to our students on the path to knowing the Web.

WordPress As a Symbol and a Choice

At UMW, the vast majority of our students’ work on Domain of One’s Own happens within WordPress, and increasingly I admit I worry about this. Don’t get me wrong, WordPress is still hugely popular and as I mentioned earlier there are estimates that it runs close to 30% of the world’s Web sites, but our dependence on it bothers me for two reasons:

First, as Web technology goes WordPress is ancient. This past weekend it actually had it’s 15-year anniversary. In other words, it’s almost as old as a college freshman. In Web time, that’s really, really old. Meanwhile, new technologies are changing how Web applications are built, resulting in faster, more agile publishing platforms.

The other reason I worry about our dependence on WordPress is that we run the risk of recreating the very dynamic that Domain of One’s Own seeks to challenge — an environment in which we lock students into a choice we’ve made for them by default.

I think it’s important that as we foster Domain of One’s Own on our campuses, we continue to look at the technical horizons. WordPress won’t be the industry leader or standard forever, and we need to be prepared to support our students in whatever new environments emerge. In addition, we need to find a way to make Domain of One’s Own as flexible as possible when it comes to facilitating student choice and agency. 

In the meantime, I think we need to remember that while WordPress is powerful and fairly simple to use (the primary reasons we tend to depend upon it) it is also useful as a symbol of what is possible on the Web. Learning WordPress should not just be about learning WordPress — it should also be about all the tacit lessons that go along with learning how to publish online in an open-source Web application.

WordPress should serve as an exemplar with which our students can grapple as a way towards a deeper understanding. The things they learn to do in WordPress are generalizable to other systems and other online spaces: identifying an audience; honing a voice; organizing and architecting an online space; mixing media to create compelling narratives; considering the interplay between design and content; understanding how Web applications work “under the hood” and how databases and scripts interact; adapting sites to consider accessibility and universal design; connecting disparate online spaces so they relate to each other in synthesized whole; adapting a site as it grows and develops in new directions; responding to comments and finding other spaces and sites upon which to comment; learning how search engines rank sites and how those search engine’s algorithms impact the findability of their own site.

When we teach WordPress we need to push beyond the practical skills our students must know in order to make the application work and into this territory of generalizable knowledge.

How Search Works

How search engines work is a great example of one of the ways in which we can help students to better know the Web. So yes, of course, search is ubiquitous. We and our students search so much that we don’t even stop to think about what search represents.

But if they are learning how to build on the Web they probably need to know something about becoming findable (or unfindable) on the Web. And by extension they need to understand how the power behind that findability is impacting the course of human history. 12 months ago if I had said that, some people would have rolled their eyes at me, but I think it’s safe to say that in the last 9 months we’ve all realized just how powerful algorithms are in shaping the outcomes of our culture.

Here’s a story I like to tell about the power of search. Many of you probably know it, but it’s worth revisiting. Back in 2010, when redevelopment of lower Manhattan was still ongoing, a new Islamic community center has been proposed about two blocks from Ground Zero. The center was to include an auditorium, theater, performing arts center, fitness center, childcare center, bookstore, culinary school, art studio, food court, and a memorial to the victims of the September 11 attacks.  And it included a prayer space for the Muslim community.

As the project moved through the review process it began to attract national media attention, and the attention grew into outrage in certain circles. As this progressed, the project started to become know as the “Ground Zero Mosque.”

The name was a misnomer, though. The Center wasn’t really a mosque and it wasn’t really at Ground Zero. And the name glossed over all the other services and programming that the Center would have provided for the community at large.

Some main stream media news outlets sought to rectify this by directing their reporters to not use GZM to refer to the project. But it was too late. Because the misnomer has propagated so widely, it was now how people were searching for articles about it. To make their articles findable, news outlets had to use the phrase Ground Zero Mosque.

In this particular case, Google worked as a kind of amplifier of distortion. And make no mistake, that distortion has real, discernible impacts on public opinion. The narrative about the Center became divorced from the reality of what it was actually meant to me — and the propagation via search of language that reinforced those misconceptions was partly to blame.

In addition to talking to students about cases like these, there are a number of simple exercises that I like to do about search that help demonstrate its power — having students do a basic Google image search for terms like “doctor” “teacher” “baby” and talk about what these visual results tell us about the representation of race and gender in our culture for example. There’s an important conversation to be had about how much search is reflecting back to us our culture, our culture as it is represented on the Web, or a version of either of those that has been filtered through a human-coded algorithm.

Much like the conversation about WordPress can be generalized, the conversations about search algorithms are generalizable as well. I would argue, in fact, that the algorithms of the Web are one of the least understood concepts that our students know nothing about. We need to be talking to students about where these algorithms come from, how they dictate what we seek, and how they have the potential to control our reality.

Consumption/Creation

In the aftermath of the 2016 election there’s been lots of attention paid to the ways in which our students consume and digest information. It’s certainly become clear that we have a lot of work to do, and to anyone who wants to really think about this topic deeply I would point you to Mike Caulfield’s work.

When the conversation around information access, consumption, and sharing was unfolding between last November and this spring in my various professional networks, I struggled with trying to understand how these issues intersect with Domain of One’s Own. I don’t think we can divorce a conversation about how the Web works with the conversation about how we consume and propagate information on the Web — particularly when we’re realizing more and more each day that that sharing and propagation has a deep and resounding impact on our lives.

What I would like to suggest is that consumption and creation are two sides of a single coin and that we must help our students to understand this. On a very basic level this is about teaching our students why what they share matters — whether that’s on their Facebook feed, Twitter timeline, or personal domain. Each act of sharing that we undertake is a moment in a larger narrative that spreads throughout the Web, pointing people towards truths that may or may not be real.

One of the simplest ways to approach this topic is a discussion about social media sharing. A few years ago in a first-year seminar that I teach, I asked my students whether or not they fact-check the things they share or re-share on Facebook. For the most part I got a rather lukewarm reaction to my question. They didn’t seem particularly concerned with whether or not what they share is true or not; what they cared about was whether or not it told a good story. I challenge you to pose this question to the students you work with or to ask the faculty you work with to pose it.

If Domain of One’s Own is about educating more savvy creators of the Web than don’t we have a responsibility to teach them the ethical implications of creative acts?

Beyond Uniformity

My own history of the Web has walked a strange line between conformity and individuality. In fact much of my life can be described between these two concepts.

I actually grew up in a 1960s era “planned community” called Reston (in Northern Virginia) where there was a prescribed palette of colors that people could paint their houses. And I mean prescribed — there was actually a color known as “Reston Brown” that you could buy at our local hardware store.

The result of this conformity was actually quite lovely. Reston was aesthetically uniform, pleasing to the eye, well-balanced and well-maintained. The very proportions of roads to trees to houses to roads to shops to lakes was defined, and you could feel this proportionality living in the town.

My first real Web development job was as Web director at a university out West where it was my job to bring uniformity to the myriad of department and college sites across the school. I designed templates and systems and training for getting people to use those templates. I sought to shut down a startup culture at the school that was resulting in sites built with decidedly unregulated palettes and proportions.

Now I live in the country so that I never have to be part of an HOA. We mow our lawn when we darn well please and it would never occur to me to consult a community handbook before changing the color of my house. And I help support and administer Domain of One’s Own at UMW — with the baked in value of empowering students to create their own individualized Web presence, free from the shackles of Facebook’s templates.

You could say I’ve been converted.

Yet I still struggle with how to balance supporting a system as complex as Domain of One’s Own without dictating how people use it. My anxiety about depending too much upon WordPress is wrapped up in this struggle. For the last two springs, I’ve been involved in a group that meets to assess student domains in our history department and american studies program. The exercise is enlightening. We find that often we can learn more about the assignment that a student had been given than about the student herself.

If we want Domain of One’s Own to flourish as a space for student agency than we need to balance structured guidance with playfulness and empowerment.

We need to provide useful guidance. We need to point students in those directions where we think that they can be successful, by suggesting applications they should install and use, by offering ideas of what elements to include on their sites, by providing feedback as they explore their own digital presence, but after that we need to be able to step back and get out of the way.

Finding Our Metaphors

I’d like to return to the idea of knowing and what exactly the word “know” means. In addition to the definitions I already talked about the OED defines know as

  • to recognize
  • to perceive as identical with one already perceived or considered
  • to be able to distinguish.

The fact of the matter is that Domain of One’s Own is hard to know, and it is hard to teach. It is easy, in fact, to know and teach it when our focus is on the practical goals I’ve discussed earlier: choosing a domain, building a site, even fixing basic problems we encounter with the sites we’ve built. These are skills that we and our faculty, our administrators and our students can pin down. They feel tangible; they feel knowable.

But perhaps the real power of Domain of One’s Own is when we recognize that the naming and building and breaking and fixing are all symbols of something greater, something more powerful and more binding than just practical activity.

Im struck more and more that in order to dive into these deeper waters of Domain of One’s Own we need to find language that lets us do so, and for me that’s the language of symbolism and metaphor and even poetry.

Around the office back when Domain of One’s Own was still new we had a running joke about Jim Groom’s favorite analogy for Domains: “It’s like a house.” While I poke fun at Jim’s house analogy, I’ve come to realize more and more that these analogies, metaphors, and symbols are the way that we can come to teach the Web so that our students know it in the sense of recognizing it — distinguishing it, perceiving it in relation to those things already known.

This past spring, I had the pleasure of leading an independent study undertaken by Meredith Fierro, (who just graduated from UMW and will soon be working at Reclaim Hosting). Meredith created a short introductory video for Domain of One’s Own for us to show to all of our incoming students at UMW, and to create it she interviewed a bunch of people about Domains. I gave her some advice as she was choosing the questions to ask, most of which were designed to get people to talk about what DoOO is to them and how they think UMW students can use it. But I snuck one question into Meredith’s interview. It didn’t make it into the final video; it wasn’t really appropriate for the video she wanted to create for her project. But it was really useful for me as I worked on this presentation!

If the Web were a concrete space, what would it look like?

This is the question that Meredith asked, and last week I went back and pulled together the answers that all of her interviewees gave — these are faculty, students, and alumni of UMW. And also Audrey Watters, because when Audrey comes to visit your school and you’re working on a video about Domain of One’s Own, you’d be stupid not to ask her to sit down and talk to you about it. And now I’d like to show you just a bit of what they said.

Moving forward I would ask that we all think about sharing the language we use to talk about these spaces. What does the Web look like? What does Domains look like? What metaphors for teaching these things can we bring to bear upon the conversations we’re having in our communities and can those metaphors help us to unearth deeper, untapped nuances to how we inhabit these spaces.

Web Literacy/Cultural Literacy

So where does this leave us? As promised, I don’t think I’ve offered any pat conclusions or nuggets of pure truth. But I hope I’ve said some things and shown you some things that have provoked you in interesting or frustrating or curious or meaningful ways. I hope that I’ve helped you to know a bit more about what we’re doing with this project we call Domain of One’s Own.

I would like to leave you with this: For many years, I feel like when the conversation about teaching the Web in our curriculums came up, there was not so much a pushback as a shrugging of the shoulders. A sort of general sense that it didn’t really “fit” with what we do in college and university.

We were about established academic disciplines and approved research methods. We were about rigor and deliberation. Yes we were also about creative thinking and critical thinking and problem solving, but always within a kind of framework of the academy. Even our consideration of popular culture was within a rigorous academic discipline.

The Web seemed well. . .just there. Interesting, visually pleasing at times, weird, always expanding beyond measure, inscrutable, and a bit of an opiate of the masses. I mean, how could we take something seriously that had birthed lolcats? 

Can any of us say that anymore? This powerful, relentless presence has been growing and changing for 20+ years — and it is changing us and our perceptions and our access to truth and our ability to make our world a better place to live in. And all along, we’re actually the ones who have been growing it and changing it, bit by bit, domain by domain, site by site, service by service. With what we build and what we share and what we sign up for and what we search.

The time came long ago for us to have a conversation in our schools and with our students about what this all means. If anything, I worry that it may be too late for this conversation. As Audrey suggests in that video, it sometimes feels like the Web is being torn down to make room for a parking lot — its been consumed by huge corporate, locked down silos. And as UMW professor Zach Whalen states at the end of my video, the Web sometimes feels too locked down, too clean. I would argue that the places where the web still feels messy and chaotic? Those are also the places that are the equivalent of the dark alleys that Professor  Parrish Watters alluded to in the video. Is the Web now a space that is so intentionally controlled by commercial interests and vile trolling that we no longer have a chance of reclaiming it as a space of ideas, a space of expression, a space of possibility?

At my heart I guess I’m an eternal optimist. Because, honestly, these days I feel like if I don’t hold onto that optimism with a steel grip, my own spirit would begin to feel unreclaimable.

So I will say that I think we have to double-down our efforts to have these conversations, and we need a foundation for that conversation. A space in our discourse in which we can grapple with the relentless, marvelous, complicated, monstrous space of the Web. I think that foundation is Domain of One’s Own. Yes, let’s build Web sites, but let’s also make the world a better place.

Messy & Chaotic Learning: A Domains Presentation at Keene State College

The following is the text of a presentation I gave at Keene State College on March 31st, 2017. 

When I was asked to come speak at Keene it was due, in part, to a presentation I gave last summer at Digital Pedagogy Lab Institute at Mary Washington. My presentation was titled Making & Breaking: Rethinking the Web in Higher Education, and the purpose of that talk was to disentangle a bit of the history of the Web within colleges and universities. My thesis was that we in higher education have spent far too long avoiding larger conversations about the Web: what it means to our culture and communities; how it’s re-shaping our social and political landscapes; how it’s altering the work of our individual disciplines; and, on a whole, what role schools of higher education should be playing in helping our citizenry understand all of these factors.

These are questions that have been troubling me more and more for the last ten years or so. I won’t claim to have been awoken to these concerns from my first forays onto the Web. It took being embedded in these digital spaces and in the spaces of my University for many years before I was able to begin to articulate these questions. What started as a general sense of concern had turned into a deeper and more overwhelming sense that something was very, very wrong with higher education’s general abandonment of the Web as a space that needs to be interrogated and interpreted.

Several years ago, along this journey, I was  in a meeting with a few like-minded colleagues, all of whom I deeply respected and many of whom were active, vocal members of the open education movement. When the topic of the Web, digital citizenship, digital fluency, and digital identity came up at the table, it was asked why we weren’t dealing  with these issues head-on in our curriculums, across our curriculum. And even at that table, with people who deeply understood the issues at hand, I remember a general shrugging of our shoulders, a sense of “Well, what can we do?” and, perhaps more specifically, a surety that our administrations and our faculties, more generally, weren’t ready to see a place for these kinds of conversations at the heart of our curriculums and institutions.

In other settings and conversations, the pushback I would hear was more targeted: What does digital identity have to do with college? Why do our students need to muck around in the code of the Web? Isn’t this kind of stuff in the area of “life skills?” Like teaching students how to balance a checkbook or dress appropriately for a job interview? What’s so special about the Web that we need to be bothered with understanding how it works on such a deep level?

In a sense, I’m sure that people who asked these questions were responding to the broader perception of the Web that many of us have: sure there’s some “serious” stuff that happens online, but, otherwise, it’s kind of cat memes all the way down.

When I did encounter academics who were working with the Web in deeper ways, it was often so focussed on a particular project, outcome, or product that there was no room for the broader or deeper questions about the essence of the Web. The work was traditionally academic in its intense focus and disciplinary loyalty. I’m speaking of projects that often are labeled as digital humanities initiatives. Now, I’m not trying to take potshots at DH. I actually love digital humanities as an approach and a discipline, but sometimes it felt like it failed to see the forest for the trees.

I think the talk I gave last August resonated with some people in suggesting that our responsibility to our students and citizenry is a different kind of engagement with the Web than we’ve been undertaking so far. I was pleased by this, and I sort of patted myself on the back and walked away.

But a few months later, something happened. In November, as everyone knows, in a rather shocking upset the U.S. elected Donald Trump president, and suddenly, almost overnight, the conversation about the Web changed. In the days and weeks following that election, it became clear that, at least to some degree, we owed the election outcome to a kind of structural deficiency of the Web that we had failed to really see. We had been so focused on our own news streams and social feeds that we had failed to see the deeper currents that were running through (and being directed through) our digital spaces. We had failed to see the forest for the trees.

In the aftermath, we find that we live in a post truth world filled with fake news and alternative facts. And all around us, people are pointing at the web as the engine that allowed all this to advance: it turns out that understanding how search engines work is really important; it turns out that understanding Facebook algorithms really does matter; it turns out that knowing how to create and disseminate information on the Web is a very, very powerful force.

And it turns out that we have a lot of work to do.

I want to spend a few minutes talking about how we got here, and to do that we need to consider the shape the Web has taken over the last two decades in our institutions. If we look at the Web we had to begin with, we can basically identify two competing spaces back to the mid to late 90s: The LMS and the tilde space. Let’s take a look at each.

The LMS, or Learning Management System, broke big on the scene around 1997-1998. Most of the earliest LMSs were actually built at schools, often under the guidance of faculty and  they focused their initial efforts on building systems for delivering content. In fairness that’s what the Web was really best at those days: it was a publishing platform, with the magic of hyperlinking built-in. Given those realities, it’s not surprising that the earliest LMSs were basically designed to distribute and share content. Eventually, though, vendors began adding other “management” features: grade books, internal email/messaging tools, attendance tracking. As the Web began to evolve, the LMS continued to evolve: vendors began adding tools for “pedagogy”: discussion boards, chat rooms, interactive tests and quizzes, wiki pages and group collaboration spaces.

The forces behind the LMS began to evolve too, turning away from internally managed projects within a particular school or consortium of schools. Instead you saw the emergence of large companies: Blackboard, WebCT, Angel. Their roots may have been in higher education, but their future was in capturing a marketplace, and to do so, they touted a very particular kind of Web environment for teaching and learning. Their spaces were standardized, their features were streamlined. Your students experiences would also be standardized streamlined: predictable.

This is also, in fact, not surprising. These are large companies we’re talking about now. For their business model to succeed they have to streamline a product they could seamlessly deliver to schools. And to make this work they need to “sell” us on the idea that this streamlining and standardization is actually what’s best for our students and our classes. When we’re talking about management (email, grade books, file sharing) perhaps streamlining and standardization isn’t so bad (I’m not sure about that, but I’m willing to concede it for argument’s sake). But when the LMS goes beyond merely providing administrative and management features and instead is offering features designed (perhaps badly) to build community, share information, and collaborate with others, it is obviously influencing pedagogy.

Frankly, we don’t acknowledge this nearly enough when we talk about the technologies we use in education. We like to think that a tool is easily defined by its basic functionality: discussion board, wiki page, synchronous chat, quiz builder. But all of these tools are of course far more complex than that. They’ve been designed and coded and engineered by companies to provide functionality in very particular ways. And that design and code guides our students’ and our experiences through their use. 

Imagine, if you will, if someone told you that from now on when you conduct a discussion in your face-to-face classroom you are bound by a series of rules, procedures, and steps. You must follow those at all times, and, everyone else at your institution must also.

That’s right: From now on, every classroom discussion at your school must be conducted or created using a predetermined set of rules, procedures, and steps. If you don’t like them? You’ll have to wait and see if the next update to them addresses your concerns. You would probably balk at this suggestion — and you should.

But rules, procedures, and steps are exactly what code defines, and when we fail to acknowledge this we fail to see the pedagogical power that technology and the LMS can have in our classroom.

So the LMS underscores and codifies a set of beliefs and values: with our courses we should build standard interfaces, provide standardized features and tools, and promote, among our students, the expectation that their experiences from one course to the next will be, standard and predictable

I teach a first-year seminar at the University now, and I advise these students as well until they declare their major. I have conversations with students who are completely flummoxed when a professor doesn’t post their course content, assignments, and grades in our learning management system. If the grade book isn’t being used? The students have no idea how to determine what they’re earning in the class. If assignments aren’t posted (with system prompts that text them when they’re due), they forget (or think they can ignore) the work. If a reading isn’t in the system, rather than ask where they can find it, they assume it’s a mistake with the system, and come to class unprepared.

We can sit here and talk about how this is a sign that our students are underprepared and lazy. We can bemoan the special snowflake culture or the helicopter parenting movement. But make no mistake: our students are learning these cues from us. Our institutions and the systems we buy are sending them messages about how we do school. They believe they’re simply following the straightforward, streamlined rules, procedures, and steps we’ve told them to follow.

Lest we think the solution is simple (“let’s simply back out of the LMS”) let’s talk for a moment about the infiltration of these companies into our schools (and the messages THAT sends to our students). I think this infiltration is insidious:

At first, the LMS seemed like a nice convenience that allowed us to easily share files that we otherwise would have printed (I used to refer to this as “digital Kinkos”) . Oh, and an online interface for calculating grades that we had been calculating by hand or in a an Excel spreadsheet.

But isn’t it nice how we can now push those grades straight from the LMS to the other system our school uses to manage student records and transcripts? Isn’t that nice. Oh, and look they’ve added a tool now for quizzing. Well that seems useful? If it meant we had to rewrite a few questions to fit the form that the LMS used, well that wasn’t so bad, was it?

Oh, look, the LMS has a discussion forum and now it allows us to track how many times each of our students have commented on each thread. That MUST be useful, right? No? Well, then let’s find a way to make that useful in our grading and assessment of students’ work.

Funny, the company that makes our LMS system now has a partnership with this other company that will scan every assignment our students turn in and check if it’s plagiarized. Hmmm. That seems a bit. . .much? But, we do want to know if our students are plagiarizing, right?

And NOW they have a partnership with a global marketing and data collection company so that they can provide identity verification for test proctoring. Well, we don’t want our students to cheat on tests, so I guess that’s okay, too.

Finally, the LMS company offers a product for creating and managing our students school ID cards and, what? The laundry and vending machines on campus? Um. OK?

The narrative spins out of control. Simultaneously, we are allowing a corporation to deliver a coded set of tools for us to improve our pedagogy — whether or not that’s what we want to do with our pedagogy — while also turning over our students’ work, data, and information to this corporation and its partners. All of this so that our and our students experiences can be streamlined, predictable, straightforward. . .

So while the LMS was emerging in the mid to late 90s as an online space for faculty to embrace in their teaching, many universities were also spinning up another kind of space, affectionately called the “tilde space.” Schools like mine, Mary Washington, provided faculty and students with their own tilde space where they could post HTML documents. And some faculty did use those spaces for students to publish on the Web. My former colleague at UMW, Jim Groom, has done a lot of writing and thinking about the history of the tilde space. Tilde spaces actually predate the LMS. Jim’s done some informal polling around his personal network and heard from faculty who had them as far back as 1993. And with the magic of archive.org’s Wayback Machine, we can actually find Mary Washington’s directory of student and faculty sites.

In fact, I was able to find Keene State’s as well.

In addition to predating the LMS, the tilde space lived squarely within the complexity  of the Web (from Jim’s blog):

The following image  is a scan of a tutorial. . . Jim Greenberg wrote about creating personal web pages at SUNY Oneonta. If you read it, you’ll notice users had to create the www directory, change permissions, FTP files, write HTML, etc. In other words, creating and managing a personal webpage on universities servers back in the mid-90s wasn’t simple.

Tilde spaces were our schools’ first responses to the Web. They were messy, complex, and chaotic. And, they were quickly overtaken because as the Web evolved our institutions didn’t keep up with evolving those spaces. We didn’t add scripting or database features, for example, and so the spaces became technically irrelevant and obsolete. And instead of putting our resources and skills into imagining what those spaces could become for teaching and learning, we continued spending more and more money on Learning Management Systems and the other services the companies that made them offered (or partnered with).

So that’s my brief, somewhat cursory history lesson for today, because I think it’s important to understand where we came from in order to understand where we are.

The bottom line is that I think we abdicated our responsibility in higher education. We allowed ourselves to believe that within our schools the Web was easily understood as a commodified, vendor-managed space in which we could just skim along the surface. We could sit in the walled gardens of our learning management systems and, with that, believe we were “teaching online.” Meanwhile, the Web was evolving into a massive, amazing garden of marvels and monstrosities. Thinking the marvels were merely entertainment and the monstrosities were merely “fringe,” we decided we had no greater responsibility to our students, ourselves, and our citizenry than to stay in our walled spaces, posting PDFs and counting discussion board comments.

Beneath all of this is still a tension, though, about teaching and what we believe learning should feel like for us and our students. Through its coded spaces, the LMS values a learning experience that is as streamlined and predictable as possible, and, thus the teaching we do in the LMS never addresses the Web below the surface. What spaces can we imagine on the Web that might push us deeper?

At Mary Washington, our first foray into exploring the Web as a space not of predictability, but as a space for possibility happened in 2004. in August of that year, every member of my department (the Division of Teaching and Learning Technologies or DTLT) got a domain name and open source Web hosting. We went from having one tool in the toolshed (the LMS) to many, many tools from which we could choose.

The tools themselves were open source applications — applications for creating Web sites in many different flavors: blogs, discussion forums, media galleries, wikis, even open source learning management systems.

In addition , we were working in a space where, if we wanted to, we could learn to build our own tools, or at the very least we could adapt the tools we had.

Suddenly, the Web felt accessible to me in a way it had never been before. I had complete control over a slice of it, and I dove into understanding how it worked. My colleagues and I all started our own blogs. We began experimenting with open source community building platforms as a way to connect our department since, at the time, we all worked in different buildings. We began building custom learning spaces for courses, based on partnerships with faculty.

For me, working in open source, on the open Web made possible all the things I had imagined back in the 90s, and it challenged all of those beliefs and values that the LMS underscored. It was possible to build learning environments that empowered students, and not necessarily to the detriment of the course. I could create learning environments in which the interfaces, tools, and features were customized to the needs of the professor and students. And there was simply no reason to assume that the experience from one course to the next needed to be standardized. Open source was infused with a different set of values and beliefs: co-construction, iteration, fast prototyping, extensibility, and, well, openness.

It was probably within three years that we began to ask the question “What if every faculty member and student had this? Their own domain name? Their own Web space to build what they want or need? What would happen and what would change?”

Eventually these questions would lead us to a project at UMW called Domain of One’s Own, but there was six years of further development before we got there.

Within our personal Web spaces, the application that captured our imaginations the most was an open source blogging platform called WordPress. WordPress was popular back then; it’s even more popular now. Some estimates suggest that it powers close to 30% of the Web. Within WordPress, users can use plugins and themes to extend and alter the application. Themes let users change the way their site looks; plugins let them change the way it behaves. This extensibility of WordPress is why it has become, for me, a game-changer. When faculty or students have something they want to build on the Web, I can almost always figure out a way they can achieve it with WordPress.

In 2007, we developed a multi-user blogging platform for UMW that was built on WordPress, called UMW Blogs. The system makes use of a special flavor of WordPress called MultiSite which allows us to administer a single core code instance that governs as many individual sites as we need. In other words, we only have to upgrade it in one place. UMW Blogs has been hugely popular for us; in the nine years since it launched, it has had almost 13 thousand users and it now contains 11 thousand individual WordPress sites.

Students have used UMW Blogs to create literary journals, survey properties around Fredericksburg, build online exhibits, connect with the authors of the works their reading, publish their poetry, develop in-depth online resources, and, of course, to blog.

UMW Blogs allows us to give any member of the UMW community a WordPress site — really as many WordPress sites as they want. They could activate whatever plugins or themes they wanted (as long as we had made them available), which meant they could built pretty highly individualized, sites. We were quickly moving out of the territory of predictability and into a messier more chaotic space for teaching and learning online. However, within UMW Blogs we still controlled the underlying code. We decided what plugins and themes are available, and we were the ones controlling when upgrades happened. We needed to push ourselves even further.  

In 2011 I became part of another project that did just that. That spring, I was scheduled to teach a computer science class in digital storytelling alongside Jim Groom. Jim had taught the class face-to-face for two semesters, but he wanted to do something bigger that spring. He suggested we open the course up and allow anyone on the Web to participate. I gamely agreed. This, was the birth of ds106, a digital storytelling community, and I want to tell you about a few pieces of that experiment that were game-changers for me.

First, we decided that every student at UMW participating in ds106 had to get their own domain and Web hosting for the class. We knew they were going to be publishing their work on the Web, but UMW Blogs wasn’t enough. They had to fully own their own space. In fact, owning that space, building out their digital identity, and understanding the ensuing narrative would become a crucial, critical piece of the ds106 experience. This notion is one of the ideas at the heart of ds106 and DoOO.

The other thing we did in ds106 was massive syndication. Every participant, whether at UMW or elsewhere, has their individual blog syndicated into the main ds106 site where posts can be filtered and viewed by specific categories and tags. We had been experimenting with syndication for quite some time in UMW Blogs, but never on this scale, and we’d never brought together a community quite like this before. Posts from my students were interwoven with Jim’s students and with those of our open participants all over the world.

That commitment to massive syndication and massive openness became a core value of ds106. And the dynamic of having open participants in the mix with our UMW students changed the nature of how we and our students thought about teaching and learning.

My colleagues in the ds106 community from other institutions often helped my students or gave them feedback before I did. In future iterations of ds106, we’ve had our students collaborate with open participants on large projects, like producing a radio show as well as participating together in synchronous hangouts.

UMW students in ds106 come away with an understanding that there is absolutely nothing standardized about their experience.

Right off the bat in ds106 we knew we wanted to turn the idea of media assignments on its head. Jim, in teaching the course face-to-face, had ten to twelve specific assignments that he would have the students work through, grouping them around particular media genres or storytelling approaches.

We decided early  on that we wanted to blow that model up. And in the vein of massive openness, we built an assignment bank that allowed anyone to submit an assignment idea. They provide a name, a description, an example, and a difficulty rating (one to five stars). We publish it on our assignments site.

When we teach ds106, on a weekly basis we tell people how many stars of work they need to complete. Our students get to choose which assignments to do to meet that goal. When they finish an assignment, they publish it on their own site, and, through the magic of massive syndication, we pull it onto the individual assignment page so future visitors can see how others went about completing the assignment. As of today, we have almost 1000 assignments in the assignment bank and 11 thousand submissions.

I mention ds106 here because it was such an important stop on the road to what would eventually be Domain of One’s Own. It validated for us that students were capable of working on the open Web, building and managing their own spaces. And it confirmed for us that we needed to make this all happen on a much larger scale.

In fall 2012, we began to pilot DoOO and in fall 2013 the project was funded. Today, any UMW student can get a domain name (for the duration of her time at UMW) and open source Web hosting alongside it. Faculty and staff also have access to the project.

Domain of One’s Own has some critical properties that I think embody it’s uniqueness as an exploration of technology in higher education, and I’d like to focus on four of them:

THE NAMING OF THINGS

The very first step in signing up for Domain of One’s Own is choosing a domain name for yourself. We have few limitations on what our faculty and students can choose. We do restrict them to four top-level domains (primarily to ensure that pricing remains consistent): .com, .net, .info. and .org. Beyond that the sky’s the limit, but we offer guidelines.

We suggest that if someone is really interested in being findable on the Web, they have their domain name reflect their first and last name. That’s because, search engines tend to give higher rankings to sites that reflect the search query in the actual URL.

Conversely, if one doesn’t want to be found, we recommend they leave their name out of their domain. That’s correct: within Domain of One’s Own there’s no requirement that students or faculty make their identity publicly knowable. In fact we believe that one of the primary tenets of Domain of One’s Own is that participants be able determine for themselves how they wish to be known and found on the Web.

Beyond whether or not to include their name in their domain we give students some other suggestions. They might use a hobby, a sport, a favorite line from a poem, play or song, really any word or phrase that is meaningful to them as their domain name. I also usually recommend they pick a domain name they could comfortably share with a grandparent today and they could put on their resume when they graduate.

In the end our goal is for the naming to represent a moment of taking ownership: a consideration of what a thing is through its naming.

I believe there’s something actually metaphysical about the act of naming a thing. I believe that on some level it’s the naming that helps call a thing into existence. For many of our students this possibility of creating a space for themselves on the web that they not only can build but that they can actually name represents an opportunity that they’ve never had before. It certainly represents an opportunity that is nothing like anything else we’re asking them to do on the web within the context of their higher education.

As I was preparing for this presentation this past week, I was reading an article on CNN about a new kind of cloud that meteorologists have named.  The name of the cloud is the asperitas cloud, and it’s just been added to the official International Cloud Atlas (yes, that’s a wonderful thing I learned exists). The name comes from the Latin word meaning roughness, and the cloud is identified as having “localized waves in the cloud base, either smooth or dappled with smaller features, sometimes descending into sharp points, as if viewing a roughened sea surface from below.” At the end of the article, there is this quote  from author and meteorologist, Gavin Pretor-Pinney :

When we know the name of something, we began to know it in a different way and when we began to know it, we began to care about it.

This quote resonated deeply with me because it captured exactly what it is that I think the naming of a domain represents. In choosing a domain, we hope that students will begin to know their place on the Web differently, and in that knowing, we hope they begin to care, as well.

THE BUILDING OF THINGS

In addition to the domain name that we pay for while students are at the Mary Washington we also give them space on an open source LAMP web server. The LAMP part stands for the open source technology stack that sits on the server (for those of you who was interested). That would be Linux, Apache, MySQL, and PHP or Perl or Python as the scripting language.

We choose this stack very deliberately. For one, the open source platform embodies, frankly, openness: the applications that students can install here are all open source meaning that their code is readable and modifiable. We also choose the open-source platform because it is inherently portable for when students graduate. They can take what they build with them, if they so desire.

For the most part what students do in classes that engage with Domain of One’s Own is build things. They build web sites, primarily using WordPress which is an application that we have deep knowledge of Mary Washington. But they’re not limited to WordPress. We have students in computer science classes who use Domain of One’s Own as a platform for building their own custom applications. We have students in history classes who install the open-source collection and curation application Omeka.  Over the last couple of years we have had a number of students in our digital studies program experimenting with Known: an open source application that lets you distribute your content across various web sites and social networks.

The building of things. The building of websites. This is absolutely the core activity of Domain of One’s Own at Mary Washington. For many of our students they’ve lived on the web their entire lives — literally as far back as they can remember they have always been engaged with the web in some way. I take a survey in my freshman seminar of students’ earliest memories of the web and they regularly are able to recall websites that they used when they were in kindergarten, 1st, 2nd grade. They’ve lived on the web their whole lives and yet they have lived primarily in spaces that have been controlled for them by media conglomerates, television networks, schools, social networking companies. Many of them have never had the to opportunity to take back that control and build something from scratch on the Web.

When Domain of One’s Own first started one of the things I would frequently say was that I wanted students to realize that the web was not something that was happening to them but something that they were creating. Because the reality is they are creating things on the web right now. Every day they’re contributing posts to Facebook, pictures to Instagram, links to Pinterest. They’re creating content all the time but they’re not doing it in their own spaces. They’re doing it in spaces that have been created and curated and programmed and coded for them. Domain of One’s Own is about giving students a space where they build something that is by and for themselves.

THE BREAKING OF THINGS

So if you haven’t realized by now there is nothing inherently streamlined or predictable about Domain of One’s Own. In fact, much like the tilde spaces of the early 90s that Jim described in his blog post, managing a domain is not simple. Users have to grapple with some complicated technical concepts and tasks, particularly when things go wrong.

When I talk to faculty about Domain of One’s Own, this part of the project is often what gives them the most anxiety: What about when things go wrong? What will I do? What will my students do?

Sometimes it feels like people would like me to tell them that actually we at UMW have developed a foolproof system for ensuring that things never really break, or at least not in any kind of serious ways. Or that we have a tool that we use to fix the really bad breaks, really quickly.

We haven’t and we don’t.

The truth is that things go wrong, and they go wrong in all kinds of ways.

First, there’s the technical kind of “going wrong.” Here’s a rundown of just a few of the technical problems that arise when students are working on their own domains:

  • They install a plugin that doesn’t work with their version of WordPress. The site loads as a blank white page.
  • Their WP upgrade fails. The site starts showing random code instead of a site.
  • They accidentally delete the wrong application.
  • They upload an image to their site that is too big; it breaks the display of everything so their site becomes unreadable.
  • They upload a theme that doesn’t play well with a plugin they’re using; things stop working properly.

The list goes on and on. On any given day, some new kind of problem can and will arise. Luckily at Mary Washington we’ve developed ways to deal with these issues.

At UMW, we address this complexity in part through the existence of the Digital Knowledge Center, the tutoring Center I run where students can get one-on-one peer support. But while the DKC is one model for supporting a project like this, it’s by no means the only model. Other models that embrace adaptability, peer support, and a commitment to understanding not just how things break but WHY they break can work as well.

The anxiety  that faculty express to me about open online spaces like Domain of One’s Own is not merely about the technical aspects of the project. They worry about other types of things going wrong. What if students, for example, post things they shouldn’t? What if they embarrass themselves, their instructor, the institution? What if they make big, bad mistakes, publicly?

I’m sensitive to these concerns, but I think we need to consider this challenge differently. The bottom line is that there is no keeping our students off the Web. They are on it all the time. I guarantee they are already making mistakes. Who is going to have their back as they figure this all out? Who is going to help them understand when they’ve made a mistake and how to fix it? I believe we’re the ones who have to do this. I think it’s our responsibility. We have to forge ahead, despite our fears, and we have to be ready to have those difficult conversations with a student when she overshares, when he says something that could be considered offensive, when they post something they’ve written that is half-baked and not ready for primetime.

I would rather have that difficult conversation with a student now about a comment they left that comes across as racist, or a biased news article they shared, or a half-baked idea they espoused.

I would rather unpack that with them now. I would rather talk with them, listen to them now. I would rather do all of that now if it means that somewhere down the road, when they’re out there in the “real world” they think twice before making an offensive comment, sharing a biased piece, espousing a vile idea, or trusting a false prophet.

THE KNOWING OF THINGS

I started this presentation by talking about ways in which I think we have abdicated our responsibility in higher education to really grapple with the Web as a space to interrogate and interpret, and I want to circle back to that now. Because, in all the talk about Domain of One’s Own, I think it’s easy to get bogged down in the naming, building (and the breaking) to such a large extent that we begin to see the project purely as one aimed at helping students build a product. And, surely, it is that ability to build something that so many students (and faculty) find particularly compelling and enticing. And, from a practical standpoint, there is something quite wonderful about students graduating from UMW with a rich portfolio of their online work, a digital resume that they can share with future employers or graduate programs. These products matter.

There are other practical aspects to Domain of One’s Own that matter as well: WordPress, which I’ve already mentioned several times and which so many of our students use and learn, is a powerful force on the Web. Because it is used by so many sites, learning it is an actual marketable skill that our students can include on their resumes. This matters, and it’s worth pointing out and emphasizing to our communities.

But let’s talk about the other side of Domain of One’s Own. Let’s talk about the more philosophical underpinnings of the project — the notion that we are pushing our students to develop a deeper understanding of how the Web works and why that matters to us in 2017. Let’s return to WordPress for a moment. WordPress is, indeed, a specific, popular content management system. But even if it wasn’t the most popular, or, even if some other open source tool were to overtake it in popularity in the next four years, that doesn’t mean the experience of learning it loses value for our students, not if we approach that learning in a particular way.

For WordPress can actually serve as an exemplar, a symbol with which our students can grapple as a way towards a deeper understanding. The things they learn to do in WordPress are generalizable to other systems and other online spaces: identifying an audience; honing a voice; organizing and architecting an online space; mixing media to create compelling narratives; considering the interplay between design and content; understanding how Web applications work “under the hood” and how databases and scripts interact; adapting sites to consider accessibility and universal design; connecting disparate online spaces so they relate to each other in synthesized whole; adapting a site as it grows and develops in new directions; responding to comments and finding other spaces and sites upon which to comment; learning how search engines rank sites and how those search engine’s algorithms impact the findability of their own site. This list goes on and on, and it leads us to a more fundamental conversation about the Web and it’s place within our classrooms, our disciplines, and our culture.

I’ve begun to think that we need to push for an approach to the Web that considers it as space that begs of us an interpretive approach. Much like in our specific disciplines we learn how to interpret text, research, data, stories, art, I believe we need to approach the Web as an object of this kind of interrogation and consideration. The Web is not merely the content we read or view. It’s not merely the sites we browse or post on.

It is a structured space, coded and built by humans with identities, biases, leanings and agendas.

It is an evolving space, one that we will have to always be chasing after in order to understand where it might be headed next.

It is a commodified space, in which corporations are determined to make lots and lots of money through advertising, content dissemination, journalism, digital services. . .

It is a political space in which power and access is not evenly distributed, and where people and groups will always attempt to consolidate and reinforce those power differentials.

It is neither an inherently good or bad space, but it can, through its marvels and monstrosities, provide amazing and terrible experiences.

It is not streamlined or straightforward or predictable. It is messy, chaotic, wonderful, and awful.

This is the Web we need to grapple with, for our students’ sakes as well as our own. And there is still so much work we have to do.

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 http://umwdomains.com 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 community.umwdomains.com 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

tales of swimming upstream