eCampus Norge: web conferencing discussion memo Authors:

Ingrid Melve (UNINETT) Jan Meijer (UNINETT)

Date:

2010-07-09

Version:

1.0

1 Introduction Web conferences are mostly used to conduct live meetings or presentations over the Internet. Web conferencing is a light weight approach to online collaboration with requirements to a participant's desktop environment being so modest that any modern desktop will suffice. It runs in the user's web browser environment and often uses Flash or a Java applet for extra functionality. Typical features of a web conferencing environment include real time audio and/or video conferencing, slide show presentations, whiteboard, desktop sharing, chat, ability to interact with the shared workspace, polls and meeting recording. Participants access the meeting by clicking on a meeting invitation link distributed by email or by clicking on a link from within their portal environment. When the eCampus project was defined at the end of 2009, web conferencing emerged as one of the hot topics in the Norwegian higher education sector. A number of institutions(like Telemark University College and Bodø University College) have solutions in place; most other institutions are working either individually or through their respective collaboration alliances to make a web conferencing service available for their users before the end of 2010. Most sites want to begin using it for net-based teaching: lectures, feedback sessions and student group assignments; and see use of web conferencing tools for holding meetings in a more administrative setting follow. Web conferencing – a key area The eCampus working group in fall 2009 identified web conferencing as one of the key areas on which the eCampus project will work in 2010. The main focus in 2010 is supporting education, especially lectures and building good learning environments. With the entire higher education sector activated to deploy web conferencing solutions it is an obvious area for sector wide collaboration to drive down cost, benefit from economies of scale and ensure a decent sector wide functionality baseline and interoperability where needed. Given the SAK processes with increasing intern-institutional collaboration and merger of institutions, the interoperability requirements are greater than they were few years ago. The eCampus work may take different forms such as establishing common requirements, a joint procurement of solution(s), establishing a shared solution, a combination of these and more. The eCampus goal for web meetings is to ensure systemic and systematic use of web conferencing, and to facilitate that the different use cases becomes a reality for all lecturers, students, researchers and staff within Norwegian universities and colleges with a decent sector wide functionality baseline. This memo aims to guide the discussion to a decision on the course of action for sector wide collaboration on web conferencing.

1/22

2 Use in education and research Three common usage scenarios for online collaboration where web conferencing can fulfil a role have been identified, each with their own peculiarities: 1. Meetings 2. Lectures 3. Ad hoc collaboration

2.1 Meetings On-line meetings are used to reduce travel time and cost for the participants. Most meetings take place within the same organizational unit, or with well-known collaborators. The on-line meetings shares characteristics with on-campus meetings, and are subject to organizational policy and practice. This type of web conferences is held within a controlled ICT environment. Normally there is a meeting chair (often called administrator, organiser or convenor in the web meeting tools) and two or more participants. Most meetings have 3-10 participants, but there may be all hands meetings with several hundred persons. Meetings that exceed 10-20 participants often get some of the characteristics of lectures, as there in practice is limited feedback from the participants. Meetings typically involve employees, but are sometimes held with external partners. On-line meetings in higher education are, with the exception of research projects, mostly used in the same way meetings find place in the ordinary organization and within the usual work flow. Many meetings result in meeting minutes. Research meetings often span organizational and national borders, and relationships are set up for intensive use in a limited time period. For more details on research meetings, see the information about collaboration. Planning and booking Most meeting participants are well known to each other, and meeting booking is done using some kind of calendaring solution (the most common is Exchange). Higher education has a large number of people (experiences from Feide indicate 30-80% of the user space) that are not directly employed by the institutions, but still are part of the collaboration sphere. However the number of meetings is smaller for the external partners than it is within an institution across physical distance. Some institutions have close collaboration with their surrounding business environments, as well as the work flow that is done in hospitals and schools for trainee nurses and teachers. The external meeting participants are integrated by (email) invitation, as a meeting is normally set up and administered by an employee of the institution. The organizational structure plays a role in scaling and determining how many meetings are expected. Meetings are often planned in advance, and may be booked in the same way that physical meeting rooms are booked (which implies a flatter distribution of room usage than we see for lectures). Digital skill levels Digital skill levels vary in the user population, and there may be a need to upgrade digital competence to get efficient use of web meetings. Most web meeting solutions are easy to use, but there still needs to be an update on on-line meeting behaviour and digital competence. And some user interfaces may be confusing, and need trained users (or a switch to more user friendly software). Deployment challenges: •

authentication

•

the individual participant's calendaring system

•

institution wide meeting scheduling or booking systems

•

buddy lists, contact list etc. where information about contact details are found

2/22

•

institution wide employee lists where every employee can be found. This is an extension of the individual's personal contact lists

•

the PC/Mac for each participant, with headset and camera

•

social meeting behaviour, digital competence

The number of online meetings in this context is a subset of the ordinary meetings in higher education. We expect an increase in the use of online meetings as the reorganization of higher education (SAK processes) proceed. One of the keystones of SAK is close collaboration between distributed study sites, as we currently see being implemented in the teacher training universities and colleges.

