From Steeple

Work packages are derived from outcomes and deliverables. Discuss outcomes and deliverables here!

How to edit the work packages: Use the section edit links next to the work package descriptions below. Editing this page itself will just show you a set of semantic queries, and you won't be able to adjust any of the work package properties.

Discuss the work packages here!

Contents 1 Requirements and design (WP1) (5 weeks effort, during months 1-2) 1.1 Community liaison, scoping study and requirements analysis (5 weeks effort, during months 1-2) 1.1.1 Project Community Wiki 1.1.2 Enterprise Podcasting - Techincal and Requirements Overview 1.1.3 Compile User Literature 1.1.4 Compile Use Cases 1.2 Compile use cases (3 weeks effort, during months 2-3) 1.3 Policies and Processes - agnostic (8 weeks effort, during months 4-8) 1.4 Requirements to implement channels for public access (6 weeks effort, during months 3-5) 1.5 Accessibility Requirements/Demonstrators (4 weeks effort, during months 1-6) 2 WP/2 2.1 Initial technical setup (11 weeks effort, during months 3-5) 3 WP 3: Implement some delivery channel demonstrators 3.1 Institutional Web Portal for podcasts (18 weeks effort, during months 6-11) 3.2 Cross-institutional Aggregator Demonstration (6 weeks effort, during months 4-14) 3.3 Third party portals, channels, modules (8 weeks effort, during months 7-9) 3.4 LMS/VLE Internal Distribution Demonstrator (6 weeks effort, during months 9-11) 4 WP4: Encoding engine 4.1 Configure Processing Engines (6 weeks effort, during months 4-6) 4.2 Encoding scripting and development work (8 weeks effort, during months 6-9) 5 (0 weeks effort, during months 1-2) 6 Process Management System for content life cycle (16 weeks effort, during months 7-11) 7 8 WP8 8.1 Evaluation of systems (6 weeks effort, during months 12-12) 8.2 Cost models (2 weeks effort, during months 4-12) 9 Dissemination and Training (18 weeks effort, during months 1-16) 10 Final Report (11 weeks effort, during months 1-16) 11 New WPs 11.1 (0 weeks effort, during months 18-18) 11.2 (3 weeks effort, during months 1-3) 11.3 Blank (0 weeks effort, during months 18-18) 11.4 Blank (0 weeks effort, during months 18-18) 11.5 Blank (0 weeks effort, during months 18-18)

Overview of work packages:

Workpackage	Title	Total Effort (Weeks)	Lead	Ox	Cam	OU	Month Start	End
WP/1	Requirements and design (WP1)	5	Ox	3	1	1	1	2
WP/1-1	Community liaison, scoping study and requirements analysis	5	Ox	3	1	1	1	2
WP/1-2	Compile use cases	3	Ox	1	1	1	2	3
WP/1-3	Policies and Processes - agnostic	8	OU	1	1	6	4	8
WP/1-4	Requirements to implement channels for public access	6	Ox	3	2	1	3	5
WP/1-6	Accessibility Requirements/Demonstrators	4	OU	1	0	3	1	6
WP/1-5	Requirements for private access to LMS or VLE.	2	Ox	1	0.5	0.5	2	4
WP/2a	Initial technical setup	11	Ox	8	1	2	3	5
WP/3a	Institutional Web Portal for podcasts	18	Cam	5	11	2	6	11
WP/3b	Cross-institutional Aggregator Demonstration	6	Cam / OU	2	2	2	4	14
WP/3c	Third party portals, channels, modules	8	Cam	2	5	1	7	9
WP/3d	LMS/VLE Internal Distribution Demonstrator	6	Ox / Cam	3	2	1	9	11
WP/4a	Configure Processing Engines	6	Ox	6	0	0	4	6
WP/4b	Encoding scripting and development work	8	Ox	8	0	0	6	9
WP/5		0		0	0	0	1	2
WP/6	Process Management System for content life cycle	16	Ox	12	0	4	7	11
WP/7ab		0		0	0	0	1	2
WP/8a	Evaluation of systems	6		3	1	2	12	12
WP/8b	Cost models	2		1	0	1	4	12
WP/9	Dissemination and Training	18		4	10	4	1	16
WP/A10	Final Report	11		5	3	3	1	16
WP/New1		0		0	0	0	18	18
WP/New3		3		1	1	1	1	3
WP/New5	Blank	0		0	0	0	18	18
WP/New6	Blank	0		0	0	0	18	18
WP/New7	Blank	0		0	0	0	18	18

