3D Social Networking (Photo credit: StockMonkeys.com)
We all take it for granted that when you join up with a university, they give you a shiny new email address with a .edu address to help you communicate with the other students, faculty, and staff. This one shared communication network unites a university, making it possible to reach anyone instantly. As our options for online collaboration grow more varied and sophisticated, should your school provide your social networking, your collaborative documents, your video chat, and your blog? Or should everyone use the tools they like best, irrespective of what everyone else is doing? What if those tools don’t play nice with each other? What do you do if you want to use Google Hangouts but your classmates all use FaceTime?How do we keep our classrooms and workgroups from becoming Towers of Babel, with everyone speaking their own language in utter isolation? This post will seek to examine the merits of both approaches and try to find a middle way between a centralized cloud infrastructure and a user-centered “do it yourself” approach to online social collaboration.
The Case for Togetherness
I imagine the ideal configuration for a school system looks a lot like Google Apps– where everyone in the organization has access to a full suite of powerful, modern tools that meet most people’s communication and collaboration needs. It includes email (Gmail), cloud storage and collaborative documents (Google Drive), instant text and video chat (Hangouts), blogging (Blogger), wikis (Sites), and social networking (Google+). Everyone is on the same “network”, which makes it easy to find your colleagues and classmates without first trying to figure out what tools they’re using. Everyone’s email address and online handle follows a predictable formula like [first name + lastname @ schooldomain.edu] that is easy to guess so you can quickly and easily invite people.
I have experience working in a Google Apps environment after recommending that Envision Schools switch to it in 2006. The fact that everyone had access to the same powerful set of tools made it easy for users to teach each other how to solve common problems. There’s no confusion about “which tool should I use to do X?” because all of the included Google tools offer good solutions for most collaboration needs. The overall effect was of “a rising tide lifting all boats” where students and teachers of all skill levels could build their tech skills from their current level of expertise.
Downsides of Togetherness
Though we didn’t experience it, there are some possible downsides of having your whole school community on one all-encompassing tech ecosystem. Using the school’s provided tools brings issues of free speech and intellectual property to the fore. Who owns the communication that happens on the university’s network? What expectation of privacy should users have when they’re using provided tools? How can your users get their data back when they leave the school? Providing technology tools requires you to develop good answers to these thorny questions, and possibly re-examine your school’s existing policies and practices around these issues.
Similarly, you should check the Terms of Service for any tech tool you use to see if they have any restrictions on users’ intellectual property, freedom of expression, or ability to take data back out of the system. Cloud services vary wildly on these details, and you can easily find yourself trapped in your software’s terms of service if you’re not careful.
Another downside of offering all-encompassing tools can come if the tools themselves are not as appealing and powerful as the great free Web 2.0 tools available to consumers. Your school may provide (and require everyone use) tools that just aren’t that good. Clunky email, an outdated Learning Management System, and kludgy collaboration tools that leave your users more frustrated than productive can impact your whole school culture for the worse. In this type of scenario, users do not feel empowered to bring their own tools into the environment, and they are not motivated to use the in-house tools. They fall behind.
If this sounds like the situation at your school, you may want to have a critical conversation about what’s working and what’s not. You may find that your power users have been secretly using consumer tools for their collaboration. You may start envisioning your school’s online networking as a hybrid approach between the tools that are offered and the powerful tools that tech savvy consumers can bring from home.
The Case for Distributed “Do It Yourselfer-ism”
David Weinberger conceived of the web as “Small Pieces, Loosely Joined“, and posited that the web’s distributed architecture is its greatest strength. Do we really need “one big collaboration system to rule them all”, or should we encourage users to be, in Gardner Campbell‘s words, “systems administrators of their own digital lives“? Encouraging your users to develop their own skills in evaluating software tools to solve problems is arguably an investment in them as lifelong learners. Users who will one day leave your school’s tech ecosystem need to have a “digital toolbox” of software that they can use to be productive anywhere– not just at your school with your specific mix of devices and software. They need to know how to find and evaluate new types of software in response to new challenges, avoiding malware, and matching the tool’s features to the problem at hand.
In practice, this can look a lot of different ways. You can offer your full suite of enterprise tools with the understanding that people are free to use the tools they like best. This is what most universities look like today– students filling in the gaps with their own personal gmail, twitter, facebook, and google docs accounts to meet their needs in a way that makes sense for them.
You might even decide not to provide certain types of tools, but rather encourage your users to explore the many great free options available to consumers. As an example, our LMS Canvas has stated publicly that they have no plans to add a blogging tool into the LMS– if you want a blog, use WordPress, Blogger, Tumblr, or any of the other great options. In this scenario the school (or the LMS) only needs to be able to interoperate with whatever tools the community decides to use. For example, Canvas allows students to submit assignments via URL so they can basically post their work anywhere on the web and just turn in the URL. You don’t need to mandate which software everyone’s using as long as they can post publicly to the web.
Another approach to distributed way of working is the Domain of One’s Own from University of Mary Washington. In that program, faculty, staff, and students are given their own personal cloud server space full of powerful open source tools that they can easily employ to solve common tech challenges. They build skills in administering their own online tools and take ownership for providing their own software solutions.
Downsides to Cobbling Your Own Tools
The obvious drawbacks to this distributed approach are that there is very little consistency from one user to the next with regards to the tools they use, the file types they’re working with, and the ways they collaborate. For the school’s IT department, this makes administering, securing, and supporting users extremely difficult. Giving users too much leeway to configure computers opens the doors to malware attacks and other unexpected behaviors. If the institution has a mandate to collect and preserve student work or faculty publications, that is made more complex when they “live” on various distributed cloud services.
People tend to be short-sighted in choosing technology tools, and fail to ask themselves “what problem am I trying to solve?” They think of tech tools as “better” or “worse” than others without touching the question “better for what?” This leads to challenging conversations about which tools we should use to collaborate– an early stumbling block that keeps people from actually collaborating. Often people are reticent to sign up for a new account or start yet another social network just so they can communicate with collaborators. This means that everyone starts smaller circles of collaboration and it becomes hard to send a message that reaches everyone.
The final downside to asking average users to evaluate and maintain their own technology tools is that lots of people hate doing that. Not everyone enjoys the process of auditioning new products and finding ways to solve problems with them. Struggling tech users sometimes prefer to just be told which tools are good to use so they can get on with their other job responsibilities. For these users, there needs to be some basic infrastructure in place so they can just get things done. Acknowledging that not everyone is an enthusiastic tech user means recognizing that we can’t rely on users to bring their own tools all the time.
So what’s the best approach?
It seems to me that schools should provide a basic layer of functionality that anyone can use to be productive and collaborate online. From activities like email to collaborative documents and video chat, you want to at least offer some viable solution that will meet all these (very common) needs.
You don’t want tools that restrict who you can communicate with by limiting connections to only within the organization or only working on certain platforms (Windows, Mac, iOS, Android). Wherever possible, your communication tools should be able to include people inside and outside of your organization, as well as uniting people of all different roles within the organization.
This is easiest when you and your colleagues are all using the same tool (or at least tools that talk to each other nicely). It’s challenging to get everyone to agree to use the same tool unless it’s an organization-wide expectation to do so. If you’re OK with smaller groups agreeing to do what they want, just know that this may come at the expense of cohesive communication. Schools may have overlapping communities on Facebook, Twitter, Instagram, and an internal tool like Yammer, but it will be harder to reach everyone on all those different networks.
Even if you offer a suite of tools, encourage users to explore their own solutions to tech challenges and integrate those into their workflows. Your power users will thank you for this, and will probably bring good ideas into the organization. However, be aware of where their data ends up– make sure that people using cloud tools periodically back up their work on university servers so there are records of their contributions. That way, the institution can still benefit from the work they’ve done. You may even want to train people to evaluate 3rd party tools, looking for methods of exporting their data to work with the existing tech infrastructure.
Wherever possible, embrace open source tools that interoperate nicely between various platforms and open document types (like ODF). These can make it easy for various tools to share documents where proprietary solutions like Apple iWork and Microsoft Office require their own document ecosystems.
Liked this post? Follow this blog to get more.
