It's a matter of policy.... - Digital Learning

Thursday 6 September 2012

It's a matter of policy....


Like another eight or so Institutions around the country, Sheffield has relatively recently become a full “customer” of Google Apps for Education (GAFE). After moving our student email service to Gmail in 2009, and then a phased transition of our staff email service about 12 months ago, we then enabled Calendar, Docs and Sites for all staff and students alike.

With its readily usable platform that enables collaborative working amongst our students, and apparent popularity, there’s lots to like about using Google Apps in learning and teaching. In the last year we’ve seen a few really exciting examples of innovative practice, and there’ll no doubt be more to come. But before we just wade in with wholesale promotion of using the Apps with our students, we need to think about some of the broader issues, starting with policy and guidelines. Here are some of the areas I’ve identified over the last few weeks that require such attention.

Acceptable use policy

Now in many ways this is an easy one to start with. We will all have generic codes of practice and regulations governing the use of IT facilities, which will be provided by our respective IT services. Many of the things contained in these are in fact inherited directly from JANET. Equally many of these can be directly applied to the use us of Google Apps too. Google also have their own regulations to which we must adhere. There are no massive surprises here - all the usual suspects are covered including non-distribution of bulk commercial emails, copyright infringement, virus/malware distribution, reverse engineering of the products and other generally unlawful activities. It might be worth considering providing a localised version of the Google terms which might seem more digestible to staff and students  - Google don’t for example specifically mention obscenity or pronography although these areas would almost certainly be covered by any educational institution’s own regulations. These latter of these areas are covered in the slightly more prescriptive Google+ acceptable use policies, as are matters such as “Hate Speech”, which is perhaps not surprising as this social networking platform is not directly associated or tied to an Institutional domain, although slightly confusingly can be accessed using your Institutional GAFE credentials.


Coffee table
Image by maistora CC -BY-NC-ND


Copyright and IPR

It is always essential to ensure that your copyright and intellectual property rights are safe when using a third party service, especially when it means that your data is being stored at a location not owned by your Institution. However, the GAFE terms and conditions clearly state that we retain IP over the information we use or store with the services, as below:

“As between the parties, Customer owns all Intellectual Property Rights in Customer Data, and Google owns all Intellectual Property Rights in the Services”

Some concerns were expressed publicly recently about Google’s use of our data, with the release of Drive, although these were really misinterpreted in what could be described as a bit of  knee-jerk reaction. The reality is that  in running a service such as Drive, Dropbox, Skydrive or iCloud, we need to license the service providers with the right to copy our content just to make the services work at all. It’s not really that much different to what we allow our local IT services to do when we copy files to a shared drive, or when they perform routine backups. Brian Kelly recently wrote an excellent blog post about exactly this.

In terms of using GAFE for learning and teaching, this also means that the IPR in any students’ work created or hosted using these will follow the same policies that govern other work they do. I mentioned this specific area (point 12) in a recent blog post about copyright - it’s important that we recognise our students IP and act responsibly to safeguard this.

Of course the other major issue we need to be rigorous about here is ensuring that third party copyright is not infringed when using the GAFE suite. We’ve blogged about these issues a number of times recently, as summarised in this post. The infringement of copyright is no doubt explicitly prohibited in all our acceptable use policies, and heavily implied in Google’s too. There is an added potential risk when using the GAFE suite though, as they are partly designed to facilitate easy and accessible web publishing. So if a student incorporates a copyrighted image into a Google doc, hits the “Publish to the web...” option on the File menu, and then pastes the URL into an open group in Facebook, we are now potentially responsible for a worldwide copyright infringement. So there'll be no excuses about hiding behind the metaphorical closed doors of the Institutional VLE this time....

Related to these acceptable use and copyright issues is the placing of a disclaimer on the home pages of any Sites published through the domain. Several Universities in the US and UK are now insisting on this with a specified wording, which should to some extent isolate the Institution from any negative consequences arising from the site’s existence, such as those specified by Oxford Brookes in their terms and conditions for Sites usage.

Privacy and e-Safety.