Bjoern: About effort: We should agree that the project will proceed in an agile way, and that commitments are 'fixed time', not 'fixed deliverable'. I.e. each institution should spend the allocated time, and where additional time is required (or where time can be released) this is moved into a different WP.

Bjoern: We should track the progress of each WP through the wiki. Blog posts might be tagged with WP numbers, which can then be displayed next to each WP entry.

Summary of effort:

Total Effort Oxford (weeks)	Total Effort Cambridge (weeks)	Total Effort OU (weeks)	Grand total (weeks)
73	42.5	36.5	152

(The grant total is about 2 FTE * 1.5 years, which is about 132 weeks. Calculation: 220/5*1.5*2. Oxford should have twice as much work as Cambridge and the OU.)

Note the project start and end is calculated by Template:Steepletime, and gives project month 1 = Nov 2008 (project start), and project month 18 = Apr 2010 (original project end).

Comments PR

• Roughly 74 Oxford Weeks. Approx 36 Cam Weeks, Approx 39 Open Weeks. This is heading in the right direction but there is the sense that there is too much work, too many dependencies and too much overlap for a small amount of people - so some packages need to be trimmed or dropped.
• If there are 44 working weeks in an academic year (52), then on average, there are 58 weeks of work/resource time in an 18 month period.
• If it is based on Cam and OU having 0.6 of a dev person each, their real time work effort is 60 weeks and 65 weeks respectively.

Comments Carl

• In process of trimming and restructuring project plans based on the past 6 months and current thinking (May 09).

[edit] 1 Requirements and design (WP1) (5 weeks effort, during months 1-2)

Bjoern's suggestion is to do this as a 'book sprint'.

Overall description of Work Package 1

[edit] 1.1 Community liaison, scoping study and requirements analysis (5 weeks effort, during months 1-2)

(was WP 1/a)

Following the launch of the project Oxford will recruit Technical Support Officers, prepare the website ([1]) and contribute to the community wiki ([2]). Technical preparation will begin by preparing a timeline for the Oxford institutional testbed server implementation, including ordering equipment and preparing a small set of local client capture machines. At this point key departmental content creation partners will be notified of the pilot work.

All project members must share prior use-cases, consolidate relevant publicly available reports and compile their experience of the podcasting domain. There should be a particular reference to the current recommended workflows and best practice. A simple enterprise ‘podcasting for beginners’ document is needed to explain the workflow path of capturing and delivering material in a typical enterprise podcast encoding architecture. This is mainly to inform non-technical steering group members and institutional stakeholders.

Deliverables

[edit] 1.1.1 Project Community Wiki

