Guidelines for Web 2.0 Integration in the Classroom


This document discusses barriers and opportunities for the integration of Web 2.0 technologies in the classroom. It has been produced by the Integrated Learning Environments and 21st Century Learning activity within the Technical Standards for Digital Education Project, supporting the Australian Government's Digital Education Revolution.

The document explores three areas:


© Copyright 2010 University of Southern Queensland

Policy considerations


Addressing Access Restrictions

Using Web 2.0 technologies in the classroom, and integrating them with existing learning infrastructure, usually presupposes access to the Open Web. Core Web 2.0 technologies such as wikis and blogs can be deployed locally in school intranets, or access-restricted sites (e.g. Scootle). But Web 2.0 technology typically assumes unrestricted web access, philosophically as well as technically, and it does not always provide for authentication. Teachers attempt to integrate material from the Open Web in their teaching. Web 2.0 integration depends critically on access to Open Web resources: closed access material (e.g. intranet wikis) and authorised content (e.g. Scootle) may incorporate Web 2.0 functionality, but teachers seek to include other found material and processes into their teaching, that they encounter on the Open Web. For Web 2.0 integration to reach its potential in the classroom, then, student access to the Open Web is needed.

There is a long-running debate on the extent to which school systems should allow access to the Open Web. We sketch the debate and its implications in an appendix. Here we suggest some ways forward for enabling controlled access to the Open Web, given the concerns and responsibilities of schools against inappropriate access.

We suggest the following approaches are worth exploring further:

  • Teachers need to work out which large-sized content they will be accessing recurringly, and discuss with the school or jurisdiction options for caching it locally. This should be done both to prevent spiralling bandwidth consumption, and to lessen the burden of traffic monitoring for the school.
  • If teachers are trying to work around firewalls for educational purposes, schools should determine why they need to do so, instead of discouraging it. This is an opportunity for teachers to give feedback on the provision of IT infrastructure: what are they trying to do that the school is not already providing, and see whether the school can start providing it. Schools need to be careful not to quash innovation.
  • School systems cannot keep pace with developments on the Open Web: a school may be able to provide blogs and wikis but not tweets, for instance.
  • Both content and technologies on the Open Web develop faster than schools can keep up with, at any rate. It may be better at a policy level to develop categories of sites that should be open or blocked rather than named particular sites,
  • The concern about students being exposed to inappropriate material remains, and if students are exposed to the Open Web for a particular purpose, their use must be monitored.
  • Teachers are the professionals in immediate contact with students, and are well positioned to judge whether the student use of the Open Web is appropriate or not. If schools do allow student access to the Open web, teachers should have tools with which to monitor what the students are doing, and to intervene when necessary.
  • Student access to the Open Web should be in a specific teaching context, which is determined by the teacher. Blanket enabling student access to the Open Web is problematic, as we discuss in the appendix: an alternative to consider is to have the teacher enable access to the Open Web, or a subset of it, for a specific cohort and timeframe. The teacher is better aware of student requirements, and is able to intervene more quickly and more effectively than a central IT administrator.
  • Teacher-enabled access requires authentication infrastructure (of the type discussed below), and user-friendly interfaces for enabling and disabling authentication at the cohort and student level. Teachers should also have tools with which to enable and disable student access to the Open Web locally. The pilots to student access provisioning under SIF, which involve OpenID, are one such avenue worth exploring.

Longevity

The advantage of free online Web 2.0 tools is that they are readily available, without requiring setup or institutional investment, and they can be put to use immediately. The control that teachers have over the Web 2.0 tools is one of the main reasons they are so attractive. There are some downsides to free tools we will consider below: they are not deployed in a secure environment, they need to be provisioned explicitly with manageable student identities, and they do not follow formal standards.

Another downside of free online tools is easy to lose sight of: their providers are not accountable. Many Web 2.0 tools have a short lifespan; even the more heavyweight providers, such as Google and YouTube, do not guarantee that they will keep providing their services in the form they have been. If a school has not signed a Service Level Agreement with the Web 2.0 provider, be it Google or the latest Silicon Valley startup, then they have no guarantee that that the content they put up will be there tomorrow. This is a significant advantage of enterprise systems over freeware: they are accountable to the education jurisdiction, and have an explicit mandate to keep material accessible.

This does not mean that content should not move to "the Cloud"; Cloud services can be deployed within an enterprise, or through a Service Level Agreement with a provider like Google. The concern is primarily a matter of accountability and failsafes, and those concerns are much more acute with the freeware, unaccountable cloud of openly accessible Web 2.0 tools - which is what most users assume The Cloud to be. That said, relying on the Cloud forces more dependence on network infrastructure: if access to the network at the school is intermittent, safeguards are still needed, and intranet solutions are preferable to internet-based solutions.

