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.