briefing documents in project wiki linked from web site (http://steeple.oucs.ox.ac.uk/).

[edit] 1.1.2 Enterprise Podcasting - Techincal and Requirements Overview

Working paper on “Enterprise Podcasting - Technical and Requirements overview” for project staff and potential Learning Technology staff including the JISC and OpenCast community. (A starting guide)

[edit] 1.1.3 Compile User Literature

Compilation of current partner user orientated literature (user guides, equipment guides etc) and relevant podcasts on public website, such as the detailed presentation from Oxford on placing the University in iTunes U.

[edit] 1.1.4 Compile Use Cases

Cross links and connections to be established to existing podcasting and streaming projects such as JISC Podcasting Pedagogy SIG, Leicester IMPALA, TASI, OpenCast Podcasting based at Berkeley and JISC ELTAC (Coventry University lecture capture room capture).

[edit] 1.2 Compile use cases (3 weeks effort, during months 2-3)

Compile a list of "use cases" from constituent departments, media units and potential solo content creators ( lone academics) who have already registered an interest in podcasting and audio-video content creation. The emphasis should be on those departments with clear requirements and an ability to contribute time to any pilot testing of architecture. Oxford will document legacy material, current activity, audio and video format needs, recording situation, urgency of turnaround on recording content, mixing of material, scheduling etc. The workflow for 'virtual' project teams will be clarified.

Deliverable:

• 6-7 use cases typical of departmental and administrative needs for podcasting suitable for JISC community. Each use case should mention existing technical setup, support issues and potential workflow with an evaluation of where gaps in technical support could be mediated from the centre.

Skills required:

[edit] 1.3 Policies and Processes - agnostic (8 weeks effort, during months 4-8)

(Was WP 1/c)

This work package will provide a simple step through guide to policies and processes that need to be considered by institutions considering podcasting at an enterprise level. It will cover briefly the range of typical issues that need to be tracked and monitored when producing audio and video content for public distribution through podcasting channels such as the web, iTunes U and YouTube. The issues should be collated into a typical workflow sequence to show the dependencies that need to be factored in from start of recording to final sign-off.

This work will document current content management processes practiced at the three active institutions, particularly focusing on the Open University who has a more mature and complex set of processes. The work will document resource creation workflows: tracking issues; filming permissions and best practice; legal paperwork for speakers to sign; logging of metadata; reviewing material; artwork; technical sign-off; paperwork sign-off; contact details for speakers and IPR/copyright tracking.

Deliverable:

• Report including a simple schema for stages of processes mapped to policies, spreadsheet of tracking issues, diagram showing workflow and manual check stages.

• Policies and Processes Report

Skills required:

[edit] 1.4 Requirements to implement channels for public access (6 weeks effort, during months 3-5)

Document pathways for material to be created, encoded and stored for an institutional presence in typical delivery channels, including public access (institutional web portals, cross-institutional web-portals, iTunesU, YouTube), Create various use case options that mimic a typical university’s activities: Public material; Course material; Social and Campus material; Administrative activities e.g. Admissions; Document the local needs in departments for teaching, research and public dissemination, consider how can be met by central services and public channels. Test sample prepared content linked from institutional content servers by RSS/Atom services and any channel related web services.

Deliverable:

• Document outlining different presentational options for an institution through content delivered by an institutional RSS service, including an institutional portal and a 3rd party service presence.
• Provide suitable modules for delivery into websites and services (including specifications in DTD, as well as XSL and template transforms for XML/MYSQL databases where appropriate).

[edit] 1.5 Accessibility Requirements/Demonstrators (4 weeks effort, during months 1-6)

This short work package will investigate and give a general report on accessibility requirements for podcasting related media (transcripts, captions, automatic OCR of video slides, low bandwidth formats etc), including an initial study of the costings for additional accessibility work. The package will briefly examine potential future innovations ( such as speech to text ) in automating and producing this content. The ease of incorporating transcripts into workflows and display channels, multiple formats for content, closed-captioning, etc. will be considered.

Audio editing will be explored in greater detail; looking at ways to automatically improve audio quality in media files via normalization, EQ noise reduction, low bandwidth issues, etc.

Deliverable:

• Simple short document outlining issues and considering future technical developments, including advice on how accessibility issues such as transcripts can be efficiently integrated into the workflow

Accessibility requirements report

== Requirements for private access to LMS or VLE. (2 weeks effort, during months 2-4) ==

This package will document pathways for material to be created, encoded and stored for an institutional use of media in a VLE/LMS, such as Moodle and Sakai.

The key is to define the privacy requirements, then consider how this might be enforced either technically or through policies, and what the obvious risks are for the public release of material. It is important to outline that the risks might mean certain material may not be suitable for hosting either publicly or through a private channel.

Deliverable:

• A simple, short document outlining issues and considering different integration and presentational options.

One party needs to produce integration with Sakai, the other party with Moodle.

Skills required:

[edit] 2 WP/2

[edit] 2.1 Initial technical setup (11 weeks effort, during months 3-5)

• 2 Weeks for Oxford to setup new SAN storage hardware
• 2 Weeks for initial Replay system to be setup for test purposes
• 2 Weeks to document the approaches taken with both aspects.
• 2 Weeks to setup new PcP Processing node (ideally using Episode Engine)

Some consideration needs to be given here to reporting on technologies, capabilities and implications (e.g. networks/comms and network capacities; storage requirements dependant on file types and durations; deep archiving practices)

Work package 2 is initial architecture work building upon Oxford’s current implementation of Podcast Producer documented in WP 1.1 and also informed by requirements outlined in WP 1.1, WP 1.4,1.5,1.6.

The project needs to install a new server testbed and document the hardware requirements of the server, supporting server infrastructure and the storage and back-up scenarios for low and medium usage. The project will need to process and store extremely large amounts of video and audio data at an enterprise level. Therefore considerations must be made for a modular approach to the architecture built around server resilience; any developments must fit as much as possible with existing centrally supported architecture. Any online hosting requirements must be resilient and secure, and network security concerns must be explicitly stated. The online storage of material should be placed on a dedicated SMB/AFS network or similar to isolate and protect the encoding engine from public online vulnerability. This work will document a typical testbed and use it to review set encoding engine options, which may be commercial or open source (e.g. Podcast Producer or ETH Zurich's open source engine REPLAY), or a combination of commercial/open products. The project will pilot with current architecture based on Apple’s Podcast Producer and Episode encoding engine but will install, review and consider the following encoder scenarios:

• PCP and episode podcast on it's own (likely to be insufficient)
• ETH Zurich’s Replay 0.5 + ffmpeg (an open end to end solution but in early beta)
• ETH Zurich’s Replay 0.5 Replay with episode engine as transcoder
• Replay 0.5 using PCP and episode podcast as transcoder

This will cover a wide range of server encoding related topics:

1. Installation and configuration of Podcast Producer (PP) on main architecture
2. Installation and configuration of Replay on test architecture (VMware?)
3. Installing and using Episode Podcast
4. Detailed hardware requirements analysis (both for the pilot project and for any future podcasting service)
5. Integration of PP into Oxford LDAP environment
6. Initial work on Kerberos cross-realm authentication with Oxford KDC
7. Xgrid best practices

Deliverables:

• Documentation, including:
  • architecture schematics;
  • equipment list;
  • storage estimates per annum;
  • and a review of server requirements per product.
• SWOT analysis on PP and Replay.

Skills required: This is one of the more technical packages that requires insight into networking, file systems, SAN setup etc. Oxford will contribute support from across the computing services department to assist with technical expertise.

[edit] 3 WP 3: Implement some delivery channel demonstrators

Work package that shows explicit delivery goals for the project – i.e. what we do will leads to these outputs.

In detail, the required demonstrator services include

• a demonstrator module for institutional, public web presence
• a demonstrator module for delivering into commercial 3rd party services, such as iTunesU, YouTube,
• and demonstrator modules for non-commercial 3rd party services, including a UK-HE syndication portal, and GGfL.

Bjoern 11:14, 2 November 2008 (UTC): I feel this is a core deliverable of the project. In my view, producing modules that can be used by all UK-HEIs would have a key impact on how much UK-HE media gets onto itunesu, youtube, ggfl, and a syndication portal. I would vote for increasing the time for all partners on this WP.

Kick-start meeting gives agreement that workpackage needs to be much bigger than originally conceived.

[edit] 3.1 Institutional Web Portal for podcasts (18 weeks effort, during months 6-11)

This work is to develop a demonstrator web portal for displaying an institution’s audio and video podcasting content, arranged by categories. It may not be possible in the time available to offer a fully featured solution but the work will involve reviewing existing options and the development of a selected solution that meets core partner requirements and support infrastructure. The ideal solution is an easy to maintain web system that can automatically display dynamic institutional podcasting content in an easy to use, subject orientated portal.

The system needs to be under access control and offer a means for a non-programmer to add new feeds to subject category areas and to a final destination page for the course/topic feed. The feeds will be provided as URLs from an institutional system (e.g. RSS server). This will serve as a core demonstrator for an institutional podcasting web portal service ideally based upon an existing open source CMS or framework that provides core modular functionality. Such a framework could provide: User Interface skins; Access control for sys admins; splash pages; search; reporting; and feedback forums)

The feature list below is ranked in order of institutional priority.

Core feature list:

• Show all available podcasts in a categorized structure
• Search for keywords to find a course (podcasts) in it’s destination area
• Optional Playback in browser (embedded flash MPEG 4 player)
• User Links to subscribe to feed and download item
• Links to external systems (e.g. departmental/project pages) from individual feeds and sub-pages
• Browse hierarchy of content, broken down into institutional subject categories and sub divisions, each with their own configurable and individual page
• Web based administration
  • Front Home page – Featured recordings/subjects/adverts
  • Sub- category page – New areas/centres/adverts
  • Destination page – departmental descriptions/links/further info
• Able to consume RSS/ATOM feeds for destination pages and Flash playlist quick viewers
• Able to be branded/customized/skin to suit institutional preferences
• Ability to advertise and market material on splash pages
• Support Album cover graphics

Extended Feature list:

• Track and display statistics on popularity (e.g. Top Downloads)
• Ability to tag individual podcasts and feeds with user generated input

Optional Feedback/Community/Pedagogical Pathways:

• Ability to provide feedback on content (e.g. comments system)
• Ability to personalize usage – e.g. create own playlist, share playlist, create and share pathways

N.B. It may be necessary to determine whether this can have a relationship with the (OPML) to generate site content/structure.

Deliverable:

• Demonstration portal – development work on an extended framework/system/CMS package with templates and new modules for generic reuse. Online pilot version.

Comments: The Open University have strengths here on the design/UI. Cambridge has much experience in the Flash/media.cam area and wish to develop this further. Oxford looks for this work to replace podcasts.ox.ac.uk.

[edit] 3.2 Cross-institutional Aggregator Demonstration (6 weeks effort, during months 4-14)

The aim of this work package is to produce a lightweight, simple showcase web demonstrator that allows multiple institutions to merge two or three subject sets (e.g. philosophy, environmental science etc) of RSS/Atom content into one web portal. There is a need to establish common categorization (e.g. extended iTunes U category codes) for aggregation and common data format (e.g. RSS/OPML). However, this may have issues with scaling, and so one must consider whether all institutions can or should offer live data for this demonstrator. Perhaps providing test static feeds as an alternative.

Comments: This work looks towards post-project demonstrator modules for non-commercial 3rd party services, including a UK-HE syndication portal, and Gel.

This is a natural continuation of package 3.1 but a lightweight version can be demonstrated early in the project and refined towards the latter stages. The scope of this needs to be kept as tight as possible and should be based around the three institutions and work completed on an agreed standard format for feeds to be aggregated. The emphasis should be on standard tags for subject areas and/or courses, course levels.

Deliverable:

• A simple web page demonstration of aggregation opportunities for multiple institutions collaborating on subject area audio and video portals. This will be linked from the main project web site.

[edit] 3.3 Third party portals, channels, modules (8 weeks effort, during months 7-9)

Cambridge will investigate automated processes for distributing institutional content to 3rd party services including iTunes U and YouTube. The aim is to reduce or remove a need for human interaction between the institutional podcasting system and the 3rd party service.

Deliverable:

• Module to support web services and RSS generation.

[edit] 3.4 LMS/VLE Internal Distribution Demonstrator (6 weeks effort, during months 9-11)

Based upon the requirements from WP1.5, Oxford and Cambridge will produce demonstration systems that integrate with local LMS/VLE solutions and meet requirements for access control and distribution methods.

Oxford and Cambridge’s solution will utilize their WebLearn system (based on Sakai) and relevant authentication and authorization systems. The solution will allow users to be able to consume podcasts via subscription and direct download.

Deliverable:

• Extending VLE modules to support web services and RSS ingest.

[edit] 4 WP4: Encoding engine

[edit] 4.1 Configure Processing Engines (6 weeks effort, during months 4-6)

The server-based encoding engine will be piloted, allowing test material to be sent by remote clients under default XML workflow scripts. Then Oxford will test that the encoded material can be transferred to simple secondary online delivery channels. The test will be conducted under simplified authorization, and will ensure that an RSS feed can be generated automatically on content creation. Oxford will research the integration of encoded material with web portal delivery, process management system and 3rd party services. Further piloting will occur outside of central services, testing the ease of ingest of materials.

The aim is to integrate a processing/encoding engine with the hosting platform and provide a multi-platform easy to use method for submitting podcasts for publishing.

Deliverable:

• Podcast site that shows publicly available test feeds.

Skills required: If we're using replay, this requires Java. If we're using PCP, this requires OSX Server skills.

[edit] 4.2 Encoding scripting and development work (8 weeks effort, during months 6-9)

This work package will produce program workflows for ingestion and creation of multiple file formats and process associated metadata. Client server capture via chosen infrastructure will be trialed. The existing workflows will be modified to meet user requirements for input and output format needs, with a special focus on a highly collaborative production environment. Oxford will undertake mapping of Authentication and Authorisation group workflows to the institutional LDAP domains. Work will be conducted on converting sample analogue content to multiple delivery encodings for distribution online within University services such a web portal, VLE and within 3rd party services.

Further, selected departments will capture podcasts via the chosen solution using the established workflows for distribution. Oxford will refine the encoding workflow scripts and development work to support archiving, multiple channels including future 3rd party services (iTunes U, YouTube model etc.).

A technical review of the pilot systems can be done to show how the small number of media production units can scale and grow to encompass lecture room capture (out of scope) and ad-hoc creation that any fuller enterprise solution will need to address.

Deliverable:

• Detailed workflow scripts and associated tools to be placed online for community overview and testing. Report on progress and pilot activity.

Comments: PeterR: This is the core of the Steeple and the bit we need to breakdown and plan the most. Basically how can we automate as much as possible and hence make the costs go down. Storage/archiving/quality control/ delivery/ private edit comments

[edit] 5 (0 weeks effort, during months 1-2)

* 2 weeks hardware search and review. Looking for hardware solutions to capture situations.

• 3 weeks on evaluating PC screen capture software .Review VNC, Screenshare, Echo 360
• 2 weeks to document findings

Make recommendations of things to use and incorporate. How does this integrate into the processing engine and beyond Look to focus on one or two scenarios – e.g. Lecture capture.

Skills required:

WP 5 removed.

[edit] 6 Process Management System for content life cycle (16 weeks effort, during months 7-11)

The aim is to refine and produce a demonstrator of a workflow tracking system, PMS. This work is to try to scope and code an online database to track progress of all project, activities, content, and RSS items in the system from birth to delivery. It builds upon a simplistic system developed by Oxford called Podchecker, and is expected to expand on it to take in early work and track non-technical parallel project activities centred around the speaker: logging events; talks; and paperwork. This work can be considered to be a practical implementation of documented processes outlined in WP.

The aim is to have a content PMS that allows us to track a podcasting entity from inception, through to delivery. Whilst providing the necessary checks and balances to handle the legal and technical processes, this would provide a clear management overview of the content and its state of readiness. A flexible workflow engine should provide a simple and scalable user interface that can handle parallel tasks and partial completions and be able to allow users and managers to monitor and control the overall task of podcasting.

• Act as gatekeeper for delivery channels. i.e. approval to iTunes U, the web channels etc
• Quality assurance interface, allow for reviews of content (quality, tech) and comments to be logged
• Show progress of podcasts from creation to publish
• Take down Process – able to switch things off
• Manage and log grey activities – events, interviews, projects

Open University will act as a sounding board, incorporating their expertise on processes and policies and also through WP1.3 Policies and Process and WP1.5 Accessibility.

Oxford has a partial web-application (Podchecker) that acts as gatekeeper for the iTunes U service, however it lacks initial progress status reporting (it first becomes aware of podcasts at the RSS creation stage).

This WP follows on from WP1-3 and WP1.5 Accessibility.

Deliverable:

• Demonstrator online tool for recording and tracking activity associated with content management.

Comments: There is also a need from all project partners for a simple statistics application or web site that generates better reports on iTunes U downloads and subscriptions per feed for departments. This relationship to the PMS should be investigated.

Skills required:

[edit] 7

Selected departments capturing podcasts via chosen solutions using established workflows for distribution via multiple channels, including 3rd party services like iTunesU. Report back on the ease of use, especially in terms of streamlining the process and relieving the burden on individuals. There will be two iterations of this

1. Public
2. Private authorisation

Deliverable: Pilot Public Service

WP 7 moved from initial plan to be part of WP 4.3

Skills required:

[edit] 8 WP8

[edit] 8.1 Evaluation of systems (6 weeks effort, during months 12-12)

The evaluation activities surround the vision of the project:

• Streamlining media (ingest, encoding, RSS, management and delivery )
• Maximising the institutional benefits ( teaching and learning, research profile, outreach, marketing )
• Refining a cost model for production costs of audio and video podcasts
• Evaluation of the core aspects to support an institutional podcasting service
• Evaluation of the pilot solution by partners against initial requirements

Skills required:

[edit] 8.2 Cost models (2 weeks effort, during months 4-12)

Defining a simple cost model for the production costs of audio and video:

• Quality vs. Cost vs. Time,
• Audio and Video production costs ,
• External facing vs. Internal facing
• Time independent ( outreach ) vs. Time dependent ( teaching and learning )
• Areas that all for efficiencies ( technology, training etc )

Deliverable:

• Document evaluating the project activities with respect to cost and benefits model

Skills required:

[edit] 9 Dissemination and Training (18 weeks effort, during months 1-16)

A one day conference to bring together members of the UK HE podcasting community with invited guest speakers. A series of 3 one day workshops need to be held for institutional webmasters and communications officers. This will be supported by the OUCS training department and run by the Project Board members. Dissemination events

• JANET IPTV Workshop October 2008
• Workshop around server based encoding and storage
• Workshop based around the process of placing an institution in Apple iTunes U project
• Beyond Walls - One day Steeple conference on April 3rd at Oxford – max 120 delegates
• Beyond Walls 2 – One day Steeple event – final quarter of project/ early Jan 2010? Cambridge?
• Potential Steeple supported legal/copyright/ session in late Jan/Feb 2009
• JISC events TBC

Deliverable:

• Conference. Training workshops, with training materials available online for HE community use.
• A regular podcast series - talks and events including training material and presentations.

[edit] 10 Final Report (11 weeks effort, during months 1-16)

Deliverable:

• Final report on the support structures needed and the strategic decisions required to make use of a key emerging technology at an enterprise-level.

Comments: The skeleton of the draft final report, which is a summary of previous work and compilation of sub-reports, will be started in November for review in December. The final report will need be finished by end of January. End of project is end of March 2010/early April.

[edit] 11 New WPs

[edit] 11.1 (0 weeks effort, during months 18-18)

Skills required:

[edit] 11.2 (3 weeks effort, during months 1-3)

Skills required:

[edit] 11.3 Blank (0 weeks effort, during months 18-18)

Skills required:

[edit] 11.4 Blank (0 weeks effort, during months 18-18)

Skills required:

[edit] 11.5 Blank (0 weeks effort, during months 18-18)

Skills required: