A combination of the Bring Your Own Device (BYOD) “movement” and the rise of widely-used, highly-effective third party communication systems (eg – Gmail over whatever your company/institution is using) has created what I see as a conflict about whether to support people that you’d call either early adopters or ones that have gone off on his or her own and away from standardized systems.
First, some general definitions and stuff. BYOD has arisen mostly because incredibly powerful computing devices have hit the mainstream. Tons of people have smart phones (though the actual % is lower than you might think – recent surveys indicate that a solid 30-40% of cell phone users have, at most, “feature” phones with keyboards or some other extra feature for faster texting, but no web browsing or anything like that. Many others just have flip phones for regular calling). Lots of people have tablets. And laptop ownership went past 75% a long time ago. So with all of these devices already in our pockets and bags, we have to start considering the ramifications of so much computing and productivity power being brought to our campuses and work places, rather than being provided by. A computer lab might need to be only half the size of just 2 years ago, with empty desk space being far more useful for students and their own laptops, etc.
Even though AOL first offered its own e-mail system a very, very long time ago (I was on AOL starting in 1994-1995, and I remember it had not yet purchased Compuserv), the massive shift to yahoo and google for personal e-mail also causes an issue. In the same way that we have to consider that users have their own devices which they prefer to use over the ones we provide, we must also be aware that one’s well-established gmail account might supersede the benefits of an organizational e-mail system (or calendar system, or chat system, etc). Yes, for work purposes there is the issue of separating official from personal e-mail but the lines get more and more blurred, even for employees, as adoption of these other tools gets higher and higher. Investment into one’s personal gmail account gets so high that his or her identity is based on that account, not the name.edu or company.com one.
We have faculty at Santa Clara Law – people who are scholars associated with an academic institution – who use their gmail accounts with gmail.com suffixes over their scu.edu accounts. I recently worked with a few marketing folks that asked me to contact them on their yahoo and gmail accounts instead of their company ones, because it was faster (and easier to get to one their phones, etc).
A lot of the two movements go hand-in-hand. Because it’s so easy to connect an Android phone or iPhone to gmail, people prefer to have that account when “on the go.” As they are more and more mobile, more of their e-mail goes to those “non-sanctioned” accounts. As more goes there, less goes to the official one. And so on.
As we look towards a shift to a new e-mail and calendaring (and collaboration) toolset at Santa Clara University, those faculty that switched over to gmail will in fact be left “out in the cold.” They are using the “commercial” version of gmail, and we’ll be using the “educational” version of either Google or Microsoft’s cloud-based solutions. Even if we go with Google, there is no migration option from a personal, commercial account to an institutional, Apps for Education one.
So…in a way, we are punishing those that adopted these highly-productive tools (gmail, gchat, etc), potentially a side-effect of early adoption of highly-capable devices (smartphones, tablets). We are penalizing early-adopters.
Yet we rely on early adopters to push the envelope, to ask the questions that those only one standard-deviation away from the mean have not yet considered, and to help motivate and inspire us to do more and be more creative.
How do we resolve this conflict? Do we create an environment that encourages early adoption? Many times it is these individuals that help instructional technologists (or just plain technologists) try new things and work out the bugs. But what happens when we switch to a standard that leaves them out in the cold? What safety nets do we provide? If none, then do we risk fragmentation (aside from dissatisfaction, of course)?