So teachers putting content up in the Cloud need to know the risks of relying on the Cloud. Teachers are far from the only professionals that have come to rely on the Cloud; but that does not lessen the damage done if they don’t take appropriate precautions:

  • Always back up uploaded material - preferably on school or jurisdiction-based systems with offsite backup, and not just on personal computers;
  • Harvest content created on the Open Web that needs to be preserved (e.g. student blogs for assessment) back onto school-based systems - this can be as simple as capturing RSS feeds;
  • Try to use multiple dissemination channels for material where practical, both for redundancy as a failsafe, and to anticipate possible interoperability glitches;
  • Do not use the Cloud for sensitive or mission-critical information, such as grades;
  • Duplicate at least core Web 2.0 technology in school and jurisdiction systems (wikis, blogs)

Prototyping

While Web 2.0 infrastructure is easy to set up, integrating it with school systems is an investment, since school systems are not set up for such integration - particularly given the reluctance to use the Open Web in schools. It is wise to start with prototypes, to convince jurisdictions of the educational and cost value of the proposed integrations - and system vendors that what is being proposed is feasible. Fortunately, the ease of seeing up Web 2.0 infrastructure means that prototyping is straightforward.


Technical Considerations


Authentication

Integration of Web 2.0 tools with learning systems presupposes a common trust environment between the two. The typically involves Single Sign-On on both school and Web 2.0 systems; Single Sign-On is highly desirable for most integration of tools in general, and in some contexts it is essential.

Single Sign-On need not mean that the Web 2.0 system is provisioned directly with the school’s usernames and passwords. The Web 2.0 system can still use distinct credentials (such as users’ preexisting accounts). There are ways of bridging between two sets of credentials, by mapping one user identity that has been authoritatively established to the other. There are several ways of doing this mapping worth exploring, including using OpenID (currently being piloted under SIF-AU), IMS LTI (specification using OAuth, already widely taken up in the US), and Shibboleth (more secure but also more difficult to deploy).

There are policy reasons we should note against using preexisting Web 2.0 accounts for school purposes. Student-selected passwords are less likely to be secure, and most schools would want the ability to monitor students’ use of the Web - meaning that they should be able to bypass the students’ passwords. School accountability on user accounts obtained outside the school is clearly compromised.

The authentication system for students to access the Web should be secure enough to prevent unauthorised access from outside the school; but it should not be so heavy-handed as to be unusable with the Open Web, or difficult to deploy in schools with limited IT resources. It should also be possible to use the authentication system with a reasonable range of Web 2.0 tools - bearing in mind that the range of Web 2.0 tools is expanding. OpenID, which is currently being piloted for Scootle integration, is arguably at an acceptable level of security, but jurisdictions and schools need to do their own investigation of technologies and risk assessment. Different applications require different levels of security; disseminating subject assessment to students for example requires higher security than circulating YouTube links.

Note that not all Web 2.0 technologies are set up for authentication and authorisation, because they presuppose unrestricted Web access. Many RSS readers for example do not support authentication. Some classes of tools are most appropriate for use on the Open Web (such as notifications/alerts and knowledge sharing tools), while others can be deployed within a firewall without losing essential functionality (such as authoring and publishing tools) - although this depends on how the tools will be used for learning. Schools increasingly see themselves as knowledge producers and not just knowledge consumers; this means schools should be considering online publishing to the Open Web - and the associated risk mitigation (comment moderation for example).


Standards

Unlike other IT domains, Web 2.0 has resisted formal standardisation to date - though there are beginning to be efforts like W3C Widgets to address this. Web 2.0 technologies have been developing too quickly for the time-consuming standards process to be undertaken. Instead, different protocols compete without central coordination, and market adoption dictates which protocols prevail. This is usually decided by which major players have taken up a protocol (Google, Flickr, Wikipedia, etc.) Implementers need to monitor developments in Web 2.0 protocols, including the emergence of both formal and informal standards, and the competition or convergence of existing protocols.

For developers, the lack of central coordination can mean having to support multiple protocols, and that the protocols are more loosely defined or more quickly changeable than elsewhere. For software procurement, it means that software should be able to output information in a way that Web 2.0 can process. That need not mean a specific format so much as an explicit, text-based format (including XML, but not limited to it). Filters can usually be written to transform textual output to a desired format.

Systems will be called on to interoperate with a range of Web 2.0 tools, without central coordination. As a result, the choice of protocol may need to err on the side of pragmatism. For example, both ATOM and RSS 2 are acknowledged to be more powerful and elegant protocols for news feeds; but the need to integrate with a broad range of feeds (whatever relevant feeds teachers find online) means that the RSS 1 baseline still needs to be supported.

Systems seeking to interoperate with Web 2.0 should also adopt a REST, resource-oriented view of their outputs. Avoiding cookies and stateful representation makes for easier integration, and REST-like interfaces are assumed by Web 2.0 tools. That means unique, static URLs for the system objects that will be exposed to Web 2.0, such as feeds or tags.


Education Value

There is an overwhelming number of Web 2.0 tools available; their number is ever changing, both because new tools are constantly being created, and because old tools fail to achieve a sustainable business model. This can happen even if individuals have come to depend on the tool: as said above, unless there has been a Service Level Agreement, the Web 2.0 provider is not under an obligation to sustain their service.

Teachers getting started in the space should not get fixated on a single tool as a solution to all their problems; rather they should evaluate similar tools, in terms of how they satisfy their educational objectives. So tools should be classified in terms of how they can be used in the classroom.

There are already several attempts at classifying Web 2.0 tools that teachers can get ideas from. For example, there is ongoing work in the US to align Web 2.0 tools to Bloom’s Taxonomy of learning objectives - bearing in mind that tools can be used in multiple, often unforeseen ways. See for example:

Other classifications of Web 2.0 and online tools for educational use include:

Teachers who are not already familiar with Web 2.0 tools should not be trying to boil the ocean all at once! Tools will be more successfully harnessed in the classroom if they are incrementally added to the teacher’s practice, rather than revolutionising it - one tool at a time, in a way that fits in with their current practice. For example individual blogs, used for reflective writing, might match existing assessment practice better than collaborative authoring tools.

The point of using new technologies is always better education outcomes - not using the technology for technology’s sake. Introducing Web 2.0 technologies into the classroom provides an opportunity for a more engaging classroom experience, more relevant to students as digital natives, with an open universe of information and resources available. It helps students consolidate the new skills they need to navigate and contribute to the digital world, but it also helps to build on the familiar skills and capabilities in the new environment. It should not be made a new burden for teachers to endure, or new headache for school IT to deal with; but it is an opportunity education cannot afford to let pass.


Appendix: To open or not?

The debate on allowing student access to the Open Web is an attempt to balance educational needs and expectations of 21st century students, against the responsibilities schools hold towards the students and community expectations.

Jurisdictions have a legal responsibility of duty of care, to safeguard minors in schools from being exposed to inappropriate material. The expectation of compliance is reinforced by public perception, and breaches in compliance result in high profile exposure politically. The simplest way of addressing this requirement is a blacklisting approach, blocking all access by students to the open web, and to materials that have not been vetted by an accountable authority. Many schools also need to limit their bandwidth consumption, and thus prefer students to access local or locally cached content, rather than keep downloading it from the Open Web.

Teachers attempt to integrate material from the Open Web in their teaching. Web 2.0 integration depends critically on access to Open Web resources: closed access material (e.g. intranet wikis) and authorised content (e.g. Scootle) may incorporate Web 2.0 functionality, but teachers seek to include other found material and processes into their teaching, that they encounter on the Open Web.

There have been several reports recently encouraging managed risk rather than blanket bans to the Open Web. The recent Oftsed report (UK) The safe use of new technologies is one high-profile example. There are two major arguments for enabling some access to the Open Web.

  • The first is that significant educational opportunities are being missed by blocking all access, which should be weighted against the risk of inappropriate exposure; so access to the Open Web should be managed and monitored rather than banned outright.
  • The second is that children are increasingly exposed to the Open Web outside the school environment, with variable degrees of parental oversight. Managed access to the Open Web in a school environment, it is argued, makes students better equipped to deal with challenges outside the school environment. More generally, school should be equipping students to deal with the Web, as a primary professional as well as recreational environment: there is already a sentiment that what students do at school is irrelevant to their out-of-school experience.

It is impractical for school or jurisdiction IT staff to vet beforehand all content students may be exposed to on the open web. What often happens is that teachers at the school level ask for access to individual sites to be whitelisted for a particular purpose, or circumvent school systems to do it themselves. Whitelisting takes time, and circumventing systems is usually against school policy: this ends up pitting teachers against IT administrators, and makes IT a blocker rather than an enabler in education. Dissatisfaction with current arrangements is frequently heard in teach and online fora.

On the other hand, the safeguards against inappropriate content are there for good reason, and it is politically and ethically untenable to provide unfettered access to everything on school systems. Any arrangements to give student more access to the Open Web on school equipment and in school time are constrained to follow those safeguards; what is at issue is how to realise them.


The Technical Standards for Digital Education project is funded by the Australian Government's Department of Education, Employment and Workplace Relations (DEEWR).

Southern Cross