2.2 Lectures Lectures are used in net based education, where on-line lectures are scheduled in the same way as lectures are scheduled in auditorium. The professor acts as chair (moderator, meeting convener), and controls who can speak in the session. The priority list for good on-line lecture is 1. a skilled professor with motivated students, a good professor is the primary key to a good learning experience 2. no trouble with the on-line meeting, waiting more than five minutes because of technological nonsense is unacceptable 3. good audio quality 4. access to learning materials (handouts, slides, shared whiteboard) 5. chat for feedback and trouble shooting The first point is provided by the universities and colleges. Training digital competence in web meeting use may be needed to unleash online the potential evident in the auditorium or class room. The eCampus project does not plan digital competence training until 2011, when there will be work on best current practices in Norwegian higher education, with examples and some workshops. The second point is achieved by lecturers, students and support staff from ICT/AV. Choosing a user friendly solution is important. User friendly includes a solid web meeting solutions with negligible downtime and access to support if problems should occur. Good audio quality is a key feature, and this point is the single issue raised by every one of the persons interviewed when working on this memo. Requiring headsets for students and a good quality microphone for the lecturer is important. The fourth point is solved in web meeting solutions by various sharing options, but may also be solved by publishing the teaching material in the learning management systems (putting slides into Fronter or it's learning is standard practice). Chat is currently the primary trouble shooting channel, where students may report technical trouble without interrupting the lecture itself. Chat is also useful for discussions or other forms of feedback. Pedagogical tools In addition to the key points, there is also often a need for some more pedagogical tools, for example:

3/22

•

polls where students are asked to solve a problem, provide an opinion or analyse a situation (in auditoriums feedback is often given by show of hands, or in some cases by clickers/student response systems)

•

students may raise a virtual hand to ask a question or provide other feedback

In most cases the lecture solutions cater to the use case of distance education, where the professor gives a video lecture and students listen and may raise their hands to ask questions (or participate in polls or short assignments). Students typically don't use the audio channel to ask questions while the teacher is talking, as they do not wish to interrupt the flow of speech. Instead the ask questions during the lecture over chat. Once the part of the lecture where the teacher has the primary focus is over, students will ask questions over the microphone. The lecturer uses pointing device a lot. Some solutions are made primarily for the meeting use case, where participants share information under the guidance of a meeting chair person. The meeting use case correspond better to some pedagogical models that require interaction more than consuming information as in the main stream education software solutions. The meeting use case is the closest use case for study groups, where interaction and active participation is a strong requirement. Pedagogical models vary in higher education, and web conferences must be able to support a wide variety of pedagogical models. For more details on requirements for functionality in education, see appendix I. Deployment challenges: •

authentication: who gets access to a lecture? A webinar could be open to everyone in the world, but most lectures are for closed groups corresponding to a course.

•

calendaring systems

•

the PC/Mac for each participant, with headset and possibly camera

Information needs to be available from: •

the learning management systems (Fronter, itslearning and others), where groups/courses are managed. The key information is maintained in FS (shared student registry), but uploaded into the LMSs that act as group management solutions for lectures. This information is important for the selection of attendees.

•

institution wide booking systems for lecture rooms (in some cases)

•

lecture capture systems, for distribution to students within the course/semester. This could be extended to support Open Educational Resources (OER), and early experiments with this is foreseen within the time frame of 2011-2012.

Software solutions may be tailor made for education (as is the case for the Elluminate/Fronter integration) or may use presentation mode in generic on-line meeting solutions (like Nefsis, Adobe Connect, GoToMeeting). The lecturer's equipment is provided by the institution, and some requirements are made for student equipment. The student equipment requirements must be sufficiently wide to include hardware and software normally found in the student population. In practice this means it is not desirable to require a Mac user to buy a PC in order to follow net based lectures. The student ICT hardware is not under institutional control or well known but certain basic requirements can be imposed. Telemark University College has defined such basic requirements for students participating in net-based courses.

4/22

The number of lectures using web meetings is low, but is growing rapidly. Several colleges have launched net-based studies in fall 2009, and more are expected in fall 2010. Existing distance education are (to a certain extent) converting their courses into using more web meetings for lectures, especially those courses that are not based on video conferences room-to-room. Since the number of lectures is high, the subset of on-line lectures has a large potential. The number of lectures per institution is planned and may be coordinated for optimal utilisation of the available number of on-line meeting rooms. This is the same model currently employed to maximise auditorium usage.

2.3 Ad hoc collaboration Collaboration solutions range from the basic (phone call and documents distributed on email), via shared tools (Google Docs, Etherpad, MSN, Facebook chat) to full immersion with sharing of desktops and full video. Our interviews indicate that Skype with some form of shared document/desktop is used both as the primary alternative and as a fall back alternative for other tools. There is an unlimited number of web2.0 sharing tools, and these kinds of tools seem to multiply by numbers. Ad hoc collaboration has two areas of primary interest for our community 1. Student study groups and student group work assignments. Some of the collaboration is set up in advance, for example a study group may agree to meet every Monday at 3 pm. Given the transient nature of student life, this kind of social contract often gets re-negotiated and appointments are moved around. Other times there may be a deadline for an assignment, and two or more students may need to meet up online to work until the deadline. In practice this is often left until the last minute. We can expect these ad hoc meetings to be initiated at short notice (minutes, hours, sometimes for a semester or several weeks in a row) 2. Research project meetings. Project meetings come in various categories, from the administrative well planned in advance (similar to meetings in the first scenario), via the semiplanned meetings before a report needs to get handed in, to the pure ad hoc meetings that are set up on short notice to discuss a problem, investigate data or work in smaller groups on specific issues. Participants are often from different institutions spanning international borders, and there is great cultural and technical diversity. In addition to the two areas mentioned, ad hoc collaboration tools should be available for all users within our community with a need to collaborate. It is important to enable flexibility in collaboration. We have a really strong suspicion that this field will develop into something different from what it is today within a few years. 1 in 8 couples that got married in the US in 2009 met online. The 300 000 users in higher education and research are likely to collaborate online in more ways than we can imagine today. To sum up: ad hoc collaboration using web meetings should be for everyone, and it will change. In 2010-2011 the two areas mentioned are our primary targets. Collaboration requires a high degree of interaction, with verbal comments as well as comments in drawing and other media. There are good reasons for the presence of blackboards/whiteboards in every single teaching room on the planet, displayed text, formulas and drawings are essential to a good learning experience. In most cases collaboration results in a document (student assignments, meeting notes, sketches, slides for presentations, reports, memos), as the point is to convert a conversation into a working result. The ad hoc collaboration in higher education and research is document centric. In traditional meetings using video conferencing, the emphasis is on the communication and not on end product over which collaboration takes place, in many cases a document. Video is normally of secondary importance, where audio and shared workspace is most important. Researchers participate in international projects, where the information exchange and collaboration needs are growing. Demand for green alternatives to extensive (and expensive) travel is a global 5/22

trend. Some web meeting tools have been made explicitly for the research community, for example Evo. Functionality tends to overlap with other web meeting tools, with emphasis on interactive dialogue and sharing of materials. A characteristic of research projects is that available hardware and software is not controlled (or indeed known) by any single entity, there are normally heterogeneous systems both on the end user side and with regards to server side solutions. The current situation is that each researcher may have to use several different web meeting solutions if she participates in several projects. The most important “it has to work” issue is to get each participant's PC/Mac connected to the web meeting, with headset and camera if needed. This should work out of the box. There is always something, though. Things that need to be available in parallel (or within) with the web meeting •

buddy lists, contact lists etc. where the contact information (for email, instant messaging, cell phones, Facebook and other social media) is kept and updated

•

for students: the learning management systems, since the LMSs act as group management and a study group normally is a subset of a course

•

for researchers: web project space

•

whatever shared workspace is used to generate a shared “document” ◦ Word/OpenDocument + email ◦ web based sharing tools, stand-alone tools for one specific task (screen dump, document, slides, shared authoring, mind maps etc.) ◦ web meeting tools (shared whiteboard, shared documents, shared desktop)

For ad hoc collaboration we see a plethora of loosely coupled systems, where web2.0 services are used to support various tools or media content (photo sharing, drawings, document authoring services, desktop sharing, snapshots, social media etc.) We expect this trend to continue in 20112012. Many web meeting solutions provide integrated work spaces, and these will be in competition with the stand-alone specific web2.0 services. The number of collaboration on-line meetings is unknown, since we are in the first phase of deployment and still not know what will be the primary use. Collaboration may prove to be the major use of on-line meetings, in the same way we could see email transform from a research support tool to a main stream tool. Researchers are using online web meetings today, and we expect the use to increase as the possibilities (and relevant digital competence) is deployed in reach of the individuals. Better user interfaces and easy to use solutions are important factors for the growth curve. We expect an increase in phone meetings side by side with the increase in more immersive tools. Students should have access to ad hoc collaboration tools, even if they are not involved in net based studies, as this provides important functionality for study groups and projects. It follows from this that if students have full access to ad hoc collaboration web meeting tools, there may be extensive use.

2.4 Different tools for different needs The table below summarizes the important different characteristics of the three scenarios previously described.

6/22

meetings

lecture

ad hoc collaboration

Primary use

staff meetings

net-based teaching

ad hoc-, study groupand project meetings

User group

staff

lecturer and students

students, researchers (staff, lecturers) everyone

Organisational scope

university or college SAK coalition merging institutions

university or college SAK coalition where students cross borders guest lectures

World wide, normally scoped to a person related to the institution

Number of participants

Typical: 5-10 Max: 20

Typical: 15-40 Max: 400-500

Typical: 2-7 Max: 20

Country scope

national

national/Nordic

national/international

Typical observed solutions

Microsoft Office Communication Server Tandberg WebEx

Adobe Connect Elluminate Nefsis NTR-meeting DimDim WebEx

Adobe Connect Nefsis NTR-meeting DimDim WebEx Skype Etherpad, Google Docs EVO

Institutional control over equipment and network

yes for office situation, somewhat for home offices

no, perhaps lecturer, but no, heterogeneous not students solutions

Duration of collaboration

permanent

semester

day/short time/project

Meeting scheduling planning horizon

days – months, normally medium

weeks – semester, normally long

hours – months, normally short

Scaling

number of staff, departments, meetings Follows organizational structure

# courses # participants/course # classes/course

all students (90 %?) all staff (10 %?) all collaboration partners

Key integration

calendar booking AD

LMS, student contact lists registration system, buddy lists possibly lecture capture social media? solution

Finding participants

buddy lists calendar

LMS? contact lists

buddy lists know email address know IM address Facebook groups?

Platform

MS Windows

Much MS Windows Bit of Mac and Linux

Most MS Windows (80%) Part Mac (increasing)

7/22

meetings Recording requirements

no, not used at the moment

lecture

ad hoc collaboration

yes, some lectures are being recorded

no, but need captures of documents or other collaboration results

Typical license models #users in LDAP

# rooms # concurrent users

different models today mostly free

Current use

some

some courses

little systematic use, some for study groups in net based courses

potential use

increasing (SAK) collaboration/work sharing/coordination)