Some of the privacy issues with the GAFE products has been touched on above. What has received less attention however are some of the issues relating to the use of Google+. The Hangouts feature of Google+ appears a very attractive option for online conferencing. Not only does it provide free web conferencing, with full audio and video support, but members of a Hangout can also easily work collaboratively on  shared Google Docs. Hangouts can also be timetabled by scheduling them as events, and they can also be recorded, using Hangouts On Air. This however is where we’ve encountered a slight problem: Currently, to enable a recorded Hangout On Air, it has to be streamed to an unrestricted YouTube channel first. Although this channel can be restricted after the Hangout On Air has been recorded, there’s nothing to stop anyone who locates the channel to both watch and comment on the conference as it’s happening. We’ve tested a few here, and sure enough, within minutes of starting the Hangout On Air, we’ve received a number of unsolicited comments from users completely beyond our control. In addition to this, the person who instigates the Hangout On Air takes full responsibility for any potential copyright infringement that could occur during the session. We currently feel that the risks for abuse  and lack of enforceable e-Safety precautions with these types of conferences are so severe, that it’s our current policy to strongly recommend that people do not use them in their teaching. Please note that this only applies to the recordable Hangouts On AIr, and that normal Hangouts do not suffer from this. For those wishing to record their hangouts, we would recommend using a screencasting tool instead. Sarah has also blogged about this a while ago when this feature first became available.

Another area that has implications for privacy and e-safety is when looking at the potential use of Marketplace Apps. Although many of these in the “Edu” category are aimed at content for schools, some may seem attractive in HE settings too. Whilst we don’t currently have these published as University policy, our Information Officer, Chris Willis, has been looking at some guidelines in conjunction with colleagues at other Institutions.  Factors that should be considered generally revolve around what information these Apps require to work from users’ accounts, and whether they require read/write access to Calendar, email or Drive Apps, as they are provided by third-parties who are not governed by the contractual agreements we have with Google themselves.

Although not technically policy as such, it may also be worth us thinking about allaying some of our students’ and colleagues’ fears about these issues with some more general information and guidance.  Again Oxford Brookes have taken some steps in this direction with their Google Worries FAQ.

Guidelines for Assessment.

There are a couple of specific issues we need to address if we are going to adopt more widespread use of the Apps for assessed work - and given the collaborative nature of the work that they facilitate, we can definitely expect to see interest in this increasing.

The first is the issue of handling the actual submission itself. We need to give guidelines to academic departments on how best to do this. Broadly there needs to be some transfer of ownership and sharing permissions on the Google Docs or Sites, that enables the students to hand the work over to the lecturer, or department. As part of this there needs to be a way of “locking down” the submission so that the student can’t subsequently alter their work. One way of doing this would be a “systems” approach. This would mean a semi or fully automated way of getting the Google Apps infrastructure to manage transfer of ownership, and shifting the students’ privileges to “read-only”. We understand that colleagues in other Institutions are actively pursuing this. The other way would be to adopt a “process” approach, in which students would manually transfer ownership of their work to a staff or departmental account, and then this account holder could manually change the students access to read-only. There are pros and cons to each strategy - the systems approach might take longer to develop but would possibly be more scalable and sustainable, whereas the process approach could pragmatically be applied quicker, but could also lack scalability or sustainability, and would be prone to aspects of human error. For this latter reason I would personally argue that this task would be better handled by an admin team, with shared responsibilities for the whole assessment process, rather  than an individual academic staff member (accepting if we may that the type of creative flair that enables academic genius doesn’t always readily lend itself to processual robustness, if you get get my drift). We have in fact recently modelled this manual approach in a Biomedical Science module (using Sites) and is does indeed work - in this case we used a user account created specifically for the module, and used the email notification system to create an audit trail to monitor the submissions. In either approach, enforcing a naming convention on Docs or Sites would be a really good idea, and this is also addressed in Brookes’s Sites policy.

We would also need to consider business continuity issues in the submission process. For example. access to GAFE for our students is via our MUSE portal. If the portal were down in close proximity to a submission deadline, it could prevent students from being able to complete the submission. We would need a series of contingencies to handle this, including having a way for the student to officially report this if asking for a deadline extension, or by circumventing the problem all together by enabling access to the Apps via an alternative route. We’re currently investigating doing the latter by using Google’s own authentication processes.

Handling potential plagiarism detection with this kind of submission will also no doubt be question that needs addressing. So how, for example, can we advise students who create assessments in Sites submit their texts to TurnItIn to check their originality scores? No doubt doable vie one approach or another, but something else we need to be able to have a policy and/or guidance on.

We also need to address the issue of retention of the assessed work after submission. At Sheffield we currently require academic departments to retain assessed work for one year after the students’ graduation, but for six years in the case of a grade challenge or appeal.  For work submitted as Google Docs, either of the two approaches above would work, as long as the ownership per se of the document was given to the Institution, as ultimately the students’ accounts will be deleted after graduation, and so their work will disappear. The situation superficially looks slightly simpler with Sites, as these belong to the Institutions’ domain already. However we do need to be careful. There could be a scenario in which a group of students collaboratively author a Site, and in doing so, embed text content authored using Google Docs, owned by one of their accounts. As we understand, if they transfer ownership of the Site to the department, but not those individual Documents, when their accounts are ultimately deleted (or if they accidentally delete the Doc or change its sharing permissions themselves), this text will disappear from the Site. This is definitely an area where the Devil lives in the detail, and we are still looking at what other scenarios might lead to this problem, and how they can be mitigated.


Accessibility Issues

There are known accessibility issues with some components of the GAFE suite. These have been excellently summarised in a recent presentation given by Shirley Evans from TechDis.  Google are themselves aware of this, and we understand work is ongoing to address these. As Shirley herself has said, we don’t know exactly how many specific issues have arisen with the Apps over the last few years, mainly because as a profession, we tend to talk to other learning technologists rather than students themselves. To this end I have raised an enquiry with our Dyslexia and Disability Support service here at Sheffield to see whether any such issues have arisen - and perhaps colleagues in other Institutions using GAFE could consider doing the same. That way we might be able to collaboratively construct some kind of assessment between us. Accessibility issues become particularly important if we’re planning to use the Apps for assessment.


When Students and Staff Leave

As mentioned above, when students leave their accounts are eventually deleted. Although we don’t have to take responsibility for looking after the stuff in their filestore, it equally doesn’t hurt to give them a bit of advice on how best to deal with this. We currently address this by giving them advice on the use of the Takeaway tool, which copies all the contents (excluding Sites) to a local drive, and also how to transfer ownership of their files to a personal account here. For those wishing to extract the text from Sites, you can use the tool created by the fantastically named “Data Liberation Front”, available here.

Staff may have many documents that require transfer of ownership back to the Institution when they leave. From our perspective we would be mostly concerned about any teaching materials or assessed work created or delivered using the Apps. Again this transfer might be better done to a departmental account rather than to any one individual.

Policy and the Learning Technologist

I’m aware that much of this is really a work in progress, with reference to other Institutions where these issues may have been dealt with. In some cases, such as those regarding the use of GAFE for assessment, putting the Apps suite under such a magnifying glass does in fact expose broader gaps in our policies. We currently have no blanket Institutional policy regarding e-Assessment, although we hope to address this as part of our new e-learning strategy.

I also think that there’s a an important general point here for those of us working as learning technologists. We need our academic colleagues to develop and test innovations in the field. But it’s our professional responsibility to take a step back, and ensure that we can support these in robust, sustainable and scalable ways. Formulating policy might seem a bit dull to some*, but it’s an essential component of this. Some of the issues raised here might have to stay on the "too difficult pile" for now, but it's important to have at least acknowleged and thought about them.

If anyone has got any brilliant ideas for handling any of the above do please share them with us - I’’ll buy the person with the best idea a pint (or some appropriate variant of) at ALT-C if you’re there......


* I would actually much rather spend time playing with BuzzTouch ;)

Graham

No comments:

Post a Comment