increasing, net-based courses and collaboration(SAK)

big and increasing

Linear growth, with a spike for SAK processes with interinstitutional collaboration

Classic growth curve, with a ceiling for how many courses are net based

Exponential growth, as this use is dependent on number of relationships rather than the number of users. Expect high usage, well beyond the other two scenarios

Predicted adoption rate (graphs are not on scale with each other)

The eCampus project focuses on the challenges associated with the last two columns of this table, the lecture and the ad hoc meetings, where the solutions are required to be most flexible. eCampus is chartered to work on ICT in education, research and supporting higher education's processes. We find that lectures (where eCampus is concentrating our effort for 2010) and ad hoc collaboration are the two scenarios that are closest to the eCampus mission. For completeness, and because we know that there is a need related to SAK, we have included the meeting scenario in this memo. In the SAK processes we see increased collaboration across institutional borders. To increase productivity and quality of work it becomes important to allow for quick and easy collaborations to take shape, and to support the various shapes the different coalitions for higher education are forming in their local environment. The green aspects of distance spanning collaboration are not discussed in this memo. Initiatives within the community On-line lectures in net based education is an important use case, and there are several initiatives within our community testing and investigating solutions for this scenario. There are strong practical and political incentives for distributed education, and we expect the trend with increase in net based education to continue. Ad hoc collaboration is an important factor in building good learning environments both for net based and on-campus education. This form of web meetings is in its infancy, and we expect a sharp uptake with exponential growth. The ad hoc collaboration differs from 8/22

the meetings and lectures in that the area is not necessarily closely connected with the institution, but focus on the participants as individuals. This is observed both for students and for the research project use case. In the research project case, the participants relate to the project and to each other more than they do to the institutional infrastructure for web meetings. The ad hoc collaboration is characterized by a strong use of individual tools, and strong individuals choosing their own heterogeneous solutions.

3 The market The various solutions making up the web conference market place have converged to a more or less common set of features and functionality from a number of quite different backgrounds: • educational software extended with multimedia support (e.g. Fronter/Elluminate); • video conferences between rooms (e.g.Tandberg Movi); • IP telephony (e.g. Skype); • IP telephony and unified communication solutions (e.g. Cisco Webex or Microsoft OCS); • web chat solutions extended with sound,video and desktop sharing (e.g. Adobe Connect).

3.1 Convergence process The convergence process is still ongoing for several aspects important to us: • integration with LMS (The Norwegian LMS market is divided between Fronter and It's Learning) group management,integration with learning spaces, sharing materials; • authentication: most web conferences lack support for federated login, i.e. Feide; • integration with booking/calendar systems: progress seems further advanced in solutions from the IP telephony background, where integrating with the enterprise work flow has been important for businesses) • feature set for educational purposes: raising hand in class, lecture mode for control of "classroom", support for polls; • storage, management and distribution of captured lectures or sessions: captured meetings are usually stored within the solution and the process can't be integrated with e.g. existing lecture capture systems. The market is not yet dominated by a hand full of large vendors, with easily more then 50 different solutions available. Some major vendors are starting to emerge, with Microsoft as one example (Sharepoint/OCS). The market situation indicates that consolidation is to be expected in the next 2-3 years both on the vendor and the solution side. This observation is valid for the open software solutions as well as for the commercial packages offered. Common features are emerging, but the software solutions still seem to be in that stage of technology development where features are added instead of the iPhone stage where a solid set of minimum features are defined by a market leader. We believe that the consolidation phase is yet to happen, and that various solutions may be used and tested until consolidation has happened both on technology and vendor support. It is important to avoid lock-in and keep deployment and integration costs manageable in this phase.

9/22

3.2 Licensing 3.2.1 Licensing models A web conferencing solution can be purchased as a service from a provider or as a software package to be installed and operated on site. The most common reason for running a local installation is the possibilities for integration this offers. Integration with local AD/LDAP or community authentication systems like Feide is available from some vendors. Integration with local calendaring systems is available from some vendors. Independent of service model (local installation or ASP) licensing is typically a factor of: •

the number of available meeting rooms

•

the number of participants.

The last number will typically be a maximum per room although for example Adobe Connect licenses its software with a number of (concurrently usable) seats for the particular installation. Some of the unified communication solutions also offer licensing for all local users with a number of outside invitees. Common licensing models include •

•

•

•

•

#room You pay for a room of a certain size, typically 20, 50, 100 and 100+ participants. A room has one host account, this is the person who can organise and configure meetings. The terms of use often allow you to share the host account between multiple people but this is rather unpractical, and often includes sharing passwords. #named hosts You pay for a host account, where the host is a meeting organizer. A host account can usually create multiple meeting rooms, but can only use one at a time. A room typically does not function without the host or meeting moderator being present. #concurrent users # seats in concurrent use. May be independent of number of rooms or named hosts or servers. #servers # servers installed. When running a solution on-site, often a server license comes in addition. The cost of this is while not negligible usually small compared to the other licensing parameters. site license for all users You pay for a site license, where payment is related in some way to the size of the institution. This model is not widely available today, but is probably where we would like to go when the web conferencing solutions are widely deployed and used.

Web conferencing is not in wide use, but there is active investigation and several small scale deployments with plans for larger scale use. This points towards a hosted solution with a license limited by number of concurrent users, with the possibility of rapid scaling.

3.2.2 Service delivery The market reconnaissance was to provide a quick overview of promising available solutions, get a feeling for common and distinguishing features, deployment complexity and licensing models. The 10/22

five major models of service delivery we have looked at are 1. Free services (examples: small scale web conferencing in several solution, Skype) 2. Hosted solutions, web meetings as Software-as-a-Service (examples include: AdobeConnect, WebEx, Elluminate, Skype/Vivu, NTR-meeting) 3. Shared solutions, hosted a central place in our network (example: EVO, SUNET's AdobeConnect solution hosted by NORDUnet at their servers) 4. Per site installations that interconnect, mostly unified communication solutions (example: Microsoft Office Communication Servers) 5. Open source software, hosted a central place in our network (examples: BigBlueBotton) The functionality of free services offered does not satisfy the requirements for the scenarios when operating on an institutional scale. The limited functionality you find in for example Skype is still useful for some scenarios, notably the ad-hoc scenario where we find many user populations forming collaboration solutions based on Skype. Typically they use Skype for voice and chat, and share documents in other fashions (email, Google Docs, Etherpad etc). The hosted solution (SaaS) allows easy scalability and allows us to focus on the use for education without the need for building specific system administration skills for the web conferencing solutions. Shared solutions are used to ensure integration and get site-wide licensing. SUNET have implemented federated login (using SWAMID, the Swedish equivalent to Feide), which gives easy access to web conferencing for all users in Swedish higher education. This centralized model is also used by those who want to ensure high bandwidth and low latency to their hosted solution. Central hosting will require an up front investment in servers and skilled system administrators, as well as a procurement of licenses. Per site installations may end up with a multitude of servers per site, where the total number of servers explode far beyond what is needed for scaling in order to accommodate the institutional security borders. Open source software solutions are available, and we have identified one promising solution: Big Blue Button, which is currently being tested by Høgskolen i Telemark. We have not found any solution that is evaluated as good enough for a current wide scale deployment. The usual lack of high sound quality and federated login are present in all the open source solutions we have looked at. All commercial web conferencing solutions are available as hosted solutions. A number of solutions can also be installed on-site, either as an installable package or as an appliance. Solutions for unified communication are often per site installations, as they rely on local AD or LDAP user management.

3.2.3 Connectivity to hosted solutions The connectivity to the hosted solutions is generally speaking good enough. Bandwidth, latency and round trip time (RTT) are all within acceptable tolerances: they do not lead to a deteriorated user experience. Reflectors are usually within Europe and in network terms close enough to Norway, given the extensive international network provided by NORDUnet's international links. Tests from Perth, Australia indicated that even such a distance is no problem as long as the RTT to the hosted solution does not exceed 500ms. One tested solution showed a RTT of 1500 ms and that lead to a deteriorated user experience. The conclusion is that a Norwegian or Nordic reflector is not needed to provide an adequate service as long as the RTT stays within reasonable values and jitter (variation in RTT) is under control. Like any other major service provided outside the network, it is important to have monitoring and data 11/22

gathering of network traffic patterns to the service. If someone reports a problem with the service, having network statistics available makes it possible to determine if it is a network problem or a service related problem.

3.3 Technical developments There are a number of technical developments are likely to significantly change the market place in the near future: •

Flash is currently a market leader for web based multi media applications. Apple refuses Adobe's Flash access to the iPhone and iPad. The latest development is an addition to the iPhone SDK contract only allowing developers to use a certain set of languages to develop iPhone applications in. This set does not include Flash. For some reason Apple wants to keep Flash applications away from the iPhone and iPad platform. Where this battle is going to end and who will win is as of yet uncertain.

•

Microsoft pushes its Silverlight product. Silverlight offers functionality similar to Flash and is supported on the popular browsers on the Apple Mac, Linux (through the Moonlight open source plugin) and Microsoft Windows platform.

•

HTML5, the new web language standard, is nearing completion. Significant parts of the new standard are already supported by Firefox and IE. HTML5 includes new features like Canvas (allowing drawing in a web browser using JavaScript), multimedia support and a way to recognise audio and video devices. What that means is that audio and video conferencing using just a standards compliant browser, without any extra plugins, will be possible. Google has recognised the potential of HTML5 and is betting big on it. YouTube videos can already been watched plugin-less using a HTML5 compliant browser. The Google Gears plugin, used for supporting the offline mode of gMail and GoogleDocs, will be phased out in favour of similar functionality found in HTML5. It will take several years before the standard is entirely adopted but already many of the new features relevant for web conferencing are agreed on and implemented. With Google putting its weight behind the adoption of the standard something is bound to happen that will greatly influence the way current web conferencing applications are implemented. There is still no agreement on a standard codec for HTML5.

These developments are typically steered by the big web players like Adobe, Apple, Microsoft and Google who have multi-billion dollar interests at stake. What all developments have in common is that we can not influence them but they will certainly influence us and the choices we can make. As of yet things are in a state of flux and which horse will prove to be a safe bet is unclear.

4 Requirements and assumptions 4.1 Top level requirements for sector wide solutions The following top level requirements have been identified for a sector wide baseline for web conferencing solutions: 1. Invitation link: Participation in a web conference must be possible without a having local user account, e.g. by sending an invitation link or using a Feide login); 2. Easy access: Ad hoc collaboration infrastructure should be available without any bureaucracy to students for study groups and for researchers for project work.

12/22

3. Small and large meetings: Any (collection of) web meeting solution(s) must support both small and large meetings. For the meeting scenario a room should accommodate up to 20 people, after that the meeting turns into a lecture. For use with online lectures a meeting room should accommodate the same number of people as a physical lecture room would, in practice this means up to 50-500 people. Ad hoc collaboration has high interactivity and normally needs to support up to 8-12 persons. 4. Audio is king: Excellent audio quality is one of the most important features in a web conferencing experience. The audio has to be without distortion, delays etc.; 5. Multipoint capability: Any web meeting solution needs multipoint capability: the ability to let more then two people communicate with each other simultaneously; 6. Chat: Any web meeting solution needs chat functionality; 7. Shared work space: Any web meeting solution needs a shared work space and a pointer that can at least be controlled by the meeting presenter (lecturer, chair); 8. Feide login: If authentication is needed to set up a meeting then this authentication should comply with Feide login using SAML2. For solutions geared towards local users with a few outside participants, use of institutional user databases (LDAP/AD) is an alternative. Many institutions do not have students in their AD, so any solution for students should support Feide.

4.2 Assumptions The following assumptions have been identified: 1. The most important issues for eCampus are the use of web conferencing in the lecture and ad hoc collaboration areas as defined in the table in chapter 2.4; 2. Users can handle different user interfaces. All web conferencing solutions offer a similar user experience so from a user deployment perspective conversion time from one to another solution is not a big issue; 3. The requirements of all Norwegian HE institutions have sufficient similarities to facilitate a usable shared solution or shared requirements 4. Using two or more different web conferencing solutions on the same desktop does not lead to practical issues, they do not bite each other; 5. Solutions need to support various platforms: a. MS Windows (MUST) b. Mac (MUST) c. Linux (nice to have) d. Mobile platforms (nice to have) 6. A solution is preferably as much browser based as possible and can be used 'as is' on a user's existing desktop environment. Any extra components should download quickly and require as little user interaction as possible, also on slow network connections. 7. A requirement to install a piece of client software on the user's desktop is a significant hinder for deployment; 8. Audio is king. Video in web conferencing is very much of secondary importance, the audio needs to be excellent and free of chop; 9. Having a solution that works Good Enough is more important then tight integration with for example the LMS and/or institutional directory; 13/22

10. Meetings are initiated from within an institution, e.g. by a teacher, student, staff, researcher; 11. Persons physically or organisationally outside the institutional borders must be able to participate in meetings, lectures and ad hoc collaboration; 12. The ad hoc collaboration in higher education and research is typically document centric; 13. The maximum one-time set up time per user must NOT exceed 30 minutes, and should be lower than 10 minutes 14. The maximum fumble time to sort technical issues out before a meeting starts must NOT exceed 5 minutes; 15. Global low latency and low jitter to service is important: exchange students, foreign guest lecturers, collaborators; 16. Web conferencing solutions lifetime is limited to 2-3 years from now; 17. The web conferencing market will change substantially over next 2-3 years leading to a different mix of vendors, price and features; 18. Contracts have an institution centric view: they will be made per institution. There will be no more then one solution for each of the three areas (meeting, lecture, ad hoc collaboration) with institutions having a desire to consolidate to one solution for all three areas. 19. Licensing should be based on the number of rooms possibly combined with a maximum number of participants per room, analogous to the concept of meeting/class rooms of various sizes in the physical world. Lectures and most meetings are and can be planned well in advance leading to predictable resource use. A number of concurrent users per installation or per institution is going to lead to unexpected resource depletion at a likely inconvenient time.

5 Consultation and discussions 5.1 Practical options A number of practical options to help us attain the goal of ubiquitous web conferencing have been identified. The focus is on the usage scenarios 'lecture' and 'ad hoc collaboration' as sketched out in chapter 2. To make practical progress, pursuing a combination of options is likely needed. Which options make most sense to pursue depends a lot on the answers to the open questions described in chapter 5.2. Important to keep in mind is the requirement for a formal tender procedure when purchasing services or goods with a value of NOK 500.000 over 4 years. •

Do nothing: do not undertake any sector wide activity;

•

Increase competence and skills: facilitate training in using web conferencing for lecturers, students and researchers by leveraging existing training resources. For example Bodø university college has online training material available. eCampus can be instrumental in bringing training resources, trainers and trainees together;

•

Document common requirements: establish a small eCampus working group to write a common requirements specification (UFS) for web conferencing. This document can be used for product/service selections by individual institutions and for a possible joint approach;

14/22

•

Market reconnaissance: make a quick inventory of service providers and software packages considered to adhere to the set of common requirements, let each institution or SAK coalition make their own decision and not undertake any action to a shared service or shared purchase;

•

Sector wide (framework) agreement: aim for a sector wide (framework) agreement for web conferencing services and/or software. This involves a formal purchase process with the associated labour cost. This option requires a Call for Tender to be ready by (early) June if we are to have a contract in place around December 2010. A framework agreement can be established for both software and services. The result will be a solution from one or more ASPs or software vendors. The business relationship would be between the solution provider and each individual institution;

•

Open services: recommending open services that are available for free, such as Skype, GoogleDocs, DimDim etc.;

•

Establish a shared solution within the sector ◦ Use services of other NRENs: SUNET, the Swedish NREN, has deployed a national Adobe Connect service and integrated it with their SwamId identity federation. Sweden is positive to the idea of letting Norwegian institutions use their installation, as is Denmark. Other NRENs have installations we might be able to leverage; ◦ UNINETT service: establish a UNINETT web conferencing service based on one or more commercially available and supported solutions. Such a service could be based on a commercial service, on an installation of a commercial software package (like Adobe Connect) operated under UNINETT's responsibility. ◦ UNINETT pilot service – open source based: there are a number of open source packages for web conferencing available (DimDim, OpenMeetings) that appear to meet most requirements. Rather then spending money on licenses and support we can invest that money in establishing a professional service based on open source software. Any missing features can be implemented using the money we save on licenses. This option would likely start as a pilot service; ◦ Extending open services with functionality specific for the research and education sector, such as plugins for popular services, paying for software development, etc.;

These options could be combined into a best of breed combination: use different solutions for different size meeting rooms and different scenarios optimising on cost and functionality. There is a limited sector-wide need for really big meeting rooms with up to 500 participants (lectures), a controlled and predictable need for rooms up to 50 participants (lectures) and a fairly unpredictable need for rooms up to 20 participants (ad hoc meetings). Several vendors provide options for free small meetings up to 5-20 people, depending on the vendor.

5.2 Feedback from universities and colleges Spring 2010 was the time for consultation with higher education institutions in Norway about the road forward for web meetings. The first and strongest feedback was 1. Web meetings are being actively investigated and tested in large parts of the community. The scenarios for meetings, lectures and ad-hoc correspond with the perceived needs. 2. Sound quality matters. Good enough audio was the most important requirement. Everything else is icing on the cake. 15/22

3. Everyone should be able to organize a meeting with minimal bureaucracy. Access should be managed using Feide login. It must be possible to invite guests to a meeting. 4. Meetings, lectures and ad-hoc must all function across institutional borders. This is of crucial importance for the SAK coalitions. 5. We must aim for usability, not technology. Technology must play second fiddle to teaching, learning and research. There is no time for stuff that does not work at first try. Digital competence is important for lecturers and meeting chairs. 6. Solutions must support multiple platforms, with a possible exception for the meeting scenario. More and more students use Macs, and there is a Linux user population in addition to various Windows versions for PC. There was much discussion of what kind of integration is most important, and the answers varies both from institution to institution and between the scenarios. The conclusion was that the most important integration requirement was Feide login, to get single sign on and avoid having all users initiate a new user account for web meetings. With Feide login, it should be possible to predefine meeting rooms and leave the URL to the meeting room inside a portal, a LMS or a social web solution. Other integration wishes include • • • • •

•

calendaring support, integration with email for invitations LMS integration, at least by adding a URL to a “room” in the LMS group support, with organizational structure, with course information, with self-defined groups and roles, with social web sites (ala Facebook); and with buddy lists video conferences lectures captured inside a web meeting room should integrate with other lectures captured in the institution, and be handled by a institution-wide media asset management system, and archives integrated with other digital learning resources support for dialogue, using web2.0 and other social media

5.3 eCampus goals for web meetings The eCampus goal for web conferencing is to enable online collaboration in education and research by establishing ubiquitous access to web meeting tools that support the three scenarios laid out earlier in this document • meetings • lectures and learning environments • ad-hoc collaborations Ideally there would be tools with one consistent user experience supporting all three scenarios accessible to all students, lecturers and staff within the Norwegian higher education and research community. A good solution would allow anyone to set up a meeting of any size through self service, not involving any bureaucracy. In practice this means Feide login for the meeting organizer, a sector wide licensing scheme and self service solutions for meetings.

16/22

5.4 Recommendation for web meetings A task force of volunteers from universities and colleges has investigated: • requirements for web conferencing solutions for the higher education sector • the web conferencing market • whether or not a sector wide web conferencing approach is desirable The task force concludes that: • various web conferencing solutions are in use with the different institutions but none of them can be used for all three usage scenarios described in the eCampus web conferencing discussion memo. Most institutions already using a particular solution have focused either on lectures (especially those with many net-based courses) or meetings (multi-campus); • there is currently no commercial solution available that satisfies all requirements and is available against favourable business conditions; • there is currently no open source solution available that is sufficiently mature to be used for the three scenarios; • there is a strong desire within the higher education sector to start using web conferencing to build competence and explore education specific use; • it will take time for users to start using web conferencing on a large scale. Experience from Swedish SUNET points to a ramp up period of 1-2 years before use really takes off; • a sector wide approach is desirable ◦ to enable use of web conferencing on a large scale (several 10.000s of users); we believe the use of web conferencing functionality will increase a lot in the years to come; ◦ to create favourable business conditions for a large scale deployment of web conferencing functionality to all lecturers, students, researchers and administrative staff in the higher education sector; ◦ to motivate the market to provide us with solutions that satisfy our requirements, in particular with regards to use of identity federations (Feide) for user management and good quality audio (echo cancellation); ◦ to achieve the eCampus goal of ubiquitous access within the Norwegian higher education and research community to tool(s) supporting the three aforementioned use case scenarios. • a sector wide approach does not automatically imply one centralised solution. The task force recommends to: 1. make a small scale interim web conferencing solution available to the higher education sector for the time it will take to execute the Call for Tender process described in recommendation 3. This period amounts to the coming academic year (Sep. 2010 – Aug. 2011). This interim web conferencing solution is to: a) enable and stimulate institutions and users currently without access to a web conferencing solution to start building digital competence related to use of web conferencing b) gain practical experience with a sector wide solution c) start building digital competence for using web conferencing in an educational setting This solution should be sized similar to the SUNET installation, supporting around 250 concurrent users during the first year. 2. Continue consultations with vendors during fall 2010 and work to get desired functionality (like Feide support) available 3. run a Call for Tender for a sector wide solution to be operational in June 2011 a) write the Call for Tender specification in Oct. - Nov. 2010 17/22

b) run the formal CfT process in Dec. 2010 - Mar. 2011 c) selection process Feb. 2011-Mar. 2011 d) agreement signed Apr. 2011 4. set up facilities and processes for training of web conferencing skills and building competence regarding use of web conferencing in an educational setting (start Aug. 2010) 5. establish a small scale experimental service based on the open source solution 'Big Blue Button' and evaluate its usefulness by organising a small group of real pilot users. (start Sep. 2010) The time line is as follows:

18/22

1 Appendix: technical requirements for on-line collaboration This appendix outlines some scenarios for use of web conference, video conference, document sharing and desktop video conference in the academic network.

1.1 Scenarios for collaboration across networks 1.1.1 Scenario: two people write together Two persons need to work together to produce a document. This could be a student assignment, a research report or a staff memo. The main support needed is for collaborative editing and sound. Working together requires the ability to communicate (by talking) and sharing work (collaborative editing). Video or chat may be useful, depending on the context and familiarity of the users.

1.1.2 Scenario: meeting to meeting Classic video conferencing is a meeting between people located in meeting rooms at each site. The meeting has a chair person, an agenda that was distributed ahead of time, and meeting minutes will be distributed afterwards. The meeting includes people at two sites, and there are presentations given. Sound and video is important, whereas application sharing is less important. Presentations require ability to share slides or using a document camera.

1.1.3 Scenario: person participates online in physical meeting A person online needs to participate in a meeting at a meeting room or physical classroom to attend class, do research or be a part of a staff meeting. The meeting has presentations, a chair and several participants in the meeting room. This scenario requires support for all the facilities in both the online meeting and the room-to-room scenario.

1.1.4 Scenario: online meeting with many participants Web conference or desktop video conferencing is a way to support an online meeting with several participants, where all the participants are online from their own desktop. The goal is often to present material for discussion.

1.1.5 Scenario: teaching an online class One teacher needs to present material, students are participating online. Sound must be good, and the teaching material must be available. Video is useful, as is chat. The scenario may be looked upon as a special case of online meetings, where the teacher chairs the conversation. This is the primary scenario investigated by HiBo for their web conference activity. Indications from other academic networks in Europe point to scaling for online classrooms with 15-20 people. Chairing the video conference includes tools for raising your hand and asking explicit questions to participants (did you understand, is the speed ok), and the need for these tools increase with the 19/22

number of participants. Feedback from participants should be available without everyone needing to speak, through other feedback channels to the teacher or chair person.

1.1.6 User groups Editing-2person 2xMeeting Peer-to-Meeting Online-meeting Online-class YES NO NO NO? YES NO NO NO YES YES

Students Teachers Researcher YES s Staff YES

YES

YES

YES

NO

YES

YES

YES?

NO

1.2 Technical 1.2.1 Web conference roles Administrator should be able to • • • •

update software solution configure and reconfigure manage access for other users (add, delete, change) monitor and measure use of resources

Organizer should be able to • manage meeting rooms (create, delete and configure) • invite participants ((send invitations and reminders before a meeting, and send invitations during a meeting) • edit invitations with text, links and images with specific content for each meeting • define the user who will be moderator • reserve resources required for a set period (resource timetable management) Moderator should be able to • invite participants (during a meeting) • open/close access for end users to send audio, video, chat and sharing • end a meeting

1.2.2 Functionality Solutions for meeting rooms should include • • • • • • • • 20/22

Transmission of sound from participants, with ability for moderator to mute participants Transmission of video from participants Chat, with option to private chat among participants Display of presentation material (ODF, PDF and powerpoint/excel spreadsheets) Comment and draw in presentation material, with export to PDF Shared workspace for text and images, with editing facilities for all participants Application sharing option, including co-browsing Whiteboard, with export to PDF

• Raise your hand-functionality • Ability to record sessions and share recordings at a later stage • Feide login (based on SAML2), and possibly additional support for local LDAP or orphanage In addition there is functionality for e-learning that we have not investigated • • • •

Polls controlled by moderator Integration with e-learning systems Dividing participants into working groups Predefined groups from campus identity management systems, student registry or LMS

Encryption of meetings is an option to be investigated for future use.

1.3 User environment Web conference and collaboration tools support • • • •

exchange audio and video streams share desktop and specific applications, and interact with the shared workspace display presentations may answer polls and other functionality associated with e-learning

Assumptions for user environments when users work online in a web conference and collaboration tool: • Support for the following platforms • Windows (XP, Vista) with Internet Explorer, Firefox (min 3.*), Opera • Mac OSX with Safari, Firefox (min 3.*) • Linux with Firefox • Pre-installed headset with microphone, correctly configured • Pre-installed camera, correctly configured • Java or Flash, installed and correctly configured • Bandwidth will vary, assume broadband for normal use case, but should support lower bandwidth • Firewalls may be present, open TCP ports for outgoing traffic should be a least http/80, https/443, rtmp/1935. Could have additional proxies present. Some scenarios involving meeting rooms may have to support additional open ports for UDP and TCP, even if the end user should not be assumed to control access to firewall configuration.

1.3.1 Interoperability Interoperability challenges get bigger when crossing security boundaries or organizational boundaries. Working from home on a non-secure PC/Mac by definition cross a security boundary before reaching anyone, and places high requirements on peer to peer communication. Communicating with a central server is less complicated, as the number of boundaries crossed is limited. Vendor lock-in is a danger when choosing products, and such lock-in may manifest in different ways: • software installation: requiring everyone participating in a meeting to download and install specific software on their PC/Mac • lock-out of other solutions: being unable to participate in other meeting solutions as the PC/Mac is pre-configured for a specific solution and the other solutions may have conflicting requirements that are difficult for the end user to sort out 21/22

• data rot: stored content/data, developed for a specific whiteboard or document format, get inaccessible as the contract expires • no sharing of information: impossible to extract content/data to other systems Some interoperability challenges may be solved on the organizational level for applications residing inside the organizational security boundary. Traditional video conferencing, with pre-configured meeting rooms, is an example where dedicated staff and pre-punched holes in firewalls make it possible to use not-really-interoperable products across organizational borders. Open standards, and consistent implementation of these, play a key role in interoperable collaborative solutions. The current technology situation makes it necessary to test products for compliance with open standards.

1.4 Background work BELNET shared their call for tender with us, and some of the technical information is adapted from their documents. Bodø and Telemark University Colleges provided input based on their evaluations of existing tools.

22/22