Opencast Adopters Wiki
This documentation is outdated. Please find the current documentation at https://docs.opencast.org 1. CLA and CCLA Master List ...... 7 2. Navigation ...... 8 3. TreeNavigation ...... 8 4. .bookmarks ...... 9 5. Opencast Matterhorn Project Home ...... 9 5.1 Getting Started Guides ...... 10 5.1.1 Get to know Matterhorn ...... 10 5.1.2 Matterhorn and my organization ...... 11 5.1.3 Take a Look Under the Hood ...... 12 5.1.4 Developer Getting Started Guide ...... 12 5.1.5 Contribute to Matterhorn ...... 18 5.2 Product Documentation ...... 19 5.2.1 Release 0.5 Documentation ...... 19 5.2.1.1 Release 0.5 Cookbook ...... 20 5.2.1.1.1 Anatomy of a Service (Release 0.5) ...... 22 5.2.1.1.2 Capture Media from the Command-line (Release 0.5) ...... 27 5.2.1.1.3 Create a New Service (Release 0.5) ...... 27 5.2.1.1.4 Get Capture Agent Schedules (Release 0.5) ...... 32 5.2.1.1.5 Including common static resources in your UI (Release 0.5) ...... 33 5.2.1.1.6 Integration Testing (Release 0.5) ...... 35 5.2.1.1.7 Java Unit testing (Release 0.5) ...... 37 5.2.1.1.8 JavaScript Unit testing (Release 0.5) ...... 38 5.2.1.1.9 MediaPackage Cookbook (Release 0.5) ...... 42 5.2.1.1.10 Obtaining the server's base URL (Release 0.5) ...... 44 5.2.1.1.11 Registering User Interfaces (Release 0.5) ...... 45 5.2.1.1.12 Simulate Capture Agent Hardware (Release 0.5) ...... 46 5.2.1.1.13 Workflow Cookbook (Release 0.5) ...... 47 5.2.1.2 Release 0.5 FAQ ...... 57 5.2.1.3 Release 0.5 Install and Configure ...... 59 5.2.1.3.1 Configure Matterhorn Port Number and Base URL (Release 0.5) ...... 60 5.2.1.3.2 Capture Service Configuration (Release 0.5) ...... 61 5.2.1.3.3 Create a Virtual Machine (Release 0.5) ...... 63 5.2.1.3.4 Configure Matterhorn Feed Catalog (Release 0.5) ...... 63 5.2.1.3.5 Register a Capture Agent (Release 0.5) ...... 67 5.2.1.3.6 Overview of Configuration Files (Release 0.5) ...... 68 5.2.1.3.7 Install Source (Release 0.5) ...... 69 5.2.1.3.8 Install Virtual Machine (Release 0.5) ...... 73 5.2.1.3.9 Windows 3rd Party Tools Installation (Release 0.5) ...... 74 5.2.2 Road Map ...... 75 5.2.2.1 Grant Deliverables ...... 77 5.2.2.2 Q1 User Stories ...... 84 5.2.2.3 Q2 User Stories ...... 84 5.2.2.4 Q3 User Stories ...... 85 5.2.2.5 Q4 Scenarios and Deliverables ...... 85 5.2.3 License Information ...... 85 5.2.4 Features and Functionality ...... 89 5.2.4.1 Lecture Capture and Administration ...... 89 5.2.4.2 Ingest and Processing ...... 91 5.2.4.3 Distribution Management ...... 92 5.2.4.4 Engage Tools ...... 92 5.2.4.4.1 Accessibility Features ...... 92 5.3 Get Matterhorn ...... 93 5.4 Development Documentation ...... 93 5.4.1 Developing Source ...... 97 5.4.2 Standards ...... 99 5.4.2.1 Accessibility ...... 99 5.4.2.2 Caption Support ...... 101 5.4.2.3 Media Codecs and File Types ...... 102 5.4.2.4 Metadata Standards ...... 102 5.4.2.4.1 Metadata mapping in the UIs ...... 104 5.4.3 Install and Configure ...... 105 5.4.3.1 Create a Virtual Machine ...... 106 5.4.3.2 Install Virtual Machine ...... 106 5.4.3.3 Install Source ...... 107 5.4.3.3.1 Windows 3rd Party Tools Installation ...... 111 5.4.3.4 Capture Agent Configuration ...... 112 5.4.3.5 Capture Service Configuration ...... 113 5.4.3.6 Configure Matterhorn Feed Catalog ...... 115 5.4.3.7 Configure Matterhorn Port Number and Base URL ...... 118 5.4.3.8 Create a custom workflow ...... 119 5.4.3.9 Engage media player installation ...... 132 5.4.3.10 Install Matterhorn Capture Agent ...... 133 5.4.3.11 Overview of Configuration Files ...... 133 5.4.3.12 Register a Capture Agent ...... 136 5.4.4 Technology Stack ...... 137 5.4.4.1 Architecture ...... 138 5.4.4.1.1 Ingest Overview ...... 139 5.4.4.1.2 Distribution ...... 139 5.4.4.1.3 PortalDistribution ...... 140 5.4.4.1.4 Capture Agent Job Sequence ...... 141 5.4.5 Tools ...... 141 5.4.5.1 Confluence ...... 142 5.4.5.1.1 Gliffy ...... 143 5.4.5.2 Crucible ...... 143 5.4.5.3 Eclipse Guide ...... 144 5.4.5.4 Jira ...... 146 5.4.5.4.1 Create Jira Stories, Tasks and Sub Tasks ...... 146 5.4.5.4.2 Estimate and Log Jira Issues ...... 146 5.4.5.4.3 Jira Issue Types ...... 146 5.4.5.4.4 Jira Overview ...... 147 5.4.5.4.5 Navigate Jira Issues ...... 147 5.4.5.5 Matterhorn Subversion Repository ...... 148 5.4.5.6 Maven Nexus Server ...... 149 5.4.6 Work Practices ...... 149 5.4.6.1 Committers Practices ...... 149 5.4.6.2 Common Processes ...... 150 5.4.6.2.1 Agile Software Development ...... 150 5.4.6.2.2 Licenses ...... 151 5.4.6.2.3 Processes Communication ...... 154 5.4.6.3 Frontend best practices ...... 155 5.4.6.3.1 Javascript coding style ...... 156 5.4.6.4 Java best practices ...... 157 5.4.6.5 Management Processes ...... 158 5.4.6.5.1 Conducting "Scrum of Scrums" ...... 158 5.4.6.6 REST practices ...... 158 5.4.6.7 Submitting a Patch to Matterhorn ...... 158 5.4.7 Cookbook ...... 158 5.4.7.1 Adding Demo Data To Your Instance ...... 160 5.4.7.2 Atom and RSS Feeds ...... 161 5.4.7.3 Capture Media from the Command-line ...... 162 5.4.7.4 Create an Encoding Profile ...... 162 5.4.7.5 Get Capture Agent Schedules ...... 164 5.4.7.6 Including common static resources in your UI ...... 165 5.4.7.7 Integration Testing ...... 166 5.4.7.8 iTunes Distribution Service ...... 168 5.4.7.9 Java Unit testing ...... 168 5.4.7.10 JavaScript Unit testing ...... 169 5.4.7.11 MediaPackage Cookbook ...... 173 5.4.7.12 Obtaining the server's base URL ...... 175 5.4.7.13 Registering User Interfaces ...... 176 5.4.7.14 Service Design ...... 177 5.4.7.14.1 Create a New Service ...... 177 5.4.7.14.2 Anatomy of a Service ...... 182 5.4.7.14.3 Document a Service ...... 188 5.4.7.15 Simulate Capture Agent Hardware ...... 190 5.4.7.16 Workflow Cookbook ...... 191 5.4.7.17 Youtube Distribution Service ...... 200 5.4.8 Service Contracts ...... 204 5.4.8.1 AdminService ...... 207 5.4.8.2 ArchiveService ...... 208 5.4.8.3 AuthoritativeAnnotationService ...... 209 5.4.8.4 Capture Admin Service ...... 210 5.4.8.5 CaptureAgentService ...... 210 5.4.8.6 ConductorService ...... 211 5.4.8.7 DownloadDeliveryService ...... 211 5.4.8.8 FeedbackService ...... 212 5.4.8.9 FeedDistributionService ...... 213 5.4.8.10 IngestService ...... 214 5.4.8.11 iTunesUDistributionService ...... 216 5.4.8.12 MatterhornPortalDistributionService ...... 217 5.4.8.13 MediaAnalysisService ...... 218 5.4.8.14 MediaComposerService ...... 219 5.4.8.15 MediaInspectionService ...... 220 5.4.8.16 NotificationService ...... 221 5.4.8.17 SakaiDistributionService ...... 222 5.4.8.18 Scheduler Service ...... 223 5.4.8.19 SearchService ...... 228 5.4.8.20 SiteIntegrationService ...... 229 5.4.8.21 StreamingDeliveryService ...... 230 5.4.8.22 TranslationService ...... 231 5.4.8.23 WorkflowService ...... 232 5.4.8.24 WorkingFileRepository ...... 236 5.4.8.25 WorkspaceService ...... 237 5.4.8.26 YouTubeDistributionService ...... 238 5.4.9 Entities ...... 239 5.4.9.1 MediaPackage Attachment ...... 239 5.4.9.2 MediaPackage Catalog ...... 241 5.4.9.3 MediaPackage Manifest ...... 242 5.4.9.4 MediaPackage Overview ...... 244 5.4.9.5 MediaPackage Track ...... 246 5.4.10 User Experience ...... 250 5.4.10.1 BA-UX Common ...... 250 5.4.10.1.1 Welcome Page Brainstorming ...... 250 5.4.10.1.2 Design Principles ...... 251 5.4.10.1.3 Customer Research ...... 252 5.4.10.1.4 User Research ...... 264 5.4.10.1.5 Workflows ...... 266 5.4.10.2 BA-UX Engage ...... 269 5.4.10.2.1 User Experience Studies ...... 269 5.4.10.2.2 Past relevant work ...... 280 5.4.10.2.3 Mockups ...... 300 5.4.10.3 BA-UX Admin App ...... 302 5.4.10.3.1 Admin App Use Cases ...... 303 5.4.10.3.2 Admin UIs ...... 303 5.4.10.3.3 Comparative Analysis of Administrative Applications ...... 308 5.4.10.3.4 Pain Points ...... 328 5.4.10.3.5 Past Relevant Work - Admin ...... 328 5.4.10.3.6 Mary Johansson - Podcast Administrator ...... 330 5.4.10.3.7 User Testing - Admin App ...... 331 5.4.11 Release Management ...... 343 5.4.11.1 Managing Releases ...... 345 5.4.11.2 Release 0.4 ...... 347 5.4.11.2.1 Release 0.4 Documentation ...... 348 5.4.11.3 Release 0.5 Management ...... 349 5.4.11.4 Service checklist ...... 351 5.4.11.5 Verifying Matterhorn Releases ...... 351 5.4.12 Quality Assurance ...... 352 5.4.12.1 Acceptance Testing ...... 353 5.4.12.2 Code Documentation ...... 353 5.4.12.3 Developer checklist ...... 354 5.4.12.3.1 Caption Handling 0.5 Checklist ...... 355 5.4.12.3.2 Capture 0.5 Checklist ...... 356 5.4.12.3.3 Capture Admin 0.5 Checklist ...... 356 5.4.12.3.4 Composer 0.5 Checklist ...... 356 5.4.12.3.5 Distribution (local) 0.5 Checklist ...... 356 5.4.12.3.6 Engage 0.5 Checklist ...... 357 5.4.12.3.7 Ingest 0.5 Checklist ...... 358 5.4.12.3.8 Inspection 0.5 Checklist ...... 358 5.4.12.3.9 Scheduling 0.5 Checklist ...... 358 5.4.12.3.10 Search 0.5 Checklist ...... 359 5.4.12.3.11 Workflow 0.5 Checklist ...... 359 5.4.12.3.12 Working File Repository 0.5 Checklist ...... 360 5.4.12.3.13 Workspace API 0.5 Checklist ...... 360 5.4.12.4 Matterhorn Supported Screenreaders ...... 360 5.4.12.5 QA Process Overview ...... 360 5.4.12.6 Selenium Core Test ...... 361 5.4.12.7 Tools and HOWTOs to improve the quality for non-java development ...... 362 5.4.12.8 X Browser Test Environments ...... 363 5.4.12.8.1 _Components Schedule Drafts_ ...... 363 5.4.13 Working Documents ...... 363 5.4.13.1 BA-UX - Distribute ...... 365 5.4.13.2 Service Modeling ...... 365 5.4.13.3 Service Definitions - Distribute ...... 365 5.4.13.4 Service Definitions - Cross-Component ...... 365 5.4.13.5 Service Definitions - Capture ...... 365 5.4.13.6 Revised ArchiveService ...... 365 5.4.13.6.1 ArchiveService_Release_Notes ...... 366 5.4.13.7 Reviewing Code ...... 366 5.4.13.8 Requirements - Schedule ...... 366 5.4.13.9 Requirements - Process-Encode ...... 366 5.4.13.10 Requirements - Distribute ...... 367 5.4.13.11 Requirements - Capture ...... 367 5.4.13.12 OBSOLETE - Engage ...... 367 5.4.13.12.1 Archive Docs - Engage ...... 367 5.4.13.13 Components Schedule UIs ...... 367 5.4.13.14 Components Schedule Other ...... 367 5.4.13.15 Testing balsamiq ...... 367 5.4.13.16 Relationships between admin UIs ...... 367 5.4.13.17 Deployment Case Studies ...... 367 5.4.13.17.1 Simple Classroom Setup - USask ...... 367 5.4.13.18 Candidate metadata available for capture ...... 367 5.4.13.19 Capture Agent and System Test Instructions ...... 369 5.4.13.20 Streaming and Web Server solutions from the Community ...... 369 5.4.13.21 Keyboard shortcuts for a basic media player ...... 370 5.4.13.22 BA-UX - Process-Encode ...... 370 5.4.13.23 Welcome Page - Installation ...... 370 5.4.13.24 DEPRECATED Service Contract Description Template ...... 370 5.4.13.25 Service Definitions - Engage ...... 371 5.4.13.26 Capture Media and Encoding Results ...... 373 5.4.13.27 Matterhorn Capture Hardware Specification ...... 374 5.4.13.28 Sample Media Output ...... 374 5.4.13.29 Composer Features ...... 374 5.4.13.30 Advanced Workflow Options - Chris ...... 374 5.4.13.31 Calendar -- Capture architecture proposal ...... 374 5.4.13.32 HTML CSS js framework ...... 375 5.4.13.33 Scheduling Scenarios ...... 375 5.4.13.34 Adding a new service ...... 376 5.4.13.35 Matterhorn Engage - Player architecture ...... 376 5.4.13.36 Ingest Flow ...... 376 5.4.13.37 Potential workflows for Admin App ...... 377 5.4.13.37.1 Admin UI Component Diagram 1 - Ingest Only ...... 377 5.4.13.37.2 Admin UI Component Diagram 2 - Ingest and manual scheduling with Bedework ...... 377 5.4.13.37.3 Admin UI Component Diagram 3 - Import from my Scheduling System, Ingest, and use Bedework for manual scheduling ...... 377 5.4.13.37.4 Admin UI Component Diagram 4 - Import from my Scheduling System and Ingest only (no Bedework, no manual scheduling) ...... 377 5.4.13.38 Flex frameworks ...... 377 5.4.13.39 Media Portal ...... 377 5.4.13.40 Components Schedule Services ...... 377 5.4.13.41 Components Process and Encode UIs ...... 377 5.4.13.42 Components Process and Encode Other ...... 377 5.4.13.43 Components Process and Encode Drafts ...... 377 5.4.13.44 Components Engage Drafts ...... 377 5.4.13.45 Components Distribute Drafts ...... 377 5.4.13.46 Components Common UIs ...... 377 5.4.13.47 Components Common Services ...... 377 5.4.13.48 Components Common Other ...... 378 5.4.13.49 Components Common Drafts ...... 378 5.4.13.50 Components Capture Drafts ...... 378 5.4.13.50.1 CaptureAgentService_Draft ...... 378 5.4.13.51 Live media capture architecture ...... 379 5.4.13.52 Service Definitions - Process-Encode ...... 379 5.4.13.53 Release 0.5 ~ Deliverables (Aug. 09 - Jan. 10) ...... 380 5.4.13.54 Release 0.5 ~ Iterations (Aug. 09 - Jan. 10) ...... 380 5.4.13.55 Release 0.5 ~ Scenarios (Aug. 09 - Jan. 10) ...... 380 5.4.13.56 Step 1 - config.sh ...... 380 5.4.13.57 Step 2 - external_tools.sh ...... 383 5.4.13.58 Step 3 - capture_agent.sh ...... 385 5.4.13.59 Service Definitions - Schedule ...... 387 5.4.13.60 Archive Docs - Capture ...... 387 5.4.13.61 Archive Docs - Cross-Component ...... 387 5.4.13.62 Archive Docs - Distribute ...... 387 5.4.13.63 Requirements - Cross-Component ...... 387 5.4.13.64 Archive Docs - Process-Encode ...... 387 5.4.13.65 Archive Docs - Schedule ...... 387 5.4.13.66 BA-UX - Capture ...... 387 5.4.13.67 Ingestor Interface ...... 387 5.4.13.68 Components Process and Encode Services ...... 388 5.4.13.69 BA-UX - Schedule ...... 388 5.4.13.70 Meeting Goals & Activities ...... 388 5.4.13.71 Design Studio ...... 388 5.4.14 BA-UX - Cross-Component ...... 389 5.5 About the Project ...... 389 5.5.1 Partners ...... 390 5.5.2 People ...... 390 5.5.2.1 Committers ...... 392 5.5.3 Advisories ...... 392 5.6 Project Coordination ...... 393 5.6.1 Calendar ...... 393 5.6.2 Meetings ...... 393 5.6.2.1 Admin Team Meeting Notes ...... 395 5.6.2.2 BA-UX-UI Meeting Notes ...... 401 5.6.2.3 Capture Team Meeting Notes ...... 401 5.6.2.4 Distribution Team Meetings ...... 402 5.6.2.5 Engage Team Meeting Notes ...... 402 5.6.2.6 Product Owner Meeting Notes ...... 402 5.6.2.7 Services and Architecture Team Meeting Notes ...... 403 5.6.2.7.1 2010-02-15 ...... 403 5.6.2.8 Developer Meeting Notes ...... 404 5.6.2.9 Weekly Matterhorn Meeting (SoS) Notes ...... 404 5.6.2.10 Archive of Past Meetings ...... 405 5.6.2.10.1 Deep Dive Agenda ...... 405 5.6.2.10.2 Zurich meeting September 21-25 ...... 406 5.6.2.11 Communications & Adoption Strategy Working Group Notes ...... 411 5.6.2.12 Year 2 Planning Meeting Notes ...... 418 5.6.3 Communication ...... 420 5.6.3.1 Community Newsletter ...... 422 5.6.3.1.1 Opencast Matterhorn Newsletter - October 2009 ...... 422 5.6.3.1.2 Opencast Matterhorn Newsletter - August 2009 ...... 422 5.6.3.1.3 Opencast Matterhorn Newsletter - December 2009 (draft) ...... 422 5.6.3.2 Site restructuring process - working document ...... 425 5.6.3.2.1 Revision Proposal for www.opencastproject.org ...... 427 5.6.3.3 Matterhorn Introductory Tour Video ...... 428 5.6.4 Governance ...... 428 5.6.4.1 Roles and responsibilities ...... 429 5.6.4.2 Decision Making ...... 431 5.6.5 Process ...... 431 5.6.5.1 Accessibility QA process ...... 432 5.6.5.2 Agile and UX - Observations, Suggestions, and Questions ...... 432 5.6.5.3 Contributor Guide ...... 433 5.6.5.3.1 High Level Iteration Process ...... 433 5.6.5.3.2 Roles and Expectations ...... 433 5.6.5.3.3 Project Tool Tips ...... 436 5.6.5.3.4 Making Decisions ...... 437 5.6.5.3.5 Communication Practices ...... 437 5.6.5.3.6 Development Practices ...... 437 5.6.5.4 Signing an Opencast CLA and CCLA ...... 439 5.6.6 Glossary ...... 439 5.6.6.1 Definition of engage activities and functionalities ...... 441 5.6.6.1.1 Adding Demo Data To Your Instance (Release 0.5) ...... 441 5.6.7 Matterhorn Basecamps ...... 442 5.6.8 Strategy ...... 443 5.6.8.1 6 Month Priorities and Resource Allocation ...... 443 5.6.8.1.1 Iteration Planning ...... 443 5.6.8.2 Adoption Strategy ...... 443 5.6.8.2.1 Base Camp Candidates ...... 446 5.6.8.2.2 Release 0.5 Board Meeting Update ...... 447 5.6.8.3 Considered Year 2 Requirements ...... 448 5.6.8.4 Considered Year 2 Requirements (decision table) ...... 450 5.6.8.5 Year 2 Requirements - top level decision making ...... 453 5.7 Archive ...... 454 5.7.1 DEPRECATED Existing Technologies and Projects ...... 455 5.7.2 DEPRECATED Service Guides ...... 458 5.7.2.1 DEPRECATED Create a Matterhorn Service ...... 458 5.7.2.2 DEPRECATED Creating an OSGI service with REST and SOAP Endpoints ...... 459 5.7.2.3 DEPRECATED Creating UI-facing, RESTful service in Matterhorn ...... 463 5.7.2.4 DEPRECATED From installing Matterhorn to a live Service ...... 466 5.7.2.5 DEPRECATED Service Design Best Practices ...... 468 5.7.3 Matterhorn Calendar Mockup ...... 469 5.7.4 DEPRECATED - Release 0.5 ~ Scenarios (Aug. 09 - Jan. 10) ...... 469 5.7.4.1 Administrator cancels one recording in recurring event ...... 472 5.7.4.2 Administrator changes date-time for one recording in recurring event ...... 472 5.7.4.3 Administrator follows the progress of today's events from capture to distribution ...... 472 5.7.4.4 Administrator schedules individual event for capture and distribution ...... 472 5.7.4.5 Administrator schedules recurring recording for automated capture ...... 473 5.7.4.6 Administrator uploads a video-audio file to be processed ...... 473 5.7.4.7 Administrator uploads caption file for automatically and manually captured recordings to be distributed with media ...... 474 5.7.4.8 Learner finds video in Matterhorn list of videos and watches it ...... 474 5.7.4.9 Learner searches for specific video by keyword and watches the video ...... 474 5.7.4.10 Learner subscribes to feed ...... 474 5.7.4.11 Status for All Iterations ...... 474 5.7.5 DEPRECATED - Release 0.5 ~ Iterations (Aug. 09 - Jan. 10) ...... 475 5.7.5.1 Today's Work ...... 475 5.7.5.2 Iteration 2 (Aug. 09) ~ Admin Tools ...... 475 5.7.5.3 Iteration 2 (Aug. 09) ~ Architecture and Process Services ...... 475 5.7.5.4 Iteration 2 (Aug. 09) ~ Capture Tools ...... 476 5.7.5.5 Iteration 2 (Aug. 09) ~ Distribution Services ...... 476 5.7.5.6 Iteration 2 (Aug. 09) ~ Engage Tools ...... 477 5.7.5.7 Iteration 3 (Sept. 09) ~ Admin Tools ...... 477 5.7.5.8 Iteration 3 (Sept. 09) ~ Architecture and Process Services ...... 478 5.7.5.9 Iteration 3 (Sept. 09) ~ Capture Tools ...... 478 5.7.5.10 Iteration 3 (Sept. 09) ~ Distribution Services ...... 478 5.7.5.11 Iteration 3 (Sept. 09) ~ Engage Tools ...... 479 5.7.6 DEPRECATED Working Documents ...... 479 5.7.6.1 DEPRECATED ArchiveService ...... 480 5.7.6.2 DEPRECATED AuthoritativeAnnotationService ...... 480 5.7.6.3 DEPRECATED CaptionConversionService ...... 480 5.7.6.4 DEPRECATED CaptureAgentService ...... 480 5.7.6.5 DEPRECATED DistributionService ...... 480 5.7.6.5.1 Distribution Candidates ...... 481 5.7.6.6 DEPRECATED Documentation ...... 481 5.7.6.7 DEPRECATED Media Capture and Ingest ...... 483 5.7.6.8 DEPRECATED Media Distribution ...... 484 5.7.6.9 DEPRECATED Media Processing ...... 484 5.7.6.9.1 DRAFT Workspace API Requirements ...... 486 5.7.6.10 DEPRECATED MediaAnalysisService ...... 486 5.7.6.11 DEPRECATED MediaComposerService ...... 487 5.7.6.12 DEPRECATED MediaIngestService ...... 487 5.7.6.13 DEPRECATED MediaInspectionService ...... 487 5.7.6.14 DEPRECATED NotificationService ...... 488 5.7.6.15 DEPRECATED Service Candidates ...... 488 5.7.6.15.1 DEPRECATED Distribution Service ...... 490 5.7.6.15.2 DEPRECATED Editing Service ...... 490 5.7.6.15.3 DEPRECATED Encoder Service ...... 491 5.7.6.15.4 DEPRECATED Media Package Entity ...... 492 5.7.6.16 DEPRECATED SiteConductorService ...... 492 5.7.6.17 DEPRECATED SiteIntegrationService ...... 492 5.7.6.18 DEPRECATED WorkflowService ...... 492 5.7.6.19 DEPRECATED WorkingFileRepository ...... 492 5.7.6.20 DEPRECATED WorkspaceService ...... 493 5.7.7 DEPRECATED - Release 0.5 ~ Deliverables (Aug. 09 - Jan. 10) ...... 493 5.7.7.1 Admin Tools Release 0.5 (Aug. 09 - Jan. 10) ...... 493 5.7.7.2 Engage Tools Release 0.5 (Aug. 09 - Jan. 10) ...... 494 5.7.7.3 Capture Release 0.5 (Aug. 09 - Jan. 10) ...... 494 5.7.7.4 Distribution Services Release 0.5 (Aug. 09 - Jan. 10) ...... 495 5.7.7.5 Achitecture and Process Services Release 0.5 (Aug. 09 - Jan. 10) ...... 495 5.7.8 Usage Requirements ...... 496 5.7.8.1 Potential User Interfaces ...... 496 5.7.8.2 Proposed Matterhorn Requirements ...... 497 5.7.8.3 Requirements from Face-to-Face Meetings ...... 498 5.7.9 DEPRECATED StatusMessage Structure ...... 501 5.7.10 DEPRECATED Distribution Team Diagrams ...... 502 5.7.11 DEPRECATED IngestService ...... 502 CLA and CCLA Master List
Following is a list of signed CLAs and CCLAs that have been returned. The signed copies are kept in a master file in Dwinelle 9 (UC Berkeley).
Institution Individual CLA CCLA
UC Berkeley Adam Hochman NA
UC Berkeley Josh Holtzman NA
UC Berkeley Judy Stern NA
UC Berkeley Allison Bloodworth NA
UC Berkeley Michelle Ziegmann NA
ETH Zurich Tobias Wunden
ETH Zurich Olaf Schulte
ETH Zurich Christoph Driessen
University of Osnabrueck Markus Ketterl
University of Osnabrueck Clemens Gruber
University of Osnabrueck Rugider Rolf
University of Osnabrueck Johannes Emden
University of Osnabrueck Bejamin Wulff
University of Osnabrueck Nils Birnbaum
University of Osnabrueck Stefan Altevogt
University of Osnabrueck Marcus Lunzenauer
University of Copenhagen Jamie Hodge
University of Copenhagen Lars Palmqvist
University of Copenhagen Thomas Schlitling
University of Copenhagen Uwe Wollin
Indiana University Martin Wagner
Indiana University Manjit Trehan
Indiana University Namrata Lele
Cambridge University Aaron Zeckoski
Cambridge University Tony Stevenson
University of Saskatchewan Christopher Brooks
University of Saskatchewan Kristofor Amundson
University of Saskatchewan Greg Logan
University of Nebraska-Lincoln Micah Sutton
University of Vigo Vicente Goyanes
University of Vigo Ruben Rua
University of Vigo Ruben Perez Vazquez
Open University of Catalonia Josep Manual Rivera Lopez
Open University of Catalonia Alicia Valls Saez
Open University of Catalonia Juan Antonio Recia Valls
University of Toronto Heidi Hazelton
University of Toronto Antonio Gamba Bari
University of Toronto Laurie McArthur
Jozef Stefan Institute Bostjan Pajntar
Jozef Stefan Institute Peter Kese
Jozef Stefan Institute Škofi Nejc
Jozef Stefan Institute Mitja Jermol
Northwestern University Jonathan Smith
Northwestern University Xin Xiang
Navigation
Who We Are
Partner Organizations
People
Advisories
Project Coordination
Meetings
Communication
Governance
Planning
Product Definition
Roadmap
Requirements
Workflows
Services
Story Cards
Components
Schedule
Capture
Process & Encode
Distribute
Engage TreeNavigation Unknown macro: {html}
.bookmarks
Recent bookmarks in Matterhorn This page is a container for all the bookmarks in this space. Do not delete or move it or you will lose all your bookmarks. Bookmarks in Matterhorn | Links for Matterhorn
Unknown macro: {bookmarks} Opencast Matterhorn Project Home
New Locations for Matterhorn Services Please note Our wiki has just moved to it's new home, and we're still settling The following Matterhorn services have been relocated. in. Please be patient as we resolve any missing images, Please update your links (as we are working on ours!): broken links and error messages. Issues/JIRA - https://opencast.jira.com Wiki/Confluence - https://opencast.jira.com/wiki Getting Started Guides SVN - Repository - Check this out - https://openca st.jira.com/svn/OPENCAST/ Welcome to the Opencast Matterhorn project! SVN - Browsable (Crucible) - https://opencast.jira.c om/source/browse/OPENCAST Below find links to several Getting Started Guides for different purposes.
Get to know Matterhorn Daily Standup Recommended first steps to getting acquainted with the Opencast Matterhorn project Unknown macro: {rss}
See if Matterhorn fits my organization's strategy and needs For those who are considering adopting Matterhorn for their institution
Take a look under the hood For a more technically-detailed tour of Matterhorn and insight into the development process
Take a look at the latest release or trunk Take Matterhorn for a test drive with step-by-step instructions to get you up and running.
Contribute to Matterhorn Join us! Learn how you or your organization can get involved Recently Updated
Capture Agent Communication Protocols May 25, 2019 • updated by Stephen Marquard • view change MH Jan 22, 2019 • attached by Olaf A. Schulte Opencast Development Wiki Sep 08, 2017 • updated by Olaf A. Schulte • view change Developer Documentation Jul 06, 2017 • updated by Stephen Marquard • view change Work Practices Aug 11, 2016 • updated by Olaf A. Schulte • view change Opencast Community - Institutions Aug 04, 2016 • updated by Olaf A. Schulte • view change Google Summer of Code Ideas Page Jul 07, 2016 • updated by Corné Oosthuizen • view change Adopters Meeting Minutes - 2016-6-29 Jun 30, 2016 • updated by Kevin CHAN • view change Adopters Meeting Minutes - 2016-5-25 May 26, 2016 • created by Kevin CHAN Adopters Meeting Minutes - 2016-4-27 Apr 27, 2016 • created by Kevin CHAN Configure LDAP Authentication and Authorization Mar 31, 2016 • updated by Rubén Pérez • view change Adopters Meeting Minutes - 2016-3-30 Mar 30, 2016 • updated by Kevin CHAN • view change Configure LDAP Authentication and Authorization Mar 02, 2016 • commented by James Perrin Adopters Meeting Minutes - 2016-2-24 Feb 24, 2016 • created by Kevin CHAN Adopters Meeting Minutes - 2016-1-27 Jan 27, 2016 • created by Kevin CHAN Getting Started Guides
Welcome to the Opencast Matterhorn project!
Below find links to several Getting Started Guides for different purposes.
Get to know Matterhorn Recommended first steps to getting acquainted with the Opencast Matterhorn project
See if Matterhorn fits my organization's strategy and needs For those who are considering adopting Matterhorn for their institution
Take a look under the hood For a more technically-detailed tour of Matterhorn and insight into the development process
Take a look at the latest release or trunk Take Matterhorn for a test drive with step-by-step instructions to get you up and running.
Contribute to Matterhorn Join us! Learn how you or your organization can get involved Get to know Matterhorn
Opencast Matterhorn is a project, backed by an international community of higher education organization, that aims to build an open source, end-to-end platform that supports the scheduling, capture, managing, encoding and delivery of educational audio and video content.
If you are interested in finding out more about Matterhorn, the following documents should provide you with a broad overview of the project.
About Opencast Matterhorn The one-pager overview of the project goals, features and origins
Road Map Breakdown of deliverables and scenarios by quarter
Features & Functionality Overview of the product, with detailed information about each component including architecture, services, and scenarios
Standards Introduction to the technical standards incorporated into the project
Community Newsletter Bi-monthly updates to the community regarding progress and activities within the Opencast Matterhorn project
Partners & People Find out what organizations and individuals are behind Opencast Matterhorn
Opencast Matterhorn Videos View presentations and other videos created about the Opencast Matterhorn project Matterhorn Communication Follow Matterhorn by joining one of the mailing lists or participating in one of the weekly meetings. Matterhorn and my organization
Now that you are familiar with Matterhorn, you are probably wondering how your institution could benefit from implementing it. Opencast Matterhorn is a collaborative effort, developed by a consortium of academic institutions with guidance from a larger community of academic institutions - but does it actually meet your needs and expectations?
We invested quite some time in requirement gathering and customer research to ensure Matterhorn meets the needs of the archetypical instiution we like to call "the Cobbler." An entry into lecture recording Podcasting already, but need to increase efficiency and productivity Looking for an alternative to commercial lecture recording system Hoping to augment your existing system Considering Matterhorn as a strategic alternative to flying solo Sharing what you've got Unique requirements that don't come with Matterhorn out of the box Wanting to test Matterhorn, but in need of technical assistance
An entry into lecture recording
Matterhorn is designed to accomplish basic but essential functionality related to the production, the management and the distribution of thelecture recording. We are developing
reference capture agents to be installed in the classroom, recording VGA, audio and video, a scheduling service to set up the devices for re-occurring or individual recordings, an ingest service to manually upload audio or video files, a processing service to analyze media and to manage the overall system, distribution services with standardized distribution channels, and an engage UI to provide additional features while consuming the video.
[More about these features]
As a whole, this list covers a typical "podcast service" and will allow you to easily make a first move towards lecture recording.
Podcasting already, but need to increase efficiency and productivity
The majority of institutions we talked to have a productive podcasting programs already - but are less efficient than they would like it to be, and are poorly situated to respond to the growing demand for lecture recordings and handling of media objects for the future. This scenario describes " the cobbler", the primary customer for who Matterhorn 1.0 is focused.
Instead of working with a variety of tools and programs to produce and distribute content, Matterhorn will offer all relevant functionalities as a integrated whole. This reduces the amount of manual work needed to sheperd media objects across various sub-systems, and increases productivity and reliability. Matterhorn workflow service matures will allow you to integrate those parts of your non-integrated process. This is the benefit of "maximizing reuse" of Matterhorn services.
Looking for an alternative to commercial lecture recording system
Various vendors offer universities and their students the opportunity to "rewind, relive and reconnect with the classroom experience" (Echo 360) and to "generate affordable knowledge catalogs you can search and secure" (MediaSite) and some certainly do this well. However, beyond fundamental issues around Open vs. Closed Source solutions, these systems are also limiting at least in two major areas of concern.
1. The ability to customize to your needs While we initially described lecture recording as a rather simple produce-manage-distribute process, we know from our own experience and the customer research that the devil is in the details: Any institution has particular needs and requirements - be it a Solaris infrastructure to run your system on or the wish to integrate existing capture hardware. Unlike most commercial systems, Matterhorn allows you to customize to meet these needs, be that by running selected services only or by adding functionalities you need. 2. Commercial systems come with a licensing model Whether based on the number of capture devices used or the number of (concurrent) users, commercial systems come with licensing fees. This implies that you cannot scale without additional fees - the more successful your service becomes, the more you have to invest. With an Open Source system like Matterhorn, you can actually benefit from economies of scale instead. Developed with automation in mind, the cost of running Matterhorn will actually decrease per course being recorded.
Hoping to augment your existing system
Service-oriented architecture is the guiding principle in Matterhorn and offers the flexibility to implement only the functionalities you need. This is a huge advantage for those looking for an addition to or an extension of your existing system instead of replacing an entire system. Whether it's the ingest service or the media analysis to OCR slides, most Matterhorn services come with a REST-style interface, so that they can be easily accessed from any sort of system, platforms and computer languages. This gives you the flexibility you need to enrich your existing system with Matterhorn services. Considering Matterhorn as a strategic alternative to flying solo
Having established a system to meet your needs means that you invested time, money, and resources - and ideally you are happy with that system. This is the case with many of the Matterhorn partners as well. However, we are all acutely aware of how rapidly things are changing in video production and distribution. In a market driven by major companies, it is challenging to keep up with technological developments as well as users' expectations - and almost impossible to do it all on your own.
Matterhorn is being developed out of a community of academic institutions sharing the pressure to keep up to date with recent developments.
Sharing what you've got
The Matterhorn project stems from the Opencast Community and is therefore all about sharing: Knowledge, experience, expertise, technology, content - (almost) everything. Being part of Opencast Matterhorn affords opportunities to share what you've accomplished in an effort to enrich Matterhorn. In an open source community, there is most certainly a return on investment for sharing beyond acknowledgment: the more interest you generate in your technology, the more likely it is for other individuals and organizations to join you in your effort to further develop it.
So if you have expertise in speech-to-text, camera tracking or authentication and authorization technology, why not integrate it into Matterhorn? Its architecture, technology and design, as well as the community behind Matterhorn, provide you with the ideal environment for furthering your ideas.
Unique requirements that don't come with Matterhorn out of the box
Matterhorn will offer the ideal matrix to further develop what is there already. Whether you would like to have a say in the future shape and functionalities of Matterhorn by participating in the Matterhorn project or directly participate in the making of Matterhorn - your help is appreciated! And we would be happy to see you contribute the functionalities that meet your needs as they will almost certainly be helpful to other institutions as well.
Wanting to test Matterhorn, but in need of technical assistance
With regard to testing Matterhorn, our adoption strategy is to incorporate as many institutions as possible, as we are looking for your feedback. To facilitate your interests in taking a look at Matterhorn, we will establish a number of "base camps" that help you testing. They will run demo instances of Matterhorn for you, help you with installing it yourself, enable access to capture agents for testing purposes, and support you in case you run into problems. Thus, we would like to establish networks of testing institutions around these base camps, where more advanced institutions will help those making their first steps. Take a Look Under the Hood
For those who want more technical details behind Matterhorn, the following documents should be helpful.
Install and Configure Trunk or the Latest Release This document will help you install and run the latest build of Matterhorn
Technology Stack The technologies on which Matterhorn is built
Service Contracts A complete listing of Matterhorn services
Architecture Overview of Matterhorn service orchestration and some service usage scenarios
Media Package Overview A media package is the business document within the Matterhorn ecosystem
Workflow Cookbook Introduction to workflows: defining, creating and customizing operations for routing lecture recordings through the system
Opencast Matterhorn Jira Jira is the issue tracker for the Matterhorn project. Within, you'll find a detailed set of tasks on which the team is working. For an introduction to Jira and how it is used in this project, visit this guide on how to navigate Jira issues Developer Getting Started Guide
Summary
Matterhorn is an end-to-end platform that supports the scheduling, capture, managing, encoding and delivery of educational audio and video content (more detailed intro About the Project). This page is for developers who are looking to get started modifying source code in Matterhorn or writing integrations with external systems. If you are looking to install Matterhorn then check out the administrators guide. If you just want to try it out then go to the matterhorn nightly server (http://nightly.opencastproject.org/). If none of this seems right then go to the Getting Started Guides.
Matterhorn is built in Java to run in an OSGi container. It does not require a servlet container or webserver and is a selfcontained system. The system consists of 2 main parts: the backend services and REST endpoints, and the frontend UI. The system takes media files as input to start a workflow. The media within the workflow is referred to as a media package. The media package stores everything related to the media that is being processed or has completed processing. Developers who are interested in technical details can check out the Architecture, Technology Stack, or Services listing.
Developer Setup Guide
Install Matterhorn from source code
Directions to install the latest release may be found here. Otherwise, the following directions will walk you through installing Matterhorn from trunk.
This document will help you install and run Matterhorn from the source code. If you want to preview Matterhorn then it is running at http://nightly.o pencastproject.org/.
Windows Users Matterhorn is having problems building on Windows. Please see this Jira filter for more information. Environment variables: To Add (or edit) environment variables (Control Panel -> System -> Advanced -> Environment variables) or use "set" instead of export like so: set MAVEN_OPTS="-Xms256m -Xmx512m" Spaces in paths: Windows XP users should ensure they do not have spaces in the paths to matterhorn, maven repository, and felix. It may fail to run if there are spaces in the paths.
OSX 10.5 Opencast recommends you install the Mac OS X Developer Tools 1. Open the Mac OS X installation disc. 2. Go into "Optional Installs" folder and run the Xcode.mpkg file.
1. Install Java 1.6 or higher
Note: Mac OSX 10.6 will have Java 1.6 installed by default
1. a. To check: Run java -version on the command line b. If not correct, download the J2SE SDK from: http://java.sun.com/javase/downloads/widget/jdk6.jsp c. Install it (the SDK) to /opt/java Note: Install the JRE to a different directory (probably the default, especially under windows) or you will have problems d. Set environment variable: JAVA_HOME=/opt/java Mac users: JAVA_HOME=/Library/Java/Home Windows users default: JAVA_HOME=C:\j2sdk1.6.0_xx (where "xx" is the minor version - for example "j2sdk1.6.0_11") e. Add $JAVA_HOME/bin to PATH
2. Setup Maven 2.0.6 or higher
Maven - http://maven.apache.org/
Note: Mac OSX 10.6 will have maven 2.2.0 installed by defaultNote: Mac OSX 10.5 will have maven 2.0.6 installed by default
1. a. Download Maven 2 (minimum 2.0.6) - http://maven.apache.org/download.html b. Extract to /opt (should create maven-2.X.X folder, where X.X is the sub version) c. Set environment variable: MAVEN2_HOME=/opt/maven-2.X.X d. Add $MAVEN2_HOME/bin to PATH\ e. Set the MAVEN_OPTS environment variable
MAVEN_OPTS='-Xms256m -Xmx960m -XX:PermSize=64m -XX:MaxPermSize=150m'
Windows: XP users have to change the location of their local repository since its path contains spaces (since it is in the user home directory by default). To change the location go to
3. Setup Subversion 1.5 or higher Subversion - http://subversion.tigris.org/
Note: Mac OSX 10.6 will have svn 1.6.5 installed by default Note: Mac OSX 10.5 will have svn 1.5 installed by default
1. a. To check: Run svn --version on the command line http://subversion.tigris.org/project_packages.html Get the subversion binaries and not the source, if possible If there are no binaries for your platform, get the source and use the configuration options --with-ssl and --with-libs b. Extract to /opt (should create subversion-1.5.5) Windows users will want to rename the extracted directory Unix users will probably want to use a package for their flavor c. Set environment variable: SUBVERSION_HOME=/opt/subversion-1.5.5 d. Add $SUBVERSION_HOME/bin to PATH
4. Get Matterhorn source
Matterhorn svn repository: http://source.opencastproject.org/svn/products/matterhorn/trunk
1. a. Create a directory to hold the source and your matterhorn install called matterhorn (referred to as MATTERHORN_HOME)
mkdir /opt/matterhorn cd /opt/matterhorn
b. Checkout matterhorn trunk into the matterhorn_trunk dir (referred to as MATTERHORN_SRC) in the MATTERHORN_HOME dir
svn checkout http://source.opencastproject.org/svn/products/matterhorn/trunk matterhorn_trunk
5. Setup Apache Felix OSGi
Apache Felix - http://felix.apache.org
NOTE: These instructions are for Apache Felix. Other OSGi implementations include Equinox and Knopflerfish. Matterhorn is tested on Felix but should work on any modern 4.1 compatible OSGi implementation.
1. a. Make sure you are in the MATTERHORN_HOME dir
cd /opt/matterhorn
b. Download the latest binary release of the "Felix Framework Distribution" http://felix.apache.org/site/downloads.cgi (probably version 2.0.1 or higher) c. Extract the archive in the MATTERHORN_HOME dir and rename the directory to felix
tar -xvf felix-framework-2.0.1.tar.gz mv felix-framework-2.0.1 felix
d. Create the felix load directory
mkdir felix/load
e. Copy over the felix configuration files to the felix conf dir
cp -r matterhorn_trunk/docs/felix/conf/* felix/conf/
NOTE: Remember to check for revisions to the Felix configuration files with each update of Matterhorn. If you are unsure 1.
e.
whether the file has been updated, it is safest to simply copy them over each time.
6. Copy run scripts and setup environment
These scripts setup your environment correctly to execute the matterhorn runtime using the felix OSGi container
1. a. Make sure you are in the MATTERHORN_HOME dir
cd /opt/matterhorn
b. Copy the matterhorn run scripts into the current directory (bat files for win or sh files for unix/OSX)
cp matterhorn_trunk/docs/felix/bin/*.sh .
NOTE: You may need to make the script executable: chmod a+x start_matterhorn.sh c. Add the following environment variables
export FELIX_HOME=/opt/matterhorn/felix export M2_REPO=~/.m2/repository
NOTE: If the "export" command doesn't work for you, use the equivalent command in your shell, or type "bash" to switch to a bash shell. NOTE: You could also edit the matterhorn start script but the recommended method is to setup the environment variables so the script picks up the changes d. Load the environment variables into the shell by closing the shell and opening a new one, or running:
source ~/.bash_profile
7. Build matterhorn
1. a. Make sure you are in the MATTERHORN_SRC dir
cd /opt/matterhorn/matterhorn_trunk
b. Build the source using maven
mvn clean install -DdeployTo=/opt/matterhorn/felix/load
Windows: Matterhorn does not yet build without test errors on Windows so in order to build Matterhorn -Dmaven.test.skip= true is specified. Instead of -Dmaven.test.skip=true you can also set -Dmaven.test.error.ignore=true and -Dmav en.test.failure.ignore=true to see which tests fail. NOTE: The Matterhorn project components will be deployed to the load directory of your Apache Felix instance. Felix will automatically reflect any changes made to this directory, even during runtime. Remember to delete everything in the felix/load directory before rebuilding Matterhorn. Maven does not delete previously built bundles when redeploying.
8. Install the 3rd party tools
Windows: The windows install for the runtime tools is much more complex and is documented here
Linux: Linux users will need ant, xml-commons-apis, zlib-devel or zlibig-dev, patch, byacc and pkgconfig. Linux users having difficulty building libmediainfo can download a binary version.
1. a. Go to the runtime tools dir (in the MATTERHORN_SRC dir)
b. cd opencast-runtime-tools
c. 1.
c. Build the runtime tools
sudo mvn install -Dthirdparty
NOTE: Admin access required: When the sudo command is used, you will need to enter your computer's operating system password.NOTE: Firewall rules: For licensing and patents reasons, the installer gets FFmpeg sources from their subversion repository, which means that you need to have outgoing access to port 3690
9. Configure Matterhorn
1. Matterhorn has a number of configuration options which you can generally leave at defaults for development purposes but it is important to be aware of them Overview of Configuration Files Configure Matterhorn Port Number and Base URL Configure Matterhorn Feed Catalog Capture Service Configuration
10. Run Matterhorn
1. a. Execute the run matterhorn script from your FELIX_HOME/bin dir
./start_matterhorn.sh
b. Wait for the logs to stop scrolling past at high speed (should take 30 secs to 1 min depending on your machine) c. Open http://localhost:8080 in your favorite web browser to test things are working NOTE: You can access the Felix system console at http://localhost:8080/system/console (user:admin, pw: admin)
11. Update Matterhorn source
After you have installed Matterhorn source code, you may want to periodically update to the latest revision if you are working with the trunk
1. a. run the svn update command from the matterhorn_trunk dir (a.k.a MATTERHORN_SRC) b. after the update is complete, if Matterhorn is running, to stop Felix type shutdown at the command prompt (you may need to press 'Enter' to get the '$' which is the command prompt) where your Felix is running. You can also press 'CTRL-C'. c. delete all files from felix load with the command: rm -rf /opt/matterhorn/felix/load/* d. optionally (e.g. if you have problems), you may also want to delete the temporary files in the "opencast" Temp directory created to run Matterhorn on your machine. This directory can be seen by watching the Felix logs while you ingest a file-on my Mac the path to it is: /private/var/folders/FU/FU Unknown macro: {long string of letters and numbers} -/Tmp/opencast. e. execute the maven build command (see the Build matterhorn section above) f. You may want to ensure your felix configuration is up to date: cp -r /opt/matterhorn/matterhorn_trunk/docs/felix/conf/* /opt/matterhorn/felix/conf/ i. NOTE: You will lose any local changes you made to those files g. run the ./start_matterhorn.sh script to restart Felix
Developing Matterhorn source
1. Installing eclipse Eclipse IDE - http://www.eclipse.org/ a. Download the current version of the Eclipse IDE for Java EE Developers from http://www.eclipse.org/downloads/ This version is recommended because it includes the web development tools b. Extract the downloaded file Windows: should extract to c:\ Mac OSX: should use the installer and put it in Applications c. Run eclipse to verify it works (/opt/eclipse/eclipse) Windows: c:\eclipse\eclipse.exe to run eclipse NOTE: If it does not work, there is probably a problem with your java install d. Set the memory settings for Eclipse The default memory settings for Eclipse are too low to handle a large project like Matterhorn i. Shutdown eclipse if it is running ii. Edit the eclipse.ini file in the directory you extracted/installed eclipse iii. Change the settings from something like this: 1.
d.
iii.
-vmargs -Xms40m -Xmx256m
to something like this (leave any params that do not match these alone):
--launcher.XXMaxPermSize 256M -vmargs -Xms128m -Xmx1024m -XX:+UseParallelGC
Windows: users should not use notepad to edit this file, use wordpad or edit (command line) Mac OSX: users will need to take additional steps to edit the eclipse.ini file i. Control-click on the Eclipse Application icon and select Show Package Contents ii. Double-click on the Contents folderD iii. Double-click on the MacOS folder, the eclipse.ini file should be here iv. Full path: eclipse/Eclipse.app/Contents/MacOS/eclipse.ini e. Install the subclipse plugin Subclipse - http://subclipse.tigris.org/ i. Use eclipse updater to install the plugin from the update site
http://subclipse.tigris.org/update_1.6.x
f. Install the Maven Integration for Eclipse plugin Maven Integration for Eclipse - http://m2eclipse.sonatype.org/ i. Use eclipse updater to install the plugin from the update site
http://m2eclipse.sonatype.org/update
2. Configure eclipse There are more details available in the Eclipse Guide a. Install the files below in your eclipse installation to automatically adhere to the project code styles
Preferences > Java > Code Style > Formatter > Import docs/eclipse_settings/opencast-codestyle.xml
Preferences > Java > Code Style > Code Templates > Import docs/eclipse_settings/opencast-codetemplate.xml 2.
a.
Preferences > Java > Code Style > Organize Imports > Import docs/eclipse_settings/opencast.importorder
3. Import source into eclipse There are more details available in the Eclipse Guide a. Import the entire matterhorn source as a single project i. Click on File > Import ii. Select Maven Projects under General iii. Browse to your MATTERHORN_SRC directory (e.g. /opt/matterhorn/matterhorn_trunk) and click Open iv. Open the advanced options at the bottom and uncheck Resolve Workspace projects and Separate projects for modules v. Click on Import to start the process (may take 5-10 minutes) vi. Once this is complete you can access all the matterhorn trunk projects in the new base project Recommend you rename this from "base" to "matterhorn-base" 4. Build and redeploy a single bundle When developing for Matterhorn you may just want to change a small part of a single project/bundle. This does not require a rebuild and restart of the entire Matterhorn system. You can redeploy a single bundle allowing for faster development! a. Go to your MATTERHORN_SRC directory
cd /opt/matterhorn/matterhorn-trunk
b. Change to the directory containing the bundle you want to redeploy (e.g. opencast-search-service-impl)
cd opencast-search-service-impl
c. Rebuild and redeploy using maven (use the same build command you always use)
mvn clean install -DdeployTo=/opt/matterhorn/felix/load
d. The new bundle should replace the existing one and you will see the startup process (or failures if you made a mistake) in the logs
Developer details
Developers working on Matterhorn should follow this set of best practices (all work practices).
Committers Practices Java best practices Frontend best practices REST practices
Issue tracker: http://issues.opencastproject.org/jira (more details about usage) Javadocs: http://build.opencastproject.org/apidocs/ Nightly server: http://nightly.opencastproject.org/ VM info: Install Virtual Machine - setup and run Matterhorn using a virtual machine image Contribute to Matterhorn
Opencast Matterhorn can only achieve the goal of developing a system for the community if the project is supported by the community. Contributions can take many forms, depending on your ambitions and your level of interest.
For potential adopters who want to follow the project
Join the Opencast Community mailing list. We'll use this list to keep the Opencast community informed about the project as it progresses. Consider test driving our latest release.
For those who want to have a voice in the direction of Matterhorn Join the Opencast Matterhorn mailing list. This very active list is the main mode of communication among the Matterhorn team members. Feel free to participate in discussions to convey your perspective. Look for email over this list tagged "#proposal" to have a say in the development of Matterhorn. Join our online meetings - as a lurker, as an active participant, as a note-taker (very welcome!) Enter JIRA to make community requests.
For those who want to lend a hand to the project
Participate in various working groups - help us do customer research, comparative analysis or technical analysis. Opportunities will be announced on list. If you have technological expertise, skills or ideas you think could contribute to the Matterhorn project, talk to our developers about how to get involved. Peruse the wiki, starting with the Contributor Guide.
Your contributions will make Matterhorn a better product in that it is based upon the expertise and the initiative of many instead of a few. Product Documentation
Matterhorn is an end-to-end platform that supports the scheduling, capture, managing, encoding and delivery of educational audio and video content. The features planned for the first release, scheduled for August 2010, include:
Administrative tools for scheduling automated recordings, manually uploading files, managing metadata Recommended capture agent hardware specifications Integration with recording devices in the classroom for managing automated capture Distribution to channels such as YouTube, iTunes, and supporting services, such as RSS, to push content to campus course or content management system Rich media user interface for learners to engage with content, including playback, content-based search, and captioning Processing and encoding services that prepare and package the media files for distribution
Matterhorn is also a media services framework. It will be flexible and services-based, so that organizations can choose to implement only the components they need, or replace default service implementations with their own to meet specific institutional needs. Release 0.5 Documentation Road Map License Information Features and Functionality Release 0.5 Documentation
Release 0.5: Start climbing!
We are very pleased to announce the release of Matterhorn 0.5, the alpha version of Opencast Matterhorn!
Opencast Matterhorn is a free, open source platform to support the management of educational audio and video content. Institutions will use Matterhorn to produce lecture recordings, manage existing video, serve designated distribution channels, and provide user interfaces to engage students with educational videos. The 0.5 alpha release offers institutions and individuals a preview of Matterhorn's functionality, namely:
the basics to capture, encode, distribute, and play media accessible media player and its unique html/js/ajax and flash hybrid architecture administrative lecture capture tools lecture capture automation rss/atom feed catalog inexpensive media capture appliance workflow flexibility
With the release of 0.5, the Opencast Matterhorn Project has decided to share Matterhorn with the Opencast Community at an early stage. Our belief is that Matterhorn is the Opencast Community's product, and it should be in your hands to experience and improve upon from the beginning. We welcome your input whether it be a complement, a comment on missing features, a bug entry, or a software patch. This alpha release does not contain the full array of features promised in 1.0 (https://wiki.opencastproject.org/confluence/display/open/Road+Map), but it provides a significant preview of things to come.
Starting in the classroom, you can access a virtual capture agent to record lectures, schedule reoccurring events and monitor the status of capture devices; alternatively, you set up your own capture device or make use of hosted capture agents. The administrative tools allow you to ingest existing videos as well to incorporate digitized media or customized video productions. Matterhorn's out of the box distribution channel offers an rss/atom catalog to enable the generation of custom rss/atom feeds as well as embeddable video.
Download and Installation
To provide adequate access to 0.5, we have arranged for a number of different installation options:
download 0.5 release install Matterhorn from the source code (https://wiki.opencastproject.org/confluence/display/open/Install+Source+%28Release+0.5%29), use Matterhorn's virtual machine distribution (https://wiki.opencastproject.org/confluence/display/open/Install+Virtual+Machine+%28Rele ase+0.5%29). test on a hosted Matterhorn installation at one of five base camp institutions (https://wiki.opencastproject.org/confluence/display/open/Ma tterhorn+Basecamps).
Communication
If you need help installing Matterhorn, we have provided several communication channels:
The Opencast Community List is a great place to ask installation questions, general questions about Matterhorn's features, or anything else related to Matterhorn. To get started just subscribe to the [email protected] mailing list and send out an email. You'll find many people there happy to help you. The IRC chat group #opencast on irc.freenode.net is by developers to communicate about low level technology issues. This group is an excellent place to ask specific technical questions or to get immediate help on something that is blocking you.
Documentation
All the relevant documentation and information releated to 0.5:
comprehensive FAQ ( https://wiki.opencastproject.org/confluence/display/open/Release+0.5+FAQ) worth reading to learn more about the installations options and many other topics. quickstart to installation and configuration can be found at https://wiki.opencastproject.org/confluence/display/open/Release+0.5+Install+ and+Configure. cookbook to help get your hands dirty developing and configuring Matterhorn at https://wiki.opencastproject.org/confluence/display/open/ Release+0.5+Cookbook once Matterhorn 0.5 has been installed, the welcome page will guide you to all relevant resources, including the introductory video you can also find at http://www.youtube.com/watch?v=6K7ij38cT1k.
Bugs
As with any alpha release, Mattherhorn has bugs. Some of these problems have already been addressed, some have been entered to be addressed, but there are likely others that are unknown to us. Please do not hesitate to enter a bug in Jira and/or fix it yourself! Instructions on how to enter bugs and submit patches for 0.5 and trunk are available at https://wiki.opencastproject.org/confluence/display/open/Release+0.5+FA Q.
A few known issues:
Admin manual ingest page indicates that only media with video can be submitted, but audio only files are supported too. Capturing and All recordings filters do not work, but the capture status page provides capture status for current recordings. Sometimes the demo capture agent fails to capture scheduled events. A simple Matterhorn restart will fix this problem. Scheduled recordings do not retain user entered metadata. Instead the recording uses canned metadata and media provided by the demo capture agent.
Bug Lists:
Release 0.5 Open and Closed Bugs (indicates issues addressed in iteration) https://issues.opencastproject.org/jira/browse/MH/fixforvers ion/10061 Iteration 8 and 9 Tasks (indicate issues addressed month after 0.5 release) Iteration 8_https://issues.opencastproject.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10010&resolution=-1&fixfor=100 40&sorter/field=priority&sorter/order=DESC Iteration 9_https://issues.opencastproject.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10010&resolution=-1&fixfor=100 41&sorter/field=priority&sorter/order=DESC Release 0.5 Cookbook
Capture
Content by label
There is no content with the specified labels
MediaPackage Content by label
There is no content with the specified labels
Workflow
Content by label
There is no content with the specified labels
REST Endpoints
Content by label
There is no content with the specified labels
Automated Testing
Adding Demo Data To Your Instance (Release 0.5) (Opencast Developer Wiki) testing r5
Service Design
Content by label
There is no content with the specified labels
User Interfaces
Content by label
There is no content with the specified labels Anatomy of a Service (Release 0.5)
This document outlines the service template created by oc:generate. Although the details are specific to the example service, it should help you get started with your own service.
All package and filenames assume an "example" service. Please substitute your service name where appropriate.
Architecture
The service template package is articulated into two parts:
Service and Entity org.opencastproject.example.api and impl
Endpoints org.opencastproject.example.endpoint
The template exposes two types of endpoints:
SOAP org.opencastproject.example.endpoint.WebService.api and impl
REST org.opencastproject.example.endpoint.RestService
The models and endpoints communicate to and from XML via Java Architecture for XML Binding (JAXB) bindings, defined in org.opencastpro ject.example.endpoint.ExampleEntityJaxbImpl.
Logging
The service template leverages The Simple Logging Facade for Java (SLF4J) to document state.
import org.slf4j.Logger; import org.slf4j.LoggerFactory; ... private static final Logger logger = LoggerFactory.getLogger(
Web Service
ExampleService.java declares methods to get and set fields of the entity described in ExampleEntity.java.
ExampleEntity getExampleEntity(String id); void saveExampleEntity(ExampleEntity entity);
ExampleServiceImpl.java implements ExampleService using a HashMap. map = new HashMap
Configuration Admin Service
ExampleServiceImpl.java also implements org.osgi.service.cm.ManagedService's single method, update, allowing it to receive configuration data from an OSGi Configuration Admin Service.
import org.osgi.service.cm.ConfigurationException; import org.osgi.service.cm.ManagedService; ... public class
Entity
ExampleEntity.java declares getters for a model with three fields.
getId() getTitle() getDescription()
ExampleEntityImpl.java implements those getters, along with corresponding setters meant for internal use.
setId(String id) setTitle(String title) setDescription(String description)
Java Architecture for XML Binding (JAXB)
ExampleEntityJaxbImpl.java uses JAXB annotations to marshal an XML representation of the above mentioned entity. import javax.xml.bind.annotation.XmlAccessType; import javax.xml.bind.annotation.XmlAccessorType; import javax.xml.bind.annotation.XmlAttribute; import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlID; import javax.xml.bind.annotation.XmlRootElement; import javax.xml.bind.annotation.XmlTransient; import javax.xml.bind.annotation.XmlType; ... @XmlType(name="example-entity", namespace="http://example.opencastproject.org/") @XmlRootElement(name="example-entity, namespace="http://example.opencastproject.org/") @XmlAccessorType(XmlAccessType.FIELD) ... @XmlID @XmlAttribute() private String id;
@XmlElement(name="title") private String title;
@XmlElement(name="description") private String description;
The constructor ExampleEntityJaxbImpl uses getters and setters to convert the in-memory representation to XML; getEntity does the opposite.
public ExampleEntityJaxbImpl() {} public ExampleEntityJaxbImpl(ExampleEntity entity) { ... this.id = entity.getId(); this.title = entity.getTitle(); this.description = entity.getDescription(); } ... public ExampleEntity getEntity() { ExampleEntityImpl entity = new ExampleEntityImpl(); entity.setId(id); entity.setTitle(title); entity.setDescription(description); return entity; } In order to be a valid Java Bean, the ExampleEntityJaxbImpl must include a second, zero argument constructor. getEntity is annotated as transient, meaning that it will not be represented as XML.
@XmlTransient public ExampleEntity getEntity() { ...
SOAP Endpoint
ExampleWebService.java declares its own version of the get and set entity methods we saw in ExampleService.java. The service and methods are indicated using Java API for XML Web Services (JAX-WS) annotations.
import javax.jws.WebMethod; import javax.jws.WebParam; import javax.jws.WebResult; import javax.jws.WebService; ... @WebService() public interface ExampleWebService{ @WebMethod() @WebResult(name="example-entity") public ExampleEntityJaxbImpl getExampleEntity(@WebParam(name="id") String id);
@WebMethod() public void storeExampleEntity(@WebParam(name="example-entity") ExampleEntityJaxbImpl jaxbEntity);
ExampleWebServiceImpl.java implements ExampleWebService, along with a setter to bind the endpoint to ExampleService.
import org.opencastproject.example.api.ExampleEntity; import org.opencastproject.example.api.ExampleService; ... private ExampleService service; public void setService(ExampleService service) { this.service = service; }
Note the use of ExampleEntityJaxbImpl.java. return new ExampleEntityJaxbImpl(entity); ... service.saveExampleEntity(jaxbEntity.getEntity());
REST Endpoint
ExampleRestService.java declares yet another version of the get and set entity methods we saw in ExampleService.java. The service and methods are indicated using Java API for RESTful Web Services (JAX-RS) annotations.
import javax.ws.rs.Consumes; import javax.ws.rs.FormParam; import javax.ws.rs.GET; import javax.ws.rs.POST; import javax.ws.rs.Path; import javax.ws.rs.Produces; import javax.ws.rs.QueryParam; import javax.ws.rs.core.MediaType; import javax.ws.rs.core.Response; ... @Path("/") public class ExampleRestService ... @GET @Produces(MediaType.TEXT_XML) public ExampleEntityJaxbImpl getAnEntity(@QueryParam("id") String id) { ExampleEntity entity = service.getExampleEntity(id); return new ExampleEntityJaxbImpl(entity); }
The ExampleRestService constructor retrieves service documentation from resources/html/index.html, which is returned by the getDo cumentation method. @GET @Produces(MediaType.TEXT_HTML) @Path("docs") public String getDocumentation() { return docs; }
protected final String docs;
public ExampleRestService() { String docsFromClassloader = null; InputStream in = null; try { in = getClass().getResourceAsStream("/html/index.html"); docsFromClassloader = IOUtils.toString(in); ... docs = docsFromClassLoader; }
Dependency Management Capture Media from the Command-line (Release 0.5)
This document explains how to capture media using the Felix OSGi command-line.
1. Prepare a. Remove
Start capture:start
Status capture:status
Stop capture:stop
Create a New Service (Release 0.5)
This document will walk you through the steps necessary to generate a new OSGi service, using the oc:generate Maven plugin.
This document assumes that you are able to commit code to the Matterhorn Subversion repository.
Jira Maven oc:generate Subversion Repository Import the New Service Delete the New Service Locally Add the New Service to the Subversion .externals File Maven Installation and Deployment Update the top-level pom.xml File Install and Deploy the Matterhorn Project Test Your New Service Document Your New Service
Jira
The first step when preparing a service is to create Jira issues for the task. 1. Add a Story Card for your new service; note the issue number (e.g. MH-582).
2. Add Tasks under your Story Card for your service API and Implementation; note the issue numbers (MH-583 and MH-584).
Maven oc:generate
The Matterhorn oc:generate plugin goal will quickly and easily produce the standard directory structure and essential classes of your new service. The service will include API and Implementation files, as well as several Web Service Endpoints (SOAP, REST, etc.) and JAX-B Entity D efinitions. It will also include the necessary pom.xml and OSGI-INF files for integration with Maven and OSGi.
1. Generate the new service
cd
Subversion Repository
The new service should be imported into the Matterhorn Subversion repository, removed locally and finally checked out from the repository. This will require updating your svn:externals properties.
Import the New Service
1. Import the service API.
cd
1. Import the service Implementation. cd
If the service was, for example, imported to the /contrib directory, the online repository would resemble the following:
Delete the New Service Locally
cd
Add the New Service to the Subversion .externals File
1. Open
../../../modules/opencast-
3. Update the svn:externals properties.
cd
4. Update the repository.
svn commit
5. Confirm that the new services have been added. 5.
You should once again see the opencast-
Maven Installation and Deployment
Apache Maven's declarative model makes it easy to add a new service to the Matterhorn project's build goals.
Update the top-level pom.xml File
1. Open
...
Install and Deploy the Matterhorn Project
cd
Remember to specify the absolute path to the Felix load directory. Assuming all goes well, you should see API and Implementation directories for your new service in
Test Your New Service
1. Start Felix.
cd
Remember to specify the absolute path to the Maven repository directory.
2. Check status of service modules within Felix.
-> ps
The output should include the following:
[
3. Browse the service: http://localhost:8080
The page should include the following:
Base URL Description WSDL
/
...
Base URL Description Documentation WADL
/
The links should display the following:
Document Your New Service
The last step in defining a new service, short of actually coding, is documenting it.
For the time being, in lieu of a stable template, please copy the markup of the DEPRECATED Service Contract Description Template a nd paste it into your new page.
1. Create a new wiki page for your service, using the Service Contract Description template. 1.
See Document a Service for more information. 2. Post to the Matterhorn email list, announcing your wonderful addition to the project. Get Capture Agent Schedules (Release 0.5)
This document will help you retrieve the schedules for active Matterhorn capture agents.
Get Schedule for all Agents in XML format
1. Send an HTTP GET
curl http://
2. Check the response
Get Schedule for a given Agent in XML format
1. Send an HTTP GET
curl http://
2. Check the response
Get Schedule for a given Agent in iCalendar format
1. Send an HTTP GET 1.
curl http://
2. Check the response
BEGIN:VCALENDAR PRODID:Opencast Matterhorn Calendar File 0.5 VERSION:2.0 CALSCALE:GREGORIAN END:VCALENDAR
Including common static resources in your UI (Release 0.5)
If you are building a user-facing tool, you should bundle the project-wide shared css, javascript libraries, and image files into your project at build time rather than copying them into your project in svn. To automate this process, you can use the maven resources plugin, like this:
This copies all of the files in the /static-resources directory to /your_project/target/classes/ui. This assumes that the /ui classpath is registered with the http service, as described in Registering User Interfaces.
You must also ensure that the maven-bundle-plugin is aware of these static resources, or they will be excluded from your osgi bundle.
Integration Testing (Release 0.5)
Introduction
The opencast-test-harness module provides a mechanism to test Matterhorn REST and SOAP service endpoints. The test harness should be used to verify:
that the endpoint exists at the correct URL(s) that the endpoint accepts new / updated content via POST and/or PUT that the endpoint returns expected data sets via GET that the endpoint is documented (/docs, /?wsdl, and/or ?_wadl returns something useful)
The test harness should not be used to test implementation logic. For that, you should use unit tests, relying on mock objects to simulate collaborating services.
Writing integration tests
This section still needs improvement... both the documentation and the implementation. If you are interested in getting involved in the project, this is a great place to help out!
1. Add a test class to opencast-test-harness/src/main/java. Use Junit's annotations to specify test methods and, if necessary, setup, teardown for your test fixture. 2. Use apache httpclient to connect to the endpoint and verify that it works as expected. We are currently writing to System.out to indicate success / failure. To post to an endpoint and inspect the returned body: 2.
HttpClient client = new DefaultHttpClient(); HttpPost post = new HttpPost(baseUrl + "/my/rest/endpoint"); List
formParams.add(new BasicNameValuePair("param1", "value1")); formParams.add(new BasicNameValuePair("param2", "value2")); post.setEntity(new UrlEncodedFormEntity(formParams, "UTF-8"));
String postResponse = client.execute(post, new ResponseHandler
Specifying a ResponseHandler gives you more flexibility, but for simple use cases you can avoid this complexity:
String postResponse = EntityUtils.toString(client.execute(post).getEntity());
To issue an http GET:
HttpClient client = new DefaultHttpClient(); HttpGet get = new HttpGet(baseUrl + "/my/rest/endpoint.xml"); String getResponse = client.execute(get, new ResponseHandler
Or using the simpler form:
String getResponse = EntityUtils.toString(client.execute(get).getEntity());
3. Verify that the responses you receive are what you expect. Java's built in xpath capabilities should be used to verify xml responses. 3.
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setNamespaceAware(true); // don't forget this! DocumentBuilder builder = factory.newDocumentBuilder(); Document doc = builder.parse(IOUtils.toInputStream(xmlResponse)); return ((Element)XPathFactory.newInstance().newXPath().compile("/*").evalu ate(doc, XPathConstants.NODE)).getAttribute("id");
The json-simple library is embedded in the test harness, and should be used to verify JSON responses.
JSONObject json = (JSONObject) JSONValue.parse(jsonResponse); System.out.println("Retrieved json response for my object with id=" + json.get("id"));
4. Add your class to the @SuiteClasses annotation in the AllRemoteTests.java test suite. You may also build your own test suite here, if appropriate, and reference your suite from AllRemoteTests.java.
Running integration tests
There are a few ways to run the integration tests:
1. In eclipse or your favorite IDE. This is useful when you want to run just your own integration test 2. Run the opencast-test-harness jar from the command line. If you want to test a server other than localhost:8080, specify the server's URL as an argument (make sure to prepend "http://"). Further enhancements may support multi-threaded operations to test server-side contention and performance.
cd opencast-test-harness java -jar target/opencast-test-harness-0.6-SNAPSHOT-jar-with-dependencies.jar
Java Unit testing (Release 0.5)
Introduction
See http://pub.admc.com/howtos/junit4x/ for a thorough introduction to the use of Junit 4.x, and http://maven.apache.org/plugins/maven-surefire-p lugin/usage.html for documentation on how unit tests are run as part of the maven build.
Writing a simple unit test
As a general rule, your test should be as simple as possible. Test one thing at a time, and do not store state between test runs. A simple example of two simple tests: public class MyTest {
protected MyObjectSerializer serializer = null; protected MyObjectImpl myObj = null;
@Before public void init() { serializer = MyObjectSerializer.getInstance(); myObj = new MyObjectImpl("value1", "value2"); }
@After public void destroy() { serializer = null; myObj = null; }
@Test public void testSerialization() throws Exception { String xml = serializer.toXml(myObj); Assert.assertEquals("
@Test public void testBehavior() throws Exception { Assert.assertTrue(myObj.hasFirstValue()); } }
Notice that, even though the two test methods coexist in the same class, they do not share state. Before each test method, both MyObject and MyObjectSerializer are instantiated, and after each test method these objects are defererenced. This ensures that any side-effects produced by one test do not impact the outcome of the others.
Collaborating services
You should try to factor your code so you can test most of it using simple unit tests, as described above. However, at some point the code that you are testing will need to reference other services. These dependencies, often known as collaborators, must be provided in order for your code to function. We have several options for providing your code with its collaborators:
Write stub implementations. This is slow and can become a maintenance nightmare, though it can be appropriate for simple use cases Launch the actual server environment. This is too slow to maintain a rapid development pace. We do this as part of integration testing rat her than unit testing Use mock objects, which can be trained to have any behavior that your test client desires. This is the preferred approach to unit testing with collaborating services, and EasyMock is our preferred mock object library. JavaScript Unit testing (Release 0.5)
Introduction
This wiki page contains a summary of the documentation of QUnit found on:
http://docs.jquery.com/QUnit in the recently released O'Reilly title "jQuery Cookbook": http://oreilly.com/catalog/9780596159788/ Citing the introductory words on its homepage:
QUnit is a powerful, easy-to-use, JavaScript test suite. It's used by the jQuery project to test its code and plugins but is capable of testing any generic JavaScript code (and even capable of testing JavaScript code on the server-side).
There is no easy definition of "unit testing" for JavaScript. Does it include having a DOM library? Does it include a specific browser of some vendor?
Each of these three levels could be tested:
"pure" unit tests using QUnit running in v8 or rhino unit tests involving a DOM library running these in htmlunit (but without ensuring cross browser compatibility) full cross browser compatible unit tests using something like Selenium Grid (http://selenium-grid.seleniumhq.org/), parallel *-Watirs (http:// watir.com/platforms/) or something like John Resig's Test Swarm (http://testswarm.com/)
We wanted to have midscale and full tests and thus decided to define JavaScript unit tests as "unit tests involving the DOM library in htmlunit". M H-1769 integrates a fully automated setting into Matterhorn.
How to write a simple JavaScript unit test
The essential structure of a unit test is:
arrange / given action / when assert / then
Assertions
There are three assertions provided by QUnit: ok(state, [message])
test("a test", function() { ok(true, "always fine"); ok(false, "this assertion fails"); });
This is the most basic assertion function provided by QUnit. It requires a single boolean argument. If this argument resolves to true, this assertion passes. If it resolves to false, this assertion fails. You can give an additional string to show a meaningful explanation, if this assertion fails. equals(actual, expected, [message])
test("a test", function() { var actual = 1; equals(actual, 1); equals(actual - 1, 0, "this message is added to the assertion result, useful for debugging"); });
equals is equivalent to JUnit's assertEqual (but the order is different). Use this for comparing non-boolean values, as it outputs both values on fail. same(actual, expected, [message]) test("same test", function() { same(undefined, undefined, "same succeeds"); same("", 0, "same fails"); });
same is stricter than equals as comparison is done with ===}. So null, 0, the empty string "" and undefined are not the same. Moreover it does a deep, recursive comparison instead. This assertion should be used in most cases.
Writing test cases
Assertions are contained in Test cases. Try to keep tests atomic using at most a single assertion per case. This way you will know exactly why a test case fails and you will prevent invalid results from side effects.
Test cases are written by calling the test method:
test("a test", function() { ok(true, "always fine"); });
The signature of this method is: test(name, [expected], test)
name is obviously the name of the test. expected is an optional parameter containing the number of assertions expected to run. This is important for asynchronous tests. test is a function literal containing the actual testing code.
Grouping Tests
If you split your test cases keeping them atomic and free of side effects, you will end up with a lot of these. To organize them logically and to be able to run only certain groups of tests, you can employ the module method to group the test cases.
module("group a"); test("a basic test example", function() { ok( true, "this test is fine" ); }); test("a basic test example 2", function() { ok( true, "this test is fine" ); }); module("group b"); test("a basic test example 3", function() { ok( true, "this test is fine" ); }); test("a basic test example 4", function() { ok( true, "this test is fine" ); }); After calling module every test case will end up in that group. If you call module again, all following test cases are grouped in that module. Additionally module can be used for setting up fixtures and tearing them down:
module("lifecyle example", { setup: function() { this.testData = "foobar"; }, teardown: function() { delete this.testData; } }); test("test with setup and teardown", function() { same(this.testData, "foobar"); });
So the signature of this method is: module(name, [lifecycle])
name is the name of this module. lifecycle is optional and contains setup and teardown callbacks which are run before and after every test in this module.
Testing synchronous callbacks
Whenever you have to tests code with synchronous callbacks, there will be passing tests that should actually fail as the assertion is never evaluated.
test("a test", function() { expect(1); $("input").myPlugin({ initialized: function() { ok(true, "plugin initialized"); } }); });
For these circumstances you may use the method expect(amount) to assert the number of assertions to get evaluated. expect does nothing for you if you do not test code using callbacks. Note that the second, optional parameter to test does exactly the same thing.
Asynchronous Tests
Unfortunately expect may not help you with asynchronous callbacks which are used by XmlHttpRequests or DOM events. Testing is inherently synchronous and so you have to stop the test runner for a moment until that magic happens and get started afterwards. test("a test", function() { stop(500); $.getJSON("/someurl", function(result) { equals(result.value, "someExpectedValue"); start(); }); });
As you see there are two additional methods stop([timeout]) and start() which allow you to test asynchronous callbacks. Just call stop b efore asynchronous operations and start after all assertions in order to ask the test runner to move onward. Obviously you risk, that start may get never be called. To mitigate that fact you may provide a number of milliseconds as an timeout to stop to make sure that the test runner continues after at most this given amount of time.
test("a test", function() { stop(500); $.getJSON("/someurl", function(result) { equals(result.value, "someExpectedValue"); start(); }); });
Try to avoid that parameter to prevent hunting for false negatives. MediaPackage Cookbook (Release 0.5)
Working with media packages
A media package represents the business document for the matterhorn lecture capture system. The following document shows how a media package can be created, modified and also made persistent. Working with media packages Creating a media package Reading a media package from a manifest Adding elements to the media package Managing package persistence
Creating a media package
In order to get hold of a media package, you first obtain a reference to a MediaPackageBuilder, offering you the possibility to either create a new media package or to load an existing one.
MediaPackageBuilderFactory factory = MediaPackageBuilderFactory.newInstance(); MediaPackageBuilder builder = factory.newMediaPackageBuilder(); MediaPackage mediaPackage = builder.createNew();
This code will create an empty media package with an automatically created identifier. Should you want to specify the identifier yourself, use the alternative signature createNew(identifier). Matterhorn comes with a default implementation of the media package. However, if you would like to replace it with your own code, you may set the java system property org.opencastproject.mediapackage.builder to the classname of your media package builder implementation.
Reading a media package from a manifest
A common usage pattern for the media package is creating an in memory representation from an input stream:
MediaPackageBuilderFactory factory = MediaPackageBuilderFactory.newInstance(); MediaPackageBuilder builder = factory.newMediaPackageBuilder(); InputStream is = getMyMediaPackageStream(); MediaPackage package = builder.fromManifest(is);
Adding elements to the media package
Adding elements to a media package is straightforward. Get hold of the media package and call the add() method with the elements url:
File dcFile = new File("dublincore.xml"); URL mpeg7Url = new URL("http://www.opencastproject.org/mpeg7.xml"); MediaPackageElement dc = mediaPackage.add(dcFile.toURI().toURL()); MediaPackageElement mpeg7 = mediaPackage.add(mpeg7Url);
Should you happen to know more about your media package elements than just the url, you may specify them right away. Media package elements support the following attributes:
File file = new File("mpeg7.xml"); MediaPackageElement e = mediaPackage.add(file.toURI().toURL()); e.setChecksum(Checksum.create(ChecksumType.DEFAULT_TYPE, file)); e.setSize(file.length()); e.setMimeType(MimeTypes.XML);
There is a variety of subtypes to the media package element that bring additional attributes like the duration of a track. If you know what you are doing (and usually this should be the case) then you can assist the package builder by providing an element flavor:
File file = new File("mpeg7.xml"); MediaPackage.Type type = MediaPackage.Type.Catalog; MediaPackageElementFlavor flavor = Mpeg7Catalog.FLAVOR; Mpeg7Catalog e = (Mpeg7Catalog)mediaPackage.add(file.toURI().toURL(), type, flavor); e.setChecksum(Checksum.create(ChecksumType.DEFAULT_TYPE, file)); e.setSize(file.length()); e.setMimeType(MimeTypes.XML); You can even make your own element types first class citizens inside the media package. All you need to do is add an element builder plugin to the classpath. Read "Extending the media package" for further details.
TODO: Add that section
Managing package persistence
The elements of a media package can be located at any location that can be referenced by a url. This adds a lot of benefits to the handling of media packages. However, there are also a few drawbacks to consider.
This is why you may add a MediaPackageSerializer to the MediaPackageBuilder. The serializer will be used to create and to resolve urls in a media package.
This technique could be used to implement a proxy for element storage or to add a shared workspace preventing clients to repeatedly download the same large track from an external webserver.
The default serializer comes with support to resolve relative paths in the media package. Therefore, it needs the common root url:
// Get hold of a media package builder MediaPackageBuilderFactory factory = MediaPackageBuilderFactory.newInstance(); MediaPackageBuilder builder = factory.newMediaPackageBuilder();
// Create a default serializer with a root url URL rootUrl = new URL("http://www.opencastproject.org/package"); MediaPackageSerializer s = new DefaultMediaPackageSerializer(rootUrl);
// Set the serializer and read the package InputStream is = getMyMediaPackageStream(); builder.setMediaPackageSerializer(s); MediaPackage package = builder.fromManifest(is);
Once you would like to serialize your media package, you can pass it the same serializer to make sure relative paths are used instead of absolute urls. Of course, you could use another implementation if you would like the media package to contain a modified set of urls.
MediaPackageSerializer serializer = new DefaultMediaPackageSerializer(rootUrl); Document xml = mediaPackage.toXml(serializer);
Obtaining the server's base URL (Release 0.5)
When generating URLs, you can obtain the base portion of the URL via the OSGi BundleContext.
Matterhorn's use of delcarative services hides most, if not all, of the OSGi framework from your service implementation, so you may not have a reference to the current bundle context. In this case, you can obtain a bundle context reference by using an "activate" method on your service implementation. Here's how this works:
1) In your component configuration, specify the name of your activation method. In this case, it's called "myActivateMethod":
2) Implement your activation method
public class MyServiceRestEndpoint { protected String serverUrl = null; public void myActivateMethod(ComponentContext cc) { if(cc == null) serverUrl = UrlSupport.DEFAULT_BASE_URL; String ccServerUrl = cc.getBundleContext().getProperty("serverUrl"); serverUrl = ccServerUrl == null ? UrlSupport.DEFAULT_BASE_URL : ccServerUrl; } ... }
Notice that the myActivateMethod method takes a ComponentContext parameter. This unfortunately ties your class to OSGi packages. The OSGi 4.2 specification allows for a Map of properties to be substituted for the component context, but this is only available in snapshot versions of the felix scr. Once this feature makes it into a stable release, we will factor out all unnecessary binding to ComponentContext. Registering User Interfaces (Release 0.5)
To register a user interface with Matterhorn, use OSGi Declarative Services.
1. Add your project-specific static resources (html, js, images) to a package under src/main/resources. (Shared static resources should be added to the /static-resources module. See Including common static resources in your UI) 2. In your project's pom.xml, include a dependency for opencast-http
3. In your project's pom.xml, add a configuration for your service component 3.
4. Your service component should register a org.opencastproject.http.StaticResource
Set the component name, "service.description", "alias" (e.g. base path for URLs), "classpath" (the package under src/main/resources), and optionally the "welcome.file" (if this is different from the default index.html).
If you have included Selenium tests for your UI, set the "test.classpath" value to the package containing your tests, and set the "test.suite" property to the HTML file within "test.classpath" that defines your test suite. Simulate Capture Agent Hardware (Release 0.5)
This document will help you simulate the capture process in lieu of capture hardware. Please refer to Capture Media from the Command-line to learn how to start, stop and submit media captures from the OSGi command-line. What about the real thing? Matterhorn 0.5 supports media capture on a specialized Linux-based hardware solution. We appreciate your patience while we work towards a more generalized solution.
The capture agent properties files, located at
capture.device.names=SCREEN,PRESENTER,MICROPHONE
capture.device.SCREEN.src=screen.mpg capture.device.SCREEN.outputfile=screen_out.mpg capture.device.PRESENTER.src=camera.mpg capture.device.PRESENTER.outputfile=camera_out.mpg capture.device.MICROPHONE.src=audio.mp3 capture.device.MICROPHONE.outputfile=audio_out.mp3
The preset media files are located in
Replace the Preset Media Files
1. Edit the capture agent properties file
capture.device.SCREEN.src=
All paths are currently relative to the preset media folder (see above).
Workflow Cookbook (Release 0.5)
Working with Workflows and the Conductor
Matterhorn is more than the sum of services that it offers. Being a lecture capture system, it is also about routing lecture recordings through the system from ingest to engage ui. This is where workflows get into the game.
Basically, a workflow definition consists of an ordered list of workflow operations. Each operation defines a single step within a workflow and can be either very simple or highly complex, depending on its implementation (see providing custom workflow operations). Working with Workflows and the Conductor Defining workflows Making workflow definitions available Providing custom workflow operations Creating and starting workflow instances Workflow configuration properties Modifying / extending workflows at runtime Specifying behaviour in case of failure Quick start
Most of the things described on this page can be tested on nightly. Defining workflows
XML definition
Let's start with an example:
What we see here is a definition for the soup-to-nuts workflow with a meaningful title and description as well as two operations, compose and distribute. The whole workflow will fail if the compose operation fails. However, we don't care wether distribute turns out well, too.
Workflow definitions can have as many operations as needed, operations can also be used multiple times.
On the fly definition
For most of the time you will define your workflows in xml files. However, it is possible to define and execute workflow definitions on the fly in your code. Let's look at the example:
String name = "compose"; String description = "Compose operation"; String exceptionHandler = "Default Error Handler"; WorkflowOperationDefinition operation = new WorkflowOperationDefinitionImpl(name, description, exceptionHandler, false);
WorkflowOperationDefinitionList operationList = new WorkflowOperationDefinitionListImpl(); operationList.add(operation);
String title = "Compose only"; String workflowDescription = "Workflow that executes encode"; WorkflowDefinitionImpl definition = new WorkflowDefinitionImpl(); definition.setTitle(title); definition.setDescription(workflowDescription); definition.setOperations(operationList);
For on the fly workflow definitions to work, you must first create all the operation definitions, then you put operations to the operation list in the right order and finally you create workflow definition and set all the parameters. After that you are ready to deploy this workflow definition.
NOTE: Operation name must correspond the name under which operation handler was registered (see Providing custom workflow operations).
Making workflow definitions available
There are two ways of making workflow definitions available in the system.
Definitions from the workflow service The first and probably easiest way is putting your workflow definition xml files one of the watcher directories (default one is ./load) and the Conduc tor service will load them and register them with WorkflowService. Then you can access them via the WorkflowService api method listA vailableWorkflowDefinitions() or getWorkflowDefinitionByName(String name).
WorkflowService workflowService = getWorkflowService(); WorkflowDefinitionList definitions = workflowService.listAvaliableWorkflowDefinitions();
NOTE: For definitions to get registered, filename must end with workflow.xml.
Ad-hoc definition
The second way is to do an ad-hoc definition. All you need to do is create the corresponding xml fragment in memory (or read it from disk/url/etc.) and then us the WorkflowBuilder as exported by the WorkflowService api to get an object representation:
InputStream is = new FileInputStream("soup-to-nuts.xml"); WorkflowDefinition soupToNutsWorkflow = WorkflowBuilder.getInstance().parseWorkflowDefinition(is);
From there, all you need to do is pass the workflow definition to the WorkflowService in order to have it executed (see creating and starting wokflow instances).
Providing custom workflow operations
If you want do define custom operations all you have to do is write a handler that implements WorkflowOperationHandler. It will contain method r un which will return WorkflowOperationResult (example below). Your new handler is then registered using declarative services and is started as part of your bundle (usually part of Conductor bundle).
public class GreeterWorkflowOperationHandler implements WorkflowOperationHandler {
public WorkflowOperationResult run(final WorkflowInstance workflowInstance) throws WorkflowOperationException {
System.out.println("Hello " + workflowInstance.getConfiguration("name"));
return WorkflowBuilder.getInstance().buildWorkflowOperationResult(workflowInsta nce.getCurrentMediaPackage(), null, false); } }
A GOOD PRACTICE: It is considered a good practice that any exception that might be thrown inside run method should be caught and Workflo wOperationException should be thrown. That way workflow can exit gracefully and special behaviour can be specified (see Specifying behaviour in case of failure).
This handler now needs registration with OSGi. This is done by simply putting the following code into a file in main/resources/OSGI-INF:
The operation will be announced as soon as your bundle starts and you can execute workflows with your new operation.
Creating and starting workflow instances
Starting a workflow involves getting hold (or putting together) a workflow definition with a list of operations, then calling the workflow service to have it executed.
WorkflowService workflowService = getWorkflowService(); WorkflowDefinition workflowDef = workflowService.getWorkflowDefinitionByName("test"); Map configurations = new HashMap
Workflow configuration properties
There are two ways to define workflow configuration properties:
Static configurations through workflow definitions
Each operation in workflow definition can have it's own set of predefined properties:
For the above example we decided that we want this operation to execute encoding with flash profile.
Configuration properties passed to WorkflowService when executing workflow
When you execute workflow you can pass configuration properties. Properties can be defined in one of two ways:
configurations.put("encode", "true");
or
configurations.put("compose/flash.http", "true");
First way is used for global properties. Every operation will see this property. If we want local properties we can specify them using second way. Before property name we put operation name and this property will be seen only in operations with matching name (compose in the example above). At the moment it is not possible to set up properties for individual operations with the same operation name (still todo).
Order of applying configuration properties
Since there are three different level of configuration properties (predefined, global and local) with possibly same names it is good to know the order by which properties are applied:
1. predefined configuration properties from workflow definition are loaded 2. local properties for matching operation are loaded possibly overwriting predefined properties 3. global configuration properties are loaded possibly overwriting local and predefined properties
Modifying / extending workflows at runtime
Once that workflow definitions are registered with WorkflowService you can modify them if they do not suit your needs any more. All you have to do is retrieve the desired workflow definition, get a list of its operations and then you can manipulate order, add or remove operations, etc... (all operations that apply to LinkedList are available) Here is a simple example:
WorkflowDefinition definition = workflowService.getWorkflowDefinitionByName("Transcode, Distribute and Publish"); WorkflowOperationDefinitionList operationList = definition.getOperations(); operationList.remove(1);
In the example above we retrieved workflow definition "Transcode, Distribute and Publish" which contains compose, distribute and publish operations. Then we retrieved operation list and removed the second operation (distribute). NOTE: Keep in mind that after definition is changed it will stay changed so it may suit your needs better to just create new workflow defintion based on the old one.
Specifying behaviour in case of failure
Each operation have two properties that specify behaviour when exception occurs. Those properties are fail-on-error and exception-han dler-workflow.
Here is the example of operation with those properties defined:
When workflow operation fails we might want to take specific actions for instance cleaning any temporary data that might have been left or writing to the log file that exception has occurred, etc. You can do that with specifying the workflow that will be executed if exception occurs. In our case we specified Default Error Handler which just logs the exception.
When exception occurs we can specify what happens after exception handler workflow is executed. If operation was critical we can specify fail- on-error="true" (as in example above), and workflow will be marked as failed. If we don't really care if operation was successful or not we specify fail-on-error="false" and execution of this workflow will continue. Default value is false.
Quick start
This section is intended for those of you who would like to quickly start using services that are provided via WorkflowService without digging through more complex aspects and options. For additional information you can always check out the Working with Workflows and the Conductor s ection or WorkflowService documentation.
Our aim is to write a simple operation handler that writes a person's name in console, use this operation handler in our custom workflow definition and then execute this workflow. Since we are working with WorkflowService, your bundle must have access to the WorkflowService API. So let us begin.
Creating custom operation handler
First we will create our custom operation handler. This operation handler will display 'Hello
Let's create a new java class and name it GreeterWorkflowOperationHandler which implements WorkflowOperationHandler interface available from WorkflowService API. You will see that you have to implement method WorkflowOperationResult run(WorkflowInstance workflowInstance) throws WorkflowOperationException.
For beginning you will add this line at the end:
return WorkflowBuilder.getInstance().buildWorkflowOperationResult(workflowInsta nce.getCurrentMediaPackage(), null, false);
This line will build WorkflowOperationResult where we pass 3 arguments:
MediaPackage mediaPackage: MediaPackage instance that will be sent to next operation's handler Map
Because we will not work with MediaPackage in this tutorial, we just pass on the current MediaPackage with no additional properties. Also our handler will not require any outside handling so we set wait argument to false. So now you should have code that looks like this:
public class GreeterWorkflowOperationHandler implements WorkflowOperationHandler {
public WorkflowOperationResult run(WorkflowInstance workflowInstance) throws WorkflowOperationException {
// Put your operation's handler code here
return WorkflowBuilder.getInstance().buildWorkflowOperationResult(workflowInsta nce.getCurrentMediaPackage(), null, false); } }
Our operation handler will display 'Hello
To access operation's properties the getConfiguration(String key) method is used:
String name = workflowInstance.getConfiguration("name")); if(name != null) System.out.println("Hello " + name); else System.out.println("Hello stranger");
We retrieve the configuration with identifier 'name' and 'Hello
Now that we have our new operation handler, we just have to register it with OSGi so that WorkflowService will be able to use it. Let's create new directory under OSGI-INF called operations and we create greeter-operation.xml file with something like this:
There are three things to note:
1.
The last thing to do is to modify project's POM file so that our workflow operation handler will get registered. We add the following line under
OSGI-INF/operations/greeter-operation.xml
Creating custom workflow definition
Now that we have our new operation handler it is time to create workflow definition that will make use of it. We create new directory under src/main/resources called workflows. In this directory we create new xml file called greeter-workflow.xml.
For the beginning we will put the following code inside our new file:
Title of our workflow will be 'Greeter workflow'. Name should be meaningful since this name is used to get a hold on the workflow if you decide to register it with WorkflowService (for more information see Making workflow definitions available). In description section we describe what this workflow will do, so all we have to do now is put some actual operations inside it.
We will define only one operation and this will be our greet operation:
As you noticed operation name is the same as the one used when registering operation handler. Fail-on-error and exception-handler-w orkflow properties are used for error handling for which are not important for this tutorial (those who would like to know more: Specifying behaviour in case of failure).
Load and register your workflow
Now that we have operation and our workflow definition in place it is time to register it with the WorkflowService. The following code will be put to the bundle Activator class or activate method inside your service if you are using declerative services.
To parse and register our workflow definition we will use those two methods:
1. parseWorkflowDefinition(InputStream stream) from WorkflowBuilder 2. registerWorkflowDefinition(WorkflowDefinition definition) from WorkflowService
First we have to create new WorkflowDefinition from file. This is done like this:
InputStream greeterWorkflow = WorkflowtestServiceImpl.class.getClassLoader().getResourceAsStream("/wor kflows/greeter-workflow.xml"); WorkflowDefinition newDefinition = WorkflowBuilder.getInstance().parseWorkflowDefinition(greeterWorkflow);
We first obtain the stream and then parse our workflow definition with a WorkflowBuilder. Now that we have our workflow definition we will register it with WorkflowService so it can be retrieved by it's name any time we need it.
workflowService.registerWorkflowDefinition(newDefinition);
Now that our greeter workflow is registered you can start using it. Here is the whole code of what we did in this section: public void activate(ComponentContext componentContext){ // load your workflow try{ InputStream greeterWorkflow = WorkflowtestServiceImpl.class.getClassLoader().getResourceAsStream("/wor kflows/greeter-workflow.xml");
workflowService.registerWorkflowDefinition(WorkflowBuilder.getInstance() .parseWorkflowDefinition(greeterWorkflow)); } catch (Exception e){ throw new RuntimeException(e); } }
Retrieving workflow definitions and deploying them
At last we are ready to deploy our new workflow definition. We will create a method deployGreeterWorkflow where the code for executing greeter workflow will be.
First step is to retrieve workflow definition. This is done by calling a WorkflowService method getWorkflowDefinitionByName(String name). Since our workflow name is 'Greeter workflow' our call will look like this:
WorkflowDefinition greeterWorkflow = workflowService.getWorkflowDefinitionByName("Greeter workflow");
Next step is to get a MediaPackage. If you don't have one you can create an empty one like this:
MediaPackage mp; try { mp = MediaPackageBuilderFactory.newInstance().newMediaPackageBuilder().create New(); } catch (org.opencastproject.util.ConfigurationException e) { throw new RuntimeException(e); } catch (MediaPackageException e) { throw new RuntimeException(e); }
Last step is creating HashMap with properties. This is optional step but if you remember from beginning when we were creating greeter operation handler, we checked for property named 'name':
HashMap
Now that we have all the parts in place we are ready to actually start the workflow. To start it you just execute the following code: workflowService.start(definition, mp, configurations);
The whole method looks like this:
public void deployGreeterWorkflow(){
WorkflowDefinition greeterWorkflow = workflowService.getWorkflowDefinitionByName("Greeter workflow");
MediaPackage mp; try { mp = MediaPackageBuilderFactory.newInstance().newMediaPackageBuilder().create New(); } catch (org.opencastproject.util.ConfigurationException e) { throw new RuntimeException(e); } catch (MediaPackageException e) { throw new RuntimeException(e); }
workflowService.start(definition, mp, configurations); }
You can call your method for executing greeter workflow for example through your REST endpoint and you should see 'Hello John Smith' in the command line.
For the end
I hope that this tutorial gave you a decent knowledge how execution of workflow definitions work and the basic use of WorkflowService. For more information about specific topic you can check out Working with Workflows and the Conductor or WorkflowService documentation.
There are couple of things left to mention: although we registered your operation handler and workflow definition through your own bundle this is primarily Conductor's job and new operation handlers should be added through Conductor. For registering workflow definitions it is enough to put them in the one of the watcher's directories (see Making workflow definitions available). Release 0.5 FAQ
HARDWARE
What hardware requirements are needed to run 0.5?
If you are running Matterhorn's virtual machine distribution, your hardware must meet the requirements specified by the VMware player app for Windows/Linux or the VMware Fusion for Mac. More specifically, "a 1 GHz or faster processor (2GHz recommended) and 1GB RAM minimum (2GB RAM recommended). You must have enough memory to run the host operating system, plus the memory required for each guest operating system and for applications on the host and guest. See your guest operating system and application documentation for their memory requirements. VMware Player requires approximately 150MB of disk space to install the application."
See Matterhorn Basecamps virtual machine setups for reference infrastructure.
If you install and build Matterhorn locally, there are currently no recommended requirements.
What should I use as a capture agent?
Matterhorn recommends the following specifications. Using capture infrastructure outside of these recommendations will likely involve modification to the capture installation scripts. You may also use Matterhorn's demo capture agent if you do not have a real capture agent available. The demo capture agent is pre-installed and will appear in the scheduling UI's agent pulldown as demo_capture_agent. NOTE: the capture agent will submit canned metadata and media regardless of what is entered in the scheduling UI. INFRASTRUCTURE
Can I run 0.5 on my local machine?
Matterhorn can be run in its entirety on one local machine through either a vm or by installing and building Matterhorn locally.
Can I run it on 0.5 in a virtual environment?
Yes. You can run a Matterhorn virtual machine using VMware player app for Windows/Linux and VMware Fusion for Mac. The free, cross-platform player VirtualBox may also be an option but Matterhorn has not been tested on this player yet.
SOFTWARE
Where can I see a demo of Matterhorn?
You can either run Matterhorn by running your own virtual machine, building it locally, or requesting a virtual environment from one of the Matterh orn Basecamps.
What operating system is required to run Matterhorn?
Ubuntu is the only operating system officially supported for 0.5, but in subsequent releases Red Hat, OSX, and likely other operating systems will be supported. Unofficially it works fine on OSX Snow Leopard. The virtual machine runs Ubuntu but it can be hosted on a variety of operating systems.
What third party tools are needed?
Some components of Matterhorn may require or be enhanced by other software ("3rd Party Tools") or hardware that is distributed or packaged in a method that may legally require licensing from patent holders. These 3rd Party Tools are not provided in Matterhorn releases, and using Matterhorn does not grant you implicit or explicit rights to patents or trademarks used by these tools. For 0.5, you will need the 3rd party tools mediainfo and ffmpeg to successfully use the encoding service. Matterhorn scripts will be available to install these tools on the VM or in a local build. You may encounter 3rd party tool installation glitches on operating systems other than OSX and Ubuntu. Please report any issues.
SKILLS
What do I have to know in order to install 0.5 out of the box?
In order to run the virtual machine to preview Matterhorn's features, you need to be a moderately technical person but you do not need to have any system administration or programming skills. See Install a Virtual Machine for more information.
If you want to install Matterhorn from source, test its services, or customize its components you need to know svn, Java, and javascript skills for the front end. Knowledge about maven is a plus but not necessary.
DOCUMENTATION
How do I install Matterhorn?
You can install Matterhorn using the Virtual Machine or building from source.
What do I have to know if I would like to customize 0.5?
Customization of Matterhorn 0.5 is fairly limited. You can change the order of operations in a workflow , capture agent service, specify paths for service binaries, rss/atom feeds, etc. The current documentation for configuration is still in progress, but you can find paths to config files here.
SUPPORT
Where can I get support for installing 0.5?
If you need help installing Matterhorn, we have provided several communication channels:
The Opencast Community List is a great place to ask installation questions, general questions about Matterhorn's features, or anything else related to Matterhorn. To get started just subscribe to the [email protected] mailing list and send out an email. You'll find many people there happy to help you. The IRC chat group #opencast on irc.freenode.net is by developers to communicate about low level technology issues. This group is an excellent place to ask specific technical questions or to get immediate help on something that is blocking you.
Where can I post feedback/issues/bugs?
Feature requests and bugs may be entered at http://opencast.jira.com. When entering a new feature request choose the issue type "Community Feature Request". Do not assign the task and make sure the fix version is "Release 0.5 Final".
When entering a new bug, please try to first see if a similar bug has been entered already, and choose the issue type "bug". Please assign the task to Nils Birnbuam and make sure the fix version is "Release 0.5 Final".
How do I submit patches to Matterhorn?
Feel free to fix bugs or submit new features. Attach a patch to the relevant task and reassign the task as blocker to the release manager, Manjit Trehan, who will then merge/commit code and resolve the task. Simple instructions on how to create a patch are available http://strasheela.sourceforge.net/strasheela/doc/HowToCreateAPatch.html.
FUNCTIONALITY
Do I need dedicated distribution servers?
No. 0.5 runs on one machine. In subsequent releases, Matterhorn will support distributed setups.
Do I need a capture agents?
Yes and No. Matterhorn comes out of the box with a demo capture agent. If you just want to review how the scheduler functions, the demo capture agent should be sufficient. If you are interested in setting up
What media can I ingest?
Matterhorn supports all of the codecs supported by ffmpeg primarily dervice by libavcodec.
Which video formats and codecs are supported for uploading to Matterhorn?
We do not have any official list of supported formats, but alot of them are supported! Whatever ffmpeg can do, Matterhorn can do because it uses ffmpeg as its primary reference implementation for its Composer Service.. In future releases Matterhorn will support other encoding engines, so eventually the answer will be whatever your encoding engine supports. Once you download Matterhorn's 3rd party tools, if you run "ffmpeg -codecs" and "ffmpeg -formats" you'll get a listing of supported codecs and formats.
Why do I lose my data after I reboot the Virtual Machine?
By default, Ubuntu deletes the contents of /tmp during a reboot, regardless of the age of files. Please note that your data will be lost during a reboot. This behavior can be changed by appropriately modifying the setting described in the following tutorial.
Changing the tmp cleanup frequency
TIMELINE
When is 1.0 due?
Matterhorn 1.0 will be released end of June 2010.
LICENSE
What license does Matterhorn use?
Matterhorn uses the Educational Community License 2.0 (a variant of the Apache license). A list of licenses compatible with ECL 2.0 is available. Some components of Matterhorn may require or be enhanced by other software ("3rd Party Tools") or hardware that is distributed or packaged in a method that may legally require licensing from patent holders. These 3rd Party Tools are not provided in Matterhorn releases, and using Matterhorn does not grant you implicit or explicit rights to patents or trademarks used by these tools.
ACCESSIBILITY
Is Matterhorn accessible?
Matterhorn's engage media player is WCAG 2.0 compliant. It supports keyboard navigation and works well in most modern screen readers. It also uses ARIA tags. In future releases, Matterhorn will support many different caption formats for multiple distributions. Release 0.5 Install and Configure
These documents will help you get Matterhorn up and running locally.
Source Content by label
There is no content with the specified labels
Virtual Machine
Content by label
There is no content with the specified labels
Configuration
Content by label
There is no content with the specified labels
Configure Matterhorn Port Number and Base URL (Release 0.5)
This document presents two ways to change the port number as well as the base URL on which the Matterhorn HTTP service runs.
Change the Port Number
Felix
1. Create a file named
# OSGi HTTP services port org.osgi.service.http.port=80
root access is required in order to run on Port 80.
Apache HTTPD Proxy
1. Edit Apache's httpd.conf 1.
ProxyPass / http://localhost:8080/ ProxyPassReverse / http://localhost:8080/
Change the Base URL
1. Edit
# Base URL (for example http://matterhorn1.telavivuniv.org:80) serverURL=http://matterhorn1.telavivuniv.org
Capture Service Configuration (Release 0.5)
This document describes the configurable properties for the Matterhorn capture agent service.
Parent Configuration File
name capture.config.url
description Location of configuration file
name capture.config.polling.interval
description Polling interval
name capture.config.cache.url
description Location of configuration cache
name capture.config.filesystem.url
description
Local Filesystem
name capture.filesystem.config.url
description Location of configuration file
name capture.filesystem.capture.url
description Location of capture folder
name capture.filesystem.cache.url
description Location of cache folder
name capture.filesystem.volatile.url
description Location of temp folder
name capture.filesystem.cache.capture.url
description Scheduler
name capture.schedule.url
description Location of schedule service
name capture.schedule.polling.interval
description Polling interval
name capture.schedule.cache.url
description Location of schedule cache
Agent Description
name capture.agent.name
description Name
name capture.agent.state.endpoint.url
description Location of state service
name capture.agent.state.polling.interval
description Polling interval
Recording Description
name capture.recording.state.endpoint.url
description Location of state service
name capture.recording.id
description ID
name capture.recording.root.url
description Location of recording(s) folder
name capture.recording.end
description Time of recording completion
Ingest
name capture.ingest.endpoint.url
description Location of ingest service
name capture.ingest.retry.interval
description Polling interval
Device Description(s)
Device properties are configured using prefix + device name + device property (e.g. capture.device.SCREEN.codec.properties.codec. properties.bitrate).
name capture.device.names
description CSV format name capture.device.
description Prefix
name capture.device.
description Location of recording file or device file (e.g. /dev/video0)
name capture.device.
description Device stream filename
name capture.device.
description Device codec
name capture.device.
description Device codec bitrate
Local Filesystem Cleaner
name capture.cleaner.mindiskspace
description Minimum diskspace threshold
name capture.cleaner.maxarchivaldays
description Maximum time threshold
Filenames
name capture.stopped
description Capture filename
name capture.ingested
description Ingested capture filename
name media.zip
description Ingested capture archive filename
Create a Virtual Machine (Release 0.5)
USING VMWARE FUSION
Download and save Ubuntu Server ISO from http://www.ubuntu.com/getubuntu/download-server In Fusion choose File -> New Click "Continue without disk" Choose the option "Use Operating System Installation disc image file" Navigate to the saved ISO Continue... Verity that the OS and Version say "Linux" and "Ubuntu", respectively Deselect "Use easy Install" Click "Customize Settings" Enter a name for your VM In the settings, choose the following settings: Network: NAT CPU: 1 Memory: 1GB (at least) Disk: 8GB (at least) Continue to boot the VM Click in the VM window. NOTE: This will connect the mouse to the VM. To recover mouse for the host machine, press ctrl-command (the ctrl and command keys) During OS installation click F4 and choose minimal install Configure Matterhorn Feed Catalog (Release 0.5)
This document will help you understand and configure the Matterhorn RSS and Atom feed catalog. The catalog supports multiple versions of each syndication format.
Access the Feed Catalog
The catalog is located at:
http://
Individual feeds are located at:
http://
Default Feeds
The catalog contains the following default feeds:
Latest
http://nightly.opencastproject.org/feeds/[atom|rss|*]/
Need an example? http://nightly.opencastproject.org/feeds/atom/0.3/latest
Series
http://nightly.opencastproject.org/feeds/[atom|rss|*]/
Aggregation
http://nightly.opencastproject.org/feeds/[atom|rss|*]/
This feed is currently hard-coded to aggregate the first and second series.
Custom http://nightly.opencastproject.org/feeds/[atom|rss|*]/
What's the query syntax? The custom search query is a lucene query, matched again Java's MessageFormat using solr. One could specify:
The feed would be available at http://
Customize the Feed Catalog
The Matterhorn feed specifications are located in:
Below is the default specification for a feed of the latest published episodes:
Feed Properties
The following properties are shared by all feed specifications:
Name feed.uri
Description The feed location/identifier
Name feed.selector
Description The feed route pattern (e.g. latest)
Name feed.name
Description The feed title
Name feed.description
Description The feed description
Name feed.copyright
Description The feed copyright notice Name feed.home
Description The feed catalog homepage (e.g. http://www.opencastproject.org)
Name feed.selector
Description The feed route pattern
Name feed.cover
Description The feed image
Name feed.rssflavor
Description The RSS enclosure route pattern (e.g. engage/rss)
Name feed.atomflavor
Description The Atom enclosures route pattern (e.g. engage/atom)
Name feed.rsstags
Description A comma, semi-colon or space-separated list of tags used to filter available enclosures
Name feed.atomtags
Description A comma, semi-colon or space-separated list of tags used to filter available enclosures
Name feed.entry
Description The route pattern used to generate links to individual enclosures (e.g. /engage/ui/watch.html?id={0})
Register a Capture Agent (Release 0.5)
This document will help you register a Matterhorn capture agent with the capture administration user interface.
1. Register the agent a. Post the agent name and state to the capture administration service.
curl --data state=
b. Check the response
2. Verify that the agent is registered a. Get the list of known agents
http://nightly.opencastproject.org/capture-admin/rest/agents
b. Check the response 2.
b.
Possible values for
IDLE CAPTURING UPLOADING UNKNOWN
Overview of Configuration Files (Release 0.5)
This document will help give an overview of the existing Matterhorn configuration files and their roles.
This document is currently no more than a list, but will eventually become a true overview.
Capture Service opencast-capture-service-impl
./src/main/java/resources/config/
name calendar_polling_scheduler.properties
description
name capture.properties
description
name capture_scheduler.properties
description
name ingest_scheduler.properties
description
name state_update_scheduler.properties
description
Media Composer Service opencast-composer-service-impl
./ name encoderengines.properties
description
name encodingprofiles.properties
description
name episode.properties
description
name episode.properties
description
Conductor Service opencast-conductor
./src/main/java/resources/workflows/
name compose-distribute-publish.xml
description
name default-error-handler.xml
description
Database Service opencast-db
./src/main/java/org/opencastproject/db/
The Activator.java file contains the database path, url and login.
Scheduler Service opencast-scheduler-impl
./src/main/java/resources/config/
name captureagentmetadatamapping.properties
description
name dublincoremapping.properties
description
Search Service opencast-search-service-impl
./src/main/java/resources/solr/conf/
Stream Service opencast-stream
./src/main/java/resources/
name access.properties
description
name password.properties
description Install Source (Release 0.5)
This document will help you install and run Matterhorn from the source code. If you want to preview Matterhorn then it is running at http://nightly.o pencastproject.org/.
Windows Users Matterhorn is having problems building on Windows. Please see this Jira filter for more information. Environment variables: To Add (or edit) environment variables (Control Panel -> System -> Advanced -> Environment variables) or use "set" instead of export like so: set MAVEN_OPTS="-Xms256m -Xmx512m" Spaces in paths: Windows XP users should ensure they do not have spaces in the paths to matterhorn, maven repository, and felix. It may fail to run if there are spaces in the paths.
OSX 10.5 Opencast recommends you install the Mac OS X Developer Tools 1. Open the Mac OS X installation disc. 2. Go into "Optional Installs" folder and run the Xcode.mpkg file.
1. Install Java 1.6 or higher
Note: Mac OSX 10.6 will have Java 1.6 installed by default
1. a. To check: Run java -version on the command line b. If not correct, download the J2SE SDK from: http://java.sun.com/javase/downloads/widget/jdk6.jsp c. Install it (the SDK) to /opt/java Note: Install the JRE to a different directory (probably the default, especially under windows) or you will have problems d. Set environment variable: JAVA_HOME=/opt/java Mac users: JAVA_HOME=/Library/Java/Home Windows users default: JAVA_HOME=C:\j2sdk1.6.0_xx (where "xx" is the minor version - for example "j2sdk1.6.0_11") e. Add $JAVA_HOME/bin to PATH
2. Setup Maven 2.0.6 or higher
Maven - http://maven.apache.org/
Note: Mac OSX 10.6 will have maven 2.2.0 installed by defaultNote: Mac OSX 10.5 will have maven 2.0.6 installed by default
1. a. Download Maven 2 (minimum 2.0.6) - http://maven.apache.org/download.html b. Extract to /opt (should create maven-2.X.X folder, where X.X is the sub version) c. Set environment variable: MAVEN2_HOME=/opt/maven-2.X.X d. Add $MAVEN2_HOME/bin to PATH\ e. Set the MAVEN_OPTS environment variable
MAVEN_OPTS='-Xms256m -Xmx960m -XX:PermSize=64m -XX:MaxPermSize=150m'
Windows: XP users have to change the location of their local repository since its path contains spaces (since it is in the user home directory by default). To change the location go to
3. Setup Subversion 1.5 or higher
Subversion - http://subversion.tigris.org/
Note: Mac OSX 10.6 will have svn 1.6.5 installed by default Note: Mac OSX 10.5 will have svn 1.5 installed by default
1. a. To check: Run svn --version on the command line http://subversion.tigris.org/project_packages.html Get the subversion binaries and not the source, if possible If there are no binaries for your platform, get the source and use the configuration options --with-ssl and --with-libs b. Extract to /opt (should create subversion-1.5.5) Windows users will want to rename the extracted directory Unix users will probably want to use a package for their flavor c. Set environment variable: SUBVERSION_HOME=/opt/subversion-1.5.5 d. Add $SUBVERSION_HOME/bin to PATH 4. Get Matterhorn source
Matterhorn svn repository: http://source.opencastproject.org/svn/products/matterhorn/tags/0.5/
1. a. Create a directory to hold the source and your matterhorn install called matterhorn (referred to as MATTERHORN_HOME)
mkdir /opt/matterhorn cd /opt/matterhorn
b. Checkout matterhorn release 0.5 into the matterhorn_rev5 dir (referred to as MATTERHORN_SRC) in the MATTERHORN_HOME dir
svn checkout http://source.opencastproject.org/svn/products/matterhorn/tags/0 .5/ matterhorn_rev5
5. Setup Apache Felix OSGi
Apache Felix - http://felix.apache.org
NOTE: These instructions are for Apache Felix. Other OSGi implementations include Equinox and Knopflerfish. Matterhorn is tested on Felix but should work on any modern 4.1 compatible OSGi implementation.
1. a. Make sure you are in the MATTERHORN_HOME dir
cd /opt/matterhorn
b. Download the latest binary release of the "Felix Framework Distribution" http://felix.apache.org/site/downloads.cgi (probably version 2.0.1 or higher) c. Extract the archive in the MATTERHORN_HOME dir and rename the directory to felix
tar -xvf felix-framework-2.0.1.tar.gz mv felix-framework-2.0.1 felix
d. Create the felix load directory
mkdir felix/load
e. Copy over the felix configuration files to the felix conf dir
cp -r matterhorn_rev5/docs/felix/conf/* felix/conf/
NOTE: Remember to check for revisions to the Felix configuration files with each update of Matterhorn. If you are unsure whether the file has been updated, it is safest to simply copy them over each time.
6. Copy run scripts and setup environment
These scripts setup your environment correctly to execute the matterhorn runtime using the felix OSGi container
1. a. Make sure you are in the MATTERHORN_HOME dir
cd /opt/matterhorn
b. Copy the matterhorn run scripts into the current directoy (bat files for win or sh files for unix/OSX) 1.
b.
cp matterhorn_rev5/docs/felix/bin/*.sh .
NOTE: You may need to make the script executable: chmod a+x start_matterhorn.sh c. Add the following environment variables
export FELIX_HOME=/opt/matterhorn/felix export M2_REPO=~/.m2/repository
NOTE: If the "export" command doesn't work for you, use the equivalent command in your shell, or type "bash" to switch to a bash shell. NOTE: You could also edit the matterhorn start script but the recommended method is to setup the environment variables so the script picks up the changes d. Load the environment variables into the shell by closing the shell and opening a new one, or running:
source ~/.bash_profile
7. Build matterhorn
1. a. Make sure you are in the MATTERHORN_SRC dir
cd /opt/matterhorn/matterhorn_rev5
b. Build the source using maven
mvn clean install -DdeployTo=/opt/matterhorn/felix/load
Windows: Matterhorn does not yet build without test errors on Windows so in order to build Matterhorn -Dmaven.test.skip= true is specified. Instead of -Dmaven.test.skip=true you can also set -Dmaven.test.error.ignore=true and -Dmav en.test.failure.ignore=true to see which tests fail. NOTE: The Matterhorn project components will be deployed to the load directory of your Apache Felix instance. Felix will automatically reflect any changes made to this directory, even during runtime. Remember to delete everything in the felix/load directory before rebuilding Matterhorn. Maven does not delete previously built bundles when redeploying.
8. Install the 3rd party tools
Windows: The windows install for the runtime tools is much more complex and is documented here
Linux: Linux users will need ant, xml-commons-apis, zlib-devel or zlibig-dev, patch, byacc and pkgconfig. Linux users having difficulty building libmediainfo can download a binary version.
1. a. Go to the runtime tools dir (in the MATTERHORN_SRC dir)
b. cd opencast-runtime-tools
c. Build the runtime tools
sudo mvn install -Dthirdparty
NOTE: Admin access required: When the sudo command is used, you will need to enter your computer's operating system password.NOTE: Firewall rules: For licensing and patents reasons, the installer gets FFmpeg sources from their subversion repository, which means that you need to have outgoing access to port 3690
9. Configure Matterhorn
1. Matterhorn has a number of configuration options which you can generally leave at defaults for development purposes but it is important to be aware of them 1.
Overview of Configuration Files Configure Matterhorn Port Number and Base URL Configure Matterhorn Feed Catalog Capture Service Configuration
10. Run Matterhorn
1. a. Execute the run matterhorn script from your MATTERHORN_HOME dir
./start_matterhorn.sh
b. Wait for the logs to stop scrolling past at high speed (should take 30 secs to 1 min depending on your machine) c. Open http://localhost:8080 in your favorite web browser to test things are working NOTE: You can access the Felix system console at http://localhost:8080/system/console (user:admin, pw: admin)
11. Update Matterhorn source
After you have installed Matterhorn source code, you may want to periodically update to the latest revision if you are working with the trunk
1. a. run the svn update command from
This document will help you install and configure a Matterhorn virtual machine.
Setup
1. Make sure you have a working internet connection. 2. Install & run VMWare or use VirtualBox (untested and some directions below may not apply) Mac: http://www.vmware.com/products/fusion/ (get the 30 day trial version - we don't have a license for folks available at this time) PC: http://www.vmware.com/products/player/ (free) 3. Download the Matterhorn-VM-0.5.zip, and unzip it. 4. Double click on the .vmx file. 5. Choose "I copied it." 6. You may see a message on your console saying "VMWare Tools is not installed," but you can ignore this. A black console will appear. It may take up to a minute for it to load.
Your mouse will not work in the VMWare window. Follow the directions or use CMD-tab (Mac) or Alt-tab (PC) to leave the VMWare window. You can ssh into your VM (ssh matterhorn@
7. Enter user name: matterhorn, password: opencast. 8. Press enter when you see "To set up a proxy server, please enter the URL or press enter []?" (unless you have reason to do otherwise) 9. Say "y" or "n" as to whether you would like to reconfigure the keyboard unless you prefer another configuration. 10. Say "y" you would like to install third party tools. 11. Say "y" you would like to install ffmpeg. 12. Enter the password (opencast) again. 13. All these things will be installed--this takes about 15 minutes. 14. If your console goes blank, click somewhere in the console window to make sure that's the active window and press a non-printing key. (NOTE: If the console is waiting for user input, pressing return will awaken the screen and send a return to the console. On the Mac, I just press the command key.) 15. After everything finishes installing, type the URL at "Matterhorn cosole (should say "console") is at http://xxx.xxx.xxx.xxx:8080" into a browser (you can't copy it)--this is your VM instance. Make sure not to press return too many times as you may move this line outside of view in the console. If you do, either shut down and restart the VM, or enter "sudo reboot" into the console so that you can see the URL again.
Need to tweak something? Use ctrl-z to interrupt the setup script. Not seeing "demo_capture_agent" when you go to Schedule Recording? You need to delete /opencast content to get a registered agent. While this should be fixed in RC3, if you still have a problem enter "rm -rf /opencast/*" and then restart your vm
Want a clean UI? If you want to remove old data and have a clean interface delete everything in "/var/lib/matterhorn/work/opencast" or restart your Mattehorn instance.
Shutdown
Go to the VMWare menu and choose: Mac: Virtual Machine -> Shut Down Windows: VM -> Power -> Power off Command line: sudo /sbin/shutdown -h 0 (NOTE: This may prompt for password [opencast])
Startup again
Click on the VMWare player icon/link on your machine, and open the Matterhorn VM instance.
Setup a virtual capture agent
Go into the VM Console and type: curl -d state=$STATE http://$HOST:8080/capture-admin/rest/agents/$NAME Replace $STATE and $NAME with any value you desire, and $HOST with the HOST to your VM instance. Example: curl -d state=online http://$www.mysite.com:8080/capture-admin/rest/agents/$camera1
Accessing the VM from outside of the host machine
This is accomplished via Port Forwarding. Port forwarding allows outside clients to connect to the VM via the host machine's IP address. Any traffic coming in on the specified port directed to the host machine is passed on to the VM. NOTE: Felix configuration (/etc/matterhorn/config.properties) would also need to be updated to replace all occurrences of the guest VM's IP number with the host machine's IP number. Instructions for Windows Instructions for MacOS X Windows 3rd Party Tools Installation (Release 0.5)
Installing the 3rd Party tools for Windows
1. Media Tools a. MediaInfo 0.7.19 i. Download binary from SourceForge. ii. Expand the archive b. ffmpeg r20641 Great tutorial for ffmpeg for windows can be found here: FFMpeg on Windows.
1. a. i. For building ffmpeg you will need 7-zip or similar command line archiver that can work with tar.gz and tar.bz2 archives ii. Ffmpeg can not be build in native windows enviroment so msys + mingw will be set to compile requred libraries and ffmpeg from source iii. You will need to download the following packages: binutils-2.19.1-mingw32-bin mingwrt-3.15.2-mingw32-dll mingwrt-3.15.2-mingw32-dev w32api-3.13-mingw32-dev gcc-core-4.2.1-sjlj-2 gcc-g++-4.2.1-sjlj-2 MSYS-1.0.11 coreutils-5.97-MSYS-1.0.11 msysDTK-1.0.1 msysDVLPR-1.0.0-alpha-1 m4-1.4.12 autoconf-2.63 automake-1.10.2 libtool-1.5.26 iv. Copy M4-1.4.12-MSYS.diff, faad2-2.6.1.patch, install_ffmpeg.sh, msysDVLPR.sh and setup_msys.b at from
Adjusting package manager and msys installation location properties Default archiver is 7-zip located in C:\Program Files\7-Zip\7z.exe. If your path is different or you are 1. a.
iv.
using different command line archiver you should adjust ARC_BIN, ARC_OPT and ARC_DEST_OPT in setu p_msys.bat. If you would like to change location of your msys installation you will have to adjust MSYS_PATH in setup_msys.bat and MSYS_PATH in msysDVLPR.sh.
v. Execute setup_msys.bat vi. After seting up your msys environment, msys setup will launch. Installation path is
./msysDVLPR.sh
x. After script is finished you can close CMD and go to: Start menu -> All Programs -> MinGW -> MSYS -> MSYS. Another CMD will open. Execute install_ffmpeg.sh
./install_ffmpeg.sh
xi. Script will install ffmpeg to
composer.ffmpegpath =
Road Map Error formatting macro: gliffy: java.lang.NullPointerException Unknown macro: {alias} Unknown macro: {alias} Unknown macro: {alias}
Q1 Overview | Q2 Overview | Q3 Overview | Q4 Overview | By Iteration (Detail) | Release 1.0 Parking Lot Q1 Overview Dates: August - October 2009
User Stories: High Level Scenarios:
Summary: At the completion of Quarter 1, Mattherhorn will offer a basic "round trip" from capture and ingest through processing to distribution. The user interfaces will lack polish, the service contracts will be incomplete, and the service implementations will be partially completed, but the system will support the necessary functionality to schedule automated recordings for processing and distribution. For example, the capture appliances will consume ical but instead of executing capture, they will send a canned media package. The services and user interfaces will be continually refined in subsequent quarters.
Primary Goal: "glue" all the baseline services together and integrate clients such as the capture agent and the admin interfaces.
Key Deliverables:
Matterhorn baseline services: MediaIngestService, MediaComposerService, MediaInspectionService, LocalDistributionService, CaptureAgentService, SchedulingService, FeedDistributionService, SiteConductorService, WorkflowService, SearchService Admin user interface for the manual ingest of media and metadata. Admin user interface for the creation of individual recording schedules. Learner user interface to view list of distributed media as well to watch individual audio/video (accessible media player). Capture agents consume a schedule and ingest a demo scheduled recording. Distribution to a local directory. This directory resides in a web server.
Q2 Overview Dates: November 2009 - January 2010
User Stories: High Level Scenarios:
Summary: At the completion of Quarter 2, Matterhorn will offer a baseline feature set for release 0.5 to show case its capabilities to potential adopters. At this stage Matterhorn will be far from complete, but it should provide interested parties a sense of its basic offerings. The feature set will cover simple "confidence" monitoring of a recording from capture through the processing pipeline. The administrator will be able to schedule and capture individual and recurring recordings. Once capture and/or ingest is initiated, the administrator will be able to follow the media's life cycle and determine its high level status as it makes its way from a capture appliance or ingest UI to distribution. Once the media has been distributed, the learner will be able to search videos by keyword, view videos with captions, as well as subscribe to rss feeds.
Primary Goal: test and package a stable Matterhorn 0.5 release.
Key Deliverables:
Admin user interface for the editing of individual recording schedules. Capture agents capture media feeds and ingest recording. Learner user interface to view captions, search videos, and subscribe to rss. Simple job monitoring prototype (developer tool, but will evolve into admin UI in Q3) Capture agent status user interface. Configuration capabilities Release 0.5 installation package and documentation. Likely vm ware image as well as documentation to install and configure manually. Q3 Overview Dates: February - April 2010
User Stories: High Level Scenarios:
Summary: At the completion of Quarter 3, Matterhorn will refine its baseline feature set, expand interactive capabilities for learners, incorporate caption format transformation/injection, and support delivery to iTunes U, Youtube as well as "local embeds". At this stage, Matterhorn will support a "media analysis" service, which will automatically index keywords from the video to allow for in video search as well as slide change detection. A "hold" feature will be introduced to allow administrators to submit captions or make offline edits before the media is submitted for processing and distribution. Administrators will be able to manually import an existing recording schedule (icalender), or configure Matterhorn to use an external icalender source for scheduling recordings. The "local embeds" feature will allow the embed of individual media to a blog and other environments that support embeds. The embeds will also be exposed in rss feeds for simple integration with Learning Management Systems.
Primary Goal: establish stable service contracts.
Key Deliverables:
Sophisticated administrative dashboard UI for the monitoring and management of the media's life cycle. Refined capture monitoring user interface Admin user interface for the creation and editing of recurring recording schedules New Services: ItunesUDistributionService, YoutubeDistributionService, MediaAnalysisService Scheduler icalender import/configuration user interface In media search for finding relevant keywords within the media Multi-view support in media player. Media player timeline representing slide changes and keyword relevance. Media player embed.
Q4 Overview Dates: May - June 2010
User Stories: High Level Scenarios:
Summary: At the completion of Quarter 4, Matterhorn will include basic media annotation as well as the ability to add/cancel recordings from existing recurring events. The primary thrust of Q4 is to benchmark and test Matterhorn as a distributed environment. The outcome of these tests will be a set of recommendations for installing and configuring Matterhorn 1.0.
Key Goal(s): incorporate the final visual designs into the user interfaces, and test and package a stable Matterhorn 1.0 release.
Key Deliverables:
New Services: AuthoritativeAnnotationService Refined configurations capabilities Internationalization support Final "skin" for user interfaces Release 1.0 installation packages and documentation.
By Iteration (Detail) Unknown macro: {jiraportlet}
Release 1.0 Parking Lot Unknown macro: {rss}
Grant Deliverables Table of contents
Table of contents Scheduling Administration Appliance Workflow Engine and Job Handling Content Repository Ingest Encoding Editing and Branding Distribution Captioning Media Analysis Statistics Search Interact Accessibility
SCHEDULING
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Calendar and scheduling service mapping. Enter manually individual or recurring recordings based on date/time/location (MH-846, MH-130)
Scheduling service contracts and implementation Pre-populate recording schedule from import of campus registrar data (This data will need to be provided by an institution's IT administrator in a specific format) (MH-1040)
Scheduling User Facing Application(adaptation or Specify institution wide exclusion dates (i.e. holidays, midterms) for a given time span (MH-1064) adoption of existing open source calendaring system like Bedework or completely customized version)
Specify capture type (i.e. video, screencast, audio) for individual or recurring recordings (assume part of MH-846, MH-130)
Specify bitrate, framerate, frame size, codec, and wrapper for scheduled recording(s) (MH-475)
Specify start/stop offsets for individual or recurring scheduled recordings NOTE: Parking Lot Item (MH-1200)
Specify whether scheduled recording should be automatically captured, captured on site manually, or initiated by lecturer/presenter NOTE: capture application that runs on lecturer's personal computer will not be supported, but services will be in place if an institution wants to develop a lecturer initiated recording on a dedicated capture appliance. This deliverable is a Parking Lot Item. (MH-1206)
Comments
*
ADMINISTRATION
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Basic Authentication (simple configuration will allow one to many Login/Logout as administrator (MH-1201) administrators)
Enterprise service definition and implementation. (these services Add/Update/Remove capture locations and their supported capture will allow custom implementations - i.e. ldap integration) capabilities (i.e. video, screencast, audio) (MH-1202)
Choose locale (internationalization) (MH-1216) Parking Lot: Setting locale in a UI. (MH-874, MH-875) Comments
*
APPLIANCE
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Basic low cost, low power appliance that supports one audio, video, and vga source for high quality encoding. This reference spec is intended for institutions with no existing infrastructure. For institutions with existing Preview samples of captured video infrastructure, the scheduling service, capture script, and inbox will allow institutions provides a low barrier for and audio (MH-476 and/or MH-515 a integration with Matterhorn. nd/or ????)
Calendar and media metadata mapping, injection, and packaging for captured media Report successful start, in process, and stop of capture MH-847
Capture service contracts and implementation Report capture failure of media feed(s) (no story yet)
Proof of concept appliance that supports simultaneous encoding from multiple media inputs, high definition capture, live streaming, and dynamic presenter tracking NOTE: the appliance will support multiple media inputs, but it will not support HD, live streaming, or dynamic presenter tracking. Report media feed connection status (no story yet)
Initiate capture via cached schedule (no user facing story required)
Cache previous recordings for specified time period
Report appliance connection status
Automatically upload captured recording(s) for Matterhorn media pipeline ingestion (no user facing story required)
Specify bitrate, framerate, frame size, codec, and wrapper of recording(s). ( MH-475)
Start and stop capture NOTE: Matterhorn will support automated capture, but there will be no support for instructor initiated capture. Parking Lot Item. (MH-1206)
Report storage status NOTE: Not a necessary requirement.
Comments
*
WORKFLOW ENGINE AND JOB HANDLING Matterhorn 1.0 Scope Primary Use Cases and Requirements
Workflow management service Support specified business processes for Matterhorn 1.0 media life cycle. (no user facing story and implementation. required)
Utilize an existing opensource, standards-based workflow engine NOTE: Matterhorn's workflows' simplicity does not warrant an off the shelf workflow engine. This will likely be reassessed after Release 1.0.
Comments
*
CONTENT REPOSITORY
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Repository management service Serve as a temporary repository for storing media before it is distributed (no user facing story and implementation required)
Store automatically capturedmedia, manually submitted media, attachments, and metadata (no user facing story required)
Provide content access to each of Matterhorn's services. (no user facing story required)
Manage access based on authorized actors NOTE : Authorization will not be supported in release 1.0. Requirements around authorization are poorly understood, and its impact across
Comments
*
INGEST
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Ingest service and Initiate workflow specified for media/metadata (no user facing story required) implementation
Watch ingest folder (no user facing story required) NOTE : Requirement not considered essential, but this can be easily implemented by interested parties.
Comments
*
ENCODING
Matterhorn 1.0 Scope Primary Use Cases and Requirements Encoding service and implementation Specify bitrate, framerate, frame size, codec, and wrapper for captured recording(s)
Report in queue, start, in process, and completion of encoding
Report encode failure
Automatic media chaptering.
Inject metadata into media container NOTE: This is needed for iTunes U distribution.
Comments
*
EDITING AND BRANDING
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Encoding service and implementation Edit metadata associated with media (MH-457,MH-458,MH-1069)
Apply default branding intro/outro to media NOTE : Parking Lot Item. (MH-1207)
Apply default watermark to video NOTE : Parking Lot Item.(MH-1208)
View preview media NOTE: Parking Lot Item.(MH-1209)
Remove media segments from existing media NOTE: Parking Lot Item.(MH-1210)
Select specific audio channel from stereo recording for mono audio
Split media into independent segments
Insert new media into existing media
Increase/decrease audio levels
| Comments
*
DISTRIBUTION
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Distribution to iTunes U, Youtube, RSS/Atom, "Archive" (file Publish media/metadata to distribution channels (no user facing story system), and VideoLectures.net or WordPress. required)
One administrative user and basic information architecture Add/Update/Remove distribution type and channel. (MH-1203) mappings for each channel
Distribution channel service contracts and implementations Define distribution type and channel
Report success, failure, in process status for un/publishing NOTE: Only publish reporting will be supported in release 1. Unpublishing from distribution channels will not be supported.
Unpublish media/metadata from distribution channels
Report storage status for distribution channel(s) (i.e. un/used storage)
Comments
*
CAPTIONING
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Caption service and implementation. Tools that enable closed captioned media.
Comments
*
MEDIA ANALYSIS
Matterhorn 1.0 Scope Primary Use Cases and Requirements Analysis service and implementation VideoOCR metadata extraction (no user facing story required)
Indexing static,dynamic, and user generated metadata (no user facing story required)
Metadata packaging to standard format (no user facing story required)
Comments
*
STATISTICS
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Stats service and implementation Provide the statistical feedback for each distribution channel (i.e. most viewed, most downloaded) (MH-12 14,MH-1215)
Combine viewed and downloaded stats across channels
Comments
*
SEARCH
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Search service and implementation. Technologies like solr/lucene will be Discovery of distributed media based on static metadata. used for the default implementation.
Interact functionality (see following row) will be the major client of search Discovery of distributed media based on dynamic/isochronic services. metadata from media analysis
Discovery of distributed media based on captioning and annotations.
Comments
*
INTERACT
Matterhorn 1.0 Scope Primary Use Cases and Requirements Embeddable, accessible media player for engaging with media. Play/FastForward/Rewind media
Support UI localization
Comments
*
ACCESSIBILITY
Matterhorn 1.0 Scope Primary Use Cases and Requirements
Establish guidelines for reference Media Integrate captioning tool into Matterhorn or at minimum import and export Matterhorn media player to meet accessibility standards files for users with disabilities.
Provide output to be used for indexing Captioning and description tool
Ability to produce accessible (ADA and European accessibility legislation compliant) media files
Clean up captioning created through voice recognition NOTE:Results from voice recognition may be one of the many inputs uploaded to CapScribe, but voice recognition is not in scope in release 1.0. Capscribe,, however, will provide general support for captioning clean up.
Allow the use of text in various formats (lecture notes, powerpoint text, etc.) as the basis for captions
Comments
*
Q1 User Stories
INTERNAL SERVER ERROR
Key Summary Status Priority Reporter Assignee
JIRA server returned an error: Service Unavailable View these issues in JIRA
Q2 User Stories
INTERNAL SERVER ERROR
Key Summary Status Resolution Priority Reporter Assignee JIRA server returned an error: Service Unavailable View these issues in JIRA
Q3 User Stories
INTERNAL SERVER ERROR
Key Summary Status Priority Reporter Assignee
JIRA server returned an error: Service Unavailable View these issues in JIRA
Q4 Scenarios and Deliverables
INTERNAL SERVER ERROR
Q4 SCENARIOS (MAY - JUNE 2010) - POSSIBLY JULY
Scenario Related User Stories
1) Administrator adds an extra recording to recurring event
2) Administrator cancels one recording in recurring event
3) Learner bookmarks a specific segment of the lecture to review it at a later date
Who subscribes to view videos and possibly Engages Tools within the LMS???
4) Configurer installs/configures Matterhorn to run a small pilot on their campus
5) Configurer installs/configures Matterhorn to run as a campus wide solution
6) Configurer installs/configures Matterhorn service to incorporate into existing system
Potential configurations:
how long media packages stick around holidays/exclusion dates for an institution drop-downs such as "Category" specify required fields for Ingest/Scheduler License Information
Any code contributed directly to Opencast Matterhorn, will be covered by the Educational Community License (ECL) 2.0. All code contributions will require signing an ECL contributor's license agreement. All other (non-code) IP under this grant will be released under the Creative Commons Attribution 3.0 license.
REPLAY and PLAYMOBIL are both released under LGPL; any use (completely or partially) in Matterhorn is allowed by this licensing model.
EDUCATIONAL COMMUNITY LICENSE, VERSION 2.0
Copyright 2008 University of California Berkeley Educational Community License, Version 2.0, April 2007
The Educational Community License version 2.0 ("ECL") consists of the Apache 2.0 license, modified to change the scope of the patent grant in section 3 to be specific to the needs of the education communities using this license. The original Apache 2.0 license can be found at: http://www. apache.org/licenses/LICENSE-2.0
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i ) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.
"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work.
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.
2. Grant of Copyright License.
Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.
3. Grant of Patent License.Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. Any patent license granted hereby with respect to contributions by an individual employed by an institution or organization is limited to patent claims where the individual that is the author of the Work is also the inventor of the patent claims licensed, and where the organization or institution has the right to grant such license under applicable grant and research funding agreements. No other express or implied licenses are granted.
4. Redistribution.You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
1. You must give any other recipients of the Work or Derivative Works a copy of this License; and 2. You must cause any modified files to carry prominent notices stating that You changed the files; and 3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and 4. If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License.
You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
5. Submission of Contributions.
Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.
6. Trademarks.
This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty.
Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
8. Limitation of Liability.
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability.
While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.
CREATIVE COMMONS LICENSE, ATTRIBUTION 3.0 UNPORTED
THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.
1. Definitions
1. "Adaptation" means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License. 2. "Collection" means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License. 3. "Distribute" means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership. 4. "Licensor" means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License. 5. "Original Author" means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i ) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast. 6. "Work" means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work. 7. "You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous 7.
violation. 8. "Publicly Perform" means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images. 9. "Reproduce" means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.
2. Fair Dealing Rights. Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws. 3. License Grant. Sub ject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:# to Reproduce the Work, to incorporate the Work into one or more Collections, and to Reproduce the Work as incorporated in the Collections;
1. to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified."; 2. to Distribute and Publicly Perform the Work including as incorporated in Collections; and, 3. to Distribute and Publicly Perform Adaptations. 4. For the avoidance of doubt: a. Non-waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; b. Waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and, c. Voluntary License Schemes. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.
The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.
4. Restrictions. The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:
1. You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested. 2. If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i ) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties. 3. Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise. 5. Representations, Warranties and Disclaimer
UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.
6. Limitation on Liability.
EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
7. Termination
1. This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License. 2. Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.
8. Miscellaneous
1. Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License. 2. Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License. 3. If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. 4. No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent. 5. This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.
The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law. Features and Functionality
Matterhorn is an end-to-end software application that supports the scheduling, capture, managing, encoding and delivery of educational audio and video content. The features planned for the first release, scheduled for July 2010, can be viewed across 4 key components:
1. Lecture Capture and Administration 2. Ingest and Processing 3. Distribution Management 4. Engage Tools Unknown macro: {imagemap} Unknown macro: {map} Unknown macro: {map} Unknown macro: {map} Unknown macro: {map} Lecture Capture and Administration
KEY FUNCTIONALITY
Capture Infrastructure
"Build Your Own Matterhorn Capture Appliance" based off a reference specification for a low cost, low power capture device that supports audio, video and VGA source for high quality encoding. Several prototypes will be available for testing purposes.( see Capture Hardware Specification) Support for automated capture based on schedule Multiple inputs for simultaneous/synchronous capture, e.g. a video of the lecturer plus the VGA signal from the lecturer's computer Configurable capture encoding specifications (see Codec Support) Ingest service for institutions with existing capture infrastructure that want to send media and metadata to be processed and distributed by Matterhorn.
Administration
Confidence Monitoring
Capture status monitoring to track the success or failure of each scheduled capture, as well as the availability of each capture media input. This will only work with Matterhorn's capture appliance reference out of the box. Workflow status monitoring to track the success or failure of each recording from processing through distribution.
Media Capture Scheduling
Manual scheduling of individual or recurring recordings iCalendar import from external scheduling source (e.g. derived from registrar data)
Recording Management
Metadata entry and editing for related recordings Distribution initiation to supported channels (i.e. iTunes, YouTube, RSS) Manual media upload (e.g. user-generated or production video) for processing and distribution
DRAFT USER INTERFACES IN CONSIDERATION
auto-generated by Balsamiq Mockups. DO NOT auto-generated by Balsamiq Mockups. DO NOT auto-generated by Balsamiq Mockups. DO NOT REMOVE REMOVE REMOVE auto-generated by Balsamiq Mockups. DO NOT auto-generated by Balsamiq Mockups. DO NOT auto-generated by Balsamiq Mockups. DO NOT REMOVE REMOVE REMOVE
auto-generated by Balsamiq Mockups. DO NOT auto-generated by Balsamiq Mockups. DO NOT auto-generated by Balsamiq Mockups. DO NOT REMOVE REMOVE REMOVE
auto-generated by Balsamiq Mockups. DO NOT REMOVE
Ingest and Processing
KEY FUNCTIONALITY Configurable workflow for processing the media through the processing and distribution life cycle Trimming, branding and watermarking capability Automated media segmentation based on slide changes and scene detection Simple integration with encoding engines such as FFmpeg or Apple's QuickTime Advanced media analysis, including video OCR that extracts time-synched metadata from slides Powerful search indexation for static, dynamic, and user-generated metadata Tool that enables closed captioning of media Sophisticated administrative dashboard for monitoring and management of media's life cycle Distribution Management
KEY FEATURES
Automated publishing to iTunes U and YouTube Distribution to RSS/Atom feeds for integration into learning management systems Distribution/archive to local storage or distribution servers Engage Tools
KEY FUNCTIONALITY
Basic embeddable media player for learners to engage with media Two-screen media player, so that the learner can view the lecturer and slides at the same time Interface for viewing closed captions, searching videos, and subscribing to an RSS feed Navigation timeline representing slide changes and keyword relevance Powerful in-media keyword search Basic media annotation All functionality accessible by keyboard and screen reader Support for customization of player interface for localization
MEDIA PLAYER MOCKUP FOR 0.5 RELEASE
auto-generated by Balsamiq Mockups. DO NOT REMOVE
Mockups for 1.0 release coming soon!
Accessibility Features
In progress, see https://wiki.opencastproject.org/confluence/display/open/Accessibility
Keyboard Shortcuts
Control + Alt + I = Toggle the keyboard shortcuts information between visible or unvisible Control + Alt + P = Toggle the video between pause or play Control + Alt + S = Stop the player Control + Alt + S = Stop the media Control + Alt + M = Toggle between mute or unmute the media Control + Alt + U = Volume up Control + Alt + D = Volume down Control + Alt 0 - 9 = Seek time slider Control + Alt + C = Toggle between captions on or off Control + Alt + F = Forward the media Control + Alt + R = Rewind the media Control + Alt + T = The current time for the screen reader on Mac Cmd + = player zoom in on Mac Cmd - = player zoom out on Windows Ctrl + = player zoom in on Windows Ctrl - = player zoom out
WAI-ARIA-Support
For different interaction elements like
Buttons (role "button" / not pressed: state aria-pressed = false; pressed: state aria-pressed = true) Slider (role "slider" / aria-volumemin, aria-volumemax, aria-valuenow, aria-valuetext) Alert (role "alert") to inform about the current media time via keystroke Log (role "log") for captions as HTML output
For more informations about WAI-ARIA visit: http://www.w3.org/TR/wai-aria/
Keyboard support
All functions (without fullscreen for some browsers) are accessible via Keyboard
Captions
Captions are available as layer over the video. This is especially for sighted user. In Addition to this there are via CSS hidden captions in the HTML source for screenreader user with WAI-ARIA support. Auto enabled by muting: Captions are automatic enabled by muting the media Currently supported format: W3C DFXP http://www.w3.org/TR/ttaf1-dfxp/
Magnification with standard browser controls
Video and the complete user interface can be zoomed via standard browser controls on Mac Cmd + = player zoom in on Mac Cmd - = player zoom out on Windows Ctrl + = player zoom in on Windows Ctrl - = player zoom out
CSS for Accessibility
We have used CSS styling form the Fluid Project Framework (http://wiki.fluidproject.org) to improve the user experience.
Other Features
Editable time-code for fast jumping to every position of the media optimized sequence of UI elements in the HTML code for efficient use especially for screenreader Get Matterhorn
Download the latest version Get the latest build from Nightly Download the Source Install and Configure License Information Development Documentation
Getting Started as a developer or programmer If you are looking to get started with Matterhorn development then try the Developer Getting Started Guide.
Documentation Under Development This section is the working area for the Opencast Matterhorn team. Documents in this section may still be in draft format, incomplete, or out of date. For the most current documentation about the project, please refer to the Product Documentation section.
Developing Source Standards Accessibility Caption Support Media Codecs and File Types Metadata Standards Metadata mapping in the UIs Install and Configure Create a Virtual Machine Install Virtual Machine Install Source Windows 3rd Party Tools Installation Capture Agent Configuration Capture Service Configuration Configure Matterhorn Feed Catalog Configure Matterhorn Port Number and Base URL Create a custom workflow Engage media player installation Install Matterhorn Capture Agent Overview of Configuration Files Register a Capture Agent Technology Stack Architecture Ingest Overview Distribution PortalDistribution Capture Agent Job Sequence Tools Confluence Gliffy Crucible Eclipse Guide Jira Create Jira Stories, Tasks and Sub Tasks Estimate and Log Jira Issues Jira Issue Types Jira Overview Navigate Jira Issues Matterhorn Subversion Repository Maven Nexus Server Work Practices Committers Practices Common Processes Agile Software Development Licenses Processes Communication Frontend best practices Javascript coding style Java best practices Management Processes Conducting "Scrum of Scrums" REST practices Submitting a Patch to Matterhorn Cookbook Adding Demo Data To Your Instance Atom and RSS Feeds Capture Media from the Command-line Create an Encoding Profile Get Capture Agent Schedules Including common static resources in your UI Integration Testing iTunes Distribution Service Java Unit testing JavaScript Unit testing MediaPackage Cookbook Obtaining the server's base URL Registering User Interfaces Service Design Create a New Service Anatomy of a Service Document a Service Simulate Capture Agent Hardware Workflow Cookbook Youtube Distribution Service Service Contracts AdminService ArchiveService AuthoritativeAnnotationService Capture Admin Service CaptureAgentService ConductorService DownloadDeliveryService FeedbackService FeedDistributionService IngestService iTunesUDistributionService MatterhornPortalDistributionService MediaAnalysisService MediaComposerService MediaInspectionService NotificationService SakaiDistributionService Scheduler Service SearchService SiteIntegrationService StreamingDeliveryService TranslationService WorkflowService WorkingFileRepository WorkspaceService YouTubeDistributionService Entities MediaPackage Attachment MediaPackage Catalog MediaPackage Manifest MediaPackage Overview MediaPackage Track User Experience BA-UX Common Welcome Page Brainstorming Design Principles Customer Research User Research Workflows BA-UX Engage User Experience Studies Past relevant work Mockups BA-UX Admin App Admin App Use Cases Admin UIs Comparative Analysis of Administrative Applications Pain Points Past Relevant Work - Admin Mary Johansson - Podcast Administrator User Testing - Admin App Release Management Managing Releases Release 0.4 Release 0.4 Documentation Release 0.5 Management Service checklist Verifying Matterhorn Releases Quality Assurance Acceptance Testing Code Documentation Developer checklist Caption Handling 0.5 Checklist Capture 0.5 Checklist Capture Admin 0.5 Checklist Composer 0.5 Checklist Distribution (local) 0.5 Checklist Engage 0.5 Checklist Ingest 0.5 Checklist Inspection 0.5 Checklist Scheduling 0.5 Checklist Search 0.5 Checklist Workflow 0.5 Checklist Working File Repository 0.5 Checklist Workspace API 0.5 Checklist Matterhorn Supported Screenreaders QA Process Overview Selenium Core Test Tools and HOWTOs to improve the quality for non-java development X Browser Test Environments _Components Schedule Drafts_ Working Documents BA-UX - Distribute Service Modeling Service Definitions - Distribute Service Definitions - Cross-Component Service Definitions - Capture Revised ArchiveService ArchiveService_Release_Notes Reviewing Code Requirements - Schedule Requirements - Process-Encode Requirements - Distribute Requirements - Capture OBSOLETE - Engage Archive Docs - Engage Components Schedule UIs Components Schedule Other Testing balsamiq Relationships between admin UIs Deployment Case Studies Simple Classroom Setup - USask Candidate metadata available for capture Capture Agent and System Test Instructions Streaming and Web Server solutions from the Community Keyboard shortcuts for a basic media player BA-UX - Process-Encode Welcome Page - Installation DEPRECATED Service Contract Description Template Service Definitions - Engage Capture Media and Encoding Results Matterhorn Capture Hardware Specification Sample Media Output Composer Features Advanced Workflow Options - Chris Calendar -- Capture architecture proposal HTML CSS js framework Scheduling Scenarios Adding a new service Matterhorn Engage - Player architecture Ingest Flow Potential workflows for Admin App Admin UI Component Diagram 1 - Ingest Only Admin UI Component Diagram 2 - Ingest and manual scheduling with Bedework Admin UI Component Diagram 3 - Import from my Scheduling System, Ingest, and use Bedework for manual scheduling Admin UI Component Diagram 4 - Import from my Scheduling System and Ingest only (no Bedework, no manual scheduling) Flex frameworks Media Portal Components Schedule Services Components Process and Encode UIs Components Process and Encode Other Components Process and Encode Drafts Components Engage Drafts Components Distribute Drafts Components Common UIs Components Common Services Components Common Other Components Common Drafts Components Capture Drafts CaptureAgentService_Draft Live media capture architecture Service Definitions - Process-Encode Release 0.5 ~ Deliverables (Aug. 09 - Jan. 10) Release 0.5 ~ Iterations (Aug. 09 - Jan. 10) Release 0.5 ~ Scenarios (Aug. 09 - Jan. 10) Step 1 - config.sh Step 2 - external_tools.sh Step 3 - capture_agent.sh Service Definitions - Schedule Archive Docs - Capture Archive Docs - Cross-Component Archive Docs - Distribute Requirements - Cross-Component Archive Docs - Process-Encode Archive Docs - Schedule BA-UX - Capture Ingestor Interface Components Process and Encode Services BA-UX - Schedule Meeting Goals & Activities Design Studio BA-UX - Cross-Component Developing Source
1. Installing eclipse Eclipse IDE - http://www.eclipse.org/ a. Download the current version of the Eclipse IDE for Java EE Developers from http://www.eclipse.org/downloads/ This version is recommended because it includes the web development tools b. Extract the downloaded file Windows: should extract to c:\ Mac OSX: should use the installer and put it in Applications c. Run eclipse to verify it works (/opt/eclipse/eclipse) Windows: c:\eclipse\eclipse.exe to run eclipse NOTE: If it does not work, there is probably a problem with your java install d. Set the memory settings for Eclipse The default memory settings for Eclipse are too low to handle a large project like Matterhorn i. Shutdown eclipse if it is running ii. Edit the eclipse.ini file in the directory you extracted/installed eclipse iii. Change the settings from something like this:
-vmargs -Xms40m -Xmx256m
to something like this (leave any params that do not match these alone):
--launcher.XXMaxPermSize 256M -vmargs -Xms128m -Xmx1024m -XX:+UseParallelGC
Windows: users should not use notepad to edit this file, use wordpad or edit (command line) Mac OSX: users will need to take additional steps to edit the eclipse.ini file i. Control-click on the Eclipse Application icon and select Show Package Contents ii. Double-click on the Contents folderD iii. Double-click on the MacOS folder, the eclipse.ini file should be here iv. Full path: eclipse/Eclipse.app/Contents/MacOS/eclipse.ini e. Install the subclipse plugin Subclipse - http://subclipse.tigris.org/ i. Use eclipse updater to install the plugin from the update site
http://subclipse.tigris.org/update_1.6.x 1.
f. Install the Maven Integration for Eclipse plugin Maven Integration for Eclipse - http://m2eclipse.sonatype.org/ i. Use eclipse updater to install the plugin from the update site
http://m2eclipse.sonatype.org/update
2. Configure eclipse There are more details available in the Eclipse Guide a. Install the files below in your eclipse installation to automatically adhere to the project code styles
Preferences > Java > Code Style > Formatter > Import docs/eclipse_settings/opencast-codestyle.xml
Preferences > Java > Code Style > Code Templates > Import docs/eclipse_settings/opencast-codetemplate.xml
Preferences > Java > Code Style > Organize Imports > Import docs/eclipse_settings/opencast.importorder
3. Import source into eclipse There are more details available in the Eclipse Guide a. Import the entire matterhorn source as a single project i. Click on File > Import ii. Select Maven Projects under General iii. Browse to your MATTERHORN_SRC directory (e.g. /opt/matterhorn/matterhorn_trunk) and click Open iv. Open the advanced options at the bottom and uncheck Resolve Workspace projects and Separate projects for modules v. Click on Import to start the process (may take 5-10 minutes) vi. Once this is complete you can access all the matterhorn trunk projects in the new base project Recommend you rename this from "base" to "matterhorn-base" 4. Build and redeploy a single bundle When developing for Matterhorn you may just want to change a small part of a single project/bundle. This does not require a rebuild and restart of the entire Matterhorn system. You can redeploy a single bundle allowing for faster development! a. Go to your MATTERHORN_SRC directory
cd /opt/matterhorn/matterhorn-trunk
b. Change to the directory containing the bundle you want to redeploy (e.g. opencast-search-service-impl)
cd opencast-search-service-impl
c. Rebuild and redeploy using maven (use the same build command you always use) 4.
c.
mvn clean install -DdeployTo=/opt/matterhorn/felix/load
d. The new bundle should replace the existing one and you will see the startup process (or failures if you made a mistake) in the logs Standards
The documents in this section provide information about technical standards that are used in Opencast Matterhon. Accessibility Caption Support Media Codecs and File Types Metadata Standards Accessibility
Multimedia (& Other) Accessibility standards: Accessibility Links The accessibility specifications are intended to address the poor implementation of accessible multimedia player interfaces both in the mass market today, as well as those tools and How can my technologies currently in use by our educational institutions. educational entity deliver accessible The standard to determine the success of the Matterhorn project meeting targeted inclusive webcasts? design objectives is based upon the four principles of accessibility as expressed by the W3C ( Flash And Accessibility http://www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head) . Creating Accessible Flash Content The guidelines and success criteria are organized around the following four principles, which National Center for lay the foundation necessary for anyone to access and use Web content. To meet inclusive Accessible Media design objectives, the Matterhorn player must be: Video Accessibility 1. Perceivable - Information and user interface components must be presentable to Status Aug 2009 - users in ways they can perceive. Mozilla wiki This means that users must be able to perceive the information being Accessible Multimedia presented (it can't be invisible to all of their senses) Javascript libraries for 2. Operable - User interface components and navigation must be operable.
If any of these are not true, users with disabilities will not be able to use the player.
Supported Assistive Technologies (AT):
Through the application of inclusive design principles throughout the project, users who require assistive technologies should have their needs supported by the Matterhorn player. Below is a brief description of types of various AT used by individuals, and some examples of design considerations that may be required. (**Note: design considerations are intended as suggestions and not as an exhaustive list of modifications required on standard players.
Alternative output technology supports:
Screen magnifiers - Function: to enlarge images and text displayed by system for individuals with low vision. Functionally much like a zoom feature is some applications, however it includes all aspects of the display (including menus) and enlarged text may be 'smoothed' to make characters less pixilated. Contrast alternatives may also be applied to applications providing individualized customization to foreground and background colours. Design Considerations: video playback controls must be of sufficient quality to be clearly discernable when enlarged, high contrast of foreground and background colours should provided. *Screen readers - Function: To read information conveyed on traditional displays through synthesized speech. Image labels, if properly identified through standard conventions, may be read aloud. Design Considerations: Any information conveyed via images must be described incorporating techniques described by WCAG, ARIA, DHTML and similar working groups and standards committees. Videos conveying information in a purely visual way must also provide description of actions using audio description techniques.
Alternative input technology supports:
Alternatives to standard keyboards Function: Utilized by individuals unable to use standard keyboards. Alternatives that may be used include onscreen keyboards, speech recognition input, single switch and coded input (e.g. Morse code). Design Considerations: All player functions must be able to be accessed using keyboard input independent of mouse control. As data entry rate may be slower than average, player controls must minimize need for repeated keystrokes through maintenance of focus on player controls that are activated. Alternatives to standard mouse usage Function: Utilized by individuals with limited motor control, and those who are unable to see the mouse pointer. Alternatives include keyboard 'shortcuts', speech input control and switched activated mouse emulation software. Design Considerations: The size of player controls should consider the needs of individuals with reduced motor control and coordination, provide Keystroke alternatives, be properly labeled, and accessible by the keyboard (e.g. by 'tabbing' to the various controls).
Sample Stories
MarthaMartha missed her history class due to a medical appointment and is reassured by the fact that she can review the missed lecture online. As Martha's school has hundreds of archived lectures, and as she is visually impaired, she needs to be able to search through the many videos in a way that allows her efficient access to a reduced list of possible options for the lecture she seeks.
JacquesJacques relies on reviewing lectures of classes he attends as he is unable to physically take notes during class (he lost the use of his hands in an auto accident). He uses a combination of speech recognition software and single switch access with an onscreen keyboard to control his computer input. Jacques accesses web content speaking the links he would like to activate. Player buttons would ideally be accessible by speaking their function.
BruceBruce is researching new pedagogies in education. One suggested resource was a presentation available in the schools media archive. As Bruce has a profound hearing loss, he must view the presentation with the captions turned on.
Challenges (and opportunities) for Matterhorn
Currently there are no demonstrated multimedia player technologies that are robust enough to address cross browser, cross platform needs and offer access methods that address the needs of all users. Although Flash remains the optimal environment for delivering video across platforms, the accessibility of this approach has had historic challenges which, although significant progress has been made for users of a specific platform and its' browsers, remain problematic for many AT users, individuals that use less popular browsers and those using mobile platforms.
Issues that remain problematic are focus issues with flash (individuals are unable to tab into the player to access functions without using a mouse) on some of the "Yahoo Grade A browsers" that Matterhorn is being designed for, controls cannot be accessed using speech recognition software commands, and functional controls that are not labeled in a way that speech synthesis programs such as screen reading software applications can inform the user of their function across platforms.
Adobe has made great strides towards accessibility efforts including the Flex environment, however it remains that accessibility support is focused on a single platform with limitations on the flexibility of the presentation. Many AT users have also had such negative experiences using flash interfaces that many abandon any encounters with the technology before fully discovering if adequate accessibility modifications have been made to allow even basic access to the presentation. A growing number of individuals with disabilities, including many who are blind and use alternate screen readers such as VoiceOver which is unable to read or access Flex based controls , are using platforms other than Windows and a broad variety of browsers. For these reasons a hybrid approach was initiated to create an additional layer of accessible controls using html, css and javascript. This has proven to provide the accessibility required for users of AT and works across the various platforms and browsers of our targeted end-users.
Caption
Still questions open how to focus by screenreader on captions (changing html div elements) and hiding this elemens for standard view by css.
Suggested keyboard shortcuts for player functions.
What the DHTML style guide suggested is the following:
Control + Alt + P = Pause/Play toggle Control + Alt + S = Stop the player Control + Alt + M = Mute/Unmute toggle Control + Alt + U = Volume Up Control + Alt + D = Volume Down Control + Alt 0 - 9 = Seek the time slider Control + Alt + C Captions toggle. Control + Alt + F = Fast Forward Control + Alt + R = Rewind
These are very similar to many of the suggestions previously made, and are fairly 'simple' as they use consistent modifier keystrokes (Ctrl + Alt) and the first letter of what it is you want to do (in English). The other alternative would be to utilize keystrokes similar to other media players that users may be experienced with. Play - WMP= Ctrl+p, QT=spacebar Stop - WMP=Ctrl+S, QT=Ctrl+Left arrow Rewind - WMP=Ctrl + Shift +B, QT=none Fast Forward - WMP=Ctrl + Shift + F, QT=none Volume - WMP=Up-F9, Down-F8, Mute-F7, QT=up arrow, down arrow Captions - WMP=Ctrl + Shift + C, QT- Ctrl+Alt+T
Is there a specific order needed in the HTML code for the navigation elements for serializing the UI
Screen readers don't use CSS Just the plain html If you take away the stylesheet, you'll see the order of things that the screenreader will follow. Jump to player controls, possibly located before the video is encountered. Tab order should be logical
What needs to be done to create an accessible videoslider
Accessible slider needs:
to be keyboard accessible to be properly labelled (for screen readers to identify function)
If progressive download is visible should provide sufficient contrast to background to be easily visible.
provide alternative reference as to progress along slider (in time or perecentage reference)
Accessible elements needed for moving to different points in video
Captioned content should be searchable by key word and user should be able to jump to the associated time reference in the video.
Additional time based navigation buttons (e.g. skip forward 5 seconds) may be:
easier to understand due to improved labelling ideally could be "held" to minimize amount of repeated keystrokes for each advance
General information:
Font and background colour of interface elements would ideally support external CSS used (eg white text on black background) Caption Support Input
The following caption formats may be uploaded into Matterhorn:
Timed Text (DFXP) more...
The captions are then converted to Timed Text format and stored within the media package.
Output
The following caption formats are available for the user or for specific distribution channels:
Timed Text (DFXP) MicroDVD QT Text SAMI SubRip SubViewer SCC (?*)
*SCC is a difficult format to create, but is necessary for distributing captions to iTunes U. Whether or not we will create this format has yet to be determined.
Media Package
Timed Text (DFXP) will be stored within the media package as the base working format. This format is the most feature-rich, and therefore flexible, when preserving the maximum amount of formatting and caption information.
Media Player
Timed Text (DFXP) is supported by the Matterhorn media player. Media Codecs and File Types
This document outlines the codecs and media file types Matterhorn currently supports. Matterhorn uses ffmpeg by default for all media handling. The following list is taken from ffmpeg's own documentation. Codecs File Formats
CODECS
FILE FORMATS
Metadata Standards
The Opencast Core metadata specification is derived from the work of the Dublin Core Metadata Initiative. It is intended to promote sharing and interoperability between members of the Opencast community by defining common fields, interpretation and formats.
THREE-TIERED SCHEME
The community will support a scheme defined at three levels:
Implemented
In order to promote federation, the Opencast Core defines a set of twenty-four fields, most of which abide by international specifications. While the scheme does not fully determine the vocabulary and formats used, federation may require additional mapping on the part of adopters.
Exposed
In order to be useful, the Matterhorn default user interfaces will expose a subset of the specification. This subset is fully configurable at runtime.
Required Matterhorn does not require the use of any metadata, but adopters will need to consider what is required by their workflows and system configuration. For example, Speech-to-Text conversion would depend upon the specification of language and a given distribution channel may insist upon a title.
SPECIFICATION
All descriptions from the Dublin Core Metadata Initiative.
Exposed
abstract A summary of the content of the resource.
contributor An entity responsible for making contributions to the content of the resource. Examples of a Contributor include a person, an organization or a service. Typically, the name of a Contributor should be used to indicate the entity.
creator An entity primarily responsible for making the content of the resource. Examples of a Creator include a person, an organization, or a service. Typically the name of the Creator should be used to indicate the entity. AACR2.
description An account of the content of the resource. Description may include but is not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content.
isPartOf The described resource is a physical or logical part of the referenced resource.
language A language of the intellectual content of the resource. Recommended best practice for the values of the Language element is defined by RFC 3066 RFC 3066 which, in conjunction with ISO 639 ISO 639), defines two- and three-letter primary language tags with optional subtags. Examples include "en" or "eng" for English, "akk" for Akkadian, and "en-GB" for English used in the United Kingdom.
license A legal document giving official permission to do something with the resource. Recommended best practice is to identify the license using a URI. Examples of such licenses can be found at Creative Commons.
subject The topic of the content of the resource. Typically, a Subject will be expressed as keywords or key phrases or classification codes that describe the topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.
title The name given to the resource. Typically, a Title will be a name by which the resource is formally known.
audience A class of entity for whom the resource is intended or useful. A class of entity may be determined by the creator or the publisher or by a third party.
available Date (often a range) that the resource will become or did become available. W3C-DTF profile of ISO 8601.
created Date of creation of the resource. W3C-DTF profile of ISO 8601.
extent The size or duration of the resource. ISO8601.
identifier An unambiguous reference to the resource within a given context. Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system. Examples of formal identification systems include the Uniform Resource Identifier (URI) (including the Uniform Resource Locator (URL), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN).
isReplacedBy The described resource is supplanted, displaced, or superseded by the referenced resource. issued Date of formal issuance (e.g., publication) of the resource. W3C-DTF profile of ISO 8601.
modified Date on which the resource was changed. W3C-DTF profile of ISO 8601.
publisher The entity responsible for making the resource available. Examples of a Publisher include a person, an organization, or a service. Typically, the name of a Publisher should be used to indicate the entity. AACR2.
replaces The described resource supplants, displaces, or supersedes the referenced resource. rightsHolder A person or organization owning or managing rights over the resource. Recommended best practice is to use the URI or name of the Rights Holder to indicate the entity. AACR2 cf. http://www.aacr2.org
.
spatial Spatial characteristics of the intellectual content of the resource. Geonames.
temporal Temporal characteristics of the intellectual content of the resource. DCMI Period Encoding Scheme.
type The nature or genre of the content of the resource. Type includes terms describing general categories, functions, genres, or aggregation levels for content. Recommended best practice is to select a value from a controlled vocabulary (for example, the DCMIType vocabulary ). To describe the physical or digital manifestation of the resource, use the FORMAT element. DCMI Type Vocabulary.
valid Date (often a range) of validity of a resource. W3C-DTF profile of ISO 8601.
Metadata mapping in the UIs
Recording Screens
Upcoming
The information for this page comes from the Scheduler Service. An array of upcoming events is requested via
SchedulerEvent[] event = service.getUpcomingEvents()
the mapping in the UI is the following
UI Field Opencast/Dublin Core
Title event.getTitle()
Presenter event.getCreator()
Course/Series event.getSeriesID()
Recording Date/Time Long.toString(event.getStartDate().getTime())
Capture Agent event.getDevice()
Processing
The information for this page comes from the Workflow Service. An array of WorkflowInstances is requested via
WorkflowInstance workflow = service.getWorkflowInstances(service.newWorkflowQuery().withState(State.RU NNING)).getItems();
Then for every WorklfowInstance the MediaPackage is retrieved via
DublinCoreCatalog dc = getDublinCoreCatalog(workflow.getCurrentMediaPackage());
The mapping in the UI is the following
UI Field Opencast/Dublin Core
Title getDublinCoreProperty(dcCatalog, DublinCoreCatalog.PROPERTY_TITLE)
Presenter getDublinCoreProperty(dcCatalog, DublinCoreCatalog.PROPERTY_CREATOR)
Corese/Series getDublinCoreProperty(dcCatalog, DublinCoreCatalog.PROPERTY_IS_PART_OF)
Recording Date/Time getDublinCoreProperty(dcCatalog, DublinCoreCatalog.PROPERTY_DATE) Capture Agent getDublinCoreProperty(dcCatalog, DublinCoreCatalog.PROPERTY_SPATIAL)
Status .getName() + .getSate() of last WorkflowOperationInstance in WorkflowOperationInstanceList
Capture Agent Status
The information for this screen is retrieved via the capture-admin/rest/GetKnownAgents endpoint.
The mapping in the UI is the following
UI Field XML element
Agent Name name
Capabilities not supported by now, thus it's hardcoded "Aduio/Video/Screen"
Status state
Scheduler
Ingester
The Ingest UI passes the metadata as key/value pair in a POST to the endpoint
The mapping is the following
From Field key in POST
Title title
Presenter creator
Sponsoring Department contributor
Series isPartOf
Subject subject
Language language
Description description
License license
Media Content Type : type
Search
Player
Install and Configure
These documents will help you get Matterhorn up and running locally.
SOURCE
Content by label
There is no content with the specified labels
VIRTUAL MACHINE Content by label
There is no content with the specified labels
CONFIGURATION
Content by label
There is no content with the specified labels
Create a Virtual Machine
Using VMWare Fusion
Download and save Ubuntu Server ISO from http://www.ubuntu.com/getubuntu/download-server In Fusion choose File -> New Click "Continue without disk" Choose the option "Use Operating System Installation disc image file" Navigate to the saved ISO Continue... Verity that the OS and Version say "Linux" and "Ubuntu", respectively Deselect "Use easy Install" Click "Customize Settings" Enter a name for your VM In the settings, choose the following settings: Network: NAT CPU: 1 Memory: 1GB (at least) Disk: 8GB (at least) Continue to boot the VM Click in the VM window. NOTE: This will connect the mouse to the VM. To recover mouse for the host machine, press ctrl-command (the ctrl and command keys) During OS installation click F4 and choose minimal install Install Virtual Machine
This document will help you install and configure a Matterhorn virtual machine.
SETUP
1. Make sure you have a working internet connection. 2. Install & run VMWare: Mac: http://www.vmware.com/products/fusion/ (get the 30 day trial version - we don't have a license for folks available at this time) PC: http://www.vmware.com/products/player/ (free) 3. Download the VMWare Image .zip file from the Release 0.5 page, and unzip it. 4. Double click on the .vmx file. 5. Choose "I copied it." 6. You may see a message on your console saying "VMWare Tools is not installed," but you can ignore this. A black console will appear. It may take up to a minute for it to load.
Your mouse will not work in the VMWare window. Follow the directions or use CMD-tab (Mac) or Alt-tab (PC) to leave the VMWare window. 7. Enter user name: matterhorn, password: opencast. 8. Press enter when you see "To set up a proxy server, please enter the URL or press enter []?" (unless you have reason to do otherwise) 9. Say "y" or "n" as to whether you would like to reconfigure the keyboard. 10. Say "y" you would like to install third party tools. 11. Say "y" you would like to install ffmpeg. 12. Enter the password (opencast) again. 13. All these things will be installed--this takes about 15 minutes. 14. If your console goes blank, click somewhere in the console window to make sure that's the active window and hit "return." press a non-printing key. (NOTE: If the console is waiting for user input, pressing return will awaken the screen and send a return to the console. On the Mac, I just press the command key.) 15. After everything finishes installing, type the URL at "Matterhorn cosole (should say "console") is at http://xxx.xxx.xxx.xxx:8080" into a browser (you can't copy it)--this is your VM instance. Make sure not to press return too many times as you may move this line outside of view in the console. If you do, either shut down and restart the VM, or enter "sudo reboot" into the console so that you can see the URL again.
Need to tweak something? Use ctrl-z to interrupt the setup script.
Not seeing "demo_capture_agent" when you go to Schedule Recording? You need to delete /opencast content to get a registered agent. While this should be fixed in RC3, if you still have a problem enter "rm -rf /opencast/*" and then restart your vm
Want a clean UI? If you want to remove old data and have a clean interface delete everything in "/var/lib/matterhorn/work/opencast"
SHUTDOWN
Go to the VMWare menu and choose: Mac: Virtual Machine -> Shut Down Windows: VM -> Power -> Power off Command line: sudo /sbin/shutdown -h 0 (NOTE: This may prompt for password [opencast])
STARTUP AGAIN
Click on the VMWare player icon/link on your machine, and open the Matterhorn VM instance.
SETUP A VIRTUAL CAPTURE AGENT
Go into the VM Console and type: wget --post-data='agentName=$NAME&state=$STATE' http://$HOST:8080/capture-admin/rest/SetAgentState (http://$URL/capture-admin/rest/SetAgentState) Replace $NAME and $STATE with any value you desire, and $HOST with the HOST to your VM instance. For more information, see: https://wiki.opencastproject.org/confluence/display/open/Capture+Agent+and+System+Test+Instructions
This same process can be used to set up a capture agent on nightly...just replace the HOST with nightly.opencastproject.org.
Install Source
This document will help you install and run Matterhorn from the source code. If you want to preview Matterhorn then it is running at http://nightly.o pencastproject.org/.
Windows Users Matterhorn is having problems building on Windows. Please see this Jira filter for more information. Environment variables: To Add (or edit) environment variables (Control Panel -> System -> Advanced -> Environment variables) or use "set" instead of export like so: set MAVEN_OPTS="-Xms256m -Xmx512m" Spaces in paths: Windows XP users should ensure they do not have spaces in the paths to matterhorn, maven repository, and felix. It may fail to run if there are spaces in the paths.
OSX 10.5 Opencast recommends you install the Mac OS X Developer Tools 1. Open the Mac OS X installation disc. 2. Go into "Optional Installs" folder and run the Xcode.mpkg file.
1. INSTALL JAVA 1.6 OR HIGHER
Note: Mac OSX 10.6 will have Java 1.6 installed by default
1. a. To check: Run java -version on the command line b. If not correct, download the J2SE SDK from: http://java.sun.com/javase/downloads/widget/jdk6.jsp c. Install it (the SDK) to /opt/java Note: Install the JRE to a different directory (probably the default, especially under windows) or you will have problems d. Set environment variable: JAVA_HOME=/opt/java Mac users: JAVA_HOME=/Library/Java/Home Windows users default: JAVA_HOME=C:\j2sdk1.6.0_xx (where "xx" is the minor version - for example "j2sdk1.6.0_11") e. Add $JAVA_HOME/bin to PATH
2. SETUP MAVEN 2.0.6 OR HIGHER
Maven - http://maven.apache.org/
Note: Mac OSX 10.6 will have maven 2.2.0 installed by defaultNote: Mac OSX 10.5 will have maven 2.0.6 installed by default
1. a. Download Maven 2 (minimum 2.0.6) - http://maven.apache.org/download.html b. Extract to /opt (should create maven-2.X.X folder, where X.X is the sub version) c. Set environment variable: MAVEN2_HOME=/opt/maven-2.X.X d. Add $MAVEN2_HOME/bin to PATH\ e. Set the MAVEN_OPTS environment variable
MAVEN_OPTS='-Xms256m -Xmx960m -XX:PermSize=64m -XX:MaxPermSize=150m'
Windows: XP users have to change the location of their local repository since its path contains spaces (since it is in the user home directory by default). To change the location go to
3. SETUP SUBVERSION 1.5 OR HIGHER
Subversion - http://subversion.tigris.org/
Note: Mac OSX 10.6 will have svn 1.6.5 installed by default Note: Mac OSX 10.5 will have svn 1.5 installed by default
1. a. To check: Run svn --version on the command line http://subversion.tigris.org/project_packages.html Get the subversion binaries and not the source, if possible If there are no binaries for your platform, get the source and use the configuration options --with-ssl and --with-libs b. Extract to /opt (should create subversion-1.5.5) Windows users will want to rename the extracted directory Unix users will probably want to use a package for their flavor c. Set environment variable: SUBVERSION_HOME=/opt/subversion-1.5.5 d. Add $SUBVERSION_HOME/bin to PATH
4. GET MATTERHORN SOURCE
Matterhorn svn repository: http://source.opencastproject.org/svn/products/matterhorn/trunk
1. a. Create a directory to hold the source and your matterhorn install called matterhorn (referred to as MATTERHORN_HOME)
mkdir /opt/matterhorn cd /opt/matterhorn
b. Checkout matterhorn trunk into the matterhorn_trunk dir (referred to as MATTERHORN_SRC) in the MATTERHORN_HOME dir 1.
b.
svn checkout http://source.opencastproject.org/svn/products/matterhorn/trunk matterhorn_trunk
5. SETUP APACHE FELIX OSGI
Apache Felix - http://felix.apache.org
NOTE: These instructions are for Apache Felix. Other OSGi implementations include Equinox and Knopflerfish. Matterhorn is tested on Felix but should work on any modern 4.1 compatible OSGi implementation.
1. a. Make sure you are in the MATTERHORN_HOME dir
cd /opt/matterhorn
b. Download the latest binary release of the "Felix Framework Distribution" http://felix.apache.org/site/downloads.cgi (probably version 2.0.1 or higher) c. Extract the archive in the MATTERHORN_HOME dir and rename the directory to felix
tar -xvf felix-framework-2.0.1.tar.gz mv felix-framework-2.0.1 felix
d. Create the felix load directory
mkdir felix/load
e. Copy over the felix configuration files to the felix conf dir
cp -r matterhorn_trunk/docs/felix/conf/* felix/conf/
NOTE: Remember to check for revisions to the Felix configuration files with each update of Matterhorn. If you are unsure whether the file has been updated, it is safest to simply copy them over each time.
6. COPY RUN SCRIPTS AND SETUP ENVIRONMENT
These scripts setup your environment correctly to execute the matterhorn runtime using the felix OSGi container
1. a. Make sure you are in the MATTERHORN_HOME dir
cd /opt/matterhorn
b. Copy the matterhorn run scripts into the current directory (bat files for win or sh files for unix/OSX)
cp matterhorn_trunk/docs/felix/bin/*.sh .
NOTE: You may need to make the script executable: chmod a+x start_matterhorn.sh c. Add the following environment variables
export FELIX_HOME=/opt/matterhorn/felix export M2_REPO=~/.m2/repository
NOTE: If the "export" command doesn't work for you, use the equivalent command in your shell, or type "bash" to switch to a 1.
c.
bash shell. NOTE: You could also edit the matterhorn start script but the recommended method is to setup the environment variables so the script picks up the changes d. Load the environment variables into the shell by closing the shell and opening a new one, or running:
source ~/.bash_profile
7. BUILD MATTERHORN
1. a. Make sure you are in the MATTERHORN_SRC dir
cd /opt/matterhorn/matterhorn_trunk
b. Build the source using maven
mvn clean install -DdeployTo=/opt/matterhorn/felix/load
Windows: Matterhorn does not yet build without test errors on Windows so in order to build Matterhorn -Dmaven.test.skip= true is specified. Instead of -Dmaven.test.skip=true you can also set -Dmaven.test.error.ignore=true and -Dmav en.test.failure.ignore=true to see which tests fail. NOTE: The Matterhorn project components will be deployed to the load directory of your Apache Felix instance. Felix will automatically reflect any changes made to this directory, even during runtime. Remember to delete everything in the felix/load directory before rebuilding Matterhorn. Maven does not delete previously built bundles when redeploying.
8. INSTALL THE 3RD PARTY TOOLS
Windows: The windows install for the runtime tools is much more complex and is documented here
Linux: Linux users will need ant, xml-commons-apis, zlib-devel or zlibig-dev, patch, byacc and pkgconfig. Linux users having difficulty building libmediainfo can download a binary version.
1. a. Go to the runtime tools dir (in the MATTERHORN_SRC dir)
b. cd opencast-runtime-tools
c. Build the runtime tools
sudo mvn install -Dthirdparty
NOTE: Admin access required: When the sudo command is used, you will need to enter your computer's operating system password.NOTE: Firewall rules: For licensing and patents reasons, the installer gets FFmpeg sources from their subversion repository, which means that you need to have outgoing access to port 3690
9. CONFIGURE MATTERHORN
1. Matterhorn has a number of configuration options which you can generally leave at defaults for development purposes but it is important to be aware of them Overview of Configuration Files Configure Matterhorn Port Number and Base URL Configure Matterhorn Feed Catalog Capture Service Configuration
10. RUN MATTERHORN
1. a. Execute the run matterhorn script from your FELIX_HOME/bin dir
./start_matterhorn.sh
b. Wait for the logs to stop scrolling past at high speed (should take 30 secs to 1 min depending on your machine)
c. 1.
c. Open http://localhost:8080 in your favorite web browser to test things are working NOTE: You can access the Felix system console at http://localhost:8080/system/console (user:admin, pw: admin)
11. UPDATE MATTERHORN SOURCE
After you have installed Matterhorn source code, you may want to periodically update to the latest revision if you are working with the trunk
1. a. run the svn update command from the matterhorn_trunk dir (a.k.a MATTERHORN_SRC) b. after the update is complete, if Matterhorn is running, to stop Felix type shutdown at the command prompt (you may need to press 'Enter' to get the '$' which is the command prompt) where your Felix is running. You can also press 'CTRL-C'. c. delete all files from felix load with the command: rm -rf /opt/matterhorn/felix/load/* d. optionally (e.g. if you have problems), you may also want to delete the temporary files in the "opencast" Temp directory created to run Matterhorn on your machine. This directory can be seen by watching the Felix logs while you ingest a file-on my Mac the path to it is: /private/var/folders/FU/FU Unknown macro: {long string of letters and numbers} -/Tmp/opencast. e. execute the maven build command (see the Build matterhorn section above) f. You may want to ensure your felix configuration is up to date: cp -r /opt/matterhorn/matterhorn_trunk/docs/felix/conf/* /opt/matterhorn/felix/conf/ i. NOTE: You will lose any local changes you made to those files g. run the ./start_matterhorn.sh script to restart Felix
Windows 3rd Party Tools Installation
Installing the 3rd Party tools for Windows
1. Media Tools a. MediaInfo 0.7.19 i. Download binary from SourceForge. ii. Expand the archive b. ffmpeg r20641 Great tutorial for ffmpeg for windows can be found here: FFMpeg on Windows. i. For building ffmpeg you will need 7-zip or similar command line archiver that can work with tar.gz and tar.bz2 archives ii. Ffmpeg can not be build in native windows enviroment so msys + mingw will be set to compile requred libraries and ffmpeg from source iii. You will need to download the following packages: binutils-2.19.1-mingw32-bin mingwrt-3.15.2-mingw32-dll mingwrt-3.15.2-mingw32-dev w32api-3.13-mingw32-dev gcc-core-4.2.1-sjlj-2 gcc-g++-4.2.1-sjlj-2 MSYS-1.0.11 coreutils-5.97-MSYS-1.0.11 msysDTK-1.0.1 msysDVLPR-1.0.0-alpha-1 m4-1.4.12 autoconf-2.63 automake-1.10.2 libtool-1.5.26 iv. Copy M4-1.4.12-MSYS.diff, faad2-2.6.1.patch, install_ffmpeg.sh, msysDVLPR.sh and setup_msys.b at from
Adjusting package manager and msys installation location properties Default archiver is 7-zip located in C:\Program Files\7-Zip\7z.exe. If your path is different or you are using different command line archiver you should adjust ARC_BIN, ARC_OPT and ARC_DEST_OPT in setu p_msys.bat. If you would like to change location of your msys installation you will have to adjust MSYS_PATH in setup_msys.bat and MSYS_PATH in msysDVLPR.sh.
v. Execute setup_msys.bat vi. After seting up your msys environment, msys setup will launch. Installation path is
b.
viii.
program might not be installed correctly you can ignore it.) ix. MsysDVLPR command line will open. Execute script msysDVLPR.sh
./msysDVLPR.sh
x. After script is finished you can close CMD and go to: Start menu -> All Programs -> MinGW -> MSYS -> MSYS. Another CMD will open. Execute install_ffmpeg.sh
./install_ffmpeg.sh
xi. Script will install ffmpeg to
composer.ffmpegpath =
Capture Agent Configuration
Configuring the capture agent can be done in a variety of ways. Default capture properties are set in svn and distributed with the capture agent. They can be found at: capture.properties.
When the capture agent is installed the properties should be loaded into the filesystem which right now defaults to "/opencast/config/capture.properties". This is the file that should be edited by a user if they wish to manually make changes to the capture agent.
This configuration file sets the following:
Location on filesystem to store captures, capture agent configuration data and anything else necessary URL of iCal schedule along with the polling interval to update it and where to store a local copy URL of centralized configuration, polling interval and where to store local copy Capture Agent name and REST endpoint to access its state and recording status Ingest endpoint URL and the retry interval Definition of capture devices, devices source and output filenames
Capture agents can also be configured programmatically by using the java.util.Properties class. The properties that can be set are defined in the interface CaptureParameters.java. Once set they can be passed into startCapture.
For release 0.5 the capture agent can only be deployed to capture from certain devices on certain Linux machines. Therefore, on most other OSes capturing any media will not be possible. Likewise, not all machines that are going to be testing the capture agent code will have any devices setup to capture from. To allow for a full Matterhorn test on any machine there is a way to generate media files from the capture agent without having to capture from any devices. Instead of specifying a device to capture from, simply specify a media file to capture from and the agent will recognize that the file is not a Video4Linux device and instead of trying to use it to capture from, it will copy the media file and get it ready for ingestion with no need to be running Linux or have any devices connected. This way everyone can test the capture agent, not just the people with access to capture hardware. Example media files are checked into the repo at opencast-capture-service-impl/src/main/resources/samples.
Setting up a mock capture only requires a few properties to be set in the capture properties file. # define the names of the devices, or for a mock capture, the files capture.device.names=SCREEN,PRESENTER,MICROPHONE
# setting the input file is the same as setting the device, just choose a file instead of a device capture.device.SCREEN.src=/path/to/input/screen.mpg capture.device.SCREEN.outputfile=/path/to/output/screen.mpg capture.device.PRESENTER.src=/path/to/input/presenter.mpg capture.device.PRESENTER.outputfile=/path/to/output/presenter.mpg capture.device.MICROPHONE.src=/path/to/input/microphone.mp3 capture.device.MICROPHONE.outputfile=/path/to/output/microphone.mp3
By setting the *.src properties to files instead of devices the Capture Agent will simply copy the input files to the output locations to be ready for ingestion. Capture Service Configuration
This document describes the configurable properties for the Matterhorn capture agent service.
PARENT CONFIGURATION FILE
name capture.config.url
description Location of configuration file
name capture.config.polling.interval
description Polling interval
name capture.config.cache.url
description Location of configuration cache
name capture.config.filesystem.url
description
LOCAL FILESYSTEM
name capture.filesystem.config.url
description Location of configuration file
name capture.filesystem.capture.url
description Location of capture folder
name capture.filesystem.cache.url
description Location of cache folder
name capture.filesystem.volatile.url
description Location of temp folder
name capture.filesystem.cache.capture.url
description SCHEDULER
name capture.schedule.url
description Location of schedule service
name capture.schedule.polling.interval
description Polling interval
name capture.schedule.cache.url
description Location of schedule cache
AGENT DESCRIPTION
name capture.agent.name
description Name
name capture.agent.state.endpoint.url
description Location of state service
name capture.agent.state.polling.interval
description Polling interval
RECORDING DESCRIPTION
name capture.recording.state.endpoint.url
description Location of state service
name capture.recording.id
description ID
name capture.recording.root.url
description Location of recording(s) folder
name capture.recording.end
description Time of recording completion
INGEST
name capture.ingest.endpoint.url
description Location of ingest service
name capture.ingest.retry.interval
description Polling interval
DEVICE DESCRIPTION(S)
Device properties are configured using prefix + device name + device property (e.g. capture.device.SCREEN.codec.properties.codec. properties.bitrate).
name capture.device.names
description CSV format
name capture.device. description Prefix
name capture.device.
description Location of recording file or device file (e.g. /dev/video0)
name capture.device.
description Device stream filename
name capture.device.
description Device codec
name capture.device.
description Device codec bitrate
LOCAL FILESYSTEM CLEANER
name capture.cleaner.mindiskspace
description Minimum diskspace threshold
name capture.cleaner.maxarchivaldays
description Maximum time threshold
FILENAMES
name capture.stopped
description Capture filename
name capture.ingested
description Ingested capture filename
name media.zip
description Ingested capture archive filename
Configure Matterhorn Feed Catalog
This document will help you understand and configure the Matterhorn RSS and Atom feed catalog. The catalog supports multiple versions of each syndication format.
ACCESS THE FEED CATALOG
The catalog is located at:
http://
Individual feeds are located at:
http://
DEFAULT FEEDS The catalog contains the following default feeds:
Latest
http://nightly.opencastproject.org/feeds/[atom|rss|*]/
Need an example? http://nightly.opencastproject.org/feeds/atom/0.3/latest
Series
http://nightly.opencastproject.org/feeds/[atom|rss|*]/
Aggregation
http://nightly.opencastproject.org/feeds/[atom|rss|*]/
This feed is currently hard-coded to aggregate the first and second series.
Custom
http://nightly.opencastproject.org/feeds/[atom|rss|*]/
What's the query syntax? The custom search query is a lucene query, matched again Java's MessageFormat using solr. One could specify:
The feed would be available at http://
CUSTOMIZE THE FEED CATALOG
The Matterhorn feed specifications are located in:
Below is the default specification for a feed of the latest published episodes:
FEED PROPERTIES
The following properties are shared by all feed specifications:
Name feed.uri
Description The feed location/identifier
Name feed.selector
Description The feed route pattern (e.g. latest)
Name feed.name
Description The feed title
Name feed.description
Description The feed description
Name feed.copyright
Description The feed copyright notice Name feed.home
Description The feed catalog homepage (e.g. {{ http://www.opencastproject.org
}})
Name feed.selector
Description The feed route pattern
Name feed.cover
Description The feed image
Name feed.rssflavor
Description The RSS enclosure route pattern (e.g. engage/rss)
Name feed.atomflavor
Description The Atom enclosures route pattern (e.g. engage/atom)
Name feed.rsstags
Description A comma, semi-colon or space-separated list of tags used to filter available enclosures
Name feed.atomtags
Description A comma, semi-colon or space-separated list of tags used to filter available enclosures
Name feed.entry
Description The route pattern used to generate links to individual enclosures (e.g. /engage/ui/watch.html?id={0})
Configure Matterhorn Port Number and Base URL
This document presents two ways to change the port number as well as the base URL on which the Matterhorn HTTP service runs.
CHANGE THE PORT NUMBER
Felix
1. Create a file named
# OSGi HTTP services port org.osgi.service.http.port=80
root access is required in order to run on Port 80.
Apache HTTPD Proxy
1. Edit Apache's httpd.conf 1.
ProxyPass / http://localhost:8080/ ProxyPassReverse / http://localhost:8080/
CHANGE THE BASE URL
1. Edit
# Base URL (for example http://matterhorn1.telavivuniv.org:80) serverURL=http://matterhorn1.telavivuniv.org
Create a custom workflow
This document will help you get started with creating your own Matterhorn workflows. For a more detailed discussion, including in-memory Java implementations, please read our Workflow Cookbook.
ANATOMY OF A WORKFLOW
Matterhorn workflows can be declared in xml document form. The name of the document should follow the pattern:
For example:
compose-distribute-publish.xml
A Matterhorn workflow should follow the pattern:
REGISTER A WORKFLOW
The Matterhorn workflow service will automatically register any workflow documents placed in the Felix load directory:
The Matterhorn user interface does not currently display additional workflows.
CREATE A SIMPLE WORKFLOW
This sections will walk you through creating a workflow that does the following: Describe the Workflow Inspect the Media Encode to QuickTime Encode to Thumbnail and Poster Frame Distribute the Media Publish Metadata to Search Index
Describe the Workflow
Start by naming the workflow and giving it a meaningful description:
Inspect the Media
Our first operation will be to inspect the media for technical metadata, such as format and length:
...
Failed Operations The fail-on-error attribute is a boolean determining whether the workflow will throw an error to the exception-handler-workf low or simply proceed with the remaining operations.
Encode to QuickTime The next operations will encode the media to the QuickTime/MPEG-4 .mp4 format:
...
...
Tags The target-tags attribute tags the resulting media for later use as input for other operations, using the source-tags attribute (see #Distribute the Media).
Encoding Profiles The encoding-profile attribute refers to an encoding profile defined in the Matterhorn composer service properties file.
Encode to Thumbnail and Poster Frame
The next operations will create thumbnails and poster frames from the media:
...
...
...
The time attribute determines which frame of the source media is used.
Distribute the Media
The next operation copies the encoded media to the Matterhorn distribution channel:
...
...
...
...
Tags The distribute operation uses all media tagged as rss, atom or engage as input. Publish Metadata to Search Index
The last operation published the media metadata to the search index:
...
...
...
...
...
Tags The publish operation uses all documents tagged as publish as input.
TEST YOUR WORKFLOW
The easiest way to test your workflow is to use the workflow service REST documentation at http://nightly.opencastproject.org/workflow/rest/docs.
1. Scroll down to "POST /start" and click on the "Testing form" link.
2. Copy and paste the complete workflow definition into the "definition" field and click "submit." 2.
key="source-audio-flavor">presentation/source
fail-on-error="true" exception-handler-workflow="Default Error Handler" description="Encode screen to thumbnail">
2.
3. Open the Admin Tools and navigate the recordings dashboard to view the status of your workflow.
4. Open the Matterhorn Media Module to see your published media.
Engage media player installation
The Engage media player - the code and all you need to get started is available after you checkout matterhorn from the svn.
To get a running Matterhorn media player instance please go to the directory where you have previously downloaded and installed matterhorn.
Building the Engage media player.
cd
Maven will download all you need to start working with or configure the media player according to your needs.
You will find all files needed for the accessible media player inside
To start simply open the index.html page found in the same folder
A list of already implemented accessibility features is available here Accessibility Features
Project docs will be created in the modules /target/site folder:
cd
Technology stack:
Pure HTML/Javascript in combination with a Flash 10 based video container. A AJAX bridge is used to combine the strength and cross-platform capability of Flash video and the accessibility of pure HTML. This bridge can also be used for other video containers like Quicktime or HTML5.
Open Source Media Framework http://www.opensourcemediaframework.com/index.html Flexmojo http://flexmojos.sonatype.org/ FlexUnit4 testing framework http://opensource.adobe.com/wiki/display/flexunit/Downloads ASMoc http://asmock.sourceforge.net/
Tools and IDEs:
Eclipse + Flex SDK http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK see also Tools and HOWTOs to improve the quality for non-java development
Supported captions format:
W3C DFXP http://www.w3.org/TR/ttaf1-dfxp/ Install Matterhorn Capture Agent
This guide describe how to install and configure the Matterhorn Capture Agent
Install Ubuntu 9.04 Check out Matterhorn Source (Steps 1-4) goto
This document will help give an overview of the existing Matterhorn configuration files and their roles.
This document is currently no more than a list, but will eventually become a true overview.
FELIX CONFIGURATION
name config.properties
description The primary Felix configuration file
Bundle Configuration Properties
name org.osgi.service.http.port
description Port number of http services
name org.osgi.service.http.port
description Port number of https services
name org.osgi.service.http.secure.enabled
description Toggle https services
[true|false]
Opencast Matterhorn Configuration General
name serverUrl
description URL of Matterhorn http services
name testMode description Toggle user interface tests and mock resources
[true|false]
Capture
name capture.ingest.endpoint.url
description URL of Matterhorn ingest REST endpoint
Composer
name composer.ffmpegpath
description Path to ffmpeg binary
Inspect
name inspection.analyzerclass
description Java class used by the media inspection service
name inspection.mediainfopath
description Path to mediainfo binary
Search
name search.searchindexdir
description Path to search index files
Workspace
name workspace.rootdir
description Path to the workspace root directory
name workspace.workingfiledir
description Path to the working file root directory
name log4j.logger.org.opencastproject
description Log level of Matterhorn log files
name log4j.appender.file.File
description Path to the Matterhorn log file
CAPTURE SERVICE OPENCAST-CAPTURE-SERVICE-IMPL
./src/main/java/resources/config/
name calendar_polling_scheduler.properties
description
name capture.properties
description name capture_scheduler.properties
description
name ingest_scheduler.properties
description
name state_update_scheduler.properties
description
MEDIA COMPOSER SERVICE OPENCAST-COMPOSER-SERVICE-IMPL
./
name encoderengines.properties
description
name encodingprofiles.properties
description
name episode.properties
description
name episode.properties
description
CONDUCTOR SERVICE OPENCAST-CONDUCTOR
./src/main/java/resources/workflows/
name compose-distribute-publish.xml
description
name default-error-handler.xml
description
DATABASE SERVICE OPENCAST-DB
./src/main/java/org/opencastproject/db/
The Activator.java file contains the database path, url and login.
SCHEDULER SERVICE OPENCAST-SCHEDULER-IMPL
./src/main/java/resources/config/
name captureagentmetadatamapping.properties
description
name dublincoremapping.properties
description SEARCH SERVICE OPENCAST-SEARCH-SERVICE-IMPL
./src/main/java/resources/solr/conf/
STREAM SERVICE OPENCAST-STREAM
./src/main/java/resources/
name access.properties
description
name password.properties
description
Register a Capture Agent
This document will help you register a Matterhorn capture agent with the capture administration user interface.
1. Register the agent a. Post the agent name and state to the capture administration service.
curl --data agentName=
b. Check the response
2. Verify that the agent is registered a. Get the list of known agents
http://nightly.opencastproject.org/capture-admin/rest/GetKnownA gents
b. Check the response
IDLE CAPTURING UPLOADING UNKNOWN
Technology Stack
Technologies
JAVA
Matterhorn is written for Java Platform, Standard Edition,
the industry standard for implementing enterprise-class service-oriented architecture (SOA) and next-generation web applications. 1
Please visit the Sun Developer Network for more information.
JSR 222: Java Architecture for XML Binding (JAXB) 2.0
JAXB uses annotations to marshal Java classes to and from XML Schema. Please visit JSR 222 at JCP for more information.
JSR 224: Java API for XML-Based Web Services (JAX-WS) 2.0
JAX-WS uses annotations for the development of Web services built according to the document-style (primarily "document/literal wrapped" SOAP ) architectural style. Please visit JSR 224 at JCP for more information.
JSR 311: Java API for RESTful Web Services (JAX-RS)
JAX-RS uses annotations for the development of Web services built according to the Representational State Transfer (REST) architectural style. Please visit JSR 311 at JCP for more information.
BUILD
Apache Maven
The Matterhorn project is built using Apache Maven, which, by encouraging "convention over configuration," brings order and simplicity to the development process.
Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. 2
The Apache Maven homepage includes The 5 minute test and a Getting Started Tutorial to get you up and running. Sonatype has published an online edition of Maven: The Definitive Guide.
Maven Bundle Plugin
The Matterhorn OSGi bundles (see Apache Felix) are built using the maven-bundle-plugin. Please visit maven-bundle-plugin for more information. We also recommend reading How to build OSGi bundles using Maven Bundle Plugin.
Maven Eclipse Plugin
The Matterhorn project Eclipse IDE files are generated using the maven-eclipse-plugin. Please visit maven-eclipse-plugin for more information.
Apache Ant
The Matterhorn project Maven plugin goals partially defer to Apache Ant. Please visit Apache Ant Project for more information. RUNTIME
Apache Felix
Matterhorn uses the Apache Felix implementation of the OSGi R4 Service Platform
to define a dynamic service deployment framework that is amenable to remote management... it is ideally suited for any project that is interested in principles of modularity, component-oriented, and/or service-orientation. 3
Dr. Richard S. Hall has published an introduction to OSGi, entitled OSGi R4 Service Platform: Java Modularity and Beyond. The Apache Felix homepage includes an Apache Felix OSGi Tutorial "to illustrate most of the features and functionality offered by the OSGi framework." Neil Bartlett has given a presentation entitled OSGi for Application Developers which we also recommend viewing.
MEDIA ANALYSIS
Matterhorn leverages several media analysis tools to extract meaningful data from video and audio files.
OCRopus
OCRopus(tm) is a state-of-the-art document analysis and OCR system, featuring pluggable layout analysis, pluggable character recognition, statistical natural language modeling, and multi-lingual capabilities. 4
OCRopus is written in C++. Please visit OCRopus for more information.
Sphinx-4
Sphinx-4 is a speech recognition engine written in Java. Please visit Sphinx-4 for more information.
METADATA
Matterhorn leverages several metadata standards to store and retrieve meaningful data about video and audio files.
Dublin Core
Matterhorn marshals and unmarshals static metadata using a subset of the Dublin Core metadata standard. Please visit Dublin Core Metadata Initiative for more information.
MPEG-7 or Multimedia Content Description Interface
Matterhorn marshals and unmarshals time-based metadata using a subset of the MPEG-7 metadata standard. Please visit MPEG-7 for more information.
Architecture cf. Architecture
REFERENCES
1. "Java EE at a Glance":http://java.sun.com/javaee/index.jsp 2. "Apache Maven":http://maven.apache.org 3. "Apache Felix":http://felix.apache.org 4. "OCRopus":http://code.google.com/p/ocropus Architecture
MATTERHORN SERVICE USAGE SCENARIOS
As the service design is improving, this section will be populated with documents that are describing the big picture.
There are basically two ways in which the matterhorn services can be used. With matterhorn following service oriented design principles, the services can either be used independently, following external orchestration principles or taking advantage of the whole service topology that forms the matterhorn media capture and process engine.
Using matterhorn service orchestration
The following documents will show how the serices are meant to be used in the media capture and process setting.
Ingest
Getting media and metadata into the system is the first step when it comes to using the matterhorn system. The document provides a short tour through the services that are involved, namely MediaIngestService, WorkingFileRepository, MediaInspectionService, SiteConductorService and WorkflowService.
Ingest Service Orchestration
Distribution
Distributing content in Matterhorn means publishing to a number of distribution channels, each of them implementing the same distribution service api. The linked document describes how these channels will be used to make distribution work and will also show how their implementation will differ from each other.
Distribution Service Orchestration
Distributing to the Matterhorn Portal
When it comes to distribution services, there is one particular implementation of the distribution service api that delivers the contents of a media package to the matterhorn portal. The Matterhorn Portal is considered to be the default way to distribute content in an out-of-the-box installation of matterhorn.
Distributing to the Matterhorn Portal Ingest Overview
Ingest Service Orchestration
The process of ingesting recorded material into Matterhorn involves a number of services:
Media Ingest Service MediaInspectionService WorkingFileRepository SiteConductorService WorkflowService
The following diagram shows how this orchestration works:
Creating a media package
First, clients will ask the MediaIngestService to create an empty media package (1) by calling createMediaPackage. The service implementation will generate a package identifier that it will return to the caller. In addition, a directory will be created that takes all the package elements that will be added during subsequent calls to the ingest service.
Adding package elements
By calling addMediaPackageTrack, addMediaPackageCatalog and addMediaPackageAttachment, the package elements are added to the media package (2).
Moving the package elements to the WorkingFileRepository
After a call to ingest, the package elements are being downloaded to the ingestor inbox and then moved to the WorkingFileRepository in order to make them locally available (3).
Inspecting the package elements
Then the media package is assembled by calling inspect on the MediaInspectionService for each package element (4) and integrating the extracted technical information (5). That information will mainly consist of technical metadata like bit and framerate, duration, codecs etc.
Publishing the media package
Once the media package has been fully compiled, it is picked up by the SiteConductorService (6), a per-site-implementation that is able to decide on what to do next with that media package.
Executing the required workflow
Depending on what the implementation looks like, the conductor service will call the WorkflowService (7) that will in turn make one or more calls to other services (8) in order to have the media package processed in the desired way.
Processing the results
Finally, the workflow service will report back to the SiteConductorService (9) to indicate that processing has come to an end. Distribution Distribution service orchestration
Distributing content in Matterhorn means publishing to a number of distribution channels, each of them implementing the same distribution service api. This document describes how these channels will be used to make distribution work and will also show how their implementation will differ from each other.
WorkflowService ITunesUDistributionService YouTubeDistributionService SakaiDistributionService FeedDistributionService MatterhornPortalDistributionService
Getting a hold of all of the distribution services
First, the WorkflowService will try to get a list of distribution services that are involved in the current distribution workflow (1). That selection will be made on a per site basis, either through configuration or implementation of a custom workflow.
Distributing the media package
By calling publish on each of those services (2), one after the other is requested to copy the relevant distribution content of the media package in question to the distribution channel, an operation that might vary according the nature of the channel.
To illustrate the differences, the next paragraphs will try to cover a few of those scenarios.
Distributing to a simple channel
In the example, the media package is published to YouTube, which involves uploading the flash distribution formats of the source tracks as well as an excerpt of the static metadata like title, author and recording date as well as a short description (3).
Distributing metadata only
Taking a learning management as an example, this channel would accept a standardized metadata document (e. g. Dublin Core) and a link to the server that is hosting the actual media formats. This means that the distribution service needs to post the metadata document to the learning management system and also move the distribution files to a local download and/or streaming server, since usually learning management systems are not built to serve audio and video content.
Distributing to complex channels iTunes U is one example of a more complex distribution channel. It takes input either via rss feeds or via soap, making distribution a management task of its own. Since the rss frontend could easily be served using the FeedDistributionService, let's focus on the soap interface for now. Depending on the country, the implementation also differs in that the content needs to be served locally or be moved to the akamai network.
So the service implementation would first need to move the distribution files into place, which means either copying them to the akamai network or to some local download or streaming platform. Then, it would need to figure out using the static metadata that is part of the media package which tab in iTunes it needs to publish to. Depending on wether that tab is already present, it would need to be created beforehand.
Distributing to the Matterhorn Portal
The Matterhorn Portal is the default distribution channel for out-of-the-box installations of Matterhorn. The service implementation moves all the distribution media and metadata to the portal, so that all of the data can be leveraged to support a powerful user interface featuring an evolved media player.
See distributing to the matterhorn portal for a detailed description of that distribution service implementation.
Distributing as rss and/or atom feeds
The feed distribution channel provides an easy endpoint for integration with any thirdparty system wanting to connect to Matterhorn. The implementation of the service is straight forward, copying the distribution media files to local download and/or streaming servers and creating an rss and/or atom feed out of the static metadata of the media package. PortalDistribution
Distributing to the Matterhorn Portal
When it comes to distribution services, there is one particular implementation of the distribution service api that delivers the contents of a media package to the matterhorn portal. The Matterhorn Portal is considered to be the default way to distribute content in an out-of-the-box installation of matterhorn, and publishing to it involves the following services:
WorkflowService MatterhornPortalDistributionService DownloadService StreamingService SearchService
The following diagram shows how distribution to the matterhorn portal is working with regards to the services.
Calling the distribution service
The WorkflowService (1) first calls the publish operation on the MatterhornPortalDistributionService (2), thereby handing over the complete media package.
At this point in time, the package not only contains pointers to the original recordings and metadata catalogs, but also to the encoded distribution formats and the (isochronic) metadata that has been collected by running the package through the media analysis service.
Moving the media to the distribution servers
The distribution service will then copy those media files that are slated for distribution from the location indicated in the media package to the distribution servers, which will usually mean copying download formats to the DownloadService (3) and streaming formats the the respective Str eamingService (4), both of which are part of the matterhorn portal.
Additional formats such as cover images might need to be copied to the download service as well.
Updating the search index
Once all the distribution media formats are in place and ready to be downloaded and/or streamed, the distribution service will call the SearchServ ice and have it update the search index (5), thereby making the newly published episode available to search queries, recent episodes lists and rss feeds that might be provided by the portals user interface (6). Capture Agent Job Sequence
CONCEPTUAL STRUCTURE
The class CaptureAgentImpl provides all the methods that provide the agent's functionality. In particular, it sets out methods for starting and stopping captures, serialize the MediaPackage, zip all the relevant files and send them (ingest them) to the core. Those are the methods which provide the actual services, and therefore they are called Service Methods. A complete recording process consists of a sequence of those service methods executed successfully in the correct order: startCapture -> stopCapture -> createManifest -> zipFiles -> ingest
If we want to schedule a recording, however, we need some kind of an infrastructure to trigger the different tasks timely, accurately and in the proper sequence. This infrastructure is made up of Jobs: methods that are triggered by a certain scheduled event that call the actual Service met hods appropriately. In our implementation, also, each method schedules the next Job in the workflow, once it has succesfully run the Service. This approach allows a better code division and facilitates testing (the Jobs in the workflow are chained together, but any single Service can be called and tested separately). Internal server error
DETAILED GRAPH Internal server error
Call code Job Input Parameters
1 ?
2 StartCaptureJob Properties file with the properties related with this capture MediaPackage with all the attachments included in the iCal
CaptureAgent object to provide the service methods
c StopCaptureJob CaptureAgent object to provide the service methods RecordingID to identify the recording
f IngestJob CaptureAgent object to provide the service methods RecordingID to identify the recording
Tools
IDES
Eclipse Guide (OLD Matterhorn Project **DON'T USE**) ide tool
Maven Nexus Server (OLD Matterhorn Project **DON'T USE**) ide tool
MATTERHORN SUBVERSION REPOSITORY
Matterhorn Subversion Repository (OLD Matterhorn Project **DON'T USE**) svn tool
JIRA
Create Jira Stories, Tasks and Sub Tasks (OLD Matterhorn Project **DON'T USE**) jira tool
Navigate Jira Issues (OLD Matterhorn Project **DON'T USE**) jira tool
Jira Issue Types (OLD Matterhorn Project **DON'T USE**) jira tool
Jira Overview (OLD Matterhorn Project **DON'T USE**) jira tool
CRUCIBLE
Crucible (OLD Matterhorn Project **DON'T USE**) crucible tool
CONFLUENCE
Confluence (OLD Matterhorn Project **DON'T USE**) tool confluence
Gliffy (OLD Matterhorn Project **DON'T USE**) tool confluence
Confluence
Enterprise wiki software for sharing and editing content, online collaboration, knowledge management, document management, file sharing, and more.
The Matterhorn project wiki is located at https://wiki.opencastproject.org. Please read the Confluence Notation Help or the Confluence Documentation for more information.
GENERAL CONFLUENCE TIPS
Confluence Notation Help Atlassian's Confluence documentation pages
SETTING UP WATCHES
It can be helpful to receive email notifications every time pages or spaces in Confluence that you are interested in change:
Watching a Space Watching a Page
The 'Watches' page displays a list of all pages and spaces you are currently watching. You will be sent email notifications when changes are made to your watched pages and spaces.
Managing Watches
DAILY REPORT
When you subscribe to the daily report, you will be sent an email with a summary report of changes in all spaces visible to you. Users who updated their personal profile will also have their name listed in the daily report.
Subscribing to Daily Report
CREATING A GLIFFY ILLUSTRATION Choose Add -> Diagram from any page to create a Gliffy. There are lots of great templates available: Flow chart, BPMN, UML, Entity-Relationship, Network, User Interface, Floorplan, Page Images, Basic Shapes and I'm sure you can add more. More details on Gliffy
COPYING A GLIFFY ILLUSTRATION
1. From the page where the original Gliffy illustration is located, go to the attachments tab 2. Click the Download All link and open the downloaded zip file 3. Open the Gliffy file (e.g. "My Original Gliffy") and save as a new file with no extension 4. Upload that new file to the attachments page of the page you'd like your new copied Gliffy to go 5. Click the Edit link for the new file a. Set the Content Type to text/xml b. Set the Name to how you want it to be accessed from your wiki (e.g. "My Copied Gliffy") 6. Insert the reference to the Gliffy on your page (e.g. {gliffy: name=My Copied Gliffy})
LINKING TO CONFLUENCE PAGES
When linking to other pages on Confluence, it is best to simply use the page name like this in the wiki markup to create the link: [Page Name].
Try not to text for the name, which you can do like this: [My version of page name | Page Name].
If you follow this best practice, then when page names are updated the wording on the links to them will automatically be updated, too. Gliffy
Gliffy is a tool for creating diagrams. There are a number of useful templates to choose from.
Create an illustration
1. Select Add > Diagram from any page. 2. Select a template.
Copy an illustration
1. Select Tools > Attachments from the illustration's current page. 2. Select "Download All." 3. Open the .zip file. 4. Copy the Gliffy file as a new file with no extension. 5. Select Tools > Attachments from the illustration's destination page. 6. Upload the new file. 7. Select "Edit" to modify the uploaded file. a. Type "text/xml" in the "New Content Type" field. b. Type a new name in the "New Name" field. 8. Add a reference to the illustration in the destination page:
{gliffy:name=My New Gliffy}
Crucible
Crucible integration is still forthcoming
Once a contributer (author) is ready to submit code, they should add a crucible review ticket from their Jira task. Should they assign the review to a developer associated with the component and/or leave the review open for anyone to take on? Utlimately it is the component lead's (moderator) responsibility to summarize the review before committing to trunk. The moderator will assess the risk associated with unresolved code reviews, and ultimately determine whether to commit the code or not.
All code commits should include the related jira issue key in the commit message. This will essentially map the commit and jira issue, thus enabling developers to refer to the specific changeset within the related jira issue (via the Fisheye tab). It also allows developers to conveniently create a code review for the specific changeset directly from their jira issue. Unknown macro: {html}
Eclipse Guide
IMPORT THE MATTERHORN CODE STYLES INTO ECLIPSE:
Please ensure you are adhering to the project best practices and code styles regardless of your development environment.
Installing the files below in your eclipse installation will allow you to automatically adhere to the project spec.
Window > Preferences > Java > Code Style > Formatter > Import docs/eclipse_settings/opencast-codestyle.xml
Window > Preferences > Java > Code Style > Code Templates > Import docs/eclipse_settings/opencast-codetemplate.xml
Window > Preferences > Java > Code Style > Organize Imports > Import docs/eclipse_settings/opencast.importorder
IMPORT THE MATTERHORN PROJECT INTO ECLIPSE:
Eclipse is the development tool that most of the developers on the project are using. This document gives a short introduction on how to integrate the technologies that are being used throughout the project with this integrated development environment (IDE).
There are 2 methods of importing the project files into eclipse. Both methods (maven plugin for eclipse and maven eclipse plugin) are detailed below. If you are working on a single module then the easiest thing to do is use the maven plugin for eclipse and import only that module. This plugin can also import the entire project but that takes a lot longer to import and will slow down eclipse substantially.
Using the maven plugin for Eclipse (Maven2Eclipse)
Maven2Eclipse is an Eclipse plugin that exposes all of the maven functionality to the developer through context menu and is also able to handle the dependencies behind the scenes. Please read Developing with Eclipse and Maven for more information.
Install the plugin
In Eclipse, go to "Help", "Install New Software...". Make sure you are working with the maven update site at m2eclipse.sonatype.org/update. Install everything under Maven Integration, then restart Eclipse. If you get an error referencing org.eclipse.ui, you may need to also add the update site http://download.eclipse.org/tools/ajdt/34/update
Configure the plugin
In order to configure your plugin, open the Eclipse preferences and go to the Maven register. For your convenience, we recommend checking "Download Artifact Sources", "Download Artifact Javadocs" and "Download repository index updates on startup":
I had problems using the embedded version of maven that comes with the plugin. Therefore I recommend configuring the plugin to your system maven installation. On Mac OS X, the installation is at /usr/local/share/maven. If you used MacPorts to install maven, the installation is in /opt/local/share/java/maven2. Configure your projects
Make sure you have imported all of the Matterhorn service projects as described in the getting started section. Right click on any of these projects, then go to the new M2 Maven submenu, which should look similar to the image on the right.
You now have to enable Maven for each of the projects, which you can do by selecting all of them and choosing the Enable Dependency Management command from the submenu we just looked at.
The process will take some time to complete, but you will finally end with a small "M" sitting ontop of all of your projects, indicating that they are now configured with Eclipse Maven support.
In addition, the Maven context menu now contains many commands that allows you to leverage Maven.
Benefits
Maven will now make sure that your project references are corretly handled, so if you are changing a Java interface in a service api project, you no longer have to go to the commandline to mvn install, then refresh in Eclipse just to see that you need to add the implementation of that change in the implementation project of the service. The maven plugin will do that for you.
Amongst other things, the plugin provides support for adding dependencies, updating snapshot dependencies, edit the Maven POM etc.
In addition, the Run As context menu gained some functionality with entries for many of the common maven targets. By right clicking a project, you could thereby install the project in the local maven repository or simply run the unit tests by choosing Run As -> Maven build.
Adding a deploy target
So you still have to go to the commandline to do the mvn install -DdeployTo=
First, be sure to select one of the projects and choose Run Configurations... from Eclipse's Run menu. Add a new Maven build by selecting Mave n build and hitting the plus icon in the upper right corner of the screen.
Now just fill in the parameters as seen in the screenshot. Putting the variable for the project location (project_loc) into the base directory field allows you to run that target for all of the projects, not only for one. Make sure to add the parameter deployTo and configure it with the path to the file load facility of local Felix installation.
Additionally, I would recommend switching to the Common tab and checking both Display in favorites menu entries.
You are done! Press "Apply" and then "Run", and you should first see the console output of the maven build and then the project's jar file should show up in the Felix load directory.
Using the Maven eclipse plugin
As an alternative, you can generate eclipse project files using the maven eclipse plugin. This is more error prone than the method above but is provided here as an alternative method.
Generate Eclipse IDE files
The Maven Eclipse Plugin is used to generate Eclipse IDE files (*.classpath, *.wtpmodules and the .settings folder) for use with a project.
cd
File > Import > General > Existing Projects into Workspace > Next Select root directory >
Jira
JIRA is a highly popular bug tracking, issue tracking and agile project management software application.
The Matterhorn project uses Jira to organize tasks into iterations, as well as provide an overview of the status of the project. Please visit the Matterhorn Jira at https://issues.opencastproject.org/. Create Jira Stories, Tasks and Sub Tasks Estimate and Log Jira Issues Jira Issue Types Jira Overview Navigate Jira Issues Create Jira Stories, Tasks and Sub Tasks
Avoid Task overload! Try and create Tasks only during iteration planning.
Associate a Task with a Story Card
1. Open Greenhopper and select a Task from the Task View.
2. Select "Link this issue to another issue". 3. Select "is related to Story" from the "This issue:" pulldown menu.
4. Enter the Story Card issue number (e.g. MH-74) in the "Issues:" text field.
5. Select the "Link" button.
Create a Sub Task for a Task
1. Open Greenhopper and select a Task from the Task View. 2. Select "Create Sub-Task". 3. Describe the Sub Task in the fields provided.
4. Select "Submit"
We recommend also relating Sub Tasks to Tasks, to simplify navigation.
Associate an Issue with a Release
1. Open Greenhopper and select an issue link (e.g. MH-74) 2. Select one or more releases under the "Affects Versions/s" select menu to indicate the context of the issue. 3. Select one or more releases under the "Fix Version/s" select menu to indicate when the issue will be resolved.
Your selections will be reflected in the issue overview.
Estimate and Log Jira Issues
This video explains how to plan and track the hours used to resolve issues: Unknown macro: {html}
Jira Issue Types Story Card
A Story Card is a requirement, functional or otherwise, which describes features or goals. An Acceptance Test describes what it means to complete the story. Story Points estimate the size and complexity of a story.
Task
A Task is a development task, ideally linked to a story card, and should be created during iteration planning. An Original Estimate is the number of hours needed to complete the task, including Sub Tasks. Developers use the Description field to describe technical details.
Sub Task
A Sub Task is the child of a larger Task.
Infra/IT Request
An Infra/IT Request is a non-developmental, infrastructural task.
Bug
A Bug is a defect in the application.
Community Feature Request
A Community Feature Request is a proposed requirement. Jira Overview
This video will help you get started with Jira:
Please note that some of the material in this video has since been deprecated
Unknown macro: {html}
Navigate Jira Issues
View Issues
Select the Greenhopper tab to see an overview of Matterhorn issues. This list can be filtered in a number of ways.
View Version
The View Version pulldown menu filters issues into iterations, releases etc.
Context
The Context pulldown menu filters issues into types, components, teams etc. Use this filter to plan releases and monitor the product backlog, either at the project level or that of an individual team or component. Story Cards
A Story Card lists all Tasks and Subtasks associated with it.
Tasks
A Task lists all Subtasks associated with it.
Hierarchy
Story Cards describe a requirement, which is then realized through Tasks, broken down into more granular Sub Tasks. View an issue's associations by selecting "Hierarchy" from the issue disclosure triangle.
A graphical representation of the Story Card, Task and Sub Task relationships will be displayed.
Matterhorn Subversion Repository
SVNROOT | |- products | |- matterhorn |- modules | |- opencast-workspace | |- opencast-encoder-service | |- etc. |- contribs | |- great-tool | |- another-great-tool
Products
The complete Matterhorn suite is listed under the products directory. Each product uses an svn:externals file to reference all of its associated modules.
Modules
Individual modules are listed under the modules directory. Each module is articulated into trunk, branches and tags.
Contributed Modules
Contributed modules are listed under the contribs directory. Each contributed module is articulated into trunk, branches and tags.
Privileges trunks and branches are maintained by the project leads, who work with the release manager to identify tags for inclusion in tagged product s. Please submit patches to the Matterhorn Jira if you wish to commit code to a trunk or branch.
Once you have been granted the right to commit code, you will want to switch to the secure Subversion repository: cd
Maven Nexus Server
SERVER
The maven nexus server maintains a copy of all the Java dependencies used by matterhorn and other opencast projects that choose to use it. The server is located here: http://repository.opencastproject.org/nexus
It uses a separate login from the one used for the other opencast servers so you will need to get an account from the admin. It is setup to automatically pull from a series of central servers if any libraries are requested which cannot be found locally. These libraries will be cached into the nexus server at that point. We also maintain a 3rd party repository which can have artifacts placed directly within it. This is only needed for artifacts not available in the central repositories. http://repository.opencastproject.org/nexus/content/repositories/thirdparty/
USING THE OPENCAST MAVEN REPOSITORY
The matterhorn main pom.xml provides examples of how to configure a project to use the opencast repository. There are 2 main repositories which should be accessed. Public releases: http://repository.opencastproject.org/nexus/content/groups/public/ Public snapshots: http://repository.opencastproject.org/nexus/content/groups/public-snapshots/
ADDING LIBRARIES TO THE REPOSITORY
1. Login as an admin to http://repository.opencastproject.org/nexus 2. Select Repositories 3. Choose the 3rd party repository 4. Select the Artifact Upload tab 5. Fill in the details and upload the file 6. Click on Upload Artifact Work Practices Committers Practices Common Processes Agile Software Development Licenses Processes Communication Frontend best practices Javascript coding style Java best practices Management Processes Conducting "Scrum of Scrums" REST practices Submitting a Patch to Matterhorn Committers Practices
Developers with commit rights to Opencast's subversion code repository must remember and adhere to the following:
1. Check out via https rather than http. To check whether your checkout is from the correct URL, try: $ svn info Path: . URL: https://source.opencastproject.org/svn/products/matterhorn/trunk ...
2. Ensure that you have properly configured your subversion client. Copy the opencast subversion configuration file to the following file, depending on your platform:
Windows %USERPROFILE%\Application Data\Subversion\config
or %USERPROFILE%\AppData\Roaming\Subversion 2.
Unix or Linux or Mac ~/.subversion/config
3. Your first commit should be to add your name as a developer to the root pom.xml NOTE: Add your
You may eventually become a Matterhorn Jedi. Please refrain from using your force powers against other commiters
Common Processes Agile Software Development Acceptance Tests Product Owner Meetings User Stories Video- Scrum Methodology Overview Licenses 3rd Party Licenses and Software Applying ECL License To Code Managing Third Party Licenses and Software Processes Communication Profile Pages in Confluence Scheduling and Documenting Meetings Agile Software Development Acceptance Tests Product Owner Meetings User Stories Video- Scrum Methodology Overview ACCEPTANCE TESTS http://agilesoftwaredevelopment.com/blog/vaibhav/acceptance-testing-what-why-how
An acceptance test case has the following primary objectives: * The Product Owner should be able to verify and validate that the user story has been implemented as it was supposed to. * The developers should be able to check if what they have developed is in accordance with the requirements. * We do no development that cannot be verified. An acceptance test case is a human level test which determines whether the product meets the expectations of the end user. http://xprogramming.com/xpmag/expCardConversationConfirmation
At the end of the iteration, when the story is done, the programmers show the customer that the story is done, confirming success by showing that the acceptance tests run correctly. http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements
For example, the following might be appropriate acceptance test cases for the story "A Recruiter can pay for a job posting with a credit card:" * Test with Visa, MasterCard, and American Express (pass) * Test with Diner's Club (fail) * Test with good, bad, and missing card ID numbers * Test with expired cards * Test with different purchase amounts (including one over the card's limit)
PRODUCT OWNER MEETINGS nice, succint explanation of Product Owner Meetings:
(where they're talking about a once-an-iteration meeting, so not necessarily what all our PO meetings would be)
Key activities:
Discuss stories coming up in the product backlog Prioritize stories Come up with optimal sequence for completing stories Estimate new stories that have been added to the product backlog Re-estimate existing stories if new information Determine relative risk and cost of new or revised stories Add investigative stories (spikes) if needed USER STORIES Epics (large or vague user stories) Non-functional Requirements as User Stories Writing Good User Stories
Epics (large or vague user stories)
Epics and Themes
Non-functional Requirements as User Stories Unknown macro: {bookmark}
Many times, requirements may be strictly about back end systems/infrastructure and never touch the user directly. This article discussed strategies to write user stories for non-functional requirements.
Writing Good User Stories Unknown macro: {bookmark}
Overview of writing a good user story. INVEST is particularly important. VIDEO- SCRUM METHODOLOGY OVERVIEW
Great overview of Scrum. The Matterhorn project tenuously follows scrum practices. Unknown macro: {html}
Licenses 3rd Party Licenses and Software Applying ECL License To Code Managing Third Party Licenses and Software 3RD PARTY LICENSES AND SOFTWARE
The following table indicates 3rd party licenses which have been evaluated and determined to be either compatible with the Matterhorn's licensing practices, or incompatible. Each license is linked to a page that describes the requirements for use.
Key: Code/libraries using this license are approved for use. Follow usage instructions. Code/libraries using this license may not be used. License currently under evaluation. License may be used under some conditions. Check with Licensing WG. License and usage instructions Used License Compatibility Notes
Apache license 1.1
Apache license 2.0
Bedework
Blazonry HTML Lib
Concurrent
CPL 1.0
Creative Commons 2.5 dom4j License
DynamicDrive permission.
ECL htmlArea License hsqldb
IBM developerWorks
JavaSoundApplet license
Jaxen License 1.3
JSR 170/Day Management AG
jdom license jing license jquery.xslt.js
JSTL license jv4linfo
LGPL2.1
MIT
MIT-OKI
Mozilla Public License v1.1 mx4j license odmg 3.0 license sax path license
Sript Asylum permission.
Sun BCL
Sun OS License
Sun-SCSL
Sun-SCSL-jsf-api
Sun-SCSL-jsf-impl
Tigra License
WebSPHINX jquery.xslt.js License jquery.xslt.js Copyright (c) 2005-2008 Johann Burkard (
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. APPLYING ECL LICENSE TO CODE
Applying the Educational Community License, Version 2.0
The following is to provide guidance for software developers, both inside and outside the Opencast, to understand what they need to do to apply the Educational Community License, Version 2.0(ECLv2), to their own or Matterhorns's software, including source code, documentation, and binary distributions. It is not intended to supplant or otherwise modify any of the terms within the license itself.
Understanding the License
The ECLv2 consists of a set of copyright licensing terms that are written in such a way that they can be used by anyone, not just Matterhorn, and can be applied by reference to the versioned license terms.
Applying the license to a Matterhorn software distribution
The Matterhorn software distribution is an aggregation of software developed and copyrighted by multiple parties. The distribution as a whole is licensed under the ECL by the Opencast Community (represented by UC Berkeley). Individual source files, libraries, and other contributions frequently must retain acknowledgements and copyright notices.
The ECL is applied to the Matterhorn software distribution by:
1. Placing the following copyright statement in the footer of front end applications as it is rendered by default:
Copyright 2009-2010 Opencast Community. All rights reserved. Portions of Matterhorn are copyrighted by other parties as described in the Acknowledgments screen.
2. Maintaining an accurate and complete Acknowledgments Screen (example)that includes the following statement followed be a detailed list of acknowledgments:
Copyright 2009-2010 Opencast Community. All rights reserved. Matterhorn is licensed for use pursuant to the Educational Community License, Version 2.0. Portions of Matterhorn are copyrighted by other parties, including the parties listed below, and you should see the licenses directory for complete copyright and licensing information. Acknowledgments
3. Placing the ecl2.txt file in the root of the licenses folder of the source distribution.
Applying the license to individual source files and libraries
The license is applied to each source file's header (code and documentation by including a short copyright notice at the top, as demonstrated below:
(Note: The build (maven) currently requires that all Java source files start with this header. If this header is not present than the build will fail. There is no safety net for non-java files)
/** * Copyright 2009 Opencast Project (http://www.opencastproject.org) * Licensed under the Educational Community License, Version 2.0 * (the "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.osedu.org/licenses/ECL-2.0 * * Unless required by applicable law or agreed to in writing, * software distributed under the License is distributed on an "AS IS" * BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express * or implied. See the License for the specific language governing * permissions and limitations under the License. * */ MANAGING THIRD PARTY LICENSES AND SOFTWARE
1. Check ECL compatability table. (Note: details on compatability link out to the Sakai site. Matterhorn will rely on Sakai for detailed license analysis).https://wiki.opencastproject.org/confluence/display/open/3rd+Party+Licenses+and+Software; 2. If a license does not exist on the table, send out a request to the list to review the license compatibility. Once the new license compatibility has been vetted by the list, add a new row to the table and link to compatibility details. 3. Add your library/software to the acknowledgement's page in svn. An example of the acknowledgements page can be found here. https:// source.sakaiproject.org/svn/reference/trunk/library/src/webapp/content/gateway/acknowledgments.html(Note:maven reports all java libraries, but since it does not cover non-java libraries, the acknowledgements page is necessary) Processes Communication Profile Pages in Confluence Scheduling and Documenting Meetings PROFILE PAGES IN CONFLUENCE
Do your part to add a personal touch to a widely distributed team!
1. Create/Edit Your Account
Your name, email address and login information is not managed in Confluence. Use these links to manage your account, which affects both Confluence and Jira:
Create an account Edit an existing account or retrieve a lost password
2. The "People" page
Visit the People page and make sure of the following:
You are listed You have a photo Your details are correct Your name links to your profile or personal space (see below).
If you need to make any changes to this page, either edit the page yourself, or feel free to send your edits and/or a photo to Michelle .
3. Your Personal Space
Create your "Personal Space" to provide teammates with contact information, and allow others to see pages you've been working on.
After logging in, mouseover your name in the upper right corner of the screen, and click on "Create Personal Space". Follow the template provided - feel free to embellish with additional details that you would like to share. Note that these profile pages are public. Follow the "recently-updated" notes - replacing "USERNAME" with your username - to have your recently created/edited documents displayed on your personal page.
4. Your Photo
Follow these instructions to change the photo that appears next to content you created or edited throughout the site. Note: The photo on the Peo ple pagedoes not use the same photo from your profile, as the profile picture is only 48x48. You'll have to update your photo on the People page separately.
After logging in, mouseover your name in the upper right corner of the screen, and click on"Preferences". Click on "Edit Profile", then "Profile Picture" and upload a new photo. SCHEDULING AND DOCUMENTING MEETINGS
How to add a meeting to the calendar
All Matterhorn meetings should be entered in the Opencast Matterhorn calendar. Contact Michelle Ziegmann with any problems you encounter in using the calendar.
1. If you are scheduling a recurring Matterhorn meeting, be sure your meeting is accurately listed on the Meetings page in the wiki. 2. Go to http://www.opencastproject.org/calendar_matterhorn and login if you are not already logged in. 3. Click the "Add +" link in the upper right area above the calendar 4. Enter the following details:
a. 4.
a. Meeting Title b. Date(s) All times are in Pacific time (sorry!) From date: enter the date and start time of the meeting To date: enter the same date as in the From date field For all day meetings, enter 12:00am in the From and To time fields c. Recurring meetings Enter in the From and To dates only the date/time of the 1st meeting Click the "Repeat" heading, and choose a frequency (e.g. choose "every" and "weeks" for a weekly meeting) d. Vocabularies Event Type: choose "Matterhorn meeting" Matterhorn Team: choose all appropriate teams e. Location/Venue If using the Adobe Connect Room, enter http://ado.uvigo.es/opencast f. Meeting Details Page (link): Enter the url of the meetings detail page for this meeting in the wiki. If there is no page specific to this meeting, enter the main Matterhorn meetings page https://wiki.opencastproject.org/confluence/display/open/Meetings g. Agenda/Description (optional) 5. Click "Save" and check to be sure your meeting is appearing on the calendar as you expected.
How to save meeting notes
A record of all Matterhorn meetings should be kept in this wiki. Follow these steps to ensure meetings are saved in the archives properly.
1. From any page within the Matterhorn wiki, click on the "Add" button and choose "News"
2. In the title, start with the date of the meeting in YYYY-MM-DD format, following by the title of the meeting, such as: "2009-08-17 Services Team Meeting" 3. Enter the notes, including the following items as a guide: a. Recording: Enter url of recording if it exists and if known; if it was recorded but you do not know the url, ask Michelle to look it up for you b. Attendees: List of attendees (first name is sufficient) c. Notes: Notes are generally recorded during the meeting in the Connect room; just copy and paste these notes into the wiki d. Labels: Use the following labels to indicate this is one of a set of regular meetings: scrums = Weekly Matterhorn SoS Meeting product_owners = Weekly Product Owner's Meeting ba-ux-ui = Weekly BA/UX/UI Meeting capture = Capture Team Meeting admin = Admin Team Meeting architecture = Services & Architecture Team Meeting services = Services Team Meeting distribution = Distribution Team Meeting e. Posting Day: Set this to the date of the meeting 4. Click the "Save" button, and be sure it appears on the meeting details page as you expected. 5. Email the notes to the [email protected] mailing list. Frontend best practices
TODO Work in progress
Javascript coding style
Please enter best practices for frontend development in Matterhorn. This includes HTML, JS, Flash, etc.
JAVASCRIPT BEST PRACTICES
HTML BEST PRACTICES
ACCESSIBILITY BEST PRACTICES
1. Use semantic HTML (including ensuring that forms that are similar, like the Ingester & the Scheduler, use the same HTML structure) 2. Follow Fluid's "DHTML Developer's checklist" (http://wiki.fluidproject.org/display/fluid/DHTML+Developer+Checklist) 3. Follow W3C Web Content Accessibility Guidelines (probably version 1, see http://www.w3.org/TR/WCAG10/, http://www.w3.org/TR/WCA G10/full-checklist.html) 4. Check pages using an accessibility evaluation tool such as: http://wave.webaim.org/ 5. Use form labels (see http://www.webaim.org/techniques/forms/controls.php) 6. Make sure all buttons have unique names (e.g. it may just say "Edit" visually, but behind the scenes it should read "Edit 'XYZ Recording'" to the screen reader, I believe via the "alt" attribute but please confirm) 7. Hidden content I believe has to be evaluated on a case-by-case basis (which is why it shows up as an alert instead of an error in the validator). If it should be hidden from everyone, it is fine to hide it using "visibility:hidden" or "display:none" as this also hides it from screen readers. But if it should be shown for screen reader users only, per our UI Developer at Berkeley, Eli Cochran, usually these days 7.
the best practice to hide content from non-screen reader users only is to position it way outside the page boundaries, as there it will be hidden from sighted users but not screen readers. There is a class in the Fluid Skinning System that can be used to do this. Additionally, here's an article on how to do it: http://www.webaim.org/techniques/css/invisiblecontent/. Btw, this WebAIM site has lots of great articles on accessibility techniques. 8. Using Javascript: In general, most modern screen readers can handle javascript, but there are some things you have to be careful of, like updating content with javascript and then not bringing focus back to that content. If you don't bring them back to the updated content, screen reader users can't tell it's been updated. Here's another WebAIM article, on Creating Accessible Javascript: http://www.webaim.or g/techniques/javascript/
GENERAL FRONTEND PRACTICES
Storing static content
Note the location of the static content and rules related to organizing it. Javascript coding style
Tab-Width: 3
Abbreviations
Simply don't do. Since all modern IDEs/code editors are capable of doing autocompletion variables can have talking names and this advantage should be made use of.
( Parentheses )
Space after ( and before ). No space in epmty parenthesis. Parameter parenthesis start right after identifier.
My practice: Outer () with, inner most not
something( param1, anything(interesting), more() );
Blocks
Always newline after Unknown macro: { block begin.Closing } always on a line by it selfe (exception is ELSE, structure of code becomes more obvious, reduces risk of missing/to_much } syntax errors).
if ( true ) { for ( i=0; i < 100; i++ ) { something( i ); } } else { anything(); }
IF Blocks
Always use {} blocks after condition, never single statement. Same goes for loops. if ( number == 123 ) { something(); } else { anything(); }
I know things like that above could look more elegant, butthis avoids errors resulting from adding lines to a block wich actually isn't one because it was not opened with Unknown macro: { after IF or ELSE.*Functions*Always newline after function head. All local variables used in the function should be declared at begining of function. Since var declaration is some kind of a "head-thing" to me, it follows the function declaration immediately without empty line in between. Always one empty line after closing }
.
function something( parameter1, parameter2 ) {
return "foo"; }
function anything() { var i,j; // iterators var firstname, lastname; // name strings
for ( i = 0; 1 < 100; i++ ) { . . . } }
Java best practices
MATTERHORN JAVA DEVELOPMENT BEST PRACTICES
General best practices
Follow the the Java recommended code format conventions and javadocs conventions. We deviate from the conventions by using 2 spaces instead of tabs and all files are expected to be encoded using UTF-8.
Detailed best practices
Logging
Developers should only use DEBUG log levels when working on things. Do not use INFO or WARN level logging for debugging. INFO level logging should be used for changes to data which are likely to need to be tracked by a server admin. WARN level should indicate failures that have been handled but require attention. ERROR level indicates actual failures which could not be handled.
If you need to adjust the log levels in Matterhorn (using Felix):
1. Copy the org.ops4j.pax.logging.properties file from MATTERHORN_SRC/docs/felix/conf to your felix/conf directory
2. 2. Adjust the file and adjust the logging level from INFO to DEBUG You may want to also adjust the logging to only log your own packages Management Processes Conducting "Scrum of Scrums" Conducting "Scrum of Scrums" Unknown macro: {bookmark}
The scrum of scrums meeting is an important technique in scaling Scrum to large project teams. REST practices
TODO This is here to capture the best practices around creation of matterhorn REST endpoints.
Generally all REST urls in Matterhorn should adhere to the microformat: http://microformats.org/wiki/rest/urls
REST ENDPOINT DEVELOPMENT PRACTICES
TODO
REST DOCUMENTATION PRACTICES
TODO Submitting a Patch to Matterhorn
Cookbook
CAPTURE
Get Capture Agent Schedules (OLD Matterhorn Project **DON'T USE**) capture cookbook
Capture Media from the Command-line (OLD Matterhorn Project **DON'T USE**) capture cookbook
Simulate Capture Agent Hardware (OLD Matterhorn Project **DON'T USE**) capture cookbook
PROCESS
Sample Media (Opencast Developer Wiki) cookbook process
Create an Encoding Profile (OLD Matterhorn Project **DON'T USE**) process cookbook
Text Analysis (Opencast Developer Wiki) cookbook process
MEDIAPACKAGE
MediaPackage Cookbook (OLD Matterhorn Project **DON'T USE**) mediapackage cookbook
Customizing Dublin Core Catalogs (Opencast Developer Wiki) cookbook mediapackage
WORKFLOW
Workflow Cookbook (OLD Matterhorn Project **DON'T USE**) workflow cookbook
REST ENDPOINTS Get a Server's Base URL (Opencast Developer Wiki) cookbook rest
Obtaining the server's base URL (OLD Matterhorn Project **DON'T USE**) rest cookbook
AUTOMATED TESTING
Unit Tests XSL (Opencast Developer Wiki) testing cookbook
Unit Tests Java (Opencast Developer Wiki) cookbook testing
Integration Testing (OLD Matterhorn Project **DON'T USE**) cookbook testing
Unit Tests JPA (Opencast Developer Wiki) testing cookbook
JavaScript Unit testing (OLD Matterhorn Project **DON'T USE**) ui javascript cookbook testing
Test Data (Opencast Developer Wiki) cookbook testing
Java Unit testing (OLD Matterhorn Project **DON'T USE**) cookbook testing
Adding Demo Data To Your Instance (OLD Matterhorn Project **DON'T USE**) cookbook testing
Integration Tests (Opencast Developer Wiki) cookbook testing
Unit Tests JavaScript (Opencast Developer Wiki) ui cookbook testing javascript
SERVICE DESIGN
Java Persistence API (Opencast Developer Wiki) service cookbook
Document a Service (OLD Matterhorn Project **DON'T USE**) service cookbook
Create a New Service (OLD Matterhorn Project **DON'T USE**) service cookbook
Anatomy of a Service (Opencast Developer Wiki) cookbook service
Document a Service (Deprecated) (Opencast Developer Wiki) cookbook service
Anatomy of a Service (OLD Matterhorn Project **DON'T USE**) service cookbook
Create a New Service (Opencast Developer Wiki) cookbook service
USER INTERFACES JavaScript Unit testing (OLD Matterhorn Project **DON'T USE**) ui javascript cookbook testing
Including common static resources in your UI (OLD Matterhorn Project **DON'T USE**) ui cookbook
Unit Tests JavaScript (Opencast Developer Wiki) ui cookbook testing javascript
Registering User Interfaces (OLD Matterhorn Project **DON'T USE**) ui cookbook
Register a User Interface (Opencast Developer Wiki) ui cookbook
Matterhorn Static Resources (Opencast Developer Wiki) ui cookbook
DISTRIBUTION SERVICES
Distribution Scheduler (Opencast Developer Wiki) distribution cookbook
iTunes Distribution Service (OLD Matterhorn Project **DON'T USE**) distribution cookbook
Youtube Distribution Service (OLD Matterhorn Project **DON'T USE**) distribution cookbook
Adding Demo Data To Your Instance
usage: demoloader [url] -h,--help display this help screen -n,--number
"number
"random": loads the packages in random order.
Example:
cd opencast-demo/target java -jar opencast-demo-0.1-SNAPSHOT-jar-with-dependencies.jar -n10 http://localhost:8080
This will load 10 random samples into the matterhorn installation running at localhost:8080. Atom and RSS Feeds
Feeds in Matterhorn
Matterhorn comes with framework for delivering many flavors of feeds like RSS and Atom, each of them in multiple versions. Feeds are being served by the feed servlet that will by default be mounted to http://
Matterhorn provides a set of feed implementations that can easily and by means of configuration be customized to suit individual needs:
Latest feed Series feed Aggregation feed Custom feed
Each of these feed implementations are described in more detail below.
The feeds are designed to be configured in the site conductor as OSGi services and support, depending on their implementation, a given set of service properties such as the feed uri, the name, description, copyright etc. Following is a list of common properties that are shared by all implementations:
feed.uri this is the uri that identifies the feed. feed.selector the pattern that is used to determine if the feed implementation wants to handle a feed request, e. g. the selector latest in http://
Latest Episodes
This feed contains the latest episodes that have overall been published by the Matterhorn instance.
Implementation: org.opencastproject.feed.impl.LatestFeedService
Latest episodes of one Series
The series feed displays the most recent episodes from the series defined by the argument that needs to be passed in when asking for the feed, e. g. http://localhost/feeds/atom/0.3/series/13 will display the latest episodes from serie 13.
Implementation: org.opencastproject.feed.impl.SeriesFeedService Parameters: the series identifier
Latest episodes out of multiple Series
This feed aggregates multiple series into one and then returns the latest episodes of that aggregated series.
Implementation: org.opencastproject.feed.impl.AggregationFeedService Additional configuration options:
feed.series, a coma separated string of series identifier
A custom selection of episodes
This implementation allows for the definition of a custom query that is passed to the search service. The resulting episodes will make up the feed entries. Any parameters that are passed in via the url will be matched against the query using Java's MessageFormat, this way a maximum flexibility is guaranteed.
As an example, you could configure the service with a feed.selector property value of alphabetical and a feed.query property value of dc_title:{0}*. Then, the new feed can be called like this: http://
Implementation: org.opencastproject.feed.impl.CustomFeedService Additional configuration options:
feed.query, a solr query, e. g. dc_title:*xml* to obtain all episodes with xml in the title Parameters: depending on the query Capture Media from the Command-line
This document explains how to capture media using the Felix OSGi command-line.
1. Prepare a. Update Matterhorn to rev 1538 or greater. b. Remove
Start capture:start
Status capture:status
Stop capture:stop
Create an Encoding Profile
This document will help you modify and augment Matterhorn's default encoding profiles.
This specification is currently in flux. Please be patient as we nail this down.
encodingprofiles.properties Anatomy of an Encoding Profile encodingengines.properties Create a new encoding engine
Get to Work! If you'd like to learn more about how to use your new encoding profile, please read the Workflow recipe.
ENCODINGPROFILES.PROPERTIES
The available encoding profiles are declared in opencast-composer-service-impl/src/main/resources/encodingprofiles.prope rties.
Please be aware that the Matterhorn default workflow relies on a number of the existing profiles; please edit with care.
ANATOMY OF AN ENCODING PROFILE
Encoding profiles conform to a basic pattern:
profile.
profile.mov-low.http.name = mpeg4/quicktime download profile.mov-low.http.input = visual profile.mov-low.http.output = visual profile.mov-low.http.suffix = -low-dl.mov profile.mov-low.http.mimetype = video/quicktime profile.mov-low.http.ffmpeg.command.video = -i #{in.video.path} -s 320x240 -vcodec mpeg4 -ar 44100 profile.mov-low.http.ffmpeg.command.audio = -i #{in.audio.path} -ar 44100 -vn profile.mov-low.http.ffmpeg.command = #{video} #{audio} -f mov #{out.dir}/#{out.name}#{out.suffix}
Note the use of
#{
for string replacement.
ENCODINGENGINES.PROPERTIES
The available encoding engines are declared in opencast-composer-service-impl/src/main/resources/encodingengines.proper ties.
Please be aware that the Matterhorn default workflow relies on a number of the existing profiles; please edit with care.
CREATE A NEW ENCODING ENGINE
Encoding engine profiles conform to a basic pattern:
encoder.
As an example, ffmpeg is declared as:
encoder.ffmpeg.class = org.opencastproject.composer.impl.ffmpeg.FFmpegEncoderEngine encoder.ffmpeg.profiles = engage-image.http, feed-image.http, mov-low.http, avi-low.http, flash.http, m4a.http Please refer to org.opencastproject.composer.impl.ffmpeg.FFmpegEncoderEngine for further implementation details. Get Capture Agent Schedules
This document will help you retrieve the schedules for active Matterhorn capture agents.
GET SCHEDULE FOR ALL AGENTS IN XML FORMAT
1. Send an HTTP GET
curl http://
2. Check the response
GET SCHEDULE FOR A GIVEN AGENT IN XML FORMAT
1. Send an HTTP GET
curl http://
2. Check the response
GET SCHEDULE FOR A GIVEN AGENT IN ICALENDAR FORMAT
1. Send an HTTP GET
curl http://
2. 2. Check the response
BEGIN:VCALENDAR PRODID:Opencast Matterhorn Calendar File 0.5 VERSION:2.0 CALSCALE:GREGORIAN END:VCALENDAR
Including common static resources in your UI
If you are building a user-facing tool, you should bundle the project-wide shared css, javascript libraries, and image files into your project at build time rather than copying them into your project in svn. To automate this process, you can use the maven resources plugin, like this:
This copies all of the files in the /static-resources directory to /your_project/target/classes/ui. This assumes that the /ui classpath is registered with the http service, as described in Registering User Interfaces.
You must also ensure that the maven-bundle-plugin is aware of these static resources, or they will be excluded from your osgi bundle.
Integration Testing
Introduction
The opencast-test-harness module provides a mechanism to test Matterhorn REST and SOAP service endpoints. The test harness should be used to verify:
that the endpoint exists at the correct URL(s) that the endpoint accepts new / updated content via POST and/or PUT that the endpoint returns expected data sets via GET that the endpoint is documented (/docs, /?wsdl, and/or ?_wadl returns something useful)
The test harness should not be used to test implementation logic. For that, you should use unit tests, relying on mock objects to simulate collaborating services.
Writing integration tests
This section still needs improvement... both the documentation and the implementation. If you are interested in getting involved in the project, this is a great place to help out!
1. Add a test class to opencast-test-harness/src/main/java. Use Junit's annotations to specify test methods and, if necessary, setup, teardown for your test fixture. 2. Use apache httpclient to connect to the endpoint and verify that it works as expected. We are currently writing to System.out to indicate success / failure. To post to an endpoint and inspect the returned body: 2.
HttpClient client = new DefaultHttpClient(); HttpPost post = new HttpPost(baseUrl + "/my/rest/endpoint"); List
formParams.add(new BasicNameValuePair("param1", "value1")); formParams.add(new BasicNameValuePair("param2", "value2")); post.setEntity(new UrlEncodedFormEntity(formParams, "UTF-8"));
String postResponse = client.execute(post, new ResponseHandler
Specifying a ResponseHandler gives you more flexibility, but for simple use cases you can avoid this complexity:
String postResponse = EntityUtils.toString(client.execute(post).getEntity());
To issue an http GET:
HttpClient client = new DefaultHttpClient(); HttpGet get = new HttpGet(baseUrl + "/my/rest/endpoint.xml"); String getResponse = client.execute(get, new ResponseHandler
Or using the simpler form:
String getResponse = EntityUtils.toString(client.execute(get).getEntity());
3. Verify that the responses you receive are what you expect. Java's built in xpath capabilities should be used to verify xml responses. 3.
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setNamespaceAware(true); // don't forget this! DocumentBuilder builder = factory.newDocumentBuilder(); Document doc = builder.parse(IOUtils.toInputStream(xmlResponse)); return ((Element)XPathFactory.newInstance().newXPath().compile("/*").evalu ate(doc, XPathConstants.NODE)).getAttribute("id");
The json-simple library is embedded in the test harness, and should be used to verify JSON responses.
JSONObject json = (JSONObject) JSONValue.parse(jsonResponse); System.out.println("Retrieved json response for my object with id=" + json.get("id"));
4. Add your class to the @SuiteClasses annotation in the AllRemoteTests.java test suite. You may also build your own test suite here, if appropriate, and reference your suite from AllRemoteTests.java.
Running integration tests
There are a few ways to run the integration tests:
1. In eclipse or your favorite IDE. This is useful when you want to run just your own integration test 2. Run the opencast-test-harness jar from the command line. If you want to test a server other than localhost:8080, specify the server's URL as an argument (make sure to prepend "http://"). Further enhancements may support multi-threaded operations to test server-side contention and performance.
cd opencast-test-harness java -jar target/matterhorn-test-harness-0.6-SNAPSHOT-jar-with-dependencies.jar
iTunes Distribution Service iTunes distribution service is an OSGi service that is based on the Web service for delivering media files to external systems such as YouTube and iTunes as part of the Media Space Project at the Academic and Research Technology Department, Northwestern University.
This document is currently in flux. Please be patient as we nail this down.
This document will help you configure and test the iTunes distribution service before it can be used to deliver a media package to the iTunes site in the Opencast environment. Java Unit testing
Introduction
See http://pub.admc.com/howtos/junit4x/ for a thorough introduction to the use of Junit 4.x, and http://maven.apache.org/plugins/maven-surefire-p lugin/usage.html for documentation on how unit tests are run as part of the maven build.
Writing a simple unit test
As a general rule, your test should be as simple as possible. Test one thing at a time, and do not store state between test runs. A simple example of two simple tests:
public class MyTest {
protected MyObjectSerializer serializer = null; protected MyObjectImpl myObj = null;
@Before public void init() { serializer = MyObjectSerializer.getInstance(); myObj = new MyObjectImpl("value1", "value2"); }
@After public void destroy() { serializer = null; myObj = null; }
@Test public void testSerialization() throws Exception { String xml = serializer.toXml(myObj); Assert.assertEquals("
@Test public void testBehavior() throws Exception { Assert.assertTrue(myObj.hasFirstValue()); } }
Notice that, even though the two test methods coexist in the same class, they do not share state. Before each test method, both MyObject and MyObjectSerializer are instantiated, and after each test method these objects are defererenced. This ensures that any side-effects produced by one test do not impact the outcome of the others.
Collaborating services
You should try to factor your code so you can test most of it using simple unit tests, as described above. However, at some point the code that you are testing will need to reference other services. These dependencies, often known as collaborators, must be provided in order for your code to function. We have several options for providing your code with its collaborators:
Write stub implementations. This is slow and can become a maintenance nightmare, though it can be appropriate for simple use cases Launch the actual server environment. This is too slow to maintain a rapid development pace. We do this as part of integration testing rat her than unit testing Use mock objects, which can be trained to have any behavior that your test client desires. This is the preferred approach to unit testing with collaborating services, and EasyMock is our preferred mock object library. JavaScript Unit testing Introduction
This wiki page contains a summary of the documentation of QUnit found on:
http://docs.jquery.com/QUnit in the recently released O'Reilly title "jQuery Cookbook": http://oreilly.com/catalog/9780596159788/
Citing the introductory words on its homepage:
QUnit is a powerful, easy-to-use, JavaScript test suite. It's used by the jQuery project to test its code and plugins but is capable of testing any generic JavaScript code (and even capable of testing JavaScript code on the server-side).
There is no easy definition of "unit testing" for JavaScript. Does it include having a DOM library? Does it include a specific browser of some vendor?
Each of these three levels could be tested:
"pure" unit tests using QUnit running in v8 or rhino unit tests involving a DOM library running these in htmlunit (but without ensuring cross browser compatibility) full cross browser compatible unit tests using something like Selenium Grid (http://selenium-grid.seleniumhq.org/), parallel *-Watirs (http:// watir.com/platforms/) or something like John Resig's Test Swarm (http://testswarm.com/)
We wanted to have midscale and full tests and thus decided to define JavaScript unit tests as "unit tests involving the DOM library in htmlunit". M H-1769 integrates a fully automated setting into Matterhorn.
How to write a simple JavaScript unit test
The essential structure of a unit test is:
arrange / given action / when assert / then
Assertions
There are three assertions provided by QUnit: ok(state, [message])
test("a test", function() { ok(true, "always fine"); ok(false, "this assertion fails"); });
This is the most basic assertion function provided by QUnit. It requires a single boolean argument. If this argument resolves to true, this assertion passes. If it resolves to false, this assertion fails. You can give an additional string to show a meaningful explanation, if this assertion fails. equals(actual, expected, [message])
test("a test", function() { var actual = 1; equals(actual, 1); equals(actual - 1, 0, "this message is added to the assertion result, useful for debugging"); });
equals is equivalent to JUnit's assertEqual (but the order is different). Use this for comparing non-boolean values, as it outputs both values on fail. same(actual, expected, [message])
test("same test", function() { same(undefined, undefined, "same succeeds"); same("", 0, "same fails"); });
same is stricter than equals as comparison is done with ===}. So null, 0, the empty string "" and undefined are not the same. Moreover it does a deep, recursive comparison instead. This assertion should be used in most cases.
Writing test cases
Assertions are contained in Test cases. Try to keep tests atomic using at most a single assertion per case. This way you will know exactly why a test case fails and you will prevent invalid results from side effects.
Test cases are written by calling the test method:
test("a test", function() { ok(true, "always fine"); });
The signature of this method is: test(name, [expected], test)
name is obviously the name of the test. expected is an optional parameter containing the number of assertions expected to run. This is important for asynchronous tests. test is a function literal containing the actual testing code.
Grouping Tests
If you split your test cases keeping them atomic and free of side effects, you will end up with a lot of these. To organize them logically and to be able to run only certain groups of tests, you can employ the module method to group the test cases. module("group a"); test("a basic test example", function() { ok( true, "this test is fine" ); }); test("a basic test example 2", function() { ok( true, "this test is fine" ); }); module("group b"); test("a basic test example 3", function() { ok( true, "this test is fine" ); }); test("a basic test example 4", function() { ok( true, "this test is fine" ); });
After calling module every test case will end up in that group. If you call module again, all following test cases are grouped in that module. Additionally module can be used for setting up fixtures and tearing them down:
module("lifecyle example", { setup: function() { this.testData = "foobar"; }, teardown: function() { delete this.testData; } }); test("test with setup and teardown", function() { same(this.testData, "foobar"); });
So the signature of this method is: module(name, [lifecycle])
name is the name of this module. lifecycle is optional and contains setup and teardown callbacks which are run before and after every test in this module.
Testing synchronous callbacks
Whenever you have to tests code with synchronous callbacks, there will be passing tests that should actually fail as the assertion is never evaluated. test("a test", function() { expect(1); $("input").myPlugin({ initialized: function() { ok(true, "plugin initialized"); } }); });
For these circumstances you may use the method expect(amount) to assert the number of assertions to get evaluated. expect does nothing for you if you do not test code using callbacks. Note that the second, optional parameter to test does exactly the same thing.
Asynchronous Tests
Unfortunately expect may not help you with asynchronous callbacks which are used by XmlHttpRequests or DOM events. Testing is inherently synchronous and so you have to stop the test runner for a moment until that magic happens and get started afterwards.
test("a test", function() { stop(500); $.getJSON("/someurl", function(result) { equals(result.value, "someExpectedValue"); start(); }); });
As you see there are two additional methods stop([timeout]) and start() which allow you to test asynchronous callbacks. Just call stop b efore asynchronous operations and start after all assertions in order to ask the test runner to move onward. Obviously you risk, that start may get never be called. To mitigate that fact you may provide a number of milliseconds as an timeout to stop to make sure that the test runner continues after at most this given amount of time.
test("a test", function() { stop(500); $.getJSON("/someurl", function(result) { equals(result.value, "someExpectedValue"); start(); }); });
Try to avoid that parameter to prevent hunting for false negatives. MediaPackage Cookbook
WORKING WITH MEDIA PACKAGES
A media package represents the business document for the matterhorn lecture capture system. The following document shows how a media package can be created, modified and also made persistent. Working with media packages Creating a media package Reading a media package from a manifest Adding elements to the media package Managing package persistence
Creating a media package
In order to get hold of a media package, you first obtain a reference to a MediaPackageBuilder, offering you the possibility to either create a new media package or to load an existing one.
MediaPackageBuilderFactory factory = MediaPackageBuilderFactory.newInstance(); MediaPackageBuilder builder = factory.newMediaPackageBuilder(); MediaPackage mediaPackage = builder.createNew();
This code will create an empty media package with an automatically created identifier. Should you want to specify the identifier yourself, use the alternative signature createNew(identifier).
Matterhorn comes with a default implementation of the media package. However, if you would like to replace it with your own code, you may set the java system property org.opencastproject.mediapackage.builder to the classname of your media package builder implementation.
Reading a media package from a manifest
A common usage pattern for the media package is creating an in memory representation from an input stream:
MediaPackageBuilderFactory factory = MediaPackageBuilderFactory.newInstance(); MediaPackageBuilder builder = factory.newMediaPackageBuilder(); InputStream is = getMyMediaPackageStream(); MediaPackage package = builder.fromManifest(is);
Adding elements to the media package
Adding elements to a media package is straightforward. Get hold of the media package and call the add() method with the elements url:
File dcFile = new File("dublincore.xml"); URL mpeg7Url = new URL("http://www.opencastproject.org/mpeg7.xml"); MediaPackageElement dc = mediaPackage.add(dcFile.toURI().toURL()); MediaPackageElement mpeg7 = mediaPackage.add(mpeg7Url);
Should you happen to know more about your media package elements than just the url, you may specify them right away. Media package elements support the following attributes: File file = new File("mpeg7.xml"); MediaPackageElement e = mediaPackage.add(file.toURI().toURL()); e.setChecksum(Checksum.create(ChecksumType.DEFAULT_TYPE, file)); e.setSize(file.length()); e.setMimeType(MimeTypes.XML);
You can even make your own element types first class citizens inside the media package. All you need to do is add an element builder plugin to the classpath. Read "Extending the media package" for further details.
TODO: Add that section
Managing package persistence
The elements of a media package can be located at any location that can be referenced by a url. This adds a lot of benefits to the handling of media packages. However, there are also a few drawbacks to consider.
This is why you may add a MediaPackageSerializer to the MediaPackageBuilder. The serializer will be used to create and to resolve urls in a media package.
This technique could be used to implement a proxy for element storage or to add a shared workspace preventing clients to repeatedly download the same large track from an external webserver.
The default serializer comes with support to resolve relative paths in the media package. Therefore, it needs the common root url:
// Get hold of a media package builder MediaPackageBuilderFactory factory = MediaPackageBuilderFactory.newInstance(); MediaPackageBuilder builder = factory.newMediaPackageBuilder();
// Create a default serializer with a root url URL rootUrl = new URL("http://www.opencastproject.org/package"); MediaPackageSerializer s = new DefaultMediaPackageSerializer(rootUrl);
// Set the serializer and read the package InputStream is = getMyMediaPackageStream(); builder.setMediaPackageSerializer(s); MediaPackage package = builder.fromManifest(is);
Once you would like to serialize your media package, you can pass it the same serializer to make sure relative paths are used instead of absolute urls. Of course, you could use another implementation if you would like the media package to contain a modified set of urls.
MediaPackageSerializer serializer = new DefaultMediaPackageSerializer(rootUrl); Document xml = mediaPackage.toXml(serializer);
Obtaining the server's base URL When generating URLs, you can obtain the base portion of the URL via the OSGi BundleContext.
Matterhorn's use of delcarative services hides most, if not all, of the OSGi framework from your service implementation, so you may not have a reference to the current bundle context. In this case, you can obtain a bundle context reference by using an "activate" method on your service implementation. Here's how this works:
1) In your component configuration, specify the name of your activation method. In this case, it's called "myActivateMethod":
2) Implement your activation method
public class MyServiceRestEndpoint { protected String serverUrl = null; public void myActivateMethod(ComponentContext cc) { if(cc == null) serverUrl = UrlSupport.DEFAULT_BASE_URL; String ccServerUrl = cc.getBundleContext().getProperty("serverUrl"); serverUrl = ccServerUrl == null ? UrlSupport.DEFAULT_BASE_URL : ccServerUrl; } ... }
Notice that the myActivateMethod method takes a ComponentContext parameter. This unfortunately ties your class to OSGi packages. The OSGi 4.2 specification allows for a Map of properties to be substituted for the component context, but this is only available in snapshot versions of the felix scr. Once this feature makes it into a stable release, we will factor out all unnecessary binding to ComponentContext. Registering User Interfaces
To register a user interface with Matterhorn, use OSGi Declarative Services.
1. Add your project-specific static resources (html, js, images) to a package under src/main/resources. (Shared static resources should be added to the /static-resources module. See Including common static resources in your UI) 2. In your project's pom.xml, include a dependency for opencast-http
3. In your project's pom.xml, add a configuration for your service component 3.
4. Your service component should register a org.opencastproject.http.StaticResource
Set the component name, "service.description", "alias" (e.g. base path for URLs), "classpath" (the package under src/main/resources), and optionally the "welcome.file" (if this is different from the default index.html).
If you have included Selenium tests for your UI, set the "test.classpath" value to the package containing your tests, and set the "test.suite" property to the HTML file within "test.classpath" that defines your test suite. Service Design Create a New Service Anatomy of a Service Document a Service Create a New Service
This document will walk you through the steps necessary to generate a new OSGi service, using the oc:generate Maven plugin.
This document assumes that you are able to commit code to the Matterhorn Subversion repository.
Jira Maven oc:generate Subversion Repository Import the New Service Delete the New Service Locally Add the New Service to the Subversion .externals File Maven Installation and Deployment Update the top-level pom.xml File Install and Deploy the Matterhorn Project Test Your New Service Document Your New Service
Jira
The first step when preparing a service is to create Jira issues for the task.
1. Add a Story Card for your new service; note the issue number (e.g. MH-582).
2. Add Tasks under your Story Card for your service API and Implementation; note the issue numbers (MH-583 and MH-584).
Maven oc:generate
The Matterhorn oc:generate plugin goal will quickly and easily produce the standard directory structure and essential classes of your new service. The service will include API and Implementation files, as well as several Web Service Endpoints (SOAP, REST, etc.) and JAX-B Entity D efinitions. It will also include the necessary pom.xml and OSGI-INF files for integration with Maven and OSGi.
1. Generate the new service
cd
Subversion Repository
The new service should be imported into the Matterhorn Subversion repository, removed locally and finally checked out from the repository. This will require updating your svn:externals properties.
Import the New Service
1. Import the service API. cd
1. Import the service Implementation.
cd
If the service was, for example, imported to the /contrib directory, the online repository would resemble the following:
Delete the New Service Locally
cd
Add the New Service to the Subversion .externals File
1. Open
../../../modules/opencast-
3. Update the svn:externals properties. 3.
cd
4. Update the repository.
svn commit
5. Confirm that the new services have been added.
You should once again see the opencast-
Maven Installation and Deployment
Apache Maven's declarative model makes it easy to add a new service to the Matterhorn project's build goals.
Update the top-level pom.xml File
1. Open
...
Install and Deploy the Matterhorn Project
cd
Remember to specify the absolute path to the Felix load directory.
Assuming all goes well, you should see API and Implementation directories for your new service in
Test Your New Service
1. Start Felix.
cd
Remember to specify the absolute path to the Maven repository directory.
2. 2. Check status of service modules within Felix.
-> ps
The output should include the following:
[
3. Browse the service: http://localhost:8080
The page should include the following:
Base URL Description WSDL
/
...
Base URL Description Documentation WADL
/
The links should display the following:
Document Your New Service
The last step in defining a new service, short of actually coding, is documenting it.
For the time being, in lieu of a stable template, please copy the markup of the DEPRECATED Service Contract Description Template a nd paste it into your new page.
1. Create a new wiki page for your service, using the Service Contract Description template.
See Document a Service for more information. 2. Post to the Matterhorn email list, announcing your wonderful addition to the project. Anatomy of a Service
This document outlines the service template created by oc:generate. Although the details are specific to the example service, it should help you get started with your own service.
All package and filenames assume an "example" service. Please substitute your service name where appropriate.
Architecture
The service template package is articulated into two parts: Service and Entity org.opencastproject.example.api and impl
Endpoints org.opencastproject.example.endpoint
The template exposes two types of endpoints:
SOAP org.opencastproject.example.endpoint.WebService.api and impl
REST org.opencastproject.example.endpoint.RestService
The models and endpoints communicate to and from XML via Java Architecture for XML Binding (JAXB) bindings, defined in org.opencastpro ject.example.endpoint.ExampleEntityJaxbImpl.
Logging
The service template leverages The Simple Logging Facade for Java (SLF4J) to document state.
import org.slf4j.Logger; import org.slf4j.LoggerFactory; ... private static final Logger logger = LoggerFactory.getLogger(
Web Service
ExampleService.java declares methods to get and set fields of the entity described in ExampleEntity.java.
ExampleEntity getExampleEntity(String id); void saveExampleEntity(ExampleEntity entity);
ExampleServiceImpl.java implements ExampleService using a HashMap.
map = new HashMap
Configuration Admin Service
ExampleServiceImpl.java also implements org.osgi.service.cm.ManagedService's single method, update, allowing it to receive configuration data from an OSGi Configuration Admin Service. import org.osgi.service.cm.ConfigurationException; import org.osgi.service.cm.ManagedService; ... public class
Entity
ExampleEntity.java declares getters for a model with three fields.
getId() getTitle() getDescription()
ExampleEntityImpl.java implements those getters, along with corresponding setters meant for internal use.
setId(String id) setTitle(String title) setDescription(String description)
Java Architecture for XML Binding (JAXB)
ExampleEntityJaxbImpl.java uses JAXB annotations to marshal an XML representation of the above mentioned entity. import javax.xml.bind.annotation.XmlAccessType; import javax.xml.bind.annotation.XmlAccessorType; import javax.xml.bind.annotation.XmlAttribute; import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlID; import javax.xml.bind.annotation.XmlRootElement; import javax.xml.bind.annotation.XmlTransient; import javax.xml.bind.annotation.XmlType; ... @XmlType(name="example-entity", namespace="http://example.opencastproject.org/") @XmlRootElement(name="example-entity, namespace="http://example.opencastproject.org/") @XmlAccessorType(XmlAccessType.FIELD) ... @XmlID @XmlAttribute() private String id;
@XmlElement(name="title") private String title;
@XmlElement(name="description") private String description;
The constructor ExampleEntityJaxbImpl uses getters and setters to convert the in-memory representation to XML; getEntity does the opposite.
public ExampleEntityJaxbImpl() {} public ExampleEntityJaxbImpl(ExampleEntity entity) { ... this.id = entity.getId(); this.title = entity.getTitle(); this.description = entity.getDescription(); } ... public ExampleEntity getEntity() { ExampleEntityImpl entity = new ExampleEntityImpl(); entity.setId(id); entity.setTitle(title); entity.setDescription(description); return entity; } In order to be a valid Java Bean, the ExampleEntityJaxbImpl must include a second, zero argument constructor. getEntity is annotated as transient, meaning that it will not be represented as XML.
@XmlTransient public ExampleEntity getEntity() { ...
SOAP Endpoint
ExampleWebService.java declares its own version of the get and set entity methods we saw in ExampleService.java. The service and methods are indicated using Java API for XML Web Services (JAX-WS) annotations.
import javax.jws.WebMethod; import javax.jws.WebParam; import javax.jws.WebResult; import javax.jws.WebService; ... @WebService() public interface ExampleWebService{ @WebMethod() @WebResult(name="example-entity") public ExampleEntityJaxbImpl getExampleEntity(@WebParam(name="id") String id);
@WebMethod() public void storeExampleEntity(@WebParam(name="example-entity") ExampleEntityJaxbImpl jaxbEntity);
ExampleWebServiceImpl.java implements ExampleWebService, along with a setter to bind the endpoint to ExampleService.
import org.opencastproject.example.api.ExampleEntity; import org.opencastproject.example.api.ExampleService; ... private ExampleService service; public void setService(ExampleService service) { this.service = service; }
Note the use of ExampleEntityJaxbImpl.java. return new ExampleEntityJaxbImpl(entity); ... service.saveExampleEntity(jaxbEntity.getEntity());
REST Endpoint
ExampleRestService.java declares yet another version of the get and set entity methods we saw in ExampleService.java. The service and methods are indicated using Java API for RESTful Web Services (JAX-RS) annotations.
import javax.ws.rs.Consumes; import javax.ws.rs.FormParam; import javax.ws.rs.GET; import javax.ws.rs.POST; import javax.ws.rs.Path; import javax.ws.rs.Produces; import javax.ws.rs.QueryParam; import javax.ws.rs.core.MediaType; import javax.ws.rs.core.Response; ... @Path("/") public class ExampleRestService ... @GET @Produces(MediaType.TEXT_XML) public ExampleEntityJaxbImpl getAnEntity(@QueryParam("id") String id) { ExampleEntity entity = service.getExampleEntity(id); return new ExampleEntityJaxbImpl(entity); }
The ExampleRestService constructor retrieves service documentation from resources/html/index.html, which is returned by the getDo cumentation method. @GET @Produces(MediaType.TEXT_HTML) @Path("docs") public String getDocumentation() { return docs; }
protected final String docs;
public ExampleRestService() { String docsFromClassloader = null; InputStream in = null; try { in = getClass().getResourceAsStream("/html/index.html"); docsFromClassloader = IOUtils.toString(in); ... docs = docsFromClassLoader; }
Dependency Management Document a Service
Service contract descriptions are essential to the success of the Matterhorn project. They help us all keep track of project development. We strong ly encourage you to take the time to thoroughly document your work using the template provided.
Where to Put a Service Contract Description
Each team has been allocated a folder in which to document their work:
Documentation > Reference > Componenents > Components
These folders are further articulated into:
Services UIs Other Drafts
Please use the Drafts folder to collaborate on your initial ideas and share related documents. The description can then be moved to an appropriate folder when it is ready for public scrutiny, as well as reference.
Write a Service Contract Description
For the time being, in lieu of a stable template, please copy the markup of the DEPRECATED Service Contract Description Template a nd paste it into your new page.
1. Create a new wiki page for your service in the appropriate folder, using the Service Contract Description template. The title of the page should be the name of the service in CamelCase.
Complete the Template
The Service Contract Description Template helps you describe a service clearly and concisely. Please take the time to hone your language, so that it is to the point and free of unnecessary jargon.
Be careful using the Firefox Rich Text editor. It is easier and safer to edit the template as Wiki Markup.
1. Write a header
Version This field will likely remain "Snapshot" prior to Matterhorn's first release. The Release Notes link that follows will be populated with legacy Bindings documents (see #Link to relevant bindings) as the project matures. The Release Notes page should reside under the Service Contract Description in the wiki page hierarchy. Revise the link the reflect the service name in CamelCase.
Classification A colon-separated, three-part list of context information: Service Type:Team Name:Topic. An example would be "Business:Common:File System," indicating that the service is of type Business, it is authored by the Common services team and that it pertains to the File System. A list of service types can be found here and below.
Description One or two sentences that distill the service's usage and functionality.
Service Types
Business Execute or enforce business rules.
Process Chain together other services to accomplish a business process.
Information Retrieve, persist and normalize data.
Integration Enable legacy systems.
Partner Communicate with external partners.
Collaboration Public interfaces for collaboration.
2. Detail the service context
Assumptions A comma-separated list of conditions, excluding other services, that the service requires. Examples include installed libraries, tools, database connections or mounted fileshares.
Service A comma-separated list of other services that the service requires. Dependencies
Known Clients A comma-separated list of tools and services that require this service.
Security A comma-separated list of specific security dependencies or requirements.
3. Enumerate the service operations
Name An abstract signature of the operation, excluding return type and other binding-specific details. Surround the name in double curly brackets to render it in a monospace font.
{{ operationName() }}
Description One or two sentences that distill the operation's usage and functionality. 3.
Notes A catch-all for more discursive notes. These notes may include constraints, transactional properties of an operation, questions, comments, artifacts used to define the operation (e.g. workflow, swimlane, or entity diagrams, user stories or use cases) or other notes. Please refer actual discussion to the Matterhorn Project mailing list.
4. Link to relevant bindings
Type The name of the type of binding (e.g. Java, REST, SOAP, etc.)
Each type of binding includes specific fields with links to the relevant documentation or API. Please refer to the template for examples. In most cases, you will simply revise the existing links to reflect the service name in lowercase.
Some services are primarily intended for internal use. These services use the /private path prefix seen in the template. Please remove the prefix if your service is for public consumption.
Rather Sketch? If you are not ready to write a formal Service Contract Description, you can use the Drafts folder mentioned above. But don't let it be a crutch! The sooner you migrate to the template, the better.
Need a Role Model? We are busy transcribing the existing descriptions to the new template. Take a look at the (still incomplete) WorkflowService if you need something to work against.
To Do
Link to how these services work together. Simulate Capture Agent Hardware
This document will help you simulate the capture process in lieu of capture hardware. Please refer to Capture Media from the Command-line to learn how to start, stop and submit media captures from the OSGi command-line.
What about the real thing? Matterhorn 0.5 supports media capture on a specialized Linux-based hardware solution. We appreciate your patience while we work towards a more generalized solution.
The capture agent properties files, located at
capture.device.names=SCREEN,PRESENTER,MICROPHONE
capture.device.SCREEN.src=screen.mpg capture.device.SCREEN.outputfile=screen_out.mpg capture.device.PRESENTER.src=camera.mpg capture.device.PRESENTER.outputfile=camera_out.mpg capture.device.MICROPHONE.src=audio.mp3 capture.device.MICROPHONE.outputfile=audio_out.mp3
The preset media files are located in
REPLACE THE PRESET MEDIA FILES
1. Edit the capture agent properties file 1.
capture.device.SCREEN.src=
All paths are currently relative to the preset media folder (see above).
Workflow Cookbook
WORKING WITH WORKFLOWS AND THE CONDUCTOR
Matterhorn is more than the sum of services that it offers. Being a lecture capture system, it is also about routing lecture recordings through the system from ingest to engage ui. This is where workflows get into the game.
Basically, a workflow definition consists of an ordered list of workflow operations. Each operation defines a single step within a workflow and can be either very simple or highly complex, depending on its implementation (see providing custom workflow operations). Working with Workflows and the Conductor Defining workflows Making workflow definitions available Providing custom workflow operations Creating and starting workflow instances Workflow configuration properties Modifying / extending workflows at runtime Specifying behaviour in case of failure Quick start
Most of the things described on this page can be tested on nightly.
Defining workflows
XML definition
Let's start with an example:
What we see here is a definition for the soup-to-nuts workflow with a meaningful title and description as well as two operations, compose and distribute. The whole workflow will fail if the compose operation fails. However, we don't care wether distribute turns out well, too.
Workflow definitions can have as many operations as needed, operations can also be used multiple times.
On the fly definition
For most of the time you will define your workflows in xml files. However, it is possible to define and execute workflow definitions on the fly in your code. Let's look at the example:
String name = "compose"; String description = "Compose operation"; String exceptionHandler = "Default Error Handler"; WorkflowOperationDefinition operation = new WorkflowOperationDefinitionImpl(name, description, exceptionHandler, false);
WorkflowOperationDefinitionList operationList = new WorkflowOperationDefinitionListImpl(); operationList.add(operation);
String title = "Compose only"; String workflowDescription = "Workflow that executes encode"; WorkflowDefinitionImpl definition = new WorkflowDefinitionImpl(); definition.setTitle(title); definition.setDescription(workflowDescription); definition.setOperations(operationList);
For on the fly workflow definitions to work, you must first create all the operation definitions, then you put operations to the operation list in the right order and finally you create workflow definition and set all the parameters. After that you are ready to deploy this workflow definition.
NOTE: Operation name must correspond the name under which operation handler was registered (see Providing custom workflow operations).
Making workflow definitions available
There are two ways of making workflow definitions available in the system.
Definitions from the workflow service
The first and probably easiest way is putting your workflow definition xml files one of the watcher directories (default one is ./load) and the Conduc tor service will load them and register them with WorkflowService. Then you can access them via the WorkflowService api method listA vailableWorkflowDefinitions() or getWorkflowDefinitionByName(String name).
WorkflowService workflowService = getWorkflowService(); WorkflowDefinitionList definitions = workflowService.listAvaliableWorkflowDefinitions();
NOTE: For definitions to get registered, filename must end with workflow.xml.
Ad-hoc definition
The second way is to do an ad-hoc definition. All you need to do is create the corresponding xml fragment in memory (or read it from disk/url/etc.) and then us the WorkflowBuilder as exported by the WorkflowService api to get an object representation:
InputStream is = new FileInputStream("soup-to-nuts.xml"); WorkflowDefinition soupToNutsWorkflow = WorkflowBuilder.getInstance().parseWorkflowDefinition(is); From there, all you need to do is pass the workflow definition to the WorkflowService in order to have it executed (see creating and starting wokflow instances).
Providing custom workflow operations
If you want do define custom operations all you have to do is write a handler that implements WorkflowOperationHandler. It will contain method r un which will return WorkflowOperationResult (example below). Your new handler is then registered using declarative services and is started as part of your bundle (usually part of Conductor bundle).
public class GreeterWorkflowOperationHandler implements WorkflowOperationHandler {
public WorkflowOperationResult run(final WorkflowInstance workflowInstance) throws WorkflowOperationException {
System.out.println("Hello " + workflowInstance.getConfiguration("name"));
return WorkflowBuilder.getInstance().buildWorkflowOperationResult(workflowInsta nce.getCurrentMediaPackage(), null, false); } }
A GOOD PRACTICE: It is considered a good practice that any exception that might be thrown inside run method should be caught and Workflo wOperationException should be thrown. That way workflow can exit gracefully and special behaviour can be specified (see Specifying behaviour in case of failure).
This handler now needs registration with OSGi. This is done by simply putting the following code into a file in main/resources/OSGI-INF:
The operation will be announced as soon as your bundle starts and you can execute workflows with your new operation.
Creating and starting workflow instances Starting a workflow involves getting hold (or putting together) a workflow definition with a list of operations, then calling the workflow service to have it executed.
WorkflowService workflowService = getWorkflowService(); WorkflowDefinition workflowDef = workflowService.getWorkflowDefinitionByName("test"); Map configurations = new HashMap
Workflow configuration properties
There are two ways to define workflow configuration properties:
Static configurations through workflow definitions
Each operation in workflow definition can have it's own set of predefined properties:
For the above example we decided that we want this operation to execute encoding with flash profile.
Configuration properties passed to WorkflowService when executing workflow
When you execute workflow you can pass configuration properties. Properties can be defined in one of two ways:
configurations.put("encode", "true");
or
configurations.put("compose/flash.http", "true");
First way is used for global properties. Every operation will see this property. If we want local properties we can specify them using second way. Before property name we put operation name and this property will be seen only in operations with matching name (compose in the example above). At the moment it is not possible to set up properties for individual operations with the same operation name (still todo).
Order of applying configuration properties
Since there are three different level of configuration properties (predefined, global and local) with possibly same names it is good to know the order by which properties are applied: 1. predefined configuration properties from workflow definition are loaded 2. local properties for matching operation are loaded possibly overwriting predefined properties 3. global configuration properties are loaded possibly overwriting local and predefined properties
Modifying / extending workflows at runtime
Once that workflow definitions are registered with WorkflowService you can modify them if they do not suit your needs any more. All you have to do is retrieve the desired workflow definition, get a list of its operations and then you can manipulate order, add or remove operations, etc... (all operations that apply to LinkedList are available) Here is a simple example:
WorkflowDefinition definition = workflowService.getWorkflowDefinitionByName("Transcode, Distribute and Publish"); WorkflowOperationDefinitionList operationList = definition.getOperations(); operationList.remove(1);
In the example above we retrieved workflow definition "Transcode, Distribute and Publish" which contains compose, distribute and publish operations. Then we retrieved operation list and removed the second operation (distribute).
NOTE: Keep in mind that after definition is changed it will stay changed so it may suit your needs better to just create new workflow defintion based on the old one.
Specifying behaviour in case of failure
Each operation have two properties that specify behaviour when exception occurs. Those properties are fail-on-error and exception-han dler-workflow.
Here is the example of operation with those properties defined:
When workflow operation fails we might want to take specific actions for instance cleaning any temporary data that might have been left or writing to the log file that exception has occurred, etc. You can do that with specifying the workflow that will be executed if exception occurs. In our case we specified Default Error Handler which just logs the exception.
When exception occurs we can specify what happens after exception handler workflow is executed. If operation was critical we can specify fail- on-error="true" (as in example above), and workflow will be marked as failed. If we don't really care if operation was successful or not we specify fail-on-error="false" and execution of this workflow will continue. Default value is false.
QUICK START
This section is intended for those of you who would like to quickly start using services that are provided via WorkflowService without digging through more complex aspects and options. For additional information you can always check out the Working with Workflows and the Conductor s ection or WorkflowService documentation.
Our aim is to write a simple operation handler that writes a person's name in console, use this operation handler in our custom workflow definition and then execute this workflow. Since we are working with WorkflowService, your bundle must have access to the WorkflowService API. So let us begin.
Creating custom operation handler First we will create our custom operation handler. This operation handler will display 'Hello
Let's create a new java class and name it GreeterWorkflowOperationHandler which implements WorkflowOperationHandler interface available from WorkflowService API. You will see that you have to implement method WorkflowOperationResult run(WorkflowInstance workflowInstance) throws WorkflowOperationException.
For beginning you will add this line at the end:
return WorkflowBuilder.getInstance().buildWorkflowOperationResult(workflowInsta nce.getCurrentMediaPackage(), null, false);
This line will build WorkflowOperationResult where we pass 3 arguments:
MediaPackage mediaPackage: MediaPackage instance that will be sent to next operation's handler Map
Because we will not work with MediaPackage in this tutorial, we just pass on the current MediaPackage with no additional properties. Also our handler will not require any outside handling so we set wait argument to false.
So now you should have code that looks like this:
public class GreeterWorkflowOperationHandler implements WorkflowOperationHandler {
public WorkflowOperationResult run(WorkflowInstance workflowInstance) throws WorkflowOperationException {
// Put your operation's handler code here
return WorkflowBuilder.getInstance().buildWorkflowOperationResult(workflowInsta nce.getCurrentMediaPackage(), null, false); } }
Our operation handler will display 'Hello
To access operation's properties the getConfiguration(String key) method is used:
String name = workflowInstance.getConfiguration("name")); if(name != null) System.out.println("Hello " + name); else System.out.println("Hello stranger");
We retrieve the configuration with identifier 'name' and 'Hello
There are three things to note:
1.
The last thing to do is to modify project's POM file so that our workflow operation handler will get registered. We add the following line under
OSGI-INF/operations/greeter-operation.xml
Creating custom workflow definition
Now that we have our new operation handler it is time to create workflow definition that will make use of it. We create new directory under src/main/resources called workflows. In this directory we create new xml file called greeter-workflow.xml.
For the beginning we will put the following code inside our new file:
Title of our workflow will be 'Greeter workflow'. Name should be meaningful since this name is used to get a hold on the workflow if you decide to register it with WorkflowService (for more information see Making workflow definitions available). In description section we describe what this workflow will do, so all we have to do now is put some actual operations inside it.
We will define only one operation and this will be our greet operation:
As you noticed operation name is the same as the one used when registering operation handler. Fail-on-error and exception-handler-w orkflow properties are used for error handling for which are not important for this tutorial (those who would like to know more: Specifying behaviour in case of failure).
Load and register your workflow
Now that we have operation and our workflow definition in place it is time to register it with the WorkflowService. The following code will be put to the bundle Activator class or activate method inside your service if you are using declerative services.
To parse and register our workflow definition we will use those two methods:
1. parseWorkflowDefinition(InputStream stream) from WorkflowBuilder 2. registerWorkflowDefinition(WorkflowDefinition definition) from WorkflowService
First we have to create new WorkflowDefinition from file. This is done like this:
InputStream greeterWorkflow = WorkflowtestServiceImpl.class.getClassLoader().getResourceAsStream("/wor kflows/greeter-workflow.xml"); WorkflowDefinition newDefinition = WorkflowBuilder.getInstance().parseWorkflowDefinition(greeterWorkflow);
We first obtain the stream and then parse our workflow definition with a WorkflowBuilder. Now that we have our workflow definition we will register it with WorkflowService so it can be retrieved by it's name any time we need it. workflowService.registerWorkflowDefinition(newDefinition);
Now that our greeter workflow is registered you can start using it. Here is the whole code of what we did in this section:
public void activate(ComponentContext componentContext){ // load your workflow try{ InputStream greeterWorkflow = WorkflowtestServiceImpl.class.getClassLoader().getResourceAsStream("/wor kflows/greeter-workflow.xml");
workflowService.registerWorkflowDefinition(WorkflowBuilder.getInstance() .parseWorkflowDefinition(greeterWorkflow)); } catch (Exception e){ throw new RuntimeException(e); } }
Retrieving workflow definitions and deploying them
At last we are ready to deploy our new workflow definition. We will create a method deployGreeterWorkflow where the code for executing greeter workflow will be.
First step is to retrieve workflow definition. This is done by calling a WorkflowService method getWorkflowDefinitionByName(String name). Since our workflow name is 'Greeter workflow' our call will look like this:
WorkflowDefinition greeterWorkflow = workflowService.getWorkflowDefinitionByName("Greeter workflow");
Next step is to get a MediaPackage. If you don't have one you can create an empty one like this:
MediaPackage mp; try { mp = MediaPackageBuilderFactory.newInstance().newMediaPackageBuilder().create New(); } catch (org.opencastproject.util.ConfigurationException e) { throw new RuntimeException(e); } catch (MediaPackageException e) { throw new RuntimeException(e); }
Last step is creating HashMap with properties. This is optional step but if you remember from beginning when we were creating greeter operation handler, we checked for property named 'name': HashMap
Now that we have all the parts in place we are ready to actually start the workflow. To start it you just execute the following code:
workflowService.start(definition, mp, configurations);
The whole method looks like this:
public void deployGreeterWorkflow(){
WorkflowDefinition greeterWorkflow = workflowService.getWorkflowDefinitionByName("Greeter workflow");
MediaPackage mp; try { mp = MediaPackageBuilderFactory.newInstance().newMediaPackageBuilder().create New(); } catch (org.opencastproject.util.ConfigurationException e) { throw new RuntimeException(e); } catch (MediaPackageException e) { throw new RuntimeException(e); }
workflowService.start(definition, mp, configurations); }
You can call your method for executing greeter workflow for example through your REST endpoint and you should see 'Hello John Smith' in the command line.
For the end
I hope that this tutorial gave you a decent knowledge how execution of workflow definitions work and the basic use of WorkflowService. For more information about specific topic you can check out Working with Workflows and the Conductor or WorkflowService documentation.
There are couple of things left to mention: although we registered your operation handler and workflow definition through your own bundle this is primarily Conductor's job and new operation handlers should be added through Conductor. For registering workflow definitions it is enough to put them in the one of the watcher's directories (see Making workflow definitions available). Youtube Distribution Service
Youtube distribution service is an OSGi service that is based on the Web service for delivering media files to external systems such as YouTube and iTunes as part of the Media Space Project at the Academic and Research Technology Department, Northwestern University.
This document is currently in flux. Please be patient as we nail this down.
This document will help you configure and test the Youtube distribution service before it can be used to deliver a media package to the Youtube site in the Opencast environment.
REGISTER A YOUTUBE ACCOUNT If you have not already registered a Youtube account, please do so at http://www.youtube.com/create_account or use the default utubedelivery/utubedelivery account.
OBTAIN A YOUTUBE DEVELOPER KEY AND CLIENT ID
A developer key identifies the YouTube developer that is submitting an API request. A client ID identifies your application for logging and debugging purposes. Please visit http://code.google.com/apis/youtube/dashboard/ to obtain a developer key and client ID.
You may also use the default
AI39si7bx2AbnOM6RM8J7mdrljfZCzisYzDkqvIqEjV3zjbqQIr6-u_bg3R0MLAVVXLqKjSs xu4ReytWFn7ylIlDk6OC7pdXpQ/abcde
pair for the purpose of testing and debugging.
The Youtube account and the developer key are not related.
MODIFY THE OPENCAST CONFIGURATION FILE
Edit the configuration file docs/felix/conf/config.properties and make changes to the Youtube section
youtube.username=utubedelivery youtube.password=utubedelivery youtube.playlist=B8B47104C2C1663B youtube.clientid=abcde youtube.developerkey= AI39si7bx2AbnOM6RM8J7mdrljfZCzisYzDkqvIqEjV3zjbqQIr6-u_bg3R0MLAVVXLqKjSs xu4ReytWFn7ylIlDk6OC7pdXpQ
A playlist helps organize videos in one's Youtube account and is similar to a directory in concept. You may create as many playlists as you like in your account. A playlist can be either public or private.
Each playlist is uniquely identified by an ID. The default playlist identified by "B8B47104C2C1663B" corresponds to the playlist "opencast" under the default Youtube account "utubedelivery".
Please leave the playlist setting as it is until the policy for managing playlists is finalized.
TEST THE YOUTUBE DISTRIBUTION SERVICE.
Copy the configuration file docs/felix/conf/config.properties to $FELIX_HOME/config
cp docs/felix/conf/config.properties $FELIX_HOME/config
and start felix. Run
ps in felix console and make sure the opencast-distribution-service-youtube bundle is active.
Open the browser and access
http://localhost:8080/distribution/youtube/rest/docs
to see the REST documentation. For unknown reason, this URL must be accessed before an HTTP request can be sent successfully to the Youtube distribution REST service to deliver a media package.
In another terminal window, send an HTTP request by
curl -X POST --data-urlencode 'elementId=track-1' --data-urlencode \ 'mediapackage=
It will take a while before the program terminates, which prints the delivered media package upon successful delivery
The line
The prompt from felix console will look similar to the following 13:54:24 INFO (YoutubeDistributionService:107) - Delivering from /var/folders/Aa/Aarxse-6H+WnUcJ+N-J89++++TI/-Tmp-/opencast/workspace/htt plocalhost8080workflowsamplescamera.mpg org.opencastproject.deliver.youtube.YouTubeDeliveryAction
Log into your Youtube account, navigate to the "My videos" section, and make sure the video "camera.mpg" is available.
TROUBLESHOOTING
If the curl program keeps running after several minutes, and the felix console prompts
13:54:24 INFO (YoutubeDistributionService:107) - Delivering from /var/folders/Aa/Aarxse-6H+WnUcJ+N-J89++++TI/-Tmp-/opencast/workspace/htt plocalhost8080workflowsamplescamera.mpg
with no other error messages, it will be most likely because of a duplicate video. Interrupt the curl program, log into your Youtube account, remove the duplicate and try again.
If there is a Java exception message saying "no object DCH for MIME type application/atom+xml", it is probably the version of activation and mail jar files. Change directory to the load directory of the felix installation
cd $FELIX_HOME/load
Check if the correct version of the jar files are packaged in the OSGi bundle
jar -tvf opencast-distribution-service-youtube-0.6-SNAPSHOT.jar | grep activation jar -tvf opencast-distribution-service-youtube-0.6-SNAPSHOT.jar | grep mail
54665 Wed Feb 03 11:19:06 CST 2010 activation-1.1.1.jar 216781 Mon Jan 25 15:00:06 CST 2010 org.apache.servicemix.specs.javamail-api-1.4-1.3.0.jar
Refer to http://code.google.com/p/gdata-java-client/issues/detail?id=130 for more details about this issue. Service Contracts
Please note that the Matterhorn service contracts are in flux. The Matterhorn REST documentation is the most current source of information.
CAPTURE
CaptureAgentService (OLD Matterhorn Project **DON'T USE**) contract service capture
Capture Admin Service (Opencast Developer Wiki) service contract capture
CaptureAgentService (Opencast Developer Wiki) service contract capture
Capture Admin Service (OLD Matterhorn Project **DON'T USE**) contract service capture
COMMON
WorkspaceService (Opencast Developer Wiki) service contract common
WorkspaceService (OLD Matterhorn Project **DON'T USE**) contract common service
ArchiveService (OLD Matterhorn Project **DON'T USE**) contract common service
NotificationService (OLD Matterhorn Project **DON'T USE**) contract common service
WorkingFileRepository (OLD Matterhorn Project **DON'T USE**) contract common service
DISTRIBUTE
iTunesUDistributionService (Opencast Developer Wiki) service contract distribute
FeedDistributionService (OLD Matterhorn Project **DON'T USE**) contract distribute service
YouTubeDistributionService (OLD Matterhorn Project **DON'T USE**) contract distribute service
MatterhornPortalDistributionService (Opencast Developer Wiki) service contract distribute
SearchService (OLD Matterhorn Project **DON'T USE**) contract distribute service
SakaiDistributionService (OLD Matterhorn Project **DON'T USE**) contract distribute service
DownloadDeliveryService (OLD Matterhorn Project **DON'T USE**) contract distribute service
FeedDistributionService (Opencast Developer Wiki) service contract distribute
iTunesUDistributionService (OLD Matterhorn Project **DON'T USE**) contract distribute service
MatterhornPortalDistributionService (OLD Matterhorn Project **DON'T USE**) contract distribute service
SearchService (Opencast Developer Wiki) service contract distribute
StreamingDeliveryService (OLD Matterhorn Project **DON'T USE**) contract distribute service
ENGAGE
Content by label
There is no content with the specified labels
INGEST
IngestService (Opencast Developer Wiki) service ingest contract mediapackage
IngestService (OLD Matterhorn Project **DON'T USE**) contract service mediapackage ingest
MANAGE
Content by label
There is no content with the specified labels
MEDIA
MediaInspectionService (OLD Matterhorn Project **DON'T USE**) contract service media
MediaComposerService (Opencast Developer Wiki) service contract media
MediaComposerService (OLD Matterhorn Project **DON'T USE**) contract service media
MediaAnalysisService (OLD Matterhorn Project **DON'T USE**) contract service mediapackage media
AuthoritativeAnnotationService (OLD Matterhorn Project **DON'T USE**) contract service media
MediaInspectionService (Opencast Developer Wiki) service contract media
MediaAnalysisService (Opencast Developer Wiki) service contract mediapackage media
SCHEDULE Content by label
There is no content with the specified labels
WORKFLOW
SiteIntegrationService (OLD Matterhorn Project **DON'T USE**) contract service workflow
WorkflowService (OLD Matterhorn Project **DON'T USE**) contract service workflow
ConductorService (OLD Matterhorn Project **DON'T USE**) contract service workflow
WorkflowService (Opencast Developer Wiki) service contract workflow
DRAFT
TranslationService (OLD Matterhorn Project **DON'T USE**) contract service draft manage
FeedbackService (Opencast Developer Wiki) engage service contract draft
DEPRECATED IngestService (OLD Matterhorn Project **DON'T USE**) contract common service draft
FeedbackService (OLD Matterhorn Project **DON'T USE**) contract service draft engage
AdminService
ADMINSERVICE
Version Draft 1
Classification Service Type:Admin:Admin
Description Provides service endpoints for:
Admin UI Locations management (list, add, edit, remove) Client management (list, add, edit, remove) ?
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations Add additional operations as required listLocations() addLocation(String name, String location) editLocation(String id, String name, String location) removeLocation(String id) listClients() addClient(String name, String ipAddress, [String Location] ) editClient(String id, String name, String ipAddress, [String Location] ) removeClient(String id)
Name Operation signature (e.g. put(MediaPackage mediaPackage, NotificationCallback callback))
Description Concise description
Notes Notes may include constraints, transactional properties of an operation, questions, comments, artifacts used to define the operation (e.g. workflow, swimlane, or entity diagrams, user stories or use cases) or other notes.
Name Operation signature
Description Concise description
Notes Related Notes
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Replace myservice in the URLs with the new service name in lowercase
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/myservice/docs
WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/myservice?wsdl
ArchiveService
ARCHIVESERVICE
Version Trunk ArchiveService Release Notes
Classification Business
Description This service provides long-term storage and retrieval of Matterhorn MediaPackages and their associated media, metadata and attachment files. This service is designed primarily for internal use.
Context
Assumptions
Service Dependencies None Known Clients
Security
Operations
Name put(MediaPackage mediaPackage, NotificationCallback callback)
Description Put a Matterhorn MediaPackage and all its associated files into an archive.
Notes
Name get(MediaPackageId)
Description Get a Matterhorn MediaPackage from an archive.
Notes
Name get(MediaPackageId, MediaElementId)
Description Get a file associated with a Matterhorn MediaPackage from an archive.
Notes
Name checkin(MediaPackage, NotificationCallback)
Description
Notes
Name checkout(MediaPackageId, NotificationCallback)
Description
Notes
Bindings
Type Java
JavaDocs
Source
Type REST
Documentation
WADL
Type SOAP
WSDL
AuthoritativeAnnotationService
AUTHORITATIVEANNOTATIONSERVICE
Version SNAPSHOT AuthoritativeAnnotationService Release Notes
Classification Service Type:Process and Encode:Annotation
Description This service converts authoritative, time-based annotations, from key/value pairs to the MPEG-7 metadata file format.
Context
Assumptions Assumptions made by this service Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Name createAnnotationDocument(Map
Description Create MPEG-7 document from timestamps and annotations.
Notes
Bindings
Type Java
JavaDocs
Source
Type REST
Documentation
WADL
Type SOAP
WSDL
Capture Admin Service
CaptureAgentService
CAPTUREAGENTSERVICE
Version SNAPSHOT CaptureAgentService Release Notes
Classification Service Type:Capture:Agent
Description This service manages capture agents, as well as their locations, schedules and status.
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Name getCaptureAgent(Location)
Description Get the CaptureAgent for a given location, if one exists.
Notes
Name getSchedule(Location)
Description Get the capture schedule for a given location, if one exists.
Notes Bindings
Type Java
JavaDocs
Source
Type REST
Documentation
WADL
Type SOAP
WSDL
ConductorService
CONDUCTORSERVICE
Version SNAPSHOT ConductorService Release Notes
Classification Process:Common:Workflow
Description This service provides for site-specific configuration of media processing workflows. Custom workflow definitions are managed by the ConductorService, and it is considered a best practice to deploy custom WorkflowOperationHandlers via the default ConductorService implementation.This service is also responsible for processing media packages that were ingested. Workflow 'Transcode, Distribute and Publish' is executed with valid media packages.
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Data Types
Please see the related WorkflowService for complete descriptions of the entities used by the ConductorService.
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/conductor/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/conductor/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/conductor/rest/docs
WADL http://nightly.opencastproject.org/conductor/rest/?_wadl&_type=xml
Type SOAP
WSDL
DownloadDeliveryService
DOWNLOADDELIVERYSERVICE Version SNAPSHOT DownloadDeliveryService Release Notes
Classification Service Type:Team Name:Context, e.g. "Business:Engage:File System" (see Document a Service).
Description This service delivers media from server to client using progressive download.
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Add additional operations as required
Name Operation signature (e.g. put(MediaPackage mediaPackage, NotificationCallback callback))
Description Concise description
Notes Notes may include constraints, transactional properties of an operation, questions, comments, artifacts used to define the operation (e.g. workflow, swimlane, or entity diagrams, user stories or use cases) or other notes.
Name Operation signature
Description Concise description
Notes Related Notes
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Replace myservice in the URLs with the new service name in lowercase
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/myservice/docs
WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/myservice?wsdl
FeedbackService
FEEDBACKSERVICE
Version Draft Classification Data:Engage:Database
Description The FeedbackService stores a learner's action and view statistics.
Context
Assumptions none
Service Dependencies Database
Known Clients Flash Video Player
Security Only used by the video player application
Operations
Name getUserSession(String userId)
Description Takes the unique userId (may be empty). Returns a generated unique sessionId and a generated unique userId, if the userId is empty.
Notes The unique userId may be stored in a local shared object or cookie on the client and passed to this method in later calls. The userId will then be associated with the new sessionId.
Name getSessions(String dayId, int offset, int limit)
Description Returns all sessions of a given dayId (YYYY-MM-DD), sorted by creation date.
Notes The parameters offset and limit are used to page the results.
Name getFootprints(String dayId, int offset, int limit)
Description Returns all footprints of a given dayId (YYYY-MM-DD), sorted by creation date.
Notes The parameters offset and limit are used to page the results.
Name addFootprint(String mediapackageId, String sessionId, int inPoint, int outPoint)
Description Takes the mediaPackageId from the media bundle that is currently watched, the unique sessionId, the inPoint which is the beginning of the footprint and the outPoint which is the end of the footprint.
Notes This Method is called periodically while the learner is watching a video
Bindings
This FeedbackService description is a proposal. There are currently no bindings.
|| Type | Java ||
JavaDocs none
Source none
Type REST
Documentation none
WADL none
Type SOAP
WSDL none
FeedDistributionService
FEEDDISTRIBUTIONSERVICE Replace MyService in the Release Notes link with the new service name in CamelCase
Version SNAPSHOT FeedDistributionService Release Notes
Classification Service Type:Team Name:Context, e.g. "Business:Engage:File System" (see Document a Service).
Description This service provides simple integration of third party systems:
Copy the distribution files to an arbitrary download and/or streaming server. Generate RSS and/or Atom Feeds from the Dublin Core metadata.
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Add additional operations as required
Name Operation signature (e.g. put(MediaPackage mediaPackage, NotificationCallback callback))
Description Concise description
Notes Notes may include constraints, transactional properties of an operation, questions, comments, artifacts used to define the operation (e.g. workflow, swimlane, or entity diagrams, user stories or use cases) or other notes.
Name Operation signature
Description Concise description
Notes Related Notes
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Replace myservice in the URLs with the new service name in lowercase
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/myservice/docs
WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/myservice?wsdl
IngestService MEDIAINGESTSERVICE
Version SNAPSHOT MediaIngestService Release Notes
Classification Service Type:Common:Ingest
Description This service creates and augments Matterhorn MediaPackages.
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Two different approaches are supported by the MediaIngestService:
Thick Client The client itself creates a skeletal MediaPackage. The MediaPackage, tracks, catalogs and attachment are compressed and added to the repository using addMediaPackage(InputStream):
1. Construct MediaPackage XML 2. Compress the MediaPackage, tracks, catalogs and attachment 3. addMediaPackage(InputStream)
Thin Client The client calls createMediaPackage() and receives an empty MediaPackage. This MediaPackage Document is than acompanying the process of ingestion.
To add additional track, catalog or attachment, the client calls addTrack(), addCatalog() and addAttachment() respectevly. The parameters of this methods are:
URL or FileStream of the file being added MediaPackageElementFlavor defining the type of the media MediaPackage the last recieved document of this package
The methods return an updated MediaPackage, which must be used with the next call to the add methods. Each add method can be called multiple times. The process to ingest:
1. createMediaPackage() 2. addTrack(), addCatalog(), addAttachment() 3. ingest()
Name addZippedMediaPackage(MediaPackage)
Description Add an existing MediaPackage to the repository.
Notes
Name createMediaPackage()
Description Create and return a new MediaPackage.
Notes
Name addAttachment(InputStream, MediaPackageElementFlavor, MediaPackage)
Description Add a media track to an existing MediaPackage and adds the content to the working file repository.
Notes
Name addCatalog(InputStream, MediaPackageElementFlavor, MediaPackage) Description Add a metadata catalog to an existing MediaPackage and adds the content to the working file repository.
Notes
Name addAttachment(InputStream, MediaPackageElementFlavor, MediaPackage)
Description Add an attachment to an existing MediaPackage and adds the content to the working file repository.
Notes
Name ingest(MediaPackage)
Description Ingests the completed MediaPackage into the system.
Notes
Name discardMediaPackage(MediaPackageId)
Description Delete an existing MediaPackage and all linked files from the repository.
Notes
Bindings
Type Java
JavaDocs
Source
Type REST
Documentation
WADL
Type SOAP
WSDL iTunesUDistributionService
ITUNESUDISTRIBUTIONSERVICE
Replace MyService in the Release Notes link with the new service name in CamelCase
Version SNAPSHOT iTunesUDistributionService Release Notes
Classification Service Type:Team Name:Context, e.g. "Business:Engage:File System" (see Document a Service).
Description Concise description
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Add additional operations as required Name Operation signature (e.g. put(MediaPackage mediaPackage, NotificationCallback callback))
Description Concise description
Notes Notes may include constraints, transactional properties of an operation, questions, comments, artifacts used to define the operation (e.g. workflow, swimlane, or entity diagrams, user stories or use cases) or other notes.
Name Operation signature
Description Concise description
Notes Related Notes
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Replace myservice in the URLs with the new service name in lowercase
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/myservice/docs
WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml
Notes cf. FeedDistributionService
Type SOAP
WSDL http://nightly.opencastproject.org/private/myservice?wsdl
Notes 1. Copy the distribution files to: a. Akamai Network; or b. other download or streaming location. 2. Determine tab ID using Dublin Core metadata; create tab, if necessary. 3. Add entry to tab.
MatterhornPortalDistributionService
MATTERHORNPORTALDISTRIBUTIONSERVICE
Replace MyService in the Release Notes link with the new service name in CamelCase
Version SNAPSHOT MatterhornPortalDistributionService Release Notes
Classification Service Type:Team Name:Context, e.g. "Business:Engage:File System" (see Document a Service).
Description Concise description
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service Security Particular security requirements
Operations
Usage 1. Copy distribution files to: a. DownloadService; and/or b. StreamingService 2. Update search index with call to SearchService.
Name distribute(MediaPackage mediaPackage)
Description Copy tracks, metadata and attachments to local filesystem
Notes Local distribution
Name Operation signature
Description Concise description
Notes Related Notes
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Replace myservice in the URLs with the new service name in lowercase
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/myservice/docs
WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/myservice?wsdl
MediaAnalysisService
MEDIAANALYSISSERVICE
Version SNAPSHOT MediaAnalysisService Release Notes
Classification Service Type:Process and Encode:Analysis
Description This service can perform a number of time-based analysis operations, e.g. speech-to-text, on a media file.
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service Security Particular security requirements
Operations
Name listTasks()
Description Get a list of available analysis operations.
Notes
Name analyse(MediaPackage, URL, ProcessingInstruction, NotificationCallback)
Description Process a media track of a specific Matterhorn MediaPackage according to the given ProcessingInstructions. The result of the analysis is sent to the given URL and a callback is made.
Notes
Bindings
Type Java
JavaDocs
Source
Type REST
Documentation
WADL
Type SOAP
WSDL
MediaComposerService
OVERVIEW
This service composes a new media file from a set of media tracks and metadata files according the given instructions.
USAGE Internal server error
OPERATIONS listProfiles()
Get a list of available composition profiles (e.g. "flash.http" or "flash.rtmp").
String[] listProfiles()
Parameters none
Return Value
String[] An array of available composition profiles
Exceptions Discussion
See Also
Related Sample Code
Declared In
API
Matterhorn Implementation
Module
Package compose(MediaPackage, URL, ProcessingInstruction, NotificationCallback)
Compose a new media file from media tracks of a specific Matterhorn MediaPackage according to the given ProcessingInstructions. The result of the composition is sent to the given URL and a callback is made.
void compose(MediaPackage mediaPackage, URL url, ProcessingInstruction instructions, NotificationCallback callback)
Parameters mediaPackage A specific Matterhorn Media Package URL A URL to send the result of the composition instructions A specific encoding profile and media tracks for composition callback cf. NotificationService
Return Value null
Exceptions
Discussion
See Also
Related Sample Code
Declared In
API
Matterhorn Implementation
Module
Package
MediaInspectionService
MEDIAINSPECTIONSERVICE
Version SNAPSHOT MediaInspectionService Release Notes Classification Service Type:Process and Encode:Analysis
Description This service extracts technical metadata (e.g. duration, codec) from a given media file.
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Name inspect(URL, NotificationCallback)
Description Get the technical metadata of a file at the given URL.
Notes
W3C XML Document
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/inspection/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/inspection/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/inspection/rest/docs
WADL http://nightly.opencastproject.org/inspection/rest/?_wadl&_type=xml
Type SOAP
WSDL
NotificationService
NOTIFICATIONSERVICE
Version SNAPSHOT NotificationService Release Notes
Classification Service Type:Common:Web Services
Description This service describes a RESTful callback mechanism and should be implemented by Service Endpoints that require notifications for long-running operations. Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Name receiveNotification(MediaPackage)
Description Receive notification of a change to a media package.
Notes
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/notification/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/notification/api/package-summary.html
Type REST
Documentation
WADL
Type SOAP
WSDL
SakaiDistributionService
SAKAIDISTRIBUTIONSERVICE
Replace MyService in the Release Notes link with the new service name in CamelCase
Version SNAPSHOT SakaiDistributionService Release Notes
Classification Service Type:Team Name:Context, e.g. "Business:Engage:File System" (see Document a Service).
Description Concise description
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Add additional operations as required
Name Operation signature (e.g. put(MediaPackage mediaPackage, NotificationCallback callback))
Description Concise description Notes Notes may include constraints, transactional properties of an operation, questions, comments, artifacts used to define the operation (e.g. workflow, swimlane, or entity diagrams, user stories or use cases) or other notes.
Name Operation signature
Description Concise description
Notes Related Notes
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Replace myservice in the URLs with the new service name in lowercase
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/myservice/docs
WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/myservice?wsdl
Scheduler Service
SCHEDULERSERVICE
Version Draft
Classification Business:Admin:Scheduling
Description This service serves three functions:
Communicate with Scheduler UI Subscribe to iCalendars Create iCalendars
Context
Assumptions External iCalendars will include:
Capture agent ID in ATTENDEE field
Service Dependencies AuthoritativeMetadataService (not yet implemented).
Known Clients Capture Agent, Scheduler UI
Security
Data Types
Name SchedulerEvent
Description A schedulable event. Values and types are yet to be determined. Notes
W3C XML Document
Name SchedulerSeries
Description A series of linked events. Values and type are yet to be determined. Notes
W3C XML Document
Name SchedulerFilter
Description A filter for SchedulerEvents. All fields are optional. Values are search patterns, excepting IDs, which are explicit references.
Notes
W3C XML Document
Operations Name String setICalendarURL (String url, long updateDuration)
Description Specify iCalendar file URL. updateDuration determines the frequency with which the calendar is reloaded. A value of '0' indicates one-time update. Returns iCalendar ID. Null is returned if the calendar fails to load.
Notes Up to iteration 5 there will only be a manual import. The ID of the selected capture client should be in the ATTENDEE property of the iCalendar. It is not clear if there will be a aggregation of different iCalendars from separate systems. As long as there is only on iCal URL the returned ID will is of no importance. Iteration 6 or later
Name String[] listICalendarIds ()
Description List the IDs of all existing iCalendars.
Notes Currently only one ID will be allowed. If iCalendar aggregation comes up it can be several. iteration 6 or later
Name boolean removeICalendar (String id)
Description Remove an iCalendar and all its events from the SchedulerService.
Notes As long as there is no aggregation id can be anything, the only source will be removed. iteration 6 or later
Name String uploadICalendar (InputStream ical)
Description Upload a new iCalendar file. Returns iCalendar ID. Null is returned if the calendar fails to load.
Notes As long as there is no aggregation an existing file will be overwritten and the same ID returned. iteration 5
Name int importEvents (String id, SchedulerFilter filter)
Description Import events using a filtered iCalendar. Redundant events will be removed from the database prior to import. Returns count of imported events.
Notes As long as there is no aggregation id can be anything, the only source will be used. iteration 5
Name boolean uploadExclusionDates (InputStream ical)
Description Upload an iCalendar file of exclusion dates. Returns false if the calendar fails to load
Notes iteration 6 or later
Name boolean setExclusionPeriod (long start, long end)
Description Set a period in which no events will be recorded.
Notes iteration 6 or later
Name int removeEventsAtExclusionDates ()
Description Remove all events that fall under exclusion dates. Returns count of deleted events.
Notes iteration 6 or later
Name SchedulerEvent addEvent (SchedulerEvent event)
Description Add a new event. Returns unique event ID.
Notes iteration 4
Name boolean removeEvent (String eventId)
Description Remove an event. Returns true on success.
Notes iteration 4
Name boolean updateEvent (SchedulerEvent event)
Description Update an existing event. Returns true on success.
Notes iteration 4
Name SchedulerEvent getEvent (String eventId) Description Get specific scheduler-event.
Notes iteration 4
Name SchedulerEvent [] getEvents (SchedulerFilter filter)
Description Get all scheduler-events that pass through a filter.
Notes iteration 5
Name SchedulerSeries addSeries (SchedulerSeries series)
Description Add a new scheduler-series. Returns unique series ID.
Notes iteration 5
Name boolean removeSeries (String seriesId)
Description Remove specific scheduler-series. Returns true on success.
Notes iteration 5
Name boolean updateSeries (SchedulerSeries series)
Description Update a specific scheduler-series. Return true on success.
Notes iteration 5
Name SchedulerSeries getSeries (String seriesId)
Description Get specific scheduler-series.
Notes iteration 5
Name boolean addEventToSeries (String eventId, String seriesId)
Description Add an existing scheduler-event to an existing scheduler-series. Returns true on success.
Notes iteration 5
Name String getCalendarForCaptureAgent (String captureAgentId)
Description Get iCalendar text for specific capture agent.
Notes interation 4
Name String setFilterForCaptureAgent (String captureAgentId, SchedulerFilter filter)
Description Set iCalendar filter for a specific capture agent. By default, the ATTENDEE property specifies the capture agent ID.
Notes interation 5
Name String getMetadataForEvent (String eventId)
Description Get metadata for a specific scheduler-event.
Notes
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/scheduler/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/scheduler/docs WADL http://nightly.opencastproject.org/scheduler/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/scheduler?wsdl
SearchService
SEARCHSERVICE
Version SNAPSHOT SearchService Release Notes
Classification Information
Description This service provides query-style access to the metadata of distributed media packages.
Context
Assumptions None
Service Dependencies None
Known Clients Engage frontend, RSS/Atom feed generator
Security None
Operations
Name add(MediaPackage mediaPackage)
Description Adds the contents of the media package to the search index.
Notes The search index knows about two kinds of items: episodes (e. g. one lecture) and series (e. g. a course containing one or many lectures). If the media package contains both a dublinc core document for the episode and the containing series, both of them are being added. Should either or both of them already exist, the respective item will be updated to match the current metadata.
Name delete(MediaPackage mediaPackageId)
Description Removes the entry identified by mediaPackageId from the search index.
Notes Note that this method can be used to remove either a single episode or a series document from the search index. In both cases, only that one entry is removed, and there is no cascading. So if for example a series document is being removed, all the episodes belonging to that lecture will still be there.
Name getEpisodesAndSeriesByText(String text, int offset, int limit)
Description Returns all episode and series that match the given text in any of their metadata fields.
Notes The text should be passed in as either one word or multiple words separated by spaces. The parameters offset and limit are used to page results.
Name getEpisodesBySeries(String seriesId)
Description Returns the episodes that are part of the series identified by seriesId.
Notes The result is ordered by date, in descending order.
Name getSeriesByDate(int offset, int limit)
Description Returns all series, sorted by date in descending order.
Notes The parameters offset and limit are used to page the results.
Name getSeriesById(String seriesId, int offset, int limit)
Description Returns the series that is identified by seriesId.
Notes The parameters offset and limit are used to page the results. Name getSeriesByText(String text, int offset, int limit)
Description Returns the series that match the given text in any of its metadata fields.
Notes The text should be passed in as either one word or multiple words separated by spaces. The parameters offset and limit are used to page results.
Name getEpisodeAndSeriesById(String seriesId, int offset, int limit)
Description Returns the episodes that are part of the series identified by seriesId along with that serie's metadata.
Notes The parameters offset and limit are used to page results.
Name getEpisodesAndSeriesByText(String text, int offset, int limit)
Description Returns both episodes and series containing metadata that matches the given text.
Notes The text should be passed in as either one word or multiple words separated by spaces. The parameters offset and limit are used to page results.
Name getEpisodeById(String episodeId)
Description Returns the episode that is identified by episodeId.
Notes
Name getEpisodesByDate(int offset, int limit)
Description Returns the episodes sorted by data in descending order.
Notes The parameters offset and limit are used to page the results.
Name getEpisodesByText(String text, int offset, int limit)
Description Returns the episodes containing metadata that matches the given text.
Notes The text should be passed in as either one word or multiple words separated by spaces. The parameters offset and limit are used to page results.
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/search/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/search/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/search/docs
WADL http://nightly.opencastproject.org/search/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/search?wsdl
SiteIntegrationService
SITEINTEGRATIONSERVICE
Version SNAPSHOT SiteIntegrationService Release Notes
Classification Service Type:Team Name:Context, e.g. "Business:Engage:File System" (see Document a Service).
Description Concise description
Context Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Add additional operations as required
Name Operation signature (e.g. put(MediaPackage mediaPackage, NotificationCallback callback))
Description Concise description
Notes Notes may include constraints, transactional properties of an operation, questions, comments, artifacts used to define the operation (e.g. workflow, swimlane, or entity diagrams, user stories or use cases) or other notes.
Name Operation signature
Description Concise description
Notes Related Notes
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Replace myservice in the URLs with the new service name in lowercase
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/myservice/docs
WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/myservice?wsdl
StreamingDeliveryService
STREAMINGDELIVERYSERVICE
Replace MyService in the Release Notes link with the new service name in CamelCase
Version SNAPSHOT StreamingDeliveryService Release Notes
Classification Service Type:Team Name:Context, e.g. "Business:Engage:File System" (see Document a Service).
Description This service delivers files from server to client using streams.
Context Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Add additional operations as required
Name Operation signature (e.g. put(MediaPackage mediaPackage, NotificationCallback callback))
Description Concise description
Notes Notes may include constraints, transactional properties of an operation, questions, comments, artifacts used to define the operation (e.g. workflow, swimlane, or entity diagrams, user stories or use cases) or other notes.
Name Operation signature
Description Concise description
Notes Related Notes
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Replace myservice in the URLs with the new service name in lowercase
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/myservice/docs
WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/myservice?wsdl
TranslationService
TRANSLATIONSERVICE
Version Draft
Classification Service Type: Information Name: Admin Tools Team
Description This service will provide translations for text in UIs provided as key value pairs.
Context
Assumptions Word order of variables that will be filled in, can not be changed. The plural of words is handled like it will be handles in english. Service Dependencies none
Known Clients JS methods in UI (to be developed
Security none
Operations
Name String translate (String languageId, String text)
Description Translates a given text into the language specified by languageId. I no translation is available it will return the input-string
Notes Usualy it is expected that the whole english sentence that should be translated is entered in "text". But sometime for example in help texts it may be useful to use a key value instead of the text. As placeholder for variables please use "%1"
Name Map
Description Generates a HashMap with the texts-array as keys and the translations in the given language (specified by languageId) as values
Notes same comment as on translate, as this method will probably call translate several times.
Name Map
Description More or less same as translateTexts, but the texts-array is already stored for this context. Context is simply an identifier, that has to be known to the translation service
Notes New Contexts can be created with createContext method
Name LanguageInfo [] availableLanguages ()
Description returns an Array of LanguageInfo Objects that contain the languageId, the plaintext name of the language and an URL where an icon for the language can be found.
Notes
Name boolean createContext (String context, String [] texts)
Description Creates a new context with the given set of texts/keys. Returns false if the context name is already in use
Notes If texts in the array are unknown to the service it will add them to the list of texts that have to be translated.
Name boolean analyzePage (String url, String context)
Description Creates a new context with the texts from the html-page that will be found under this URL. Returns false if the context name is already in use, or the page could not be loaded
Notes If texts in the array are unknown to the service it will add them to the list of texts that have to be translated.
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/translation/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/translation/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/translation/docs
WADL http://nightly.opencastproject.org/translation/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/translation?wsdl
WorkflowService
WORKFLOWSERVICE Version SNAPSHOT WorkflowService Release Notes
Classification Process:Common:Workflow
Description This service calls other services as dictated by a given Matterhorn workflow.
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Data Types
Name WorkflowOperation
Description An operation to run as part of a workflow.
Notes
W3C XML Document
Name WorkflowDefinition
Description An description of a workflow, used as a template for WorkflowInstances.
Notes
W3C XML Document
Name WorkflowInstance Description An instance of a running, paused, or stopped workflow.
Notes
W3C XML Document
Operations
Name getWorkflowDefinitionByName(String name)
Description Get workflow definition that was registered under given name.
Notes Implemented iteration 5
Name listAvailableWorkflowDefinitions()
Description Get all the workflow definitions that are registered.
Notes Implemented iteration 5
Name isRunnable(WorkflowDefinition workflowDefinition)
Description Check if given workflow definition will run at the moment. Notes Implemented iteration 5
Name registerWorkflowDefinition(WorkflowDefinition definition)
Description Register workflow definition with the service.
Notes Implemented iteration 5
Name unregisterWorkflowDefinition(String title)
Description Unregister workflow definition with given title.
Notes Implemented iteration 5
Name getWorkflowsById(String workflowId)
Description Retrieves the workflow with given workflow ID.
Notes Implemented iteration 5
Name getWorkflowsInState(State state, int offset, int limit)
Description Get specified amount of workflows, current and past, in a specific state.
Notes Implemented in iteration 5
Name getWorkflowsByMediaPackage(String mediaPackageId)
Description Get all workflows associated with a specific media package ID.
Notes Implemented in iteration 5
Name getWorkflowsByDate(int offset, int limit)
Description Retrieves given number of workflows ordered by date from given offset
Notes Implemented in iteartion 5
Name getWorkflowsByEpisode(String episodeId)
Description Returns the workflow instances that dealt with given episode.
Notes Implemented in iteration 5
Name getWorkflowsBySeries(String seriesId)
Description Returns the workflow instances that deal with given series.
Notes Implemented in iteration 5
Name getWorkflowsByText(String text, int offset, int limit)
Description Returns the workflow instances that deal with episodes matching given search terms.
Notes Implemented in iteration 5
Name getWorkflowsByTextAndState(State state, String text, int offset, int limit)
Description Returns the workflow instances that deal with episodes matching given search terms and are in specified state.
Notes Implemented in iteration 5
Name countWorkflowInstances()
Description Returns the number of created workflow instances that have been created to date.
Notes Implemented in iteration 5
Name start(WorkflowDefinition workflow, MediaPackage mediaPackage, Map
Notes Implemented in iteration 3.
Name stop(WorkflowId workflowId)
Description Stop a given workflow.
Note Implemented in iteration 3.
Name suspend(WorkflowId workflowId)
Description Suspend a given workflow.
Notes Implemented in iteration 3.
Name resume(WorkflowId workflowId)
Description Resume a given workflow.
Notes Implemented in iteration 3.
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/workflow/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/workflow/api/package-summary.html
Notes The Java bindings provide a plugin mechanism to allow multiple "handlers" to run upon each WorkflowOperation defined for a given WorkflowDefinition. Each WorkflowOperationHandler runs in parallel for each matching WorkflowOperation. New WorkflowOperationHandlers ma y be registered via OSGi. All WorkflowOperationHandlers registered as services with the "workflow.operation" property set to a known WorkflowOperation name will run as part the of handling of a WorkflowOperation.
Type REST
Documentation http://nightly.opencastproject.org/workflow/rest/docs
WADL http://nightly.opencastproject.org/workflow/rest/?_wadl&_type=xml
Type SOAP
WSDL
Please see the related ConductorService service, which provides site-specific capabilities for customizing workflows.
WorkingFileRepository
WORKINGFILEREPOSITORY
Version SNAPSHOT WorkingFileRepository Release Notes
Classification Service Type:Common:File System
Description This service is a RESTful file storage helper designed primarily for internal use.
Context
Assumptions Assumptions made by this service
Service Dependencies
Known Clients Other tools or services that use this service
Security Particular security requirements Operations
Name put(MediaPackageID, MediaPackageElementID, InputStream)
Description Put an arbitrary file into the repository.
Notes
Name get(MediaPacakgeID, MediaPackageElementID)
Description Get a file in the repository.
Notes
Name getURL(MediaPackageID, MediaPackageElementID)
Description Get a URL location of the element.
Notes
Name delete(MediaPackageID, MediaPackageElementID)
Description Delete a file in the repository.
Notes
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/workingfilerepository/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/workingfilerepository/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/files/docs
WADL http://nightly.opencastproject.org/files/?_wadl&_type=xml
Type SOAP
WSDL
WorkspaceService
WORKSPACESERVICE
Version SNAPSHOT WorkspaceService Release Notes
Classification Service Type:Common:File System
Description This service allows OSGi clients to efficiently access a java.io.File object from an arbitrary URL. Services sharing the same OSGi container will share a local cache. Multiple OSGi containers can also leverage a shared storage cache.
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Name get(URL) Description Get the file handle for a given URL.
Notes
Name put(MediaPackageID, MediaPackageElementID, URL)
Description cf. WorkingFileRepository
Notes
Name get(MediaPackageID, MediaPackageElementID)
Description cf. WorkingFileRepository
Notes
Name delete(MediaPackageID, MediaPackageElementID)
Description cf. WorkingFileRepository
Notes
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/workspace/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/workspace/api/package-summary.html
Type REST
Documentation
WADL
Type SOAP
WSDL
YouTubeDistributionService
YOUTUBEDISTRIBUTIONSERVICE
Replace MyService in the Release Notes link with the new service name in CamelCase
Version SNAPSHOT YouTubeDistributionService Release Notes
Classification Service Type:Team Name:Context, e.g. "Business:Engage:File System" (see Document a Service).
Description Concise description
Context
Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Add additional operations as required
Name distribute(MediaPackage mediaPackage) Description Distribute track(s) to YouTube
Notes Distribute to YouTube using Google Data API (gdata)
Name Operation signature
Description Concise description
Notes Related Notes
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Replace myservice in the URLs with the new service name in lowercase
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/myservice/docs
WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/myservice?wsdl
Entities
MEDIAPACKAGE
MediaPackage Manifest (OLD Matterhorn Project **DON'T USE**) mediapackage entity
MediaPackage Overview (OLD Matterhorn Project **DON'T USE**) mediapackage entity
MediaPackage Attachment (OLD Matterhorn Project **DON'T USE**) mediapackage entity
MediaPackage Track (OLD Matterhorn Project **DON'T USE**) mediapackage entity
MediaPackage Catalog (OLD Matterhorn Project **DON'T USE**) mediapackage entity
MediaPackage Attachment
Attachment
This document provides low-level documentation of the Attachment element of a media package. An attachment represents any addition to the media package that does not qualify as either a track or a catalog. Typical candidates for an attachment are the slides of a presentation in pdf or keynote format. Attachment Mimetype Url Size Checksum
The following is an example of what an Attachment might look like in the manifest. It lists the main technical properties, such as the document's checksum:
Example attachment
The type attribute of the parent element can be used to hint to the type of attachment and is subject to definition by the system using the media package.
Mimetype
The attachments MimeType entry specifies the content type and content subtype of the attachment as listed in the IANA specification.
Url
The url specifies the attachments location and is expected to be composed as detailed in rfc 2396. Essentially, this means that the url must consist of the protocol (e. g. http://, ftp:// etc) and an absolute path.
Notice Depending on the actual implementation of the media package, protocols different from the mandatory http:// may be used.
Size
The size specifies the catalog size in bytes.
Checksum
In order to allow users of the media package to make sure that the attachment they just downloaded is correct with respect to its bit order, a checksum is provided as well as the method used to compute it. MediaPackage Catalog
Catalog
This document provides low-level documentation of the Catalog element of a media package. A catalog represents static and/or isochronic metadata describing the media package as a whole or certain parts of it. In most cases, a Dublin Core metadata catalog will be featured in the media package. By adding captions or by running media analysis on the package, isochronic metadata can be added as well. Catalog MimeType Url Size Checksum
Following is an example of what a Catalog might look like in the manifest. It lists the catalogs properties, such as the type of the catalog and what it refers to, as well as technical values, such as the document's checksum:
Example catalog
MimeType
The catalogs mimetype entry specifies the content type and content subtype of the catalog as specified in the IANA specification. For strategic reasons, the mime type will almost always be some subtype of text.
Url
The url specifies the catalogs location and is expected to be composed as detailed in rfc 1738. Essentially, this means that the url must consist of the protocol (e. g. http://, ftp:// etc) and an absolute path.
Notice Depending on the actual implementation of the media package, protocols different from the mandatory http:// may be used.
Size
The size element specifies the catalog size in bytes.
Checksum
In order to allow users of the media package to make sure that the catalog they just downloaded is correct with respect to its bit order, a checksum is provided as well as the method used to compute it. MediaPackage Manifest
Manifest
This document provides in-depth documentation on the media package manifest, which mainly lists the packages contents along with their core technical properties. The aim of the manifest is to allow interested parties in knowing exactly what data they are dealing with without having to download all (potentially huge) parts of it in advance. Manifest Elements Tracks Catalogs Attachments References
Following is an example of what a manifest might look like. The example features one track (with both an audio stream and a video stream), trhee metadata catalogs (a dublin core for the media package itself, one for the series that the package belongs to and one mpeg-7 catalog containing isochronic metadata gained from track track-1):
Example manifest
The id attribute of the Manifest element contains the media package's unique identifier, while the duration attribute indicates the total length of the media production in milliseconds (ms).
Elements
Tracks
A track represent audiovisual media that is part of the media package. It is equal to a movie container like QuickTime's .mov, which may itself consist of one or more streams (e. g. a video stream in H.264 and an audio track in AAC).
Every track is identified by an id that is unique to the media package, so the tupel of (mediapackage id, track id) will fully identify the track.
The track documentation will go into more details on how to work with tracks and how they are represented in the media package.
Catalogs
A catalog typically contains static and/or isochronic metadata that can either describe the media package as a whole or refer to a certain track or attachment inside the package. Typically, those metadata catalogs will be one of Dublin Core (static metadata) or MPEG-7 (isochronic metadata), but other types of catalogs can be added as well.
Every catalog is identified by an id that is unique to the media package, so the tupel of (mediapackage id, catalog id) will fully identify the catalog.
The catalog documentation will go into more details on how to work with catalogs and how they are represented in the media package.
Attachments
An attachment represents any kind of document that can be added to the media package. Typical examples of an attachment are: slides of the presentation as pdf or a cover image for the lecture.
Every attachment is identified by an id that is unique to the media package, so the tupel of (mediapackage id, attachment id) will fully identify the attachment.
The attachment documentation will go into more details on how to work with attachments and how they are represented in the media package.
References
The ref attribute on any of the media package elements may be used to identify references to other package elements, the package itself or outside entities. The following reference schemas are implemented:
self the package element refers to the package as a whole. A good example for this is the dublin core that specifies the static metadata for a recording, thereby describing the media package itself.
track:
series:
If the ref attribute is ommitted, the value is assumed to be self. MediaPackage Overview
Media Package
A media package is considered the business document within the matterhorn ecosystem. Such a package consists of a manifest and a list of pack age elements that are referred to in the manifest. Every media package (once ingested) is identified by a unique identifier, that is returned at ingest time.
Currently, there are three kinds of package elements:
Media tracks Metadata catalogs Attachments Please refer to the sections below to get detailed information on any of the package element types, their representation in the manifest and how to create, add, modify and delete them.
Matterhorn provides access to media packages in two ways:
First, there is a java library in place that allows services to create, access and manipulate media packages.
Second, Matterhorn comes with a set of services that allow for the same operations while the packages have already been ingested into the system. (e. g. a lecture has been captured, ingested by the capture device and is then presented to a staff member via a user interface. The staff member may now add static metadata like title and author or isochronic metadata like captions and comments).
Please see using related services for a list of services that might be used to modify media packages.
Manifest
The manifest serves as an index to the media package, containing references and technical information on tracks, catalogs and attachments. The intention is that by looking at the manifest, users will know what the media package's content is and what they can expect when accessing those elements.
The manifest documentation will go into more details on what a manifest would look like.
Tracks
A track represent audiovisual media that is part of the media package. It is equal to a movie container like QuickTime's .mov, which may itself consist of one or more streams (e. g. a video stream in H.264 and an audio track in AAC).
Every track is identified by an id that is unique to the media package, so the tupel of (mediapackage id, track id) will fully identify the track.
The track documentation will go into more details on how to work with tracks and how they are represented in the media package.
Catalogs
A catalog typically contains static and/or isochronic metadata that can either describe the media package as a whole or refer to a certain track or attachment inside the package. Typically, those metadata catalogs will be one of Dublin Core (static metadata) or MPEG-7 (isochronic metadata), but other types of catalogs can be added as well.
Every catalog is identified by an id that is unique to the media package, so the tupel of (mediapackage id, catalog id) will fully identify the catalog.
The catalog documentation will go into more details on how to work with catalogs and how they are represented in the media package.
Attachments
An attachment represents any kind of document that can be added to the media package. Typical examples of an attachment are: slides of the presentation as pdf or a cover image for the lecture.
Every attachment is identified by an id that is unique to the media package, so the tupel of (mediapackage id, attachment id) will fully identify the attachment.
The attachment documentation will go into more details on how to work with attachments and how they are represented in the media package.
Related documentation
Cookbook
MediaPackage Cookbook (OLD Matterhorn Project **DON'T USE**) mediapackage cookbook
Customizing Dublin Core Catalogs (Opencast Developer Wiki) cookbook mediapackage
Using media package related services
IngestService (OLD Matterhorn Project **DON'T USE**) contract service mediapackage ingest
MediaAnalysisService (OLD Matterhorn Project **DON'T USE**) contract service mediapackage media MediaAnalysisService (Opencast Developer Wiki) service contract mediapackage media
IngestService (Opencast Developer Wiki) service ingest contract mediapackage
MediaPackage Track
Track
This document provides low-level documentation of the track element of a media package. A track represents an audiovisual media container within the media package. Usually, one or two tracks (accompanied by metadata catalogs) make a media package. The information contained in the manifest's track record represents the technical metadata for the movie container as well as the streams contained therein. Track Mimetype Url Size Checksum Duration Video streams Device Encoder Resolution Interlacing Bitrate Framerate Audio streams Device Encoder Channels Bitdepth Samplingrate
Following is an example of what a track might look like in the manifest. It lists the tracks properties, divided into the track container and the streams that are contained therein: track
Mimetype
The track mimetype entry specifies the content type and content subtype of the movie container as specified in the IANA specification. In the example, the track contains a video movie container wrapped into a dv container.
Url
The url specifies the track location and is expected to be composed as detailed in rfc 2396. Essentially, this means that the url must consist of the protocol (e. g. http://, ftp:// etc) and an absolute path.
Notice Depending on the actual implementation of the media package, protocols different from the mandatory http:// may be used. Size
The size element specifies the tracks size in bytes.
Checksum
In order to allow users of the media package to make sure that the track they just downloaded is correct with respect to its bit order, a checksum is provided as well as the method used to compute it.
Duration
The duration is given in milliseconds (ms) and indicates how long the track takes on the timeline.
VIDEO STREAMS
The element video specifies a video stream within the movie container. The stream is further described by its child elements (see below) and can be referred to by the value of the id attribute.
Device
In order to allow for future implementation of long-term archival strategies, it is important to know what device and which device driver was used to record the stream.
Encoder
The encoder element identifies the software that was used to encode the stream into the specified codec.
Resolution
Interlacing
A video stream can either be interlaced or de-interlaced. Valid entries for the interlacing element are yes and no.
Bitrate
The bitrate specifies the number of bits per seconds that are delivered by the stream.
Framerate
The framerate specifies how many frames are to be displayed per second.
AUDIO STREAMS
Device
In order to allow for future implementation of long-term archival strategies, it is important to know what device and which device driver was used to record the stream.
Encoder
The encoder element identifies the software that was used to encode the stream into the specified codec.
Channels
The channels element identifies the number of audio channels present in the stream. For mono streams, the value will be 1 while for stereo recordings it will obviously be 2.
Bitdepth
The bitdepth indicates the recordings bit depth. Commonly, recordings are taken at 16 bits, allowing for the encoding of more than 65'000 different audio levels.
Samplingrate
The samplingrate indicates the number of samples per second. Usually, this value will be 48'000. User Experience BA-UX Common BA-UX Engage BA-UX Admin App BA-UX Common
Business Analysis/User Experience Cross-Project Welcome Page Brainstorming Design Principles Customer Research User Research Workflows Welcome Page Brainstorming
Ideas
general question: is this a 'user' or a 'technicans' page? (in case it's technical then a *user* should be given a way to easily reach the matterhorn user land) as a first (and very quick step) the welcome page could be given some html/css make-up (see WP_draft1 below) maybe present just a very simple navigation to the user interfaces maybe present a list of available recordings? maybe present dashboard-like status overview (like 'there are 5 capture agents, 3 of them recording right now, 2 recordings are beeing processed, 124 recordings are available...') maybe showing the world map indicating where matterhorn is also installed (Chris' idea in Zürich, loving it), providing links to the other adopters media repository/campus sites the welcome page is the site one sees when navigating to eg. http://matterhron.cobbler.edu, but there's also the need to have a post-inst allation page (see chat conversion below)
Design Suggestions WP_draft1: view full size
css styles applied to the tables coherent layout applied to tables (cols are aligned) UI table moved to the top (users might be more interested in finding the links to the UIs), also some descriptive caption (e.g "available user interfaces" / "running services") might by good. added to Matterhorn logo to the top of the page so that everyone who hits this site first realizes 'ah, this is Matterhorn'.
Mock-Ups
Supporting Material
11-18-09 IRC Conversation cab938: 12
11-16-09 Mailing List Conversation http://n2.nabble.com/Installation-Welcome-Page-Brainstorm-td4014407.html#a4014407 Design Principles
Visual Design Should:
be simple, yet elegant be usable (e.g. visual design should not detract from usability of application) be readable be consistent use whitespace intelligently use text wherever possible for words (not graphics) so it is searchable and re-sizable have perfect alignment of items which are intended to be aligned have sufficient contrast use colors that make sense to someone who is colorblind use colors that do not give mixed messages about functionality (e.g. red usually means "error")
Web Forms
Take the time to evaluate every question you are adding to your form. Be vigilant about removing everything that isn't necessary. Organize the content on your forms into logical groups to aid scanning & completion Use the minimal amount of visual information necessary to distinguish content groups A subtle background color change or thin rule is often all you need to group related content in a form Use the "tabindex" HTML attribute to control tabbing order through a form Web form labels should use succinct, natural language and consistent capitalization to make answering the questions they pose as easy as possible When you are trying to reduced completion times or if you need flexible label lengths for localization, consider top-aligned labels When you have similar goals but vertical screen real estate constraints, consider right-aligned labels Different label alignments in a single form will disrupt a clear path to completion and will confuse many people If secondary actions (e.g. Cancel) are required, ensure there is a clear visual distinction between the primary & secondary action Align primary actions with input fields to create a clear path to completion If any input fields are responsible for an error, clearly mark them with a double visual emphasis to ensure they are noticeable from: Web Form Design by Luke Wroblewski Customer Research
This section of the wiki focuses on research we are doing to better understand the needs of our customers, those that will make a decision to adopt Matterhorn (or not). Note that we differentiate between customers (people that make a purchasing/adoption decision) and users, the people who actually use the product, especially those that use it on a regular basis (We also have a section of the wiki for User Research). In some institutions customers and users are the same people (and it will make sense to combine research activities for both area). Customer interviews Customer surveys Deviant scenarios Matterhorn Orgsonas Outstanding questions CUSTOMER INTERVIEWS
Interview planning and reporting Interview questions Interview Tips Publicly shareable interview summaries Who to interview Update August 2009: The interviews have been finished and analysed (due to privacy issues, this has been done in a private space). Matterhorn Orgsonas have been created on the basis of the information contained in the interviews.
Interview planning and reporting
Please indicate which interviews you are planning, including the date scheduled. As soon as the interview has been done, mark them as "done" in the status row.
Before the acutal interview, please let interviewees fill out the "old" Opencast survey at http://www.zoomerang.com/Survey/survey.zgi?p=WEB22 8YJDZLB7W; in conjunction, send them consent form(s) for interviews (cf. attachments at end of page). Interviews (completed and planned)
institution date of interview status interviewer(s) institution type institution size geographic location
Institution #1 20-April-09 done Allison & Judy teaching university, public Medium US (California Bay Area)
Institution #2 9-June-09 done Allison & Judy liberal arts, private Small US (California Bay Area)
Institution #3 19-June-09 done Bjoern
Institution #4 24-June-09 done Olaf teaching university, public Large Netherlands Institution #5 3-June-09 done Olaf teaching university, public Medium Switzerland
Institution #6 08-July-09 done Jack teaching university, public Large Israel/Jerusalem
Institution #7 09-July-09 done Olaf & Clemens teaching university, public Large Germany
Institution #8 14-July-09 done Vicente polytechnic univ., public Large Spain
Institution #9 15-July-09 done Josep & Alícia public university Large Spain
Institution #10 16-July-09 done Olaf & Clemens teaching university, public Large Germany
Institution types: Research Universities, Teaching-oriented Universities, Liberal Arts Colleges, Community or Junior Colleges, Specialized Colleges (e.g. agricultural, technical, teaching), Online institutions, public, private Size: Small (fewer than 2,000 students), Medium (2,000 - 15,000 students), Large (more than 15,000 students)
File Modified
MatterhornInterviewInformedConsentForm.doc Jun 19, 2009 by Judy Stern
MatterhornInterviewInformedConsentForm.pdf Jun 19, 2009 by Judy Stern
MatterhornContextualInquiryInformedConsentForm.pdf Jun 19, 2009 by Judy Stern
MatterhornContextualInquiryInformedConsentForm.doc Jun 19, 2009 by Judy Stern
Opencast Matterhorn Orgsona (draft).pdf Aug 06, 2009 by Olaf A. Schulte
Drag and drop to upload or browse for files
Download All
Interview questions Interview questions
The following are questions for interviews with potential customers, those that will be making a decision about adopting Matterhorn. Many of the questions assume that the interviewee (or someone from their institution) has already responded to the first Opencast survey. In general, we should be asking very open-ended questions, but we include prompts (in parens) that you can use to help get at what we need. General introductions & background
Provide an introduction to Matterhorn (and what we're hoping to provide)
What role do (each of) you play?
What does your unit do? Who do they serve? (Whom do you focus as target groups, e.g. instructors, students, researchers, administrative staff?) Any restrictions on who you can serve? What is the full range of services you provide?
What Is your department considered? (Try to get at whether they are primarily AV, IT, or eLearning) If A/V: How do you get IT support/services (server, storage, maintenance)? Current Institutional Podcasting Program --if have an existing system/program
If you know, can you tell us more about why [your institution] went with your existing solution?
Is there a part of your solution you consider irreplaceable (a must for MH integration)? A service/functionality you cannot afford to do without?
[If they said their system is integrated with campus systems] Can you further describe how your current system is integrated with other campus systems?
Can you tell us about your existing program? (some specific questions follow, if they don't get to them):
What capture devices do you have? or How do you capture? How many courses do you podcast/webcast/screencast? How does it get decided what gets podcast/webcast/screencast and in what format (video/audio/screen/other; file format, bit-rate, frame-rate, codec, etc)? How many different ways do you monitor and communicate about what's going on with your webcasts/podcasts? What metadata do you attribute to the videos? How? Where does the information come from? What editing needs do you have (trimming, editing within the recording, individual editing, branding)? [if time] Compare their process flow to our process flow diagram if they have an existing system
Do you know about any podcasting that's currently happening outside your system (e.g. individual profs doing it with or without help of IT or AV folks)
What are the biggest problems or inefficiencies with your current system/process/program? Infrastructure issues
What web content management systems (including LMS's) are in use at your institution, and how do you see these integrated (if at all) with Matterhorn-generated media?Are they administered within your unit?
Can you describe the facilities in which you record (or will record) events/lectures you wish to podcast? (e.g any installed equipment?)
What kind of budget to your have for hardware? Staff? Auxiliary staff (students)?
What are your concerns (if any) concerning storage? What kind of limits are you up against?
What are your authentication needs and why? What's in place already? Business Requirements
What accessibility standards do you have to meet?
What distribution channels do you have to serve (local website/CMS/blog / LMS/VLE / iTunes / iTunes U / YouTube)? Is distribution centralized or scattered over different channels?
Any other requirements being dictated? --no existing system
Can you describe any podcasting that's currently happening in a non-enterprise or one-off manner at your institution? (e.g. individual profs doing it with or without help of IT or AV folks?) Users --if have an existing system/program
Who uses (or touches) your current system in any way? Who uses the system on a regular basis? Tell us more about each of them (i.e. those that aren't a generic role, e.g. instructor, student). Describe their use.
Are there any people that don't actually touch the system, but without whom you wouldn't be able to deliver podcasts? [e.g. at Berkeley, we might say camera operator, instructors]
Can you describe the role of instructors/presenters? What are they responsible for? (Want to get at issues of whether and why instructors edit, start/stop, approve publication, etc.)
[If any seem like good people to talk to later, see if it would be okay to contact them]
With regard to podcasting/lecture recording/video management, what service(s) does your institution you provide and to whom? --no existing system
What people/roles do you anticipate being involved in your future podcast program?
With regard to podcasting/lecture recording/video management, what service(s) will your institution provide and to whom? Podcasting Goals/Vision
[If applicable] We've heard about your goals of [what they wrote in survey or elsewhere] for your podcast program. Can you say more about these goals?
Can you tell us about any (other) goals you have for your podcasting program? Do you have a focus on lecture recording or are you interested in other uses for podcasting,e .g. events and guest speakers or publishing existing content)
Have you come across any "best practices" for a podcasting solution you would aim for yourself?
Can you tell us about any podcasting or webcasting solutions (other than Matterhorn) you are now considering adopting?
Are there risks that you foresee or are concerned about?
Who are the campus stakeholders that support (or could support) your podcasting program?
Ideally, how would your podcasting system be integrated with other campus systems? What (if any) difficulties do you foresee?
Who do you hear from that wants podcasting (or podcasting improvements) and what do they ask for? [e.g. students? institutional decision-makers? instructors?] Is there any kind of roadmap?
Who do you consider your audience?
Can you describe what you envision as the ideal student experience when using your podcasts? (Issues to get at include: Search, interaction, what students need to be able to see, whether live streaming is part of the vision.) Deployment
Who would be responsible for installing and deploying a new system? Can you tell us about them (what their other responsibilities are/would be? what their level of expertise is?) [want to guage confidence in their team]
[If applicable] Can you tell us a about your experience deploying the podcast system on your campus?
What resources do you have / would you have for: a) installing and administrating a solution, b) for the operational side (scheduling, editing, hardware service etc.), c) communication with stakeholders Potential Matterhorn adoption
[If they have said Matterhorn will impact their strategy] What might encourage your institution to migrate to/adopt Matterhorn?
What might encourage your institution to take advantage of specific services? (may need to list the services for them, explain what we mean by services) Any specific services you're looking for? Specifically, would you use the authentication (e.g. HTTP Basic) provided out of the box, or would you integrate with your enterprise authentication system?
What do you hope Matterhorn would buy you over your existing system? Additional information
Can you say more about [anything that's not clear in the survey results]?
Interview Tips
Work in Progress This page is a work in progress.
Matterhorn Interview Guidelines
It is always best to perform interviews as a pair, usually with one person (primarily) facilitating the interview and the other person taking notes. However, in some situations it may make sense for the note-taker to participate in the interview - it is best for a pair doing interviews to decide on their strategy for asking questions together beforehand. If an interview is performed by a single person (which we advise you to avoid if possible), it may be helpful to record the interview for later review. If you do record the session, you should add this to the informed consent form and assure the interviewee that the recording will not be shared with anyone except the project team. An interview should flow like a normal conversation, and should not feel to the interviewee that you are just reading through a list of questions. Do your best follow through and get answers to all your questions, even if you are led off on a tangent. Though it's OK to explore tangents, make sure you circle back and get the answer to your original question before moving on.
Interviews
Interviewing users one-on-one is a quick way to gather a lot of information about their needs. It's generally not necessary to interview large numbers of people to get useful data — as few as three or four interviews are often sufficient.
There are several interview rules that you can use to help get the most information from the people you're interviewing 1:
Don't ask questions that can be answered with "yes" or "no." Don't ask leading questions. Don't use jargon. Don't draw attention to specific issues that you care about. Distance yourself from the product.
The most important goal is to get as much feedback from users as possible without influencing their answers in any way. It's human nature to try to please an interviewer by giving the answers people think the interviewer would like to hear, so it's important not to indicate your feelings about the users' responses. You want to create a safe environment for users to talk about their ideas and concerns frankly. One of the best ways to do this is to distance yourself from the project you are discussing. For example, you may want to say, "the development team asked me to talk to you", instead of, "I'm here to interview you about the application I'm developing".
Some interviewees will talk for an hour about their issues and concerns without any prompting. Others will not have much to say unless they are asked prepared questions. In either case, you should be mostly listening, prompting, and doing very little talking. While you usually want to keep users focused on issues that pertain to the system you are interviewing them about, don't feel pressured to complete all of your prepared questions. Allowing for open-ended explorations of their needs and ways of working will also yield good information. Sometimes you will find that information that doesn't seem pertinent at first will later give you valuable insights into the way users do their work and thus inform your design.
As you talk to users, you want to be looking for the following types of information from them:
What tasks are they performing currently or would they like to perform? What would they like to see in a design? What are their expectations for the service? How can the current service be improved? (If possible, observe users using the current solution.) Any other specific data you need from users to inform your development effort.
From: http://inews.berkeley.edu/bcc/Spring2007/998.html 1 Adapted from Jakob Nielsen, Field Studies Done Right: Fast and Observational.
Interview Tips
These tips are relevant for any type of user sessions you run but are particularly relevant for interviews and observations where you typically meet with individuals. Our Tips
Be a good listener Remain neutral: don't react Focus on goals first, tasks second Avoid discussions of technology Don't limit yourself to a fixed set of questions Encourage story telling Distance yourself from the product Avoid making the user a designer Categorize notes = easier analysis Analyze your notes within 48 hours Ideally should be performed in teams Don't use questions that can be answered with "yes" or "no" Don't ask leading questions Don't use jargon Don't draw attention to specific issues that you care about
Move from structured to open ended Encourage the user to speak freely and give you honest answers and feedback Determine the user's needs, goals & tasks Analyze your notes within 48 hours Interview phases Often will not use all of these phases in a single project--that's fine, but it's good to understand distinctions. Early-phase interviews Exploratory focus Mid-phase interviews Begin to see patterns Late-phase interviews Fill in the details
Many of the tips above have been inspired by or adapted from the resources below (Jakob Nielsen & About Face 2.0). Jakob Nielsen's Tips, from Field Studies Done Right: Fast and Observational
Don't ask questions that can be answered with "yes" or "no." Don't ask leading questions. Don't draw attention to specific issues that you care about. Don't use jargon. Remain neutral: don't react. Distance yourself from the product. Alan Cooper and Robert Reimann's Tips, from About Face 2.0
Interview where the interaction happens Avoid a fixed set of questions Focus on goals first, task second Avoid making the user a designer Avoid discussions of technology Encourage story telling Ask for a show & tell Avoid leading questions
Publicly shareable interview summaries Large Dutch Teaching University, Small, liberal arts college, US
Large Dutch Teaching University,
Interview Large Dutch Teaching University, 23.780 students (OAS, June 24th 2009)
• 15 years professional background in A/V • A/V department, 5 people, 2 students • facilitating role for two faculties (law, arts); for law, the scenario is very much a distance learning one (part-time students) • 1,500 h of lectures being recorded in 2008; used to be available on VHS and DVD until quite recently • low automation • Pinnacle USB video recorder (+ failure rate 10%, backup solution), student-driven cameras • looking into „Presentation2go" • solution is not scalable
Decisions, players, infrastructure • Decision about lectures to be recorded taken by faculty head • A/V has good relationships with IT, but no formal cooperation; no concerns with IT-infrastructure therefore • e-learning group is looking into new didactical scenarios (cf. separate presentation), experimenting with Presentation2go • other faculties looking into lecture recording as well, but the infrastructure is decentralized
• URL for streaming are published and „hidden" (no authentication) in Blackboard • Has not yet seen „ideal" solution; Mediasite is o.k., Accordent produced some negative experience; looked at Echo360, but this was a no-go for the e-learning group for some unknown reason; Presentation2go is the favourite solution at the moment. • Ideal podcast - excellent audio - good video (framing) - automation, if quality can be kept - slide change should be cue point in video • They today have and would prefer to continue with a pre-installed system in the classroom (Windows, looking into Mac) • Problem: Guest lecturers, ad-hoc speakers • With regard to the solution to be implemented, e-learning group and A/V will share the decision; faculties will not care, do not have a vision or a goal. • The A/V perspective is for an automated workflow to decrease time spent on individual objects; also, total integration with other systems sounds nice. • Lectures must be sovereign regarding their objects (deciding upon their deletion for example) • Option: For extra quality , send a student to the room to replace automated camera with manual worked • His personal view is that learning will change dramatically with the new generation.
Small, liberal arts college, US TOP TEN
Working with IT - big concern/fear security? open source - will there be support is an issue Network compatibility is an issue - have to have the right port open and firewalls have to allow the traffic - how easy will it be to talk the network people into allowing the software onto the system?
Monetary constraints uncertainty re: resources/funding wants to use existing equipment
They outsource hosting of applications when they can iTunesU Blackboard (he thinks - may be good to follow up to get confirmation)
He'd like a system he could set up himself if possible with as little involvement needed from the IT folks as possible Unsure what the policies will be in terms of making the content open; currently it's not but he's an advocate of making the content open (uses MIT Open courseware himself) Anything will work no specific demands from faculty (except the one about the release) Just get something set up Ideally, he'd like to (almost) completely automate the lecture capture process He's still learning about what's possible in the web/podcast environment Has AV & technical skills (pattern we've seen) will be hiring somebody who's likely to be less CS-savvy but very AV-savvy Customer service focus faculty are #1 wants to make them happy wants to work well with others on campus good relationship with person handling blackboard ADDITIONAL DETAIL
Campus has about 200 faculty, less than 100 full-time faculty Classroom technology is not the highest priority here - this school's charm isn't because of the latest gadgets, they come for the intimate feeling. Wonders if podcasting would disrupt the intimate, interactive atmosphere in the small classes Uses Banner (institutional management system - SIS, HR, etc.) & Blackboard (LMS) Podcast system will have to be integrated with Banner because that will provide all the authentication. Live streaming is probably not that important Might present podcasts in their portal, but may be thinking of more PR-oriented content. Maybe blackboard for lectures. He's not sure if he'd keep a high-quality recording for later transcoding Storage may be an issue as their IT folks are 'stingy' about storage space Most likely he'll get a computer to run the lecture capture, encoding, processing app and it will be in his office Likes University of Washington's podcast program/documentation (http://www.css.washington.edu/podcasting) "Annotating videos and searching through them would surely be valuable" Instructors may want to add annotations? iTunes pain points: it's off site, uploads take a long time, they are limited in size. Have to manually go through a web interface to upload content so he wouldn't be able to completely automate processing. Really hates limitation of 500MB per file on iTunesU, as he has to break up lectures into several files It's work to gather metadata from professors -- would be nice if this could be added by the professors after media was uploaded, but currently can't do this with iTunesU Would be great if there would be automated system checks to see if equipment is on and ready to go. Automation scenario: Prof offers class; they decide to podcast; submit their request; the request is processed (a human could be involved here in reading reports that someone requested a podcast); video camera turns on and transmits the file to server; file is compressed, audio is normalized; the links to the file are put on the portal, and maybe somewhere in blackboard too. Most professors many just want their recordings available and don't think beyond that (e.g. editing). May want to create a portable package of podcasting equipment that can be moved from room to room, as may professors are attached to their rooms; he'd like to be able to give camera & interface box to professor and allow them to set it up. Would like to be able to implement on whatever equipment he currently has. Question from interviewee: What are the hardware options in terms of what I can use? Accessibility: says it's important, but don't seem to be lots of policies around it. There hasn't been a requirement to provide captioning to deaf students yet. Matterhorn sounds like it would be fewer steps to set up than the UW-esque solution he'd been looking at. he knows it will be lots of work no matter what solution they choose, but rather than having separate components do all the tasks it would be nice to have one system that contains all the components. they want to figure out how to use a DV camera that is a few years old with firewire ports and analog video out -- how can I get one of those signals into matterhorn? "Matterhorn sounds like a really viable solution as to what we'll be doing here."
Who to interview Survey Respondents that are potential interviewees
The following are those who responded to the first Matterhorn survey
Uni-Erlangen - RRZE [email protected] Kavli Institute For Theoretical Physics [email protected] University College Cork [email protected] Would keep existing system, but take advantage of Matterhorn's services:
The Australian National University [email protected] Drexel University [email protected] University of Auckland [email protected] University of Applied Sciences Osnabrück [email protected] CSUEastBay Hayward Campus [email protected] Would eventually migrate from old system:
CSUEastBay Hayward Campus [email protected] Kavli Institute For Theoretical Physics [email protected] SURFnet [email protected] Greek Research and Technology Network (GRNET) [email protected] RRZE Uni Erlangen-Nürnberg [email protected] Monash University [email protected] SWITCH [email protected] University of Sussex [email protected] ulm university [email protected] Interested in running a pilot of Matterhorn to provide QA and feedback:
Greek Research and Technology Network (GRNET) [email protected] RRZE Uni Erlangen-Nürnberg [email protected] Monash University [email protected] ulm university [email protected] Uni-Erlangen - RRZE [email protected] University College Cork [email protected] Ostfold University College [email protected] University of Washington [email protected] Butler University [email protected] MIT OpenCourseWare [email protected] University of Athens [email protected] Columbia University, CCNMTL [email protected] Universidad Carlos III de Madrid [email protected] Amherst College [email protected] Tufts University [email protected] Australian National University [email protected] University of York, UK [email protected] University of Notre Dame [email protected] Penn State University [email protected] Connecticut College [email protected] CUSTOMER SURVEYS
Here, we should gather input for a quantitative survey of customers; the "outstanding questions" document is complimentary to this.
Opencast Community Survey- conducted March 2009 Mini-survey on role of instructor --conducted August 2009
Mini-survey on role of instructor Unknown macro: {html}
DEVIANT SCENARIOSThese suggestions stem from the response to the initial call for deviant scenarios. Some of them have been marked grey as they will be part of year 1.
Short Suggested Description (quote) Team / Technical implications / comments description by assignee / sub-project
One computer Bjoern Installation of entire system should be possible on a single computer. (That is to All Chris: While the first part of this should installation Hassler say, capture, processing, and delivery.) Ideally, the capture and presentation actually be doable with Matterhorn (e.g. computer would be able to be the same also, i.e. internal screen/VGA + internal capture/processing/delivery on one PC) the webcam capture. other is unfortunately out of scope.
Network agnostic Bjoern The system must be resilient to network interruptions. The system should not All Chris: While the first part of this should Hassler require physical network connections between components, but e.g. allow manual actually be doable with Matterhorn (e.g. transfer between capture client and server. capture/processing/delivery on one PC) the other is unfortunately out of scope.
Ubuntu Bjoern The system must be easy to install, ideally available as Ubuntu package via the All Hassler Ubuntu package manager. (Ubuntu is widely used in Africa, so we should also package for Ubuntu.) The system should be pre-configured as best as possible.
Low-tech-capture Bjoern There should be a simple capture client, e.g. the capture client should be able to Capture device Hassler use a usb webcam and stills camera for slides capture. (similar to OpenEya, where total hardware costs are around USD 1000)
High-quality Vicente - Capture system modified to ingest manually and handle input from a components Capture "capture"/"ingest" Goyanes capture card, DV card or SDI card. The output of this systems should be compliant to Matterhorn-INBOX standard. - Capability to handle professional codecs like DVCPRO 50, XDCAM, etc..
Online/web/linked Brian - For example, if an instructor curates open video resources-such as YouTube Process (Technical) metadata needed; policy and media handling O'Hagan, videos, course podcasts from peer faculty or universities, or even specially copyright issues. 404 problems (e.g. Adam produced audio/video that is hosted at the local institution-for use as [https://www.miroguide.com/items/2083351) Hochman course-related materials, it would be helpful if these external assets could also be managed manually (and re- published? Though this might get tricky...) via Matternhorn. - An instructor is wants to stay within the confines of their comfort zone, and is uninterested and intimidated with sharing video on Youtube. Basically his technology repertoire is logging onto his online course site to share syllabi and email. Recently he took part in a panel and was sent a link to the video in an email from the conferences host. He would like his class and future classes to have access to the video. He emails the link to his matterhorn account and the video appears in his online course.
E-mail ingest Adam An instructor is on site on a dig in china and wants to submit her video to an Process Hochman archive and/or share it with her class. Because she is constantly on her feet, does not carry a laptop or a video camera, and Ethernet connectivity is non-existent, she invested in a good cellphone video camera. She has decent mobile broadband connectivity, so she emails the video to her matterhorn account for processing and distribution.
GPS'ed capture Adam The same instructor is on site on a dig in china and wants to take her class on a Capture Hochman, tour through the temple of a formal ruler. Since the cellphone has GPS, she is Ruediger able to track the coordinates of the tour as she takes the video. After she Rolf completes the tour, she emails the video to her matterhorn account. A few hours later her students receive a map with a line indicating the tour. They are able to click on anypoint on the tour to view location specific video.
Software capture Bjoern I was wondering whether there is scope for software-based capture, i.e. ? Hassler camtasia-like screen capture / built-in webcam capture. (That is to say, I can turn my own laptop into a capture agent, to be used in a lecture theatre that may not be equipped with a capture installation.) FlipCam John Several JISC (UK funder) programmes are encouraging their projects to use a Flip ? Norman camera to record video pieces and include them in a project blog to increase impact of the project. I think this can be seen as an illustration of both a teaching case (encouraging students to maintain learning (b)logs) and research case (increasing the communication and impact of research) So a Flip-like scenario of plug the camera in to a laptop and get a useable url back to drop into a blog or web page would be great. I don't know if this means special software in the case of Flip.
Video only Sally We also have a requirement (that our current system does not really Hanford answer) for recordings without the slides integrated (ie where the focus is actually on the video).
(Variable in Vicente If the media is only in HQ version inside the system you will waste a lot of BW to Process quality) video Goyanes do your job or you will need to transcode it on the fly every time, so you will waste preview in MH a lot of CPU. virtual Vicente But the concept goes beyond editing or linking videos, the system will perform the ? cutting/editing Goyanes cutting and linking tasks only if you decide to export or download de Virtual Media tool file, other way it only store your decisions. In a Asset Management System with Virtual Media support you can create new media files that are build of pieces of other media files in the system but the virtual media object has not his own media (only an EDL file defining the pieces of other media and the order to create it).
Live streaming Tim For example, we stream our graduation ceremony live so family and friends ? O'Donovan, overseas etc can watch it. At the moment, we just put a link on our Bjoern homepage to the streaming server feed, and people tune in, but we would Hassler envisage putting that link on any 'podcasting' product we go with. Presumably with matterhorn, the live streaming would use other technologies, but from a users point of view, just having one URL to remember for all types of 'media' would be convenient. Then having mattherhorn 'record' the live stream, do it's magic, and package the content would be pretty neat.
LMS/VLE Tim Out-of-the-box interfacing with learning management systems (Blackboard, Distribution integration O'Donovan Moodle, Sakai etc) would be a real win.
Movie ticket Josh The instructor would produce a movie ticket for each user, and send each user ? Holtzman their ticket. That ticket would be good for X number of downloads, or would be good for X days only, etc. Without a ticket, you don't get to see the movie. It has nothing to do with CAS tickets.
Collection Brian ... we work with faculty quite often in creating private media collections that are O'Hagan hosted and distributed locally within course websites. However, more often than not, video from external sources are being used (YouTube and the like.). These collections are usually assembled by a member of our production unit, and we've been on the lookout for a DAM system that might help alleviate the resources in manually assembling these kinds of course media collections. Thus, if Matterhorn had a feature that already dealt with collecting, etc., it might come in handy.
Customized Judy Stern Basic idea is like subtitles. One or two lines of text that appears at the bottom of textual annoation the frame, that starts and stops at specific times. Blocks of text should be able to cut or dissolve into each other - fade up, crossfade, fade out. Timing of the sentences in relation to the image is very important. Perhaps also a crawl mode, like news tickers. Font, size, and text and badkground color (including degree of transparency) should be able to be specified. Annotations should be visible when clip is paused, or scrolled forwards or backwards.I would like to add the annotations myself prior to students seeing them.
Non-textual Stjepan http://urbanstew.org/rehearsalassistant/ (http://urbanstew.org/rehearsalassistant/\-) Engage annotation Rajko / http://faculty.washington.edu/reedstev/vt.html Judy Stern
SRU/SRW Tim See: http://www.loc.gov/standards/sru/ and http://www.ariadne.ac.uk/issue40/morg ? O'Donovan an/It essentially is a method to expose the metadata to external searches. (e.g. Students could search matterhorn content using the universities home page search feature)
Sword Tim http://www.swordapp.org/ Came across this in another project. It's being used as ? O'Donovan an interface to allow for remotely depositing content into institutional repositories. (Dspace, Fedora, Eprints etc)
Chris Brooks I don't have firsthand experience with manual ingestion. I look at things through an Capture automated capturing lens. A discussion with Jack this morning made me think that institutions that do have a manual recording stage (Vigo as well?) might have interesting opportunities to generate metadata (e.g. which video source should be dominant) because they have a person in the room engaged in the lecture. In the design of the capture agents thus far, I haven't considered this. There may be a hybrid between manual ingestion and automatic ingestion (e.g. the video is automatically ingested by the capture agent, but there is "teaching time" metadata that could be captured and ingested to enhance processing). I'm not sure how this would affect version 1.0 of MH, but I could see it affecting version 2.0.
MATTERHORN ORGSONAS
Matterhorn Orgsonas
The Cobbler - coping, but not happy (Primary Orgsona) The Sophisticate - fully invested in a podcasting system (Secondary Orgsona)
Matterhorn Orgsonas are intended to:
1. Provide a concise illustration/model of the patterns we saw in our customer research. 2. Serve as a tool to help Matterhorn designers & developers think through trade-offs and make decisions about requirements and functionality from the perspective of our potential customers. 3. Give the outside world and ourselves an idea as to whom we are building Matterhorn for - and what can and can not be expected.
Roughly speaking, the primary orgsona is our archetype for year one - we will certainly surprise him with some additional features, but we won't let him down on the basic expectations. The secondary orgsona leads our way into the second year we are hoping for - while some fundamental decisions to meet his expectations have to be made in year one. Photo Orgsonas are an adaptation of the concept of personas--a tool often used in used in user-centered by design. An orgsona is basically a model or an archetype representing an organization and its staff "Dru!" (at least those dealing with lecture recording, audiovisual content, podcasting and the like) that is a target customer of a product or service.
Matterhorn orgsonas stem from the following sources:
10 interviews from June and July 2009 with potential adopters of Matterhorn from 6 different countries Opencast Community survey Capture survey from Northwestern University Additional information from the comparison of administrative tools
A fun game to teach others about Matterhorn Orgsonas:
Orgsona Jeopardy
The Cobbler - coping, but not happy (Primary Orgsona)
Background Goals Pain Points
Podcasting evolved as a To offer more recorded lectures to The processes we are using now grass-roots effort our students won't scale as the program grows. Small team To gain in efficiency and Things happen in an adhoc Small, but growing program organization fashion. To keep costs low
"It would be nice to have one system that We started podcasting a few years ago. There wasn't any plan in place, rather it evolved contains all the components" from various grassroots efforts around our university. Our "system" was cobbled together so that today we combine a mish-mash of manual labor with free and proprietary audio/video tools. Demand has grown to the point that we cannot keep up with it. Due to the university's budget we cannot afford to staff up accordingly, and to save money the campus wants to consolidate podcasting efforts across campus. In response to this mandate, we really have to use our existing resources more efficiently.
As you might guess, our podcast team is small - really just two people and a couple of students here and there to produce, manage and distribute lecture and special event recordings. Our podcast administrator, Mary, has an A/V background. She is savvy enough to manage the day-to-day business - but she's surely not an IT expert (and definitely not a programmer!). Mary enters information about lectures and events into the system, and makes sure that all podcasts are properly trimmed and distributed. Then, there is our A/V technician, Joel, who handles the equipment in the classroom and most of the day-to day issues that come up with various devices. He's a bit more IT-savvy; he can install and upgrade software, and even do some limited systems administration work if needed. There are some developers and more technical sys admins in the IT department who we can call on when needed. Generally we can count on a sys admin to set up new software systems. Since they're a precious (overcommitted) resource, we usually try to handle things ourselves once they get us started.
Basically, we support two scenarios:
1. For the few equipped rooms, the instructors or one of our students start and stop a recording device. 2. For rooms without equipment, we must set up equipment based on the complexity and/or the importance of an event - which regularly means providing manned cameras in addition to the usual combination of audio and VGA. It would be great if that equipment could be used to feed into Matterhorn somehow.
Our primary directive is to offer more recorded lectures to our students; if we do that, within the boundaries described initially, everybody (instructors, campus leaders, and students, of course) will be happy, at least for a while. So far, we've distributed our recordings by uploading media files to our campus CMS and LMS. The latter gives us a somewhat of an authenticated and authorized distribution channel, which is crucial to many of our instructors.
We wish everything was automated. Long-term, we would like to fully integrate with our various campus systems, the LMS, our course management system, student information systems, room booking/reservation, LDAP - everything, basically. But for now, considering our patchwork quilt of a system, we would be happy a single coherent system to provide more efficiency. Anything that will help us scale as our podcast program continues to grow.
View Secondary Orgsona
The Sophisticate - fully invested in a podcasting system (Secondary Orgsona)
Background Goals Pain Points
Large teaching university Live up to rising customer and No integration with campus Medium-sized team with more stakeholder expectations systems (SIS, R25, room resources Customize system to provide reservation) Part of the IT department added functionalities No flexibility to adapt the system installed
"We provide a full service from centralized We are a large teaching university and have put years into building a pretty sophisticated IT - but would like to customize more." podcasting program. We share some of our lecture recordings publicly on iTunes U, some are limited so that only students in that particular course can view them in our LMS - in general, the instructors decide how widely they'd like their individual lectures distributed. Photo by "Dru!" These customers and stakeholders now have expectations about how things work, so we can't let them down - and it's hard to change practices everyone has gotten used to.
Plus, those of us that "live" the podcasting program have developed expectations as to the features of the system - and we all want more! This includes the ability to completely automate the scheduling and lecture capture process so we don't even need camera operators (i.e. some form of tracking) - but to also make it ready for some professional broa dcast equipment we have, even HD cameras to capture high quality.
Instructors shouldn't have to do anything at all - but if they want to, they should be able to not only start and stop, but also to pause their recording where needed - or easily review and edit the video afterwards. Metadata should be pushed into the system from other campus IT systems. We would also really value the ability to live-stream events while recording, delay and limit the publication of video and - on the user's end - allow for collab orative editing and complex annotation technologies. We'd also like to expand into other distribution channels such as mobile devices.
Who exactly are we? We are part of the IT department, four or so people. We provide a ce ntralized and comprehensive service and can rely on our IT infrastructure in doing so; A/V expertise is integrated into our team and we expect a certain flexibility in this domain - we all know that podcasting has to adapt to IT needs sometimes. Speaking of which, we would certainly love a more sophisticated authentication and authorization system whi ch would require each user to log on to view any non-public video. As the central campus IT department, we cannot afford to be easy-going about security - even it's video.
We know that automation is the key to increasing the amount of podcasting we can do, but at the same time this also increases the need to customize our system, especially to local needs and IT infrastructure. The more we could customize the workflow within a given system, the better it would suit us. We've got some developers on staff, they could even work on some add-on functionalities to the system in their respective domain. It would be great to be able to continue to enhance and develop our podcast system ourselves, but to do it at our own pace and have the flexibility to customize it to our needs. So what we really need is a system that allows us to keep what's working (both in terms of features and business rules) and improve what's not.
Back to Primary Orgsona
OUTSTANDING QUESTIONS
The following are questions that we should resolve as we proceed, possibly in continuation of the survey Judy initiated on August 14th; greyed out questions were covered in this survey.
Please add to this list! Service
Will you equip lecture halls for recordings? How many lecture halls do you expect to equip? How will you equip them (e.g. permanent equipment or a cart that moves from room to room)?
Who would collect metadata for each recording? How would it be collected?
How would you prefer to start the capture for each recording (e.g. manual - a tech or instructor pressing play, or automated - a scheduler starts the capture device)? Instructors' usage
Do your instructors need/want to edit their own lectures?
Will your instructors be willing to adapt their teaching style based on the technology available? (e.g. switch to using a document camera rather than a blackboard?). Will they need to edit the content by themselves, in any possible way?
Would you like instructors to have a start/pause/stop button for the recording? Infrastructure issues
Will you be providing Matterhorn as a centralized service or do you expect to see multiple, distributed implementations (e.g. either a) run several MH instances or b) at least need different distribution channels) of Matterhorn?
Would you want separate working, archive, and/or distribution repositories on your campus, or will these be centralized? Would you want separate application servers for encoding, indexing, and other media processing tasks, or will these be centralized? Would you want separate administrative tools, or a single interface that is aware of the campus structure and applies authorizations accordingly? Would you prefer to deploy into existing servers or would you be more likely to setup new servers specifically for this?
Is storage an issue for your institution?
Do you have a fixed storage limit at your institution, imposed by either technology limitations or budgets or both? Do you intend to use a large SAN, NAS, or distributed file system with Matterhorn? Do you intend to store media locally or in the cloud (e.g. Amazon S3)? Do you intend to deploy the application locally or in the cloud (e.g. Amazon EC2, Slicehost, etc)?
What are your archiving needs? (Do you need media archived in a format in a high-quality/lossless/near-lossless format, or do you anticipate that lectures will be re-recorded in a few years' time?)
Is network bandwidth an issue for your institution? [re: compressed or uncompressed capture]
Will you be recording just slides & audio or would you like to add video for instructor and/or blackboard? Capture format requirements
Any specific capture specs (codecs, bitrates, framerates) you *require* for capture? Why?
Would you specify/dictate recording settings for instructors (resolution, framerate) or would you expect the capture to auto-detect any setting?
Do you need to capture material on instructor's black/white boards? Reporting/Statistics
What types of reports would/do you need around web/podcasting?
Captioning What resources do you have for providing captioning? Will you have staff for doing transcription and/or syncing? [I would bet there are almost no European institutions doing captioning at the moment; OAS] Accessibility
What accessibility standards do you have to meet? [Here, the interviews resulted in very different answers from US and Europe; OAS] Management of recordings
Do you ever have a need to postpone distribution of a recording? How do you accomplish this? User Research Contextual Inquiries User Testing CONTEXTUAL INQUIRIES
In order to better understand the needs of potential adopters of Matterhorn, the BA/UX team will conduct contextual inquiries (interviews and observations).
See Fluid Design Handbook -> Contextual Inquiry
Matterhorn Contextual Inquiry Guide (aka Focus structure document) DRAFT
Getting Started
Introduce the team and give an overview of why you're there.
Have the participant sign the consent form.
Have fun! Demographic & background info
How long have you been at [Institution]? What kinds of positions have you held? Can you tell us about your current position?
What kinds of activities do you typically use a computer for? (Skip this if short on time)
Any favorite applications or websites? Why? Any you don't like? Why? (Skip this if short on time) User's job
Can you tell us more about what you do in each of your roles at [institution name]?
Do you consider your role on campus to be more A/V person, IT, or something else? Why?
Tell us about your typical day at work.
What do you like most about your job? (ask only if time)
What do you like least about your job? (ask only if time)
With whom would you expect to collaborate? Who has a say in your work?
Is there anything about your job, specifically around webcasting & podcasting, that you'd rather not be doing?
Deployment [to be asked if the person being interviewed is the one who'd be responsible for deployment]
[If they have an existing system] What work have you needed to do to deploy your current podcast/webcast system? (Any coding or xml?) Anything that was particularly easy or hard?
Do you have any experiences deploying/installing any open source software? If so, tell us about it. What work did it require? Skills? Pain points, if any? Additional information
Can you say more about [anything that's not clear in survey results -- that seems appropriate to ask of the individual user]?
Observation [mostly only relevant if they have some podcasting or webcasting going on]:
To tell the interviewee: We want you to demonstrate how you do things currently. Although we don't want to interrupt your flow of work, if you're willing, we're especially interested in hearing what you like most/least about how things work for you.
[The following are some of the areas of interest in which we are interested, but they should not guide the activity.]
How do recordings get scheduled (if they do)? Do you contact instructors or instructors contact you or...? Any business/legal rules around this?
What metadata is associated with each recording? How is the metadata created or added?
How does recording/capture start? Automatically or not? If manual, by whom?
Is recording/capture equipment installed in rooms or brought in as needed (or both)? Any problems/issues? Is captured media automatically submitted or manually submitted (or both)? If manual, by whom? And under what circumstances?
Where/when do formats (for capture, for distribution, for any intermediate phases) get determined?
Who needs to know about system status/failure and how do they find out about it?
What interaction do you (or others) have with the system after capture starts? (Wondering if they review media, edit media, interact in any way either on a regular basis or even an "emergency" basis, e.g. to halt distribution]
Where does media get distributed to for final consumption? Can you show us? Do you ever remove and/or republish media, and if so, how?
[If no current system] Can you show us any applications for podcasting/webcasting that are currently in use in an adhoc way?
Post-observation questions
[These will be largely determined by what happened in observation that we didn't want to bug them about, but here are some others to ask if haven't already been answered]
When you have trouble with your current system, who or what do you go to?
Any places where you feel like there's duplication of effort? Unnecessary steps?
Wrap-up
Thank them for their time.
Ask if they can suggest any other users to talk to.
Ask if it would be OK to contact them with follow-up questions and/or design review as we move through the project. USER TESTING
From the Fluid Design Handbook page on User Testing:
What is Essential to a User Test? Many people think of user tests as requiring sophisticated usability labs with one-way mirrors and recording equipment, with highly detailed tests that take an hour or more to complete, and require even more time to transcribe and understand the results. While there are definitely times where this level of testing is useful, this approach often doesn't justify the return on investment for smaller projects. In fact, you can obtain extremely helpful results, and realize great improvements in your product or service, from usability tests done at a user's desk or in the conference room down the hall.
In "A Practical Guide to Usability Testing" (1990), J. Dumas and J. Redish explain, "While there can be wide variations in where and how you conduct a usability test,every usability test shares these five characteristics:
The primary goal is to improve the usability of a product. For each test, you also have more specific goals and concerns that you articulate when planning the test. The participants represent real users. The participants do real tasks. You observe and record what participants do and say. You analyze the data, diagnose the real problems, and recommend changes to fix those problems."
User Testing Results
0.5 Admin App User Testing - Paper Prototype Testing User testing results(Engage)
Coordination of User Testing Institutions that can help with user testing
Institutions that can help with user testing
Pre-0.5 release user testing:
Please add your information in the table below if you can help with user testing in late November or Early December '09
Institution/Contact(s) # users in admin # users in learner how much time we can Details/comments roles roles provide we can provide we can provide to conduct & write up user testing
UC Berkeley / Judy Stern & Allison 2 to 4 unknown, but at least a 2 days Bloodworth few
University of Osnabrueck / Clemens 2 4 3 days Gruber Saskatchewan 2 2 days users: [email protected] and [email protected]
The University of Nottingham / Sally 2 2 2 days Hanford
UOC / Alícia Valls & Justin Ratcliffe 0 3-6 2 days [email protected]
Tel Aviv University / Jack Barokas 1 2 2 days
Update (12/8): looks like user testing of administrative applications likely can't happen until mid-late December, as UI's are not yet functioning. Workflows
This diagram was a first pass at trying to understand a potential flow of activity for Matterhorn (partly a reflection of what we understand the flows at a variety of institutions to be). Boldness of lines indicates a likely higher priority for development. This diagram does NOT yet reflect a key decision made by the processing/services team: annotations made by viewers will be stored outside of the main media pipeline, not fed back in for re-indexing (as the blue arrow near the bottom would indicate). There are certainly other "errors" as well. Internal server error SCHEDULING AND METADATA ENTRY SCENARIOS AND WORKFLOWS Scenario ETH Zurich (REPLAY) Scenario Osnabrueck U of Saskatchewan Scenario
Scenario ETH Zurich (REPLAY)
Preliminary note
We provide a full service in that the lecturer is not invovlved at all in the preparation or the actual realisation of the recording. We usually record audio, VGA and an automatically tracking camera; the settings for recording, processing, and distribution are set at the beginning of the semester and cannot be changed. The scheduling is done at the start of the semester for courses being recorded or in advance (or ad hoc) for individual recordings (no series). The screenshot come from a new scheduler introduced for the autumn semester, so the UI is different from the admin walk-through Allison and Judy did with Christoph.
Scheduling a lecture series to be recorded weekly
The scheduling information and the metadata comes from the local syllabus/course information system ("VVZ") - by entering the name of the lecturer, all courses associated with that name show. The administrator chooses the course to be scheduled and sees all the events of a series (here, there are two parts to that series). Pressing the green "Series" button under the "Metadata" button, I see the REPLAY Core metadata automatically imported from the local syllabus; I could manually edit these for the whole series (and make them the default for all items in that series), but in most of the cases they are fine.
I could go back to the scheduling overview (second screenshot) to manually change metadata or scheduling information (recording time and details) for each item individually; this happens if session are omitted, shortened or changed in other ways.
Scheduling individual recordings
If the recording is not part of a lecture series (could be part of a different series though, cf. with the button to "Select a series"), we would have to manually allocate metadata in the scheduler for individual recordings (pressing "DublinCore bearbeiten") - this would be the same scheme as for lecture series (above). For ad hoc recordings, it would be sufficient to add the metadata you see (title, location, from, to).
Scenario Osnabrueck
Preliminary note: In the most cases we are recording video and slides of a lecturer. This is the first scenario:
First Scenario
The lecturer has to install a small program called "Listener" on his or here computer.
On the initial screen you have to specify at least a minimal set of metadata for the lesson. The program uses this parameters as default for the next session so the lecturer has only to replace values have changed:
The specification of the series is done in a configuration / ini-file not on this screen mostly done by an administrator who sends the Listener to the lecturer. So if you have as teacher more than one series to be recorded he or she has to install the Listener multiple times. There is no connection to a LMS or import from a SIS at the moment!
The Listener automatically gathers meta informations and sends them to the recording device:
start of the recording - in-time by starting the PowerPoint presentation mode stop of the recording - in-time by stopping the PowerPoint presentation mode
The lecturer has to enter the metadata on the first session. The Listener "remembers" the last entry, so the lecturer has only to replace values that have changed.
If the lecturer go out of presentation mode (e.g. to show a website) the website is not recorded if he or she uses the "slide mode". For this scenario we have a VGA grabbing mode, but this needs about 1Mbit more bandwith.
After the recording the Listener sends the PowerPoint slides together with logging information to the pipeline containing
the slides for the second stream, next the video log of the time slides are changed / animations are changed - metadata for chaper, sections, fulltext search, ...
At the end of the PowerPoint presentation mode the lecturer gets a dialog to confirm the end of recording, then all they have to do to stay on internet, sometimes it's a problem if the next lecturer needs the room – and he or she pulls out the network connection or shuts down the computer. But all data, all logs are stored on the computer too, so you can uplaod this data by hand in emergencies.
After or before the recording you can input more metadata via a backend. Also here is no import from LMS / SIS at the moment.
The default publication channel is a Flash video. For the publication an admin has to change a flag.
Second Scenario
If we record only video we are using the Replay scheduler (older version with no series, instead of the later implemented series we are using the DC field "relation").
Ideal Scenario
As described above, a lot of "controlling" is currently done by a piece of Software called "Listener" at the lecturer's laptop. And it is hard linked to PowerPoint. When the Listener isn't working or there is no PowerPoint it's problematic. These are the Achilles' heel at the moment.
More flexible way would be this:
A instructor can mark a course in the local LMS as "recording" by a easy checkbox – and perhaps some additional information like distribution channels. In an ideal world this would happen before the semester starts and the lecturer would get a special room with video / audio equipment.
In our LMS we have information about the rooms and a instructor can produce a wishlist of rooms "40 seats / video equipment / special campus location."
All meta information about the course and sessions are provided in the LMS, the lecturer - or an admin - can here change description, course title, if needed session titles and so on. This is the only place where metadata about the recordings are edited by hand.
From now on all works automatically: The lecture is recorded by the video devices in the room, all time information is in the LMS, if the lecturer reschedules a session he or she makes the changes only in the LMS. After the session the video, the audio and the VGA stream of the lecturer's laptop is transfered to a central encoding server and distributed to the channels. One channel would be a version of the recording in the local LMS only the students in the course can see.
Synopsis: All admin stuff happens in the local CMS!
U of Saskatchewan Scenario
We only have 2 scenarios for recollect right now:
Scenario 1: Capture NOW. The presenter of some special event would like it captured. We need to associate the capture with a person (e.g. faculty member) to get metadata from later. Scenario 2: Capture re-occuring. The only meadata we need is course title (freeform text), faculty name, and course CRN (from registration guide). We had other metatadata fields then got rid of them when they were not used. We use these series (identified by the class name) to create an "episode guide" which is just an iframe of thumbnails (one per lecture) and links to video. BA-UX Engage
Business Analysis/User Experience aspects of this component User Experience Studies Past relevant work Mockups User Experience Studies
ENGAGE USER EXPERIENCE STUDIES Release 0.5
Iteration 4
VirtPresenter Evaluation
Study Design Combined Results Oct05.2009 UOC
Comparative Analysis of Simple Media Players
Study Design Combined Results Oct05.2009 UOC
Iteration 5
Engage Tools
Study Design Results Nov03.2009 UOC
Comparative Analysis of Dual Media Players
Study Design Results Nov03.2009 UOC
Release 1.0
Iteration 6
Engage Tools
Study Design Results Date Institution Results Date Institution
ACCESSIBILITY REVIEW OF ENGAGE TOOLS BY BERKELEY WEBACCESS GROUP
Date of Review: 30 November 2009
URL of software tested: http://qa.opencastproject.org/engage/player/player-hybrid-download.html
Environment: Windows Vista Business sp2 (whatever the most current one is), IE 8, JAWS (used both JAWS 9 and a beta of JAWS 11 Beta)
Style of review: Led by campus accessibility expert, leader of the WebAccess group, who is a non-sighted user. Established first that the primary task was to play the video. Reviewed the UI using JAWS, but kept in mind a broad array of accessibility issues.
Top Ten Findings
1. It was great that she could quickly jump to all the buttons. Play and Pause work beautifully. All buttons work great on JAWS 9 (& I believe JAWS 11). 2. List of keyboard shortcuts (or some way to view this list, e.g. a link) should be visible on screen, since it's not only screen reader users that need keyboard shortcuts. (see MH-1770) 3. For screen reader users there should be an anchor to get to the area of the page where the keyboard shortcuts are listed. (see MH-1771) 4. When user tabs to edit the current time, video playback should stop so they aren't trying to edit a moving target. (see MH-1773) 5. Didn't like that she wasn't getting any (audio) feedback when clicking the CC button as to whether it goes on or off. Said "it would be nice if that toggle closed caption button would identify whether it is on or off." (see MH-1774) 6. Felt that when one mutes, the captions should be turned on automatically as that is a standard these days. (see MH-1775) 7. Gets a strange description, "player player hybrid download link" when she's on top of the slider. The slider doesn't appear to work in JAWS, as she had to turn the virtual cursor off to make it work. Should hide the screen reader from JAWS users if they can't use it - could use the flash "don't speak" and then keep it in the tab index. (see MH-1778) Note: The virtual cursor is what JAWS uses to read in the source code and create a picture of the page in its memory. It's navigating in the buffer, not what's really there. ARIA politeness & rudeness rules tell the page to refresh. If you turn off the virtual cursor you don't get the ARIA refresh, for one thing. 8. When she downloads webpages, the percentage downloaded is voiced by JAWS at regular intervals (that is the out of the box configuration, but some people turn it off). She said this would be good info to have on the video as it downloads. (Note: she did not offer this information herself. Instead she said "yes" when asked quickly about it, and then was distracted by something else happening. It wasn't clear that she understood the likely audio interference issues.) (see MH-1115) 9. Screen reader reads the captions out loud; this is useful for those that are deaf and blind (because they it can be translated to their braille 9. display). (This stopped working part way through; we realized it had to do with the ARIA politeness level - aria-channel, aria-live="polite" - if the system is busy doing something else I won't speak....may need to switch it to "assertive.") (see MH-1784) 10. There was confusion (from sighted users) as to why captions appeared both within the video and below it (is this a bug?). (see MH-1785)
Other Findings
Dislikes: Felt that the control to turn the captions on should be available prior to the controls for playing the video (again, I think this would be most useful to the deaf & blind user). Could this be changed by changing the tab index? (see MH-1791) Thought there were too many access keys to remember - she'd just remember the ones she used. She doesn't like the fact that they are three keystrokes each, but she realizes you have to do that to avoid conflicts. She did not hear/remember the CTRL-ALT 0-9 access keys. These had to be pointed out to her at the end of the testing session. She appreciated them once pointed out to her. (Wonder if listing them separately, even though it would make the list longer, would make a user take notice that these are there. Not sure it it's worth it, though.) As the user jumps around from 0-9 in the slider, each jump is not an even percentage each time which is confusing. E.g. CTRL-ALT-5 doesn't go to 50% through the movie. (see MH-1787) Got a message about an action "on mouse over" but couldn't activate it - turned out this was a visual change only. This was a little confusing. She would prefer that changes only happen "on mouse out" as that isn't read to the screen reader, but not sure this is possible. (see MH-1794) Likes: Liked that she can quickly jump to the buttons because they indicate that they are buttons. It's nice that when she uses the access keys it performs the function but doesn't move the focus from where she is. Additional Notes: She explained that usually audio description is made to fit into the space between talking in movies, etc. This may be harder to do in an instructional setting where there is lots of talking (and sometimes drawing/writing at the same time) and few pauses. However, in stereo mode you could put audio description in one ear and audio track in the other ear. JAWS 11 Beta is available...she thinks 11 will be more widely adopted than previous versions because of blind widgets (people create their own modules which they can access via a single access key, e.g. wikipedia) & ARIA support. She thought it was OK to say "works best with jaws x," but not "jaws x required." ITERATION 4 UX STUDIES
Media Player Comparative Study
User testing results
File Modified
virtpresenter 1.1.mp4 Nov 03, 2009 by Alicia Valls
virtpresenter 2.1 .mp4 Nov 03, 2009 by Alicia Valls
virtpresenter 3.1.mp4 Nov 03, 2009 by Alicia Valls
Virtpresenter 5.1.mp4 Nov 03, 2009 by Alicia Valls
Youtube 1.1.mp4 Nov 03, 2009 by Alicia Valls
youtube 2.1.mp4 Nov 03, 2009 by Alicia Valls
youtube 3.1.mp4 Nov 03, 2009 by Alicia Valls
Youtube 4.1.mp4 Nov 03, 2009 by Alicia Valls
Youtube 5.1.mp4 Nov 03, 2009 by Alicia Valls
Google video 1.1.mp4 Nov 03, 2009 by Alicia Valls
google video 2.1.mp4 Nov 03, 2009 by Alicia Valls
google videos 3.1.mp4 Nov 03, 2009 by Alicia Valls
TED 1.1.mp4 Nov 03, 2009 by Alicia Valls
TED 2.1.mp4 Nov 03, 2009 by Alicia Valls TED 3.1.mp4 Nov 03, 2009 by Alicia Valls
TED 5.1.mp4 Nov 03, 2009 by Alicia Valls
User.Test_Oct.2009.ppt Nov 03, 2009 by Alicia Valls
User.Test_Oct.2009.pdf Nov 03, 2009 by Alicia Valls
Drag and drop to upload or browse for files
Download All virtPresenter Evaluation
See User testing resultsfor results of this evaluation.
File Modified
virtPresenterStudy.pdf Nov 05, 2009 by Alicia Valls Overview and Approach of virtPresenter Analysis
virtPresenter_pptPacket.pdf Nov 05, 2009 by Alicia Valls This is the document given to the participant before the study.
Drag and drop to upload or browse for files
Download All ITERATION 5 UX STUDIES
Comparative Analysis of Dual Media Players (I5)
Comparative Analysis of Dual Media Players
The following document is a user experience test designed to examine competing players with dual screen media players.
Results
The results of this study can be found on this page: https://wiki.opencastproject.org/confluence/display/open/Comparative+Analysis+of+Dual+Me dia+Players+Results+UOC+%28I5%29
File Modified
comparativeAnalysis_I5.pdf Nov 30, 2009 by Alicia Valls Drag and drop to upload or browse for files
Comparative Analysis of Dual Media Players Results UOC (I5)
Study Design
The design and execution of this study can be found on this page: https://wiki.opencastproject.org/confluence/display/open/Comparative+Analysi s+of+Dual+Media+Players+%28I5%29
Summary
Users were able to easily navigate the timelines that had slide previews (Omnisio, Mediasite, Echo360). Every user, at some point in the study, tried to click a video section to increase the size in at least one player. Video adjustment (i.e., size and orientation) were a problem with every player in this study. To find content of a lecture (e.g., topic or slide title), participants used search and browsing slide titles. All users had difficulty with searching content in ePresence due to lack of search result feedback. It's interesting to note that in Omnisio, users scrolled through slide previews and in MediaSite, they dragged the scrubber which changed the previews. Omnisio treats the slide previews as a closer mapping to a timeline whereas Mediasite presents them in a way similar to scrolling photo viewers. Unfortunately, preference of one method over the other was not investigated.
Pre Study Data
User Age Gender Major
1 47 F Law
2 32 F Business
3 32 M Business
4 32 M Telecommunications
5 28 F Law
Interaction Notes Key
User: Participant number Observations: Participants' actions were observed and recorded by at least one facilitator Completed: Was the task completed or not (Yes or No) Difficulty Rating: Participants were asked to rate how easy or difficult it was to complete the task (1: Difficult 10: Easy) Comments: Participants were asked open ended questions and their responses, along with any other comments, were recorded Echo360
Task 1 (Find where the professor used the highlighter)
User Observations Completed Difficulty Comments Rating
1 User scrolls through preview images and finds it quickly. Y 10 This is a great application - fantastic for distance learning.
2 User had no problem. Y 10 This is better than ePresence but not sure if it's better than MediaSite.
3 User looks for the scrubber then notices the horizontal list of Y 5 This is very slow. preview images and finds the goal section.
4 User scrolls and finds it immediately. Y 10 This was easy.
5 User clicked the second preview image immediately then began Y 10 None clicking others when it was taking a while to load. They found the goal image and clicked it.
Average Users had little difficulty scrolling through the preview Y:4 N:0 9 Even though participants had little difficulty, only one images and selecting the section of the lecture they were commented that they liked the application; it should also be looking for. noted that this participant used Echo360 before the other applications.
Task 2 (Make the video of the presenter as large as you can)
User Observations Completed Difficulty Comments Rating 1 User looks at small video. 'I don't know.' User finds buttons but they Y 5 I would double click on the video to make it larger. are changing the image preview layout. User keeps clicking and makes the video larger.
2 User clicks video section then clicks the buttons until goal state is Y 10 It's not difficult but I can still see the toolbar. I prefer the Omnisio full reached. screen because it was a true full screen.
3 User goes directly to lower left and swaps sections and full screen. Y 8 None No problem.
4 User clicks video of presenter then clicks FS button and Swap. Y 7 I gave it a seven because there's a few buttons that I didn't know. It would be better if they were right under the video.
5 User double clicks the small video then looks in corners of N 1 This was very complicated. interface. They find the buttons at the bottom and click each one of them until she gave up.
Average 4 out of 5 users clicked the video that they wanted to be Y:4 N:1 6.2 Users had difficulty making the video full screen because they larger. After realizing this wasn't working, they began clicked the video expecting it to get larger. Once finding the scanning the page looking for a full screen button. screen adjustment buttons, they still had difficulty reaching their goal state. ePresence
Task 1 (Find the slide that was red and had a large 'f' on it and begin watching the rest of the presentation from there.)
User Observations Completed Difficulty Comments Rating
1 User clicks each section to view slides then clicks > Y 3 It's not difficult but it's not intuitive. button for slide navigation then hovers over lower section of scrubber until finding the correct slide.
2 User hovers through slide previews but cannot find the N 1 Facilitator showed the user but they comment that they don't like it and it's slide. User then clicks slide navigation buttons then slow. clicks through the sections on the scrubber.
3 User hovers over top of scrubber and clicks through N 1 This was quite difficult; I couldn't find it. I know one line is for the video and the sections. Facilitator shows them after comments have other is for slides but I don't know which is which. been collected.
4 User clicks slide navigation until goal slide was found. Y 3 I gave it a three because there was no slider with slide previews. It's difficult to go through each one.
5 User clicks < > >> buttons until the goal slide is found. Y 10 I don't like how small and dark this is.
Average All users attempted to find the goal slide by Y:3 N:2 3.6 Even after showing the users that slide previews are shown when they clicking through the scrubber but none hover over the lower scrubber, they did not like them because they accomplished it this way (they used the slide were obscured and transparent. Participants looked at and used the top navigation buttons). scrubber and only one used the lower.
Task 2 (Add a comment that says 'I completely agree.')
User Observations Completed Difficulty Comments Rating
1 User sees button right away but said they would abandon as soon as seeing Y 10 This interface is horrible. the login fields
2 User found it immediately. Y 10 I like this comment better than Omnisio.
3 User tries clicking on the video but then finds button. Y 8 I gave it an 8 because the text on the button was small.
4 User added comment with no problem. Y 10 It was easy to find because the button is right there.
5 User found button immediately. Y 9 I didn't give it a 10 because the button was small.
Average Users had no problem seeing the comment button and adding a Y:5 N:0 9.4 Having a comment button made sense to the comment. However, one was discouraged upon seeing the login fields. users and they had no problem using it even though it was small.
Task 3 (Find the section of the lecture where the presenter talks about metadata)
User Observations Completed Difficulty Comments Rating
1 User commented that they would have no idea how to find that content but saw and used the Y 2 If this actually worked, I would like it. search box immediately. AFter searching, user did not notice feedback and was confused about the red lines.
2 User looks through slide titles and finds it in a title description. Y 10 Facilitator showed the user search but they did not understand the red lines.
3 User hovers over scrubber looking at titles but they are zoomed in on the scrubber so the goal N 3 The search is Ok but I didn't even notice it slide title isn't visible. User was unable to complete and Facilitator showed him search after there; that's the best way to find this topic comments were collected. in the lecture. 4 User went directly to search but was confused when they clicked the button because there N 1 After searching: I don't know if it's doing was no feedback and the text disappeared. anything, I'll try again...I don't know...maybe I'll go through slide by slide. After collecting comments, Facilitator showed them: Oh, hm, that's very hidden. I guess it makes sense.
5 User searched right away but was confused after clicking Search. N 5 Finding the search was easy but it confused me. When I searched, I expected a new page or something.
Average 3 Users searched immediately and two looked at slide titles. Both methods worked, Y:3 N:2 4.2 The red line feedback from search however, for those that searched, they became confused with the feedback provided made sense to the users after being by ePresence. The red line displays before the user clicks search and the text from asked but most did not notice them. the field disappears after they click the Search button.
Omnisio
Task 1 (Find the slide that had a pair of shoes on it and begin watching the rest of the presentation)
User Observations Completed Difficulty Comments Rating
1 User hovers over slide previews until they find the goal slide. Y 10 Very easy. This is more intuitive than MediaSite and Echoe360. I like these slides; I can go through them quickly.
2 User found goal slide very quickly. Y 9 I prefer MediaSite because I could see multiple slides; in this one, I can only see one at a time.
3 User had no difficulty. Y 9 I gave it a 9 because it didn't play as soon as I clicked the slide preview.
4 User hovers, clicks, and plays. They weren't able to click on the desired Y 9 I didn't give it a 10 because it was a little difficult to click what I one right away because it was more sensitive than they thought it would wanted. This is very modern, I like it! be.
5 User hovers over and clicks goal slide. Y 6 These slide previews are very small and crowded...too close together.
Average Slide timeline worked well for users but the sensitivity to click on Y:5 N:0 8.60 Users were quite pleased with Omnisio during this task. one particular slide was a slight problem for them. There were two complaints regarding the slides being too small and cramped to view.
Task 2 (Make the video of the presenter as large as you can)
User Observations Completed Difficulty Comments Rating
1 User clicks the Expand button in the goal video until it gets smaller. Then repeats and Y 10 This one is better than Echo360 and finds the FS button at bottom. MediaSite
2 User clicked Expand button in goal video then FS button at bottom. Y 10 This was very intuitive.
3 User clicked FS button at bottom then Expand in goal video until goal state was achieved. Y 9 I didn't think I would be able to make one video larger than the other; that's a good feature but it should be highlighted so I know that it's there. I'm not going to hover over the video when it's playing full screen - I'll be watching.
4 User clicked Expand until the video got smaller then double clicked the video. I don't Y 3 I had problems finding the Full Screen button know. User clicks FS button at bottom then Expand. at the bottom; maybe it should be with the other one (expand).
5 User clicks Expand until video gets smaller then again and clicks Full Screen at bottom. Y 10 I don't like this...I'm not sure why.
Average 4 out of 5 users clicked the Expand button found in the video before clicking the Y:5 N:0 8.4 Users seemed confused because of the full screen button found at the bottom in the control bar. They also clicked the separation of the screen adjustment Expand button until the video got smaller meaning they may have expected this functionality. button to take them all the way to full screen.
Task 3 (Add a comment that says 'I completely Agree')
User Observations Completed Difficulty Comments Rating
1 User clicked video immediately and added comment. Y 10 I like clicking hte screen to add comments but I would like all the comments combined somewhere.
2 User is not sure what to do even though they had the comment box open multiple times. Y 7 I would rather have a button on the right User clicked the comment button in the upper right but created a comment eventually. side.
3 User tried clicking and double clicking but there's a comment already visible in the other Y 6 This comment box should move to where I video section that they didn't notice. User is having problems but finds it after a while. just clicked so I know it's doing something. This is another hidden feature...maybe there should be a button on the side. 4 User had no problem. Y 10 That's a good feature. I like that I click to add.
5 Before user begins, the add comment box is open. User looks at buttons on right N 4 I don't like clicking. I expected there to be a immediately and finally gives up. button.
Average For the users who had difficulty with this task, there was a comment box open Y:4 N:1 7.4 Most users looked at the buttons on the before they began. They didn't seem to notice it open already and the comment right side of the player and clicked the box does not move when the screen is clicked in another location. Comment Filters button.
Mediasite
Task 1 (Find the slide that has a picture of people sitting in a green room and begin watching the rest of the presentation)
User Observations Completed Difficulty Comments Rating
1 User dragged scrubber and did not click on Y 10 None slide previews at all.
2 User dragged scrubber and looked at slide Y 10 I like the preview thumbnails. previews.
3 User drags playhead and watches slide Y 9 This and Omnisio were the easiest because they have a simple slider (scrubber). previews go by.
4 User drags playhead until they see the Y 7 A seven because moving the thing (playhead) was difficult. It's nice but it wasn't easy to picture. They click the slide and Play. drag it...but maybe it's because of this Macintosh that I'm not used to. Facilitator gave him a mouse for the subsequent tasks.
5 User clicked slide previews to move them. Y 10 I like this, it's much more organized than Echo360.
Average 4 out of 5 users dragged the playhead Y:5 N:0 9.2 The users were pleased with the slide navigation in Mediasite on the scrubber instead of the slide previews.
Task 2 (Make the video of the presenter as large as you can)
User Observations Completed Difficulty Comments Rating
1 Clicked Full Frame, then PIP, FS, Swap, etc. Tried many buttons but could not accomplish goal. N 1 It's not difficult but it's not logical. Makes more sense to click over the one you want to see.
2 User clicks video of presenter, then looks in lower right, then upper left. User clicked a series of buttons Y 9 I didn't give it a 10 because in the upper right until goal state was reached. there were multiple buttons and they weren't at the bottom with the others.
3 User clicks all the buttons and seems to be getting frustrated. User tries double clicking, then looks at Y 3 After finding it: Uh, ok...I guess bottom of videos but is avoiding the swap button. Finds it eventually. I understand this button (swap) but it's not what I thought of - the icon is like Back or Refresh.
4 User double clicks the small video then clicks the buttons on the right many times until goal state is Y 4 Four because these buttons reached. This took quite a while. aren't well explained. I thought the one (swap) was refresh.
5 User double clicks the small video then clicks the magnifying glass in the upper corner of the slide video. Y 7 This was very difficult because They look at the bottom then clicks all buttons in the upper right except Swap. After clicking them for of the buttons. quite a while and double clicking the videos, they reach the goal state.
Average 3 out of 5 users clicked the video first and all ended the task by clicking the buttons in the Y:4 N:1 4.8 The users didn't upper right in various sequences. understand the button logos nor their mappings to functionality.
Post Study Data Rankings
User First Second Third Fourth Comments Choice Choice Choice Choice
1 Echo360 Omnisio MediaSite ePresence User had difficulty choosing between Echo360 and Omnisio but decided that Echo360 was better for studying
2 Omnisio Echo360 MediaSite ePresence None
3 MediaSite Omnisio Echo360 ePresence MediaSite was simple with small icons and the video was central. User critiqued the rest of the Omnisio page (i.e., all that is below the player). In Echo360, I couldn't find the scroller. ePresence just wasn't usable.
4 Omnisio Echo360 MediaSite ePresence Omnisio had many features and it was easy to use. It's similar to YouTube. Echo360 was very easy to find contents. MediaSite was clear finding slides but the buttons were confusing. ePresence was very messy and difficult to look for slides.
5 MediaSite Omnisio Echo360 ePresence I liked MediaSite because it was large and easier. Average ......
Take Aways
Scrubbers similar to ePresence will not suffice. There should be preview images visible and easily scannable. Using slide preview images as a timeline/scrubber is an effective mapping. Consider mapping double-click to screen sizing. Have two methods of searching for topics within lectures (search and slide title/topic). Have noticeable and clear feedback when a search is completed. Icons and implementation of video adjustment options should be well thought out as they have shown to be a source of usability risk.
Engage Tools Results UOC (I5)
Study Design
The design and execution of this study can be found on this page: https://wiki.opencastproject.org/confluence/display/open/Engage+Tools+Study +%28I5%29
Summary
The participants had significant difficulty dragging the playhead in the scrubber. They were unable to drag it exactly to 10 seconds which seemed to frustrate them. The participants were asked what the video navigation buttons do and the majority commented that they would click < and > once to go backward and forward in the video. Only one participant specified that they expected the video to play at double speed when clicking this (as opposed to "skipping" forward). All participants commented that the << button would take them to the beginning of the video and then >> button would take them to the end; one user commented that this feature "didn't make sense." Two users clicked the volume button expecting a vertical volume slider to appear. No participants were familiar with the term Closed Captions (CC). Participants used the full screen button to enter and exit full screen.
Pre Study Data
User Age Gender Major
1 25 M Telecommunications
2 47 F Law
3 32 F Business
4 32 M Business
Interaction Notes Key
User: Participant number Observations: Participants' actions were observed and recorded by at least one facilitator Completed: Was the task completed or not (Yes or No) Difficulty Rating: Participants were asked to rate how easy or difficult it was to complete the task (1: Difficult 10: Easy) Comments: Participants were asked open ended questions and their responses, along with any other comments, were recorded Task 1 (Start the video and watch the first few seconds then pause the video)
User Observations Completed Difficulty Comments Rating
1 User clicks video section Play and Y ? I like having the Play and Pause at the bottom but I prefer the larger ones in the video. Pause.
2 User clicks large Play button and Y 10 Very easy. small Pause button.
3 User clicks Play and Pause in the Y 10 I prefer using those at the bottom because they're always there. control bar.
4 User clicks control bar Play and Y 10 User comments that there are no video control buttons when in full screen. user would like to have Pause. video controls appear when the mouse movies.
Average Users had no problems. Y:4 N:0 10 None
Task 2 (Skip the first 10 seconds of the video)
Note: The goal of 10 seconds was chosen arbitrarily without knowing the player's scrubber made it difficult to reach this mark. Thus, the tasks were considered successfully completed if they reached anywhere from 9-11 seconds. User Observations Completed Difficulty Comments Rating
1 User has difficulty with scrubber. Y ? This was difficult.
2 User had problems dragging scrubber to 10 second mark. Y 10 I normally use the slider. The >> takes me to the end and I would click > once to go forward. The different color in the slider means it's charging (User means Loading).
3 Begins to drag playhead but then clicks > once and drags Y 9 I didn't give it a 10 because I couldn't get it exactly at 10 seconds. I was using playhead again backwards. Begins to have difficulty. the buttons but they went too far and I prefer to use the slider.
4 User drags scrubber but has difficulty getting to 10 Y 3 It was quite difficult to get to 10 seconds so I gave it a three. Maybe I should seconds exactly. be able to type in 10 in the time area down here (referring to timecode).
Average Users had significant difficulty getting the playhead Y:4 N:0 7.3 All users tried to accomplish this task by dragging the playhead. When to stop at 10 seconds. they began having trouble, they tried using the < and > buttons.
Task 3 (Skip some more of the video until you see something that looks more interesting to you)
User Observations Completed Difficulty Comments Rating
1 User drags scrubber again. Y ? None
2 User clicked > button to go forward Y 10 None in video.
3 Uses arrows Y 10 None
4 User drags playhead. Y 10 I don't use the << < > >> buttons because they never work very well on DVD players. When I clicked > in this, I expected to see the video play quickly. User clicks >> and is surprised when it takes them to the end. This doesn't make sense - why would I want to go to the end?
Average Half of the participants used the Y:4 N:0 10 None scrubber and the rest used the navigation arrows.
Task 4 (Turn the volume up all the way)
User Observations Completed Difficulty Comments Rating
1 No difficulty; drags volume playhead. Y ? It was easy.
2 User had no problems. Y 10 None
3 Dragged volume slider after clicking the Y 10 I clicked the volume button because I thought the volume slider would pop up vertically. volume button.
4 User clicked volume button, then again and Y 9 I clicked the volume button because I expected the volume control to pop up but I figured drags volume slider. it out when I saw that it muted...I just expected it to be vertical.
Average No difficulty but two users did not map Y:4 N:0 9.6 Half the users clicked the volume icon and expected a slider to appear. the volume icon to the slider.
Task 5 (Mute your volume and see if you can read what is being said instead of listening)
User Observations Completed Difficulty Comments Rating
1 User mutes with no problem but looks at player for a while before clicking CC button. Y ? I don't know what CC is, we don't have that in Spain.
2 User had little problem. Y 2 I didn't notice the CC button because it's little. I don't know what CC is.
3 Muted and turned on CC immediately. Y 6 I've never seen CC before and I wouldn't even think to look for it but I would use it.
4 User clicks CC right away. Y 5 I only clicked CC because it's the only button there that I didn't know. I've never seen CC. I would never use this.
Average Users were able to deduce that the CC button would accomplish the task but Y:4 N:0 4.3 No participant (all were from Spain) had in general, they were confused with the scenario and goal of the task. heard of Closed Captioning (CC).
Task 6 (Make the video larger then return to the original size)
User Observations Completed Difficulty Comments Rating
1 User clicks FS button then again to close. Y ? None
2 User clicks FS button then ESC to close. Y 10 None
3 User clicked FS button for full screen and exit. Y 10 None 4 User clicks the FS button for entering and exiting FS. Y 9 I would also like to double click for full screen. The mouse (cursor) should disappear in full screen.
Average 3 of 4 users clicked the full screen button to enter and Y:4 N:0 9.6 One user commented that they would like to be able to double exit full screen mode. click to enter full screen.
Post Study Data Open Ended Questions
User Impressions Suggestions
1 None None
2 None I want to be able to pause and add comments.
3 None None
4 None None
Average ......
SUS
Note: The scores for questions 2, 4, 6, 8, and 10 have been reversed to provide more clear results to the reader of this document (i.e., a score of 5 is best instead of 1). Note: A score of 5 is optimal for the system. To learn more about the questions and scores, refer to the next section.
User 1 2 3 4 5 6 7 8 9 10
1 ? ? ? ? ? ? ? ? ? ? 2 5 5 4 5 4 5 5 5 5 5 3 5 5 5 5 5 5 5 5 5 5 4 3 5 4 5 3 5 5 5 5 5
Average 4.3 5 4.3 5 4 5 5 5 5 5
SUS Questions
1. I think that I would like to use this system frequently 2. I found the system unnecessarily complex 3. I thought the system was easy to use 4. I think that I would need the support of a technical person to be able to use this system 5. I found the various functions in this system were well integrated 6. I thought there was too much inconsistency in this system 7. I would imagine that most people would learn to use this system very quickly 8. I found the system very cumbersome to use 9. I felt very confident using the system 10. I needed to learn a lot of things before I could get going with the system
(The complete SUS form given to the participants can be found here)
Recommended Improvements
Fine tune draggable playhead so that precise dragging is possible. Either use a vertical volume slider or create a stronger relationship between the volume button and the slider. Map double clicking the video section to enter full screen (part of the rational behind this recommendation is found in the comparative analysis results found here https://wiki.opencastproject.org/confluence/display/open/Comparative+Analysis+of+Dual+Media+Players+Re sults+UOC+%28I5%29 )
Engage Tools Study (I5)
Engage Tools Study
The following document is a user experience test designed to test the usability of the Flash/JS implementation of the simple media player.
Results
The results of this study can be found on this page: https://wiki.opencastproject.org/confluence/display/open/Engage+Tools+Results+UOC+%28I 5%29
File Modified
engagePlayerStudy_I5.pdf Nov 30, 2009 by Alicia Valls SUS.pdf Dec 17, 2009 by Alicia Valls SUS rating sheet given to participants
Drag and drop to upload or browse for files
Download All Past relevant work Media Player Comparative Analysis Media Player walkthrough Personas Scenarios Use Cases MEDIA PLAYER COMPARATIVE ANALYSIS
What is Comparative Analysis/Benchmarking?
It is the process of analyzing products which are similar to, or compete with, the product you are designing in order to generate ideas.
Try using similar services or products in order to find out:
Current trends in the marketplace What expectations your users will have What to do, what not to do Interface conventions "Must have" standard features
Sometimes it can even be helpful to have your users test comparable products they currently use or could potentially use in order to understand how these products succeed in or fail to help users achieve their goals.
More info
Completed Media Player Comparative Analyses benchmarking Echo360 benchmarking epresence benchmarking Mediasite benchmarking Omnisio benchmarking Tuva benchmarking VITAL benchmarking Youtube Structure of each media player
Features Analyzed
Search
We analyzed the different ways users access information: how to navigate through the content, search information, order the structure or download the documentation.
Navigation
We analyzed different methods that the player's interface offers the user for browsing. Investigate the elements that the user has to navigate and the various interfaces provided by the system.
Private/Community (user) marks
We analyzed the level of customization and the elements of web 2.0. Also, we investigated the level of diffusion that the user can give to the tool through tags, bookmarks and other personal and community items.
Accessibility
We examined the accessibility of the media players. Visualization
We analyzed the level of customization that the player offers, the different ways of viewing the interface.
Other
This section includes important items that can not be classified under the previous sections.
Preparation
Before we began our Comparative Analysis, we created a List of candidates which described all the players we were considering for our analysis. Next we created a List of user needs, which listed the functionality we expected users to need in a media player and then stated whether each player incorporated each piece of functionality.
List of user needs
Legend: good practice bad practice interesting but needs improvement
Player Tel Project VITAL MediaVision ePresence Replay Yovisto Omnisio Kaltura Echo360 Aviv Pad
User reviewer Jack Judy JuanAntonio Olaf A. Juan Antonio Sally Sally
Access to information
Browse for videos (as Yes In WCMS Yes not implemented for not implemented for opposed to search) via REST viewer (but viewer (but management management interface interface allows allows administrators administrators/presenters/ to browse videos) A/V technician to browse videos)
Search in user N.i NI N.i. Not implemented not implemented for not implemented for entered metadata viewer (administrator viewer (if 'user' is also about the video in Yes can use management defined as 'presenter' general interface to search then they can have (non-isochronic) video metadata) access to management no search of interface and can search user-entered video metadata) isochronic metadata but planned for search in bookmarks in next version - due for imminent release.
Search in N.I N.i. Not implemented user-entered isochronic/time-based Yes metadata within the video (e.g. annotations, bookmarks)
Search in technical N.i Not N.i. Not implemented Management interface not implemented. metadata (e.g. implemented allows search on file search for all H.264 extension. media)
Search in usage Displays Not Displays You can browse by Management interface metadata among all "popular" implemented "popular" Recommended, reports number of videos (e.g. videos in Latest plays 'reports' option offers most-watched a tag videos Presentations, number of captures/views videos) cloud Latest 'this year by week' and Compilations, 'this month by day'. More Most Commented, detailed pdf of reports can be generated by presentation/media type/time of day/week of year.
Search in Not implemented File/event metadata not implemented for file/event metadata not separate from viewer (if 'user' is also (e.g. Lecturer, Yes 'tags' defined as 'presenter' Lecture Title) then they can have access to management interface and can search file/event metadata) Search in N.i Not implemented Not implemented no search of slides but non-audio-video planned in next version - content (e.g. Yes(does due for imminent release. transcription, slides) not work at transcription file is a text my end; file so can be searched OAS) using software used to read file.
Search in content N.i N.i. Not implemented Not implemented not implemented. (e.g. search in the audio-video content) Yes (does not work at my end; OAS)
Search for tags or N.i Not N.i. Not implemented Not implemented not implemented. marks in a particular implemented chapter or set of chapters or slide(s)
Access to event N.i Not implemented event/summary 'info' panel as tab under summary/description Yes description not video in presentation (Quick View) separate from 'tags' interface.
Download additional No Not implemented Not implemented. related files (ppt, doc, txt, pdf) can add text file (eg transcript). Appears as download link in info panel.
Download the full No Not No Not implemented Not implemented. module (everything implemented that is online for this yes - as zip file event in a self-contained application that replicates the complete experience) for viewing offline
Download in the No Not Some Not implemented Not implemented. format I need for my implemented additional device (iPhone, formats additional formats android, iPod etc. ..) available offered: mp3, m4v, and m4b
See structure of the N.i N.i. Not implemented Not implemented. not implemented. video by chapters Yes
See structure of the Yes Not implemented. video by slides Yes system generates swfs and jpgs of slide content which act as 'bookmarks'
See N.i Not N.i. Not implemented Partnership with subtitles/captions implemented SubPLY (http://www.s ubply.com) allows presenter must add addition of subtitles manually created and captions to any captions file. type of web video.
Localize the content N.i Not German, Not implemented Partnership with management interface & application for my implemented English SubPLY also allows allows system time to be needs (e.g. time, addition of subtitles set + synchronisation with language) and captions in any ntp server. language to any type of web video.
Allow users to submit N.i Not No Not implemented not implemented not implemented translations implemented
Navigation
Navigate by chapters No No concept of No concept of not implemented chapters chapters Yes
Navigate by slides No concept of slides Yes
Play, stop / pause, Play/Pause Play, stop / pause rewind, FF Play at double speed Only Not No Not implemented not implemented not implemented (x2, x4) using implemented Internet Explorer
View video by parts N.i Not No No concept of No concept of not implemented (see one chapter or implemented chapters chapters one slide, but don't jump to the next)
Navigating to a point ? ? Yes Yes in the video that matches a point in real, i.e. 'clock,' time
Connexion
When was the last N.i Not N.i. Not implemented not implemented not implemented time I connected? implemented
Where did I leave off N.i Not N.i. Not implemented not implemented not implemented the last time? implemented
What I have seen? N.i Not N.i. Not implemented not implemented not implemented implemented
What do I have left to N.i Not N.i. Not implemented not implemented not implemented see? implemented
Private (user) marks
Add Tags No No Not in player, in not implemented management Yes Yes interface, user adds tags on upload. Administrator can also add tags.
Add Bookmarks No No Not implemented not implemented not implemented Yes
Add general No No No, but plugins exist not implemented comments about the for Wordpress, Drupal video rather than Yes Yes and MediaWiki time-based
Highlight Segments No Not No Not implemented Advanced video editor not implemented implemented in Kaltura CE allows this.
Add annotations No No Advanced video editor not implemented (time-based) in Kaltura CE allows Yes Yes this.
Add annotations No Not No Advanced video editor not implemented (time-based & implemented in Kaltura CE allows space-based) Yes this
Set Annotations as No Not No not implemented not implemented public / private implemented Yes
Edit the chapter titles No Not No No concept of No concept of not implemented implemented chapters chapters
Community marks
Rate with stars No Not N.i. Not implemented No, but plugins exist not implemented implemented for Wordpress, Drupal and MediaWiki which may allow this.
Add general No No No, but plugins exist not implemented comments about the for Wordpress, Drupal video rather than Yes Yes and MediaWiki which time-based may allow this.
Add tags No No not implemented not implemented Yes Yes
Add links to course No Not No Not implemented No, but plugins exist not implemented content/syllabus implemented for Wordpress, Drupal and MediaWiki
Add annotations No No Advanced video editor not implemented (time-based) in Kaltura CE and Yes Yes concept of 'sharing' allows this. Add annotations No Not No Advanced video editor not implemented (time-based & implemented in Kaltura CE and space-based) Yes concept of 'sharing' allows this.
Set annotations as No Only for No not implemented not implemented public / private registered users Yes
Set annotations as No Not No not implemented not implemented anonymous vs. implemented attributed to user Yes
Add bookmarks No Not No Not implemented not implemented not implemented implemented
See the most No Not No Not implemented not implemented not implemented watched parts of a implemented video
See annotations No Only for No Not implemented Concept of 'sharing' not implemented registered allows this users
See comments No Only for No plugins exist for not implemented registered Wordpress, Drupal users Yes and MediaWiki
See Bookmarks No Not No Not implemented not implemented not implemented implemented
Show list or link to Not A ilst named: More Concept of 'playlists' not implemented similar content (e.g. implemented from this channel that can be created by other videos from administrator. Plugins same course / exist for Wordpress, instructor / subject, "if Drupal and MediaWiki you liked this video...you'll like")
Other interesting No Share it No An advanced plugins exist for not implemented social networking option, you embed Wordpress, Drupal features can post it configuration for and MediaWiki into Facebook, Facebook, Wordpress, DiggIt & Blogger,iGoogle Del.licious and 27 more.
Accessibility
Turn subtitles on/off No Not No Not implemented Partnership with ? implemented SubPLY also allows addition of subtitles in any language to any type of web video. They can be turned on and off.
Turn on/off closed No Not No Not implemented Partnership with yes. youTube cc option captions implemented SubPLY also allows style addition of captions in any language to any type of web video. They can be turned on and off.
Turn on/off closed No Not No Not implemented ? audio description implemented
Visualization
See Full screen yes yes
Yes Yes
See Only Slides The No concept of slides yes slides are integrated Yes in the video
See Only Video No Not applicable yes Yes Yes Customize the layout No Not No Not Implemented Yes using templates implemented
Other changes to No Not No The user can API allows changes to different viewer controlled layout implemented change the size of other aspects of the options to view video & slides player.
Comments Not geared to a viewers love the lecture recording interface, ease of moving scenario. Pretty through presentation, interface. KalturaCE is differnet formats and the currently in Alpha so fact that it works on any some functionality is OS (linux.Mac and in early stages. Windows)
Legend: good practice bad practice interesting but needs improvement
List of candidates
Player Name Player URL
1. Tel Aviv http://n2lvip.tau.ac.il/index.php?option=com_content&view=video&id=88:basics-on-technology-for-cellular-electronics-interfaces&catid=34:noshatel-2007&Itemid=55
2. Project Pad http://dewey.at.northwestern.edu/ppad2/ 3. VITAL http://ccnmtl.columbia.edu/vital/nsf/environment.html
4. MediaVisio http://www.opencastproject.org/wiki/case_westerns_mediavision_courseware n
5. ePresence http://epresence.tv/showcase
6. For http://www.multimedia.ethz.ch/ content-based search and navigation, REPLAY
7. YOVISTO http://www.yovisto.com 8. OMNISIO http://www.omnisio.com/v/ieHibSEdjhG/dna-for-dollars---featuring-23andme-genetics-just-got-personal
9. Kaltura http://www.kaltura.org/kdp-dynamic-player-and-playlist-widget http://www.kaltura.org/kdp-dynamic-player-and-playlist-widget
10. Echo360 http://www.echo360.com
11. Panopto http://www.panopto.com/showcase.aspx
12. MediaSite http://www.sonicfoundry.com
13. JW http://www.longtailvideo.com mediaplayer
14. Open http://www.openvideoplayer.com/ Video Player
15. FlowPlaye http://flowplayer.org/- r
16. VLC http://www.videolan.org/
17. Miro http://www.getmiro.com/
18. Gnash http://www.gnu.org/software/gnash/
19. Youtube http://www.youtube.com
Media Player Comparative Analyses benchmarking Echo360 benchmarking epresence benchmarking Mediasite benchmarking Omnisio benchmarking Tuva benchmarking VITAL benchmarking Youtube Structure of each media player benchmarking Echo360 File Modified
Benchmarking Echo360 v.1.0.pdf Aug 13, 2009 by Alicia Valls Benchmarking Echo360.pdf (version 1.0)
Drag and drop to upload or browse for files
benchmarking epresence
File Modified
espresence v.0.1ppt.pdf Jul 23, 2009 by Alicia Valls
benchmarking epresence.ppt Aug 19, 2009 by Allison Bloodworth
Drag and drop to upload or browse for files
Download All benchmarking Mediasite
File Modified
Benchmarking mediasite v.0.1-1.pdf Jul 27, 2009 by Alicia Valls
Drag and drop to upload or browse for files
benchmarking Omnisio
File Modified
Benchmarking Omnisio.pdf Aug 11, 2009 by Alicia Valls Drag and drop to upload or browse for files
benchmarking Tuva
File Modified
Benchmarking Tuva.pdf Aug 13, 2009 by Alicia Valls
Drag and drop to upload or browse for files
benchmarking VITAL
File Modified
Comparative Analysis of VITAL.pdf Aug 06, 2009 by Judy Stern
Drag and drop to upload or browse for files
benchmarking Youtube
File Modified
Benchmarking youtube.pdf Aug 11, 2009 by Alicia Valls
Drag and drop to upload or browse for files
Structure of each media player
These pages analyze the overall structure of each media player. It is significant to note that the distribution of the various component parts of the player does not differ greatly among players. The arrangement of the elements is often the same. echo 360 epresence mediasite Omnisio Tuva Youtube echo 360
epresence
mediasite Omnisio Tuva Youtube MEDIA PLAYER WALKTHROUGH
VirtPresenter Walkthrough
Introduction
Only heuristics and Cognitive walkthrough, no accessibility
Analysed scenario: "Lisa, Getting back to confusing part in lecture"https://wiki.opencastproject.org/confluence/display/open/Context+Scenarios+fo r+Lisa
Next day, next scenario
Adobe connect (+1) Good tool, easy to use even with firewalls in the middle (-1) you have to be very familiar with the scenario and specially with the heuristic analysis
Cheklist:http://wiki.fluidproject.org/display/fluid/UX+Walkthrough+Protocols+and+Checklists
General recommendations Lisa, getting back to confusing part in lecture
• Show time of recording • Show name of the subject of the class • Scrubber: copy the YouTube style • Change the caption of the "bookmark" button to "Power point" when Bookmark box is taking its place • Redesign all bookmark interaction • Make a clear difference between menu of chapters and menu of lessons Lisa, studying for an exam
• Allow Power Point downloading because she needs a printed copy of the Power Point. • Search for text in captions and in Power Point • Printable version of all annotations of a lesson because she is editing her study sheet • Print a video frame: "She also decides it would be useful to have a replication of the diagram the professor drew on the chalk board during lecture. So she also sketches it in her study sheet" • Search for "related videos: same subject" • Search for "related videos, same teacher": "She really likes the way this guy explains things, so decides to locate the places he's covered protein structures, and watches those"
Lisa, getting back to confusing part in lecture Heuristic Visibility of the system status
• (+1) Name of teacher is visible • (+1) Date of the lesson is visible • (-1) Title of the lesson is not visible • (-1) Lsson start time not visible • (+1) Easy to know the chapter that is beeing reproduced. There are two different indicator, a color bar in the menu and the divisions and the position of the pointer on the scrubber • (-1) No feedback for "Video downloading" when waiting to start Match between system and the real world
• (+1) Virt Presenter works as a reproduction of the classroom: name of the teacher, date, blackboard, teacher, power point, etc. • (-1) Lack of information about the time (10:40am) of the recording. 40am) and what she finds are minutes from start (0:40). This is not a severe problem because she knows when the class begun so she can make her correspondence. User control and freedom
• (+1) It's possible to drag the ponter along the scrubber • (-1) When you drag, a tab with the time over the pointer would be wellcomed • (-1) Not clear what's the difference between "square" and circle" • (-1) Bookmarks a segment allowed but difficult to use • (+1) Multiple bookmarks allowed but difficult to use • (+1) "Footprints" are GREAT • (+1) Buttons to navigate through the power point are useful • (-1) There is some confusion between "next slide" and "next chapter" • (-1) There is some confusion between "Next animation" and "Next slide" when slides don't have animations • (+1) Menu of chapters • (+1) Menu of lessons into the same player • (-1) There is some confusion between menu of chapters and menu of lessons. They represent different levels but are shown in the same way Consistency and standards
• (-1) Scrubber doesn't look like Youtube Error prevention Recognition rather than recall
• (+1) Almost all options are visible • (-1) Bookmarks are hidden Flexibility and efficiency of use Aesthetic and minimalist design
• (+1) Design is clean Help users recognize, diagnose, and recover from errors
• (-1) When a user click over the "bookmark" buttom, power point dessappear and Bookmark box appears in its place. Not easy to understand that to go back to the Power Point the same button has to be clicked again.
Help and documentation
Lisa, studying for exam Visibility of system status Match between system and the real world
(+1) Browse other lessons of the course User control and freedom
(-1) Not posible to download Poer Point (+1) "nest slide" and "previous slide" (-1) Not a index of slides (+1) Highlights (-1) There's not a searcher by words (-1) There's not a list of related videos: same teacher (-1) There's not a list of related videos: same subject Consistency and standards Error prevention Recognition rather than recall Flexibility and efficiency of use Aesthetic and minimalist design Help users recognize, diagnose, and recover from errors Help and documentation PERSONAS
Christopher Ackerman: The Efficient Soccer Student (Combined Engage Persona from UC Berkeley and UOC)
Lisa Ng: Conscientious Student (from UC Berkeley user research) Martina (from UOC Open University of Catalunya user research) Jordi (from UOC Open University of Catalunya user research)
Christopher Ackerman
Background Main Points
"I care about school - but I like Age: 20 Perfect grades are not a priority – soccer too so when it comes to School Level: University Sophomore winning the next soccer game is. studying, the quicker I can get it Major: Undecided Doesn't dedicate every night studying over with, the better." (2-3 nights/week and Sunday) so this time must be used effectively. Has a roommate that can sometimes be a distraction. If this happens, he'll sometimes go to the computer lab but he can't go there every time. Tries his best to pay attention in class but sometimes misses a topic or even an entire lecture. Creates study sheets comprised with vital details needed to pass exams; these come from books, notes, and lectures.
Personal Goals Christopher Ackerman is a 20 year old full-time sophomore student at a well-respected university. Pass classes and get a His family is fairly well-off; his father is a doctor and his mother juggles running her own jewelry degree business and taking care of his younger sister. Though his family harps on about him choosing a Do well in soccer and lift the major, he hasn't yet selected one and is still completing his general education requirements. He school team's ranking knows he must get a degree, because everyone in his family has one. Fortunately, he doesn't Be as efficient as possible need to work during the school year since his parents can easily afford his tuition and board and when dealing with school really want him to concentrate on school. Interests and Priorities
Frustrations & Pain Points Though he would like to do well in school, Christopher's biggest passion is soccer. He has been playing since he was very young, and of course plays on his university's team. Sometimes his When professors don't use many soccer practices get in the way of classes or studying, and soccer always wins out in that slides or notes. This makes it situation. This means he doesn't always get as much out of his classes as he could, but he does more difficult to identify key his best to be an incredibly disciplined and efficient student with the time he has. He has soccer points that will be on the practice 4 nights a week and games every Saturday, so he usually spends 2-3 evenings per exam. week as well as Sundays studying. Because he doesn't have much time to study, he focuses his When his roommate distracts attention on just what is needed to pass his courses. He usually ends up with acceptable grades him while he's studying. because of this--and that's enough for him. He really doesn't feel the need to get perfect grades. Study Habits Scenarios Christopher has all the typical devices of a college student; he owns a cell phone, laptop, and MP3 player while he and his roommate share high-speed internet access and a Playstation. Eric, Christopher's roommate and close friend, can make it difficult to study sometimes when he listens to music loudly and has friends over to play video games. Because Christopher's study time needs to be used as effectively as possible, he sometimes heads to the computer labs when Eric is a distraction but he also goes there between classes and when he is studying with a group.
In general, Christopher has good study habits but he isn't always on top of everything. Though he almost always goes to class, he doesn't pay as much attention as he should on days after celebrating a soccer victory with friends or texting the cute girl he's been talking to lately. This is why he's really happy that his courses are webcast; in these situations, he can always go back and review the parts he missed or didn't understand. If he still has questions about something in class, he'll try to figure it out himself or email other students because he knows professors rarely respond quickly. However, if he thinks it will be quicker to contact the instructor, he will send them an email.
He also frequently uses the webcasts to create a study sheet for exams; he's learned through experience that this is the best method to do well on tests. When he's studying with textbooks or notes, he used highlighters to mark the parts of the text that he knows he'll want to find again, as well as to identify key points or points of confusion (which he'll follow up on with a TA or instructor). This all this culminates into the creation of his 2 to 6 page study sheet that provides a summary of everything he wants to review immediately before an exam. In a similar way, he relies on webcasts to help him study. When he doesn't understand a topic covered in class, he'll review portions of the lecture where he got confused and he'll use the webcasts to help create a study sheet. Thoughts on Differing Lecture Styles
Not all of Christopher's instructors share the same teaching methods. Chris' chemistry professor doesn't use slides which is frustrating for him. Dr. Blythe writes on transparent paper which is projected onto a screen in front of the class. During the lecture, Chris usually tries to take as many notes as possible but tends to miss some information when Dr. Blythe goes too fast. Similarly, his philosophy professor does not use slides and writes virtually nothing on the board. Further, there's no textbook for the class. This makes it very difficult for Christopher to identify vital details and create his study sheets. If he's not confident about the material, he tends to have to review entire lectures a second time when it gets close to midterms and finals just so he can pass the exams. His computer science professor, on the other hand, has very organized slides which make it very easy for him to annotate and identify what material he needs to know for the exam. Chris prints out the Notes version of the slides which he uses to take notes inline during class. This also helps him find the point in the webcast that he's interested in--if his notes tell him he should review something, he finds the corresponding slide in the webcast and plays the webcast from that point on.
Jordi Jordi
Description
Jordi is 35 years and works as a logistics technician in a pharmaceutical company. Within two years his boss will retire, and he may have the opportunity to take over his boss's position. In order to improve his chances in getting the position, his boss recommended that he do a master's degree in logistics. He told him that this degree would be highly valued by the management team.
Jordi has been married for 1 year, and likes to spend time with his wife. In order to balance his personal and professional life, Jordi has established specific times to study. He spends one afternoon per week and Saturday mornings studying. Because he doesn't have much time to study, he focuses his attention on just what is needed to pass his courses. He knows that he will not get very good grades, but he doesn't care--he just wants to pass. His goal is really to just get the degree and to do it as quickly as possible.
He doesn't mind sending an email to his instructor or tutor/teaching assistant to get help when he has a question. He is accustomed to using email at work, and sometimes takes a few minutes at work to send email to his instructor, tutor, or fellow students about the course.
He has exchanged emails with most of the other students in his Masters program. So he usually responds to emails from other students when they contact him.
Motto "I'd like to advance my career." Academic profile Not particularly interested in his studies for personal enrichment. He just wants to get a degree. He doesn't really care if he gets good grades--he just wants to pass his courses. The most important goal is to finish his degree as soon as possible. Sees his studies as a complement to the training that he already has. Attitudes He is disciplined and organized. He has clear ideas about what he wants out of life. Not really involved in too many activities outside of work, school, and the time he spends with his wife. Technical profile Recognizes the benefits of new technologies in both his professional life and in academia. However, he doesn't usually use them. Access to Virtual Campus Since he's not really familiar with new technologies, he prefers to just use email. He doesn't often use the more advanced tools such as chat, etc. Use of Virtual Campus He doesn't use the Virtual Campus intensively. He doesn't explore the contents beyond what is necessary for his courses. He values the ability to contact his teachers and tutors. He doesn't often contact his fellow students.
Lisa Ng (Conscientious Student)
Martina Background Main Points
Age: 32 POINT Family: Married. Mother of 2 kids under 5 POINT years old. School Level: Bachelors completed. Taking online classes as hobby. Major: Psychology
"I love learning more about psychology and telling my friends about what I'm learning."
Personal Goals Martina is 32 years old, married, and the mother of two children - Pole, who's 4, and Mary, who's Learn about topics that 2. When she became pregnant with Pole, she quit her job to take care of him. Pole started interest her in depth. preschool earlier this year which means Martina has some free time. She's always liked school Complete an online degree in and decided to take a few courses in subject areas that interest her; she's primarily interested in psychology. Once she psychology because she's learning how her children are developing. She decided to take the finishes, she may become a courses online because she wants to be home as much as possible for Mary and Pole. school counselor or start Her husband has a well-paying job and they are doing quite well with one income; this reduces another degree. pressure for her to go back to work or use these classes as a way to find a better job. However, Spend time with her family. she has entertained the thought of finishing a degree in psychology and becoming a middle school counselor. If she doesn't do this, then she will probably go back to her old job and may Frustrations & Pain Points continue to take classes online as a hobby. She's very proud of herself for being able to go back to school and her friends are impressed that she's back in school and knows so much about POINT certain subjects. POINT Interests and Priorities
Scenarios Martina is very interested in her studies but they do not come before family. Fortunately these interests rarely conflict thanks to the help she and her husband hire for around the house; so Martina's concerns are with only her children and her studies. She has to manage her time well but rarely feels stressed or pressed for time to study or get things done. Study Habits
The university mails her some learning materials and also provides them online; Martina primarily uses the online materials from her desktop computer at home. These are typically pdf files and html pages but sometimes they are interactive. Martina is comfortable using the computer but by no means considers herself savvy. She often feels that the materials don't delve into subjects deep enough and finds herself emailing the teachers and searching the internet for other resources like articles, videos, and materials from the websites of similar courses at traditional universities. Due to the extra effort Martina puts into her studies, she has impeccable grades and a deep understanding of topics in the classes.
Martina can be found studying throughout the day. She reads printed articles while the kids are in their swimming lessons and gym classes. When the kids are napping, she logs into the computer and works on the required exercises, watches lectures, and reads online.
When Martina reads the required materials provided by the instructor, she highlights what she thinks is interesting or important to know for the class; but because these topics are interesting to her, she finds herself almost highlighting too much of what she learns. This makes it difficult to find what she needs to answer questions but she doesn't mind too much because she wants to remember the material.
She doesn't study for exams because the online university doesn't require her to take any, however, she does have to complete exercises regularly. These are typically in the form of weekly worksheets consisting of open-ended questions regarding the most recent reading section but sometimes, the exercises are interactive multiple choice questions found online. When she's answering the open ended questions, she refers to the materials provided by the instructor but often goes beyond the required answers and includes things she learned from other resources.
Another resources she consults often are webcast lectures. She loves finding lectures from well-known universities and citing what she learns in the required exercises and with friends in conversation. Although, since she's a mother of two, she doesn't always have time to sit through entire lectures. She's often on the run and only has time for part of the lecture or has to step away intermittently to tend to Mary and Pole. This makes it difficult to keep track of what she has seen. Another difficulty she has is keeping track of what she found really interesting and wants to watch again later to refresh her memory.
SCENARIOS Context Scenarios for Lisa Context scenarios for Martina and Jordi
Context Scenarios for Lisa Context Scenarios for Lisa Getting back to confusing part in lecture
• Lisa is in lecture and realizes she's confused when the instructor starts talking about mitosis. • She wants to be sure she's able to go back and review the areas she's not clearly understanding. She looks at the clock and takes note of the time when things start feeling fuzzy (10:23). • When the professor introduces a new topic, she's fine for a while, but then gets an text message on her phone from a friend and decides it's important enough to read and respond to. When she realizes that she just missed several minutes of the lecture that might have been important, she estimates the time she started chatting (10:40) and writes it down, too. • Later that day she opens up her course site and goes directly to the webcast for that day. • Lisa looks at her notes to see the time she noted earlier, and uses that time to get her to the portion of lecture she needed clarification on. • She realizes, however, that she needs to back up a bit to remind herself of the context. She backs up a minute, and lets the webcast play from there until the end of that topic. • She's still not completely confident in her level of understanding, so replays what she just watched. • She then moves on to the next area she wants to watch (the minutes of the lecture she missed). This time she doesn't need to rewatch; she simply needed to view what she missed the first time. Studying for exam
• Lisa has an exam coming up and wants to create a study sheet she can use for the next week while on the elliptical @ the gym. • She gets out notepaper, her textbook, and her binder with PPT "notes" pages and gets comfy on the couch. • She starts reviewing the powerpoints and notes from the lectures after the last exam. As she does this, she's making notes (summarizing important topics) on her notepaper. (This will become her study sheet). • As she's making her way through the slides she decides it would be useful to hear the instructor's explanation of DNA replication again. • She goes to her course site and goes to a point in the webcast where that ppt slide is, and listens. One sentence he says seems to encapsulate the concept for her, so she tries to get it down word for word. Since her prof talks fast and does not always use lay terms, she relistens several times. • After she feels like she understands, she adds some notes in the study sheet. • She sees that there were a number of segments that she'd highlighted in this lecture, and selects a few to review, adding more notes to her study sheet. • She also decides it would be useful to have a replication of the diagram the professor drew on the chalk board during lecture. So she also sketches it in her study sheet. • She starts to summarize on her study sheet various protein structures, but she's feeling that there are some protein structures she still doesn't know. Which parts of the lectures cover protein structures? • She rewatches the parts of lectures that cover the protein structures she's feeling weak on. Now she can complete the section in her study sheet on protein structures. • Then she remembers that her TA said that the professor from two semesters ago had explained mitosis really well. (The T.A. even told her which lecture and at what time in the lecture this explanation occurs.) She finds where she noted the lecture title and time in her notes; she gets to exactly that point and starts watching. • She really likes the way this guy (professor from 2 semesters ago) explains things, so decides to locate the places he's covered protein structures, and watches those. Some of his explanations are, as it turns out, very useful to her and she edits what she has on protein structures in her study sheet. Rewatching lecture via webcast
• Lisa likes to rewatch lectures (1st time through is live) on webcast between lectures • As always, Lisa sits down at the computer before the next bio 1A lecture to watch the webcast of the last lecture. She's found that since each lecture builds on the previous lecture, it helps to have a solid understanding of the concepts covered, before attending the next lecture. • She goes to her course site and begins watching webcast • She skips over the first ten minutes of the lecture where the prof is just talking about logistical stuff. • As she watches she continues to quickly move past areas of the lecture she remembers being straightforward. • She also "highlights" sections of the lecture she may want to review at exam time, in some cases jotting down notes that help her make sense of the significance of what she's highlighted. • When a friend meets her at the computer lab to drag her to dinner, she logs out of the course management system. • After dinner, when she logs back in, the lecture starts playing where she left off, and she continues to highlight significant sections. • When she comes across part of the lecture that raises a question in her mind, she marks it, too, and jots down her questions to send via email to her T.A.
Context scenarios for Martina and Jordi Martina's scenario
Studying a unit Martina logs into the Virtual Campus and goes to the classroom of the subject of psychology. She notices that the teacher has introduced a new unit. She is enrolled in a course called "Motivations and emotions" which is a required course for her Psychology degree. She finds the video that covers the unit "Emotions," -- it's an explanation from the teacher and a power point. She decides to take a look to see what it is about. Once she has seen the video, she feels that she has a general understanding of the content.
That same afternoon, she has a meeting with her son's teacher. She knows that she will have to wait 20 minutes, so she decides to print the Power Point associated with the video to go through it. While reading the document, she marks all the things that she does not understand with a pencil. At home, she reviews all her questions and sends an email to her teacher asking these questions. Then, when she has read all the documentation she reviews the video and rates every single segment with stars. She sees the annotations of other users in one of the chapters that show that they just don't understand the difference between two different concepts, so she decides to answer them adding another annotation (NOTE: is this really a review or an annotation? what is a review? -> a review could be an comment to an annotation. Visually a text below another) to help her fellow students.
While watching the video Martina realizes that she has to prepare supper, so she decides to close the session. Just before disconnecting, she adds a bookmark so she can pick up where she left off later. The following morning, when her children have left for school, she decides to review the unit.
When Martina opens the video, she can easily tell what she has seen and what is left to see. (NOTE: this wouldn't happen automatically if she had just placed a bookmark--she'd have to go to the bookmark. We've talked about providing some sort of functionality which allows a user to 'pick up where they left but we did foresee this as happening automatically. Which scenario are we talking about here? -> Footprint of virtPresenter is perfect here ) Martina decides to study the last chapter of the video and browse the slides to find specific content. While Martina is studying the last chapter, her husband calls and reminds her that this weekend they're going to their second home in the mountains. Martina decides to take the copies of the powerpoint she's already printed, but in order to also take advantage of the computer there she also downloads the pdf and the video and saves them on a Pen Drive. In their second house there is no internet connection so she cannot go online to access the Virtual Campus, but she will still be able to see the pdf and the video. Jordi's scenario
Writing an assignment
The due date for the second assignment is tomorrow. Jordi logs into the virtual classroom to read the exercise. Then he looks for any content related to the topics covered in the assignment. It's 21h in the evening and Jordi must finish the assignment before tomorrow afternoon. To extract the maximum information in a short time, he accesses the video search engine and enters a few keywords. The search returns too many results so he chooses to view the videos with higher scores (NOTE: I assume we are talking about something like page ranking, e.g. the way google ranks the best search results first? It may be OK to leave this a little vague for now. -> and ranking as in YouTube) and quickly reads the annotations. He also sees the rankings of the videos, which shows the 'most watched' videos. Before deciding to watch a video, he reads its description. With all this information, Jordi chooses a video and begin working.
After working for a while, he decides to take a break for dinner. After dinner, he thinks, "I'd better get back to work!" Before leaving, he added a bookmark in the video to mark what he has left to see. When he gets back, he makes a filter to help him figure out what videos he has seen and which he has not seen. The next morning, Jordi is leaving for a business trip to Madrid. He decides to download the videos thet he hasn't seen the night before onto a mobile device so he can finish watching them during the train journey.
Commuting to the university
Yesterday Jordi studied until very late in the evening. He was looking for videos, and found one that he really liked. It was a recording of a lecture two semesters old that covers the subjects that he is currently studing. He was watching the video for a while, but it was late and he was tired. He put a bookmark to mark where he left off and went to bed.
Today he woke up early and took the train to school. The train is really packed, so he has to stand up all the way to the university. He takes his phone, opens the Matterhorn application and selects the video that he was watching last night from the list of his favorite videos.
He starts playing the video. It is one hour long. Since his commute doesn't take more than 20 minutes, he decides to go straight to the bookmark that he made yesterday and continue watching the video from there.
There is too much noise on the train and even wearing headphones, he is not been able to hear the lecture well. He actives the captions to help to follow the lesson and increases the size of the letters to see the transcription well. While viewing the teacher's explanation, he also looks at the power point. Additionally, as the screen is too small to read the text of the power point (it was designed to be seen on the screen of a computer, much larger), he activates the zoom.
He sees that a fellow student has added an annotation about what the teacher is discussing. He stops the video to read the note.
When he reaches the stop where he gets off the train, he adds a bookmark, puts the phone in his bag and goes to class. (NOTE: Again, all this bookmarking Jordi is doing I think was envisioned as being unnecessary, as the lecture should just start playing where the student left off when they return to the video. A scenario where a student might bookmark something would be more like when they want to mark something to review later, e.g. prior to a final exam. I think this is described as "highlighting" in Lisa's scenarios. -> we have to be careful, what is good for Jordi - to play just where he left off - is bad for other scenarios) USE CASES
Use Cases Diagrams from Berkeley research Mockups
MEDIA PLAYER MOCKUPS
Youtube Mockup
VirtPresenter Main Mockup
VirtPresenter Bookmarks Mockup
Prototype
MOCKUP - PLAYER PAGE
MOCKUPS - FLASH AND JS MEDIA PLAYER
MOCKUPS - MEDIA BROWSE AND SEARCH
Mockups - Media Search
Browse Page
User Story: 419 (As a learner, I want to see a list of all the recordings available and select one to play)
Search Results Page
User Story: 180 (As a learner I want to search through the existing media in the Matterhorn installation to find recordings that might be interesting to me)
Player Page
Not affiliated with a particular user story but included here as reference. This is what the user will see after they click on an entry from the Browse Page or Search Results Page
Search results
Player & Playlist with related videos
Browse Media
MOCKUPS - MEDIA PLAYER
Mockups Media Player
Play & Pause
User Story: 168 (As a learner I want to pause the video to have a break) User Story: 173 (As a learner i want to stop (recorded) media in order to switch to other recordings) User Story: 174 (As a learner I want to play the (paused) media to watch a recording)
Video Navigation
User Story: 420 (As a learner, I want to move the current time indicator to an earlier or later time in the recording ("seek") so I can skip over parts of the recording or review parts of the recording)
Time Navigation
User Story: 176 (As a learner I want to know how much of the media I have already seen and how much is remaining to estimate my position at the moment)
Scrubber Description
About Volume
User Story: 797 (As a learner, I need to change adjust the volume on my media player to listen at a desired level)
About Captions
User Story: 799 (As a learner, I want to view the captions for my audio/video so that I can follow the lecture)
Audio Player
User Story: 799 (As a learner, I want to view the captions for my audio/video so that I can follow the lecture)
Full Screen
MH 800 As a learner, I need to change my video size to full screen so that I can watch the lecture's details
Play and pause
Video Navigation
Time Navigation
Scrubber Description
Volume
Captions
Audio Player
Full Screen
BA-UX Admin App Admin App Use Cases Admin UIs Comparative Analysis of Administrative Applications Pain Points Past Relevant Work - Admin Mary Johansson - Podcast Administrator User Testing - Admin App Admin App Use Cases
Calendaring-related use cases:
Schedule all the lectures for a class that occurs on M,W,F from 9 to 10 Cancel one of the lectures for a course (because the professor will be away or exam taking place). Uncancel a lecture that has been cancelled. Specify system-wide exclusions (e.g. holidays). Schedule a day long event that has multiple parts. Schedule a week long event that occurs (mostly) at the same time every day. (e.g. typical conference set-up) Schedule recordings for an event that happens monthly Add an extra lecture (e.g. on a different date) to the course recordings Change time for one lecture Change location for one lecture Tell system to actually record a lecture that occurs on a system-wide exclusion date (e.g. prof wants to do a special event on MLK day) Specify recording profile for course. Change recording specs for a specific lecture. Send reminders to (admin, camera operators, ???) that their presence is required at a certain recording Put events into calendars of humans (e.g. admin, camera operators???) who are either required to be at event, or just want to know about it Enter start time and duration (don't have to specify end time) Enter a course-specific offset time (how much after the class officially starts/ends should the recording start/end) Enter a course-specific offset time (how much after the class starts/ends should the recording start/end) Enter a lecture-specific offset time (how much after the class starts/ends should the recording start/end) Export ical in order to import it into another calendaring system (e.g. a personal calendar) Tell system what locations are available and what the capabilities of those locations are Tell system default recording specifications for course or system Tell system specific recording specifications for courses or individual lectures within a course Delay publication of a recording for a specified amount of time or until a specified date
------
Add lecture titles to each individual lecture
------
Dashboard-related use cases:
Administrator follows progress (capture, processing, distribution...potentially even more detailed) Trims media Reviews media to make a go/no-go decision (approves for publication) See upcoming recordings (in a list or calendar format) See which recordings haven't succeeded/have succeeded Submit media file (in case of failure) Submit media file (in case of non-automated scheduled recording) See when a recording has started (whether automated or not) Check every webcast published that everything is okay EXAMPLES OF WORKFLOWS INSTITUTIONS MAY WANT
From Tobias:
Move ingested media and/or metadata to Podcast Producer or to a Sakai instance Ingest for captioning Ingest, encode and send to the uploader's home folder Ingest, inspect and archive
From Josh
Encode and Distribute (don't add to Search Index) Distribute only Encode only (The UI would provide a couple of input fields for encoding profile, email address, and maybe an "expiration". This workflow would take the uploaded media, transcode it (say from .mov to flash), and send an email to the specified address including a temporary link to the encoded media. After the expiration period, the encoded media is deleted and the link becomes invalid.) Admin UIs Admin App Conceptual Framework Post-0.5 Ideas Pre-0.5 Designs Proposals for the integration of workflows in the Admin UIs Release 0.5 Design ADMIN APP CONCEPTUAL FRAMEWORK
The conceptual framework for the Matterhorn 1.0 version of the Administrative Application is intended to suggest an initial information architecture and give a high level idea of where things may show up visually in the interface. By no means is it a final design - it will change due to feedback from iterative design & development, further input from the community, and the results of user testing.
The inputs that we've been analyzing and synthesizing include:
contextual inquiries with a many people both on and off the Matterhon project who are also current podcast system users comparative analyses of podcast systems user stories & scenarios written by the project team designs from the design studio in Zurich
These designs are intended to match the scope for Matterhorn 1.0 that has been established in the Roadmap (only user stories that have been scoped for year 1, as well as some Parking Lot items that we felt should be incorporated in designs because they would be problematic to incorporate later).
Design Goals
Easy access if used often, in direct view nothing important buried super deep keep the number of screens to a minimum Emergency situations displayed prominently/Timely alerts "Plain language" (Speak the user's language) Give them what they need and nothing more don't overwhelm remember year 1 scope/use design & development resources wisely Provide a UI that understands that the user may be multitasking
Conceptual Framework Designs Add New Course Add New Recording Add New Series Capture Agents Courses Dashboard UI Edit Recording Import iCal Recordings
Add New Course
Add New Recording Sketch 1--Separate boxes for Capture and Upload, Upload includes all multiple kinds of files Sketch 2--Capture and Upload combined, separate boxes for Attachments & Captions
Sketch 1--Separate boxes for Capture and Upload, Upload includes all multiple kinds of files
+ All files are uploaded in one place, easy to find where to upload files + Can always see schedule; when there's a manual upload of a scheduled recording, both "File Upload" and "Schedule" tabs may contain information. - It's not as obvious that there are 2 ways to get a recording in the system (upload & schedule) - Can't see as easily what file was uploaded as a result of the schedule
Sketch 2--Capture and Upload combined, separate boxes for Attachments & Captions
+ All different file types that can be uploaded are immediately clear + Simpler/shorter list of file types in the drop-down - Slightly more complex form, user must figure out where to upload each file - Can't see schedule and file upload function at the same time; when there's a manual upload of a scheduled recording, both "File Upload" and "Schedule" tabs may contain information.
Add New Series
Capture Agents
Courses
Dashboard UI
Edit Recording
Import iCal
Recordings All Recordings Upcoming Capturing Processing Distributed
All Recordings
Upcoming
Capturing
Processing
Distributed POST-0.5 IDEAS Confidence Monitoring Prototype
Confidence Monitoring Prototype
PRE-0.5 DESIGNS Ingester Scheduler
Ingester Ingester UI - v.1 Ingester UI - v.2 Ingester UI - v.3
Ingester UI - v.1
Discussion related to this mock-up should take place at: http://issues.opencastproject.org/jira/browse/MH-608
Future iterations of this might include metadata allocations related to the MH metadata scheme (work in progress, cf.http://www.sciencemedianetwork.org/wiki/Msc/P)
Further ingest information, such as
Authenticated personal information Publication date Un-publish date Deletion date Confirmation regarding copyright Access rules (take people from LDAP, enter e-mail, enter course from LMS) Distribution: Channels, quality
Ingester UI - v.2
Ingester UI - v.3
Scheduler Scheduled Recordings List UI Scheduler UI - v.1 Scheduler UI - v.2
Scheduled Recordings List UI
Scheduler UI - v.1
Work in progress
Scheduler UI - v.2
PROPOSALS FOR THE INTEGRATION OF WORKFLOWS IN THE ADMIN UIS
- The Matterhorn admin UIs (at least for the next few releases) will support preconfigured workflows only, so there is no support for "on-the-fly" creation or editing of workflows in the UI. Additional workflows can be created and installed by the configurer only. - Matterhorn (at least for the next few releases) will be configured out-of-the box to use just one workflow - There will be a documentation section in the wiki instructing configurers on how to create and install new workflows (including documentation on how to write the XHTML to be included in the forms) - *If* the configurer installs a second workflow, the workflow drop-down will show up and the admin will be able to select from multiple workflows. - When there's only one workflow that has been configured to be used by Matterhorn, the user will not be prompted with a workflow selection, so the fact that there *could* potentially be more workflows will be hidden from a UI perspective - Every workflow will come with its own configuration panel. (This may change in future versions, e.g. there may be configuration panels per operation.) - A workflow's configuration panel consists of a piece of XHTML and is embedded in the workflow definition file. - When multiple workflows are available, if the user selects one of them the UI will adjust the workflow configuration panel to show the configuration panel of the selected workflow. - Matterhorn's out-of-the-box workflow can include many different operations (e.g. hold for captioning, branding), almost anything as long as it ends in distribution. Then users can then make selections in the UI (e.g. using a checkbox, as the workflow selector is not needed here) to determine whether certain operations take place or not. These are just optional operations, not branches. - As a design principle, if a workflow branches (which means that it doesn't get back to the "default" execution path), it needs to be a separate workflow. thread here:
Scope
Q1 stories:
MH-574 As an administrator, I would like to upload a file, so that it can be processed an distributed.
MH-571 As an administrator, I would like to upload a recording & add metadata so that the necessary information is available for processing and distributing
MH-846 As an administrator, I need to schedule a single recording
MH-1271 As an administrator, I need a list of capable locations, so that I can choose the proper location and its inputs. MH-1272 As an administrator, I need to specify when recording happens for my scheduled recording. MH-74 As an administrator, I want to record my content in a variety of formats, so that they can processed for delivery.
Q2 stories:
MH-847 As an administrator I need to know the status of my capture agents
MH-754 As an administrator, I need a list of all distributed episodes to see what's complete and what isn't.
MH-1039 As an administrator I want to see a list of scheduled events
MH-1069 As an administrator, I need to edit information about a recording that's been scheduled but not yet captured, so that I can make sure it's correct.
MH-1260 As an administrator, I need to access current scheduled recordings to make further edits. MH-1257 As an administrator, I need to edit the schedule for an individual recording because the original schedule has changed.
Designs Capture Agents 0.5 Edit Recording 0.5 Recordings - Capturing (not for 0.5) Recordings - Failed 0.5 Recordings - Finished 0.5 Recordings - Processing 0.5 Recordings - Upcoming 0.5 Schedule Recording 0.5 Upload Recording 0.5 Upload Recording With Workflow 0.5 View Recording Info 0.5
Capture Agents 0.5
Edit Recording 0.5 Recordings - Capturing (not for 0.5)
Since code isn't in place to get info about the capture status of a recording, this page won't be delivered for 0.5
Recordings - Finished 0.5
Recordings - Processing 0.5
Recordings - Upcoming 0.5
Schedule Recording 0.5
Upload Recording 0.5
Upload Recording With Workflow 0.5
View Recording Info 0.5
Recordings - Failed 0.5
Comparative Analysis of Administrative Applications
In this section: Analyses of individual tools List of user needs for administrative activities Screenshots from various apps (no analysis) We will examine a number of webcast administrative applications (which likely touch on areas in Scheduling, Capture, Processing, and Distribution) in order to generate ideas for Matterhorn's administrative interface.
This activity should be "..focused..on usability and interaction design, with visual design also factoring in strongly. These analyses tend to be for web applications, which often have the most to gain from exploring how competitors approached a design problem or a user task/process." (from http://www.boxesandarrows.com/view/competitive_analysis_understanding_the_market_context)
We focused our analyses on those areas that were originally spec'd for Matterhorn year 1. See List of user needs for administrative activities
We ended up analyzing:
Replay Echo360 Panopto PuMuKIT Tel Aviv University's CMS
See Analyses of individual tools for the analyses.
Initial candidates for analysis also included:
Recollect VirtPresenter MediaVision Webcast.berkeley
Prior to conducting the analyses, but after we had seen demos of a number of applications, we uploaded screenshots. These can be found at Scr eenshots from various apps (no analysis) ANALYSES OF INDIVIDUAL TOOLS Echo360 Panopto's Course Cast - Comparative Analysis PuMuKit Replay Tel Aviv University webcast administrative tool
Echo360
Positives
Access via a UI to the logs for each capture device -- everything that has happened for that capture device (e.g. add tasks, upload content, create manifest) Can automate the recordings using the "Schedule" (not used by Nottingham) Ability to download media files from the Dashboard Ability to "reprocess media" that has already been processed Nice integrated Editing/Trimming interface Ability to restore edited media back to its original unedited state The boxes in the rooms look after themselves; they get an alert if there's a problem with the box. Alerts can be set (individually, for each alert type) to email someone (e.g. when encoding is finished) Reporting Summary reports which show "Most viewed courses" and "Most viewed presentations" Detailed reports (views by presentation, views by product, views by time of day, views by week of year -- can filter all by a date range) Allows addition of caption & transcript files On the newer version of Echo 360 the instructor will be able to preview the media in the room Instructors can start & stop the recordings themselves - faculty like having control, ensuring they aren't captured when they don't want to be They have a lectern computer connected to the echo capture device, or a lecturer could really connect their own computer if they wanted to Max. duration in schedule defaults is important in case faculty forget to stop capture When looking at the capture device you can see "next scheduled capture" Echo is extending the APIs to allow the ability to import timetable data Section security - there is a way on the form to restrict to the university of Nottingham, but you have to set up the groups; hard to restrict to a course since these aren't in LDAP The reports are helpful, mainly for views by presentation to find out how many people have viewed the lecture, especially at exam revision time. Admins send the pdf report to the instructor. Next version of Echo will have a link to a publication channel which is a commercial provider that provides a captioning service One of the strength of echo is that the device in the room is dumb and everything is configured on the server
Negatives
Strange use of the "Echo" terminology -- means recordings that have been processed Ad-hoc captures don't capture metadata--it must be entered later Ad hoc captures can't be initiated by the instructor unless another device is used (such as the AMX control panel--there is an API that can be used to connect it to Echo 360) There is no upload of media - can only process media initially scheduled on a capture device (e.g. reingest failed capture) Must manually process an ad hoc capture--likely because the system doesn't have enough data about how to process it to do the processing It's not clear what the difference is between archived and unavailable media Sometimes time codes aren't granular enough - can only edit out pieces by seconds In Monitor -> Processing Tasks you can watch it's progress as a file is being encoded, but must refresh page No confirmation when deleting an event from the schedule No control over bit rate & frame rate; must be adjusted by Echo360 - may be possible via undocumented XML config file, but not easy "ingest recovered capture" from the device itself is possible but "it's horribly complicated" Can't cut a presentation in two with edit; had to recover the presentation in order to do this Users must all be added manually - there isn't a way to hook up LDAP to Echo 360 now "Presentation Resources" only lets you add a closed caption or transcript file - rich media resource only. Can't attach the powerpoint or anything else. As it says "all files" in the file browser, hard for user to tell what file extension it needs. Can't do live streaming with Echo Biggest problem: cost. A few universities got around the cost by having just one unit. can configure a different unit to a different room. However, it's not a mobile unit though and it's not straightforward to move it around.
Form filled out outside of Echo 360 by instructors or members of departments to schedule a lecture. This info is then input into Echo 360.
Logs for each capture device
Editing/Trimming Interface Reports
Panopto's Course Cast - Comparative Analysis
File Modified
OpenCast-Comparative-Analysis-CourseCast.pdf Aug 01, 2009 by Will Monroe OpenCast Comparative Analysis CourseCast
Drag and drop to upload or browse for files
PuMuKit
(Note: too many screenshots to upload as one document, so divided into 2) Job Monitor (No scheduling):
Ingest:
File Modified
PuMuKit_ca.doc Sep 30, 2009 by Judy Stern does not cover Ingest, due to file size
PuMuKit_ca_part2.doc Sep 30, 2009 by Judy Stern covers ingest only
PuMuKit_ca.pdf Oct 13, 2009 by Judy Stern
PuMuKit_ca_part2.pdf Oct 13, 2009 by Judy Stern Drag and drop to upload or browse for files
Download All
Replay
File Modified
replay_ca.doc Sep 03, 2009 by Judy Stern
replay_ca.pdf Oct 13, 2009 by Judy Stern
Drag and drop to upload or browse for files
Download All
Tel Aviv University webcast administrative tool
File Modified
TAU_admin_ca.doc Sep 03, 2009 by Judy Stern
TAU_admin_ca.pdf Oct 13, 2009 by Judy Stern
Drag and drop to upload or browse for files
Download All LIST OF USER NEEDS FOR ADMINISTRATIVE ACTIVITIES
We're using the lists on this page as a guide for conducting our comparative analyses; these list the highest priority needs, functionality we want to make sure to provide in the administrative software.
Matterhorn 0.5
Capture/Scheduling
-add/delete/edit an individual event -add/delete/edit a recurring event -specify classroom (recording devices) -specify capture type (audio/video/screencast/etc.) -edit event title -edit information assoicated with event (TBD)
Job Monitor -success/failure/in progress of job (capture, encode, distribution, etc.) -capture device feed (ensure audio, video feed works)
Ingest manual upload of media (video, audio, powerpoint, etc.?) -manual upload of captions* -manual upload of metadata* -manual entry of metadata fields (TBD) -specify workflows (TBD. ex. chaptering + iTunes + video) -specify encode quality and types* -specify distribution channels* -specify branding* *could be abstracted as workflow type
(Note: source of above list is
More extensive list likely in scope for Matterhorn 1.0
--Manually enter an individual recording and necessary metadata --0.5 --Manually enter a recurring event (like a class) --0.5 --adjust start & stop times for individual or recurring recordings --Specify whether scheduled recording should be automatically captured, captured on site manually, or initiated by lecturer/presenter --enters exclusion dates for a specific course (e.g. midterms) --Specify capture type (i.e. video, screencast, audio) for individual or recurring recordings --0.5 --Login/Logout -- 0.5 --monitor samples of captured video and audio from a capture appliance as it's recording -- 0.5? --See successful start, in process, and stop of capture -- 0.5 --Control a room based camera remotely (? not sure this is a year one need) --monitor media feed connection status -- 0.5 --Access cached capture recordings from the capture appliance --put media into an ingest folder --0.5 --know the status of each recording (in queue, start, in process, and completion of encoding) -- 0.5 --Receive notification when there is an encoding failure --Split media into independent segments --Remove media segments from existing media --Replace existing media file with media file that I've edited outside the system --Add/Edit/Delete metadata associated with media -- 0.5 --Increase/decrease audio levels of an individual recording --Select specific audio channel from stereo recording for mono audio --View preview media --Add closed captions to a recording. --0.5 --Publish media/metadata to distribution channels --Unpublish media/metadata from distribution channels --View status (success, failure, in process) for publishing/unpublishing -- 0.5 --View storage status for distribution channel(s) (i.e. un/used storage). --Select distribution type (video, audio, screen) --Select distribution channel -- 0.5 --submit a time-coded transcript to Matterhorn -- 0.5 --View statistical feedback for each distribution channel (i.e. most viewed, most downloaded) --View statistical feedback for each recording (views/downloads by time/ day/week/year)
(Note: Source of above list is user stories from April 09 meeting, with a few additional provided by Sally. See
SCREENSHOTS FROM VARIOUS APPS (NO ANALYSIS) Scheduler Screens Confidence Monitoring Screens Ingester Screens Job Controller Screens ePresence Screenshots Capture Agent Status screens Log Viewer screens Trimming screens
(ePresence screenshots not divided by functional type)
Scheduler Screens Replay Overview Add an individual event for scheduled capture Edit an existing event for scheduled capture Delete an existing event for scheduled capture Enter metadata for event View event in personal calendar via (ical, google cal, etc.) Berkeley Webcast NG Add an individual event for scheduled capture Edit an existing event for scheduled capture Enter metadata for event View event in personal calendar via (ical, google cal, etc.) Panopto Echo360 Axis Scheduler
Replay Overview
Primary way that events get scheduled is automatically via course information system, but the following is used to schedule an individual event. Administrator starts by going to Scheduler Add an individual event for scheduled capture
On above screen, From and To fields bring up calendar widget when clicked. Location and Contact Persons fields are autocomplete based on entries already made in system. (?Or is Contact Persons connected to ldap?)
Edit an existing event for scheduled capture
Delete an existing event for scheduled capture
Enter metadata for event
View event in personal calendar via (ical, google cal, etc.)
Berkeley Webcast NG Add an individual event for scheduled capture
On above screen the unlabeled field with date in it can be edited directly or via the calendar icon. Defaults (not-so-intelligent, as they are current date and time) appear in fields when a new event is first created.
Edit an existing event for scheduled capture
Enter metadata for event
View event in personal calendar via (ical, google cal, etc.)
Panopto
No scheduling interface. Recordings must be started by pressing a big, red "Record" button in the user interface. Echo360
Axis Scheduler
This is a scheduler for their network surveillance cameras.
Confidence Monitoring Screens Echo 360 Berkeley Webcast NG
Echo 360
Berkeley Webcast NG
Ingester Screens Replay Overview Upload a video/audio file Manually enter metadata Tel Aviv University Admin Overview Upload a video/audio file Manually enter metadata Echo 360 Panopto PuMuKit Overview Manually Adding Metadata Upload a video/audio file
Replay Overview
To manually ingest media into system, administrator clicks on Schedule tab (not shown) and sees the following.
Upload a video/audio file
User clicks "Add local track", browses and uploads
Can edit the uploaded track
Manually enter metadata
Tel Aviv University Admin Overview
Workflow at TAU doesn't truly include concept of "Ingest", in that they do not have a podcast processing system. Instead they capture and encode in the classroom, then use what is essentially a content management system to upload video files and publish. However, we have included screens of the Upload process as these are the closest the TAU system comes to Ingest.
Here is the screen on which one does the upload and adds some metadata.
Upload a video/audio file
Manually enter metadata
Echo 360
Not available. Only ingests "recovered captures" (by the Echo 360 appliance) by submitting a "Capture ID"
Panopto
Not really available. They have a way of uploading recordings from the capture computer to the server, but this is usually done automatically (if the capture computer is online) and there isn't a way to upload media recorded outside the system.
PuMuKit Overview
Here we show the screens used in the PuMuKit Wizard, which is used sometimes for ingesting media. (There is also a "hard way" that is used more commonly, but it seemed important to document how it is done using the wizard, at least at first.) There are 4 steps clearly laid out in the wizard: specifying the series that the media is part of, adding metadata, uploading the file, and waiting while the file is transcoded. (For our purposes, we'll include specifying a series as part of metadata entry, and waiting for the file to be transcoded as part of the uploading step) Manually Adding Metadata
Upload a video/audio file
Job Controller Screens Replay Berkeley Webcast NG Panopto Echo 360 PuMuKit
Replay
Berkeley Webcast NG Panopto
The "Status" screen shows jobs that are in process or incomplete. Incomplete jobs after a certain time must be in error, though the system doesn't say this.
Echo 360
Unable to show screen at this time.
PuMuKit
ePresence Screenshots
A complete description of how to use the ePresence system is given on the hardware's documentation page (ePresence documentation). As there was no server setup I was only able to play with the capture hardware side of things. The following screenshots where taken during a simple test run of the system without pushing the data to a server.
Capture Agent Status screens Replay Webcast Berkeley NG
Replay
(UI's associated with Replay, not necessarily part of the Replay system)
Webcast Berkeley NG
Log Viewer screens
Apache Chainsaw a GUI-based Log viewer Trimming screens Replay Webcast Berkeley NG
Replay
Screen from Avidemux (tool they use at ETH for trimming):
Webcast Berkeley NG Pain Points
Administrator
manually quality check (I have to see a video, there is no notification service if something goes wrong) only manual publication of videos no self service for instructors Past Relevant Work - Admin Administrative Personas ADMINISTRATIVE PERSONAS Course Webcasting Administrator (UC Berkeley) Event Webcasting Manager (UC Berkeley)
Course Webcasting Administrator (UC Berkeley) Christy Hernandez, Course Manager Christy is a dedicated university employee that's been in charge of the Courses side of webcast for several years. Her great sense of humor helps her make light of a good deal of craziness that occurs on a near daily basis due to the quantity of classes that are now being webcast or podcast.
Christy knows off the top of her head every course that's being webcast or podcast and can invariably tell you who the instructor of each course is, sometime even providing anecdotal data about the instructor or class. After all, Chris is the one responsible for getting instructors to join the program at the beginning of each semester and ensuring instructors have provided all necessary information and permissions; this often means there's lots of email correspondence with instructors, which further adds to her knowledge of the university's offerings.
And Chris is proud of her relationship with the instructors that are webcast. No matter how many times she has to send email to remind an instructor that he needs to provide information to make the webcast happen, or how difficult it may be to satisfy idiosyncratic requests of the instructor, she keeps the tone of her voice or email correspondence friendly and professional, and makes every effort to make the instructors happy. No wonder there are so many repeat customers!
Chris cares deeply about the webcast program; she's proud of how many courses are being successfully webcast and wants to grow this number, even though the greater the quantity the more work she has to do on a daily basis throughout the semester. She's the one that's ultimately responsible for making sure each lecture is made available to the public in a form that's legal (no copyright violations) and of good quality (no audio dropouts, no dead space). She tries to chunk her work, so she's processing and publishing a group of lectures in sequence, but she's still working with the system for many hours a day (there are a lot of those chunks!) Even though she's trying to delegate to her student assistant some of the routine work of getting classes published, she's on top of every class, knows when it should be available on the public site, and still checks almost every webcast that's published to ensure that everything is okay; if anything goes wrong, she makes sure it gets fixed. Often, this means working after-hours and on weekends; while she knows that this is necessary to ensure that the webcast system is a success (a reliable and high quality service), she's frustrated by the amount of her own time it takes and wishes there was some way to change this. Christy's Goals
• Have things go smoothly • Make sure what's published is of highest quality • Have satisfied customers (good customer service) • Build good on-going relationships with customers • Grow webcast/podcast courses in quanity and diversity • Capture the "right kind" of courses.
Event Webcasting Manager (UC Berkeley)
Alex Hoffman, Event Manager
After taking on the Special Events side of the campus webcast program two years ago, Alex has turned a small post-production service into a thriving success. Throughout his 10 years of experience in video/audio production, Alex has developed strong opinions of "how to do things right." Alex recognizes the importance of the webcast program as a channel of free, public knowledge, as well as a business that must deliver quality content on deadline. Thousands of people view events a day, and the sponsors spend a lot money to deliver these events to the public. Alex understands that these events reflect the integrity and message of the sponsor and ultimately the university, and he takes great pride in being responsible for the end result.
Life can be hectic for Alex, though. If he is not putting out fires caused by bad content, on the phone discussing requirements with new clients, or responding to "last second" jobs requested through emails, he is managing students and figuring out ways to incorporate post-encode requests for failed course captures. To keep his head keep above water, Alex is always finding better ways to improve everyday operations and keep everyone happy.
Alex's students seek his expertise and leadership on a daily basis. His ability to work his way through problems, like unworkable audio tracks or demanding clients, has made a deep impression on his students. They can go to Alex when things go wrong. They appreciate Alex's mentorship and have taken on more responsibilities as they professionally grow. His management approach, through the use of schedules and prioritization of work, allows them to feel a sense of accomplishment and control, even when the work seems never ending. Alex's ultimate goal is not to waste time. There are only so many hours in the workday, and he does not want any hours taken away from his "other life", which is spent writing screenplays and shooting independent films. To ensure these worlds remain separate, he works hard to identify standards and best practices so that the service will eventually run itself.
Some parts of the process are entirely dependent upon Alex, though. Since he is the person who interfaces with clients, Alex must review the end product internally and with the clients to ensure its quality matches his and their standards. Although Alex uses the Webcast systems application sparingly, it is the eventually the home for most events. He does not find it particularly intuitive. Sometimes he forgets his workarounds or where to find previous events, and wished it would be simpler. Although the system is clunky, he appreciates having a database to store and publish events, since his last job didn't have anything. Although there have been some bumps in the road, he feels confident he is heading in the right direction. The opportunity to work with students and faculty and engage in interesting material makes these challenges worthwhile. Alex's Goals
Streamline workflow to increase efficiency Spend more time on actual content and decrease information gathering. Balance work life and home. Mary Johansson - Podcast Administrator
Draft document
Background Main Points "I take pride in ensuring everything goes smoothly for my customers." Age: 32 Technology level: Has developed a good understanding of the A/V world, but is not an A/V technician or programmer.
Mary has been working at Cobbler U for 3 years in the eLearning department, providing customer Goals service to instructors. When the podcast program began a year ago, she jumped at the chance to be the administrator--she was really excited about the potential benefits of lecture recording for Have their work go smoothly improving student learning, as well as the potential for opening up lecture content to others. As Make sure what's published is the Podcast Administrator, Mary enters all the information about lectures and events into the high-quality system, and makes sure that all podcasts are properly trimmed and distributed. Have satisfied customers As the podcast program is still small and certainly doesn't take all of her time, Mary also performs (good customer service) other administrative and customer service functions for the A/V department. Mary is savvy Build good on-going enough to manage the day-to-day podcast business - but she's surely not an A/V or IT expert relationships with customers (and definitely not a programmer!). Joel, their A/V technician (with whom Mary works closely), handles the equipment in the classroom and most of the day-to day issues that come up with Frustrations & Pain Points various devices. She'd love it if the system automatically notified them both if there was trouble, but at this point they are in a more reactive mode and usually fix problems after they discover From Clemens: Christy's work problems in a podcast. seems running smoothly. the only major critical thing I see Every semester Mary spends a half day inviting all the instructors in their equipped rooms to is "he's frustrated by the podcast their course. She uses an Excel spreadsheet to track the course dates & times, locations amount of her own time" and their responses. She refers to this spreadsheet at the beginning of the semester to know Perhaps we can collect some when captures are happening, but by a few weeks into the semester she knows the schedule by more details for loosing time: heart. manually quality check (I have to see a video, there is no Mary often has to answer questions from instructors about what it will be like to podcast, or how notification service if the process will work. She sees herself as an ambassador for the program and often has to something goes wrong), only reassure them that podcasting their lectures won't be embarrassing, or that students will still manual publication, no self come to class. Mary really enjoys helping the instructors, and always keeps the tone of her voice service for instructors ... or email correspondence friendly and professional. Sometimes she will get special requests from instructors, like wanting to podcast when the aren't in an equipped room. Mary always goes the extra mile to try to get them set up, whether that means helping them move to an equipped room Scenarios or even bringing equipment into the classroom for them.
Trim Media When Mary comes in in the morning, ideally she would make sure all the capture devices are online and ready to go. However, this is a convoluted process with their various "cobbled-together" systems – so she really only does it at the beginning of the semester. As the semester progresses and captures occur as they should, she trusts the system more and checks on things much less frequently. They do have a back-up system where just the audio is captured if the video-VGA capture fails, so she can use this in a pinch. Usually, though, this doesn't happen.
After Mary downloads & trims the files in a separate application, she puts them back into the system to be processed & distributed. She sometimes checks the media quickly for copyright violations, but as the instructors sign a statement at the beginning of the semester that they won't use copyrighted material, doing this kind of checking is an "above and beyond the call of duty" function which she doesn't always have time for. Occasionally she'll also have to make adjustments to the audio. At the end of each day, she checks their distribution channel to make sure all the podcasts for the day are available. Though it would be nice to have a place where she could see everything that's happening in the podcast system at once, what she really wants is a way to see when something has gone wrong and needs attention.
Add something about adding lecture titles
handling customer in non-equipped room - B, E ** backup systems (e.g. webcast), B, E ** not editing copyrighted material (put responsibility on instructor) - E, O ** memorize schedule in the end - look at it a lot in the beginning - E, B ** other people being notified when something goes wrong - B, E ** only want to know when things need action - B, E, O ** list of scheduled recordings - B, E ** editing outside the system w/other tools - B, E ** LMS as dist. channel - C, B, O - link in lms security by obscurity ** must convince instructors to do this - instructors are fearful embarrassed or worry that would be replacement for class - OBNC ** would be nice if professors could specify lecture recording titles time-consuming & can be hard to get metadata/lecture titles prior to publishing. MEOB
Christy knows off the top of her head every course that's being webcast or podcast and can invariably tell you who the instructor of each course is, sometime even providing anecdotal data about the instructor or class. After all, Mary is the one responsible for getting instructors to join the program at the beginning of each semester and ensuring instructors have provided all necessary information and permissions; this often means there's lots of email correspondence with instructors, which further adds to her knowledge of the university's offerings.
Mary is proud of her relationship with the instructors that are webcast. No matter how many times she has to send email to remind an instructor that he needs to provide information to make the webcast happen, or how difficult it may be to satisfy idiosyncratic requests of the instructor, she keeps the tone of her voice or email correspondence friendly and professional, and makes every effort to make the instructors happy. No wonder there are so many repeat customers!
Mary cares deeply about the webcast program; she's proud of how many courses are being successfully webcast and wants to grow this number, even though the greater the quantity the more work she has to do on a daily basis throughout the semester. She's the one that's ultimately responsible for making sure each lecture is made available to the public in a form that's legal (no copyright violations) and of good quality (no audio dropouts, no dead space). She tries to chunk her work, so she's processing and publishing a group of lectures in sequence, but she's still working with the system for many hours a day (there are a lot of those chunks!) Even though she's trying to delegate to her student assistant some of the routine work of getting classes published, she's on top of every class, knows when it should be available on the public site, and still checks almost every webcast that's published to ensure that everything is okay; if anything goes wrong, she makes sure it gets fixed. Often, this means working after-hours and on weekends; while she knows that this is necessary to ensure that the webcast system is a success (a reliable and high quality service), she's frustrated by the amount of her own time it takes and wishes there was some way to change this.
Scenarios
Trim Media: Trim heads, tails, and breaks in the middle in from the webcast a/v files.
User Testing - Admin App 0.5 Admin App User Testing - Paper Prototype Testing 0.5 Admin App user testing -- RC testing 0.5 RC Admin App user testing results 0.5 ADMIN APP USER TESTING - PAPER PROTOTYPE TESTING
Summary
List major findings here in a bulleted or table format for quick and easy reading. E.g. "2 of 3 users did/found..." Remove this note before publishing.
Finding 1... Finding 2... Finding 3... Test Environment and Process
The tests were conducted using printouts of wireframes (Balsamiq mockups) of the Release 0.5 Design, with post-it paper used to cover fields that already contained sample data in the wireframes. The version used for each test is that available on the date of the test (indicated for each user).
The users were presented with tasks (see next section) to complete. Tasks were presented one at a time. The testers read each task aloud. The user had a printout to which he or she could refer as she worked on the tasks.
The user was provided with a pencil with which he or she was instructed to "type" (really write) in various fields. When the user took steps that would change text in the UI, the tester would write out the text in the appropriate place(s).
The user was also instructed to use the eraser end of the pencil to "click" on buttons. The testers would swap in and out screens appropriately. In cases where no mockups were available (e.g. date/time picker) the tester would verbally describe what the user would see/what would happen.
Testing Tasks
Note: this reflects the current version of the testing tasks, including minor improvements in wording (to make the task clearer) made after individual tests.
Scenario: You are the Webcast Administrator at your university. You are responsible for ensuring that recordings go smoothly, take place as scheduled, and are distributed to various distribution channels (e.g. YouTube, iTunes, your local portal). It's Monday morning on the second week in the semester and your university is podcasting 40 different courses.
1) When you come in at 7:45 a.m., you take a look to see which recordings are coming up today.
2) Next, you do quick check to make sure that all the capture agents are online.
3) Check to see what recordings will be happening today in Schulte Hall (known as "SH1"), the room in which the capture agent failed last week.
4) You see that one of the recordings in Schulte Hall is about to start in a few minutes, at 8:10. You make a mental note to take a look when the 8:10 class starts to be sure everything is okay. In the meantime you check your email. At 8:15 a.m., you turn back to Matterhorn. Check to see what is happening in Schulte Hall.
5) You work on other tasks for a while. At 9:15am you turn back to Matterhorn to check to on the early morning (7:10-9am) classes . Figure out if everything is going okay for the podcasts for these courses.
6) You get a call from professor Stephen Shaw in Psychology. He would like to have his class recorded next Tuesday, October 30th, at 9 a.m.. (His isn't a course that's normally recorded, but there's a special guest speaker, Rosalind Mann, coming next week. Prof Shaw reminds you to make sure the lecture gets published so it can be found with the other lectures in the "Adolescent Girls" series, which already contains a number of lectures by authors who have written books on the challenges Teen Girls face.) You know that the room in which his course takes place is Schulte Hall, one which can be scheduled for automated recording, and can even include VGA output from the presenter's computer so you ask Professor Shaw if the speaker will have Powerpoint slides and if he wants those recorded along with the video of Dr. Mann. He says he doesn't think so, but will get back to you if he finds out otherwise. Set this up in the system.
7) Professor Shaw calls to let you know that his guest speaker will have slides, after all. He also tells you that he's remembered that she often speaks for longer than expected, and that he wants to make sure the recording continues until 10:30. (Fortunately no classes are scheduled for 10 a.m.) Make both changes.
8) Sitting on your local hard drive is video of a lecture from a few days ago: "Revolutionary Love and Martial Non-Violence" given by Sulak Sivaraksa. Your client, Graduate Minority Students' Project, is hoping you'll have it published by tomorrow. Publish this to the Matterhorn media module.
9) Verify that the "Gross Anatomy," a lecture in the "Human Anatomy 455" course, has been processed and published to your local portal.
10) View "A very special movie" which has been published to your local portal.
Interaction Notes
User Task 1 Task 2 Task 3 Task 4 Task 5 User 1 initially Went right to Capture Agents screen. wanted to be able to Repeated the task text out loud, Extensive pause here, 2009-11-18 unsure When saw that one capture agent was offline, wanted to see upcoming trying to figure out what to do (he and then said "I guess what see courses/recordings for that capture agent to know recordings for a was looking at I'd want to go back to "capture what recordings will be affected. capture agent from the Recordings-Upcoming where Recordings" agent" was When went back to Recordings page to get info about capture agent screen there is no status column); First considered but then what recordings would be affected commented that he had on eventually clicked on individual sorting by status (no deduced it to remember the offline capture agent's name from one Recordings-Upcoming, recording title (which brings up status column), then quickly screen to another (Tobias' suggestion about linking to needed to use sorting edit screen) thought to sort by date sorted by from an agent name to the agent on the Capture Agent to accomplish this task Appeared not to understand that (He was still not aware date, page would be nice to get in 0.5**) (in 0.5 - we don't want he was on the Upcoming page that he was only commenting he liked capture agent "capabilities" being listed ("oh cool") to scope sorting out) (this may have been due to the looking at Upcoming that it would fact that we had bad data-bad recordings) be nice if dates-on the mockups) After it was explained already Eventually went to Status page; to him (due to bad sorted that wanted to see "a preview window" data) that he was way (probably meant live feed) looking at upcoming would have (Note: we believe we should recordings only, he liked a filter rewrite this task so the goal is went to Recordings- by date more specific than "see what is Processing specifically happening in Schulte Hall") wanted to click on to see "processing failed" to today find out why it failed
Task 6 Task 7 Task 8 Task 9 Task 10
went to screen immediately no problem getting to Edit screen; no problem finding Started on Since thought for a minute about whether he should turned out that he didn't need to confused by "Subject," Recordings-Upcoming he'd include the Series title in the Title field make edits (due to how he had wondered if it was similar to "Has it been already after a while opened up add'l content descriptors filled form out when scheduling) genre. Says he usually processed and done questions about Subject (not sure what it was) but had no problem talking out depends on the client for that published?" (basically this made guesses (e.g. about duration, as it wasn't loud how he would do it. info. repeating the task out (clicked specified in the scenario) liked the "Back to Recordings" later said he felt compelled to loud) "local") Chose Audio & Screen option link fill it in (along with all other "Processed or for the On Confirm screen, wanted an Edit button fields) because he knows in published..." one in Confused at Confirm screen; couldn't figure out some systems (e.g. iTunes) it Took a while to figure #9, this how to leave it (Only link is "Schedule Another determines what category the out to go to was Recording". Tried to go to Capture Agents recording is placed in. Distributed where he obvious because it appeared to be only other option. Liked seeing both filename & said "It's there" (found to him Wrote in an "Ok" button. May need a "Back to title of recording in upload recording in the list) Recordings" link here.** ) progress indicator Then found "local" in the Distribution succeeded column and said "I guess so, then" Clicked "local" and when we confirmed that he'd be able to view the movie in the local portal, said "sweet"
Other comments from User 1:
would like to see Description exposed, not inside addl content descriptors says he'd like to see all fields on the forms, including Additional Content descriptors, open. Didn't like the way it "kept closing." wonders if Capture Agent tab is "Necessary" as he'd like to just be able to jump there from a link on a recording** would like to be able to filter by date: day, week, today, like a calendar (he uses both a calendar & list view when using a calendar in general) would like to be able to click on a Course title and see all the recordings for that course likes the filters in Recordings and says correctly that they are "status filters." Suggests he would use "Upcoming, Processing, Distributed, Failed" likes the idea of the All tab - often seems to want to see everything** likes YouTube approach to Series - which they call Playlists. It has a known list of playlists you select from. Likes the idea of being able to see all Playlists at once. Can add recordings to playlists only after the playlists are created and the recordings have been uploaded (can't do it in the edit screen). Can also get to each video from the playlist. One downside: would like to see what playlist each video is in, but can't as that info isn't available in the recording details in his current system he chooses Series from a dropdown; he sometimes he has duplicates of a Series that he entered by mistake (e.g. "Lunch Poems" vs. "The Lunch Poems"); system doesn't let him remove the duplicates and he dislikes this. Told us about how they like to upload media, but put a hold on the distribution until they've got all the metadata. Asked if there was a way to cancel an upcoming recording.** Told us that he "sometimes" has to drop everything to take care of a client.
** should we consider for 0.5?
Analysis/Discussion of Interaction Notes
Discuss any pertinent findings in the interaction data. If there are none then remove this section.
Analysis/Discussion of Interaction Notes
Discuss any pertinent findings in the interaction data. If there are none then remove this section.
Potential Design Improvements (based on testing) List potential and/or suggested design improvements here in a bulleted or table format for quick and easy reading. E.g. "Add "noon" or "midnight" above the text field when it is 12am/pm." Remove this note before publishing.
Improvement 1... Improvement 2... Improvement 3... 0.5 ADMIN APP USER TESTING -- RC TESTING Steps for facilitators 1) Prepare for the test: 2) Run the test: 3) Report your results: Supporting documents:
Steps for facilitators
1) Prepare for the test:
Schedule time with the user (1 hour is recommended) Print: 2 copies of Informed Consent Form 1 copy of demographic questionnaire (Optional) 1 copy of script for introducing the project and the procedure 1 copy of task sheets for facilitators (if you have more than one facilitator, you may want to print one for each) 1 copy of task sheet for user (For your convenience, all the above documents are also contained in the 0.5RC Admin User Testing Packet) Preparation of the test computer: WARNING: In the latest revisions of Matterhorn (e.g. I'm at 2582), the second demo/mock capture you run doesn't work--it just runs forever. So if you want to test to make sure demo capture works on your machine before you run the test, it is best to stop and then restart Matterhorn. Otherwise, the demo capture with demo_capture_agent may not work during the test. Download the Selenium IDE (it is a Firefox add-on): http://seleniumhq.org/download/ . You may also want to watch the short Sele nium 2-minute intro. Copy the video file your users will upload during the test to the machine's hard disk. Use file screen.mpg from here: https://issues .opencastproject.org/jira/browse/MH-2118 Add capture agents 127DwinelleHall, 250WheelerHall & 244WarrenHall by entering the following command (once for each of the 3 capture agents) at the command line on your computer. Examples: (if testing on local host) curl -d state=idle http://localhost:8080/capture-admin/rest/agents/127DwinelleHall (if testing on VM) curl -d state=idle http://
2) Run the test:
The following is an at-a-glance view of the steps you should take when running the test with a user. For complete, detailed user testing protocol see Admin App 0.5 User Testing Protocol--Incomplete.
Introductions: greet user, introduce the matterhorn project, explain procedure, have user sign consent form and complete demographic questionnaire, ask if they have any questions before starting
Remember to: make it clear that you are testing the system and not them.
Conduct the test: Present tasks one-by-one, asking the user to think out loud. (Place user task sheet in front of user, with another sheet covering any tasks not-yet-presented. Reveal tasks one-by-one as you you present them.) After each task, complete the faciltator task sheet for that task. Remember to: take notes or record what is happening not offer help unless they are really stuck (instead ask them: "What do you think you should do?", "What do you think that would do?", "What do you think that means?") not try to explain what the system is doing or why it is doing it not react, interrupt, or ask leading questions *try* not to interrupt what the user is doing with your own questions, unless you feel that it will be too late to ask at the end of the task.
Conclude the test: ask any remaining questions that you have regarding what the user did and why, and give them an opportunity to ask questions. Thank them! You may want to print out any of the recordings entered by the user for your notes.
3) Report your results:
Report results on 0.5 RC Admin App user testing results
Supporting documents:
File Modified
MatterhornUsertestingInformedConsentForm.pdf Jan 26, 2010 by Judy Stern
MatterhornUsertestingScript.pdf Jan 26, 2010 by Judy Stern
demographicquestionnaire.pdf Jan 26, 2010 by Judy Stern
opencast.mov Jan 28, 2010 by Allison Bloodworth
rc_usertesting_user-tasksheet.pdf Jan 29, 2010 by Judy Stern
rc_usertesting_facilitator-tasksheet.pdf Jan 29, 2010 by Judy Stern
rcusertestingpacket.pdf Jan 29, 2010 by Judy Stern
MatterhornUserTestingScript Jan 29, 2010 by Allison Bloodworth
Drag and drop to upload or browse for files
Download All
Admin App 0.5 User Testing Protocol--Incomplete
Adapted from http://wiki.fluidproject.org/display/fluid/User+Testing+Protocol and http://wiki.fluidproject.org/display/fluid/User+Testing+Tips
Instructional notes are in italics and preceded with theicon. Remove instructional notes and this note before publishing.
Reference: User Testing Protocol
Supporting Materials:
Add link to Prototype User Testing Demographic Questionnaire Add link to task sheets for facilitators, if used Add link to task sheets for users, if used Add link to Post-test Questionnaire Greeting script
Hi user's name. I'm your namewith the Opencast Matterhorn Project. Matterhorn is an open source project to develop an end-to-end, open source platform that supports the scheduling, capture, managing, encoding and delivery of educational audio and video content. Today we are looking for ways to improve the user experience of Matterhorn. This is a test of the system; we are not testing you. If you find something difficult to use, chances are that others will as well. This test of the system is simply a means of evaluating the system's design and to discover any issues we need to address.
If you feel uncomfortable you can stop at any time during the study.
Please speak all your thoughts aloud as you go through the tasks. This helps us better understand why you are making certain choices. The study will take about XX minutes. We will answer any questions you have at the end of the study.
Do you have any questions?
First we'll need you to sign this Consent Form.
Let's get started!
User Testing Demographic Questionnaire
Scenarios Persona/Role
Write out the scenario for each unique persona or role. This should be in a script format that can be read to the user during the test. Remove this note before publishing.
Scenario script. Tasks
Write out the tasks for each unique persona or role. This should be in a script format that can be read to the user during the test. Remove this note before publishing.
1. Task 1 2. Task 2 ...
Notes for Test Coordinator
Record specific notes for the test. This may refer to offering help, what to watch for, or other notable points during the test. Example below, which can be removed before publishing if necessary. Remove this note before publishing. Offering help during the test
Don't offer help; let the user attempt to perform the task themselves. If they ask for help reply with:
"What do you think you/that would do?" "What do you think that means?"
You want to observe whether the user has trouble:
Post-test Questionnaire
Link to and/or document the the post-test questionnaire below if one is to be used. Remove this note before publishing.
Have the user fill this out on their own before asking them the post-test questions below.
How easy or difficult was it for you to ...?
1. Very difficult 2. Difficult 3. Neutral 4. Easy 5. Very easy
Post-test questions (ask these verbally after the user has filled out the questionnaire)
Document post-test questions that are to be asked. Potential examples are listed below. Remove this note before publishing.
1. How easy or difficult was it for you to...? 2. Did you notice a visual cue for...? What do you think it is for? 2.
How helpful was it to you? 3. How did you know to...? 4. Was there anything confusing about...? If so, what? (If confusing) Are there any changes you would suggest to make it less confusing? 0.5 RC ADMIN APP USER TESTING RESULTS Process summary Results by Task Task 1: Task 2: Task 3a: Task 3b: Task 4a: Task 4b: Task 5: Task 6: Task 7: Task 8: Summary by Institution Recommendations for improvements to Matterhorn Admin App Short-term Long-term Recommendations for improvements to Protocol
Process summary
Process: Participants were asked to complete a number of tasks. See 0.5 Admin App user testing -- RC testing for the complete process the user testing facilitators (Judy/Allison, Jack, Sally) followed. There were 5 users who participated in testing at 3 institutions.
User Number Testing Date Gender Age Range Role Webcast admin experience
B1 22Jan2010 M 51 - 60 years Course-cast administrator yes. coordinate and manage over 50 video and audio podcasts per semester.
B2 28Jan2010 M 31-35 years Manager, Webcast program yes
T1 31Jan2010 M
N1 01Feb2010 F 35-40 years E-learning delivery group leader Not really
N2 01Feb2010 F 41-50 years Learning Support Development Officer No
Results by Task
Task 1:
You have just arrived at work.
Task: See which recordings will be happening for the rest of today, and which capture agents (named for the locations in which they live) will be used.
User Completed Facilitator observations User User thoughts Number difficulty task? rating
B1 Y immediately noticed "Upcoming" 10 "What to publish I assume is in finished," (user didn't understand immediately that it was already published.) "Capturing is happening now, processing is what it is doing -- uploading, encoding -- a separate failed is fine." "ooh this is nice" (said after clicking "Upcoming") very helpful to have presenter listed -- he has lots of courses to remember. felt "Upcoming" was "pretty descriptive," said it was "everything for the day" (it was just events for the current day in the display, so he may *not* be misunderstanding that it also includes future events) would be nice to have a way to look at just the current day likes the list format thinks font size is a little small but says he thinks "it's me" "seems very straightforward"
B2 Y immediately sorted by "recording date/time to see 8 He would really prefer to export today's calendar to an iCal feed he could place in what's happening first (shouldn't this be the default his personal calendar. Said he'd rather not have to go into this system at all to see sort). what's happening. He'd like to be able to filter the table so he could just see a specific day or date range. Thought it wasn't clear what the date range was for Recordings - Upcoming.
T1 Y I would like to have graphic tabs from which to select 9 "upcoming" N1 Y noticed 'upcoming' straight away and noted that none 10 Quite simple were for today. Then looked at Capturing to see if any were being captured now.
N2 Y Admin link goes to 'Upcoming' tab by default. 10 Guessing 'Upcoming' is a list of what's happening today. In FF 3.6 the arrows for sorting are almost over the end of the text of the column on the final column.
Task 2:
There have been some problems in the past with capture agents being offline. Task: Confirm that any capture agents you have are NOT offline.
User Completed Facilitator observations User User thoughts Number difficulty task? rating
B1 Y moused around for several seconds (starts in Failed) 10 liked seeing capabilities listed; thought it would be good to see selected before noticing Capture Agents saying "the way my eyes capabilties as well as status (e.g. offline) on Upcoming Recordings page go I don't always see it the first time." (important on anything that's failed). Would like the tabs to be more prominent -- suggested different color tabs to be able to see them better. Also talked about how important it would be to have email notification go to operations staff (who could check on what's wrong with capture agents and restart them themselves)
B2 Y went to Capture Agents tab right away 9 "One capture agent is idle, 3 are online, do I have to submit a JIRA task.? (user seems to think idle means it's not working.) Would really like to see a live preview of what's happening in the room integrated into the "Capture Agent" screen, especially if there is trouble where it's idle or the recording has failed. He suggests that a pop-up might work. If a capture agent is offline, he'd like to know how close to the next recording it is, what are the upcoming recordings.
T1 Y found right away the "Capture Agents " tab 10
N1 Y noticed Capture Agents tab immediately 10 Idle presumably means 'not offline' - What would you do if they were offline though?
N2 Y Very quickly found Capture Agents tab. 10 I'm looking at capture agents - they are all online but idle.
Task 3a:
Sitting on your local hard drive is a video file of a lecture from a few days ago. (Facilitators will tell you where to find the file.) The lecture was called "Revolutionary Love and Martial Non- Violence" and it was given by Sulak Sivaraksa. Your client, Graduate Minority Students' Project, is hoping you'll have it published by tomorrow. (This lecture has not been entered into the system in any way.)
Task: Do whatever you need to in order to publish this to the Matterhorn media module.
User Completed Facilitator observations User User thoughts Number difficulty task? rating
B1 Y First went to find the file on the local hard drive and selected it (then explained that he expected to have 10 Commented that he wasn't sure to drag for file server somewhere, which is what his current practice is). Finally went back to Admin app what the differences were for and saw and clicked on "Upload Recording". Didn't notice "Additional Description" until we asked him to "Media File Content" dropdown. put in Subject (this was facilitator nervousness, forgetting that I had a separate task that required him to open "Additional Description"--jls)
B2 Y User didn't think it was clear in the task whetehr it's something that had been already scheduled and put 7 When told typos are OK, he in the system, so he first looks for the recording in "All" and "Upcoming." When he figures out this is not says "But I'm a perfectionist!" the case, he immediately goes to "Upload Recording." Easily enters all info (including things in Additional (persona info) Description), but was confused at first about wat License was. Later (during next task) sees that it's in the User didn't notice "Uploading" Distribution box, so he realizes what it means. notification bar as the file he . uploaded went up so fast. Asked and asked that we make sure to provide a progress indicator--important feedback for large files. User said he might want to edit the file after it was uploaded. Suggests he'd like to send links to a recording's sponsors which allow them to fill out metadata for their recording
T1 Y I noticed some hesitation while filling in uploading form 9 The test form metions a "client". The upload form has a "Sponsoring Department" field. I would expect more consistency in the terms so as not to have to assume that the client is the sponsor.
N1 Y Hesitated on 'Licensing' - not sure what to put here or if mandatory (star is in this panel). Uploaded file 8 Not sure about license field easily N2 Y Hoverd over license - 'no idea' chose help, but it is not that helpful. 'still no wiser' 8 Is 'client' the same as 'sponsoring dept'?
Task 3b:
You know that it will take a short while for the system to encode the file. Task: Confirm that the file is being encoded.
User Completed Facilitator observations User User thoughts Number difficulty task? rating
B1 Y He went to Recordings-Processing but file Likes the metadata and "Additional Description." was done processing before he got there. Then went to Finished.
B2 Y User goes to processing before we'd even 10 User is again not happy he can't edit after upload. Says he'd like to check with client and add read the task (seems like the natural next client's info about subject, langauge, etc. before it publishes. Since encoding takes a long step for him), saying "I'm doing whatever it time, he doesn't want to have to wait until he has this info to start this process. Says there's takes to make sure the system publishes an "assumption that I'm ready to publish when I upload and that's rarely the case." "It was so it." fast, I couldn't edit it." Wants a step in the workflow where he gives the final okay to go ahead and publish. "Now that it's done, I'd like to be able to link to right where it is." "In our system, I'd like to verify that it encoded before it posts" (to a distribution channel). "It's super-fast, a high peformance system."
T1 Y he was expecting some feedback about 9 A progress bar indicating the remaining time would help the remaining time of processing
N1 Y Was not sure if it would be moved once it 8 I am not sure I would then look in Processing - would probably expect to see a tab called is done. Assume it will finish processing at 'uploads' instead some point, but no indication how long it might take.
N2 Y Goes to 'Processing' straight away. looks 10 Progress bar would be useful. No idea how long it might take to complete. I'd also like to for further information on this page know when it was uploaded so I know how long it has been in this 'Processing' state.
Task 4a:
You get a call from professor Stephen Shaw in Psychology. He would like to have his February 3rd class (which is in 127 Dwinelle) recorded. It starts at 19:00 (7pm) and ends at 20:00 (8 pm). His isn't a course that's normally recorded, but there's a special guest speaker, Rosalind Mann, coming next week, and she'll be giving a talk on "Adolescent Psychopathology". Prof Shaw reminds you to make sure the lecture gets published so it can be found with the other lectures in the "Psych Talks" series. When you ask Professor Shaw if the speaker will have Powerpoint slides and if he wants those recorded along with the video of Dr. Mann, he says he doesn't think so, but will get back to you if he finds out otherwise.
Task: Set this recording up in the system. (Please don't worry about precise typing; typos are fine for this user test.)
User Completed Facilitator observations User User thoughts Number difficulty task? rating
B1 Y Some mousing (and clicking) around before finding "Schedule 9-10 "I assume this is always AM as there is no AM/PM." Recording" (starts in "Recordings"). "As long as you can add (info) after you've already created (a Put series name in Title (but this was based on an earlier version of Recording), I think that's fine." the task in which we didn't provide a title) "Input is pretty straight-forward." Provided data for all visible fields (even if he wasn't provided with data, e.g. "license"), has no problem with "capture agent" field. Right before he submits, clicks "Additional Description." Looks at confirm message.
B2 Y User first goes to "All" then "Upcoming" (seems to be looking to make 6 Doesn't like the audio, video, screen options as he asys audio is sure this recording isn't already there) then right to "Schedule assumed. Suggests checkboxes instead. Recording." Comments that "Additional Description" doesn't need to be so User mouses over Help and the "Click for help" tooltip comes up, but hidden as "you will almost always have a description." he doesn't click on it (may not have noticed it). Comments that events & courses are different. Thinks this task is User goes back to "Additional Description" to enter Series, Subject & more like a task for an event than a course as it is a series. language after entering everything else. "I'd infer that the Psych Talks series exists." Would be nice to User easily finds & uses "Back to Recordings" link. have an auto-fill or drop-down (otherwise risk is that they'd be creating different versions of the same series), but that would be a really long dropdown for us. Would be nice to set a default for language as it's always English for us. Also would be good for institution to set default license. Was unclear to user whether the recording would start at the exact time he specified, or if there was any kind of buffer. Said in a real situation, he would have set the time to be earlier.
T1 Y 7 Confusion in terms. There is a title field and a subject field. Are they the same? Also, the actual presenter is a guest speaker of the course lecturer. What is the proper way of specifying this in the form? Free text?
N1 Y Went to 'Upcoming' tab, but found 'Schedule Recording' pretty quickly. 8 I had to look back at the question to see if it should be Did not seem to see 'Additional Description' option audio/video/slides. It's a bit confusing when there is already a recording listed under 'upcoming' with the same details.N2 N2 Y Found 'schedule recording' very quickly. Not sure where to put the 9 You need to enter Psych Talks somewhere so that if someone is series info. Found 'Additional Description' while looking for this. Chose looking for all the recordings in that series you can search on this. to choose audio-video-screen in case the user came back to change it.
Task 4b:
Professor Shaw calls to let you know that his guest speaker will have slides, after all. He also tells you that he's remembered that she often speaks for longer than expected, and that he wants to make sure the recording continues until 20:30 (8:30 pm). (Fortunately no classes are scheduled for 20:00.)
Task: Make both changes (slides recorded AND later ending time).
User Completed Facilitator observations User User thoughts Number task? difficulty rating
B1 Y User is already in Upcoming and clicks to edit recording. He easily changes 10 User liked the mouse-over on "Edit Recording." the time and had already set audio, video, screen so no changes are needed there.
B2 Y Clicked on the Recording, added screen and added 30 mins to duration. 7 "I only gave it a 7 because I'm unclear on the buffer time. Plus I don't like the radio button choices for Audio, Video Screen. Otherwise it's really easy."
T1 Y He moved with the mouse at the bottom of the list for the new record until 9 The task description shows relief that there are fortunately finnaly found it at top no classes scheduled, so the existing lecture can be extended. Can this system do a "double booking" by mistake, or does it have the capability of preventing such a confusion from taking place?
N1 Y Didn't notice Additional Details so could not see where to put the Psych 10 It is not very intuitive to have one field hidden for no obvious Talk information in the form. Queried why this part of the form is hidden. reason.
N2 Y looked in 'Upcoming' - it was not clear which was her recording as others 10 It is fairly obvious that you need to click ont he recording with the same name were there, assumed it would be the top one on the lsit name to edit it. as the most recently added, but this was not the case as the start time was earlier. Clicked on recording name to edit without hesitating
Task 5:
You want to know which recordings have successfully been distributed today and which haven't. For any recordings that have had a problem, you want to notify the sponsoring department.
Task: for recordings that haven't been successfully distributed, get the sponsoring department(s) name(s). Also, check to see which recordings have finished.
User Completed Facilitator observations User User thoughts Number task? difficulty rating
B1 Y Immediately looked at finished. 9-10 I'd like to be able to email the sponsoring department that it's published from the app. (Need sponsoring dept email.) Think I'd like to compose the email myself unless there were two or three canned emails I could send. The email should include a link to the recording.
B2 Y Goes to "View Recording" and looks at sponsoring 5 "It's frustrating that there's no contact info associated with these recordings." department. There were no recordings in Failed due to testing setup error, but also goes to "Failed" to see what failed and says, "that part is a 10!"
T1 Y The Sponsoring Department meta data didn't appear 10
N1 Y Easily found failed and finished recordings. No sponsoring 10 The recordings were where I thought they would be. I checked in finished, Dept metadata on test recording - if the data were there it but no date so I don't know if they were today or not. would have been easy for her to find.
N2 Y Looked in finished and found the list of successfully 10 It would be ok if the informationa bout the sponsoring department was there. distributed recordings. found the one that hadn't under 'failed' Could not find any sponsoring information so did not know what to do now.
Task 6:
You have just received a call from your university's president. A major political figure is visiting and is about to make a quick announcement, which the president wants recorded. Fortunately the announcement will be made in a room where you have a demo capture agent set up.
Task: Set your demo capture agent so it records starting as soon as possible and so that the recording lasts for 5 minutes.
Note: This task was not given to most test participants because the demo capture agent was not working at the time/location of the user test. User Completed Facilitator observations User User thoughts Number task? difficulty rating
B1 n/a
B2 Y User cannot enter a time that will allow the recording to start immediately. Says, "it's 3:09 8 User thought "as soon as possible" was so I'll enter 3:15 since I don't know if I will have time to update it." User wanted to put in ambiguous in the task, and Judy explains that 10 minute duration but Judy asks him to put in 5 so the task will complete in time. the recording will start "any minute." "Because the task doesn't give the type of recording, I'll enter audio, video, screen." "I was confused earlier about license because the "Distribution Channel" label wasn't obvious to me (because it's already checked). I see now it's related." "We have 42 rooms, so a pull-down list (for capture agent )would be cumbersome."
N1 n/a
N2 n/a
Task 7:
Since you had problems with the capture agent in 250 Wheeler Hall yesterday, you'd like to take a look and see what classes are scheduled in that room today. You know that Dr. James Klondike gets very upset if he has any problems, so you hope he isn't teaching in that room today!
Task: See what classes are scheduled in 250 Wheeler, and whether Dr. Klondike is one of the instructors in that room.
User Completed Facilitator observations User User thoughts Number task? difficulty rating
B1 n/a
B2 Y User goes to All, Upcoming, then sorts by Date/Time and looks 4 Would like to have the ability to search the page and limit the recordings for 250 Wheeler to see if Klondike is in there--and he's not. to a certain date range. "I could also have sorted on Presenter." Because each line is spread across the page, it's hard to follow the lines. A rollowver highlight would be nice.
N1 Y Fiirst looked in 'capture Agents' for this information. Once found, 6 Think that I would first look in 'Capture Agents' for information about sorted the list ok what is scheduled for that agent. On sorting, commented 'That's quite handy'
N2 Y First wen tto capture agents tab. Clicked on 'capture Agents' 10 If you had hundreds of items and lots of rooms it would be quicker to go header to sortand noted that problem user was in list for that tothe capture agent for this information. room.
Task 8:
You want to be sure that everything is going okay with the 5 minute recording you scheduled (prior to checking on Wheeler Hall)
Task: Find out what's happening with your recording (warning: due to a bug in the system it will be called "Opencast Sample Recording"; don't worry about this.)
Note: This task was not given to most test participants because the demo capture agent was not working at the time/location of the user test.
User Completed Facilitator observations User User thoughts Number task? difficulty rating
B1 n/a
B2 Y User goes to "Capturing" tab. Clicks on it multiple times and doesn't seem 4 Would like to see an "under construction" graphic on the to see message to go to "Capture Agents" screen, but comments "Can't non-working screens. The "X" on the Capturing tab is do...only I can do is got into capture agents". Goes to Capture Agents page. confusing...maybe change it to "coming soon." Having it be a After moving around, goes back to "Capture Agents" page and sees the live link is frustrating to the user--users may become recording is still capturing. User doesn't notice it for the short time it's in desensitized and learn *never* to go to these pages. I give it processing, but does notice it in Finished and clicks on it to see the details. a 4 because I have to remember from the Recordings screen to the Capture Agent screen what capture agent is recording.
"Is it bad that I choose screen & video and there may be no screen? There could be a big blue screen next to the visiting politician." User wonders, "where can I see it?" (the video)
Summary by Institution Institution Top issues/summary Additional comments
Berkeley Both participants completed all tasks without any major problems. Large concern voiced by both participants about media going thru to distribution without any human giving an "okay to publish" action or ability to add/edit metadata. Wanted assistance (auto-complete or drop down) on a number of fields (series, license), plus wanted there to be institutional defaults (license, language). Both wanted to be able to filter by date, especially on Upcoming page. Both wanted add'l info on Capture Agents page (confidence monitoring for both, plus one wanted info about next recordings for capture agents and one wanted to know what inputs were being used for a recording).
Nottingham no feedback about the progress of the encode at minimum the date/time it started so you can tell how long it's been there, but preferably a progress bar; upcoming list needs to be able to filter, not just sort. Capture agent status says "idle" it should perhaps be called ready; hidden description field (sally thinks you'd get used to that and don't necessarily want to always fill something in there{}e.g. it can be hidden if it's part of a series{}one tester did miss it completely; going to capture agents doesn't give you much info. Currently just the list of capture agents and whether they are idle, would like more info about the capture agent.
Tel Aviv test was well-designed. Doing the test helped me learn about Matterhorn. My colleague who was simulating the user thought that scheduling was a problem. He is used to working with Google calendar or iCalendar. He'd like to choose the date & time first, then add the metadata. Department & sponsoring department. When he added one recording at the beginning he was looking at the end of the list for the new recording. In the future we need to have basecamps/testing environment ready in the future. In the future the tests should perhaps be simpler and easier to read since not everyone is a native speaker. Judy suggests that maybe we could help Jack or others translate tests in the future.
Recommendations for improvements to Matterhorn Admin App
Short-term
recommendation based ticket that fixed? on addresses
Add explanation of the date range of "Upcoming" B2 MH-2429 y
Add filters for Recordings screens (show only today, show date B1, B2 range)
Don't use "Idle" as term for a capture agent that's okay, since B2, N1? MH-2593 Discussed in BA/UX/UI meeting 4Feb10: we liked the term "ready", rather than "idle". users may interpret Idle as a negative term or not be sure of (Didn't want to use "online" because the agent could be connected to network but not what it means capable of capturing.) May want to confirm with capture team what full set of reportable statuses is.
Add Search on Recordings pages. B2 MH-2561
Show capture agents' selected capabilities on Recordings B1 MH-2578 pages
Add a way to see the time of the next recording on the Capture B2, N1, MH-2580 Agents page (especially if a capture agent is offline) N2
Add explanatory text that says metadata cannot be edited after B2 MH-2419 y uploading a recording.
Add "hold prior to distribution" asap and allow editing of MH-2566 metadata (or killing recording) while in that state.
Add link from Recordings-Finished to recording on distribution B2 In designs. channels MH-?
Make sure users know that currently the recording will be B2 MH-? (I ? published right after they upload. thought Allison put in ticket for this)
Switch to radio buttons for capture agent input values B2 MH-1346
Reconsider whether "Additional Description" should be hidden. N1 Discussed in BA/UX/UI meeting 4Feb10: as a default this can remain hidden, but needs to be configurable.
Get enumerated list or auto complete working in several form B1, N1 fields (License was particularly problematic)
Allow configurers to set defaults for metadata in the UI B2, N1 (Language & License were 2 identified in this round of user tests)
Allow configurers to specify which metadata fields are shown & T1, B2, which are hidden (under Additional Description), which fields N1 are required and which are not, and the labels for the fields
Add text to Start Time help that explains there is no buffer B2 MH-2421 y
Add Sponsoring Department email or contact info field B2 Discussed in BA/UX/UI meeting 4Feb10: this is not DC metadata, but we could have institutional metadata fields. Gen'l agreement that a field for contact info could be helpful (though ideally it would be provided via integration with other campus systems) Allow user to enter Start Time of "Now."
Add a highlight of each line on rollover so it is easier to read B2 MH-2430 y left-to-right
Add an "under construction" graphic on the non-working B2 MH-2422 screens
Reconsider "X" # of recordings on "Capturing" tab. B2 MH-2422
Add information to the Finished tab stating that recordings can MH-2429 be found in the Matterhorn Media Module
Make labels the same on the Welcome page--why do we say both "Engage Tools" (heading) and "Distrubution Modules?"
Consider adding capabilities and status to the Recordings page, especially Failed
Show how long recording has been in processing N1 MH-2598
Make sure to prevent conflicting recordings i.e. T1 MH-1253 "double-bookings"
Long-term
recommendation based ticket that fixed? on addresses
Allow for specifying "guest lecturer" for a specific lecture in a course T1 (we need to wait until we have recurring events in place for this to make sense)
Allow user to export upcoming recordings to a personal calendar/provide iCal feed B2
Progress bar to show how much processing has been done. T1, N1, N2
Progress bar to show how much of the file has been uploaded.
Allow users to edit recording metadata during or after uploading B2
Send links to a recording's sponsors which allow them to fill out metadata for their recording B2 probably should be "short term"
Allow configurers to set a recordings start time buffer globally B2
Email notification to designated staff re. offline capture agents B1
If we go for dropdown for Capture agents, think about control that'll work better for B2 institutions with large number of capture agents
Recommendations for improvements to Protocol
Use either "idle" or "online" as a label for capture agents that are 'ready to go,' but not both - TEST PROTOCOL Make task 3a clearer that it's a new recording, not one already in the system - TEST PROTOCOL --FIXED in Test Protocol after B2 User thinks "as soon as possible" is ambiguous in task 6. Change it to "now." Release Management
Figure 1 (above): Release Management Flow
Figure 2 (above): Branching and Merging
Release Process
CODE SLUSH
30 days before the anticipated release date, code enters slush state. During this time only following changes should be made Bug fixes Documentation updates Security related fixes Changes deemed urgent by the team
WIKI PAGE
For each release, create a new wiki page with release specific information and content of following files: README.txt RELEASE-NOTES CHANGES
CODE FREEZE 15 days before the anticipated release date, code enters Freeze state. No changes will be made to the branch during code freeze.
RELEASE CANDIDATE
Create svn branch for release candidate. For a Major/Minor release, we would branch, so that we can continue development on that as a separate path. Release 0.5 would be a branch, as we continue development on the trunk. Later we may need to fix some issues in version 0.5, and provide patch releases (0.5.1 and 0.5.2 and so on...); 0.5.1 and 0.5.2 would be tags.
CHECKOUT RC
Checkout a fresh copy of the release candidate.
UPDATE VERSION INFO
Use script to update version number in poms and ____. (Need to list files here and develop script).
UPDATE FILES FROM WIKI
Update the content of following files from the release wiki page README.txt RELEASE-NOTES CHANGES
VERIFY LICENSE HEADERS
Use rat:check maven plugin?
VERIFY BUILD
Link to build instructions here
CREATE ARCHIVES
Create following product distribution archives. Linux (.tar.gz) Mac OS (.dmg) Windows (.zip)
GENERATE HASHES gpg --print-md MD5 xxx.tar.gz > xxx.tar.gz.md5 gpg --print-md MD5 xxx.zip > xxx.zip.md5 gpg --print-md MD5 ./RELEASE_NOTES-x.y.z.txt > ./RELEASE_NOTES-x.y.z.txt.md5 gpg --print-md MD5 ./README.txt > ./README.txt.md5 gpg --print-md MD5 ./NOTICE.txt > ./NOTICE.txt.md5 gpg --print-md MD5 ./LICENSE.txt > ./LICENSE.txt.md5 gpg --print-md MD5 ./DISCLAIMER.txt > ./DISCLAIMER.txt.md5 gpg --print-md SHA1 xxx.tar.gz > xxx.tar.gz.sha1 gpg --print-md SHA1 xxx.zip > xxx.zip.sha1 gpg --print-md SHA1 ./RELEASE_NOTES-x.y.z.txt > ./RELEASE_NOTES-x.y.z.txt.sha1 gpg --print-md SHA1 ./README.txt > ./README.txt.sha1 gpg --print-md SHA1 ./NOTICE.txt > ./NOTICE.txt.sha1 gpg --print-md SHA1 ./LICENSE.txt > ./LICENSE.txt.sha1 gpg --print-md SHA1 ./DISCLAIMER.txt > ./DISCLAIMER.txt.sha1 gpg --armor --output xxx.tar.gz.asc --detach-sig xxx.tar.gz gpg --armor --output xxx.zip.asc --detach-sig xxx.zip gpg --armor --output ./RELEASE_NOTES-x.y.z.txt.asc --detach-sig ./RELEASE_NOTES-x.y.z.txt gpg --armor --output ./README.txt.asc --detach-sig ./README.txt gpg --armor --output ./NOTICE.txt.asc --detach-sig ./NOTICE.txt gpg --armor --output ./LICENSE.txt.asc --detach-sig ./LICENSE.txt gpg --armor --output ./DISCLAIMER.txt.asc --detach-sig ./DISCLAIMER.txt
DISTRIBUTE FOR VOTING
Create a directory for distribution of the RC for voting. http://releases.opencastproject.org/dev/
CALL A VOTE
Send email notification to developers for voting on the release candidate All negative votes must include justification All negative vote issues must be resolved or appropriate documentation included MERGE BRANCH WITH TRUNK
(Once the release has been blessed, we can merge the fixes from the branch with the trunk)
MOVE THE BRANCH TO TAG
(List instructions)
PUBLISH RELEASE
Given no negative votes, publish the release http://releases.opencastproject.org/public/ (List steps)
NOTIFY
Send notification via email and other channels regarding the new release. (Enumerate all new-release notification channels and include sample messages here) Managing Releases
1. What is Release Management?
Release Management is the process of building, packaging, and deploying of software for consumption. Many projects think they do not need to make releases until they are complete, this is not the case, as discussed in ReleaseEarlyReleaseOften.
There are a number of roles in the release management process. In an early stage project it is likely that these roles will be carried out by a single person, however, as a project matures they can be separated out and delegated to different team members. This document discusses the roles in isolation in order to facilitate this.
It is a process that is controlled by a Release Manager. A Release Manager is:
Architect - helps to identify, create, and implement the release process Manager - of the release process Facilitator - is the liaison between all stakeholders in a release
The stakeholders in a release include:
Developers of the software Quality Assurance engineers Users of the released software Press and marketing contacts
2. Process Overview
making a release has legal consequences users tend to interact with a project through its releases
Software releases require much more process than many other activities in software development. Process is necessary to ensure that all legal issues are addressed and that the quality of a release is sufficient be useful to users. This does not mean that a release must be complete (what software ever is) or that it must be bug free (yeah right!). It merely means that each release is well documented with respect to its status and users therefore know what they are getting.
Building a version of the software to be considered for release should be a fairly easy process since the software build ought to be an almost fully automated process. However, some aspects of the release build process will be difficult if not impossible to automate.
There are likely to be multiple release candidates packages, for different platforms.
Each release candidate is identified by a version number.
Before becoming an official release a build of the software will undergo a phase of prerelease testing. Often the package being tested will be indicated in the version number, for example, it may be designated as a release candidate with the letters RC1, for release candidate one.
Once a release candidate has been fully tested it will be approved for release. This approval process will be dependent on the governance model adopted by the project.
Signing of the release package. Users need to be assured of the integrity of the downloaded package. Therefore the release should be signed.
Once a release has been approved it must be made available to users via the projects distribution channels. These channels should be capable of handling the expected demand for the release.
Of course, making a release available is not enough. They must be made aware of the new release via news announcements.
3. Best Practice 3.1. ISSUE TRACKER
The list of open issues needs to be analysed prior to release. Decide which issues will be resolved in this release and which should be moved to a later release. Do not attempt to fix all issues in any given release. This is a sure way of ensuring the release never happens. Any issues that are to be delayed should be moved to a later release in your issue tracker so that a known issues list and a roadmap for the release can be created. If the issue had previously been scheduled for this release you should record this in your release documentation so that users will get a clear indication of slippage in the schedule.
Remember slippage of individual is not a bad thing, it is clear indicator to your users about what they can expect in the next release. This is open source, if a user wants to see an issue fixed in time for the next release they should provide a patch. By clearly indicating that the active developers will not address any given issue in a given release users can decide just how important it is to them and, where necessary, provide additional resources to the project.
The review of issues should not be limited to the run-up to release management. It should be a part of the daily routine of software development, however, in the run up to a release it is sensible to review issues in order to ensure the release will ready on schedule.
3.2. DOCUMENTATION
Documentation should be proof read and tested (in the case of things like install instructions).
3.2.1. Release Documentation
Users expect to find a minimal set of documentation in the root directory of a release. This section describes those documents.
3.2.1.1. README
The README.txt is where the users will first go once they download you distribution. This should give the bare minimum of information on how to understand the release and how to start working with it. At the very least it should include getting started instructions and details of where to find more information.
3.2.1.2. RELEASE-NOTES
The release notes contains a description of the project and an overview of what this new release provides. It does not provide detailed change information but it does provide the "headline" changes that will encourage users to upgrade.
This document should also contain information on where to get the various distributions and where to find out more information as it will often be used when announcing a release to the outside world. That is, it should be a meaningful document even when not located in a distribution.
3.2.1.3. CHANGES
The changes document describes the bug fixes, new features and API changes found in this release. Where the document
This document is usually the first point of call for users upgrading from a previous version.
SVN logs can be used to collect changes, however this can result in too detailed a view of things, i.e. a spelling correction in the docs does not warrant an entry in the changes document. This is a good opertunity to reinforce the need for good commit messages, that is each commit should be atomic and messages should be clear and concise.
Some tools provide a means for managing change documents independently of SVN. This allows much more control over what appears in your changes document and so makes the document more useful to users.
3.2.1.4. LICENCE and NOTICE
You should have a licence file in your root directory that clearly indicates the licence in use. You may also require a NOTICE text. The existence of a NOTICE text dictated by the licences of projects you are dependent upon.
3.3. JARS
META-INF Should include LICENCE and NOTICE. Note this Should include a standards compliant MANIFEST.
3.4. DISTRIBUTIONS
A release often comes in a number of distribution packages. Since this is an open source project you should always have a source distribution that contains clear instructions on how to build the application. Compiled languages should also provide a binary distribution in which the application has already been built. In most instances you should also provide the source files within a binary distribution. This encourages people to contribute by minimising the hoops they need to jump through in order to get to the source.
Distributions should be made available as compressed files, typicaly zip files for windows and tar.gz for Linux. 3.4.1. Installers
It is also a good idea to provide an installer for your users. This allows them to get going quickly and easily and thus maximises the chances that they will give you feedback.
Different platforms have different install packages, there are some cross platform installers and you may choose to use one of this and live with some of the limitations they present. However, you should also make it as easy as possible for third parties to provide a platform specific installer. Often this means nothing more than providing a good source distribution for them to work with.
3.4.2. Legal Audit
It is of particular importance that released code is clean. It is good practice to check the provinance of any source documents which do not have licence headers. Check that dependencies (and in particular those dependencies that ship in the distribution) comply with Apache policy. Legal policy and interpretation changes from time to time so it is worth investing a little time reading again the legal release material.
3.4.3. Tag Releases in Version Control
All releases should be built from a tag in your version control system. It is occasionally necessary to rebuild releases many years later. Tagging is a reliable way to do this. So, every release and candidate should be tagged.
It is useful to adopt a reasonable naming convention when tagging releases. This allows release tags to be recognized easily. Typically the tag will be a variation on the name of the release. For example, some projects use ALL CAPS to indicate release tags in which can foo-1.2 would be tagged FOO-1-2. It is generally better to use '-' rather than '' as in most browsers the '' gets lost when a hyperlink is underlined.
If svn:externals is used, check carefully that a tag is referenced. This ensure that all the source for the release is fixed. If the target of a svn:externals changes then the release will no longer be complete reproducable.
3.4.4. Dependencies
It is important to review all library dependencies as part of the release process for compliance with your project policy. A list should be compiled of the project's dependencies, those shipped as binary libraries and those shipped as source document together with the licences for those dependencies. These lists should be checked against the latest policy documents.
3.4.5. Releases as Advertising
Releases are a major news item for your project. Be sure to blog about it, put it in your project RSS feeds, send to your announcements list. Update your records in catalogues such as freshmeat.net, update your DOAP file and ping any DOAP powered catalogues.
4. A Checklist
The checklist below is useful in ensuring everything you need to do in a release has been done. Individual projects will need to add some other checks, but this is a good starting point.
Distributions Check compressed distributions unpack correctly Check documentation is readable Check distributed libraries Check licences for libraries are distributed together with any applicable NOTICEs Check that licences comply with project policy Check that LICENCE and NOTICE documents contain required sections Check copyright notices: Licences missing from source files Source files with other licences which are not mentioned in LICENCE Check all headers comply with project policy Distributed Artifacts Check LICENCE and NOTICE files. Check a meaningful readme.txt document is present Source Distribution Check a meaningful readme.txt document is present Check build instructions exist and that source builds using these instructions Check licence headers are correctly applied Check for version control files Check that source is exported from tag OpenPGP keys Check KEYS file contains signing key Check key has been uploaded to regular public key servers
Special thanks for OSS Watch for seeding this page with content. OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford. Release 0.4 New version available See Release 0.5 Management for a newer Release!
Download KEYS: File containing public keys - not necessary for install.
PRODUCT (VM) DOWNLOAD & INSTALL
Caution This is a preview, not an official Matterhorn release. It may not be stable, and you are likely to find many bugs. The first official Matterhorn release will be Release 0.5 Management.
Help for installing available If you are not familiar with VMware Images, please read our page Install Virtual Machine.
Version Product download file Signatures
0.4.10 VMWare Image .zip (rev #1593) Created with VMWare Fusion 3.0.1 md5 sha1 To log in to the VM use: asc username: matterhorn password: opencast
0.4.11 VMWare Image .zip (rev #1630) Created with VMWare Fusion 3.0.1 md5 sha1 To log in to the VM use: asc username: matterhorn password: opencast
0.4.12 VMWare Image .zip (rev #1901) Created with VMWare Fusion 3.0.1 md5 sha1 To log in to the VM use: asc username: matterhorn password: opencast
Dev VM VMWare Image .zip (rev #2249) Created with VMWare Fusion 3.0.1 md5 sha1 To log in to the VM use: asc username: matterhorn password: opencast
Version 0.4 Documentation Page Release 0.4 Documentation
RELEASE 0.4 DOCUMENTATION
README
Matterhorn README ======
Thank you for downloding Matterhorn.
Opencast Matterhorn is a project, backed by an international community of higher education organization, that aims to build an open source, end-to-end platform that supports the scheduling, capture, managing, encoding and delivery of educational audio and video content.
Please visit http://www.opencastproject.org for more information about Matterhorn.
LICENSE ======Matterhorn is licensed under an "Educational Community License, Version 2.0" license. The text of the ECL 2.0 license can be found in the license file: LICENSE
System Requirements ======
INSTALLATION ======
By default Matterhorn installs its components in the following directories:
Matterhorn Home = /usr/local/matterhorn Matterhorn Lib = /var/lib/matterhorn Configuration = /etc/matterhorn Log files = /var/log/matterhorn
The default location of Felix is /usr/local/felix
Run the install.sh script to install matterhorn. Locations of above components can be changed by specifying parameters on the install.sh script.
Use the following command for more information install.sh -?
Known Issues ======
The Matterhorn project uses a JIRA website to track bugs: http://issues.matterhorn.org
RELEASE-NOTES
CHANGES
This is an Internal-only test release of Matterhorn. Release 0.5 Management
TIME LINE
Matterhorn 0.5 RC 2 source and VM
Release Date : Wed. 1/27/10 Release Time : 6 pm PST
Notes:
VM1 never happened due to a variety of glitches. Everyone should download VM2 and test it starting tomorrow morning. We have a small window to identify bugs and fix them. The lack of VM testing is our highest risk for not releasing on time. Between RC2 and RC3. trunk development should be constrained to Blockers and minor, low risk bug fixes. If you're not sure whether your work fits under these categories, please ask your product owner for clarification. In future releases, we should not restrict ongoing trunk development, but our process is new so we need to be extra conservative for this release.
Download KEYS: File containing public keys - not necessary for install.
Version Product download file Signatures
0.5-RC2 VMWare Image .zip (rev #2413) Created with VMWare Fusion 3.0.1 md5 sha1 To log in to the VM use: asc username: matterhorn password: opencast
Matterhorn 0.5 RC 3 source and VM
Release Date : Mon. 2/1/10 Release Time : 6 pm PST
Version Product download file Signatures 0.5-RC3 VMWare Image .zip (Built from tags/0.5-RC3) Created with VMWare Fusion 3.0.1 md5 sha1 To log in to the VM use: asc username: matterhorn password: opencast
Notes:
Code generated documentation must be completed by RC3 (javadocs, etc.) Documentation: javadocs, Engage UI Documentation, Admin Documentation
Preparation for Final Release
Release Date : Thu. 2/3/10 Release Time : 6 pm PST
Notes:
If you are not working on a blocker or minor bug, please focus on documentation. We need to have non-code generate documentation in by next Thursday. Contact me if you don't have anything to do All marketing deliverables should also be ready to go. All steps should be taken on Release Checklist (please add more steps if any are missing from below)
Official Release 0.5 source and VM
Release Date : Fri. 2/5/10 Release Time : 6 pm PST
Version Product download file Signatures
0.5 VMWare Image .zip
Created with VMWare Fusion 3.0.1 md5 sha1 To log in to the VM use: asc username: matterhorn password: opencast
Verify the integrity of the files
It is essential that you verify the integrity of the downloaded files using the PGP or MD5 signatures. Please read Verifying Matterhorn Releases for more information on why you should verify our releases.
The PGP signatures can be verified using PGP or GPG. First download the KEYS as well as the asc signature file for the relevant distribution. Make sure you get these files from the main distribution directory, rather than from a mirror. Then verify the signatures using
$ pgpk -a KEYS $ pgpv apache_1.3.24.tar.gz.asc or $ pgp -ka KEYS $ pgp apache_1.3.24.tar.gz.asc or $ gpg --import KEYS $ gpg --verify apache_1.3.24.tar.gz.asc
gpg: Good signature from "Manjit Trehan (Key Signing)
Alternatively, you can verify the MD5 signature on the files. A unix program called md5 or md5sum is included in many unix distributions. It is also available as part of GNU Textutils. Windows users can get binary md5 programs from here, here, or here. An MD5 signature consists of 32 hex characters, and a SHA1 signature consists of 40 hex characters. Ensure your generated signature string matches the signature string published in the files above.
Notes:
Publicize release through list, etc. Celebrate!
RELEASE CHECKLIST
Confirm that the latest release candidate is acceptable for releaseCopy the latest X.Y-RC-Z tags to the X.Y tag Update poms in the X.Y tags to reference versions X.YConfirm successful build of the X.Y tag Maven artifacts posted to http://repository.opencastproject.orgjar filessource jarsjavadoc jars Release directory set up on http://releases.opencastproject.orgJavadocs posted to release directory Installation instructions posted to release directorySource code (zip, tar) posted to release directory Wiki updated to reflect how to build Have QA review and test the installations instructions Update http://www.opencastproject.org/ to promote the latest release Service checklist
Checking services prior to release
FIRST PASS
Installation
Maven Make sure the maven install target is running without issues. Pay special attention to warnings about building the bundle like split packages, import and export settings.
Startup
Logging Look at the logging of your service. Can anyone find out whether your service is running, has been set up correctly and whether it's reflecting in the logs when it is serving requests.
OSGi configuration (DS) Start and stop your service, start and stop services you rely on on the felix console. If your service trackers and/or declarative service settings are working properly, then your service and others should react to this (e. g. your service should be stopped once you stop a service that yours is relying on).
Configuration
This section answers the question whether your service is customizable to a meaningful extent.
Configuration items Make sure that there are no hardcoded pieces in the code that will prevent others from running your services on other ip adresses, ports etc. Go ahead and think about what other people might want to change about the default/hardcoded behavior. This is where you should start implementing the ManagedService interface and allow for customization of those items.
Default configuration For those items that are configurable, please put a documented poperties file into the "docs/felix/conf/services" section in svn.
Documentation
Functionality
Is the service working Possibility to gather what's happening from the logs Error handling REST endpoint Connection to UI Roundtrip compliance
Performance
Bottlenecks?
Documentation
Javadocs REST documentation Configuration Cookbooks / Tutorials
SECOND PASS
Libraries, Licenses
Next steps (> 0.5)
Verifying Matterhorn Releases WHAT WE SIGN
All official releases of code distributed by the Opencast Matterhorn Project are signed by the release manager for the release. PGP signatures and MD5 hashes are available along with the distribution. You should download the PGP signatures and MD5 hashes directly from the Matterhorn download page. This helps ensure the integrity of the signature files.
CHECKING SIGNATURES
The following example details how signature interaction works. The following example assumes that you have downloaded Matterhorn-VM-0.5.zip (the release) and Matterhorn-VM-0.5.zip.asc (the detached signature). This example uses The GNU Privacy Guard. Any OpenPGP-compliant program should work successfully. First, we will check the detached signature (Matterhorn-VM-0.5.zip.asc) against the release (Matterhorn-VM-0.5.zip).
$ gpg Matterhorn-VM-0.5.zip.asc
gpg: Signature made Sat Jan 18 07:21:28 2003 PST using DSA key ID 9C65E585 gpg: Can't check signature: public key not found
If you see this error, it means you do not have the Release Manager's public key. One popular server is pgpkeys.mit.edu (which has a web interface). The public key servers are linked together, so you should be able to connect to any key server.
$ gpg --keyserver pgpkeys.mit.edu --recv-key 9C65E585 gpg: requesting key 9C65E585 from hkp server pgpkeys.mit.edu gpg: key 9C65E585: "Manjit Trehan (Key Signing)
In this example, you have now received a public key for an entity known as "Manjit Trehan (Key Signing)
$ gpg httpd-2.0.44.tar.gz.asc
gpg: Good signature from "Manjit Trehan (Key Signing)
At this point, the signature is good, but we don't trust this key. A good signature means that the file has not been tampered. However, due to the nature of public key cryptography, you need to additionally verify that key 9C65E585 was created by the real Manjit Trehan. Any attacker can create a public key and upload it to the public key servers. They can then create a malicious release signed by this fake key. Then, if you tried to verify the signature of this corrupt release, it would succeed because the key was not the 'real' key. Therefore, you need to validate the authenticity of this key.
VALIDATING AUTHENTICITY OF A KEY
You may download public keys for the Matterhorn Team from our website or retrieve them off the public PGP keyservers (see above). However, importing these keys is not enough to verify the integrity of the signatures. If a release verifies as good, you need to validate that the key was created by an official representative of the Opencast Matterhorn Project.
The crucial step to validation is to confirm the key fingerprint of the public key.
$ gpg --fingerprint 9C65E585 pub 4096R/9C65E585 2009-09-25 Key fingerprint = 1FCB 5774 71BF 1AB0 16C8 F53D 1FB7 9B59 9C65 E585 uid Manjit Trehan (Key Signing)
A good start to validating a key is by face-to-face communication with multiple government-issued photo identification confirmations. However, each person is free to have their own standards for determining the authenticity of a key. Some people are satisfied by reading the key signature over a telephone (voice verification). For more information on determining what level of trust works best for you, please read the GNU Privacy Handbook section on Validating other keys on your public keyring. Quality Assurance
Here you can find all information about quality assurance in opencast matterhorn
1. QA Guidelines
Guidelines for writing test plans Guidelines for supported browsers Guidelines for accesibilty Supported Screenreader Developer checklist for code that is "ready for QA" 2. QA Test Inviroment
Test maschines Test servers
3. QA Test Documentation
Unit Tests User Tests Cross browser test Acceptance Tests
4. Test Issues
Here every team can add his test cases or functions that should be tested Acceptance Testing
Acceptance testing is black-box testing performed on a system prior to its delivery. Code Documentation
Code Documentation
One important measurement for the quality of code is its documentation. This is especially the case for open source software projects that count on the support of external developers and a strong community around the code base.
Why invest time into code documentation?
Who of you would engage in a software where lines of code need to be inspected just to gather how to use a certain library, service or function? Voilà! This is why good and consistent documentation is so important.
Right to Edit
As with all places on this page, this is a wiki, so feel free to add to it. Also, when editing this page, make sure the content gets accepted as broad consensus by passing it by the list.
JAVA LIBRARIES AND SERVICES
Java comes with a well-established framework for code documentation called Javadoc. Feel free to take a look at how to do java code documentation like an expert. Also, looking at the source code of the Java Development Kit will give you insight into what your code documentation could look like, given you had a decent amount of time at hand.
Matterhorn Required Documentation
Being able to invest a huge amount into docuemtation efforts is usually not the case, therefore we propose the following subset of documentation in order to achieve a consistent quality and amount of documentation coverage amongst all of our services and libraries. If you are able to check off all of the tasks below, then you can be sure that your code will be accepted for release.
Let JIRA help you
We have set up a JIRA template that you can use to make sure you followed all of the advice that you will find below. Just make a copy of MH-15 42, change the title to reflect the piece of code that you are about to document, assign it to your team and make it due in the current iteration.
Package
Package documentation should cover the general concepts that are being used throughout the package, along with the principal interfaces and classes that are being used. A good example is provided by the Java 6 sql package description.
Where does the documentation go?
The package information should be put into a file called package-info.java and reside in your package root folder. Generally, the package-info is a java class itself consisting of documentation and a package declaration only. Documentation can be found here.
Checklist
In order to achieve a decent package documentation, make sure your documentation answers the following questions:
What problem domain does your package deal with? Are there any concepts that the developer should understand? What are the different strategies that your package might implement? What are the entry points into your package in terms of interfaces and classes? What best practices are there to use the package? What major requirements need to be met before being able to use the package? Is there related external documentation (rfc, specifications) that should be linked?
Types
By looking at the documentation of a class or an interface, the devloper should have a clear idea as to how the class can be used, what pitfalls there might be in terms of threading, performance etc. Again, a good example can be found in the Url class of the Java Development Kit.
Documentation body
Has a one-sentence description been given on what the class does or describe? Is there a description of concepts that should be known to users of the class? Are there possible pitfalls in the area of threading, transactions or performance? Are any other issues covered that might arise when using the class? Have any constraints be documented, like special behaviour of the equals() method? Are best practices on how to use the class documented?
Tags
Are there related classes or external resources that should be linked using @see?
Methods
As with type documentation, the notes on a method should consist of instructions on what to expect in terms of behaviour when the method is called. Also, the user should be informed about any constraints that might apply to the objects state, the format of input parameters etc. As an example, take a look at the constructor for the URL class of the Java Development Kit.
Documentation body
In general, what does the method do? Are there any requirements regarding the format of the input parameters? What does the method return with respect to input parameter values or state? If applicable, are there any constraints regarding an objects state? How are special parameter values (e. g. null) handled? Does the user know what exceptions are thrown under which circumstances?
Tags
Are the input parameters documented using the @param tag? Is the return value documented using the @return tag? Are there related methods that should be linked using @see? Are the exceptions documented with @throws?
REST ENDPOINTS
All Matterhorn REST endpoints must display HTML formatted documentation at the /docs path. Please use this template as a starting point. Please be sure that your documentation includes:
An entry for each path pattern, categorized as read and write paths. Descriptions for each path pattern, including: the HTTP method (GET, POST, PUT, DELETE) Required and optional parameters the expected input, including data formats and headers the expected output, including data formats, headers, and HTTP response codes Developer checklist
This is a checklist for developers to communicate their services' level of readyness for QA. Please ensure that your service meets at least minimal testing and documentation standards prior to the QA process. When adding to this table, please link to source file when possible, and minimize linking to the nightly build server.
Service 0.5 0.6 0.7 0.8 0.9 1.0
Caption Handling Caption Handling 0.5 Checklist
Capture Capture 0.5 Checklist Capture Admin Capture Admin 0.5 Checklist
Composer Composer 0.5 Checklist
Distribution (local) Distribution (local) 0.5 Checklist
Engage Engage 0.5 Checklist
Ingest Ingest 0.5 Checklist
Inspection Inspection 0.5 Checklist
Scheduling Scheduling 0.5 Checklist
Search Search 0.5 Checklist
Workflow Workflow 0.5 Checklist
Working File Repository Working File Repository 0.5 Checklist
Workspace API Workspace API 0.5 Checklist
Items marked with this icon indicate satisfactory levels of testing and documentation, and that the component is ready for QA.
Items marked with this icon indicate incomplete or missing documentation or tests. Click the link to see a more detailed description of what is missing.
Caption Handling 0.5 Checklist
Configuration documentation NONE
Package Javadocs http://build.opencastproject.org/apidocs/index.html?org/opencastproject/captions/impl/package-summary.html
Type Javadocs http://build.opencastproject.org/apidocs/index.html?org/opencastproject/captions/api/CaptionsMediaItem.html
Runtime Documentation Available at runtime REST (HTML) REST (WADL) SOAP (WSDL)
Integration Tests None
Code coverage 0% Capture 0.5 Checklist
Configuration https://wiki.opencastproject.org/confluence/display/open/Capture+Agent+Configuration documentation
Package http://build.opencastproject.org/apidocs/org/opencastproject/capture/api/package-summary.html Javadocs
Type Javadocs http://build.opencastproject.org/apidocs/org/opencastproject/capture/api/CaptureAgent.html http://build.opencastproject.org/apidocs/org/opencastproject/capture/api/Scheduler.html http://build.opencastproject.org/apidocs/org/opencastproject/capture/api/StateService.html
Runtime REST (HTML) Documentation REST (WADL)
Integration http://source.opencastproject.org/svn/modules/opencast-test-harness/trunk/src/main/java/org/opencastproject/remotetest/CaptureRestEndpointTest.java Tests
Code coverage http://build.opencastproject.org/coverage/org/opencastproject/capture/admin/impl/pkg-summary.html
Capture Admin 0.5 Checklist
Configuration None documentation
Package http://build.opencastproject.org/apidocs/org/opencastproject/capture/admin/api/package-summary.html Javadocs
Type Javadocs http://build.opencastproject.org/apidocs/org/opencastproject/capture/admin/api/Agent.html http://build.opencastproject.org/apidocs/org/opencastproject/capture/admin/api/AgentStateUpdate.html http://build.opencastproject.org/apidocs/org/opencastproject/capture/admin/api/Recording.html http://build.opencastproject.org/apidocs/org/opencastproject/capture/admin/api/RecordingStateUpdate.html
Runtime REST (HTML) Documentation REST (WADL)
Integration http://source.opencastproject.org/svn/modules/opencast-test-harness/trunk/src/main/java/org/opencastproject/remotetest/CaptureAdminRestEndpointTest.java Tests
Code coverage 96%
Composer 0.5 Checklist
Configuration documentation
Package Javadocs
Type Javadocs
Runtime Documentation REST (HTML) REST (WADL) SOAP (WSDL)
Integration Tests
Code coverage 0% Distribution (local) 0.5 Checklist
Configuration The "distributionDirectory" property in the configuration file for PID "org.opencastproject.distribution.local.DistributionService" defines the local directory for documentation distribution.
Package http://build.opencastproject.org/apidocs/org/opencastproject/distribution/api/package-summary.html Javadocs
Type Javadocs http://build.opencastproject.org/apidocs/org/opencastproject/distribution/api/DistributionService.html
http://build.opencastproject.org/apidocs/org/opencastproject/distribution/local/DistributionServiceImpl.html
Runtime REST (HTML) Documentation REST (WADL) SOAP (WSDL)
Integration http://source.opencastproject.org/svn/modules/opencast-test-harness/trunk/src/main/java/org/opencastproject/remotetest/DistributionLocalRestEndpointTest.java Tests
Code coverage 60%
Engage 0.5 Checklist
Configuration documentation
Package Javadocs
Type Javadocs
Runtime Documentation REST (HTML) REST (WADL) SOAP (WSDL)
Integration Tests
Code coverage 0%
ENGAGE MEDIA PLAYER
Configuration http://wiki.opencastproject.org/confluence/display/open/Engage+media+player+installation documentation
Package Javadocs
Type Asdocs http://releases.opencastproject.org/public/05/uidocs/engage/asdoc/index.html
Type Jsdocs http://releases.opencastproject.org/public/05/uidocs/engage/jsdoc/index.html
Runtime Documentation Video url download/stream Caption file: W3C DFXP Integration Tests
Code coverage 0%
Useful tools http://wiki.opencastproject.org/confluence/display/open/Tools+and+HOWTOs+to+improve+the+quality+for+non-java+development
Accessibility checklist https://wiki.opencastproject.org/confluence/display/open/Accessibility
Accessibility status https://wiki.opencastproject.org/confluence/display/open/Accessibility+Features
Ingest 0.5 Checklist
Configuration documentation
Package http://build.opencastproject.org/apidocs/org/opencastproject/ingest/api/package-summary.html Javadocs
Type Javadocs http://build.opencastproject.org/apidocs/org/opencastproject/ingest/api/IngestService.html http://build.opencastproject.org/apidocs/org/opencastproject/ingest/impl/IngestServiceImpl.html
Runtime REST (HTML) Documentation REST (WADL)
Integration http://source.opencastproject.org/svn/modules/opencast-test-harness/trunk/src/main/java/org/opencastproject/remotetest/IngestZipTest.java Tests
Code coverage 59%
Inspection 0.5 Checklist
Configuration documentation
Package Javadocs
Type Javadocs
Runtime Documentation REST (HTML) REST (WADL) SOAP (WSDL)
Integration Tests
Code coverage 0%
Scheduling 0.5 Checklist Configuration There is the possibility to define other ingestion endpoints that the capture agent might use. This is defined in the felix confing with the key "capture.ingest.enpoint.url". If this is missing, documentation the value will be constructed from the "serverURL" that is in the felix-config too.
Package Javadocs http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/api/package-summary.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/endpoint/package-summary.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/impl/package-summary.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/impl/dao/package-summary.html
Type Javadocs http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/api/SchedulerEvent.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/api/SchedulerFilter.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/api/SchedulerService.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/endpoint/SchedulerWebService.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/endpoint/HashtableAdapter.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/endpoint/MetadataEntry.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/endpoint/SchedulerBuilder.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/endpoint/SchedulerEventJaxbImpl.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/endpoint/SchedulerEventMetadataJaxbImpl.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/endpoint/SchedulerFilterJaxbImpl.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/endpoint/SchedulerRestService.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/endpoint/SchedulerWebServiceImpl.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/impl/CalendarGenerator.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/impl/CaptureAgentMetadataGenerator.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/impl/DublinCoreGenerator.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/impl/MetadataMapper.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/impl/SchedulerEventImpl.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/impl/SchedulerFilterImpl.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/impl/SchedulerServiceImpl.html http://build.opencastproject.org/apidocs/org/opencastproject/scheduler/impl/dao/SchedulerServiceImplDAO.html |
Runtime REST (HTML) Documentation REST (WADL) SOAP (WSDL) - not implemented
Integration Tests
Code coverage 65% impl, 18% Endpoint
Search 0.5 Checklist
Configuration documentation
Package Javadocs
Type Javadocs
Runtime Documentation REST (HTML) REST (WADL) SOAP (WSDL)
Integration Tests
Code coverage 0%
Workflow 0.5 Checklist
Configuration Workflow definitions can be added as *-workflow.xml files in the felix/load directories documentation
Package Javadocs http://build.opencastproject.org/apidocs/org/opencastproject/workflow/api/package-summary.html Type Javadocs http://build.opencastproject.org/apidocs/org/opencastproject/workflow/api/WorkflowService.html
Runtime REST (HTML) Documentation REST (WADL) SOAP (WSDL) – not implemented
Integration http://source.opencastproject.org/svn/modules/opencast-test-harness/trunk/src/main/java/org/opencastproject/remotetest/WorkflowRestEndpointTest.java Tests
Code coverage 25-80%
Working File Repository 0.5 Checklist
Configuration No configuration available documentation
Package Javadocs are implemented, but are not aggregating properly. See MH-1604 Javadocs
Type Javadocs Javadocs are implemented, but are not aggregating properly. See MH-1604
Runtime REST (HTML) Documentation REST (WADL)
Integration http://source.opencastproject.org/svn/modules/opencast-test-harness/trunk/src/main/java/org/opencastproject/remotetest/WorkingFileRepoRestEndpointTest.java Tests
Code coverage 66% (service impl), 52% (total)
Workspace API 0.5 Checklist
Configuration documentation None
Package Javadocs http://build.opencastproject.org/apidocs/org/opencastproject/workspace/api/package-summary.html
Type Javadocs http://build.opencastproject.org/apidocs/org/opencastproject/workspace/api/Workspace.html
Runtime Documentation No endpoints
Integration Tests No endpoints
Code coverage 36% (the remaining uncovered tests are simple delegate methods)
Matterhorn Supported Screenreaders
Win XP Win Vista Mac 10.5.† Mac 10.6.†
Firefox 3.0.† A-grade
Firefox 3.5.† A-grade A-grade A-grade
Opera 10.0.† A-grade
IE 8.0 A-grade A-grade
IE 7.0 A-grade A-grade
Safari 4.0.† A-grade A-grade
QA Process Overview
TESTING TECHNIQUES
Designers/Developers will alert the QA manager of new features to be added to the regression tests. Matterhorn includes three types of tests:
Unit Tests indicate whether Matterhorn's implementation logic is correct, and help minimize introducing new bugs when developers refactor code . These tests are run daily on Matterhorn's Bamboo integration server and developers run them locally via maven during build time. Java unit tests cover the back end and javascript unit tests cover the front end. Javascript unit tests unit tests that rely on dom manipulation use the Selenium server, whereas other javascript unit tests that only test implementation logic are integrated into the maven build. Integration testsexercise the REST services to ensure they accept expected inputs and provide expected outputs. These tests run daily on nightly and run on the QA server. UI regression testswalkthrough the core user functionality to determine whether it is still functioning as expected. Step 1) Resolve, review, and close tasks.
Once a developer has determined that all the requirements have been met they can do one of the following: -IF a committer, they should merge/commit the patch, and resolve the task. -If not a committer, they should attach a patch to the relevant "high level" task, and reassign the task as blocker to a committer who will merge/commit code and resolve the task. Developers should only submit their patches to the relevant high level "implement/complete" task and not lower level tasks. For infrastructure and services work, if there is not relevant higher level task assign to relevant lower level task.
Once a high level task has been resolved by the developer: -Concerning UI testing and requirements, Allison, Judy, Marcus, Nils, and Laurie (and yet tbd resource) will confirm that their tasks have been satisfied and close them. -Concerning code coverage, Josh, Tobias, Christoper, and Markus will confirm that their tasks have been satisfied and close them. -This may happen at any point during an iteration. -An task cannot be closed until its code has been committed to svn and confirmed by a tester that it satisfies requirements on nightly.
Once a low level task has been resolved by the developer: -The product owner (e.g. chris, josh, tobias, markus) is responsible for closing out the low level task.
The developer should give testers enough time to review their work and assign follow up tasks before the iteration ends.
Step 4) Reopen tasks or Create Bugs.
Bug vs. Acceptance Testing Failure
Acceptance Testing Failure
Design and Acceptance Tests ensure that the requirements have been adequately met. These tasks are not considered bugs since the original task is incomplete. To ensure that acceptance test don't go on forever, this process will depend on granular story cards with clear requirements. If Allison and Judy find that the design requirements have not been met, they will reopen their task and add comments for completion. If Laurie (and yet tbd resource) finds that the accessibility requirements have not been met, she will reopen her task and add comments for completion. If Josh, Tobias, Christopher, and Markus find that the unit or integration test coverage is inadequate, they will reopen their task and add comments for completion. If Josh, Tobias, Christopher, and Markus find that documentation is inadequate, they will reopen their task and add comments for completion.
Bug If there are cross browser, usability, test, or other failures, a "sub-bug" should be created within the story card. Regarding cross browser and test failures, Marcus and Nils (starting in January) will be primarily responsible for issuing bugs associated with UI related test failures and cross browser tasks. Others may enter bugs related to these tasks but they should check with them or determine whether any similar bugs currently exist. Anyone can task bugs related to usability tasks but they should search whether current bugs already exist.
How to report a bug: Every bug report/ticket contain the URL of the machine where the failure occurs, the build id, browser and OS used and a link to the recording/mediapackage that was used to trigger the bug, if it happened during processing. Don't forget to choose the Component/s your ticket affect. Assign the ticket to the developer and/or the product owner (see list for details) you think is responsible for your report.
Step 5) Closing story cards and moving incomplete story cards/tasks/bugs to future iterations
When a task or a bug is not completed in its assigned iteration....
If it is a large bug or task that is only partially complete, the developer should leave the task or bug opened and record what has been completed and what work is remaining. During iteration planning, Product Owners will determine whether the work should be carried on to the subsequent iteration or a future iteration. Once this has been decided, the iteration number should be changed by the PO. If the purpose of the task has changed, the Product Owner should rename it to more accurately reflect the remaining work.
If the incomplete task/bug prevents closure of the high level "implement/complete" tasks, the story card will be left open and tagged by Judy, Allison, and/or Adam for the next iteration.
When all of the tasks and bugs have been completed in its assigned iteration....
If the high level "implement/complete" tasks have been close for UI related story cards, Judy, Allison, and/or Adam will close the relevant story cards. If the high level "complete" tasks and necessary low level tasks have been closed for infrastructure and service only story cards, Josh and/or Tobias will close the relevant story cards. Selenium Core Test
Share your Selenium Core test.
To use this tests with Selenium IDE:
1. Install the Selenium IDE Plug-In Download in your Firefox 2. Download the .txt file and open the file in your favourite text editor. 3. Then you have to customize 4. Now you can cleanup the Selenium IDE source view and copy and paste it into Admin UI Upload recordings with a large set of metadata
selenium_upload_admin_ui_large.txt Additional customizations: Change value of Cmd: "type" Target: "track" to the location of the test media file on your computer
Admin UI Upload recordings with a large set of metadata
selenium_upload_admin_ui.txt Additional customizations: Change value of Cmd: "type" Target: "track" to the location of the test media file on your computer Tools and HOWTOs to improve the quality for non-java development
Tools that help to increase our products quality:
JavaScript
Creating javadoc like code documenation jsdoc-toolkit http://code.google.com/p/jsdoc-toolkit
Examples for code comments http://code.google.com/p/jsdoc-toolkit/wiki/DocExamples
Cookbook section http://code.google.com/p/jsdoc-toolkit/wiki/CookBook
Code coverage http://getfirebug.com/extensions/index.html#firebugcodecoverage or http://siliconforks.com/jscoverage
JavaScript unit testing http://docs.jquery.com/QUnit
Improve code quality - note: JSLint will hurt your feelings http://www.jslint.com/
Creating/recording test suites for user interaction in a web application http://seleniumhq.org/
Javascript maven jslint/jsdocs reports http://dev.abiss.gr/mvn-jstools/index.html
Flex development
Flexmojo - Flex development the maven way http://flexmojos.sonatype.org/
Creating javadoc like code documentation for Flex http://labs.adobe.com/wiki/index.php/ASDoc
NOTE: Flexmojo is used to create asdoc + runs unit tests in a headless build server environment + code coverage
Flex unit testing http://opensource.adobe.com/wiki/display/flexunit/FlexUnit
Flex code coverage http://code.google.com/p/flexcover/
Flex PMD to improve code quality http://opensource.adobe.com/wiki/display/flexpmd/FlexPMD
Creating/recording test suites for user interaction http://code.google.com/p/flexmonkey/
HOWTOs section:
Example pom snippet for a maven site report (javascript and asdoc)
OS Browser URL Access Additional Infos Location Admin
Ubuntu 9.04 Firefox 3.5, Opera mh-ubuntu.virtuos.uos.de - Universität Osnabrück Nils Birnbaum, [email protected]
Windows 7 Firefox 3.5, Opera, IE 8 mh-windows.virtuos.uos.de - Universität Osnabrück Nils Birnbaum, [email protected]
Mac OS 10.5.8 Safari, Firefox 3.5 wyre.virtuos.uos.de - Universität Osnabrück Nils Birnbaum, [email protected]
_Components Schedule Drafts_
Working Documents
All working documents should:
Link to a relevant Jira ticket Be deleted or moved upon completion or moved to the Archive Tagged working and the relevant team name
CAPTURE
Capture Agent Configuration (OLD Matterhorn Project **DON'T USE**) working capture
Live media capture architecture (OLD Matterhorn Project **DON'T USE**) working capture
Calendar -- Capture architecture proposal (OLD Matterhorn Project **DON'T USE**) working capture
Capture Agent Job Sequence (OLD Matterhorn Project **DON'T USE**) working capture
Candidate metadata available for capture (OLD Matterhorn Project **DON'T USE**) working metadata capture
COMMON
Content by label
There is no content with the specified labels
DISTRIBUTE
Content by label
There is no content with the specified labels
ENGAGE
Testing balsamiq (OLD Matterhorn Project **DON'T USE**) working engage
Streaming and Web Server solutions from the Community (OLD Matterhorn Project **DON'T USE**) working engage
Keyboard shortcuts for a basic media player (OLD Matterhorn Project **DON'T USE**) working engage
Service Definitions - Engage (OLD Matterhorn Project **DON'T USE**) working engage
Javascript coding style (OLD Matterhorn Project **DON'T USE**) working engage
Media Portal (OLD Matterhorn Project **DON'T USE**) working engage
Service Definitions - Engage (Opencast Developer Wiki) engage working
Keyboard shortcuts for a basic media player (Opencast Developer Wiki) engage working
HTML CSS js framework (OLD Matterhorn Project **DON'T USE**) working engage
Flex frameworks (OLD Matterhorn Project **DON'T USE**) working engage
MANAGE
Content by label
There is no content with the specified labels
BA-UX - Distribute
Business Analysis/User Experience aspects of this component Service Modeling
This page will be used to describe our service modeling processes and mechanisms. The services themselves will be defined under each of the relevant components
References
Service Contract Definition template Service Definition & Assumptions template Service Definitions - Distribute
Service Definitions - Cross-Component
Service Definitions - Capture
Revised ArchiveService
Instructional notes for this template are in blue and preceded with the icon. Remove instructional notes and this note before publishing.
ARCHIVESERVICE
Version Trunk Release Notes
Classification Nomenclature: Type:Component:Context (e.g. "Business:Common:File System")
Description Concise description
Context
Assumptions Assumptions on which this service is based
Static Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Name put(MediaPackage mediaPackage, NotificationCallback callback)
Description Put a Matterhorn MediaPackage and all its associated files into an archive.
Notes Related Notes. Name get(MediaPackage mediaPackageId)
Description Get a Matterhorn MediaPackage from an archive.
Notes Related Notes.
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/composer/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/composer/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/files/docs
WADL http://nightly.opencastproject.org/files/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/conductor?wsdl
ArchiveService_Release_Notes
1.0
Blah, blah.
0.9
Blah, blah.
0.1
Blah. Reviewing Code
Once a contributer (author) is ready to submit code, they should add a crucible review ticket from their Jira task. Should they assign the review to a developer associated with the component and/or leave the review open for anyone to take on? Utlimately it is the component lead's (moderator) responsibility to summarize the review before committing to trunk. The moderator will assess the risk associated with unresolved code reviews, and ultimately determine whether to commit the code or not.
All code commits should include the related jira issue key in the commit message. This will essentially map the commit and jira issue, thus enabling developers to refer to the specific changeset within the related jira issue (via the Fisheye tab). It also allows developers to conveniently create a code review for the specific changeset directly from their jira issue. Unknown macro: {html}
Requirements - Schedule
Requirements, or Stories of this component... could be a Jira Include? Requirements - Process-Encode Requirements, or Stories of this component... could be a Jira Include? Requirements - Distribute
Requirements, or Stories of this component... could be a Jira Include? Requirements - Capture
Requirements, or Stories of this component... could be a Jira Include? OBSOLETE - Engage Archive Docs - Engage
This is a space to archive planning or reference documents related to the Engage component... Components Schedule UIs
Components Schedule Other
Testing balsamiq only a Test
Relationships between admin UIs Internal server error Deployment Case Studies
Opencast institutions are encouraged to share their deployment case studies. Simple Classroom Setup - USask Simple Classroom Setup - USask
Candidate metadata available for capture
Because there is not really a metadata schema for Matterhorn/Opencast the metadata group (Olaf, Nils) proposed to use the Replay metadata schema to start with: https://wiki.opencastproject.org/confluence/download/attachments/4424230/Replay_metadata_simplified.xls
Metadata could be vocabulary-based or format-based (e.g. dynamic or free formed)
Free Form metadata
Candidate Field Multiplicity Format Notes
Capture Bitrate 1 per media stream kbits per second
Quality 1 per media stream ffmpeg q values?
Instructor 1+ per media stream name:name:name:...
Class 1 per media stream classname
start time 1 per media stream unix timestamp?
end time 1 per media stream unix timestamp?
date 1 per media stream unix timestamp? This could just be derived from the start and end times too...
description 1 per media stream text Description of class material coverage (explanation of the core components of your computer)
title 1 per media stream text Description class title (Lecture 1: Computer Hardware)
Vocabulary Constrained metadata
Candidate Field Multiplicity Format Notes
Codec 1 per media stream (h264,flv,mpeg2,mpeg4,wmv)
Language 1 per media stream (eng,fr,es,de,...) Use the ISO language codes
OCR 1 per media stream true/false Processing should OCR this video
Audio codec 1 per media stream (mp3, aac, ogg, ...)
dc:type 1+ per recording restriced vocabluary (lecture recording, MovingImage)
Content based metadata
Candidate Field Multiplicity Format Notes dc:titel 1 per recording text maybe provided by iCal, otherwise maybe generated text ("recorded on
Organisational Metadata
Candidate Field Multiplicity Format Notes dc:identifier 1 per recording MediaPackage ID format will be provided by MediaIngestService.createMediaPackage
Capture Agent and System Test Instructions
TO CREATE A CAPTURE AGENT FOR THE UI wget --post-data='agentName=$NAME&state=$STATE' http://nightly.opencastproject.org/capture-admin/rest/SetAgentState or curl -d agentName=$NAME -d state=$STATE http://nightly.opencastproject.org/capture-admin/rest/SetAgentState
(replace $NAME and $STATE with any value you desire) then check it out at http://nightly.opencastproject.org/capture-admin/rest/GetKnownAgents
TO RUN CAPTURE AGENT TESTS mvn -Dtest=CaptureAgentImplTest, if you are in opencast-capture-service-impl dir
TO GET THE ICAL SCHEDULE FOR A CAPTURE AGENT YOU FIRST MUST SCHEDULE AN EVENT, THEN GO TO http://nightly.opencastproject.org/scheduler/rest/getEvents for an overall summary of *all* scheduled captures (for all agents) http://nightly.opencastproject.org/scheduler/rest/getEvents?agent=$NAME for an xml summary of the scheduled captures for a given agent http://nightly.opencastproject.org/scheduler/rest/getCalendarForCaptureAgent/$NAME for the iCal version of the agent's calendar. Note that as of 2009-01-12 this link generates iCal for *all* agents, not just the one you want. A bug has been filed at MH-2013.
WANNA TEST THE WHOLE SYSTEM? MIGHT TAKE AWHILE, BUT YOU CAN RUN INTEGRATION TESTS AFTER BUILDING WITH: java -jar opencast-test-harness/target/opencast-test-harness-0.1-SNAPSHOT-jar-with-dependencies.jar Streaming and Web Server solutions from the Community
The Opencast Community uses different server types to bring vidoe/audio to distribution channels.
Candidates:
Red5 // http://red5.org/ Flash Media Server Mammoth // http://mammothserver.org/ Helix //https://helixcommunity.org/ wowza // http://www.wowzamedia.com/
Web server solutions:
lighty // http://www.lighttpd.net/ Apache with mod QuickTime Streaming Server Windows Media Server (WMS) Tomcat Wowza Flash streaming server Helix mobile server IIS and Apache web servers Keyboard shortcuts for a basic media player
EXAMPLE FROM THE JW PLAYER:
Shortcut Key Legend Alt + Control + P = play and pause toggle Alt + Control + S = stop Alt + Control + M = mute audio toggle Alt + Control + C = caption pane toggle expanded/collapsed Alt + Control + R = resize player toggle ((Alt + Control + T = shift cursor focus between toolbar and timer region (primarily useful for screen reader users)))
FOR THE BASIC MEDIA PLAYER:
Variant 1
Play/Pause: Alt + Control + P = play and pause Stop: Alt + Control + S = stop Volume: Alt + Control + M = mute audio toggle
Variant 2
play / pause toggle spacebar stop s fast-forward / fast-fast-forward 1x cursor right / 2x cursor right (once again cursor right back to normal speed) fast-rewinde (fast-fast-rewinde) 1x cursor left / 2x cursor left (once again cursor left back to normal speed) (If necessary a 3rd "gear") volume control cursor up / down mute m next chapter / slide previous chapter / slide BA-UX - Process-Encode
Business Analysis/User Experience aspects of this component Welcome Page - Installation
DEPRECATED Service Contract Description Template
Instructions for this template are in blue and preceded with the icon. Remove all instructions, including this note, before publishing.
MYSERVICE
Replace MyService in the Release Notes link with the new service name in CamelCase
Version Current Version (e.g. Trunk) MyService Release Notes
Classification Service Type:Team Name:Context, e.g. "Business:Engage:File System" (see Document a Service).
Description Concise description
Context Assumptions Assumptions made by this service
Service Dependencies Other required services
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
Add additional operations as required
Name Operation signature (e.g. put(MediaPackage mediaPackage, NotificationCallback callback))
Description Concise description
Notes Notes may include constraints, transactional properties of an operation, questions, comments, artifacts used to define the operation (e.g. workflow, swimlane, or entity diagrams, user stories or use cases) or other notes.
Name Operation signature
Description Concise description
Notes Related Notes
Name Operation signature
Description Concise description
Notes Related Notes
Bindings
Replace myservice in the URLs with the new service name in lowercase
Type Java
JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html
Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html
Type REST
Documentation http://nightly.opencastproject.org/myservice/docs
WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml
Type SOAP
WSDL http://nightly.opencastproject.org/private/myservice?wsdl
Service Definitions - Engage
DRAFT: in progress This page is a work in progress. requirements reference implementation:
configuration of a server (uri, api key); parameter:
mediaBundleID; quality autoplay in out start position referer skin size show subtitle enable accessibility enhancements buffersize basic media player:
//MediaBundle => list of Mediafiles + 1 x general Metadata for MediaBundle
//Each Mediafile inside a MediaBundle might have it´s own Metadata getMediaIdentifiers(mediaBundleID) return value: struct: list of media_identifier; getMediaTypes(media_identifier) return value struct: list of available types (e.g., MP4 HD, FLV, MP3, ...) getMediaUri (media_identifier, type, transport_protocol) return value: url getMediaLength(media_identifier) return value length in ms getMediaDimension(media_identifier) return value height px width px getAuthor(mediaBundleID) return value string author getRecordingDate(mediaBundleID) return value date date getDescription(mediaBundleID) return value string description getPreviewImage(mediaBundleID) return value url getTitle(mediaBundleID) return value string title getCaptions(media_identifier) return value subtitle file getTags(mediaBundle) return value list of struct(time,text) createSession(mediaBundle,userID) return value string sessionID sendTag(sessionID,tagtext,time) return int tagID
//critical authenticateUser(mediaBundle,userID,....) return value string systemtoken sendFootprint(sessionID,timeIN,timeOUT) return int footprintID sendException(sessionID,stackTrace) return int exceptionID
ENGAGE FEEDBACK SERVICE
/** * @return ip address the ip address of the client */ public String getIPAddress() /** * This Method is called if the Flash Client finds no Local Shared Object with a user id. * * @return userId a unique user id */ public String createUser() /** * @param userId the unique User-ID either stored in a Local Shared Object * @param referrer the referrer of this session passed by a get parameter to the Flash Client * @param ipAddress the ip address (browser type, Operating System, ...) of the client * @return sessionId a unique session id */ public String createSession(String userId, String referrer, String ipAddress) /** * This Method is called periodically while watching the video * * @param videoId videoId from the media bundle that is currentlich watched * @param sessionId the unique session id * @param inPoint the beginning of the footprint * @param outPoint the ending of the footprint * @return footprintId the unique footprint id */ public String sendFootprint(String videoId, String sessionId, int inPoint, int outPoint) Capture Media and Encoding Results
Matterhorn 0.5 capture agent supports a variety of file outputs. The following the final delivery format from the various outputs supported by the 0.5 capture agent. The original output can be found here. http://dl.dropbox.com/u/477193/h264aac_camera-mux.flv http://dl.dropbox.com/u/477193/h264aac_mux.mp4 http://dl.dropbox.com/u/477193/h264aac_screen-mux.flv http://dl.dropbox.com/u/477193/h264mp3_camera-mux.flv http://dl.dropbox.com/u/477193/h264mp3_screen-mux.flv http://dl.dropbox.com/u/477193/mpeg2aac_camera-mux.flv http://dl.dropbox.com/u/477193/mpeg2aac_screen-mux.flv http://dl.dropbox.com/u/477193/mpeg2h264_camera-mux.flv http://dl.dropbox.com/u/477193/mpeg2h264_screen-mux.flv http://dl.dropbox.com/u/477193/mpeg2mp2_camera-mux.flv http://dl.dropbox.com/u/477193/mpeg2mp2_screen-mux.flv http://dl.dropbox.com/u/477193/mpeg2mp3_camera-mux.flv http://dl.dropbox.com/u/477193/mpeg2mp3_screen-mux.flv Matterhorn Capture Hardware Specification
We do not intend to sell anything, but our goal is it go provide inexpensive hardware specifications for those interested in building their own Matterhorn capture appliance. Beyond purchasing the hardware components, it's free. No licensing costs. No maintenance fees. Nothing. And approx. $1000 (USD) for an appliance that captures vga, video (H264/MPEG2), and audio, it's a steal!
Matterhorn's schedule based, automated media capture software can run on a variety of hardware. We've outlined the hardware we're using to test it here, but if you want to substitute different hardware or software you can. Our installation scripts are written with Ubuntu 9.10 in mind, but modifications to other linux-based operating systems should be straight forward. If you plan on adding video capture devices outside of those listed below, you may need to modify the capture agent Java sources and rebuild. But before you do drop a line to the opencast community list, make sure your cards have already been added to the appropriate bundles!
Caution The list below is for convenience only and the vendors are not monitored by, approved by, or represented by Opencast or the Matterhorn build project. Many of the components listed can be obtained through various vendors. This list of hardware is not complete nor finalized. It should be appropriate for the 0.5 release, and a 1.0 reference guide will be released after testing has begun.
HARDWARE
Component Known Good Hardware Vendor Notes Link
Processor & Intel D945GCLF2D Logic 2GB of RAM is plenty, capture should be fine with 1GB. Motherboard - add 2GB DDR2 667 RAM Supply
Enclosure Casetronic C137 Mini-ITX Logic Mounting brackets are available as well. This case is nice because it can be rackmounted in an A/V rack as well as Case Supply has plenty of room for cooling.
Storage 2.5" SATA Drive, 80GB+ NCIX A faster drive (7200 RPM) is prefered to a slower drive (5400 RPM).
Video Capture Hauppauge PVR350 Has native MPEG2 capture but generates significant heat. Other Hauppage MPEG2 cards should work. Card (discontinued) PV-143 bluecherry BT878 chipset (1 NTSC/PAL stream at full fps) PV-149 bluecherry BT878 chipset (4 NTSC/PAL streams at full fps)
VGA Capture Card VGA2USB Epiphan External, if a smaller enclosure is used. VGA2USB-i Epiphan Internal, appropriate for Casetronic eclosure.
Sample Media Output
This output media derived from the variety of inputs generated by the release 0.5 capture agents. Composer Features
A draft list of some of the composer features:
Merging multiple frames into one (e.g. two video side by side) Advanced Workflow Options - Chris Calendar -- Capture architecture proposal Internal server error Internal server error
HTML CSS js framework
The client-side framework that will be used is Fluid.
One big reason is that it cares about accessibility in the way that it is capable of 'linearizing' a page. Also it has a rich and well documented component library.
Fluid uses JQuery as its baseframework, wich is the state-of-the-art framework for now and probably the near future. For testing, Fluid wraps the JQuery test-suite QUnit with the JUnit-ish jqUnit. In Matterhorn we employ Maven as build tool. There exists a Maven plugin for automatic testing with JsUnit, a JUnit compliant js testing framework. Since jqUnit claims to be JUnit compliant to it should be possible to use this plugin with Maven also for testing with jqUnit (maybe minor modifications are needed). Scheduling Scenarios
IN GENERAL
Whenever an iCalendar file will be imported from a channel (R25, LCMS, ...) every event that is already in the scheduler database will be removed, so that we do not have to care about synchronisation. Import of events can be restricted to a specified period, events outside that period will not be affected (implementation in a later iteration) There is no reporting back of changes in the events made with matterhorn to the channels. events already recorded will be removed after a configurable timespan. The system is not intended to keep a history of recording events.
SCENARIOS
These scheduling scenarios will all be supported by the Scheduling Service, the adminstrator decides on which to use:
1) No import (deliverable for Q2)
The Matterhorn Scheduling UI is the only way that user schedules an event. (System is configured so no import is allowed.)
2) One-time upload (deliverable for Q3)
One iCalendar file is manually uploaded by the Admin user. After that the schedule can be edited and changes made within the Matterhorn Scheduling UI.
2a) Once a semester import
An iCalendar file from one (or multiple) iCalendar channels will be downloaded from a specified URL once per semester directly through the scheduling service. New events can be imported manually for a later timespan but must not conflict with existing events in the database. If they do conflict, the old events will be deleted and the new ones will replace them.
The Configurer provides the URL to the iCalendar file on the iCalendar channel (e.g. R25). After that the schedule can be edited and changes made within the Matterhorn Scheduling UI. For example, the Admin can add additional metadata to the events (technical and content). Changes in the Matterhorn Scheduling UI will only affect Matterhorn, and will not be reported to other systems.
Whenever we reimport, anything scheduled for the future based on is
3) Recurring import from one channel
No changes made in admin UI.
3b) Recurring import from multiple channels
The iCalendar files from the different iCalendar channels (e.g. R25) will be updated at specified intervals (e.g. once a day). This interval can be set individually for each channel.
Whenever the iCalendar from a channel has changed events, all events from this channel will be removed and the new events imported.
Every channel has a priority. The channel with the higher priority is the source of authority when conflicting events emerge. The conflicts will be reported to the job controller (or something similar) with the information about which channels produce the conflict. The Matterhorn Admin is notified of the conflict in this way, and communicates with the administrators of the outside systems (e.g. R25, other iCalendar channels) to resolve the conflict.
When the Matterhorn Admin doesn't act, the priority determines the schedule that is sent to the capture agent.
The Matterhorn Scheduling client is in this scenario just another channel and will not be able to edit events from other channels. It will, however, still allow the Admin to edit events entered through the Scheduling UI. Notepad for Service Description
Mapping of iCalendar to DC
Technical metadata goes into Resources http://tools.ietf.org/html/rfc2445#section-4.8.1.10 Capture Agent is an ID in the list of Attendees http://tools.ietf.org/html/rfc2445#section-4.8.4.1 Creator goes into Organizer http://tools.ietf.org/html/rfc2445#section-4.8.4.3 Location maps to Location http://tools.ietf.org/html/rfc2445#section-4.8.1.7 Recurrence maps to Recurrence Rule http://tools.ietf.org/html/rfc2445#section-4.8.1.7 Recurrence may also may to Recurrence Date/Times, Exception Date/Times, and Exception Rule depending on how complicated the recurrence scenarios are that we want to support. Abstract maps to Description http://tools.ietf.org/html/rfc2445#section-4.8.1.5 or to Summary http://tools.ietf.org/html/rfc2445#section-4.8. 1.12 Starttime maps to Date/Time Start http://tools.ietf.org/html/rfc2445#section-4.8.2.4 Endtime maps to Date/Time End http://tools.ietf.org/html/rfc2445#section-4.8.2.2 SeriesID may map to "Related To" http://tools.ietf.org/html/rfc2445#section-4.8.4.5 Dublin Core Metadata will be provided as a XML-Attachment No idea where to store the Contributor except in an x-Prop... Adding a new service
This page describes how to add a new service to matterhorn. It's in-development.
Step 1: Create new directory in the matterhorn modules directory.
Step 2: Organize directory to include typical branches, trunk, etc.
Step 3: Edit the svn props for the externals file in the main matterhorn directory
svn propedit svn:externals . Windows users might need to do this first: set EDITOR=notepad
Step 4: Edit the pom.xml at https://source.opencastproject.org/svn/products/matterhorn/trunk/pom.xml ONLY WHEN IT BUILDS CLEANLY Matterhorn Engage - Player architecture
Matterhorn Engage - Media player architecture
First take a look at Matterhorn Portal Distribution architecture to get an overview where the Engage tools life in the overall architecture.
The engage applications (media players) will showcase Matterhorns capabilities with regard to media analysis and metadata processing. All engage applications need to be accessibly in multiple ways.
Screenreader access Captions Keyboard shortcuts Embedable and useable in a variety of extern platforms like Blogs/Wikis and LMS Systems. Cross platform / browser independent
Multimedia accessibility is overall not an easy undertaking.
The architecture is as open as possible in the way of technology to use.
Matterhorn Engage Videoplayer
Matterhorn will be shipped with "out of the box" servers (download + streaming) to let users watch the recordings. The server solutions that will come with Matterhorn are open source based.
There are many reasons why this open source servers will not be the perfect candidates for every adopter.
Matterhorn Engage will take this into account. Whether it is Flash video, Quicktime or HTML5 video content the architecture is not limited to a certain format.
A AjaxBridge will be used to notify the videodisplay(s) about user interaction.
Different player mockups are currently discussed Media Player Mockups.
Engage Videoplayer view states
Single video
Multistream videoplayer Ingest Flow Internal server error Potential workflows for Admin App
These workflows illustrate potential flows of information (including user, service & database interactions as well as application and hardware interfaces) both with and without Bedework. Admin UI Component Diagram 1 - Ingest Only Admin UI Component Diagram 2 - Ingest and manual scheduling with Bedework Admin UI Component Diagram 3 - Import from my Scheduling System, Ingest, and use Bedework for manual scheduling Admin UI Component Diagram 4 - Import from my Scheduling System and Ingest only (no Bedework, no manual scheduling) Admin UI Component Diagram 1 - Ingest Only
This is likely to be used by the Cobbler, but may also be useful in special cases for other organizations (e.g. providing a simple encoding service to a department, or the campus). Internal server error Admin UI Component Diagram 2 - Ingest and manual scheduling with Bedework
This set-up is also likely to be used by the Cobbler. The Cobbler does not yet have the strong need to integrate with campus systems and would like a Matterhorn system that works 'out of the box' without much customization. Internal server error Admin UI Component Diagram 3 - Import from my Scheduling System, Ingest, and use Bedework for manual scheduling
This set-up is more likely to be used by the Sophisticate. Internal server error Admin UI Component Diagram 4 - Import from my Scheduling System and Ingest only (no Bedework, no manual scheduling) Internal server error
In this situation, Bedework would not be used at all. We are unsure if this is an actual configuration that potential Matterhorn customers would want--further investigation is needed. If it is, it would be more likely to be used by the Sophisticate. Flex frameworks
Documentation
Flex framework:
MH-257 select a FLEX framework which is used in creating user-interfaces
This document describes some issues during the evaluation process of choosing an architecture framework for Adobe Flex in the Opencast Project. A comparisson is done between the two Frameworks cairngorm and Swiz. While the Team in Osnabrück uses Cairngorm within the virtPresenter Project, Swiz claims to solve some serious problems that can not be addressed by Cairngorm The main issues are: Pro: - Command Chaining: DynamicCommand can be added to a CommandChain object, which is useful for running a series of tasks a the same time before proceeding to a final task - Module Support: Beans with controllers, delegates, events etc. can be assigned to a certain Flex Module. - Less code: Certain repetitive steps of code generation, e.g. creating Cairngorm-Events/-Commands can be done much more elegantly with Swiz Contra: - Still Version 0.6.2 - it's not documented if swiz has been used in production projects yet - virtPresenter successfully used Cairngorm for many years Media Portal showcase for Matterhorn functionality... Internal server error Components Schedule Services
Components Process and Encode UIs
Components Process and Encode Other
Components Process and Encode Drafts
Components Engage Drafts
Components Distribute Drafts
Components Common UIs Components Common Services
Components Common Other
Components Common Drafts
Components Capture Drafts CaptureAgentService_Draft CaptureAgentService_Draft
CaptureAgentService
This service specification is still a draft. It may (and probably will) be split in different simpler services, even though all of them are related with the Capture Agent, seen as a whole from the Core perspective
Version SNAPSHOT CaptureAgentService Release Notes
Classification Process:Capture:Agent
Description This service manages capture agents, as well as their locations, schedules and status.
Context
Assumptions As per 0.5 release, this service is not intended to be used directly. An iCal file should be provided and the Capture Agent must call its services by itself.
Service IngestService, ZipUtil (in Utils) Dependencies
Known Clients Other tools or services that use this service
Security Particular security requirements
Operations
In the following overview, RecordingID is not a class name, but a String object containing a certain recording ID.
Name RecordingID startCapture()
Description Starts a single capture in the agent
Notes This operation is suppossed to call startCapture(MediaPackage, Properties) with default values for the MediaPackage and Pr operties parameters, but this feature is not currently well supported, since this call is not yet used. startCapture(MediaPackage, Properties) is the only signature for this method that should be relied on. Returns the ID of the started capture
Name RecordingID startCapture(Properties)
Description Starts a single capture in the agent applying the given Properties
Notes This operation is suppossed to call startCapture(MediaPackage, Properties) with default values for the MediaPackage parame ter, but this feature is not currently well supported, since this call is not yet used. startCapture(MediaPackage, Properties) is the only signature for this method that should be relied on. Returns the ID of the started capture
Name RecordingID startCapture(MediaPackage)
Description Starts a single capture in the agent with the given MediaPackage
Notes The MediaPackage here acts as a mechanism to store all the files what are relevant to this capture, even before it has been recorded, such as attachments, metadata catalogs, etc., which are sent from the core to the agent when the capture is scheduled and sent back from the agent to the core once the recording is finished. This operation is suppossed to call startCapture(MediaPackage, Properties) with default values for the MediaPackage and Pr operties, but this feature is not currently well supported, since this call is not yet used. startCapture(MediaPackage, Properties) is the only signature for this method that should be relied on. Returns the ID of the started capture Name RecordingID startCapture(MediaPackage, Properties)
Description Starts a single capture in the agent with the given MediaPackage and applying the given Properties
Notes This method does the actual service. The previous ones are suppossed to construct any of the missing parameters and call this one afterwards Returns the ID of the started capture
Name boolean stopCapture()
Description Stops the capture currently in progress
Notes Returns true if all went well or false if some error happened or nothing was being captured when this method was called
Name RecordingID getAgentState()
Description Returns the current state of the Capture Agent, which should be one of the defined in AgentState
Notes
Name boolean stopCapture(RecordingID)
Description Stops the current capture if its RecordingID matches the specified
Notes Returns true if all went well or false if some error happened, nothing was being captured when this method was called or the active capture ID does not match the specified RecordingID
The following methods are not in the API (yet!) but they perform essential operations for this service
Name boolean createManifest(RecordingID)
Description Creates the manifest (i.e. serializes the MediaPackage associated with the specified recording)
Notes
Name boolean zipFiles(RecordingID)
Description Compresses the files listed in the specified recording's MediaPackage, plus the manifest
Notes Uses the zipUtil class
Name int ingest(RecordingID)
Description Calls the addZippedMediaPackage REST endpoint from the IngestService to input the zip file created with the previous method
Notes Returns the HTML response code (roughly speaking, 200 is an OK, and 400 something is an error)
Bindings
Type Java
JavaDocs http://build.opencastproject.org/apidocs/
Source http://source.opencastproject.org/svn/modules/opencast-capture-service-api/trunk/src/main/java/org/opencastproject/capture/api/CaptureAgent.java
Type REST
Documentation
WADL
Type SOAP
WSDL
Live media capture architecture Internal server error Internal server error Service Definitions - Process-Encode DEPRECATED Encoder Service (OLD Matterhorn Project **DON'T USE**) service_description service process-encode
Release 0.5 ~ Deliverables (Aug. 09 - Jan. 10) Unknown macro: {redirect} Release 0.5 ~ Iterations (Aug. 09 - Jan. 10) Unknown macro: {redirect} Release 0.5 ~ Scenarios (Aug. 09 - Jan. 10) Unknown macro: {redirect} Step 1 - config.sh
#!/bin/sh
#location of the opencast source files export OC=~/opencast #location of felix export FELIX_HOME=~/felix-framework-2.0.1 #location of the local maven repo export M2_REPO=~/.m2/repository #url to the version of opencast you want to build export OC_URL=http://source.opencastproject.org/svn/products/matterhorn/trunk/ #url to the felix framework, use version 2.0 or beyond export FELIX_URL=http://apache.mirror.iweb.ca/felix/felix-framework-2.0.1.tar.g z #where java installs into export JAVA_HOME=/usr/lib/jvm/java-6-sun #maven needs a bit more memory export MAVEN_OPTS="-Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m"
#write environment variables to login file echo "export OC=$OC" >> .bashrc echo "export FELIX_HOME=$FELIX_HOME" >> .bashrc echo "export M2_REPO=$M2_REPO" >> .bashrc echo "export OC_URL=$OC_URL" >> .bashrc echo "export FELIX_URL=$FELIX_URL" >> .bashrc echo "export JAVA_HOME=$JAVA_HOME" >> .bashrc echo "export MAVEN_OPTS=\"$MAVEN_OPTS\"" >> .bashrc
#add a couple of helpful aliases to the bashrc #todo: we shouldn't have to skip tests, but they are buggy echo "alias buildmh='mvn install -DdeployTo=$FELIX_HOME/load -DskipTests'" >> .bashrc echo "alias buildcleanmh='mvn clean install -DdeployTo=$FELIX_HOME/load -DskipTests'" >> .bashrc echo "alias startmh='$OC/docs/felix/bin/start_matterhorn.sh'" >> .bashrc #update aliases source .bashrc
#set autoaccept for sun jdk sudo debconf-set-selections < #by default the ubuntu vms are only setup with universe in /etc/apt-sources; jdk needs multiverse? #todo: this url to the ubuntu mirror close to me is hard coded, it should be a param sudo echo "deb http://aifile.usask.ca/apt-mirror/mirror/archive.ubuntu.com/ubuntu/ karmic main restricted universe multiverse" > sources.list sudo echo "deb http://aifile.usask.ca/apt-mirror/mirror/archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe multiverse" >> sources.list sudo echo "deb http://security.ubuntu.com/ubuntu karmic-security main restricted universe multiverse" >> sources.list sudo mv sources.list /etc/apt/sources.list sudo apt-get update #setup local system packages #base packages sudo apt-get -y --force-yes install ssh maven2 subversion wget sun-java6-jdk curl update-motd expect-dev expect #check out the matterhorn build #todo: lock this to a particular revision number mkdir $OC svn co $OC_URL $OC cd .. #check out and install felix curl $FELIX_URL | tar xz mkdir ${FELIX_HOME}/load #build matterhorn cd $OC buildcleanmh #install felix config files cp -r $OC/docs/felix/conf/* $FELIX_HOME/conf/ #start matterhorn startmh #todo: write an updated message of the day file #todo: set clock to sync with time server? important for capture agents? Step 2 - external_tools.sh #todo: more packages, from the wiki, unclear if they are needed sudo apt-get -y --force-yes install zlib1g-dev patch byacc #todo: some of the third party libraries are packages #opencv sudo apt-get -y --force-yes install libcv1 libcv-dev opencv-doc #ffmpeg support #http://ubuntuforums.org/showthread.php?t=786095 sudo apt-get -y --force-yes install build-essential subversion git-core checkinstall yasm texi2html libfaac-dev libfaad-dev libmp3lame-dev libsdl1.2-dev libtheora-dev libx11-dev libxvidcore4-dev zlib1g-dev git clone -n git://git.videolan.org/x264.git cd x264 git checkout fe83a906ee1bb5170b112de717818e278ff59ddb ./configure make sudo checkinstall --fstrans=no --install=yes --pkgname=x264 --pkgversion "1:0.svn`date +%Y%m%d`-0.0ubuntu1" --default cd .. #todo: should be safe to delete x264 sources now svn checkout -r 21076 svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg cd ffmpeg ./configure --enable-gpl --enable-nonfree --enable-pthreads --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libxvid --enable-x11grab make sudo checkinstall --fstrans=no --install=yes --pkgname=ffmpeg --pkgversion "3:0.svn`date +%Y%m%d`-12ubuntu3" --default #install media info wget http://downloads.sourceforge.net/zenlib/libzen0_0.4.8-1_i386.Ubuntu_9.04 .deb sudo dpkg -i libzen0_0.4.8-1_i386.Ubuntu_9.04.deb rm -f libzen0_0.4.8-1_i386.Ubuntu_9.04.deb wget http://downloads.sourceforge.net/mediainfo/libmediainfo0_0.7.24-1_i386.U buntu_9.04.deb sudo dpkg -i libmediainfo0_0.7.24-1_i386.Ubuntu_9.04.deb rm -f libmediainfo0_0.7.24-1_i386.Ubuntu_9.04.deb wget http://downloads.sourceforge.net/mediainfo/mediainfo_0.7.24-1_i386.Debia n_5.deb sudo dpkg -i mediainfo_0.7.24-1_i386.Debian_5.deb rm -f mediainfo_0.7.24-1_i386.Debian_5.deb #ocr support sudo apt-get -y --force-yes install libpng12-dev libjpeg62-dev libtiff4-dev sudo apt-get -y --force-yes install tesserat-ocr cd /usr/share/tesseract-ocr #install english language file sudo curl http://tesseract-ocr.googlecode.com/files/tesseract-2.00.eng.tar.gz | sudo tar xz cd tessdata sudo chmod 755 * Step 3 - capture_agent.sh #! /bin/sh # Configure capture agent for use with Matterhorn echo "Installing third party packages from Ubuntu repository..." sudo apt-get update sudo apt-get -y --force-yes install v4l-conf ivtv-utils ant echo "Installing jv4linfo..." mkdir /tmp/jv4linfo cd /tmp/jv4linfo wget http://luniks.net/luniksnet/download/java/jv4linfo/jv4linfo-0.2.1-src.ja r jar xf jv4linfo-0.2.1-src.jar cd jv4linfo/src # The ant build script has a hardcoded path to the openjdk, this sed line will # switch it to be whatever is defined in JAVA_HOME sed -i "s#\"\/usr\/lib\/jvm\/java-6-openjdk\/include\"#\"$JAVA_HOME\/include\"# g" build.xml ant sudo cp ../lib/libjv4linfo.so /usr/lib cd /tmp rm -rf jv4linfo sudo mkdir /opencast sudo chown opencast:opencast /opencast mkdir /tmp/vga2usb cd /tmp/vga2usb wget http://www.epiphan.com/downloads/linux/vga2usb-3.23.7.2-2.6.31-16-generi c-i386.tbz tar jxf vga2usb-3.23.7.2-2.6.31-16-generic-i386.tbz make load cd .. rm -rf vga2usb #configure users/directories #install with -Pcapture in maven #set clock against time server Service Definitions - Schedule Archive Docs - Capture This is a space to archive planning or reference documents related to the Capture component Archive Docs - Cross-Component This is a space to archive planning or reference documents related to the Administration component Archive Docs - Distribute This is a space to archive planning or reference documents related to the Distribute component Requirements - Cross-Component Requirements, or Stories of this component... could be a Jira Include? Archive Docs - Process-Encode This is a space to archive planning or reference documents related to the Process-Encode component Archive Docs - Schedule This is a space to archive planning or reference documents related to the Capture component BA-UX - Capture Business Analysis/User Experience aspects of this component Ingestor Interface QUESTIONS AND STATEMENTS FOR THE BA/UX MEETING 2008-08-06 POSSIBLE SCENARIOS FOR INGESTION "dump" uploader, uploads only the video without knowing the context, cameraman uploads video after lecture, doesn't know the exact title, teacher name, ... "regular" uploader, admin uploads media and all necessary metadata lecturer knows the metadata but doesn't have the video webcast administrator wants to enter the metadata about a course or event prior to the event/lecture, and will later upload the video alternative: divided in upload / metadata / processing As an administrator, I would like to upload a media file into the matterhorn pipeline after the recording is finished in order to get it into the system. (It will not be processed or distributed.) As an administrator, I would like to add metadata to a recording I've already uploaded and then have it processed and distributed to iTunes via an RSS feed. As an administrator, I would like to upload a media file into the matterhorn pipeline after the recording is finished in order to have it processed and distributed to iTunes via an RSS feed. TASKS input / edit metadata / multiple languages, different data sets (metadata editor gadget) upload multiple metadata, e.g. caption upload multiple media (video, audio, vga, ...) upload attachments (slides, PDFs, images) input relations (which series? email notification) import metadata (from LMS, inherit from series, ...) select distribution channel select output format and/or quality QUESTIONS when do I enter metadata, before or after upload? what is the minimal information for the ingest? what are the required felds? should this minimal information be enough for distribute media what informations does the site conductor need? are the distribution options part of the ingest? are captions part of the ingest? are captions labeled as metadata? UI: one or multiple upload dialogs / screens for media, metadata, attachments, captions how many gadgets are in the ingestor, "editor" more gadgets? should the ingestor a re-engestor, e.g. add hd-video, change video, captions, delete one media file how do I select the series that the media package belongs to? how do I track the status of the currently ingested media packages? list of my own packages, do we have some kind of user management? search packages status / error information by email multi language support for ingestor UI? i18n of the UI? (general question for all admin tools) Components Process and Encode Services BA-UX - Schedule Business Analysis/User Experience aspects of this component Meeting Goals & Activities Overall Meeting Goals Synchronization - bring teams together on the same page, resolve common services, cross-team fertilization of ideas Generate Code - peer programming, designing services, bootstrapping personal dev environments, on the spot training. Progress assessment - are we on target to meet our goals? ahead? Open issues - group resolution Funding strategies - for the board, prepare for post Mellon year 1 grant Adoption measurement and strategies Revisit issues on "process" - what's working? what's not? are people following the process? Schedule Unknown macro: {html} Design Studio PROCESS Goal: Design an interface to meet the needs of the Scenario. Step 1: Read scenario Step 2: Come up with list of functional elements and data elements (what do users need to do, what do users need to see) Step 3: Collaboratively sketch ideas Step 4: Create screens that show the flow thru the scenario To remember: Make mistakes faster. Goal is idea creation, not perfection. Write down assumptions you need to make (i.e. if something missing from the scenario) as well as any questions or comments that come up. SCENARIO It's Monday morning on the second week in the semester and Cobbler U is podcasting 40 different courses. When Mary comes in at 7:45 a.m., she takes a look to see which ones will be recorded today. She also does a quick check to make sure that all the capture agents are okay. No classes have started yet, but everything looks fine. Even Schulte Hall, the room in which the capture agent failed last week. Thinking about that, she checks to see which recordings will happen in Schulte Hall today, and see that there are four of these, one of which will start in a few minutes, at 8. She makes a mental note to take a look when class starts to be sure everything is okay. In the meantime she checks her email; the only thing that requires immediate action is a request to cancel the recordings of Professor Hochman, who is sick today. She locates the course that Professor Hochman teaches (Anatomy 221) and cancels today's lecture, which is supposed to happen at 11 a.m. The phone rings (it's Mary's son who has a quick question to ask before he heads off to school) and by the time Mary hangs up it's 8 a.m. Mary confirms that everything is working fine in Schulte Hall. She also checks to be sure capture is happening for the six 8 a.m. courses in which it's supposed to be happening right now. She also double-checks to be sure that Anatomy 221 won't be recorded today. Mary checks email again and this time there is a request from Professor Ketterl saying that his Tuesday-Thursday 2 pm course was just moved into Brooks Hall, one of the rooms that's equipped for podcasting, and that he's excited about having the course video podcast so he can have students (and the rest of the world) access it via his blog. Mary adds a new recurring recording to the system, providing the info she knows (who's teaching, the name of the course, the days and times of the course, and the location of the course). She also specifies that only video/audio should be captured, and that it should be available in the Matterhorn Media Module. She indicates that she's done for now; the system generates and displays a list of recordings that are now scheduled to occur for this course. She then checks the list of tomorrow's recordings to confirm that Professor Ketterl's lecture tomorrow afternoon is set to be recorded. DATA AND FUNCTIONAL NEEDS See: recordings for today state of capture agents recordings for today in a specific room Do: cancel recording of a lecture add recurring event provide info about the course specify what should be captured where to distibute to EXAMPLE OF PROTOTYPING DESIGNS WITH PAPER http://www.alistapart.com/articles/paperprototyping/ (scroll half-way down the page) BA-UX - Cross-Component Business Analysis/User Experience aspects of this component About the Project An enterprise-level, easy-to-install open source podcast and rich media capture, processing and delivery system Matterhorn is... Matterhorn is an end-to-end platform that supports the scheduling, capture, managing, encoding and delivery of educational audio and video content. The features planned for the first release, scheduled for July 2010, include: Administrative tools for scheduling automated recordings, manually uploading files, managing metadata Recommended capture agent hardware specifications Integration with recording devices in the classroom for managing automated capture Distribution to channels such as YouTube, iTunes, and supporting services, such as RSS, to push content to campus course or content management system Rich media user interface for learners to engage with content, including playback, content-based search, and captioning Processing and encoding services that prepare and package the media files for distribution Matterhorn is also a media services framework. It will be flexible and services-based, so that organizations can choose to implement only the components they need, or replace default service implementations with their own to meet specific institutional needs. Value to institutions For institutions who want to easily produce audio and video webcasts and podcasts, Matterhorn will significantly lower the technical and cost barriers to entry. The Matterhorn 1.0 release will be an easy-to-install, out-of-the-box system with automated workflows. For institutions who want to expand and evolve their existing commercial or homegrown systems, Matterhorn's service-based architecture allows institutions to implement only the components they need, or replace default service implementations with their own to meet specific institutional needs. Matterhorn is backed by a large community comprised of world-class experts in many domains relevant to audio and video technology and academic content production and delivery. Through engagement with the Opencast Community, Matterhorn will continue to evolve in response to advances in technologies, emerging needs of end users, and lessons learned by all along the way. Roadmap for 0.5 Release After a year-long planning and community-building effort, development officially kicked off in July 2009. Matterhorn will have multiple releases prior to its 1.0 Release in July 2010. Release 0.5, the first preview release, has been available since Feb. 2010 and contains basic functionalities to ingest, process, and deliver media.. An updated roadmap is available with detailed outcomes and deliverables for our 0.5 release, as well as a high-level overview of scenarios and story cards broken down by iteration. Join Matterhorn Subscribe to the Community and Matterhorn mailing lists. Visit the Opencast Matterhorn wiki for project planning and documentation. Log on to the Tuesday Matterhorn Weekly Meeting and introduce yourself! Got something that you think could add value to Matterhorn? Please share with the community to discuss, collaborate and contribute. Matterhorn Team & Community The initial development effort, led by UC Berkeley Educational Technology Services and ETH Zürich, was launched in collaboration among 13 partner institutions from North America and Europe who have made a commitment of resources toward the 1.0 release. UC Berkeley ETH Zürich University of Osnabrück Cambridge University Indiana University Northwestern University Jozef Stefan Institute Open University of Catalonia University of Copenhagen University of Nebraska-Lincoln University of Saskatchewan University of Toronto University of Vigo Matterhorn is an open source software project and is supported by a growing international community that includes over 700 members from more than 300 organizations. Community input is welcome and critical to the success of the project. Acknowledgements The Opencast Matterhorn project is funded in part by generous grants from the Andrew W. Mellon Foundation and the William and Flora Hewlett Foundation. Partners The institutions below have made a commitment to participate in the Opencast Matterhorn Project. Institution Institution Name Institution Lead University of California Berkeley Mara Hancock ETH Zurich Armin Brunner University of Osnabrueck Markus Ketterl Cambridge University John Norman Indiana University Martin Wagner Jozef Stefan Institute/Videolectures.net Mitja Jermol Northwestern University Bob Davis Open University of Catalonia Josep Rivera University of Copenhagen Uwe Wollin University of Nebraska-Lincoln Bruce Sandhorst University of Saskatchewan Christopher Brooks/James Greer University of Toronto Jutta Treviranus Fluid Project University of Vigo Vicente Goyanes People UNIVERSITY OF CALIFORNIA BERKELEY CAMBRIDGE UNIVERSITY UNIVERSITY OF COPENHAGEN Mara Hancock John Norman Uwe Wollin Project Director Institutional Lead Institutional Lead Adam Hochman Tony Stevenson Jamie Hodge Matterhorn Project Manager Systems Administrator Developer Josh Holtzman Architecture & Process Services Team Aaron Zeckoski Lars Palmqvist Technical Lead Developer Architecture & Process Services Team Developer Architecture & Process Services Team Thomas Schlichting Allison Bloodworth Developer BA Lead INDIANA UNIVERSITY User Experience & Business Analysis UNIVERSITY OF NEBRASKA-LINCOLN Team Martin Wagner Bruce Sandhorst Judy Stern Institutional Lead Institutional Lead UX Lead Manjit Trehan User Experience & Business Analysis Micah Sutton Team Release Manager Michelle Ziegmann Developer NORTHWESTERN UNIVERSITY Admin Tools Team Communications Coordinator Bob Davis UNIVERSITY OF SASKATCHEWAN ETH ZÜRICH Institutional Lead Christopher Brooks Armin Brunner Jonathan Smith Institutional Lead Developer Institutional Co-Lead/Project Manager Xin Xiang Capture Team Christoph Driessen Architecture & Process Services Team Developer Jim Greer Olaf Schulte JOZEF STEFAN INSTITUTE Institutional Co-Lead Product Manager Kristofor Amundson User Experience & Business Analysis Mitja Jermol Team Institutional Lead Developer Tobias Wunden Peter Kese Capture Team Developer Greg Logan Technical Lead Architecture & Process Services Team Boštjan Pajntar Developer UNIVERSITY OF OSNABRÜCK Capture Team Developer Architecture & Process Services Team Markus Ketterl UNIVERSITY OF TORONTO Nejc Škofi Jutta Treviranus Institutional Lead UI Lead Developer Institutional Lead Engage and Admin Tools Teams Heidi Hazelton OPEN UNIVERSITY OF CATALONIA Stefan Altevogt Developer Josep Rivera Developer Engage Team Engage Team Institutional Lead Laurie McArthur Engage Team Accessibility Specialist Nils Birnbaum Engage Team Alicia Valls Saez Quality Assurance UNIVERSITY OF VIGO User Experience Specialist Johannes Emden Engage Team Vicente Goyanes de Miguel Developer Juan Antonio Recia Valls Engage Team Institutional Lead Developer Capture Team Clemens Gruber Engage Team Ruben Gonzalez Project Manager Engage Team Developer Capture Team Marcus Lunzenauer Ruben Perez Vazquez Quality Assurance (Rubencino) Rudiger Rolf Developer Capture Team Developer Engage Team Benjamin Wulff Developer Engage Team Committers ollowing are developers on the Matterhorn project with commit rights: Kristofor Amundson, University of Saskatchewan Christopher Brooks, University of Saskatchewan Jamie Hodge, University of Copenhagen Josh Holtzman, University of California Berkeley Markus Ketterl, University of Osnabrueck Greg Logan, University of Saskatchewan Bostjan Pajntar, Jozef Stefan Institute Ruben Perez, Universidade de Vigo Ruediger Rolf, University of Osnabrueck Nejc Skofic, Jozef Stefan Institute Tony Stevenson, Cambridge University Micah Sutton, University of Nebraska-Lincoln Manjit Trehan, Indiana University Ruben Perez Vazquez, Universidade de Vigo Benjamin Wulff, University of Osnabrueck Tobias Wunden, ETH Zurich Aaron Zeckoski, Cambridge University Advisories Matterhorn leadership and the development teams will make use of stakeholder advisory groups to inform their work. This is intended to ensure that key users and campus stakeholders are engaged with and informed about the project as well as subject matter expertise from across higher education. Members of the advisory groups will be providing guidance and input into the features, functions, and key technology outputs from the project. Their input will be sought in a variety of ways, either individually or as a group, determined by the need of the board, the Project Management Committee, or the development teams. They function purely on an advisory level and although their input will be highly valued, they do not have a binding vote in the decision-making process. The advisory groups are intended to exist for the longevity of the grant-funded project, and may not be necessary once Matterhorn is released and a solid user/adopter base is established that can continue to provide this input. Membership on an advisory group is acquired through invitation from the Matterhorn Project Management Committee (PMC) and the Matterhorn Board. Interested persons can request sponsorship from a member of the PMC or Board. Members of each advisory group will be chosen to ensure geographical and subject matter expertise representation. Three advisory groups will be formed: Technical, Functional and Executive. Executive Advisory The Executive Advisory group will be formed by the Matterhorn board and acts as a group of high level consultants to the Opencast Matterhorn board. They will be called on as individuals and as representatives of their organization and/or constituency to provide feedback toward the direction of the project and Matterhorn product. This group will be called on to participate in a one hour group call once at the beginning of the project, once in the middle and once toward the end. Board members may call on individuals for specific advice or outreach. Executive Advisory Members Hal Abelson, Massachusetts Institute of Technology Hervé Bourlard, IDIAP Research Institute Malcolm Brown, EDUCAUSE Learning Initiative Tiffiniy Cheng, Participatory Culture Foundation Gerald Friedland, International Computer Science Institute Ross Gardler, Open Source Software Watch Obadiah Greenberg, YouTube Peter Kaufman, Intelligent TV Sean Mehan, University of Highlands and Inlands (Sabhal Mòr Ostaig UHI) Mike Sandler, Epiphan John Shawe-Taylor, University College London Scott Siddal, Longsight Group Functional Advisory The Functional Advisory group will consist of campus and higher education stakeholders to include campus IT, faculty, students, and media specialists. The primary mission for this group is to help the team ensure that the applications and functionality of the system meet the needs of its primary users. Technical Advisory The Technical Advisory group will consist of campus stakeholders to include enterprise IT architects, database administrators, and media specialists. The primary mission for this group will be to help the project establish/prepare as seamless an integration process as possible. Project Coordination Calendar Meetings Admin Team Meeting Notes BA-UX-UI Meeting Notes Capture Team Meeting Notes Distribution Team Meetings Engage Team Meeting Notes Product Owner Meeting Notes Services and Architecture Team Meeting Notes 2010-02-15 Developer Meeting Notes Weekly Matterhorn Meeting (SoS) Notes Archive of Past Meetings Deep Dive Agenda Zurich meeting September 21-25 Travelling to and in Zurich Year 2 Brainstorm Communications & Adoption Strategy Working Group Notes Year 2 Planning Meeting Notes Communication Community Newsletter Opencast Matterhorn Newsletter - October 2009 Opencast Matterhorn Newsletter - August 2009 Opencast Matterhorn Newsletter - December 2009 (draft) Site restructuring process - working document Revision Proposal for www.opencastproject.org Matterhorn Introductory Tour Video Governance Roles and responsibilities Decision Making Process Accessibility QA process Agile and UX - Observations, Suggestions, and Questions Contributor Guide High Level Iteration Process Roles and Expectations Project Tool Tips Making Decisions Communication Practices Development Practices Signing an Opencast CLA and CCLA Glossary Definition of engage activities and functionalities Adding Demo Data To Your Instance (Release 0.5) Matterhorn Basecamps Strategy 6 Month Priorities and Resource Allocation Iteration Planning Adoption Strategy Base Camp Candidates Release 0.5 Board Meeting Update Considered Year 2 Requirements Considered Year 2 Requirements (decision table) Year 2 Requirements - top level decision making Calendar Unknown macro: {redirect} Meetings Resources Subscribe Subscribe to the Matterhorn Meeting Notes RSS Feed Opencast 2009 Meetings iCal Feed (meetings only) Matterhorn 2009 Team Calendar iCal feed (includes meetings + "time off" notices) HowTo Scheduling and Documenting Meetings Weekly Meetings Following is a list of standing meetings for the Opencast Matterhorn project. All meetings are announced via the Matterhorn mailing list, and are posted on the Opencast Meetings & Events. A record of minutes and link to a recording are also available from [link to be posted] (for most meetings). Most meetings take place in the Opencast Connect Room or Opencast Connect Room #2, but check your email and the meetings page as this may change. Weekly Meeting Schedule-at-a-Glance Time (Pacific) Monday Tuesday Wednesday Thursday Friday 7:00 am Distribution Team 8:00 am Capture Team | Services & Architecture Team Weekly Scrum of Scrums Services BA/UX/UI (8:30) 9:00 am Admin Team Product Owners (note: this meeting sometimes starts early if Scrum of Scrums ends early) Product Owners Communications/Adoption (9:30) WEEKLY MEETINGS DETAIL Meeting Lead Day PST MST CST EST GMT CET Required attendees Weekly Matterhorn (Scrum of Scrums) Meeting Tuesdays 8am 9am 10am 11am 4pm 5pm All project managers and technical leads; Adam All team members are strongly encouraged to attend | Weekly Matterhorn Product Owner's Meeting Adam Tuesdays & Wednesdays | 9am (or when SOS ends; could be as early as 8:30am) | 10am (or as early as 9:30am) | 11am (or as early as 10:30 am) | 12pm (or as early as 11:30 am) | 5pm (or as early as 4:30 pm) | 6pm (or as early as 5:30 pm) | All product owners, project managers and BA/UX team | Weekly BA/UX/UI Meeting (Business Analysis/User Experience/User Interface Development) Allison , Judy , Olaf , and Clemens | Thursdays | 8:30am | 9:30am | 10:30am | 11:30am | 4:30pm | 5:30pm | BA/UX/UI Team | Services & Architecture Team Meetings Mondays 8am 9am 10am 11am 4pm 5pm Services & Architecture Team Josh and Tobias Capture Team Meeting Mondays 8am 9am 10am 11am 4pm 5pm Capture Team Chris Admin Team Meeting Mondays 9am 10am 11am 12pm 5pm 6pm Admin Tools Team Chris Services Meeting Wednesdays 8am 9am 10am 11am 4pm 5pm All developers implementing services are strongly encouraged to come. Josh and Tobias Distribution Team Meeting Fridays 7am 8am 9am 10am 5pm 6pm Distribution Team Martin Engage Team Meeting Engage Team Clemens Communications & Adoption Strategy Working Group Olaf Thursdays 9:30am 10:30am 11:30am 12:30pm 5:30pm 6:30pm Olaf, Michelle, Adam & interested others Year 2 Planning Meetings Adam Varies Announced on list Special Meetings All-Hands Matterhorn Meeting, September 21-25, 2009 in Zurich, Switzerland: View meeting summary Matterhorn Leadership and Planning Meeting, Apr 27-May 1, 2009 in Berkeley, CA: View meeting summary Archive of Planning Meetings Most Recent Meeting Notes Blog stream Create a blog post to share news and announcements with your team and company. Create blog post Admin Team Meeting Notes Tag News posts with "admin" to include it here. Admin Team Meeting 2009-12-21 Judy Stern posted on Dec 21, 2009 Attendees: Chris, Benjamin, Micah, Judy Notes: 1) New Uploader Benjamin implemented an uploader that's pure AJAX. Achieved to upload 1.1 gig file and it went thru whole pipeline. (Took 8 to 9 hours to code.) http://outstack.virtuos.uos.de:8080/ingest/ui/upload.html Ingest service REST endpoint had to be changed; Benjamin not sure if we can switch, need to check with Josh/Tobias. One big thing against AJAX approach is we don't want ot have sticky sessions. Not sure request is always rooted to same instance of ingest service. But way Benjamin does it, don't need sessions. Can be several instances of ingest service that can ask for upload progress. To change from SWF to this is 2 to 3 days. Not a big thing. Chris tried to ingest file in real time. Said it ingested it too quickly. 2.21 gigs. Benjamin reminds that can't do more than 2 gigs. Browser limitation. In Sakai they do it with signed java applet. Chris not for or against java applet, likes AJAXian approach. Chris asks if at a point where Benjamin can put proposal to list to switch; have decision by Christmas. Benjamin wants to test further. (e.g. there are some problems with filenames) Agrees to send out proposal. (Chris did quick test and found it didn't work in IE...progress only updated to 1%.) Official supported files are H.264 and MPEG-2. Not all third party tools installed. Chris points Benjamin to https://wiki.opencastproject.org/confluence/display/open/How+to+Build+a+Virtual+Machine and https: //wiki.opencastproject.org/confluence/display/open/3rd+Party+Tools+Script 2) Harmonizing CSS Status of harmonizing CSS? Micah reports that, in terms of using same CSS, it's not happening. But he's updated Scheduler to look like Ingest. Thinks that's the right approach for 0.5. Due to slight differences in html. Fully aligning both files isn't worth it for 0.5 release. Since we're talking about merging UI's post-0.5, it would be more efficient to just wait. Chris would really like to see all of the UI's merged for 0.5, would add more cohesion. (Not to mention efficiencies of sharing code, etc.) Wants everythiing in Admin UI bundle. Micah reports that on IRC, Adam didn't think we should put the time into it in iteration 7, since we should be focused on bug fixes. Asks Benjamin if he'll be affected if we start moving stuff into admin UI bundle. AJAX uploader is single html file with javascript included. No CSS involved. Micah will work next few days, won't promise getting it done, but will aim for end of this month. Benjamin's plan is to take with Micah doing and build new ingest UI accordingly. Chris tells Micah when he's got patch to deploy to use "blocker" so Chris will get it up asap. admin 2009-12-11 Matterhorn Visual Design Meeting Allison Bloodworth posted on Dec 11, 2009 Visual Styles Meeting 12/11/09 Attendees: Adam, Allison, Benjamin, Chris, Judy, Michelle Recording: http://uvigo.emea.acrobat.com/p67784021/ Agenda: Michelle needs help gathering the existing resources for this: Chris' mockup (installation page)? - https://wiki.opencastproject.org/confluence/display/open/Welcome+Page+-+Install ation Current style sheet(s)? Welcome page brainstorming: https://wiki.opencastproject.org/confluence/display/open/Welcome+Page+Brainstorming Rough outline of tasks and resources: installation page mockup (adam?) all uis: design (ben & michelle) all admin uis + welcome: application of design (michelle (welcome page), ben (others)) all admin uis + welcome: underlying implementation (micah) Benjamin will create subtasks of MH-259: create first reference implementation of visual styles iterate on reference implementation of visual styles Currently existing tasks: Implement user interface styles defined in MH-259 to non-Player 0.5 Engage UIs(MH-1685) - Markus Implement user interface styles defined in MH-259 to non-Player 0.5 Engage UIs (MH-1686) - Markus Implement user interface styles defined in MH-259 to 0.5 Admin UIs (MH-1687) - Benjamin Harmonize & re-structure all Matterhorn CSS (MH-1688) - Micah Implement user interface styles defined in MH-259 in 0.5 Welcome Page (Mh-1829) - Benjamin ^^ These are all children of: As a Matterhorn user I want User Interfaces that have a similar Look & Feel in order to administrate/schedule/change/ the system or to get system notifications. (MH-230) FUTURE Explore the use of an easy to use theming/skinnning engine (perhaps with a UI to set the styles) to set visual styles in Matterhorn (MH-1831) NOTES FSS being used on ingester & admin app, not scheduler or engage Benjamin will talk to Markus about assigning MH-1685 & MH-1686 to someone Benjamin will set up a time for interested parties to iterate on the CSS in IRC admin engage Admin Team Meeting 2009-11-09 Christopher Brooks posted on Nov 09, 2009 Recording: http://uvigo.emea.acrobat.com/p71854125/ Admin Team Meeting Agenda - How the JPA stuff is going (our week of work ends today) - 0.5 Admin App screens JPA - Ruediger: for the db, converting to JPA wasn't a problem, nice to use, nice API. Hard to get it working in OSGI. 1) Eclipse Link 2) Dynamic JPA worked. First started with #2 but there were bundles that couldn't be resolved. Aaron pointed Ruediger to Sakai. He's still going through this. He hopes he got it to work with Eclipse Link. There are still problems with the code, probably related to logging. He's not 100% confident that it will work. He'll know more tomorrow. If he doesn't succeed he suggests looking at it in a later iteration. - Chris: We'll touch base tomorrow and decide what to do. - Chris: creating a schedule and turning it into an iCal feed for agents is something we still need to do (From iteration 4) - Ruediger: I'll make a recommendation in the scrum of scrums - Chris: Micah, I got lots of your code in. Had trouble finding a patch in JIRA. Update on what you did last week? - Micah: spent the week wiring up the scheduling UI with Ruediger's scheduling service. Then got the UI in line with what we're doing in Ingest and BAUX spec. Now it should be working since we can submit events to the backend db (derby?). I don't know if we're writing iCal files from that. This week I have a few things left to do on the UI and then a service task about getting a list of scheduled events. - Chris: what about the tasks that were in but need to be closed? (finger over links) I'll close that. 0.5 Admin App screens - Chris: we have new screen Screen design is here: https://wiki.opencastproject.org/confluence/display/open/Release+0.5+Design - The bottom "Designs" section contains the list of screens for 0.5. - Top navigation might change a bit Capture Agents 0.5 - task this to Micah, "untask" it from Benjamin - Greg is building the back end service, as capture-admin-service - look to hook up capture pushing to capture-admin-service then pulling to the ui for next week - need to clarify the list of statuses by looking at previous wiki task - note, tables are sortable Recordings - Scheduled 0.5 - Benjamin - currently there is no date/time for when a recording was scheduled, perhaps there should be? Recordings - Processing 0.5 - Benjamin - processing time might not be available, so it is find to skip - what are the list of processing statuses? Recordings - Distributed 0.5 - Benjamin - links to actual webcasts to the matterhorn media portal - is there any actual distribution to the matterhorn media portal? Unclear, though Rudiger mentions that there is a search service that will show results, so shouldn't this bring up the same ui? - Note: bubbles represent tooltips - Allison: There is a double method of sorting, does this make sense? Maybe not... - Resolution is to break the first couple of columns up into two columns, and look into a natural method for secondary sorting for future iterations Schedule Recording 0.5 - Assigned Micah - sticking with radio buttons for 0.5, work progressing on the check box ideas - Micah: is licensing field a text field now instead of a drop down? Yes, but there are open questions for later iterations. - Going with capture agent for now, and see what user testing days - Talk about start time and duration, we're going with durations and *not* end times right now - Our 0.5 drop down fields should be something like :2 mins, 5 mins, 30 mins, 1 hour, 2 hours, 3 hours Discussion over sorting - xslt vs non xslt; open issue, rudiger loves xslt, chris disdaines it, rudiger is more likely to write the code that makes it work so chris will probably give...micah is on board with xslt - stress that sorting should be in the browser - sorting should not always be lexical (e.g. agent statuses), but in 0.5 they will be View Recordings - once we start capturing there is no way to edit for 0.5, but you can view the recordings Unpload Recordings - Note: text area for distribution - Change terminology from ingest to upload Todo: Names of primary UI dev should go behind the item on the wiki Todo: Benjamin and Micah need to discuss how to do the tables admin Admin Team Meeting 2009-10-21 A posted on Oct 26, 2009 Attendees: Benjamin, Ruediger, Allison, Micah, Adam, Judy Recording: http://uvigo.emea.acrobat.com/p24497429/ Agenda: Iter Audit: -Stories Iter 3,4,5 -Tasks 4 Ingester UI Mockup: http://wiki.opencastproject.org/confluence/display/open/Ingester+UI+-+v.3 Scheduler UI Mockup: http://wiki.opencastproject.org/confluence/display/open/Scheduler+UI+-+v.2 Ingestor UI Implementation: http://vm081.rz.uos.de:8080/ingest/ui/index.html auto-complete -> services have own UI and passed to two different services ingest UI Upload metadata with a post file operation ingest service generates dublin core xml scheduler UI creates xml document to pass to the scheduling service Chat: The chat history has been cleared. Tobias Wunden: Adam, could you stop the recording of the architects meeting? Tobias Wunden: Thanks! Benjamin Wulff: MH-? Adam Hochman: https://issues.opencastproject.org/jira/browse/MH-594 Adam Hochman: https://issues.opencastproject.org/jira/secure/VersionBoard.jspa?autoRefresh=false&start=0&type=VB&deco rator=none&selectedProjectId=10010&selectedBoardId=10020&viewType=list# Adam Hochman: https://issues.opencastproject.org/jira/browse/MH-997 Adam Hochman: https://issues.opencastproject.org/jira/browse/MH-1220 Ruediger: http://opencast.virtuos.uos.de:8080/workflow/ui/index.html Micah: It's not there. Looks like nightly isn't up-to-date Ruediger: looks like on our server Ruediger: http://opencast.virtuos.uos.de:8080/ Adam Hochman: temp for develpoers Micah: Excellent, Thanks Ruediger Benjamin Wulff: http://nightly.opencastproject.org/workflow/ui/index.html Benjamin Wulff: developers Allison Bloodworth: ok, we can talk more offline Adam Hochman: 1002 and 1271 Ruediger: i guess the FSS is not the interesting point. But the scheduler and ingestor mostly look the same at the moment. And much of the ingestor could be reused Allison Bloodworth: just what I was going to say Rudiger! Allison Bloodworth: micah, judy will be working on the scheduler UI today and making it look very much like the ingestor UI Judy: it's pretty much done! Allison Bloodworth: she's fast! Judy: The way Allison & I designed it, almost everythign is the same Judy: The only dif is that ingest has upload fields and schedulue UI has date/time & capture location fields Allison Bloodworth: who is working on this one? https://issues.opencastproject.org/jira/browse/MH-1039 Allison Bloodworth: ''As an administrator I want to see a list of scheduled events'' Allison Bloodworth: you can always go aheaad to the next iteration, right? Allison Bloodworth: if you finish what's in the current iteration Micah: I think that the list of scheduled events will be mine task. Allison Bloodworth: thanks micah. let us know if you have any questions about the mockup Ruediger: MH-722 for me I guess Micah: Is there one? Benjamin Wulff: not in place Allison Bloodworth: we may even want to allow configuration as to which elements show up Judy: agree Allison Bloodworth: http://wiki.fluidproject.org/display/fluid/Fluid+Project+Wiki Benjamin Wulff: that's what I understood from Ingest UI mockup v.3 Allison Bloodworth: 2 different issues I think Judy: is it that metadata search is required for autocomplete? Allison Bloodworth: can we finish answering autocomplete? Ruediger: autocomplete is searching the metadata Allison Bloodworth: i think it's like creating a reusable template Allison Bloodworth: rock on rudiger! Adam Hochman: freebird! Benjamin Wulff: like having building-blocks for the UIs Adam Hochman: that's true Adam Hochman: configurable and contextual Benjamin Wulff: if this is the case we will not come around a metadata-editor service.. Allison Bloodworth: i think the system will be a lot less flexible if people can't add custom fields. it's probably fine for now, but I'm not sure if it's a good long-term strategy Allison Bloodworth: ruediger, do you need a complete list of what all the metadata will be? Or can more metadata be added over time¿ Ruediger: https://wiki.opencastproject.org/confluence/display/open/Scheduler+Service Adam Hochman: +1 Allison Bloodworth: sure Allison Bloodworth: is there an agenda for the services team meeting we can add stuff to? Allison Bloodworth: i will look for it and add my questions... Allison Bloodworth: iot' Micah: This is the wednesday service meeting? Adam Hochman: y Micah: Or you mean, righ tnow? Micah: Okay. admin Admin Team Meeting 2009-10-05 Michelle Ziegmann posted on Oct 05, 2009 Recording: http://uvigo.emea.acrobat.com/p50583166/ Chris wondering about vision for job controller; Judy reports thatshe and Allison will be working on this over the next 2 weeks. Rudiger update: Zurich agreement: Micah doing front-end, Rudiger doing services We have basic story cards, e.g. schedule an individual event. Rudiger already spec'd out service and wrote to the list to get feedback. All messages re. creating events are there. Later, things like deletion. Need to deliver icalendar to capture agent; J&T concerned about idea of connecting calendar feed to capture agent id and not to the room, because agent may change but location will remain. Micah: Story cards created first, tasks attached to story cards? Later elaboration. Chris doesn't like this for investigative stories, but fine for user-facing stories. We'll iterate on the UI's. Chris not sure he agrees with J&T re. agent/room issue. Discussion to ensue on list. (Subject Scheduler service #proposal) Rudiger: no problem to provide 1st version of ical feeds for next iteration. Chris: need it for this iteration. Micah handling...carryover...has test files created, was waiting on standardized metadata fields. chris won't be around next Monday, but meeting should continue without him. UI's will be committed to subversion by then. admin Admin Tools Meeting 2009-08-21 Michelle Ziegmann posted on Aug 21, 2009 -clarify Ben's role -who assigns tasks? -who determines scope? -what is happening right now? -communication -ingest service -front end technologies: JQuery? - regular meeting time http://issues.opencastproject.org/jira/browse/MH-595 http://issues.opencastproject.org/jira/browse/MH\- Benjamin 0.5 (split) Johannes 0.5 (split) Rüdiger 1 Markus 1 Stefan Altevogt 1 Are the services will there be a UI service for every UI? where is the UI Do we want a separate service for the UI or is it part of the service bundle? One UI may need services across components? # not except media files, but attachments (pdf, ppt, caption) admin INGESTER UI 2009-08-07 Michelle Ziegmann posted on Aug 07, 2009 As an administrator, I would like to upload a single audio-file into the matterhorn pipeline after the recording is finished in order to get it into the system. (It will not be processed or distributed.) Acceptance tests: -Title field is required - accept any type of input. - User receives confirmation *on the screen* that the upload was successful. A progress bar indicates the progress of the upload. - Accepts upload of a single audio-video file As an administrator, I would like to upload multiple files (audio, video, VGA) into the matterhorn pipeline after the recording is finished in order to get it into the system. (It will not be processed or distributed.) Acceptance tests: -Title field is required - accept any type of input. - User receives confirmation *on the screen* that the upload was successful. A progress bar indicates the progress of the upload. - Accepts upload of multiple a/v vga files, workflow/interface to be determined Notes: - would the fluid uploader work? does it handle single file uploads? does Fluid provide a progress bar? - Allison to think through whether uploading files at once is too difficult. expert vs. novice user. As an administrator, I would like to add metadata to a recording I've already uploaded and then have it processed. As an administrator, I would like to add metadata to a recording I've already uploaded and then have it processed and distributed to iTunes via an RSS feed. Notes: How does the site conductor know what Series in VirtPresenter knows how a recording will be distributed. We can make distribution channels optional, but that is a field in the Ingestor user interface. As an administrator, I would like to create a series into which to place recordings. As an administrator, I would like to create a category into which to place recordings and series. As an administrator, I would like to create a series into which to place recordings and specify the distribution channel to all the recordings in the series. As an administrator, As an administrator, I would like to upload a media file into the matterhorn pipeline after the recording is finished in order to have it immediately processed and distributed to iTunes via an RSS feed. (do we need this storycard?) - gadgets: HTML page w/Javascript, everything is embedded in an iFrame - they are thinking of many gadgets with a little functionality and put multiple gadgets on a page - Eli told them to go this way, Clemens thinks there is no problem with this approach - do we need to start working on a user management system? - talk through with - Internationalization story card (user interface & admin interface) MPEG 7 - the user that uploads the media has info that needs to go into the file. Captions, chapters - can extract this info from the DVD. Several files that contain metadata information. user story: an administrator wants to upload just the metadata for a file without uploading a video/audio/VGA file. - question: what would josh & tobias think about uningested media bundles 'laying around.' - can bedework handle this? - Allison to think more about how the ingestor relates to the scheduler - in box - a collection of things that should be worked on - site conductor service looks for things to Clemens: think about what metadata should be n admin BA-UX-UI Meeting Notes NEXT MEETING: Thursday, February 11th at 8:30 am PDT / 10:20 am Saskatoon / 10:20 am CDT / 11:20 am EDT / 4:20 pm GMT / 5:20 pm CET in the Adobe Connect room at: http://ado.uvigo.es/opencast. Agenda: Any interesting items from Engage meeting (which will have taken place before this meeting) Update on Potential Adopters Demo of/introduction to Capscribe Possible agenda items for future meetings: Review of shared annotation systems (Recollect...) What kind of monitoring does admin user need to do: see Tag News posts with "ba-ux-ui" to include it here. Blog Posts 2010-02-11 BA-UX-UI Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Feb 11, 2010 2010-01-28 BA-UX-UI Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Jan 28, 2010 2010-01-14 BA-UX-UI Meeting created by Laurie McArthur OLD Matterhorn Project **DON'T USE** Jan 14, 2010 2009-12-17 BA-UX-UI Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Dec 17, 2009 2009-12-10 BA-UX-UI Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Dec 10, 2009 2009-12-03 BA-UX-UI Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Dec 03, 2009 2009-11-19 BA-UX-UI Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Nov 19, 2009 2009-11-12 BA-UX-UI Meeting created by Judy Stern OLD Matterhorn Project **DON'T USE** Nov 16, 2009 2009-11-05 BA-UX-UI Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Nov 05, 2009 2009-10-29 BA-UX-UI Meeting created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Oct 29, 2009 2009-10-22 BA-UX-UI Meeting created by Judy Stern OLD Matterhorn Project **DON'T USE** Oct 23, 2009 2009-10-15 BA-UX-UI Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Oct 15, 2009 2009-10-08 BA-UX-UI Meeting created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Oct 08, 2009 2009-10-01 BA-UX-UI Meeting created by Judy Stern OLD Matterhorn Project **DON'T USE** Oct 01, 2009 2009-09-10 BA-UX-UI Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Sep 11, 2009 Capture Team Meeting Notes Tag News posts with "capture" to include it here. Blog Posts 2009-12-14 Capture Team Meeting created by Rubén Pérez OLD Matterhorn Project **DON'T USE** Dec 14, 2009 2009-08-14 Capture Team Meeting created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Aug 14, 2009 Capture-Schedule Meeting 2009-07-24 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Jul 24, 2009 Distribution Team Meetings Tag news with "distribution" to be included here. Blog Posts 2009-08-14 Distribution Team Meeting created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Aug 14, 2009 Engage Team Meeting Notes Engage group weekly discussion: 07/06/09 - 07/10/09 welcome additional developers designer problem working out first ideas for the reference implementation data storage for "Engage tools" 07/13/09 - 07/17/09 JS/CSS/Ajax improvements -> no real alternative to fluid (besides the media player) automatic testing / Maven + JS/HTML/Ajax/Flex components Service simulation -> no need to have working services from sub-groups to start development what do the Engage group need from UX/BA -> especially from Alicia (Spain) Flex framework training -> Swiz organizing Podcast University:2009 conference to advertise opencast community/matterhorn 07/20/09 - 07/24/09 Flex framework training -> Swiz Streaming server vs. Web server Do we need a Media Portal Google gadgets Ajax Bridges organizing Podcast University:2009 conference to advertise opencast community/matterhorn 07/27/09 - 07/31/09 OpenSource Streaming server solutions Red5 vs. Mammoth Server Designer & Developer -> How can Design Pattern help us? -> What is important from a developer perspective? fluid testing appraoch user interface candidates Opencast Media Portal (https://wiki.opencastproject.org/confluence/display/open/Media+Portal) Meeting in Zurich 08/03/09 - 08/07/09 Defining Tasks for developers --> Storycards for Iteration 2 Play/Stop/Pause: protocol independent (rtmp/http) CodingStanards -> how can tests be integrated Module architecture (beans) project (Flex) based on swiz Include code in the nightly build (wrapping Flex in a gadgets) setup local test system (based on Matterhorn nightly builds) include RED5 in the build who will be responsible for dokumentation Developer power for the Admin group (Stefan) - bedework or not? CLA/ CCLA -> developers are ready; -->what are our lawyers doing? Product Owner Meeting Notes The weekly Product Owner Meeting focuses on functionality and requirements of Matterhorn, enabling everyone to be on the same page for priorities, deliverables, and "what it means to done" for a given story card. This meeting should also identify open questions that need to be resolved now or for an upcoming iteration. Tag "News" with "product_owners" to be shown on this list. Blog Posts 2010-01-12 Product Owner Meeting created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Jan 12, 2010 2010-01-05 Product Owner Meeting created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Jan 05, 2010 2009-12-23 Product Owner Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Dec 23, 2009 2009-12-22 Product Owner Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Dec 22, 2009 2009-12-16 Product Owner Meeting created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Dec 16, 2009 2009-12-01 Product Owner Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Dec 01, 2009 Product Owners Meeting 2009-11-24 created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Nov 24, 2009 2009-11-18 Product Owners Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Nov 18, 2009 Product Owners Meeting 2009-10-27 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Oct 27, 2009 2009-10-13 Product Owner Meeting created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Oct 13, 2009 Product Owners Meeting 2009-10-06 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Oct 06, 2009 2009-09-29 Product Owner Meeting created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Sep 29, 2009 Product Owners Meeting 2009-09-15 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Sep 15, 2009 2009-09-08 Product Owner Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Sep 08, 2009 2009-09-01 Product Owner Meeting created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Sep 01, 2009 Services and Architecture Team Meeting Notes Tag "News" items with "architecture" to include it here. Blog Posts 2010-02-08 Architecture & Services Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Feb 08, 2010 2010-01-11 Services & Architecture Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Jan 11, 2010 2009-12-14 Services & Architecture Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Dec 14, 2009 2009-11-30 Services & Architecture Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Nov 30, 2009 2009-11-23 Services & Architecture Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Nov 23, 2009 2009-11-09 Services & Architecture Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Nov 09, 2009 2009-11-02 Services & Architecture Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Nov 02, 2009 2009-10-26 Services & Architecture Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Oct 26, 2009 2009-10-19 Services & Architecture Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Oct 19, 2009 2009-10-12 Services & Architecture Team Meeting created by Josh Holtzman OLD Matterhorn Project **DON'T USE** Oct 14, 2009 2009-10-12 Services & Architecture Team Meeting created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Oct 12, 2009 2009-09-28 Services & Architecture Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Sep 28, 2009 2009-08-31 Services & Architecture Team Meeting created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Aug 31, 2009 2010-02-15 Attendess: Bostjan, Josh, Tobias Recording: http://uvigo.emea.acrobat.com/p92172681/ Agenda: SVN/Jira/Confluence transition State of the union Asynchronous service calls SVN/Jira/Confluence transition Josh and Tobias did an update on the svn layout and renamed the services to better match the "matterhorn" brand. Bostjan was able to check out. State of the union Bostjan is still working on the distributed services. It should be ready to go in a couple of days. Asynchronous service calls R-OSGi supports asynchronous calls, everything seems to be working. A problem of the current composer implementation is the Future. The composer will return immediately after the call, while R-OSGI would support real asynchronous call handling. We decide on implementing a Receipt, and to keep the callback out of the service contract Developer Meeting Notes NEXT MEETING: Wednesday, 10 February at 8 am PDT / 9 am Saskatoon / 10 am CDT / 11 am EDT / 4 pm GMT / 5 pm CET in the Adobe Connect room at: http://ado.uvigo.es/opencast. Agenda: Tag News posts with "service" to include it here. Blog Posts 2010-02-03 Developer Meeting created by Josh Holtzman OLD Matterhorn Project **DON'T USE** Feb 03, 2010 2010-01-20 Services Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Jan 20, 2010 2010-01-13 Services Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Jan 13, 2010 2009-12-16 Services Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Dec 16, 2009 2009-11-23 Services Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Nov 25, 2009 2009-11-18 Services Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Nov 18, 2009 2009-11-11 Services Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Nov 11, 2009 2009-11-04 Services Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Nov 04, 2009 2009-10-28 Services Meeting created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Oct 28, 2009 2009-10-14 Services Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Oct 14, 2009 2009-10-07 Services Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Oct 07, 2009 2009-09-30 Services Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Sep 30, 2009 2009-09-16 Services Team Meeting created by Tobias Wunden OLD Matterhorn Project **DON'T USE** Sep 16, 2009 Services Meeting 2009-09-09 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Sep 09, 2009 2009-08-17 Services Team Meeting created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Aug 17, 2009 Weekly Matterhorn Meeting (SoS) Notes The Weekly Matterhorn Scrum of Scrums meeting is held every Tuesday at 8am Pacific. The agenda typically includes updates on work across all teams on the Matterhorn Project, identification of blockers. Tag "News" items with "scrums" to be shown on this list. Blog Posts Scrum of Scrums Meeting 2010-02-16 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Feb 16, 2010 Matterhorn Scrum of Scrums - 2010-02-09 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Feb 09, 2010 Matterhorn Scrum of Scrums 2010-02-02 created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Feb 02, 2010 Matterhorn Scrum of Scrums 2010-01-12 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Jan 12, 2010 Matterhorn Scrum of Scrums 2010-01-05 created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Jan 05, 2010 Matterhorn Holiday Scrum of Scrums - 2009-12-15 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Dec 15, 2009 Matterhorn Scrum of Scrums 2009-12-08 created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Dec 08, 2009 Matterhorn Scrum of Scrums 2009-12-01 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Dec 01, 2009 2009-11-17 Matterhorn Scrum of Scrums Meeting created by Allison Bloodworth OLD Matterhorn Project **DON'T USE** Nov 17, 2009 Matterhorn Scrum of Scrums 2009-11-10 created by Olaf A. Schulte OLD Matterhorn Project **DON'T USE** Nov 10, 2009 Matterhorn Scrum of Scrums 2009-11-03 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Nov 03, 2009 Matterhorn Scrum of Scrums Meeting 2009-10-27 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Oct 27, 2009 Weekly Scrum of Scrums Meeting 2009-10-20 created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Oct 20, 2009 2009-10-13 Matterhorn Scrum of Scrums Meeting created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Oct 13, 2009 2009-10-06 Matterhorn Scrum of Scrums Meeting created by Michelle Ziegmann OLD Matterhorn Project **DON'T USE** Oct 06, 2009 Archive of Past Meetings For a historical perspective on how the Matterhorn project has evolved, below is a list of references that document some of our previous meetings: Sep 21-25, 2009: Matterhorn All-Hands Meeting in Zurich, Switzerland View meeting agenda and summary Apr 27-May 1, 2009: Matterhorn Leadership and Planning meeting View summary of meeting, including photos, presentations, and session recordings Oct 16-17, 2008: Deep Dive Meeting Agenda (some session recordings available) Next Steps Post Deep Dive Pictures! July 9-11, 2008: Opencast Working Meeting Europe Summary of Meeting Next Steps after Oxford Meeting Compiled, prioritized list of requirements from Working Meetings Pictures! June 13, 2008: Opencast Open House Watch video June 5-6, 2008: Opencast Working Meeting North America Meeting agenda Pictures! April 2008: Announcing Mellon/Hewlett Opencast Planning Grant Oct 2007: First requirements gathering meeting Hosted by Apple, Inc in Cupertino, CA Attended by nine institutions from the US, Australia and Canada Deep Dive Agenda This is a listing of the events that took place during the Deep Dive meeting (10/16-10/17/2008). Where available, presentations, notes, and podcasts are available for review. Session Title Date Description Facilitator Pre Deep Dive Tue, Oct 14, Update from the Pre Deep Dive workgroup via videoconference Josh/Tobias Reportout 2008 8:00am - 9:00am PDT Pre Deep Dive Wed, Oct 15, Update from Pre Deep Dive workgroup via videoconference Josh/Tobias Reportout 2008 8:00am - 9:00am PDT Welcome and Thu, Oct 16, Welcome from Berkeley Introductions Mara Introductions 2008 9:00am - View recorded session 9:30am PDT Diving Right In: Thu, Oct 16, Report-out from Pre-Deep Dive Meetings Overview of Architecture draft Josh/Tobias/Markus/Bjoern Architecture 2008 9:30am - View recorded session Overview 10:45am PDT Roadmap/Local Thu, Oct 16, Overview/discussion of the Roadmap View recorded session Adam Timelines/Scope 2008 11:00am - 12:00pm PDT Breakout Thu, Oct 16, Break into small groups for discussion about the roadmap/scope: Adam, Judy, Mara, Ben, Groups 2008 1:00pm - -What's missing? Josh, Tobias, Armin, Olaf 2:00pm PDT -What's included that shouldn't be? -Is everything in the right order with the right timing? -How should we organize to deliver this? Report back Thu, Oct 16, Adam, Judy, Mara from groups 2008 2:00pm - 2:45pm PDT Developer Thu, Oct 16, This is a time for the developers to meet to discuss modification/adaptation/further refinement of the technical plan Josh, Tobias, Markus, Fishbowl 2008 3:00pm - based on discussions that have taken place. The rest of us will observe this technical meeting, be available for Bjoern 4:00pm PDT questions from the developers, and help problem solve solutions to problems that they identify. Wrap Up Thu, Oct 16, Summary "Food for thought" for next day's agenda Mara 2008 4:15pm - View recorded session 5:00pm PDT Eyes Wide Fri, Oct 17, Opportunities and Challenges of Open Source Lessons Learned Mara, Gabriel, John, Jutta Open 2008 9:00am - View recorded session 9:30am PDT Management Fri, Oct 17, Discussion around management models. How will we organize ourselves to accomplish this project? Adam Models 2008 9:30am - View recorded session 10:30am PDT Revisit Fri, Oct 17, Another look at the Architecture Overview -identification of the role that REPLAY will play in the Matterhorn. Josh, Tobias Architecture 2008 10:45am View recorded session - 12:00pm PDT Grant Fri, Oct 17, Discussion of the grant proposal and next steps. Mara Proposal/Next 2008 2:15pm - View the Next Steps that were identified during this meeting. Steps 4:00pm PDT Zurich meeting September 21-25 Travelling to and in Zurich Year 2 Brainstorm \ Sunday, Monday, 21st Tuesday, 22nd Wednesday, 23rd Thursday, 24th Friday, 25th Saturday, 26th 20th 09:00-10:30 HG D16.2 09:30 HG E23 / HG D22 / HG F33.4 HG E23 / HG D16.2 / HG D18.1 / HG HG E23 / HG D18.1 HG E23 / HG D18.1 /HG F excursion Welcome session Road Mapping D22 Architecture Update 33.2 Open Questions (will be recorded) Design Studio / Team Break-Out Meetings 10:30-11:00 Coffee @ HG D19 Coffee @ HG D19 Coffee @ HG D19 Coffee @ HG D19, 10:00-10:15 Coffee @ HG D19 11:00-12:45 HG D16.2 / HG D18.1 HG E23 / HG D22 / HG F33.4 HG E23 / HG D16.2 / HG D18.1 / HG HG E23 / HG D22 / HG D18.1 10:15- HG E23 / HG D18.1 / HG excursion Team Break-Out Meetings Open Questions / D22 11:30 F33.2 User Stories Team Breakouts Packaging, Piloting, Documenting 0.5 Design Studio / Team Break-Out Meetings Shuttle Bus at 11:54 13:00-14:00 Lunch @ DF Lunch @ DF Lunch @ DF 12:30 Lunch at Hönggerberg 13:15 Lunch @ DF 14:00-15:30 HG E23 / HG D22 / HG HG E23 / HG D18.1 / HG D22 / HG HG E23 / HG D22 / HG F33.4 Value Lab/HIT K52 / HIT H31.1 HG E23 / HG D16.2 / HG People returning that night can F33.4 F33.4 Team Break-Out Meetings / D18.1 catch an earlier train back to Team Break-Out Meetings Team Break-Out Meetings Share Out Board Meeting (Videoconference) Year Two Brainstormin Zurich Team Breakouts 15:30-16:00 Coffee @ HG D19 Coffee @ HG D19 15:15-15:30 Coffee @ HG D19 Coffee as required (coffee bar Coffee @ HG D19 excursion nearby) 16:00-17:30 HG E23 / HG D22 / HG HG D16.2 HG E23 / HG D22 / HG F33.4 Value Lab/HIT K52 / HIT H31.1 HG E23 / HG D16.2 / HG excursion F33.4 Presentation slot Team Break-Out Meetings / D18.1 Develop Conference - Speech-to-text, ETH Zurich (30 Share Out Board Meeting (Videoconference) Year Two Brainstormin Backlog minutes) Team Breakouts ends at 17:00 - Epiphan (60 minutes) ends at 16:45 Welcome Commihalle HG D16.2 Restaurant Halbinsel Au At your own disposal Farewell drinks (private) More drinking drinks 7:30 5:30 All night 7:00 pm Welcome diner Apéro sponsored by Epiphan Diner Swiss Chuchi (Hotel Adler) Voluntary: Offene Rennbahn Oerlikon (if weather allows) Available rooms HG E23: Main meeting room for 40 people HG D22: Break-out room for 20 people HG 18.1: Break-out room for 20 people HG F33.4 / HG F33.2: Break-out rooms for 15 people (F-floor) HG D16.2: Large (80 seats) lecture hall with videoconferencing equipment. HG D19: Coffee room HG E16: Office (Tobias, Josh et al.) Floor plan (HG F33.4 / HG F33.2 not included). Lost? Call Olaf on +41 79 7574732; mind you, coverage is bad in the main building... Zurich, ETH Zurich, hotels, public transport http://www.ethz.ch/about/location/index_EN TRAVELLING TO AND IN ZURICH Travelling from airport to city / from city to airport / main station If you don't have Swiss money yet, now is the time to change it - there are exchange bureaus in the airport of course, one is near the stairs to the platforms, where you will also find ATM from the "Zürcher Kantonalbank ZKB" - they should offer fair exchange fairs. There is a regular train service to Zurich main station from the Airport. At the airport, just follow the signs towards the train station ("Railway", "Zug", "SBB"). Before you descend to the platform, make sure you buy your ticket before (!) entering the train; destination / red button is "Zurich". Depending on the train, there are one, two or three stops, but there are announcements on the train - and people happy to help you. Alternatively, feel free to follow the "Tram" signs that bring you outside of the main building with a stop for No. 10 towards the city - a lovely 30 minutes through various parts of the not-yet-city, passing by ETH Zurich. Ticket is the same here, exit would be Central towards most hotels. More information about the ticket boxes are available: http://www.vbz.ch/vbz_opencms/opencms/vbz/english/Tickets/. Getting back to the airport, press code "8058" for "Flughafen Zürich" on the ticket box; leaving from ETH, tram no. 10 is the easier option compared to a train from main station. The main station is central to this part of Zurich and in walking distance of ETH Zurich (10 minutes) and all the hotels (10 minutes). Public transport won't buy you an advantage going to ETH or your hotel (except for Hotel Rex), so if you absolutely cannot walk, take a taxi. Hotels Hotel St. Josef View Opencast Web: http://www.st-josef.ch/ Matterhorn Zurich Meeting in a larger It's in walking distance of the main station, near the station "Central". map Google Maps Hotel Rex Web: http://www.zuerich-hotels.ch/html/index.php?id=21 For Hotel Rex, from the main station take the tram No. 7 towards "Bahnhof Stettbach" leaving from Bahnhofstrasse (n ot the main exit from the main station), descend at „Ottikerstrasse", the fourth stop; this is covered by the ticket you bought at the airport on the same day. Google Maps Hotel Basilea Web: http://www.hotelbasilea.ch/en/home/ It's in walking distance of the main station, near the station "Central". Google Maps Leoneck Hotel Web: http://www.leoneck.ch/en/index.html It's in walking distance of the main station, near the station "Central". Or take tram No. 10 ("Bahnhof Oerlikon") from main station, No. 6 ("Zoo") or 7 ("Bahnhof Stettbach") fromBahnhofstrasse (not the main exit from the main station) to "Haldenegg" (two stops). Google Maps Getting to ETH Walk! It may be steep sometimes, but it's alway beautiful and a rare chance to get some fresh air, see the city and enjoy the people... take a look at the map and you will see. To go to ETH on public transport, look for trams No. - 6 (heading for "Zoo"), - 9 (heading for "Hirzenbach), and - 10 (heading for "Zürich Flughafen, Fracht" or "Bahnhof Oerlikon"). Get out at "ETH/Universitätsspital" and enter the main building. Other directions towards ETH. From the "Central", take the historic Polybahn - the "Central" is in walking disctance from almost everywhere... Getting around in Zurich / Tickets The best option for public transport is to buy a day pass: Press the green button for "Tageskarte", pay 8.- SFr and move around freely within Zurich (city). If you're not afraid of uphill driving, consider renting a bike. http://www.ethz.ch/intranet/misc/index_EN http://www.ethz.ch/about/location/zentrum/index_EN General information about public transport in Zurich:http://www.vbz.ch/vbz_opencms/opencms/vbz/english/PublicTransport/ Miscellaneous The blue and white streetcars ("Tram") have the right of way - everywhere and everytime, towards cars, bikers, and pedestrians! Weather in Zurich - local and global. Other FAQs Q: What power adapter do I need? See http://users.telenet.be/worldstandards/electricity.htm#plugs_j and http://www.stayonline.com/detail.aspx?ID=328. If you have an adapter for Germany, make sure it has the thinner prongs. Q: What currency is used in Switzerland? The swiss franc. 1 Swiss franc = 0.971723 U.S. dollars. Q: What's the best ticket for the local traffic, is there a recommendation for a week ticket or can we do the most by foot? The best option for public transport is to buy a day pass: Press the green button for "Tageskarte", pay 8.- SFr and move around freely within Zurich (city). In general, walking is possible however! Q: What is there to do with free time in Zurich?* Staying in the city, you should go towards the lake, starting from "Central" towards Bellevue http://maps.google.com/maps?f=q&source=s_q&hl=de&q=Bellevueplatz,+8001+Z%C3%BCrich,+Schweiz&sll=50.878174,9.67199&sspn=10.084 888,28.366699&ie=UTF8&cd=1&geocode=FZvE0gId3WGCAA&split=0&ll=47.367141,8.544724&spn=0.010566,0.027702&z=16&iwloc=A and further along the seaside. For a view, consider going to Uetliberg http://maps.google.com/maps?f=q&source=s_q&hl=de&geocode=&q=uetliberg+Z%C3%BCrich,+Schweiz&sll=47.367141,8.544724&sspn=0.010 566,0.027702&g=Bellevueplatz,+8001+Z%C3%BCrich,+Schweiz&ie=UTF8&ll=47.349059,8.476124&spn=0.084554,0.221615&z=13&iwloc=A and for the historic part towards the old town near Bahnhofstrasse. http://maps.google.com/maps?f=q&source=s_q&hl=de&geocode=&q=st.+peter+Z%C3%BCrich,+Schweiz&sll=47.371553,8.538593&sspn=0.021 13,0.055404&g=Bahnhofstrasse,+8001+Z%C3%BCrich,+Schweiz&ie=UTF8&ll=47.371501,8.54084&spn=0.020403,0.055404&z=15&iwloc=A In case of rain or cultural interest, why not go for the Kunsthaus? http://maps.google.com/maps?f=q&source=s_q&hl=de&geocode=&q=kunsthaus+z%C3%BCrich+Schweiz&sll=47.37185,8.549037&sspn=0.0204 03,0.055404&ie=UTF8&z=14&iwloc=A YEAR 2 BRAINSTORM As collected during the Zurich meeting by the group on Sept 25th. Capture Mobile capture device with UI Smart phone ingest ? (3rd world) Even lower TCO (virtualization) Very simple cost efficient recorder (software only) Desktop capture (Camtasia!) Camera control "Prof tracking" Motion talking Capture HD Video Many devices (3 VGA + 2 HD cams for example) Multi stream client to integate multi camera settings Instructor pauses capture Instructor starts and stops capture Live streaming 1-way live streaming GPS over IP Mobile device quick external capture 5 min extend timer mobile device Notification of capture agent/device failuer via SMS Encoding video conference and materials Let students tag/annotate lectures that a currently recorded Wide range hardware compatibility Auto deploy new versions (1 click update) Capture client software on Epiphan Configuration UI Email video to ingest into system Admin Mobile device admin app Enterprise integration Professor edit titles Multi-level admin tool Role ID for suppot and admin UI Multiple roles Admin authorization "Diff roles" Different access levels (root, admin, editor, etc) Instructor okays podcasting online Automatic classification tools Review workflow (4-eye principle) Conductor UI tell system which rooms are available at a particular time and capabilities of room Interface to LMS/Campus Management for data transfer in both directions Conprehensive confidence monitoring Allow lecturer to edit recording metadata (e.g. lecture captures) Process notification Automatic lecture titling based on syllabus in LMS Configuriation UI (e.g. for things configured in XML file) Specifying recording parameters (eg bitrate) on a per series/course and per-recording bases Specify a date after which a recording will be unpublished Send (email, SMS) reminders to attendees required @ a meeting (e.g. camera operators) Edit metadata on all distribution channels afer recording has been published Delay publication of a recording until a specified date Processing & Services Workflow item requiring recording to be held until after review (eg for copyright) OGG Tag, edit, brand video Edit video - trimming, cut out parts Speech > text transcript Train speech to text HD-video: cropping of unused parts of the screen HD-video: analyze the video (it extract images of boards full of text) UI service (eg libraries) Editing, editing, editing User edit recording (trim/mashup) Split and merge films Allow lecturer to trim video Trim video Video trimmer app Authoritative annotation by instructors Audio level compression/limiting Black board capture (chalk!) Distribute Support for redactional processes Integration with library digitization efforts Integration with course management systems End-user controlled publishing and unpublishing and metadata update "On camp" for libraries perserving scholarly confereneces Archiving recommendations Tool to embed video in Google Apps Collect usage stats Integration with university unified conta?? architecture Matterhorn Portal with recording from all Opencast universities Create new series based on existing recordings Distribtue to iPhone mobile devices Content federation Interplatform connection between two implementation of Matterhorn Mix "video" and "display" to generate another video for mobile devices - or do a composition Composer: mix multistream recordings to one stream videos (PiP, etc) - intelligently Engage Create new video by combining segments (eg playlists for study sheet) Open Social Spatial annotation (define hotspot and add annotation to it) Ability to email instructor with questions specific to points in time of lecture Aggregated annotation view (cross-video) Plays in the home (Wii, XBox360, etc) Mobile app (find, view, share) Share annotations HD Video: Zoom in to parts of the screen (read the board) Share playlists Amazon recommends... (collbaorative filtering) Connection to semantic web Attach files to class course or event (faculty or admin) Student talk-back (cam mess) ?? UI personalization End-user annotations Inter-course linking to related/supporting materials Collaborative transcript generation (in multiple languages) Community editing like comments, wiki-editing of captions Video annotation and informal editing for class use Template editor for engage tools Keyword and concept cloud per video/course/class Output for mobile devices Student oriented tools (slides + text) Speaker diarization HTML 5 player UI preference for language providing access to lectures by role, by id, by group Community Central portal for all recordings made with all Matterhorn installations Pedagogical oriented best practice examples Metadata exchange (searchability across universities) Opencast content and video event (conference, festival, etc) More face to face Adoption support Best practices Call home for source Other GUI made the apple way, not engineer way Functionality and low cost Statistical package for management information data Extensive interaction logging (research, Amazon) Mobile app (iPhone and blackberry & android) Authoring of classroom matierals (vieo + slides + links + formative testing + ) using video timeline Informal instructure collections of video materials Personal collections and group sharing Drop-box for mobile devices Pedagogical background + effect Mobile client support Communications & Adoption Strategy Working Group Notes Tag News posts with "communication" or "adoption" to include it here. Adoption Strategy and Communications 2009-02-11 Michelle Ziegmann posted on Feb 11, 2010 Base Camps Vigo: Setting up capture agents, mailing list, 4-5 institutions in line UK: Nothing much, waiting for servers. UNL: Problems with / questions around capture agents-setting up local website for basecamp support as well. Tel Aviv: Saskatchewan: just got in rest of hardware to set up, everyone will have their own VM, has one set up for U of Regina; installed a capture agent at U of Regina this week, have identified a few bugs, filed in Jira, will work on these this afternoon; worked on some scripts for people to run a local capture agent (can't be installed on a VM), will post to list, asked for help in testing out the script; need different drivers for each epiphan card each rev, have to request a new driver from Epiphan; still working on the capture agent for Steeple, working on a video that walks through the hardware All base camps should update their entries in https://wiki.opencastproject.org/confluence/display/open/Matterhorn+Bas ecamps (or after Friday, something like http://opencast.jira.com/wiki/open/Matterhorn+Basecamps) Support for Individuals and Base Camps Need something better than mailing list and IRC Rudiger's idea: Currently we are requesting people subscribe to community list, problems with this are that they likely want to receive emails only as they pertain to their own issues, not easy to search Suggestion to look at organizing Jira to make it easier to submit support requests, search previously submitted/solved problems (Adam and Michelle to do that) Continue to point people to community@ list and IRC for support Documentation of adoption Goals: Download data Michelle to check into some other options for using Google Analytics Jack: suggests more aggressive PR, give presentation about the current state of the project, has colleagues that are interested, but want more information about the project Bjoern: Will be writing reports for Steeple-BR (around August), so information will be available then; Which means that we'll keep 'notes' of the things that are happening in the meantime, which can be shared in other ways. Update Communication page in wiki to include where to go for support (Michelle) communication Adoption Strategy & Communications Meeting - 2010-02-04 Olaf A. Schulte posted on Feb 04, 2010 Adoption Strategy Meeting, February 4th 2010 Attendees: Adam, Allison, Chris, Bjoern, Bruce, Clemens, Jack, Jamie, Manjit, Mara, Olaf, Vicente Recording: https://admin.emea.acrobat.com/_a828609328/p54814481/ Agenda Base camps: Updates Support for Basecamps and testing institutions/individuals (Adam to report from Product Owners' Meeting) Bug reporting Managing support at Matterhorn end Communication around 0.5 - Announcement (list, individual mails to survey respondents) - Case studies (Michelle) - Video Key elements around communication - wiki contains a "release 0.5" folder now to host relevant information around the release: https://wiki.opencastproject.org/conflu ence/display/open/Release+0.5 - Download page on opencastproject.org & welcome page (content needed - OAS) - this is the primary place to come to for base campers and individuals/institutions testing - Upon intsall, the welcome page will direct you to these resources also - Work on release 0.5 FAQ - Jamie has finished the 0.5 welcome video - Everything should be in place tomorrow Friday - Base campers have and should continue to provide feedback - Announcement timing: Monday morning PST Support: IRC channel is open for feedback from testing individuals/institutions, the Opencast Community list as an asynchronous addition to that. Jamie (Europe) and Manjit (North America) to be available for instant support via IRC. Support policies: Base camps can handle support requests individually, but should strongly consider CC'ing the Opencast Community list to keep the community updated on problems and their solution. No migration plan from release to release! Chris: The capture agent is 0.5 also - alpha. Base camps Chris/Saskatchewan VM server should come today, hopefully with a new headset for Chris. Installing a capture agent at another Canadian university Preparing a video for the details of installing the capture agent. Shipping of Steeple capture agent immanent Planning to spam Canadian universities about joining the base camp (discussion needed) Using Canadian eLearning Conference as a promotional event for base camp Steeple-BR (Bjoern/Sally/Rich): - We waiting on server hardware (donation from Apple hasn't manifested yet) - We're planning an installation party, as soon as we have hardware - We're planning a UK/Steeple-BR-wide workshop for later this month - We should be able to take a pretty active support rule for UK institutions until the end of Steeple-BR (31/8/10) Jack/Tel Aviv Full installation & VM Technical issues, getting support from Matterhorn team Todd/Nebraska-Lincoln Question on VM (configuration issues) VMFusion: Virtual Box as an alternative? Planning for outreach activities, getting contacts from potential adopters and survey respondents from Olaf. Vicente/Vigo Finalizing hardware for capture agents. Issues around XEN infrastructure for VM. Prepared welcome webpage http://lab2.media.uvigo.es/ Communication via NREN multimedia mailing list. Spanish version of the welcome video to be produced Contact to South American HEI (ISTEC) communication Adoption Strategy & Communications Meeting - 2010-01-14 Olaf A. Schulte posted on Jan 14, 2010 Adoption Strategy & Communication Meeting, December 14th 2009 Attendees: Adam, Carl, Clemens, Recording: http://uvigo.emea.acrobat.com/p18566538/ Agenda Basecamps: Updates Encore: Pilot and Adoption FAQ: https://wiki.opencastproject.org/confluence/display/open/Pilot+and+Adoption+FAQ or https://w iki.opencastproject.org/confluence/display/open/Development+Documentation Communication around releasing 0.5 Basecamps update UK (Sally) still waiting for servers to arrive. VM installed on Sallys machine. Version conflict. Adam points to https://wiki.openca stproject.org/confluence/display/open/Release+0.4. Sally suggests adding date and time to the downloadable version to compare with installed. Institutions in the UK will be informed when 0.5 is running in Loughborough, a workshop is planned for people to play with Matterhorn. Chris is waiting for HW from California to set up the machine for the UK. Germany: Clemens is talking to Universities of Vechta and Hannover. Erlangen-Nuernberg is also involved. Ruediger is setting up a VM for testing, not yet for actually hosting a base camp. Spain (Vicente): Also waiting for capture cards to become functional. Virtualization infrastructure at Vigo asks for different approach to VM, probably waiting for freeze before setting up VM. Five or six institutions involved. Chris suggests a community request for non-VMWare (XEN) VM installations to be supported. Institutions collaborating with base camps should be made to answer the survey to identify them. FAQ: Finally some progress, will be further developed. Communication around 0.5 Newsletter & individual e-mails to people who answered the survey or are on the adopters list Chris suggests visual/slide/table to provide overview on progress from 0.5 onwards. Adam will work on this. Case Studies To start collecting these stories shortly after 0.5 release Trying to asses total cost of adoption Michelle to lead this effort, work with Olaf, Chris, Sally, Adam adoption Adoption Strategy & Communications Meeting - 2010-01-07 Olaf A. Schulte posted on Jan 07, 2010 Recording (partially): http://uvigo.emea.acrobat.com/p53801354/ Attendees: Adam, Bruce, Chris, Jack, Michelle, Olaf, Todd, Vicente Agenda Basecamps: University of Nebraska-Lincoln; updates from others Survey: Update Pilot and Adoption FAQ: https://wiki.opencastproject.org/confluence/display/open/Pilot+and+Adoption+FAQ Communication: Invite Adopters to future meetings? Basecamps Nebraska-Lincoln Will set up base camp. (notes missing, cf. recording) Tel Aviv U Setting up Matterhorn on VM, asking for step-by-step guidelines beyond installation documentation. UVigo Working on "Matterhorn Lab", providing base camp for three and more institutions. Working on step-by-step guidelines or guided tour (Spanish!). Bruce: Are there minimal skills we should require users in a base camp to have? Adam: We expect people interested in 0.5 to be enthusiastic enough to bring the skills needed. Survey: Good response rate so far, details will be looked at later. No further "encouragement" to answer the survey until 0.5. FAQ: Very much needed, but not clear who will do it; Adam to consult with Jamie. Communication: Future meetings should continue to be "strategic" with base camp institutions present, but a seperate meeting for testing institutions is also a must beyond 0.5. adoption Matterhorn Adoption & Strategy Meeting - 2009-12-17 Michelle Ziegmann posted on Dec 17, 2009 Attendees: Olaf, Adam, Vicente, Michelle, Clemens, Jack, Mara Recording:http://uvigo.emea.acrobat.com/p45949686/ NOTES Survey: Quick update 30 responses so far Olaf to send individual requests to people who have previously expressed interest who haven't already completed the survey Olaf has consolidated lists to 1 master list of all contacts that are considered "Potential Adopters" - https://wiki.opencas tproject.org/confluence/display/open/Pilots+and+potential+adopters+%28consolidated%29 Base camp updates USask: have installed 2 new servers, will start testing VMs on these; collecting contacts for notifying when available, suggests McGill University as a major Canadian institution to focus on USask: Regarding hardware for Steeple, OK'd now to order 3 units, hopes they will arrive before Christmas, will be setting them up over break, ready to ship out in January for Februrary 1, 1 to Steeple, 1 to keep local for testing, 1 to set up locally for online demo? USask: will be posting the reference hardware specifications on the wiki/mailing list in January; are currently under $1,000 total (shipping not included!) Jack Bar: have just set up VM, waiting for instructions to install an instance of Matterhorn Adam: still working on the install instructions, hopefully to be completed in January Jack: offering to test instructions Vicente: No major news from Spanish base camp. Pilot and Adoption FAQ: https://wiki.opencastproject.org/confluence/display/open/Pilot+and+Adoption+FAQ Still needs work December newsletter Will stay on schedule to release before Christmas Support infrastructure Adam: Manjit as first level support, not sure about second level and details; will have to be dealt with mid-January. Jack: Considers base camps to be the solution to that. However, even base camps can have questions and problems (Olaf) and the issue is who is going to answer/solve these. adoption Adoption Strategy & Communications Meeting - 2009-12-10 Michelle Ziegmann posted on Dec 10, 2009 AGENDA Survey: First results, next steps Communication: Invite institutions interested to next meeting(s)? Basecamp: Updates Pilot and Adoption FAQ: https://wiki.opencastproject.org/confluence/display/open/Pilot+and+Adoption+FAQ NOTES Attendees: Chris, michelle, Vicente, Olaf, Clemens, Adam, Patrick, Rich Goodman, Sally, Mara Recording: http://uvigo.emea.acrobat.com/p70659580/ Adoption Survey launched on Tuesday, receivied 20 responses need a 2nd wave - will re-announce in newsletter; direct contact with people who contacted us previously http://wiki.opencastproject.org/confluence/pages/viewpage.action?spaceKey=MHOLD&title=Pilots+and+poten tial+adopters https://wiki.opencastproject.org/confluence/display/mhboard/Potential+Adopters Individual contacts to all subscribers of opencast mailing list Olaf will consolidate the 2 lists, then share with those on this call; Chris and Adam both have contacts to add to the list Timing: Next week: individual contacts Dec 22ish: reminder in newsletter Jan: address broader Opencast community individually Next week, will consider plan for how to follow-up with those who completed the survey Base Camps Sally: spoke to hardware contact today, has confirmed 3 servers to use, on their way to Rich Rich: awaiting servers, will install as soon as they arrive Sally/Rich will write an article including their interests and motivations behind offering a base camp, and a summary of what will be offered via the UK base camp Chris and Vicente to write similar articles from their perspectives Articles due (either in wiki or to Michelle) by next Friday Question about the demand for base camps, will look to the survey results for some insight into thos Michelle to summarize results to date and distribute to this working group Vicente: question about what a base camp will look like Adam: also a question of security Chris: anyone who asks for a VM by email, he will start it up for them Chris: can also use a VM for an demo for public Vicente: PumuKit (http://lab.media.uvigo.es/), has given each institution their own VM Concern about performance; should probably limit filesize, recording length Online demo: one central online demo? or each base camp offers one? Adoption Meeting Should we open this meeting to all potential adopters? or keep it as a team meeting? Suggested opening it up in January for parties interested in testing Pilot and Adoption FAQ https://wiki.opencastproject.org/confluence/display/open/Pilot+and+Adoption+FAQ Feedback that the questions look good, Olaf to start filling in answers then involve others to help adoption Communications and Adoption Strategy Meeting 2009-12-03 Michelle Ziegmann posted on Dec 03, 2009 Attendees: Adam, Jack, Mara, Michelle, Olaf, Vicente, Richard Goodman (lurking) Recording: http://uvigo.emea.acrobat.com/p32446444/ Agenda Vote on Lists Finalize survey Vigo base camp Adopters FAQ (tabled) Vote on Lists Proposed: [email protected] - for marketing purposes only, contact for people/institutions (temporary until new form/survey completed) [email protected] - for contributors/developers [email protected] - for adopters and people interested in light technical stuff Agreed by all to keep as is Finalize Survey Questions https://wiki.opencastproject.org/confluence/display/open/Adoption+Survey+Draft Proposed goal statement: The goal of this survey is to survey the larger Opencast Community to solicit further interest in piloting Matterhorn 0.5 and 1.0 in order to better prepare to support their activities and to support the Year two proposal. Suggestion to incorporate into Institution/Organization profile on www.opencastproject.org Jack: feels we are missing info we need to provide to potential adopters, e.g. technical requirements, skill requirements, infrastructure, etc; we need some introductory information Lots of discussion around questions on survey Plan: Olaf to continue to work on draft rest of this week Discuss Vigo Basecamp Vicente: have already deployed 25 virtual servers for any institution who wanted to try PuMuKit, gave them a login and password for administration so they can start customizing; some are using these in production, or some started there then copied config files to local server Vicente: idea is to do the same for Matterhorn, issue of recorders is a little complicating, but could have some hardware recorders and/or dummy recorder ti get an idea what can be done Vicente: also to prepare documentation in Spanish, thinking of Spanish mailing list to answer questions Vicente: People and institutions are in a waiting position with regard to their decision about investing in lecture recording systems. Some fear exists with regard to the project coming "from another world", not something smaller institutions would run as early adopters. adoption Adoption Strategy Meeting 2009-11-19 Michelle Ziegmann posted on Nov 19, 2009 Nov. 19, 2009 Recording: http://uvigo.emea.acrobat.com/p19586062/ Agenda -> Installation "experience" -> Basecamp planning -> 0.5 community interest survey -> marketing material brainstorm -> Support Strategy NOTES Olaf: Hopes all have reviewed adoption strategy: https://wiki.opencastproject.org/confluence/display/open/Adoption+St rategy Olaf: Central strategy is "base camps", for example UK have at least 4 base camps that will be ready to support us (Saskatchewan, Steeple, Vigo, UNL) possible Osnabrueck as well? we have internal and external base camps; Steeple is external Chris: Have a few processing servers, willing to run private VMs, capacity to run 6 VMs (some have been spoken for) U of Regina, Plan to have several VMs of 0.5 and first line of support Wants to run 1 public capture agent, anyone can schedule; but will require a shift of resources to customize scheduler UI Will prepare some less-than-optimal capture agents for use of some small CA universities to demo Question re: monthly release, how do we migrate the VMs with each release? Vicente (Vigo) Similar to Chris' setup Also with respect to language, translate some landing pages, basic documentation To be a point of support for Spanish-speaking people, on mailing list and wiki Technologically, can imagine something similar to what they've done for PuMuKit, using VMs ready to try Matterhorn installations; must talk about recorders, to really try Matterhorn, real power to try scheduler, need to have 1, 2 or 3 recorders Adam: regarding Spanish-speaking, plan is to have Manjit and Namrata as first line of support; can they provide 1st line of support for Spanish-speaking community? Vicente: yes, they plan to provide additional support for the spanish-speaking community Question: how can they manage/make decisions around resources regarding support, moving one of the Ruben's to support side? Also engaging with some support service providers? wondering if it's reasonable to work with them to become support providers (possibly paid) Clarification: want access to the information, want people to have access to the software so they can learn it and be able to sell support services and hardware Regarding capture, would like to build a virtual capture device that would give visual capture of files (dummy agents) Idea to have 3-4 installations with virtual capture devices like this in place, and 1 installation with a real capture device Clemens (Osnabrueck( Have done implementation past few years of virtPresenter could do this for Matterhorn; Would not be a scenario for 0.5 (right?) Would provide servers for smaller universities, but they want the content on their own servers Regarding Capture Devices Steeple has also identified capture devices as a need Committed to requiring 2 more capture devices for demo during the project Adam: we need to figure out how many capture agents we have, who they're designated to Basecamp Planning UNL is interested, but has questions around resources and hardware; need criteria Berkeley may be able to host capture machines Chris: it's much easier to allocate soft resources (e.g. VMs) rather than purchase hardware Adam and Chris will be talking with Steeple, will clarify their willingess to acquire necessary hardware and have the technical skills Adam: not clear whether we need to set up capture machines physically at basecamps, or can just use the ones at Sask Chris: technically, it doesn't matter much; but would like people to have a hands-on experience with these, also need further testing under various situations/environments Agreed we want to support Steeple's basecamp setup, including sending them a capture device Olaf: can we invite base camps to this weekly meeting? Chris: question about how we see base camps, and new base camps as they make decisions to come on board - is there room? what happens to basecamps relative to funding? Olaf: currently looking at base camps in terms of 0.5, focusing on this; but beyond this, we should re-evaluate Vicente: we should consider our potential adopters in the base camp strategy Olaf: disagrees, should focus on identified base camp providers first, they have a stronger commitment already; then bring in potential adopters Community Interest Survey Adam and Olaf working on this We have 12+ potential adopters that we have asked questions regarding their expectations for MH 0.5; but need more information to really understand what level of adoption, what perspective they are considering Would like to survey these regarding the details of their interest Also will use this for additional outreach to the community for more adopters Vicente: would like to be able to point potential adopters to something for them to complete, to give their name; has a big meeting next week, annual meeting of all Spanish universities Next meeting will invite Steeple to next meeting adoption Year 2 Planning Meeting Notes Tag News posts with "year2" to include it here. 2010-01-08 Year 2 Requirements Meeting Allison Bloodworth posted on Jan 08, 2010 RECORDING: http://uvigo.emea.acrobat.com/p36296666/ Attendees: Adam, Allison, Josep, Josh, Judy, Martin, Michelle, Olaf, Ruediger, Tobias, Vicente NOTES: starting at line 90 PROCESSING & SERVICES - OUT OF SCOPE authoritive annotation by instructors - instructors preparing video for students may want to annotate it ahead of time - why is this under processing & services & not engage? seems to be a variation on themes in engage. josh - agrees it belongs in engage, it's a workflow & engage question. can it be associated with dublin core as 'special annotations'? Judy: and hide it from the students until the instructor has done their work. UI service (e.g. libraries) - no response from anyone, adam says out of scope integration with library dititization efforts - our architecture would hopefully support this. Rudiger: I don't think libraries here means where you store books, I think it means software libraries (e.g. google gadgets). This may be misplaced. "On camp" for libraries preserving scholarly conferences Tool to embed video in Google Apps - seems to be low-hanging fruit, and what we're doing in 0.5 Integration with university unified conta architecture - not sure what this is Proof of concept authn/authz support in existing portals - this isn't something we'll be supporting out of the box in year one. there are standard apis with CMSs which allow you to integrate with multiple cmss. Notifcation service - Martin: UMS is at IU, integration with ms messenger. I think it was there because if there was something in the workflow it could be associated with your UMS so it could come via multiple push notification services. Tobias says he didn't bring that up. Martin J. Wagner: UMS is a service Martin J. Wagner: Microsoft Service Martin J. Wagner: http://kb.iu.edu/data/anrp.html Martin J. Wagner: I think it was there for notifications Martin J. Wagner: Unified Messaging Service (UMS) integrates voice messaging with your email account, letting you store voice messages in your mailbox along with your email. With UMS, you can access your voice messages using an email client or your telephone with the telephone user interface (TUI). Adam: I think it's something we should strongly consider, Allison says +1 improve discoverability across insitutions -> syndication & metadata (federation?) - Adam: didn't realize this was a necessity. Vicente: More related to distribution. Matterhorn could have a plug in in the future to distribute to any other national portal, e.g. steeple or arca. Tobias: after Matterhorn is installed by many institutions, it's a unique opportunity to aggregate content. I think we should add something like "under the opencast umbrella we should get community projects running." Vicente: Not to have one monolithic national portal but allow portals to talk to each other. one portal could search other portals in a specific area.perspective for year three... Josh Holtzman: improve discoverability across institutions Tobias Wunden: Right. I really like this. We shouldn't set the portal up but make it very easy to aggregate content. Martin J. Wagner: +1 Josh Holtzman: since we all use the same service contracts, we can interact with other Matterhorns easily Adam: I just want to be careful to not go to the federated search. we can enable that ability but to come up with a way to do this search across Matterhorns I think is out of scope. Tobias: we are serious about metadata, and it needs to be and will be improved. I don't think that federated search will be completely out of scope. Adam: I've heard that people don't use federated search (from Matterhorn board). I think we just need to discuss further. Exposing it is a good idea tho. create new series based on exisiting recordings - Olaf: this is about having a channel called distinguished speakers, or with speakers from an existing department. could you easily compile that channel? One episode could be a member of many series , like dublin core? - this may be important but not that important. Tobias: this is already implemented in the RSS & Atom feed way, but implementing this in dublin core is much more difficult. Adam: seems to also be like "improve discoverability across institutions" - then that would have to be dublin core. Olaf: RSS & Atom feeds are more important than dublin core. distribute to mobile devices - olaf - what does this mean? how is it different from what we already have? if we're submitting to youtube or itunes I know it's pretty universal to mobile phones, and itunes is an iphone app. tobias: distribution to mobile devices is done when we are distributing to itunesu or youtube because they support clients on many mobile platforms. if we want to leverage time-based metadata we'd need a special player for mobile devices. I don't think we need to create a simple application allowing display of a list of videos. that's already done. there are several institutions like stanford & duke who have their own iphone apps. adam: I don't see this as essential in year 2, though it's cool. tobias: i think we should focus on the desktop version of these capabilities first (e.g. isochronic metadata) as just doing that will be a lot of work. Judy: remember that Berkeley's iTunesU videos don't play on iPhones Olaf A. Schulte: +1 Adam: We are wanting the isochronic metadata in year one. Is this something beyond that. Tobias: yes. Content federation - put a question mark beside it, not sure how much we want to do this. interplatform connection between two implementations of matterhorn - tobias: isn't that the same thing as making content discoverable? olaf: I think this is about insitutions who have multiple mattehorns and want to aggregate towards the outside world (e.g. multiple departments). Adam: I think this could mean many things. Different roles, shibboleth, translating across different instantiations, sharing of content. I think it will be a common use case. Ability to use a matterhorn service from one instantiation to another. From cloud services standpoint, I think it's forward looking that would distinguish us from other products, but it's not required at Berkley for year two. Josh: I don't think it's very sexy in terms of what the end users want, but I think it's something that will be pretty critical. Tobias Wunden: +1. Olaf: we'll need to discuss among institutions whether we'll focus on technology or the learners, as Adam brought up. Vicente: If you can't do the same thing using the full installations of matterhorn in order to give servies to the other, it's a matter of optimization but you can do it anyway. Adam: Vicente, you're saying that because we're SOA one university could use the encoding service of another university. Josh: yes, you could do this in theory, but that doesn't mean a lot. I won't believe we've actually attained it until I see it working. Vicente: it will be the difference between our base camps. we can give more power to the base camps to give services to other institutions. it's not optimal. you can do it with more hardware. Josh Holtzman: right. Tobias: it's a crtical application that will enhance matterhorn a lot. Rüdiger: +1 Adam: take the concept and confirm it's a reality. We'll need authentication/authorization layer over the services to be sure they are being used properly. josh: yes, there are lots of ways, e.g. adding a wrapper for security, monitoring, auditing, these things can be easily tacked on. Adam: allow specific roles to do specific things across instantiations. out of scope for year 2. Mix "video" and "display" to generate another video for mobile devices - or do a composition. Tobias: just want to clarify there are two ways to handle this. Create a new video and cut out a piece or do compositions. it could be engage only or processing depending on what we want. we may want processing as it allows for much more flexibility - combine things as well as play a small portion. Rüdiger: +1. Adam: strong agreement. Composer: mix multistream recordings to one stream videos (PiP, etc.) intelligently - Tobias: example: we've thought about trying to get out an algorithm which shows the presenter then show the slides then switch back to the speaker. otherwise we lose real estate especially on small screens. always having pip there can be annoying. adam: do you mean being able to choose what view you want, being able to toggle between views? Tobias: yes. Adam: we will have multiple streams of content coming from devices. seems to me to be pedagogically relevant. ENGAGE MUST HAVES Josh: I want folks' feedback. In our grant proposal does it make sense to align with other open source projects. when we get into more sophisticated CMS use cases, do we want to specifically mention other projects that deal with CMS, do we want to say we will try to leverage their capabilities. We may keep adding things on (e.g. role vs. object based authenticaion) and reinvent the wheel. Adam: I'd like to leverage software out there, not sure if we need to put it in the grant. It might be more important to chris mackie than scholarly communications. I don't know yet what they are looking for. Josh: when Mara has this conversation, I'd like to explore this question. Adam: we could always put it as a footnote. scoped annotations based on authn/authz (e.g. share with class, share with individuals, share with public) - Adam: we've punted this for year one. Josh Holtzman: very complicated :)and handled by content managment systems. Adam: it would be risky, we'd have to incorporate a CMS. where are the lines drawn for Matterhorn. Media pipeline and lecture capture system? store and manage annotations? does that step on the toes of the LMSs already out there? are we moving into a space that has been well established. Josh Holtzman: 107 could take all year Rudiger: I think it's essential but as you say it depends on other systems (e.g. to find out who is in a class). We can provide interfaces, APIs that systems can use to communicat with matterhorn. Josh Holtzman: I think 107 shoud be year 2 Adam: is it an annotation service that lives in the LMS. Tobias Wunden: +1 to what Josh said. Josh Holtzman: we'd need federated group providers. this is complicated. we don't want to invent this ourselves. we'd need to tie into a variety of LMSs so we'd need to be able to share annotations within a google group, within a class in a LMS. Adam: maybe in the grant we can say (it's complicated) and they would be amenable to whatever we do. If we do put it in the summary of things we're anticipating doing, we need to make sure we're not overpromising. we should continue to discuss this topic. maybe we can get into more details in person. If we think about 108 (open social support) a bit in this context, we have large social networks like facebook, we have a more standardized interface there. Maybe we can mix what we know about LMSs with social networks and how authorization is provided there.. Adam: I think it's a trend with LMSs having open social containers and supporting that pardigm. Would that help us with allowing the multiple applications in many environments approach. Josh Holtzman: yes, that's definitely part of the solution. Adam: I assume that will be part of 107. Chris has a negative 2. He liked portlets for uPortal instead. Josh Holtzman: portlets are so old school Rüdiger: write a wrapper and it can be nearly the same. Portlet support: not much support for that Hotspots by most viewed. Adam: I'm the only one who voted on it, but I think it's important. Tobias: we should start leveraging the metadata we collected by media analysis. Judy: cool but not necessarily pedagogically worthwhile. Allison: It seems like it is to me. Students marking points they didn't understand and coming back to them may indicate the unclear parts of the lecture. Judy: It's the lemmings philosophy. I'm not sure it is useful when it comes to thinking about their learning; it's possible there are negative impacts on metacognition, reflection. Rüdiger: Johannes will write his master thesis about this, and how valueable this information may be. Hotspots by most annotated STRONGLY CONSIDER HD VIdeo: Zoom in to parts of the screen (read the board) - Adam: seems popular. Rudiger: yes it's compelling & doable. we have a student trying to figure out how it may work. Prototype: http://vs1.rz.uos.de/public/virtmm/player/?vi deo=http://vs1.rz.uos.de/public/virtmm/podcast/algorithmen09-hd/algorithmen09-hd_2009_10_19.mp4. Adam: northwestern did some work on that. mobile app (find, view, share) - Adam - not sure what this means, seems like our distribution channels already have that. not for year 2. template editor: associating multiple sources of content. Tobias: I don't think this is the same template editor we talked about before (e.g. intelligent pip), this to me seems to be the ability to lay out the web page. Adam: I don't think that's important. Seems to be small potatos, we'll table it for now and talk to chirs. amazon recommends - not popular keyboard and concept cloud per video/course/class: Olaf: I think this is about the indexed content we have from the object and the ability to summarize what's in a tag gloud to easily recognize what a video is all about. Tobias: I feel strongly about this. By creating this concept cloud we can link to other content perhaps linked on the same site or other universities. I think it's a good starting point for connecting to third party content. Olaf: could you explain how the cloud concept aligns with aggregating content? Josh: you could expand the tag cloud to other third party recordings. Allison Bloodworth: but we'd also perhaps have a tag cloud on a per recording bassis? Allison Bloodworth: that seems valuable in terms of figuring out what the major concepts in a recording are. Josh Holtzman: yes... the tag cloud exists for a single recording, and you can easily discover related recordings Olaf: not sure how that takes us to a repository of other universities. that could be confusing. Tobias: we first need the concept cloud then we determine where we link from that cloud. we could allow people to link to whatever content they think appropriate (e.g. other universities, wikipedia, syllabus) Olaf A. Schulte: +1, Olaf A. Schulte: Translate, Look up in Dictionary, Buy related books in Amazon. Adam: I think it's sometimes easy to say let's do a tag cloud. OUT OF SCOPE share annotations, share playlists connection to semantic web - Tobias: assign meaning to keywords and link to other related content. give people and institutions a starting point. we can't do it all ourselves. for example by providing a tag or concept cloud. we should consider bringing other people on board to help, e.g. the uVista people. attach files to class course or event (faculty or admin) -> incorporating supporting documents into the index - if anyone has feelings about this please chime in. tobias: we should think beyond students downloading what comes with a course but also has to do with indexing rich metadata. Allison Bloodworth: we need to attach files to recordings. not sure how this is different. student talk-back (cam mess) Allison Bloodworth: sounds like students talking to the professor Allison Bloodworth: and being part of the recording UI Personalization: I assume that is a low priority. Rudiger: I think this means if you have multiple video streams you only want to see one. I think it has to do with accessibility - ability to adapt the UI to your needs. Good for people even without handicaps. Tobias: I'm also thinking about localization settings. If there is a german version I'd like to see that one, playlist, shared content with other student groups, getting back to the portal idea as well, enabling students to use the video content to learn. Josh: I was just going to say that goes back to what's our relationship with CMS. localization is easy to do, other things might be more challenging. year2 Communication Getting Support Trying to install and use Matterhorn, but running into problems? Below are the recommended mechanisms for getting help: 1. Search the mailing list Nabble archives, to see if someone else has already gotten support for the same issue. 1. Send an email to [email protected] - subscription is required. 1. Log into #opencast on IRC to get help. Recommended IRC client software: Mac-Colloquy, PC-Pidgin 1. Submit your support request or bug report in Jira ("Create new issue") Mailing Lists The Opencast Matterhorn project relies heavily on the use of mailing lists for communication across the team. There are 3 mailing lists associated with the project. List Who should subscribe Subscribe Link Archive Opencast Community [email protected] | Primary channel for support requests for Matterhorn All Matterhorn Team members; Anyone interested in receiving updates on the project | http://lists.opencastproject.org/mailman/listinfo/community | http://n2.nabble.com/Opencast-f3480289.html | Matterhorn Project [email protected] | All Matterhorn Team members; Anyone interested in detailed day-to-day progress of Matterhorn NOTE: You should also be subscribed to the Community list, as important announcements about Matterhorn will only be sent to the Community list. We assume everyone on the Matterhorn@ list is also on the Community@ list. | http://lists.opencastproject.org/mailman/listinfo/matterhorn | http://n2.nabble.com/Opencast-f3480289.html | Matterhorn Commits [email protected] | Anyone interested in tracking commits to the subversion repository | http://lists.opencastproject.org/mailman/listinfo/matterhorn-commits | | Infrastructure/IT Requests [email protected] | Matterhorn project infrastructure team members | http://lists.opencastproject.org/mailman/listinfo/infra | | DAILY STANDUP The Opencast Matterhorn team will adopt an asynchronous "daily standup" mechanism, where each team member should provide a very brief synopsis of what they are working on and any obstacles in their way. Subscribe to the daily standup feed. To post your daily standup, post your message in Twitter, tagging it with "#ocdaily". JIRA https://issues.opencastproject.org. [Note: in development] This is the main area where active work on the project is tracked, and also a place where bug reports and new feature requests should be filed. The JIRA content is publicly accessible, but you need to create an account in order to post a bug report or request a new feature. To create an account, please visit https://issues.opencastproject.org/jira/secure/Signup\!default.jspa\|https://issues.opencastproject.org/jira/secure/Signup\!default.jspa (https://issues.opencastproject.org/jira/secure/Signup\!default.jspa) and sign up. "Meet" Spaces ADOBE CONNECT The University of Vigo provides an Adobe Connect Meeting room for the Opencast Matterhorn project at http://ado.uvigo.es/opencast. The meeting room allows for videoconferencing, chat, screen and document sharing among multiple participants. This meeting is available for any team member to use at anytime for scheduled or impromptu meetings. IRC CHANNEL (#OPENCAST) On irc.freenode.net, the chat group #opencast is used as a group chat by many of the developers. "Share" Spaces There are several spaces dedicated to sharing or reading about less formal ideas, processes and thoughts about Opencast and the Matterhorn project. PLANET OPENCAST This is an aggregation of blogs of people working on (or writing about) the Opencast Matterhorn project. To add your blog (or any RSS feed) to Planet Opencast, login to your website account at www.opencastproject.org and go to My Account > Edit > Opencast Profile. Enter details in the Blog Information area, and your posts will be included in the feed (allow up to an hour for Planet Opencast to be updated). FACEBOOK Become a fan of Opencast at http://www.facebook.com/pages/Opencast-Project/115843586240! Community Newsletter The Opencast Matterhorn Newsletter has moved to its new location at www.opencastproject.org/newsletter. Opencast Matterhorn Newsletter - October 2009 The Opencast Matterhorn Newsletter has moved to its new location at www.opencastproject.org/newsletter. Opencast Matterhorn Newsletter - August 2009 The Opencast Matterhorn Newsletter has moved to its new location at www.opencastproject.org/newsletter. Opencast Matterhorn Newsletter - December 2009 (draft) The Newsletter has moved! The Opencast Matterhorn newsletter is now located on the main Opencast website (instead of the wiki) at www.opencastproject.org/newsletter. The RSS for the newsletter has also changed to: http://www.opencastproject.org/newsletter/feed. Opencast Website Makeover Earlier this month, we launched the new Opencast website at www.opencastproject.org. While this website has been a resource for the Opencast Community, many of you expressed difficulty finding Matterhorn related project information. Based on your excellent feedback, Matterhorn has more of a presence on the site. In particular, please note two new sections about Matterhorn: Matterhorn Project Getting Started Guides These guides will address the more common questions about Matterhorn, and will be kept up-to-date as the front-line resources. Matterhorn Features & Functionality This is the feature list - the vision for Matterhorn 1.0 - to provide a high level understanding of what Matterhorn will do. In addition to providing key information about Matterhorn, this site will most importantly support the mission of the Opencast Community: "to offer guidance and information to help others choose the best approach for the delivery and usage of rich media online." To support the Community in this mission, we have added a new section - the Community Resource Exchange- which offer a new way to share resources among the Community. It's a space for the community to share publications, reference materials, best practices, showcases, and products - for you to share your experience and learn from others. Please consider contributing to the Resource Exchange! With a new navigation structure, we hope the Community will be able to more easily locate and contribute meaningful resources more easily than before, such as: Community Calendar- stay up to date with what is going on in the Opencast Community and the Matterhorn project. Presentations- at your disposal to quickly learn more and re-use for your own purposes. Directory of Organizations- get to know the Opencast Community. Call for Institutions The Matterhorn 0.5 release will provide individuals and institutions a first glimpse into what will become Matterhorn 1.0 in July 2010. To better prepare and organize the 0.5 release and to help you get the necessary support, we need you to answer this survey to collect information on how you would like to install, implement, use, and evaluate Matterhorn 0.5 - or subsequent pre 1.0 releases. Feel free to forward this survey to colleagues! Matterhorn 0.5 Release Our first preview release Matterhorn 0.5 will be available January / early February 2010. This release will be a modest one, but along with its bugs and limited feature set comes the unique opportunity to follow our progress, assist us with testing, and provide general feedback. It's important to us that developers, designers, and thought leaders in media and education join us as early as possible to fullfill Matterhorn's potential as an open source alternative to proprietary media service frameworks, interactive media tools, and lecture capture systems. The 0.5 release will interest individuals managing general academic and lecture recordings. institutions that would like to get a first insight into Matterhorn with respect to their adoption strategy. Releasing by Service and/or System For 0.5, we will release Matterhorn's existing service components as well as its "out of the box" lecture capture system. For subsequent pre-releases, we will likely have individual releases per service as well as full releases for the lecture capture system. For instance, we may release a new 0.6 version of a Matterhorn component, such as the encode service, before releasing a new 0.6 version of the "out of the box" lecture capture system. This approach allows us to offer the latest and greatest components without being encumbered by a monolithic system release. "Release early, release often" is not only a development philosophy within the Matterhorn project, it's an invitation to the Opencast Community to join the expedition towards Matterhorn 1.0 at any given time. Your feedback will help us reach the summit. Orgsona: The Institution as Customer Our UI and feature set will be geared towards our primary "orgsona", "The Cobbler", introduced in our last newsletter. This means that institutions with fairly simple needs and limited or no existing lecture capture systems should consider Matterhorn a complete product. Developers hoping for more flexiblity and customization will find promise "under the hood", since the service oriented nature of Matterhorn is inheritently flexible. Nevertheless, we will do our best in future releases to make Matterhorn even more flexible and customizable to satisfy the needs of our secondary orgsona, "The Sophisticate". Documentation Draft Our developers are drafting documentation, so that the community can: install and configure Matterhorn's lecture capture system and/or develop against its services. We emphasize "draft" because this documentation will be neither perfect nor complete. Although we're working hard to provide "good enough" documentation, we will look to the community to let us know when things don't make sense - and hopefully make an effort at upgrading the documentation beyond the draft status. Only with your input will Matterhorn become more usable for developers and sys admins overall. Adoption Strategy As a funded open source project with community source ambitions, Mattherhorn needs individuals and institutions to establish a self-supporting help network. We will do our best to allocate limited resources for support, but a broader support model is the only path to long term sustainability. The less time the core Matterhorn team spends supporting early releases, the more time they can focus on development of new features and addressing feedback received from individual and institutional testers. One strategy for a self-sustaining support model is the establishment of Matterhorn base camps (see Matterhorn Base Camps Section below). T hese camps will be offered by the community and provide a foundation for inexpensive testing opportunities and regional or national community support. Thus far two base camps will be established from funded Matterorn project partners, one on each side of the Atlantic, as well as two other base camps supported by enthusiasts from the Opencast Community. This number may increase before the release of 0.5 and will likely grow as we approach 1.0. Software Distributions VMware Image A VMware image running ubuntu will be available with the Matterhorn system pre-installed and configured. Install scripts for GPL licensed components will be part of the VM startup procedure to avoid any legal issues. This distribution will run on any Linux and Windows platforms using free software called VMware player. VM fusion for OSX will also play vm images, but this software is not free. This VMware image is relevant to the "novice" and "intermediate" climber (see classifications below), and it should be an easy installation for configurers or general users with moderate technical skill. If someone wants to get Matterhorn up and running fast, this is the distribution for them. For institutions without hardware or technical resources, base camps will offer a limited number of Matterhorn virtual machines for free . Build and Install A source archive of 0.5 will be available for download. System administrators and developers will be able to follow instructions in the wiki to build and install this distribution locally. This software is relevant to the "intermediate" to "advanced" climber and users will need some knowledge of mvn, svn, and possibly java. Capture Install An installation script for 0.5 will be available for download. System administrators and developers will be able to follow instructions in the wiki to build and install this distribution locally. This software is relevant to the "intermediate" to "advanced" climber and users will need some knowledge of mvn, svn, and possibly java. This installation script will only work for Matterhorn specified capture devices. Matterhorn Capture Appliance We do not intend to sell this device, but Matterhorn will provide inexpensive hardware specifications for those interested in building their own Matt erhorn capture appliance. Beyond purchasing the hardware components, it's free. No licensing costs. No maintenance fee. Nothing. And approx. $1000(USD) for an appliance that captures vga, video (H264/MPEG2), and audio, it's a steal! A "dummy capture agent" will be available out of the box for institutions interested in testing automatic capture, but uninterested in building a Matterhorn capture appliance on their own. Additionally, a remote capture appliance will be available for institutions interested in testing a real Matterhorn capture appliance. Matterhorn Base Camps As described above, base camps are not only a central component for testing Matterhorn prereleases, but the nucleus of the Matterhorn community. We are therefore delighted to see four base camps in the UK, Spain, Israel and Canada. UK Base Camp, Steeple Projects The Steeple-BR Project is an Opencast affiliated UK based JISC funded project (running until 31st August 2010), a core aspiration of which is to conserve resources by not duplicating effort. Currently, each institution is pursuing their own technical developments, often at significant cost in both technical and financial resources. The Steeple and Steeple-BR projects seek to build a UK community to share tools, and to develop these jointly where they are needed. The hosting of an Opencast Matterhorn base camp by the Steeple-BR Project community fulfills part of this aim. More information about the Steeple projects may be found on the project wiki at: http://www.steeple.org.uk and the project blog at: http://steeple.p osterous.com. For updates, join the project mailing list at:https://www.jiscmail.ac.uk/STEEPLE Loughborough University will host the UK Opencast Matterhorn base camp, providing a number of virtual machines for demonstration purposes, as well as an opportunity for other UK institutions to try out the reference capture hardware which will be available for free loan to participating institutions. Lecture capture is now accepted as a part of the E-Learning toolset available to staff and students at Loughborough University. Loughborough are currently undertaking a small scale pilot of the Echo360 lecture capture system, which has already proved very popular with the staff and students who have used it. After a deliberately slow start, there is now growing interest in lecture capture. Hosting the UK Opencast Matterhorn base camp is an ideal opportunity to compare and contrast these two systems. Loughborough also hopes to be able to pilot another installation of Opencast Matterhorn for its own staff and students. Spain Base Camp, University of Vigo The University of Vigo will host an Opencast-Matterhorn demonstration Base Camp. "Ready to try" hosted installations of Matterhorn Core and Matterhorn Capture devices will be available online from 0.5 to 1.0 releases. This base camp will try to be the reference base camp for Spanish speaking Matterhorn community but, of course, any international Institution (or individual) will be welcome to try the "Matterhorn experience" with us. Transition from "hosted experience" to "on campus installation" will be also supported. University of Vigo network is part of RedIRIS the Spanish high bandwidth research network, so no bandwidth issues are expected. Contact and support will be available in English and Spanish. Our timezone is CET; contact Vicente Goyanes, [email protected]) Israel Base Camp, Tel Aviv University Our base camp will provide dedicated virtual machines and high bandwidth access connectivity to all near by institutions who would like to try and gain some experience using Matterhon 0.5 and later releases. Please contact Jack Barokas at [email protected]. Canada Base Camp, Saskatchewan The University of Saskatchewan is hosting a Canada-wide base camp to demonstrate Matterhorn features from capture agent through processing to delivery for the 0.5 through to 1.0 releases. Dedicated virtual machines for processing and delivery are available upon request (contact Christopher Brooks, [email protected]), and open-web demo accounts will be made available. Hosted in a high bandwidth facility on the CANARIE research network, the University of Saskatchewan team will investigate the feasibility of running Matterhorn in a cloud service-based environment. International institutions who are interested in being involved are welcome. You and Your Institution We've identified potential roles you may play as you engage with the Opencast community and contribute to Matterhorn. Which will role best fits you? Novice Climber An individual or institution that casually checks out Matterhorn to better understand its features or technologies. They compare its features with other commercial products and do some form of competetive analysis. Some demo an existing online version or run it OOTB. A developer may read the documentation and install it on their laptop to poke around. In terms of the "community", they generally lurk on lists and occasionally respond to threads. For 0.5, this group is mainly interested in learning more about Matterhorn by reading high level documentation and looking at a current online demo. They're not interested in spending resources on Matterhorn, and are just in a preliminary exploration stage. For 1.0, they may run a small (one class) pilot at their campus or dedicate more resources to determine total cost of adoption. Intermediate Climber An institution/organization that has designated limited resources to install, test, and pilot Matterhorn. These individuals or institutions have a strong desire to participate in Matterhorn and will likely post questions to the list when they're in need of an answer. They will depend on documentation when troubleshooting, and they're fairly self sufficient. This group may already have a basic existing system and/or an established podcast program. The intermediate climber most aligns with the Cobbler orgsona. For 0.5, this group is interested in testing Matterhorn locally or using a "basecamp" to run a small testing environment. They will enter feature requests in Jira through Community Feature Requests and bugs if they find any problems. For 1.0, they'll run Matterhorn OOTB for a pilot involving a few classrooms in the Fall. They anticipate Matterhorn will be a long term solution. If they're migrating from an existing system, their migration path should be simpler due to the lack of infrastructure and simplicity of their existing system. They may make minor modifications to Matterhorn through configurations or modifications to the UI. Advanced Climber An institution/organization/individual that is heavily involved in the day to day activities of the community. They follow and respond to the list frequently, and they log into irc and engage in "low level" activities. They're willing to get their hands dirty to make things work, and will submit patches to Matterhorn for their local needs. They may contribute to documentation or initiate conversations on list. They're comfortable within Matterhorn's wiki, issue, repository, and integration environments. They have their finger on the pulse of Matterhorn and they see themselves as a contributing to its health. This group may already have an advanced system and/or the capacity to do a big rollout. The advanced climber most aligns with the Sophisticate orgsona. For 0.5, this group will provide substantial testing and may push Matterhorn beyond its capabilities. They will explore it in as detailed a manner as possible to understand integration costs and the total cost of adoption. For 1.0. this group will integrate Matterhorn with their campus systems, and run a pilot in a few classrooms. This group may alternatively adopt specific services from Matterhorn and integrate them into their existing system. They may not migrate to Matterhorn until there is more parity with their existing system. Master Climber This group contributes significant resources to the Matterhorn effort, and are likely committers and/or thought leaders on the project. They are heavily invested in the long term success of Matterhorn. Spreading the Word - December 2009 January 21st 2010: The IARU workshop on Open Access at ETH Zurich will feature a session on Open Video with speakers from various Opencast-related institutions; cf. with the programm. We're considering recording and possibly live streaming this event. Please let us know wheth er you would consider this valuable! Site restructuring process - working document AUDIENCES 1) Potential Adopter: Decision-Maker Examples: Program Director, Administrator, has strategic and financial responsibilities General Scenarios: Need to implement a new webcasting solution for the campus/department Struggling with keeping a current system up to date Struggling with the costs of a 3rd party solution Goals for 0.5 release: need to understand the limits of 0.5 and how these limits will be fulfilled in future quarters. We need to set reasonable expectations by providing a coherent 0.5 feature set as well happy path scenarios to demo and/or run a pilot for one course. 2) Potential Adopter: Technical Examples: Configurers Developers Program Administrators General Scenarios: Has been asked by management to evaluate Matterhorn as a potential solution for campus? Need to determine if Matterhorn will meet specific technical requirements Have specific technical problems with current system, would like to see if parts of Matterhorn can help Goals for 0.5 release: Configurers (traditionally system administrators) need to be able to easily install the system without understanding the intimate details of Matterhorn. We need to offer them an easy package for installation as well as adequate documentation to properly configure the system. Developers need an easy way to easily build the system locally so that they can demo and play with the various UIs and services. We need to provide them with adequate javadocs, high level service contract documentations, and installation/configuration documentation. Administrators need to be able to successfully pilot the scheduling, capture, and delivery of a class. They need basic user documentation and user interface functionality to schedule a course, ingest a file, and ensure that the file has been distributed. 3) Potential Contributor: Developer/Designer/Other Examples: A new team member from a partner school A new person from a potential adopting school Anyone from the community Scenarios: My school wants me to join the team and begin working on the project - I need to get started I like the idea and where this is headed, and want to help in any way that's needed I have an idea for a contribution, and want to know how to get started developing this against Matterhorn My school wants to adopt Matterhorn, and wants me to get involved now so I'm ready for the 1.0 release and can have some influence on the direction of the project INFORMATION THEY SEEK These are questions that might be asked of the above audiences. #1 #2 #3 Questions Answer currently exists X X What functionality will Matterhorn provide? Usage Scenarios X X Who is behind Matterhorn? Partners X When will it be available? Roadmap X Will Matterhorn continue to develop and be maintained? X What is planned for the future of Matterhorn? X What are the costs of implementing Matterhorn (money and staff resources, related costs)? X What are the licensing/legal issues? X X Architecture details Usage Scenarios, Services X X What technology is used Technology Stack X X System requirements for 0.5 install X X Current issues X X Report bugs and request features X X X I want to stay informed of progress X X X I want to contribute resources X X X I need help or more information WIKI STRUCTURE Getting Started (home page) A brief welcome to the project, with invitations to go into any of the following launch pages for specific intentions. The idea will be modeled after ht tp://maven.apache.org. Each of the pages below will provide a path through the wiki, based on the questions above, focused for the specific audiences/purposes Get to know Matterhorn (primarily leading to About Us and Product Documentation sections) See if Matterhorn fits my organization's strategy/needs (leads to some of About us and Product Documentation, but much of this content needs to be written) Take a closer look (or Under the Hood) (leads to more detailed areas in Product Documentation and Development Documentation) Pilot 0.5 release (needs to be developed) Contribute to Matterhorn (hits on all sections) About Us This section would be similar to as it currently exists. Potentially add a section to highlight and recognize the community, news, licensing and legal info? Product Documentation This is primarily the front-facing side of the wiki, for those on the outside trying to get to know Matterhorn; will be organized to provide a high level overview; primarily will consist of more polished and finalized documents vs draft and working documents; working and draft documents (e.g. UIs, service definitions) may move her as they are finalized. Roadmap Features & Functionality (currently "Usage Scenarios") This will open with a high-level, functional illustration and explanation of the product functionality and components; the user can select each component (e.g. Capture, Engage, etc), and go into deeper level of documentation, including: More detailed description of the component's functionality Relevant Scenarios (stories?) Architecture diagram of component Relevant Services User Interfaces Metadata Standards I'm not sure about this one, if it belongs here; maybe as a subpage within a larger section here titled "Standards", under which we could also include standards we are using such as media format, calendaring, etc. Make sense? Development Documentation (currently "Technical Documentation") This is our workspace, primarily intended for developers and designers on the project. By retitling this to "development" documentation, I think the evolving nature of these documents can be implied. Potential adopters will likely want to dive into this section to get a more detailed understanding of the development effort. Project Coordination The is for team members, on the project, information about how the project is managed and the processes by which we do our work. Of only minimal interest to adopters I would think. I'm inclined to leave this as is. Archive The structure and use of this section needs further discussion Revision Proposal for www.opencastproject.org Community About Opencast (Is it that you want to promote "Opencast" as a term? I would say "Opencast Community" here) Features: Mission, Branding & Logos Members ("Members" sounds exclusive; as a non-native speaker, it's hard to tell whether it actually is. How about "Institutions & people" or "Participate"? Purpose: Networking Features: Self-registration, register as an organization or individuals, will copy current list on http://www.opencastproject.org/institutions, registration will provide people to share information about their current system, experience, etc. Resources (or "Exchange") "Resources" is not meaningful to me, with the description provided I would say "Information" or "Information exchange". Do we have enough information or can we expect enough contributions to make this valuable? Purpose: Sharing Features: Community-contributed, tagged and categorized by type (e.g. documents, products, technologies, best practices, research, presentation), other members can comment, rate each resource, searchable News Purpose: Aggregating relevant information Features: Community-contributed rss feeds (e.g. Podcast Producer Forums, WTF; would we also feed Matterhorn news here...) Planet Opencast Purpose: Sharing Features: Aggregated blog posts, anyone from the community can subscribe their blog posts (... or is this where we infiltrate the community?) Community Calendar Purpose: Sharing events of common interest Features: Anyone can post a meeting, conference, or event for community interest (should probably limit Matterhorn team meetings unless they are aimed at the community) Mailing List Archive Purpose: Facilitating communication Features: Embedded nabble archive of recent posts, with link to Nabble for more advanced searching Matterhorn Project What is Opencast Matterhorn? (include video overview - the "commercial") Features Getting Started Guides (Point to the Getting Started Guides in the wiki) Follow Matterhorn (Mailing list info, newsletter, rss feeds, invitations to join Tuesday meeting) FAQ Team Calendar Affiliated Projects Metadata Project Open U Project Matterhorn Introductory Tour Video This is a draft storyboard for a screencast-based video, to be available for the 0.5 release. Video General Script Topic Screenshot Welcome Welcome to Opencast Matterhorn! We're pleased to have you take a look at the project in it's current alpha release stage. of MH Welcome screen Features 0.5 caveat Note that this is a preview release, giving you, the community, an opportunity to evaluate the software and give us feedback. illustration Not all features are available in this release. To see the full vision of the 1.0 release, visit www.opencastproject.org/matterhorn Powerpoint High-level Matterhorn consists of 4 major components: Scheduling and Capture, Ingest & Processing, Distribution and Engage animation, overview using features illustration Scheduling Capture The media life cycle starts with acquiring the video. Matterhorn allows you to schedule a class to be recorded, given that a screen capture agent has been set up in a room. This initial recording setup screen is also the place where information about the video is first entered. In future releases, this information will be able to be automatically imported using an iCal feed. Capture Capture The capture agent screen gives an overview of all registered capture agents, allowing an administrator to easily monitor the Agents agents status of the capture agents in the various capture-enabled classrooms. Recordings Recordings The administrator dashboard was designed to give an administrator the ability to monitor recordings quickly and easily, in their various states of processing. Upload Upload In addition to scheduling an automated capture, Matterhorn allows videos that were created outside of the system to be recording screen uploaded for processing and distribution. Simply complete the form, providing the necessary information about the video, and it will be available for additional processing. Distribution Distribution Once a video has been processed, it gets distributed to the distribution channel you specified. In this preview release, the only module distribution available is within the Matterhorn system, which includes an RSS and ATOM feeds that can be used in other systems. In future releases, you'll be able to configure Matterhorn to automatically publish your videos to other channels such as iTunes, YouTube. Search Search The Matterhorn distribution channel provides a powerful search service, which searches based on ... ? screen Player Engage Matterhorn also comes with a fully-accessible player. Built using a hybrid approach of Flex and HTML-based technologies, the player Matterhorn video player offers advanced navigation functionality that is fully accessible to users of all abilities. In future releases, Matterhorn Engage tools will include chaptering, bookmarking and other tools that will enable the learner to get the most out of the videos. Wiki: Install Evaluation The preview release can be accessed in a number of ways: throgh a Virtual Machine installation, a full build from the source. and options Installation and configuration instructions are available on the Opencast wiki. We also have a number of Matterhorn base Configure camps, partners who've made an installation of the software available for anyone to test. Wiki: Base Camps Install & Configuration A number of configuration options are available in this release, including how to register a capture agent and configuring a Configure feed. Visit the Opencast Matterhorn wiki for more information about these options screen Jira bug entry Call for At this stage in development, your input is very valuable. Please share your experiences with us and let us know what we got feedback right, what's missing, and what's not working the way you expected it to. The easiest way to share your insights is through the Matterhorn mailing list, but we also invite you to submit a bug or feature request in our issue tracker. With your help, we can build Opencast Matterhorn together, as a community. Governance Many thanks to OSS Watch for providing the example meritocracy governance modelthat served as the basis for this model. Additional structures were added to support the SOA / UXD design processes and to ensure accountability for the deliverables in the grant proposal.http://www.openca stproject.org/comment/reply/473 ENGAGING THE COMMUNITY SOURCE MODEL The Opencast Matterhorn Project is utilizing many of the organizational elements of the Kuali Student, Fluid, Sakai and CollectionSpace Projects, as well as some decision-making, role definitions and contribution processes adopted from the Apache Software Foundation. The aim is to pool community, college, and university resources and intellectual capital investments and leverage them to create a sharable academic podcasting solution that is of, by, and for higher education and learners around the world. The additional structure reflects the need to ensure accountability for the deliverables in the grant proposal and to support the SOA / UXD design processes and activities necessary to develop an infrastructure that adequately supports user-facing applications and workflows. We encourage a meritocratic, transparent, and inclusive approach to include the larger Opencast community wherever possible. Anyone with an interest in Matterhorn can contribute to the project's design, documentation and strategy. Anyone can join the project community and participate in the decision-making process. This document describes how that participation takes place and how one can increase ones influence on the project. Roles and responsibilities Decision Making Roles and responsibilities Users Users are community members who have a need for Matterhorn. Anyone can be a user, there are no special requirements. Users are the most important members of our community. We ask that our users participate in the project and community as much as possible. Common user activities include (but are not limited to): evangelizing about the project informing developers of strengths and weaknesses from a new user perspective moral support (a thank you goes a long way) financial support Users who continue to engage with the Matterhorn project and its community may find themselves becoming more and more involved. Such users may find themselves becoming a member of a Stakeholder Advisory group or a Contributor on the Development teams, as described below. Stakeholder Advisory Groups Matterhorn leadership and the development teams will make use of stakeholder advisory groups to inform their work. This is intended to ensure that key users and campus stakeholders are engaged with and informed about the project as well as subject matter expertise from across higher education. Members of the advisory groups will be providing guidance and input into the features, functions, and key technology outputs from the project. Their input will be sought in a variety of ways, either individually or as a group, determined by the need of the board, Project Management Committee or development teams. They function purely on an advisory level and although their input will be highly valued, they do not have a binding vote in the decision-making process. The advisory groups are intended to exist for the longevity of the grant-funded project, and may not be necessary once Matterhorn is released and a solid user/adopter base is established that can continue to provide this input. Membership on an advisory group is granted through invitation from the Matterhorn Project Management Committee (PMC) and the Matterhorn Board. Interested persons can request sponsorship from a member of the PMC or Board. Members of each advisory group will be chosen to ensure geographical and subject matter expertise representation. Three advisory groups will be formed: Technical, Functional and Executive. The Functional Advisory group will consist of campus and higher education stakeholders to include campus IT, faculty, students, and media specialists. The primary mission for this group is to help the team ensure that the applications and functionality of the system meets the needs of its primary users. The Technical Advisorygroup will consist of campus stakeholders to include enterprise IT architects, database administrators, and media specialists. The primary mission for this group will be to help the project prepare as seamless an integration process as possible. The Executive Advisorygroup will be formed by the Matterhorn board. An effort will be make to seek out members who represent target schools for Matterhorn adoption, such as smaller Liberal Arts colleges, consortiums such as NITLE (National Institute for Technology and Liberal Education), commercial affiliates such as the Longsight Group, and other potential consumers and evangelists, such as members of the OpenCourseWare Consortium, Open Source Software Watch (of the UK), research and educational networks, such as SWITCH (Switzerland). Development Teams The development teams will include a diverse range of skill sets, including software architects, java developers, business analysts, user experience designers, user interface developers, media specialists and quality assurance managers. Teams will be organized into specific domains of focus, with an emphasis on tight integration across disciplines where appropriate. Development teams will be comprised of Contributors, Code Committers, and Design and Document Committers. Contributors All those community members who contribute in concrete ways to the project are considered Contributors. Contributions can take many forms, such as those outlined below and in the above section on users. Anyone can become a Contributor. There is no expectation of commitment to the project, no specific skill requirements and no selection process. Contributors will already be performing actions as a user (see above) but will also find themselves doing one or more of the following: supporting new users (users are often the best people to support new users) reporting bugs identifying requirements Graphics and web design programming assisting with project infrastructure writing documentation fixing bugs adding features As Contributors gain experience and familiarity with the project they may find that making such contributions becomes easier. As a Contributor's profile and commitment increases they may be nominated for committership. Committers Contributors who have shown that they are committed to the continued development of Matterhorn through ongoing engagement with the project and its community may be eligible to become a Committer. Committership allows Contributors to more easily carry on with their project related activities by giving them direct access to the projects resources. In Matterhorn, the project's resources include not only code, but also designs, documents, and other non-code resources. As such, there exist two categories of Committers - a Code Committer, who is a developer with direct access to code, or Design and Document Committer, who may be Project Manager, User Experience Specialist, User Interface Designer, Business Analyst, and other discipline as relevant to the project. Design and Document Committers have access to resources other than code, such as design or document repositories. All committers must have a signed Contributor License Agreement (CLA) on file. The CLA clearly defines the terms under which intellectual property has been contributed to the Matterhorn project. Anyone can become a Committer; there are no special requirements other than to have shown they are willing and able by participating as a Contributor. Typically a Committer will need to show they have an understanding for Matterhorn, its objectives and its strategy. They will also have provided valuable contributions to the project over a period of time. New Committers are nominated by any existing Committer through the Matterhorn mailing list. Once nominated, there is a vote by all current Committers. The vote is based on the +1/-1 process (see Decision-Making Process below), and conducted through a private Matterhorn list to allow Committers to freely express their opinions about a nominee. The nominee is entitled to request an explanation for any "no" votes against them regardless of the outcome of the vote. This explanation will be provided by the Matterhorn Project Manager (see below) and will be anonymous and constructive in nature. Committer Emeritus Committers sometimes become inactive for a variety of reasons. To keep the repository secure and to simplify processes, inactive committers are given the status of Committer Emeritus. Committer emeriti no longer have accounts to the SVN or other repositories and are not expected to participate in community governance issues. However, if a committer emeritus returns to the project at a later date and asks for commit access, they can be reinstated without a vote. Committers become emeriti either: When they request committer emeritus status After six months of inactivity Matterhorn Project Management Committee (PMC) The Matterhorn PMC is comprised of the several key positions within the Matterhorn project, including project managers, technical leads, a User Experience lead and a Business Analyst lead. The Matterhorn Project Manager chairs this committee. The PMC is responsible for defining, planning, and meeting the project deliverables. The exact roles and responsibilities of each team lead will be defined as part of the project kick-off. These positions will initially be filled by appointment of the Matterhorn Board (see below). In the future, the PMC members may also invite additional members from the community. A nomination will result in discussion and then a vote by the existing PMC members. PMC membership votes are subject to consensus approval of the current PMC members. All PMC members will also be either Code Committers or Design and Document Committers. The Matterhorn PMC will initially include the following roles: Project Managers The Matterhorn Project Manager (MPM) acts as an overseer for the communication and work effort according to the project roadmap, and also serves as the PMC Chair. The MPM has no additional authority over other members of the PMC. The role is one of coordinator and facilitator, and to ensure all governance processes are adhered to. The MPM also provides regular updates and recommendations to the Opencast Matterhorn board. There will also be a project manager (PM) assigned to each work project. Project Managers for sub-projects will play a similar role for their team and are their team's resident expert in governance and communication processes as well as requirement priorities. Their most basic responsibility is enabling others to succeed. Technical Leads A number of technical leads will be identified who will lead development efforts in specific areas of responsibility to be determined (e.g. SOA, capture appliance, and user facing applications). User Experience Lead The UX lead will be responsible for addressing issues related to user experience design and usability across all work products. She will assist the development teams to shape the user experience across all work products and ensure the products adhere to current W3C accessibility guidelines. She will also provide user testing and feedback for the PMC and development teams. Business Analyst Lead The Business Analyst lead will be responsible for the identification, analysis, and prioritization of workflows. These workflows represent the different actors and tasks involved in completing the key activities within Matterhorn. They will also provide user testing and feedback for Matterhorn leadership and the Development and Support Team. The User Experience and Business Analyst leads will work closely together to ensure that Matterhorn's users' needs are met. They will also assist the project managers in the day to day prioritization of user requirements. Matterhorn Board The Matterhorn Board is responsible for management and oversight of the project, and is ultimately accountable for ensuring the deliverables of the proposed project are executed. The board will initially be comprised of the institutional leads, one individual from each of the 13 institutions who have committed resource to this proposal. Additional members may be considered at the discretion of the board as other institutions come forward with committed resources. While technical decision-making authority primarily rests with the PMC, the board will be involved when there is a proposed change in the direction or major deliverables of the project, or when the PMC cannot achieve consensus. The chair of the board is the lead PI on the project, Mara Hancock, from the University of California, Berkeley. Decision Making Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the PMC member and the board. All project management discussion takes place on the Matterhorn mailing list (occasionally sensitive discussion occurs on a private list, but general project management discussion always occurs on the public lists). Lazy Consensus This process need only be followed for an action that will significantly affect the project. Lazy consensus generally involves discussion around an idea, proposal of a solution, and if nobody explicitly opposes the proposal, then it is recognized as having the support of the community. Most day-to-day decisions will be made by the development teams in a less formal fashion. Any community member can present an idea for consideration at any time. In order to prompt a discussion about a new idea, send an email to the Matterhorn mailing list. Once the idea has become more concrete and appears to have a significant level of support within the community it is time to make a proposal. Proposals are initiated by sending a new email that summarizes the discussion with "[Proposal]" in the subject line. If a proposal has consensus, it will be incorporated into a current or upcoming iteration. Lazy consensus is a very important concept within Matterhorn, particularly in light of transcontinental working teams. It is this process that allows a large group of people to efficiently reach consensus. This efficiency stems from the fact that someone with no objections to a proposal need not spend time stating their position; furthermore others need not spend time reading such mails. For lazy consensus to be effective it is necessary to allow at least 72 hours before assuming that the community has no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal email. The time spent gaining the consensus of the community does not prevent work proceeding on the idea. People are free to work on the implementation of any idea or proposal while under consideration of the community. As mentioned earlier, this process need only be followed for an action that will significantly affect the project. Smaller actions, such as the addition of an optional feature or the fixing of a reported bug need no discussion. Contributors are free to action these items. Since this process is only followed for major activities the time spent reaching consensus is usually considerably less than the time spent implementing the decision. Voting Not all decisions can be made using lazy consensus. Issues such as those that affect the strategic direction of the project must gain explicit approval in the form of a vote. These issues require a more formal approval process in order to ensure a fully transparent decision making. It is at the discretion of the PMC to determine when a vote is necessary. Any member of the PMC can call for a formal vote on an issue. If a formal vote on a proposal is called, then the following procedure applies. +1 "yes", "agree" - also willing to help bring about the proposed action +0 "yes", "agree" - not willing or able to help bring about the proposed action -0 "no", "disagree" - but will not oppose the action going forward -1 "veto", "disagree" - opposes the action going forward and must propose an alternate action to address the issue (or a justification for not addressing the issue) To abstain from the vote, one would simply not respond to the call to vote. Every member of the community, from an interested user, through to the most active developer may express an opinion and vote. We encourage all members of the community to express their opinions in all discussion and all votes. However, only members of the PMC have binding votes for the purposes of decision making. It is the responsibility of the PMC to ensure all community members' opinions are considered. In most decisions made at this level, consensus will be sought. When there is an inability to reach consensus, the MPM will cast the deciding vote in consultation with the Matterhorn Board. A veto by a member of the PMC must be addressed until the veto is either rescinded, the proposal is altered in order to achieve consensus, or the proposal is withdrawn. In the very rare circumstance when consensus cannot be achieved, the MPM with consultation from the Matterhorn Board will decide the forward course of action. Process Accessibility QA process A starting reference for review prior to customizing this protocol for the Matterhorn player: http://wiki.fluidproject.org/display/fluid/Accessibility+Resources Additional content that will be added: Jaws and NVDA specific walk through instructions (focus on keystrokes required) Time permitting, VoiceOver instructions will also be provided for cross-platform support Please suggest additional requirements. Agile and UX - Observations, Suggestions, and Questions THINGS I LIKE ABOUT UX 1. UX can be strong advocates for the user. A customer may not ultimately be the person engaging with the application. In other words the "customer knows best" does not always apply. UX elevates user requirements to the same level as technical and business requirements. (sometimes they don't overlap). I think UX is unfairly labeled as research but little action. If done right, up front analysis will improve a project team's ability to make the right choices on a day to day basis and assess these decision's broader impact in the long run (at least from a user perspective). 2. "Conceptual framework" provides a low fidelity, high level sketch of the user interface before development starts. This benefits everyone because it provides yet another tool to help align the project's overall vision. It should avoid detail that sends people down design by committee rabbit holes. No colors, no wizz bang ajax. Just boxes and basic data as place holders. Generally from this design, the different parties start discussing cost and complexity. 3. "Personas" evoke both rolling eyes and smiles of agreement. It is hard to create good personas, and it can feel like marketing fluff more than a valuable tool. When done well, they capture the user's spirit, making them something more than a "user" of role X. UX defines user's core goals, and uses these goals as a filter to understand what motivates through their day to day interactions. It should offer a helpful pair of blinders for scoping functionality, allow the designers to get down to what is most important about a user. Personas also help define overreaching design goals, that act almost like mantras to help the projects make hard decisions around user experience. 4. "Low fidelity rapid prototyping" is far cheaper on paper than code. I think paper prototypes make a tone of sense up to the conceptual framework stage and to work out design ideas/problems. In order for this approach to work, UX needs to work closely with developers to understand what is and what is not possible. GENERAL UX CHALLENGES Having taken Alan Cooper's courses on user centered design, overall, I think his principles are correct, "accommodate the user, not the technology." In the "real world", it is not so black and white. Due to time constraints and other project realities, user experience at some point is compromised. Unfortunate, shouldn't happen, but there are other things that sometimes take precedence over user experience. And if the team members are communicating well, at the end of the day, these compromises do not add up to a crappy user experience. Furthermore, even with a great conceptual framework, there still a lot open questions, and it can be challenging to determine what is an acceptable user's experience iteration by iteration. And even the best engineers fail to adequately assess cost and risk when looking at a conceptual framework. Cooper's courses also did quite a bit of hand waving on how to transition from their beautiful requirements document to a tangible project bound by cost, time, etc. Apparently these factors are taken into account, but I thought this methodology lacked any details in incorporating these constraints. As a project manager, I am very aware that the devil is in the details, and I get wary when the scent of gloss is in the air (not that I am immune from glossing things over myself) POTENTIAL UX CHALLENGES RELATED TO MATTERHORN UX relies on techniques like "contextual inquiry" to observe users in their native habitat (the margaret meads of technology). On a highly distributed project like Matterhorn, this useful technique is challenging if not impossible due to logistics. This may apply to general challenges as well, but it is really difficult to determine how much "user research" is needed to kick start a project. The UX team at least needs to come up to speed about the domain and the existing requirements in order to make that determination (or live with the gaps). GENERAL OBSERVATIONS ABOUT AGILE A company like Yahoo practices Scrum because their development skills, roles, and technologies are well understood. They understand what is/is not possible from a deep well of experience using the same methodology, technologies, and people (to a degree). Maybe I am giving them too much credit? I see agile really taking hold in contexts where the technologies are well understood and the teams members are in close proximity. I personally have never been part of a development project that fully embraces a specific agile methodology. My main concern is the magnitude and highly distributed nature of the Matterhorn project. When I received "scrum certification" my scrum trainer, a grizzled agile veteran, said that a company should take on a few small projects to get their feet wet. And most likely they will fail ( a good thing in the short term --lessons learned). And that the scrum master, and tech leads, should let it fail. When I asked for advice how scrum may apply for managing multiple teams distributed around the world, the scent of gloss filled the air and he basically shrugged his shoulders. Going pure "agile", whatever that may mean seems like something we can't risk in our circumstance. I think there is a large misconception by agile advocates that up front analysis is not needed in an agile development process. We'll get better results from user input by releasing early and often rather than waste a bunch of research on something that we won't get right. Scrum, for example, squarely focuses on the management of the development cycle, and lacks any detail in terms of the others phases critical to a project like inception and closure of a project. I think that UX fills the gap for both inception and closure. Another key element for Scrum is the idea of a product manager playing the role of dictator. They essentially represent all stakeholders and their word goes. A "product manager" is difficult to attain when 11+ universities are involved. And it kinda goes counter to the Apache model. Another consideration is the technologies used. A colleague of mine once remarked that using Java in a purely agile project is like asking an elephant to do the two step. Although he said this somewhat in jest, some technologies certainly get in the way of churning out demonstrable functionality in short, iterative chunks. For example, Berkeley's Webcast Next Generation application needed a lot of up front plumbing and it took us a long time to get functionality in front of stakeholders. I always find this a challenge, and hope that we can avoid this problem with Matterhorn. SUGGESTIONS 1. Accept that unless you're superhuman, whether it be agile, ux, or karate, you're not going to get it perfect. 2. Adopt an "agile lite" methodology that accounts for the entire project life cycle (still relies on up front analysis). This methodology relies on upfront analysis, but also acknowledges that requirements evolve on an iterative basis. 3. Consider Scrum for the discrete iterative cycles if someone can play the role of product manager. 4. Embrace "Iteration 0" (team building, scoping, requirements analysis, setup environment), before going agile. 5. Not everything flows from user requirements. Although our users are a major factor, the infrastructure and business has its own requirements unrelated to the user. 6. We need testable, demonstrable functionality as early as possible. 7. Adopt some structure for decision making (see my leadership proposal post). 8. There needs to be some shared methodology for this project. Whether it be light weight or heavy duty, we need to agree on common terminology, communication, and management of the projects. HELPFUL LINKS Help conceptualize UX planning in an Agile environment. There are also links on the bottom of this page about Agile and UCD. http://wiki.fluidproject.org/display/fluid/Agile+Planning+-+Goals%2C+ben... http://www.alistapart.com/articles/gettingrealaboutagiledesign/ Autodesk Information on Iteration 0 http://wiki.fluidproject.org/download/attachments/1704207/Autodesk_WUD20...) General information regarding opencast discussion and agile approaches. Feel free to tag others with opencast and agile. http://delicious.com/tag/opencast+agile QUESTIONS What is the difference between UX/BA roles and deliverables? What do we mean by ba? A business process analyst, systems analyst, or plain ol' analyst. What are the differences? Can an iterative process be applied to SOA or is it absolutely to get the modeling "perfect" up front? How do UX and SOA intersect? Who are our users and how can we ensure that our iterative releases work for them? Contributor Guide High Level Iteration Process Navigation The following diagram provides a basic understanding of a typical Matterhorn monthly iteration. The diagram is broken down by weekly stages that include critical/optional meetings and their purpose . The optional meetings reflect key activities that will likely happen asynchronously. Click on image to see larger diagram. Process Diagram Internal server error Roles and Expectations Navigation The root page Contributer Guide could not be found in space OLD Matterhorn Project **DON'T USE**. 1 Team Meeting Expectations 2 Team Member Expectations 3 Project Wide Members Expectations 4 Team Roles 4.1 Project Wide 4.2 Engage Team 4.3 Admin Tools and Capture/Sched Team 4.4 Distribution 4.5 Media Pipeline This page illustrate the potential roles/responsibilities one may have within the Matterhorn community, and should help contributers define where they may fit in the ongoing effort. The Matterhorn development effort is currently broken up into "teams" who meet on an ongoing basis. You'll find a list below of As a contributer, if you're interested in taking on work, it is best to contact the component lead specified in Jira. Team Meeting Expectations Only one monthly meeting, the Team Work Breakdown Meeting (during the first week of an iteration), is critical for all team members . That being said each team can decide to call additional meetings, expected or otherwise, outside of the meetings identified in the process diagram. Each team must appoint a representative to attend weekly Scrum of Scrums. This individual must be able to communicate the team's progress, roadblocks, dependencies, etc. and work through any given technical or strategic issues with other teams. A team may consider both a product owner and dev lead to share this role to ensure a broad perspective. It is recommended that all contributors to Matterhorn attend the Scrum of Scrums as "listeners", but this is not mandatory. Team Member Expectations Each team member is expected to: estimate all tasks assigned to him/her before starting work on a given iteration. Tasks should be estimated in hours. expected to participate in QA at the end of each month either as a tester or fixer of bugs. log hours worked while working on a task. be available for expected meetings. enter availability in team calendar. follow agreed upon project practices. Team development leads are expected to: lead their team's Work Breakdown meeting. assign story points to any story card associated with their team. Story cards assigned to a given iteration backlog must have story points. assign tasks to their fellow team developers. This process can be more organic but all tasks must be assigned and estimated. ensure that best practices and technologies identified by yourself and/or project architects are followed provide mentorship to other developers prioritize open questions Team developers (including leads) are expected to: work with their team's product owners to clarify the scope and details of a given requirement. inform product owners (or UX) of any open questions or requirement research needed for upcoming iterations. understand the general and team practices and technologies. Product owners are expected to: prioritize team's product backlog on an ongoing basis identify new requirements (story cards) establish iteration product backlog clarify story cards for current iteration. define iteration goals/deliverables help in release planning User experience experts are expected to (outside of product owner responsibilites): support developers by clarifying story cards or providing the necessary research to clarify requirements. design user interfaces. provide user testing as well as perform other forms of usability evaluation. Business analysts are expected to: support architects and developers by providing the necessary research to define services. identify community priorities Project Wide Members Expectations Matterhorn's product wide roles such as project manager, architects. product manager, QA/Release manager, and communication director will provide support across teams. BA/UX roles may also play a cross team resource when necessary/possible. Project manager is expected to: support all areas of the project where necessary facilitate road map, release schedules, and requirments definition track progress and share ensure that project stays on track and participants have clear objectives Architects are expected to: define development practices propose technologies and implementation approaches provide mentorship to other developers explore emerging technological directions for Matterhorn ensure that technological open questions are resolved in a timely manner Product manager is expected to: promote and provide materials to promote Matterhorn support UX/BA team identify future directions Communication director are expected to: support Matterhorn's communication channels formulate best practices for communication provide materials to promote Matterhorn engage with community to ensure involvement outside Matterhorn funded partners QA/Release manager is expected to: gather necessary requirements/documentation for deployment document configuration needs. ensure that installation can be completed by a moderately technical sys admin. ensure that there are no licensing conflicts for contributed software (also job of committers) assist Matterhorn Project Manager in release planning coordinate iteration QA effort (recruit testers, organize effort) identify necessary tests and facilitate information needed to successfully complete them (performance, unit, acceptance) Team Roles Each team will have one or more of the following: development lead, developer, ux expert (only front end facing teams), and product owner. The responsiblities/expectations for each of these roles may found in the "team activity expectations" section above. Project Wide Product Owners Adam Hochman Olaf Schulte Architects Tobias Wunden Josh Holtzman UX/BA Judy Stern Allison Bloodworth Olaf Schulte QA/Release Planning Nils Birnbaum Project Infrastructure Sys Admin Tony Stevenson UI Dev Lead Markus Ketterl Outreach and Communication Michelle Ziegmann Olaf Schulte Engage Team Product Owners Alicia Valls Saez Clemens Gruber (Engage PM) and/or Markus Ketterl Markus Ketterl (optional) Dev Lead Markus Ketterl UX Alicia Valls Saez Developers Rolf Rudiger Benjamin Wulff Heidi Hazelton Johannes Emden Admin Tools and Capture/Sched Team Product Owners Allison Bloodworth Judy Stern Chris Brooks (optional) Dev Lead Chris Brooks UX Allison Bloodworth Judy Stern Developers Micah Sutton Greg Logan Kristofor Amundson Ruben Gonzalez Gonzalez Distribution Product Owners Martin Wagner Dev Lead Manjit Trehan Developers Peter Kese Media Pipeline Product Owners Josh Holtzman and/or Tobias Wunden (TBD) Business Analysts Allison Bloodworth Judy Stern Jamie Hodge Developers Aaron Zeckoski Jamie Hodge Project Tool Tips Navigation The root page Contributer Guide could not be found in space OLD Matterhorn Project **DON'T USE**. Making Decisions Navigation The root page Contributer Guide could not be found in space OLD Matterhorn Project **DON'T USE**. Decisions must be made on list. That being said, in order to ensure that open questions are answered, we need to have a clear process for prioritizing open questions and recording decisions made as we boldly move ahead with Matterhorn. It is crucial that we track our decisions as a historical record to inform the community and ourselves. Open questions should be managed in Jira to facilitate decision making. Anyone can enter open questions into Jira. If an open question is resolved on list, someone who is able to articulate the decision in a Jira comment should close the issue. At least initially, resolution should be a fairly organic process. Anyone can change the status of an open question in Jira. Open question statuses will influence priorities during iteration planning and our a way to call attention to a given topic. Blocker status: needs to be answered right away because it is blocking work. Critical status: must be resolved during the next iteration. Directions on how to enter an open question: Creating an open question is similar to creating a story card in Jira. 1. Click on new card and choose issue type "Story Card". 2. Once you've entered an open question, associate it with all other open questions by choosing the #openquestion component. You may also choose multiple components if the open question relates to a specific team or technological component. 3. You can view #openquestions associated with a specific iteration (or unscheduled) using greenhopper navigation. Choose the #openquestion context and version. See Project Tool Tips for a more detailed explanation of navigating in Jira. Directions on how to make decisions: If an open question has a blocker status, anyone should pose the question on list immediately (add blocker to the subject). Critical open questions should be brought on list during their associated iteration, and will be associated with an upcoming iteration by the product owners. Once a decision has been resolved on list, it should be closed in Jira like any other issue. Communication Practices Navigation The root page Contributer Guide could not be found in space OLD Matterhorn Project **DON'T USE**. This is a list of all the basic communication practices for internal/external team communication. All decisions must happen on list. (see Making Decisions) All Internal/External team communications happen on list or project irc channel (#opencast). Comments are not allowed in Confluence, and Jira comments should only be related to minor questions regarding the task at hand. Each Matterhorn contributer must provide a daily update via twitter (tag tweets with #ocdaily). All "F2F" meetings will be recorded and notes will be shared out to the community via the opencastproject.org calendar. Each Matterhorn contributer must put their availability in the Matterhorn Team Calendar (http://www.opencastproject.org/calendar_matter horn) As noted on the iteration diagram, the Scrum of Scrums will ensure cross communication between teams, and the Product Owner meetings will ensure cross-team consensus regarding iteration/release planning. More details about Matterhorn's communication channels may be found here. Development Practices Contributer's Guide Navigation The root page Contributer Guide could not be found in space OLD Matterhorn Project **DON'T USE**. This section contains how tos to help developer's ramp up on Matterhorn development practices, and covers topics such as checking out code, building from source, and annotating code with license info. Coding Practices Content by label There is no content with the specified labels Service Design Content by label There is no content with the specified labels Licensing Signing an Opencast CLA and CCLA (OLD Matterhorn Project **DON'T USE**) license howto guide Release Process Content by label There is no content with the specified labels Jira Content by label There is no content with the specified labels Confluence Content by label There is no content with the specified labels Agile Practices Content by label There is no content with the specified labels Signing an Opencast CLA and CCLA The Opencast community asks each Matterhorn contributor to sign a Contributor License Agreement, which provides a clear agreement to share code under terms amenable to Opencast's licensing strategy. In order to legally publish source code in the Opencast Matterhorn repository, the University of California Berkeley needs permission from the creators of the code and from the organizations for which they work. The following agreements are provided for this purpose: The Individual Contributor License Agreement (CLA) - to be signed The Corporate Contributor License Agreement (CCLA) - to be signed by an appropriate person in the organization. The person who signs your CCLA needs to have the authority to bind your institution to a contract, or the CCLA is invalid. This ensures that the primary investigator, UC Berkeley, is not at risk of liability if your institution/organization recants and asserts rights over the code it contributes. Signed agreements should be faxed to Michelle Ziegmann at 510-643-9221. Because code cannot be submitted without a signed agreement, please sign these agreements at the earliest possible opportunity. If your institution has any questions, email [email protected] and I will do my best to answer their questions or put them in contact with someone that can. File Modified OpencastCCLA-v1.pdf Jul 01, 2009 by A OpencastCLA-v1.pdf Jul 01, 2009 by A Drag and drop to upload or browse for files Download All Glossary Design & Development Processes Activity diagram Acceptance testing - in agile, the product owner (usually) performs tests whether or not the user story has been fulfilled. The acceptance test is usually written on the Storycard. (See Acceptance Tests) Agile design & development - Product development methodology emphasizing: People over tools and process Continuous integration Short cycles Simplicity - maximizing the amount of work not done Just in time requirements Time-boxed - must decide whether to reduce time or scope Annotations [preliminary definition] are an action of the user engaging with the video; they are part of the user activity we would like to stimulate with Matterhorn. This engagement in turn enriches the video for future users. The action can take various forms: Make a comment, annotate the video Give simple feedback (love/hate or +/-) Attach documents Bookmark [preliminary definition]: A technology and/or activity to mark a video object for future use. Bookmarking can take various forms: Bookmark one exact point in the video (for pin-point access) Highlight a part of the video (e.g. from 00:00:13 to 00:01:28) Favorite marks the video as a whole and adds in to a "my videos" collection Burn-down chart - agile method for calculating the amount of work remaining in a sprint or release. Business analysis Customer- in agile, this is the product owner, the persons or teams we build MH for. Prioritizes the product backlog. Entity - a unit, instance, actor in a system; technically, this might be a node or a module (in MH, "archive", "encoder" or "administrator" would be entities) Interaction design Information architecture (Matterhorn) Media Portal (MMP), sometimes referred to as "MMM" or "the thing" is the primary distribution channel for MH as it will feature and showcase the functionalities MH has that make this distribution a real engage end for students (search, annotate, bookmark etc.). Mockup: a design that shows what the page or application will look like; incorporates look-and-feel (e.g. has had visual design applied to it, is not just a wireframe). (Note: in Matterhorn, largely because we use the tool called "Balsamiq Mockups" we often use the term "mockup" to refer to things that are really just wireframes.) Orgsonas - archetype customers, based upon the concept of >Personas. These combine institutions we see as adopters with people working there. Based upon interviews with these, we created twoMatterhorn Orgsona. Personas - archetype user, customer; the modeled representation of the person MH is designed for, with her needs, problems, wishes, restraints. Principal Investigator (PI) is the person responsible for the Matterhorn project at the local institution. Product backlog - agile method for organizing work to be done for a release (a list of features). It can also be organized into a Release backlog, which is the work to be done in a release. Includes user stories and non-functional requirements. Product owner - cf. "Customer" Scenarios - stories about users getting work done in context. (may be a concrete example of one use case but more likely are a string of use cases the user needs to complete an activity.) Tobiosh - The MH architects, i.e. Tobias and Josh. Use case - high level functional requirement*.* An action and a noun (at minimum) that describe what the user needs to get done in the system. (Note: we are not talking about fully fleshed out use cases here, but rather, what one might consider a "use case title") User-centered design -- a philosophy (and loose set of methodologies) that puts users at the center of the design process, ensuring that their needs are met. User experience - User Experience Design takes into consideration users and their goals to ensure that the entire experience associated with the product is a 22positive one and that the design of the product addresses the needs of diverse users. User interface (UI) - the means by which people interact with a system. A user interface is not always a graphical user interface (GUI) or a web interface. In Matterhorn, there are various UI for administrative tasks, some for end users (e.g. for an uploader or ingest service); the UI for the Matterhorn Media Portal (which is the interface for end users, students, other people enjoying the videos) should be referred to as the "Engage UI" to differentiate from the more administrative UI. User story - a way of capturing user requirements. Used for agile planning. It's not a complete description of the required functionality, but a "promise of a conversation." Visual design - the use of colors, fonts, patterns, images, and visual elements in design Wireframe - a mockup of a page that only addresses the layout, not aesthetics. Products & Technologies Camtasia Studio is a screen video capture program for Microsoft Windows, now also available for other OS... It is published by TechSmi th. The user defines the area of the screen or the window that is to be captured before recording begins; it is also possible to capture the entire screen area. DirectShow (sometimes abbreviated as DS or DShow), codename Quartz, is a multimedia frameworkand API produced by Microsoft for software developers to perform various operations with media files or streams. Echo360is a commercial lecture capturing and distribution solution, newly branded after Apreso (Anystream) bought Lectopia. Epiphan USB2VGA card - *(http://www.epiphan.com/products/frame-grabbers/)* FFmpeg is a computer program that can record, convert and stream digital audio and video in numerous formats. FFmpeg is a command line tool that is composed of a collection of free software / open source libraries. Flash Video is a file format used to deliver video over the Internet using Adobe Flash Player (initially produced byMacromedia) versions 6-10. Until version 9 update 2 of the Flash Player, Flash Video referred to a proprietary file format, having the extension FLV. The most recent public release of Flash Player supports H.264 video and HE-AAC audio. Flash Video content may also be embedded within SWF f iles. Notable users of the Flash Video format include YouTube,Google Video, Yahoo! Video, Reuters.com, metacafe, and many other news providers. GOCR (or JOCR) is a free optical character recognition program, initially written by Jörg Schulenburg. It can be used to convert or scan image files (portable pixmap or PCX) into text files. Gstreamer is a pipeline based multimedia framework written in the C programming language with the type system based on GObject. GStreamer allows a programmer to create a variety of media-handling components, including simple audio playback, audio and video playback, recording,streaming, and editing. The pipeline design serves as a base to create many types of multimedia applications such as video editors, streaming media broadcasters, and media players. H.264 is a standard for video compression, and is equivalent to MPEG-4 Part 10, or MPEG-4 AVC (for Advanced Video Coding). As of 2008, it is the latest block-oriented motion-compensation-based codec standard developed by the ITU-T Video Coding Experts Group (V CEG) together with the ISO/IEC Moving Picture Experts Group (MPEG), and it was the product of a partnership effort known as the Joint Video Team (JVT). Hauppauge consumer NTSC/PAL WinTV card - (http://www.hauppauge.com/html/wintvpvr350_datasheet.htm). MediaSite is a commercial lecture capture and distribution software, popular in the Netherlands and the UK. Microsoft Media Server (MMS) is the name of Microsoft's proprietary network streaming protocol used to transfer unicast data in Windo ws Media Services (previously called NetShow Services). MMS can be transported viaUDP or TCP. The MMS default port is UDP/TCP 1755. Ncast.com OCRopus is a free document analysis and OCR system released under the Apache License, Version 2.0 with a very modular design through the use of plugins. These plugins allow OCRopus to swap out components easily. OCRopus is developed for Linux; however, users have reported success with OCRopus on Mac OS X. OSGI - The OSGi Alliance (formerly known as the Open Services Gateway initiative, now an obsolete name) is an open standards organization founded in March 1999. The Alliance and its members have specified a Java-based service platform that can be remotely managed. The core part of the specifications is a framework that defines an application life cycle management model, a service registry, an Execution environment and Modules. Based on this framework, a large number of OSGi Layers, APIs, and Services have been define Panopto is a commercial lecture capture and distribution software, originally developed at Carnegie Mellon. Podcast Producer PuMuKIT Real Time Messaging Protocol (RTMP) is a proprietary protocol developed by Adobe Systems for streaming audio, video and data over the Internet, between a Flash player and a server. REPLAY is an Open Source video management system developed at ETH Zurich. SMIL (pronounced /smal/ "smile"), the Synchronized Multimedia Integration Language, is a W3C recommendedXML markup language for describing multimedia presentations. It defines markup for timing, layout, animations, visual transitions, and media embedding, among other things. SMIL allows the presentation of media items such as text, images, video, and audio, as well as links to other SMIL presentations, and files from multiple web servers. SMIL markup is written in XML, and has similarities to HTML. Tegrity is a commercial lecture capture and distribution software with a live streaming component (I think... OAS) Telestream's Episode Engine - "Episode Engine is the smart choice for high-volume, time-critical broadcast, post-production and new media workflows. Professionals worldwide rely on Episode Engine's broad format support, server-based encoding automation and scalability to deliver unprecedented speed, performance and value." (from: http://www.telestream.net/episode-engine/overview.htm) Tesseract is a free optical character recognition engine. It was originally developed as proprietary software at Hewlett-Packard between 1985 until 1995. After ten years without any development taking place, Hewlett Packard and UNLV released it as open source in 2005. Tesseract is currently developed by Google and released under the Apache License, Version 2.0. Tesseract is considered one of the most accurate free software OCR engines currently available. virtPresenter is an Open Source lecture capture software developed at the University of Osnbrueck, Germany. VLC Media Player is an open source, free software media player written by the VideoLAN project. Definition of engage activities and functionalities Annotations are an action of the user engaging with the video; they are part of the user activity we would like to stimulate with Matterhorn. This engagement in turn enriches the video for future users. The action can take various forms: Make a comment, annotate the video Give simple feedback (love/hate or +/-) Attach documents Bookmark: A technology and/or activity to mark a video object for future use. Bookmarking can take various forms: Bookmark one exact point in the video (for pin-point access) Highlight a part of the video (e.g. from 00:00:13 to 00:01:28) Favorite marks the video as a whole and adds in to a "my videos" collection Tag: "A non-hierarchical keyword or term assigned to a piece of information (such as an internet bookmark, digital image, or computer file). This kind of metadata helps describe an item and allows it to be found again by browsing or searching. Tags are chosen informally and personally by the item's creator or by its viewer, depending on the system." Source: wikipedia. Tags can relate to videos, parts of a video and point in a video; also, they can relate to bookmarks and annotations, in that users can thus categorize these: Bookmarks could be tagged "open issues", "exam" or according to different sub-topics within a video; annotations could be tagged "questions", "comment" etc. Annotation Bookmark Tagging Who? Users Users Users, services For whom? User & other users User & other users User & other users Modality Symbolic, text, files (PDF, audio, video), URL Symbolic Symbolic, text, statistical Examples Comments, ratings Favorite videos for exam preparation Categorize parts of video for analytic purposes Sharable? Yes Yes Yes Private? Yes Yes Yes Open Questions Adding Demo Data To Your Instance (Release 0.5) usage: demoloader [url] -h,--help display this help screen -n,--number "number "random": loads the packages in random order. Example: cd opencast-demo/target java -jar opencast-demo-0.1-SNAPSHOT-jar-with-dependencies.jar -n10 http://localhost:8080 This will load 10 random samples into the matterhorn installation running at localhost:8080. Matterhorn Basecamps Basecamps provide a foundation for inexpensive testing opportunities and regional or nationalcommunity support. Thus far two base camps will be established from funded Matterorn project partners, one on each side of the Atlantic, as well as two other base camps supported by enthusiasts from the Opencast Community. This number may increase before the release of 0.5 and will likely grow as we approach 1.0. UK Base Camp, Steeple Projects The Steeple-BR Project is an Opencast affiliated UK based JISC funded project (running until 31st August 2010), a core aspiration of which is to conserve resources by not duplicating effort. Currently, each institution is pursuing their own technical developments, often at significant cost in both technical and financial resources. The Steeple and Steeple-BR projects seek to build a UK community to share tools, and to develop these jointly where they are needed. The hosting of an Opencast Matterhorn base camp by the Steeple-BR Project community fulfills part of this aim. More information about the Steeple projects may be found on the project wiki at: http://www.steeple.org.uk and the project blog at: http://steeple.p osterous.com. For updates, join the project mailing list at:https://www.jiscmail.ac.uk/STEEPLE Loughborough University will host the UK Opencast Matterhorn base camp, providing a number of virtual machines for demonstration purposes, as well as an opportunity for other UK institutions to try out the reference capture hardware which will be available for free loan to participating institutions. Lecture capture is now accepted as a part of the E-Learning toolset available to staff and students at Loughborough University. Loughborough are currently undertaking a small scale pilot of the Echo360 lecture capture system, which has already proved very popular with the staff and students who have used it. After a deliberately slow start, there is now growing interest in lecture capture. Hosting the UK Opencast Matterhorn base camp is an ideal opportunity to compare and contrast these two systems. Loughborough also hopes to be able to pilot another installation of Opencast Matterhorn for its own staff and students. Spain Base Camp, University of Vigo The University of Vigo is hosting an Opencast-Matterhorn demonstration base camp. "Ready to try" hosted installations of Matterhorn Core and Matterhorn Capture devices will be available online from 0.5 to 1.0 releases. This base camp will try to be the reference base camp for Spanish speaking Matterhorn community but, of course, any international Institution (or individual) will be welcome to try the "Matterhorn experience" with us. Transition from "hosted experience" to "on campus installation" will be also supported. University of Vigo network is part of RedIRIS the Spanish high bandwidth research network, so no bandwidth issues are expected. Contact and support will be available in English and Spanish. Our timezone is CET; contact Vicente Goyanes, [email protected]) Israel Base Camp, Tel Aviv University Our base camp will provide dedicated virtual machines and high bandwidth access connectivity to all near by institutions who would like to try and gain some experience using Matterhon 0.5 and later releases. Please contact Jack Barokasor visit the website. Canada Base Camp, Saskatchewan The University of Saskatchewan is hosting a Canada-wide base camp to demonstrate Matterhorn features from capture agent through processing to delivery for the 0.5 through to 1.0 releases. Dedicated virtual machines for processing and delivery are available upon request (contact Christopher Brooks, [email protected]), and open-web demo accounts will be made available. Hosted in a high bandwidth facility on the CANARIE research network, the University of Saskatchewan team will investigate the feasibility of running Matterhorn in a cloud service-based environment. USA Base Camp, University of Nebraska-Lincoln Our base camp will provide dedicated virtual machines and high bandwidth access connectivity to institutions who would like to try and gain some experience using Matterhon 0.5 to 1.0 releases. Help setting up your own vitual machine will also be supported. Our timezone is CST; contact Todd Jensen, [email protected]. Strategy 6 Month Priorities and Resource Allocation Adoption Strategy Considered Year 2 Requirements Considered Year 2 Requirements (decision table) Year 2 Requirements - top level decision making 6 Month Priorities and Resource Allocation Blocker Critical Major Minor Distributed Computing Josh/Tobias Multiple Workflows Tobias/Josh Media Analysis Annotations YouTube and Itunes Xin/Josh Recurring Event UI Micah/Benjamin In Video Search Accessibility in Admin UI Confidence Monitoring Kris/Greg/Chris Skinnable, Embeddable Player Johannes/Markus Timeline Segmentation (slide change) Recurring Event Data Model/Service Ruediger/Chris Media Player Caption Support Johannes/Markus/Stefan Localization Support Streaming Engine Ruediger Pipeline Caption Support Aaron Caption Hold State and Attachment Migrating to Jira Studio Tony/Josh/Tobias Review State (replace media/metadata pre-dist) Tobias Play Multiple Media Sources Synchronously QA Server Manjit/Tony ICAL Import Utility Ruediger Admin App Dashboard Automated Regression Tests Nils/Marcus Data Persistence Layer Tobias/Josh/Chris? Add attachments to Recording Automated VM Build Ruediger/Manjit Stablizing Nightly Manjit/Ruediger Deleting a Recording 2GB > Upload UI Benjamin Processing Hold on Recording Paging in Recordings UIs Recordings - All & Recordings - Editing/trimming Recording (up for discussion - AH thinks this needs be shifted Capturing pages to lower priority) Search/Filters in Recordings UIs User & Customer Research to inform year 2 What slipped? Aligning Engage with Search Service All and Capturing Recording Filters More Verbose Capturing Status Feedback Capture Install Script Capture Integration Tests w/ real device Shadow Tasks? Performance Testing Code Optimization Extensive Integration Tests Unit Test Coverage Iteration Planning Adoption Strategy TIMELINE January 31, 2010: Matterhorn "Preview" Release 0.5 February - April 2010: "Preview" Release Testing May 1, 2010: Matterhorn "Beta" Release May - June 2010: Matterhorn "Beta" Testing July 1, 2010: Mattherhorn Release 1.0 STATE OF AFFAIRS On March 24th, a general survey was sent out to the Opencast community list to identify institutions interested in adopting Matterhorn. Responses were positive ( http://wiki.opencastproject.org/confluence/x/NgBd1), and follow up individual emails in September (http://wiki.opencastproject.org/c onfluence/x/A4Ns) confirmed continued interest. In the next few weeks, a new survey will be sent to the list to determine in what form universities are interested in piloting Matterhorn "Preview" Release 0.5. Matterhorn partners will also be called upon to identify colleagues whose institutions are interested in adopting Matterhorn. The key goal from now through the end of January is to identify and classify testers/adopters and provide them with the necessary information and resources to successfully preview and later adopt Matterhorn. This paper is written with a perspective toward Matterhorn 1.0 in July 2010. For future funding considerations, it will be necessary to have interested parties sign a letter of intent at the earliest time possible. RELEASE AND TESTING OVERVIEW Matterhorn "Preview" Release 0.5 and Testing Summary The Matterhorn 0.5 release is an open invitation to the the community to explore Matterhorn and its role in their short and/or long term plans. Although 0.5 will be a "preview release" (unfinalized APIs/implementations and limited feature set) it should help institutions consider running a pilot for Fall 2010. Developers will be able to review Matterhorn's code, technical stack, and documentation to gauge whether it meets their standards. Administrators will be able to review the basic workflows to see the promise of things to come and get a sense of what Matterhorn can do today. Goals Identify adopters and classify adopter pools Establish a network of self supporting testers Community feedback for bugs, technical, and UI requirements Strengthen relationship with community towards Matterhorn 1.0 Foster commitments from commercial vendors and non-profits for early integration Next Steps Follow up 0.5 testing and adoption survey on the Opencast list to clearly identify and classify interested institutions Personal emails to institutions that have expressed interest to identify their position for 0.5. Create process and allocate resources for feedback and triage Identify and setup up "base camps" (see below) Determine "game plan" for commercial and/or non-profit integration pre-1.0. Specify and complete documentation (starting with FAQ) and marketing materials Redesign installation home page Create adoption tracks Create release candidates for distributions. Create downloads environment on the wiki and/or opencastproject.org. Create separate email list for support. Specify deadlines for all the above steps! Target User Groups 1. Customers: (traditionally purchasers - those that look at the shiny box and have the purse strings) need to understand the limits of 0.5 and how these limits will be addressed in future quarters. We need to set reasonable expectations by providing a coherent 0.5 feature set as well happy path scenarios to demo and/or run a pilot for one course. 2. Configurers: (traditionally system administrators) need to be able to easily install the system without understanding the intimate details of Matterhorn. We need to offer them an easy package for installation as well as adequate documentation to properly configure the system. 3. Developers: need an easy way to easily build the system locally so that they can demo and play with the various UIs and services. We need to provide them with adequate javadocs, high level service contract documentations, and installation/configuration documentation. 4. Administrators (user facing application users) : (see persona Mary) need to be able to successfully pilot the scheduling, capture, and delivery of a class. They need basic user documentation and user interface functionality to schedule a course, ingest a file, and ensure that the file has been distributed. Software Distributions VMware Image A VMware image using ubuntu will be available with the system pre-installed and configured. Install scripts for GPL licensed components will be part of the VM startup procedure to avoid any legal issues. This distribution will run on any Linux and Windows platforms using free software called VMware player. Apparently VMfusion for OSX will also play vm images, but this software is not free. This software is relevant to the "novice" and "intermediate" climber (see classifications below), and it should be an easy installation for configurers or general users with moderate technical skill. If someone wants to get Matterhorn up and running fast, this is the distribution for them. Build and Install A source archive of 0.5 will be available for download. Configurers and developers will be able to follow instructions in the wiki to build and install this distribution locally. This software is relevant to the "intermediate" to "advanced" climber and users will need some knowledge of mvn, svn, and possibly java. Online Demo Environment An online demo for 0.5, so that "novice climbers", "customers", and "administrators" can take a "cheap" look at Matterhorn's features. Capture Device An installation script for 0.5 will be available for download. Configurers and developers will be able to follow instructions in the wiki to build and install this distribution locally. This software is relevant to the "intermediate" to "advanced" climber and users will need some knowledge of mvn, svn, and possibly java. This installation script will only work for Matterhorn specified capture devices. Matterhorn Release 1.0, Testing, and Deployment To Be Determined. OPEN QUESTIONS/RECOMMENDATIONS How many institutions should partake in testing 0.5 and piloting 1.0? What resources are needed from our end to do this adequately? Recommendation: As many organiations as possible should be involved in the testing and piloting of Matterhorn. There should be support for novice and intermediate levels for 0.5 testing. In terms of resources, we need front line help for installation and build issues as well as feature questions. Its unclear whether a separate support list is needed or specific resources can be counted on to reply to questions on the main list. If the front line team cannot adequately answer these questions, they will triage them to second tier and so on. Details on this process will be proposed shortly. Are there key institutions / specific kinds of institutions / countries we should consider? Recommendation: The institutions that show real interest (vision, resources, pilot plans) should be the highest priorities. Strategic hubs, such as Steeple and NITLE, that may impact wide spread adoption should be supported. Should we strictly focus on institutions with simple to no existing systems (i.e. "The Cobbler") to get better responses? Is "The Sophisticate" orgsona relevant for 0.5? Recommendation: The Sophisticate is only relevant for 0.5 in the respect that they may want to better understand the SOA nature of Matterhorn and how it may impact their existing systems. We should not oversell our product to the Sophisticate though. Can we pull resources from further development to support testers/adopters against further development? Recommendation: Yes. Namrate and Manjit could be first line development resources to answer build and install question, and the second tier could initially be comprised of Jamie, Michelle, and a BAUX resource. The third tier will be comprised of a committers for the specific component at question. The fourth tier will be Josh and Tobias. Manjit will be the cornerstone for this plan to be solvent, but there is some risk in that he will need to significantly ramp up his knowledge of the system to be a viable "firewall". Since Namrata has java experience, she can also play an important support role for Manjit, but she is new to the project and needs to significantly ramp up. Are we supporting 32 bit and 64 bit in 0.5 for the VMware version? Recommendation: It's not clear whether it is costly to support both, but since performance is not of key importance in 0.5, so the 32 bit is of greater importance since this architecture seems more prevelant. In the long run, a 64 bit architecture will provide significant gains in performance. How well does our vm ware version perform workflows? Recommendations: We need to test this and make sure processing is not super slow. Are we including Capscribe in the VMware version? Recommendation: By including Capscribe in the VMware image, it could be perceived as an OOTB feature. It also means more overhead in the respect that testing, release management, and look and feel need to be better aligned for 0.5. I think there should be steps to include Capscribe. Perhaps everything is already there, but the user needs to do something insignificant like run a start script. OUTREACH Adoption and Tester Classifications The following classifications are volunteer based and will not be dependant on funding. Base Camp An institution/organization that helps other institutions run and support Matterhorn. This may mean hosting capture agents for remote testing, hosting Matterhorn instances for other institutions to demo or test, installation support for system admins, or build support for developers. This name also signifies organizations that strongly advocate Matterhorn, offer commercial services around Matterhorn, or generally help bring other institutions/organization/individuals on board. (see Candidate Base Camps) Novice Climber An individual or institution that casually checks out Matterhorn to better understand its features or technologies. They compare its features with other commercial products and do some form of competetive analysis. Some demo an existing online version or run it OOTB. A developer may read the documentation and install it on their laptop to poke around. In terms of the "community", they generally lurk on lists and occasionally respond to threads. For 0.5, this group is mainly interested in learning more about Matterhorn by reading high level documentation and looking at a current online demo. They're not interested in spending resources on Matterhorn, and are just in a preliminary exploration stage. For 1.0, they may run a small (one class) pilot at their campus or dedicate more resources to determine total cost of adoption. Intermediate Climber An institution/organization that has designated limited resources to install, test, and pilot Matterhorn. These individuals or institutions have a strong desire to participate in Matterhorn and will likely post questions to the list when they're in need of an answer. They will depend on documentation when troubleshooting, and they're fairly self sufficient. This group may already have a basic existing system and/or an established podcast program. The intermediate climber most aligns with the Cobbler orgsona. For 0.5, this group is interested in testing Matterhorn locally or using a "basecamp" to run a small testing environment. They will enter feature requests in Jira through Community Feature Requests and bugs if they find any problems. For 1.0, they'll run Matterhorn OOTB for a pilot involving a few classrooms in the Fall. They anticipate Matterhorn will be a long term solution. If they're migrating from an existing system, their migration path should be simpler due to the lack of infrastructure and simplicity of their existing system. They may make minor modifications to Matterhorn through configurations or modifications to the UI. Advanced Climber An institution/organization/individual that is heavily involved in the day to day activities of the community. They follow and respond to the list frequently, and they log into irc and engage in "low level" activities. They're willing to get their hands dirty to make things work, and will submit patches to Matterhorn for their local needs. They may contribute to documentation or initiate conversations on list. They're comfortable within Matterhorn's wiki, issue, repository, and integration environments. They have their finger on the pulse of Matterhorn and they see themselves as a contributing to its health. This group may already have an advanced system and/or the capacity to do a big rollout. The advanced climber most aligns with the Sophisticate orgsona. For 0.5, this group will provide substantial testing and may push Matterhorn beyond its capabilities. They will explore it in as detailed a manner as possible to understand integration costs and the total cost of adoption. For 1.0. this group will integrate Matterhorn with their campus systems, and run a pilot in a few classrooms. This group may alternatively adopt specific services from Matterhorn and integrate them into their existing system. They may not migrate to Matterhorn until there is more parity with their existing system. Master Climber This group contributes significant resources to the Matterhorn effort, and are likely committers and/or thought leaders on the project. They are heavily invested in the long term success of Matterhorn. IDEAS TO BE CONSIDERED Chris suggests "a "Local Champions" program, where for each person who is publically trying opencast (e.g. they have talked to us about it), we assign to them a local person to help answer questions." Bjoern and Sally seem keen to become a "gold pilot" for the UK 3.5. Starting the pilot: it is essential to be on time with 0.5 (including documentation!)-- and to be prepared for people using it. Tracking downloads & pilots Potential Basecamps: Steeple, Saskatchewan, —Vigo, —Nebraska, —Osnabruck 0.7 in May?? Base Camp Candidates This is a draft version and the information may not be up to date; please consult with the official description of the Matterhorn Basecamps. Institution 0.5 Infrastructure Support Candidates Contacts Mail Support Steeple Project yes Two Centos 5 VMs / physical servers "JISC-funded UK-based Steeple project, a Carl, Sally, [email protected]; Demo agent from Saskatchewan? collaborative project between Oxford, Cambridge and Bjoern, and [email protected]; the Open University, and 15+ UK HE's as community David [email protected] partners." University of Vigo Up to 4 MH Cores on 4 Debian VM on a XEN server. One physical ¿? Vicente [email protected] capture agent ( we will try two). Up to 4 virtual capture agents Goyanes Nebraska Saskatchewan yes Up to 4 Ubuntu 9.10 VM's on a shared server. One Open for discussion Chris [email protected] nightly/developer matterhorn capture agent, one 0.5 matterhorn Brooks capture agent, perhaps one 0.5 matterhorn capture agent reserved for project use. Osnabrueck yes Up to 2 Ubuntu 9.10 VM's. One physical capture agent. University Vechta Rüdiger [email protected] Rolf Tel Aviv Will be updated soon Jack [email protected] University Barokas University of yes Specs to come soon, hosted VM 0.5-1.0 server, potential capture Todd [email protected] Nebraska-Lincoln client Jensen [email protected] Bruce Sandhorst Release 0.5 Board Meeting Update Admin App Features Media Capture Scheduling Manual scheduling of individual recordings for automated capture (See Schedule Recording 0.5) Capture Agent Monitoring Capture status monitoring to track the success or failure of each scheduled capture, as well as the availability of each capture media input. This will only work with Matterhorn's capture appliance reference out of the box. (see Capture Agents 0.5) Recording Management Metadata entry and editing for individual recordings (see View Recording Info 0.5, Edit Recording 0.5) Workflow execution and monitoring for the lifecycle of the media. (see Recordings - Finished 0.5, Recordings - Processing 0.5, Recording s - Upcoming 0.5 Manual media upload (e.g. user-generated or production video) for processing and distribution (see Upload Recording 0.5) Capture Infrastructure Matterhorn capture prototypes based off a reference specification for a low cost, low power capture device that supports audio, video and VGA source for high quality encoding. Several prototypes will be available for testing purposes.( see Matterhorn Capture Hardware Specification) Support for automated capture based on schedule Multiple inputs for simultaneous/synchronous capture, e.g. a video of the lecturer plus the VGA signal from the lecturer's computer H264 and mpeg 2 capture Engage Features Keyword search and video results page Accessible media player accessible by keyboard and screen reader Support for captions Service Features 0.5 Ingest Service Ingest of complete media package from capture agent or other source Ingest of data and creates a media package. Supports 4GB or higher for media uploads. Composer Service Encoding h264 source to h264 deliverable in mp4 container. Workflow Service Configuration of workflows via xml "transcode and distribute workflow" that transcodes to h264 and distributes to the Matterhorn Media Module. Support for rest end points to provide data for recording UI Engage Search Service Supports search for the media/metadata pushed to the Matterhorn Media Module Local Distribution Service Supports distribution to local disk to be used by local hosting services (i.e. red5, apache -- not supported in 0.5) Scheduling Service Generation of ical schedules for capture agent consumption (does not support recurrence) Inclusion of recording metadata (dc data) as an attachment Caption Handling Service Retrieves media in need of captioning Adds captions to media package for further processing Risks Minimal QA: No test plans or organized testing from top to bottom No integration testing, minimal unit testing. Release process not fully exercised and no release candidates Lack of documentation for services and UIs No testing framework for rest end points Database calls need to be unified through one service No user testing Fit and finish for 0.5 in beginning stages December Legality around ffmpeg (GPL) Considered Year 2 Requirements Originally collected during the Zurich meeting by the group on Sept 25th. For decision-making, please go to the Google Docs version of this document. CAPTURE Must Have Desktop Capture : Instructor pauses, starts, and stops capture User Driven Appliance Capture : Instructor pauses, starts, and stops capture Authn/Authz support for Instructor intiatied capture. Multiple Appliance Support (with multiple devices attached) Auto deploy new versions (1 click update) Wide range hardware compatibility: Very simple cost software recorder Strongly Consider Live streaming Capture HD Video Proof of concept 3rd party commercial integration: Camtasia, Dim Dim, Ephiphan, Kaltura, commercial encoder Out of Scope Mobile capture device with UI Smart phone ingest ? (3rd world) TCO analysis and techniques: virtualization, cloud computing Many devices (3 VGA + 2 HD cams for example) GPS over IP Mobile device quick external capture 5 min extend timer mobile device Notification of capture agent/device failuer via SMS Encoding video conference and materials Let students tag/annotate lectures that a currently recorded Capture client software on Epiphan Email video to ingest into system Auto Camera Tracking: "Prof tracking" ?Motion talking? ADMIN Must Have Multiple admin roles and contexts: "trusted sources" and "distributed administrators" Instructor Role: limited set of admin func such as title edit, and perhaps approval to publish Editing Tool for removing and adding media. Preview Media workflow Workflow Configuration UI Dynamic UI based on workflow configuration Capture Parameters Config UI per appliance Branding UI Other Configuration UIs (e.g. for things configured in XML file) Redistribution of media/metadata/captions to distribution channels Strongly Consider Stats UI Comprehensive confidence monitoring Web Conferencing administration (e.g. manage i/o for processing/dist, conf. initiation, and capture of web conferencing system) Continual synchronization between Matterhorn and Enterprise registrar data. Scheduling resolution UI to deal with conflicts between Matterhorn and Enterprise registrar data. Capture Parameters Config UI per recording Audio level compression/limiting UI Out of Scope Mobile device admin app Automatic classification tools tell system which rooms are available at a particular time and capabilities of room Interface to LMS/Campus Management for data transfer in both directions HD Cropping UI (i.e. removal of unwanted parts of the frame) Process notification Automatic lecture titling based on syllabus in LMS Specify a date after which a recording will be unpublished Send (email, SMS) reminders to attendees required @ a meeting (e.g. camera operators) Delay publication of a recording until a specified date PROCESSING & SERVICES Must Have Federated search service across Matterhorn instances Composer support for open codecs and wrappers (e.g. Ogg Vorbis) Composer support for HD Support for media editing "Hold" workflow for multi user media review Configuration support for workflows Configuration support for composer Support for redistribution of media/metadata Archive workflow (e.g. Duraspace, JackRabbit?) Strongly Consider Media Analysis for blackboard and whiteboard Proof of Concept Auth implementation: CAS, OpenID, Shibboleth (e.g. distribution, administration) Proof of Concept Enterprise Integration: Kuali, PeopleSoft, LDAP, ? (e.g. distribution, administration) Proof of Concept LMS integration: Moodle, Sakai, Blackboard (e.g. distribution, administration) Support for audio level compression/limiting Open source speech to text transcription and training intergration: Sphinx, MIT? Proof of Concept commercial transciption/sync integration: Google, AST Statistics "homoginization" service Feedback Loop for Annotation Data. Scoped distribution based on Authn/Authz (e.g. share with class, share with individuals, share with public) Proof of concept commercial cloud service impls for encoding and storage Proof of concept Matterhorn cloud service models for cross institutional infrastructure. Out of Scope Authoritative annotation by instructors ?UI service (eg libraries)? Integration with library digitization efforts "On camp" for libraries perserving scholarly confereneces Tool to embed video in Google Apps Integration with university unified conta?? architecture Matterhorn Portal with recording from all Opencast universities Create new series based on existing recordings Distribtue to iPhone mobile devices Content federation Interplatform connection between two implementation of Matterhorn Mix "video" and "display" to generate another video for mobile devices - or do a composition Composer: mix multistream recordings to one stream videos (PiP, etc) - intelligently ENGAGE Must Have Proof of Concept Authn/Authz Support in existing portals: Drupal, WordPress, etc. Scoped annotations based on Authn/Authz (e.g. share with class, share with individuals, share with public) Open Social Support (i.e. gadgets) (e.g. Facebook proof of concept) Scoped search based on Authz/Authz Portlet Support Hotspots by most viewed Hotspots by most annotated Strongly Consider HD Video: Zoom in to parts of the screen (read the board) Keyword and concept cloud per video/course/class Mobile app (find, view, share) Template editor for engage tools Amazon recommends... (collbaorative filtering) Ability to email instructor with questions specific to points in time of lecture Out of Scope Create new video by combining segments (eg playlists for study sheet) Plays in the home (Wii, XBox360, etc) Share annotations Share playlists Connection to semantic web Attach files to class course or event (faculty or admin) Student talk-back (cam mess) ?? UI personalization End-user annotations Inter-course linking to related/supporting materials Collaborative transcript generation (in multiple languages) Community editing like comments, wiki-editing of captions Output for mobile devices Student oriented tools (slides + text) Speaker diarization HTML 5 player UI preference for language providing access to lectures by role, by id, by group COMMUNITY Must Have Metadata exchange (searchability across universities) Opencast content and video event (conference, festival, etc) More face to face Adoption support Best practices Call home for source Strongly Consider Pedagogical oriented best practice examples Out of Scope Central portal for all recordings made with all Matterhorn installations OTHER GUI made the apple way, not engineer way Functionality and low cost Statistical package for management information data Extensive interaction logging (research, Amazon) Mobile app (iPhone and blackberry & android) Authoring of classroom matierals (vieo + slides + links + formative testing + ) using video timeline Informal instructure collections of video materials Personal collections and group sharing Drop-box for mobile devices Pedagogical background + effect Mobile client support Considered Year 2 Requirements (decision table) This version is out-of-date, please go to Google Docs to find an editable version. Rating is from -2 to +2, prioritization can be changed to MH (Must have), SC (Strongly consider), O(O)S (Out of Scope) when different from current - please indicate in red. "?" is for not knowing what the description actually means. Capture Adam Chris Tobias Markus/Ruediger Olaf A. Josh Must Have Desktop Capture : Instructor pauses, starts, and stops capture 0 User Driven Appliance Capture : Instructor pauses, starts, and stops capture 0 Authn/Authz support for Instructor intiatied capture. ? Multiple Appliance Support (with multiple devices attached) -1 Auto deploy new versions (1 click update) ? Wide range hardware compatibility: Very simple cost software recorder -2 Strongly Consider Live streaming +1 Capture HD Video +1 Proof of concept 3rd party commercial integration: Camtasia, Dim Dim, Ephiphan, Kaltura, commercial encoder +1 Out of Scope Mobile capture device with UI SC (Cobbler!) Smart phone ingest ? (3rd world) -2 TCO analysis and techniques: virtualization, cloud computing -2 Many devices (3 VGA + 2 HD cams for example) -2 GPS over IP -2 Mobile device quick external capture -2 5 min extend timer mobile device -2 Notification of capture agent/device failuer via SMS -2 Encoding video conference and materials +1 Let students tag/annotate lectures that a currently recorded -2 Capture client software on Epiphan (SC if cooperation) Email video to ingest into system -2 Auto Camera Tracking: "Prof tracking" +2 (separate project?) ?Motion talking? ? Admin Must Have Multiple admin roles and contexts: "trusted sources" and "distributed administrators" 0 Instructor Role: limited set of admin func such as title edit, and perhaps approval to publish +2 Editing Tool for removing and adding media. +2 (is this the online editor?) Preview Media workflow 0 Workflow Configuration UI ? Dynamic UI based on workflow configuration ? Capture Parameters Config UI per appliance ? Branding UI +2 Other Configuration UIs (e.g. for things configured in XML file) +2 Redistribution of media/metadata/captions to distribution channels +2 Strongly Consider Stats UI +1 Comprehensive confidence monitoring Web Conferencing administration (e.g. manage i/o for processing/dist, conf. initiation, and capture of web conferencing system) Continual synchronization between Matterhorn and Enterprise registrar data. Scheduling resolution UI to deal with conflicts between Matterhorn and Enterprise registrar data. Capture Parameters Config UI per recording Audio level compression/limiting UI -1 Out of Scope Mobile device admin app -2 Automatic classification tools ? tell system which rooms are available at a particular time and capabilities of room -2 Interface to LMS/Campus Management for data transfer in both directions SC HD Cropping UI (i.e. removal of unwanted parts of the frame) +1 Process notification ? Automatic lecture titling based on syllabus in LMS SC is this related to automatic metadata via. R25 et al.? Specify a date after which a recording will be unpublished SC Send (email, SMS) reminders to attendees required @ a meeting (e.g. camera operators) -2 Delay publication of a recording until a specified date SC Processing & Services Must Have Federated search service across Matterhorn instances +2 Composer support for open codecs and wrappers (e.g. Ogg Vorbis) +2 Composer support for HD +2 Support for media editing +2 "Hold" workflow for multi user media review +2 Configuration support for workflows +1 Configuration support for composer +1 Support for redistribution of media/metadata ? Archive workflow (e.g. Duraspace, JackRabbit?) ? Strongly Consider Media Analysis for blackboard and whiteboard OOS Proof of Concept Auth implementation: CAS, OpenID, Shibboleth (e.g. distribution, administration) MH Proof of Concept Enterprise Integration: Kuali, PeopleSoft, LDAP, ? (e.g. distribution, administration) MH Proof of Concept LMS integration: Moodle, Sakai, Blackboard (e.g. distribution, administration) MH Support for audio level compression/limiting 0 Open source speech to text transcription and training intergration: Sphinx, MIT? +2 Proof of Concept commercial transciption/sync integration: Google, AST -1 Statistics "homoginization" service ? Feedback Loop for Annotation Data. ? Scoped distribution based on Authn/Authz (e.g. share with class, share with individuals, share with public) +2 Proof of concept commercial cloud service impls for encoding and storage 0 Proof of concept Matterhorn cloud service models for cross institutional infrastructure. 0 Out of Scope Authoritative annotation by instructors -2 ?UI service (eg libraries)? ? Integration with library digitization efforts ? "On camp" for libraries perserving scholarly confereneces ? Tool to embed video in Google Apps -2 Integration with university unified conta?? architecture ? Matterhorn Portal with recording from all Opencast universities SC Create new series based on existing recordings MH Distribtue to iPhone mobile devices Done? Content federation +2 Interplatform connection between two implementation of Matterhorn +2 Mix "video" and "display" to generate another video for mobile devices - or do a composition -2 Composer: mix multistream recordings to one stream videos (PiP, etc) - intelligently -2 Engage Must Have Proof of Concept Authn/Authz Support in existing portals: Drupal, WordPress, etc. +2 Scoped annotations based on Authn/Authz (e.g. share with class, share with individuals, share with public) +2 Open Social Support (i.e. gadgets) (e.g. Facebook proof of concept) 0 Scoped search based on Authz/Authz +2 Portlet Support ? Hotspots by most viewed ? Hotspots by most annotated ? Strongly Consider HD Video: Zoom in to parts of the screen (read the board) +2 Keyword and concept cloud per video/course/class MH Mobile app (find, view, share) 0 Template editor for engage tools ? Is this the online editor? Amazon recommends... (collbaorative filtering) 0 Ability to email instructor with questions specific to points in time of lecture 0 Out of Scope Create new video by combining segments (eg playlists for study sheet) +1 Plays in the home (Wii, XBox360, etc) -200 Share annotations SC Share playlists SC Connection to semantic web ? Attach files to class course or event (faculty or admin) ? Student talk-back (cam mess) ?? -2 UI personalization -2 End-user annotations MH (s. above) Inter-course linking to related/supporting materials +1 Collaborative transcript generation (in multiple languages) 0 Community editing like comments, wiki-editing of captions +1 Output for mobile devices Done? Student oriented tools (slides + text) +2 Speaker diarization -2 HTML 5 player 0 UI preference for language 0 providing access to lectures by role, by id, by group +2 s. above Community Must Have Metadata exchange (searchability across universities) +2 Opencast content and video event (conference, festival, etc) +2 More face to face +1 Adoption support +1 Best practices -1 Call home for source ? Strongly Consider Pedagogical oriented best practice examples 0 Out of Scope Central portal for all recordings made with all Matterhorn installations +1 (s. above) Other GUI made the apple way, not engineer way 1 Functionality and low cost ? Statistical package for management information data ? Extensive interaction logging (research, Amazon) ? Mobile app (iPhone and blackberry & android) -2 Authoring of classroom matierals (vieo + slides + links + formative testing + ) using video timeline ? Informal instructure collections of video materials 0 Personal collections and group sharing 0 Drop-box for mobile devices -2 Pedagogical background + effect 0 Mobile client support -1 Chris, is you "deviant scenario" (http://n2.nabble.com/BA-UX-orgzona-request-td4033185.html#a4033185) considered here? Year 2 Requirements - top level decision making This is a summary to the decision making tablewith all the issues that have been discussed towards a year two perspective; the latter part of that discussion can be viewed at http://uvigo.emea.acrobat.com/p25522821/. (http://uvigo.emea.acrobat.com/p25522821/.*) Strategic considerations Lecture Capture System vs. Engage apps Will we change perspective and focus the end user instead of the institutional user? Lecture Capture System vs. Rich Media Will the focus be on further functionalities to produce and distribute media or on producing richer video (media analysis, search, semantic analysis)? Didactical Perspective vs. Technical development Are we going to take a dedicated perspective on the use of Matterhorn video in education or "merely" enrich Matterhorn with more features and functionalities? Themes arising as patterns from the discussion around features Opening video temporally / "temporal communication mechanism" "device agnostic" "works in internet enabled devices" "automated enrichment of media" "support discoverability and exchange of open content" "instructional design driven" "low total cost of adoption" Functionalities with major impact, workload, need for discussion or relating to year 1 functionalities Online editor: Let Mary trim and edit within Matterhorn: A year 1 functionality? Annoations: Let students annotate video on the timeline (MPEG-7) Authorization/Authentication: Roles beyond the administrator (lecturer to start/pause/stop capture, review recording, student annotation) "Federated Search" / aggregating functionalities across Matterhorn installations Functionalities with overwhelming agreement in the decision making table Capture UI for users to start/pause/stop recording Multiple device capture agent Live streaming HD video Admin Workflow configuration and UI Branding UI (part of Online Editor?) Enterprise integration/synchronization Processing/Service Composer for open formats & HD "Hold" functionality UI/support for workflow configuration Archive support Speech to text Engage AA-enabled Annotations (complexity of annotations yet to be discussed) Open Social Scoped & faceted search User stats (visualization) Keywords/clouds as quick overview on content User-driven HD consumption (zoom into the video) / customized UI / support for multimple media in UI Share: Playlists, annotations UI preference for language multi-speed playback Support mobile devices/consumption Personal collections Community Pedagogical oriented best practice examples - Educational Tech Specialist collect data and provide results. Other functionalities - cf. decision making table Archive DEPRECATED Existing Technologies and Projects DEPRECATED Service Guides Matterhorn Calendar Mockup DEPRECATED - Release 0.5 ~ Scenarios (Aug. 09 - Jan. 10) DEPRECATED - Release 0.5 ~ Iterations (Aug. 09 - Jan. 10) DEPRECATED Working Documents DEPRECATED - Release 0.5 ~ Deliverables (Aug. 09 - Jan. 10) Usage Requirements DEPRECATED StatusMessage Structure DEPRECATED Distribution Team Diagrams DEPRECATED IngestService DEPRECATED Existing Technologies and Projects Almost all of the Matterhornpartners have developed at least some aspect of a rich media capture processing and distribution solution. It is our expectation that this collection of expertise and technologies will inform by and inclusive of many these technologies. Below is a summary of technologies and projects that we anticipate will play significant roles in the design and development of Matterhorn. WEBCAST.BERKELEY NEXT GENERATION In August 2008, the University of California Berkeley released a redesigned system for automated lecture capture, processing and distribution (Webcast.Berkeley Next Generation). The redesigned system addressed issues of integration with Apple's Podcast Producer and with Sakai, extended the capacity to distribute to multiple public channels, and to integrate with campus systems. An overview of Webcast.Berkeley NG can be found at http://www.opencastproject.org/node/28. Screenshot of Administrator Interface (managing course capture) Berkeley's Webcast.Berkeley NG's state machine will inform Matterhorn's workflow and event handling requirements. REPLAY REPLAY is a multimedia processing and distribution system in development by Multimedia Services of ETH Zurich. It is designed to work with large amounts of audiovisual content. It takes objects through a complete life cycle from integration to distribution. In this, REPLAY addresses a number of aspects that need to be taken into account when dealing with audiovisual content today. An overview of REPLAY can be found at http:/ /www.opencastproject.org/node/30. Architecture of REPLAY Components from ETH Zürich's REPLAY system will be the basis for many of the service implementations in Matterhorn, such as video OCR, indexation technologies, and semantic search patterns. PLAYMOBIL, ETH Zürich's capture appliance, will inform the development of a Matterhorncapture solution. In addition, REPLAY will be the short term solution to be promoted by the Opencast Community until the release of Matterhorn - to provide an entry point for institutions in need for an instantaneous solution and to be the incubator for a number of technologies (OCR, indexation) to become part of Matterhorn. With a migration path to Matterhorn, continuity is safeguarded for technologies and users.http://w ww.opencastproject.org/node/30 RECOLLECT The Recollect system is a turnkey course casting system used at the UniversityofSaskatchewan in some classes. Notable features include: automatic publishing of videos, templating of videos for different media/output formats, automatic chaptering, in-lecture search capabilities, student note-taking facility, integration with CAS authentication for SSO and WebCT/Blackboard integration. The system uses post-processing to form output videos ensuring that original content can be captured in as high fidelity as possible for archival. An overview of the Recollect system can be found at http://www.opencastproject.org/content/recollect_lecture_capture_system. The University of Saskatchewan's Recollect capture appliance and client application provides a basis for Matterhorn's capture appliance and manual capture application. Although the direction of development will start from Recollect, "best of breed" elements from other solutions, such as PLAYMOBIL, will be considered. The Recollect system is a turnkey course casting system deployed at the UniversityofSaskatchewan. It started as a research project from the Advanced Research in Intelligent Educational Systems laboratory in the Department of Computer Science (http://ai.usask.ca). http://www.opencastproject.o rg/node/69 VIRTPRESENTER The virtPresenter framework has been developed at the UniversityofOsnabrück at the "Center for Information Management and Virtual Teaching" (virtUOS). VirtPresenter is a combination of different software programs, containing components for the semi or fully automatic recording and post-production as well as distribution and replay over different platforms. A major feature of virtPresenter is a fully automatic production chain, which is started by running a Powerpoint-Presentation or a VNC screenrecording. As a result, the recording is available online over different web interfaces and platforms or as mobile podcast version. An overview of the virtPresenter Framework can be found at http://www.opencastproject.or g/node/34. VirtPresenter Production Process VirtPresenter's Flex-based Web Interface Osnabrück's virtPresenter's front end technology and design will be a major reference for Matterhorn's user facing applications. virtPresenter's annotation, media presentation, ingest, and metadata entry functionality will provide Matterhorn with working model of innovative learning tools. PROJECT PAD Northwestern's "Project Pad" software includes tools that let users attach annotations to time segments of video and audio clips. It provides both the standard audio / video controls and a zooming timeline. Users can move to any point by clicking the timeline and even drag on the timeline to preview the media. An overview of Project Pad's audio and video annotation tools can be found at http://www.opencastproject.org/wiki/project_pad_audio_and_video _annotation_tools. Video Annotation Tool This highly innovative tool offers Matterhorn cutting edge design and functionality and will inform, possibly provide key technologies forMatterhorn's presentation tool. CAPSCRIBE Developed at the UniversityofToronto, CapScribe provides an interface for creating synchronized captions and audio descriptions for Quicktime Video. CapScribe application In collaboration with the University of Osnabrück, this work will be contributed and integrated as Opencast functionality and the Matterhorn captioning service will be created for the ingest and integration with CapScribe content.http://www.capscribe.com/ FLUID PROJECT UX DESIGN HANDBOOK, FRAMEWORK, AND COMPONENTS Fluid is a collaborative project to improve the user experience (often referred to as "UX") of community source software. Matterhorn will leverage the open source Fluid libraries wherever possible and appropriate. It will also contribute back code for use within components that merit extension and generalization across other community and open source projects. In addition, the Fluid UX Design Handbook will provide design, accessibility, and usability strategies for Matterhorn designers to follow.http://wiki.fluidproject.org STEEPLE PROJECT Steeple is a JISC funded UK Higher Education community project, led by Oxford University, the Open University, and University of Cambridge. The vision for the Steeple project is to create a viable community around scalable, enterprise-level solutions suitable for the UK-HE sector in the areas of automated video/audio capture, video/audio processing, and video/audio delivery. The project proposes to provide a clearly documented example of processes necessary to implement an enterprise level podcasting encoding solution, which will have been tested for robustness and interoperability within each of the three different collaborating universities. It is anticipated that Opencast Matterhorn will be adopted as the basis for this solution. The Steeple project leads have been active members of the Opencast Community, and the direct participation of UniversityofCambridge in the Opencast Matterhorn project will facilitate a coordinated effort between Opencast and Steeple. This project is still in early planning phases.http://www.steeple.org.uk/ PUMUKIT PuMuKIT is a mixture between a Content Management System and a Repository System customized for the easy handling of audiovisual digital contents. PuMuKIT catalogs and archives the audiovisual assets of a University in form of Multimedia Objects (MO) In a MO you can group the video files with other contents as text files, PDFs, pictures, etc... A PuMuKIT server is able to presents the MO available in his database in different ways, it can display/generate/produce a multimedia web site, a MM web site for mobile devices, and export federated environments flows in different RSS an XML formats (Podcast-XML, ARCA-RSS, etc), OAI-PMH. An specific module insides PuMuKIT drives the transcoding of the master media files using a cluster of servers with a SOA (REST) architecture.PuMuKIT is now in use by 12 Universities and Institutions inSpain, 2 in Argentina and 1 in Ecuador. Examples can be seen in: tv.um.es, ehutb.ehu.es, tv.cesga.es or www.uvigo.tv DEPRECATED Service Guides DEPRECATED Create a Matterhorn Service DEPRECATED Creating an OSGI service with REST and SOAP Endpoints DEPRECATED Creating UI-facing, RESTful service in Matterhorn DEPRECATED From installing Matterhorn to a live Service DEPRECATED Service Design Best Practices DEPRECATED Create a Matterhorn Service CREATING A NEW OPENCAST SERVICE The Matterhorns foundations are running in an OSGi environment, meaning it is formed out of modular service components. Api vs. Implementation When implementing services, it is a good and common practice to separate api from implementation, since only then can you develop other services against the api while swapping out the implmentation of it later (even at runtime). Therefore, when iplementing a service foo for opencast matterhorn, you will usually end up with two OSGi bundles: opencast-foo-service-api opencast-foo-service-impl Creating a service using the opencast template Luckily enough, there is an easy way to create a service skeleton using the maven opencast plugin: mvn oc:generate -N -DserviceName=foo Adding the projects to Eclipse We will now add the two new projects to Eclipse (other ide's can be used in a similar fashion), which is an easy task as maven comes with an eclipse plugin that will generate all the project metadata for you. Just change directory into each of the project folders and issue mvn eclipse:eclipse which will generate the eclipse project files and allow you to import your new services as preconfigured projects into your Ecplise workspace. Adding sources and javadocs to Eclipse If you like eclipse to link the thirdparty libraries that you are using in your project to their sources and javadocs, add a -DdownloadSourc es=true and/or -DdownloadJavadocs=true. The eclipse projects will refer to each other using the maven repository, e. g. the service implementation will expect the service api to be available there. This is why you want to make sure that it also gets installed into the maven repository: mvn install After that, go to Eclipse and choose "File" and "Import..." to select the new projects and import them into the workspace. DEPLOY YOUR SERVICE IMPLEMENTATION TO FELIX Once your service definition and implementation look promising enough to try them in the runtime environment. Depending on how you are installing and registering your bundles, there are two ways of deployment, detailed in the following two sections. Deployment using the file load service If you happen to be running an OSGi container with support for the file load facility, deployment is as simple as pointing the maven install target to the root folder of the load facility: mvn install -DdeployTo=$OSGI_HOME/load Your container will then reload your bundles and you are done. Be Careful Reloading your bundles (as opposed to restarting the whole OSGi container) means that you need to carefully implement the bundle lifecycle, i. e. if you registered a resource at bundle start time, make sure you unregister it once your service stopps. Manual deployment In this scenario, your OSGi container will use the bundles from the maven repository, therefore you need to build and install them into the repository: mvn install Now that the service api and implementation are installed in the maven repository, go to $FELIX_HOME and add the new artefacts to the list of services. This step needs to be done once, so if you keep developing and refining the service, unless you are augmenting the service version, there is no need to register again. Restart felix For the time being, you also need to manually clear the felix cache if you were updating a previously installed bundle by calling rm -r $FELIX_HOME/felix-cache/* This will be removed shortly and bundles will be published to the felix load directory instead. If you now restart felix, you should see your running services by typing -> ps on the felix console. Make sure your services are marked as being Active. DEPRECATED Creating an OSGI service with REST and SOAP Endpoints This tutorial aims to help developers put together a Matterhorn service API and implementation with REST and SOAP endpoints. Step 0: Add a task (and subtasks) in Jira Step 1: Add -service-api and -service-impl modules in SVN Step 2: Set up the modules' builds with maven Step 3: Add your service API and implementation Step 4: Register your service implementation with the OSGi container Step 5: Implement REST and SOAP service endpoints Step 6: Verify that your service is running Step 0: Add a task (and subtasks) in Jira Before starting work, please create Jira tasks or story cards for the work you are about to do. Without a Jira ticket number, you can not commit code to SVN. Step 1: Add -service-api and -service-impl modules in SVN Choose a name for your module, following this naming convention: opencast-[service]-service-api and opencast-[service]-service-impl. svn mkdir --parents https://source.opencastproject.org/svn/opencast-my-service-api/trunk \ -m "[Jira ticket number] -- adding a module for the 'my' service api" svn mkdir --parents https://source.opencastproject.org/svn/opencast-my-service-impl/trunk \ -m "[Jira ticket number] -- adding a module for the 'my' service impl" To add your new module to the default Matterhorn checkout, add the following lines to the .externals file in the root of the Matterhorn checkout: ../../opencast-my-service-api/trunk opencast-my-service-api ../../opencast-my-service-impl/trunk opencast-my-service-impl Update the svn:externals property of the root of the Matterhorn checkout, and update Matterhorn. svn propset svn:externals . -F .externals svn update Step 2: Set up the modules' builds with maven Your new modules should now be available locally to work with. Create the following directory structure under each module: MATTERHORN_ROOT | |- ... |- opencast-my-service-[api|impl] | |- src | | |- main | | | |- java | | | |- resources | | |- test | | | |- java | | | |- resources This is the standard maven2 directory structure. The Java classes to be packaged as part of the software should be placed under src/main/java. Unit tests go under src/test/java. Any resources (e.g. properties files) should go under src/main/resources, and any test-specific files that you want available on the classpath during testing should go under src/test/resources. If this is confusing, please read the maven2 users guide. Create pom.xml files in opencast-my-service-api and opencast-my-service-impl, specifying the dependencies and osgi bundle instructions. See the other pom.xml files for a template. TODO: Provide a template Step 3: Add your service API and implementation Create a java package called org.opencastproject.my.api in the service module, and add a Java interface named MyService.java. In the implementation module, add a class that implementats your API and name it org.opencastproject.my.impl.MyServiceImpl. The file opencast-my-service-api/pom.xml must include instructions for building the osgi metadata, including the package exports. See the documentation for the maven-bundle-plugin The file opencast-my-service-impl/pom.xml must also include instructions for building the osgi metadata. In this case, we define where to find the osgi declarative serices xml file(s). Step 4: Register your service implementation with the OSGi container I recommend using OSGi declarative services to register your service, since this allows you to keep your code free of OSGi dependencies. The choice is yours, so if you prefer, feel free to register your service programmatically using OSGi ServiceTrackers to track your service's dependencies. To use declarative services, add a new directory: opencast-my-service-impl/src/main/resources/OSGI-INF. Add a file to this directory named my-service.xml with the following contents: The xml above exposes a service endpoint using CXF's default DOSGi configuration (Simple frontend with Aegis databinding). This produces a WSDL endpoint that is difficult to customize, so if you intend to support web service clients with a WSDL, you should add another endpoint using JAX-WS. TODO: Provide a sample JAX-WS + JAXB service If your service requires a collaborating service (e.g. the WorkingFileRepository), you can add a reference like this: Please read the Declarative Services section of the OSGi compendium spec for more details. Step 5: Implement REST and SOAP service endpoints To add a REST service, add a new Java class to the impl project. Add JAX-RS (JSR-311) annotations to define the HTTP methods, URL spaces, and object and media types that your RESTful service produces and consumes. See the CXF Users Guide for an overview of the available annotations. Please follow Matterhorn's convention of providing service documentation under the '/docs' URL by specifying a method such as: @GET @Path("/docs") @Produces(MediaType.TEXT_HTML) public String getDocumentation() { return "Please Document Me!"; } TODO: Is this really how we want to deal with runtime documentation? Use declarative services to register this service with OSGi: To use declarative services, add a new directory: opencast-my-service-impl/src/main/resources/OSGI-INF. Add a file to this directory named my-service.xml with the following contents: Step 6: Verify that your service is running All registered service endpoints are displayed on Matterhorn's service listing page. Verify that your service is listed at http://localhost:8080/ and start using your new service! DEPRECATED Creating UI-facing, RESTful service in Matterhorn Custom services to support rich client-side applications can make development of the front end easier by providing a single service endpoint for all of the client's CRUD operations, even when these operations span multiple back-end services. Take for example a rich client-side application that displays address information for the current user: Josh Holtzman 9 Dwinelle Hall Berkeley, CA 94720 USA There may be two back end services that store such information: a user directory that stores simple username, ID, and email information, and an address service that manages physical addresses. If the client application calls these services directly, two service calls must be made from the front-end: 1. Find the full name of the current user, who has an ID of 123 2. Find the address for this user By providing a service tailored to the needs of this client, we gain several advantages: 1. We reduce the complexity of the UI code 2. We reduce the number of client-server round-trips 3. We are able to develop the UI and its services in parallel, allowing for rapid iteration regardless of the state of any collaborating back-end services. Simple stub implementations can be written and then swapped out in later iterations once the back-end services come online. With our aggressive schedule, the last point is critical for Matterhorn to be able to deliver on time. Teams developing user interfaces can develop the services they need, as they need them. This tutorial aims to help developers put together a user-facing RESTful service in Matterhorn. Step 0: Add a task (and subtasks) in Jira Step 1: Add a module in SVN Step 2: Set up the module's build with maven Step 3: Add your JAX-RS annotated service implementation Step 4: Register your service with the OSGi container Step 5: Verify that your service is running Step 0: Add a task (and subtasks) in Jira Before starting work, please create Jira tasks or story cards for the work you are about to do. Without a Jira ticket number, you can not commit code to SVN. Step 1: Add a module in SVN Choose a name for your module, following this naming convention: opencast-client-ui-service. If you are building a service for the dashboard tool, for example, you would name the service opencast-dashboard-ui-service. svn mkdir --parents https://source.opencastproject.org/svn/opencast-dashboard-ui-service/tru nk \ -m "[Jira ticket number] -- adding a module for the dashboard UI service" To add your new module to the default Matterhorn checkout, add the following line to the .externals file in the root of the Matterhorn checkout: ../../opencast-dashboard-ui-service/trunk opencast-dashboard-ui-service Update the svn:externals property of the root of the Matterhorn checkout, and update Matterhorn. svn propset svn:externals . -F .externals svn update Step 2: Set up the module's build with maven Your new module should now be available locally to work with. Create the following directory structure under opencast-dashboard-ui-service: MATTERHORN_ROOT | |- ... |- opencast-dashboard-ui-service | |- src | | |- main | | | |- java | | | |- resources | | |- test | | | |- java | | | |- resources This is the standard maven2 directory structure. The Java classes to be packaged as part of the software should be placed under src/main/java. Unit tests go under src/test/java. Any resources (e.g. properties files) should go under src/main/resources, and any test-specific files that you want available on the classpath during testing should go under src/test/resources. If this is confusing, please read the maven2 users guide. Create a pom.xml file in opencast-dashboard-ui-service, specifying the dependencies and osgi bundle instructions. See the other pom.xml files for a template. TODO: Provide a template Step 3: Add your JAX-RS annotated service implementation Create a java package called org.opencastproject.dashboard.ui.service and add a Java class named DashboardUiService.java. Add JAX-RS (JSR-311) annotations to define the HTTP methods, URL spaces, and object and media types that your RESTful service produces and consumes. See the CXF Users Guide for an overview of the available annotations. Please follow Matterhorn's convention of providing service documentation under the '/docs' URL by specifying a method such as: @GET @Path("/docs") @Produces(MediaType.TEXT_HTML) public String getDocumentation() { return "Please Document Me!"; } TODO: Is this really how we want to deal with runtime documentation? Step 4: Register your service with the OSGi container I recommend using OSGi declarative services to register your service, since this allows you to keep your code free of OSGi dependencies. The choice is yours, so if you prefer, feel free to register your service programmatically using OSGi ServiceTrackers to track your service's dependencies. To use declarative services, add a new directory: opencast-dashboard-ui-service/src/main/resources/OSGI-INF. Add a file to this directory named opencast-dashboard-ui-service.xml with the following contents: If your service requires a collaborating service (e.g. the WorkingFileRepository), you can add a reference like this: Please read the Declarative Services section of the OSGi compendium spec for more details. Step 5: Verify that your service is running All registered service endpoints are displayed on Matterhorn's service listing page. Verify that your service is listed at http://localhost:8080/ and start using your new service! DEPRECATED From installing Matterhorn to a live Service 1. Install Matterhorn and set up tools 1.a Get an copy of matterhorn and install it. follow instructions at OpencastWiki: Install and Configure 1.b Also you want to have all development tools set up correctly. follow instructions at OpencastWiki: Tools 2. Build Eclipse projects and import them into Eclipse 2.a After you have checked out the trunk you have to generate the Eclipse projects. cd 2.b When the projects have been generated you import them them into Eclipse. in Eclipse: File / Import / Projects with Existing Source Simply select the matterhorn base directory that you checked out. 2.c If you have installed Matterhorn for the first time you also have to run a build on the opencast-runtime-tools project to make sure that all the things necessary to run Matterhorn in felix are in the Maven repository. cd 3. Generate your new Matterhorn service 3.a There is an Opencast plugin for Maven wich will generate a new service for you. cd This will create two subfolders under the Matterhorn base folder: /opencast- 3.b Once you have generated your new service you have to create the Eclipse projects. cd You can then import the two projects into Eclipse by repeating step 2.b. The first project is the place where you define Java API for your service, notinhg more. The -impl project is where you implement your API (again pure Java), it's service endpoints (Java + JAX-WS/JAXB) and the tests for your implementation. It is also the place where to put static resources like images, webpages etc. 4. Build and deploy your service 4.a There is a Maven plugin that deploys your code into felix for you. To make your new service run in felix you have to build and deploy the -api project as well as the -impl project. cd This will build your service API and implementation and copy the resulting .jar files to the /load directory of your Felix server. The Felix should recognize the new service or the new version of your service automatically after a few monments. 4.b In case automatic reloading of your service fails you have to restart Felix and clear it's cache. In the console you started felix in, type shutdown This will shutdown felix. Then, in felix base directoy rm -r felix-cache/* java -DM2_REPO= Under Linux/Mac the maven repository is in a hidden directory in your home folder where your Maven lives. So in most cases ~/.m2/repository should work as M2_REPO path. 4.c Your new service should be running now. In the console you started felix in, type ps This will show you all services that are currently running in felix. If everything went fine you should find your services API and implementation in this list. It should look something like this [ 67] [Active ] [ 3] opencast- Your service should be marked as Active. If you find it, but it is marked only as Installed, then there are probably some dependencies missing in the Maven repository. In this case doing step 2.c might help. If your new Service is alive and happy, you can reach it under http://localhost:8080 (Service Endpoints Overview) http://localhost:8080/ On this page: Types of Services Matterhorn Service Design Process Differences between REST & SOAP + WSDL Deciding when to create a REST vs. SOAP + WSDL Service Naming Conventions for Services Versioning of Services TYPES OF SERVICES Business Services that focus on executing or enforcing business rules Process Services that chain together other services to accomplish a business process Information Services that deal with the retrieval, persistence and normalization of data Integration Services that enable legacy systems such as mainframes Partner Services that communicate with partners and do simple transformation Collaboration Services that are exposed publicly and serve as the interface to the application allowing people and processes to collaborate More info: http://www.momentumsi.com/harmony/RA-ServiceClasses.html MATTERHORN SERVICE DESIGN PROCESS 1. The Service Candidates page (https://wiki.opencastproject.org/confluence/display/open/Service+Candidates) will (for now) serve as our list of the services we are working on or plan to work on. As services are modeled, they should be linked as child pages underneath this Service Candidates page. Developers who are involved with services in any way should "watch" the Service Candidates page so they are notified as changes are made. 2. There has been some debate about whether we will do 'services-first' ('code-first') or 'contract-first' ('design-first') development of services. Even if you are coding a service in Java, you are likely doing some design work first, and we'd like everyone to document their thoughts as they design a service (or set of services) in the wiki in some fashion. All of these documents should be child pages of the Service Candidates page. There are several different levels of rigor you could use in this process: a. A 'paper napkin' sketch wiki page, which you can format in any way you choose. This could be for a single service (if so, please link it from Service Candidates page) or a set of services (e.g. "Markus' initial thoughts on Engage services). The idea is just to document what you're thinking on the wiki so others are aware of it and can react to it if necessary. b. A capabilities list, similar to the one we created for the Editing Service (https://wiki.opencastproject.org/confluence/display/open/ Editing+Service) c. A simple operations table, similar to the ones Josh & Tobias created: https://wiki.opencastproject.org/confluence/display/open/_ MediaIngestService_ d. The SOAP+WSDL Service Description Document template (https://wiki.opencastproject.org/confluence/pages/templates/viewpa getemplate.action?pageTemplateId=1540101&key=MHOLD) or a REST Service template (to be created if needed) e. Any template you find helpful - if you've got something that works well, be sure to point everyone to it so they can use it if it works for them! DIFFERENCES BETWEEN REST & SOAP + WSDL In the REST world the service definition process usually starts with identifying resources whereas in the SOAP/WSDL world activities are more often the focus. Resources in REST can be any kind of entity. DECIDING WHEN TO CREATE A REST VS. SOAP + WSDL SERVICE Asynchronous communication is a requirement for many of the processing services due to the long processing times involved in media transcoding, analysis, and transfer. There are a few techniquest to deal with asynchronous RESTful services, but no standard. There are a few standards for SOAP+WSDL services, but limited tooling support. In the end, the message exchange pattern may influence the REST vs. SOAP decision, but this is still to be determined. NAMING CONVENTIONS FOR SERVICES VERSIONING OF SERVICES #proposal This should only be handled after the 1.0 release. Matterhorn Calendar Mockup Internal server error DEPRECATED - Release 0.5 ~ Scenarios (Aug. 09 - Jan. 10) "Release 0.5 Scenarios" include all of the scenarios available by Jan 2010. Click on here to learn more.NOTE: If text in scenario is green, the user action takes place outside the Matterhorn system. Under "Related Services" column, bolded red indicates that the rest service is used by a client, whereas the other services are used directly or indirectly by other services. If a service is in italics, it means that the service is currently a "working document". Services with no links have yet to be defined. MHOLD:Release 0.5 ~ Scenarios (Aug. 09 - Jan. 10)#Q1 Q1 Scenarios (August - October 2009, ends with iteration 4) Scenario Functional Related Comments User Stories Services 1) Administrator uploads a Admin: MH-571 MediaIngestService, Encompasses ingest, processing, and distribution. video-audio file to be processed MediaComposerService, MediaInspectionService WorkingFileRepository SiteConductorService WorkflowService 2) Administrator schedules Admin: MH-846 MediaIngestService, Encompasses capture, ingest, processing, and distribution. individual event for capture and MediaComposerService, distribution MediaInspectionService, StreamingDeliveryService will not be added since there is an open question CaptureAgentService, whether red 5 can be easily integrated into build within OSGI env. Red 5 may LocalDistributionService, ultimately be a contrib tool. Opencast-HTTP Unclear whether we will meet this deliverable by creating custom UI with module, Scheduling Service, or with Bedework as interim prototype. Ideally the former, but WorkingFileRepository, depending on velocity we may need to go with the latter. WorkspaceService, simple rss feed will be based on the search service, and show latest episodes. SchedulingService, Querying the search service for a more sophisticated feed service (categories, SearchService, keywords, channels, etc.) will come later. FeedDistributionService Open Questions: How does the search service know where the media was distributed to? If the rss feed plans to use this service, why can't it be used for scenario 3. 3) Learner finds video in Engage: Opencast-HTTP module Search service should not be used to list distributed files, refer to file directory where Matterhorn list of videos and MH-174,MH-176, MH-168, media was distributed to. watches it MH-419, MH-797, MH-420, LocalDistributionService MH-800 Orphan user stories (Admin & Learner) currently slotted for iterations 1-4: scheduled for iteration 2: MH-646, MH-130, MH-173 scheduled for iteration 3: MH-622 (iteration 3, though Adam says too big to be a story), MH-798, MH-234, MH-235, MH-236 (not needed until Q2), MH-237, MH-979 scheduled for iteration 4: MH-1038, MH-989, MH-993, MH-515, MH-799 (not needed until Q2), MH-980, MH-179 Q2 Scenarios (November 2009 - January 2010, ends with iteration 7) Scenario Functional Related Comments User Stories Services 1) Administrator MH-130 MediaI FeedDistributionService the location will be named after the agent device. the agent device name will reflect room name, schedules recurring ngestService,MediaCom number, and capability. "mobile agents" do not have a naming convention yet. we assume that recording for automated poserService, the Administrator will understand the naming convention. the agent device names will need to be capture MediaInspectionService, configured. This is discuss in Scenario 6. CaptureAgentService, LocalDistributionService, WorkingFileRepository, WorkspaceService SchedulingService, 2) Administrator follows MH- 754, MH-846, MH-8 simple list of capture and distribution success. will be replaced by job controller. the progress of today's 47 events from capture to distribution 3) Learner watches a MH-799 Opencast-HTTP no caption processing in this iteration. just support for turning on and off captions. captioned media file module LocalDistributio nService 4) Learner searches for MH-796 specific video by keyword and watches the video 5) Learner subscribes to feed 6) Configurer installs/configures Matterhorn to review its functionality 7) Administrator checks the status of all the capture devices. Orphan user stories (Admin & Learner) currently slotted for iterations 5-7: MH-723 (iteration 7) Release 0.5 Q3 Scenarios (February - April 2010, ends with iteration 10) Scenario Related User Stories Related Comments Services 1) Administrator logins into to the system 2) Administrator uploads manually captured video for a scheduled lecture 3) Administrator follows the progress of today's events from capture to distribution extensive job controller including filters, basic tasks, and sorting. 4) Administrator monitors capture feeds to ensure they're working audio and video "snapshots" 5) Administrator distributes processed video to iTunes U need more detail 6) Administrator distributes processed video to Youtube need more detail 7) Administrator uploads caption file for automatically and manually captured MH-845 workflow will hold recordings to be distributed with media processing until caption file is provided. 8) Learner searches within media for text in the captions http://issues.opencastproject.org/jira/browse/MH-796 9) Learner navigates within media by slides 10) Administrator uploads supporting attachments eg. Powerpoint, pdf, doc, txt, etc. (no sync supported) 11) Administrator imports schedule (ical) that has been exported from campus scheduling service. Q4 Scenarios (May - June 2010) - possibly July Scenario Related User Stories 1) Administrator adds an extra recording to recurring event 2) Administrator cancels one recording in recurring event 3) Learner bookmarks a specific segment of the lecture to review it at a later date Who subscribes to view videos and possibly Engages Tools within the LMS??? 4) Configurer installs/configures Matterhorn to run a small pilot on their campus 5) Configurer installs/configures Matterhorn to run as a campus wide solution 6) Configurer installs/configures Matterhorn service to incorporate into existing system Potential configurations: how long media packages stick around holidays/exclusion dates for an institution drop-downs such as "Category" specify required fields for Ingest/Scheduler RELEASE 1.0 PARKING LOT hold scenario for parking lot. CURRENTLY OUT OF SCOPE NOTE: When it says "Administrator" below, it implies that there is a graphical user interface to perform the task (as opposed to an XML configuration file used by the Configurer). Administrator changes date-time for one recording in recurring event Instructor starts/stops capture appliance from their personal computer Administrator specifies locale for native language Administrator specifies institution wide exclusion dates, midterms for a given time span Administrator reviews and possibly trims media before publishing Instructor reviews and possibly trims media before publishing Administrator reviews statistical feedback for each distributed channel Administrator reviews statistical feedback for the Matterhorn player Administrator specifies branding and intro/outro for an individual or group of recordings Administrator adds/edits/removes capture locations Administrator specifies encoding specs for distribution and capture Administrator redistributes problematic media/metadata Administrator adjusts audio before distributing media PROMISED DELIVERABLES IN GRANT FOR LECTURE CAPTURE SYSTEM Scheduling UI to schedule lecture/event recordings Metadata entry for courses/lectures/events Updates on the success/failure of capture, encoding, and distribution Encode from original source to one/many different formats Distribute encoded media/metadata to iTunes U, YouTube, RSS/Atom Accessible, embeddable media player Capture appliance specs and prototype that supports one audio, video, and VGA source for high-quality encoding Administrator cancels one recording in recurring event Note: may want to make this one use case in a larger scenario, but for now making it independent. Need to flesh out, first. Administrator changes date-time for one recording in recurring event Note: may want to make this one use case in a larger scenario, but for now making it independent. Need to flesh out, first. Administrator follows the progress of today's events from capture to distribution User: Administrator Precondition: Administrator has entered the date, time, and location for an event to be recorded automatically. User intention/action System Responsibilities Begin capture at designated time See that capture has started. After capture ends, move recorded media into media pipeline, process it, and then distribute it See that the recording has been distributed. Administrator schedules individual event for capture and distribution NARRATIVE: User: Administrator Precondition: Instructor Smith contacts administrator to request video/audio capture of a special event. User intention/action System Reponsibility Indicates he wants to add a new event. Enters name of the event, category, date/time, and location. Specifies that only video/audio should be captured, and that it should be available on a page on the Matterhorn Media module. Enters remaining relevant metadata (TBD). Indicates that event should be scheduled for automated capture. The capture agent listens to the schedule on an ongoing basis. A few days later a capture agent captures the scheduled event and submits the media/metadata it for processing to the Matterhorn media pipeline. The capture agent provides the technical metadata. The pipeline encodes the file based on specs provided by the site conductor. The media is distributed to a server to be accessed by the media module. The distribution service creates and/or adds media to an rss feed. A day later,checks his rss reader and finds the completed media in an rss feed. Emails Instructor Smith that his video is available at "X" url. NOTE: the admin will be able to subscribe to the icalendar feed to view scheduled events in their personal calendar. (the following is now incomplete because scenario above was edited. Should edit below accordingly, and probably move it onto a separate but linked page.) DESIGN ELEMENTS EXTRACTED FROM SCENARIO: --- confirmation that the recordings have been entered successfully - tell system she has new event(s) to add - enter & save information about recordings into the system: series title days & times the recordings take place ? term of recording (i.e. when the first and last lecture occurs) or is this in a configuration? in what location the lectures will take place what type of capture it is (e.g. VGA, audio, audio-video, or multiple) other Dublin core-esque metadata about the video publication information (e.g. distribution channels to which the recordings will be published) Administrator schedules recurring recording for automated capture NARRATIVE: User: Administrator Precondition: Instructor Smith contacted administrator to request video/audio course capture of his course. User intention/action System Responsibility Indicate the addition of a new course (recurring event). Enter name of the course, its days and times, and location (agent name). Specify that only video/audio should be captured, and that it should be available as Matterhorn Media (will be used in instructor's blog) Enter remaining relevant metadata (TBD). Indicate that capture schedule should be generated. Generate and display a list of recordings that are now scheduled to occur See list of recordings (lectures) for this course, to confirm that system has it right. The capture agent listens to the schedule on an ongoing basis. A few days later a capture agent captures the scheduled course and submits the media/metadata it for processing to the Matterhorn media pipeline. The capture agent provides the technical metadata. The pipeline encodes the file based on specs provided by the site conductor. The media is distributed to a server to be accessed by the media module. The distribution service creates and/or adds media to an rss feed. Administrator receives the completed media in an rss feed. Administrator emails Instructor Smith that his video is available at "X" url. NOTE: the admin will be able to subscribe to the icalendar feed to view scheduled events in their personal calendar. Administrator uploads a video-audio file to be processed Narrative: User: Administrator Precondition: Administrator has video file on their local hard drive, and knows title and category for it. User intentions/actions System responsibilities Indicates that he has a recording to be uploaded. Enters a title and category of the video. Picks a file from their local video files. Indicates that media should be ingested. System ingests the video and metadata into Matterhorn processing pipeline. System checks to make sure the submitted media and metadata is okay, and provides confirmation if this is the case. Receives confirmation that the upload was submitted properly. The pipeline inspects the media for technical metadata and adds it to the media package. The pipeline encodes the file based on hard coded specs provided by the site conductor service. The distribution service creates and/or adds media element to an rss feed (title, category, and technical metadata in the description). A day later, checks his rss reader and finds the completed media in an rss feed. Administrator uploads caption file for automatically and manually captured recordings to be distributed with media 1. Administrator browses their local files and picks a video within the Ingest UI. 2. Administrator browses their files and picks a caption file within the Ingest UI. 3. Administrator enters a title and category of the video and uploads the video, caption file, and metadata to the Matterhorn processing pipeline. 4. The pipeline encodes the video and generates a video and audio file. 5. Learner watches the video with captions on a Matterhorn media module watch page. Learner finds video in Matterhorn list of videos and watches it NARRATIVE: User: Learner Preconditions: Learner has a specific recording in mind and has gone to the page that lists all recordings. Media has been processed by the Matterhorn pipeline and pushed to a hosting environment for viewing. User intentions/actions System Responsibilities View list of available recordings MH-419 Provide list of distributed recordings with titles and categories for each recording. Choose a recording to review. MH-419 Download service is called to progressively download recording. Loads video into player. Play the recording MH-174 Pause the recording (due to interruption) MH-168 Resume playback. MH-174 Turn up volume (due to competing noise in room) MH-797 (Gets a phone call that takes a minute or so) Set the current time to about 2 minutes earlier in the recording and resume playback. (She didn't pause when the call first came back in) MH-420 See how much of the recording has been viewed (wants to stop when half-way through the recording so can take a break.) MH-176 Additional user stories that aren't crucial to this scenario (but including them since they are already done): MH-980, MH-173 Learner searches for specific video by keyword and watches the video 1. Learner goes to a Matterhorn media module, and enters a search term. 2. "The system" provides a list of results from the search results page. 3. Learner chooses a video and watches it on a Matterhorn media module watch page. 4. Set playback to full screen (can't see the board clearly) MH-800 5. Sees the progress of the download (last 2 steps are just thrown here...not sure this is the right scenario for them) Learner subscribes to feed 1. Learner goes to Matterhorn Engage feed list, subscribes to an audio as well as a video rss feed (based on a category specified in the Ingest UI), and downloads the video via their rss feed reader. 2. Learner plays multiple episodes on their computer. Status for All Iterations DEPRECATED - Release 0.5 ~ Iterations (Aug. 09 - Jan. 10) Story Cards and Tasks broken down by high level components (teams) by iteration. Contains iterations 2-7. Today's Work List of tasks currently "In Progress". Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Iteration 2 (Aug. 09) ~ Admin Tools Admin Tool Story Cards Admin Tool Tasks Admin Tool Story Cards Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Admin Tool Tasks Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Admin Tool Story Cards Admin Tool Tasks Iteration 2 (Aug. 09) ~ Architecture and Process Services Architecture and Process Services Story Cards Architecture and Process Services Tasks Architecture and Process Services Story Cards Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Architecture and Process Services Tasks Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Architecture and Process Services Story Cards Architecture and Process Services Tasks Iteration 2 (Aug. 09) ~ Capture Tools Capture Story Cards Capture Tasks Capture Story Cards Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Capture Tasks Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Capture Story Cards Capture Tasks Iteration 2 (Aug. 09) ~ Distribution Services Distribution Story Cards Distribution Tasks Distribution Story Cards Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Distribution Tasks Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Distribution Story Cards Distribution Tasks Iteration 2 (Aug. 09) ~ Engage Tools Engage Tool Story Cards Engage Tool Tasks key summary assignee reporter status priority Data cannot be retrieved due to an unexpected error. View these issues in JIRA Engage Tool Story Cards Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Engage Tool Tasks Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Engage Tool Story Cards Engage Tool Tasks key summary assignee reporter status priority Data cannot be retrieved due to an unexpected error. View these issues in JIRA Iteration 3 (Sept. 09) ~ Admin Tools Admin Tool Story Cards Admin Tool Tasks Admin Tool Story Cards Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Admin Tool Tasks Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Admin Tool Story Cards Admin Tool Tasks Iteration 3 (Sept. 09) ~ Architecture and Process Services Architecture and Process Services Cards Architecture and Process Services Tasks Architecture and Process Services Cards Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Architecture and Process Services Tasks Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Architecture and Process Services Cards Architecture and Process Services Tasks Iteration 3 (Sept. 09) ~ Capture Tools Capture Cards Capture Tasks Capture Cards Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Capture Tasks Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Capture Cards Capture Tasks Iteration 3 (Sept. 09) ~ Distribution Services Distribution Cards Distribution Tasks Distribution Cards Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Distribution Tasks Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Distribution Cards Distribution Tasks Iteration 3 (Sept. 09) ~ Engage Tools Engage Cards Engage Tasks Engage Cards Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Engage Tasks Key Summary Assignee Reporter Status Priority JIRA server returned an error: Service Unavailable View these issues in JIRA Engage Cards Engage Tasks DEPRECATED Working Documents DEPRECATED ArchiveService DEPRECATED AuthoritativeAnnotationService DEPRECATED CaptionConversionService DEPRECATED CaptureAgentService DEPRECATED DistributionService DEPRECATED Documentation DEPRECATED Media Capture and Ingest DEPRECATED Media Distribution DEPRECATED Media Processing DEPRECATED MediaAnalysisService DEPRECATED MediaComposerService DEPRECATED MediaIngestService DEPRECATED MediaInspectionService DEPRECATED NotificationService DEPRECATED Service Candidates DEPRECATED SiteConductorService DEPRECATED SiteIntegrationService DEPRECATED WorkflowService DEPRECATED WorkingFileRepository DEPRECATED WorkspaceService DEPRECATED ArchiveService Provides long-term storage and retrieval of MediaPackages and their associated media, metadata, and attachment files. This service is intended for use by the lecture catpure system, and is not intended to be a general purpose archiving solution. Operation Return Type Exception(s) Desctiption put(MediaPackage, MediaPackage (via asynchronous callback) Puts all relevant (rules-based) elements and files associated with a NotificationCallback) MediaPackage into the archive. get(MediaPackageId) MediaPackage Gets a MediaPackage from the archive get(MediaPackageId, InputStream, 200 OK + file download, or SOAP Gets a file stored as part of an archived MediaPackage MediaElementId) message with attachment TODO Add checkin(MediaPackage, NotificationCallback) and checkout(MediaPackageID, NotificationCallback) DEPRECATED AuthoritativeAnnotationService Converts authoritative, time-based annotations from simple key-value pairs to valid MPEG-7. Operation Return Type Exception(s) Desctiption createAnnotationDocument(Map DEPRECATED CaptionConversionService Converts MPEG-7 documents containing transcripts to other captioning formats, such as QTtext. Operation Return Type Exception(s) Desctiption convert(MPEG-7, 200 OK + caption file download or SOAP Takes the captions from the mpeg-7 and converts them to the specified output OutputFormat) attachment format DEPRECATED CaptureAgentService Manages capture agents, locations, schedules, and status. Operation Return Type Exception(s) Desctiption getCaptureAgent(Location) CaptureAgent Gets the CaptureAgent (to be defined) for a given location, if one exists getSchedule(Location) iCalendar stream Gets the schedule for automated capture in a location. TODO Finish this design. DEPRECATED DistributionService Publishes and unpublishes media, metadata, and attachments to / from distribution channels. Operation Return Type Exception(s) Desctiption publish(MediaPackage, MediaPackageElementID, DistributionContext (via Distribute and transform any parts of a media package into the format NotificationCallback) asynchronous callback) needed by the distrubution channel unpublish(MediaPackageID, NotificationCallback) NotificationMessage (via Remove any media files related to the media package asynchronous callback) unpublish(MediaPackageID, NotificationMessage (via Remove a specific element from a distributed media package MediaPackageElementID, NotificationCallback) asynchronous callback) Service endpoints are on a per-channel basis. So if there are two different iTunes accounts, there must be two different iTunes distribution service endpoints, each configured with different iTunes credentials. Developers will typically choose one of two strategies when implementing DistributionService. One strategy is to push the media and metadata to a distribution channel, then discard any local copies of the files. The other stragegy is to store the media and metadata in some kind of database (e.g. a filesystem, a relational database, a Java Content Repository, etc), and make the content available via any number of network protocols (e.g. http download or streaming, atom or rss feeds, etc). This "store and serve" strategy can further be implemented to share a storage location with other distribution services, if that is desired. Internal server error Distribution Candidates Architecture ======We see the distribution piece of Matterhorn consisting of various components, probably one for every distribution channel: RSS, iTunes U, etc., each of them implenting the same service contract. This would allow for the conductor service (handling workflows within Matterhorn) to collect a list of all distribution channel services and chose the right ones to have them distribute the media by calling the publish() method and getting back information on the publishing context (e. g. an id from the iTunes store). Distribution channels do not keep track of what has been published, instead they return channel specific context information (e. g. an itunes tab id) to the caller (e. g. the workflow or a thirdparty service). The core services will provide a global search service in order to support feed based distribution channels (see "Services", 7), however, the feed channels might want to keep state (e. g. last 25 entries) on their own. Services ======We can see the following initial distribution services: 1) LocalDistributionService Copies/removes the encoded media to/from a locally mounted file storage which represents the root of an http or streaming server 2) FTPDistributionService Uploads/deletes the encoded media to/from an ftp server 3) HTTPDistributionService Puts the encoded media to a rest url or calls a respective url to delete (unpublish) it. 3) EmailDistributionService Sends a link to the encoded media (located in the work file repository) to a list of recipients. Alternatively, the encoded media could be attached, by I don't think that this is a valuable approach, given the size of these attachments. 4) RSSiTunesUDistributionService Publishes/unpublishes media packages on the iTunes U store by either adding/removing feed entries or triggering feed updates. So far it is unclear if this service should provide its own feeds or use the FeedDistributionService (7). 5) SOAPiTunesUDistributionService Publishes/unpublishes media packages on the iTunes U store by making calls to the iTunes U SOAP interface and pushing encoded media files to the store. 6) YouTubeDistributionServices Publishes/unpublishes media packages on YouTube. 7) FeedDistributionService Provides a variety of feeds (rss, atom, ...) that can serve as an integration point for "pull-style" systems that want to integrate with Matterhorn using any of the feed related technologies. This service might need to be stateful in that it keeps the latest x media and metadata files so that it is able to create the feed. Alternatively, the feed could refer to a storage location that has been called using the LocalDistributionService and use the matterhorn search service to gather the relevant feed data. Channel Configuration ======Since one matterhorn installation might serve various organizational entities with differing distribution channels, the services need to be configurable with respect to mountpoints, channel ids and authentication credentials. This also means that there might be many instances of a distribution service running, using the same implementation but different configuration data. DEPRECATED Documentation Organizational principles: Use short, declarative, active phrases. Incorporate citations and links into the text. Use role-based guides (do this, do that). All tags are inherited in this tree. (highest to lowest) Documentation GUIDES (TAGS: GUIDE) Get Started (tags: get_started) See Matterhorn Install Matterhorn Develop (tags: develop) Overview (tags: overview) High-level Diagrams Technologies (tags: technology) Java JAXB JAX-WS JAX-RS Build Maven Maven Plugins Ant Runtime Felix Media Analysis OCRopus Sphinx-4 Metadata Dublin Core MPEG-7 Architecture Schedule Capture Ingest Process/Encode Distribute Engage Tools (tags: tool) Matterhorn SVN Repository Eclipse IDE Jira Crucible Service Oriented Architecture (tags: soa) Overview Concepts Terminology Service Design Process (tags: process) Common Agile Software Development Licenses Management Releases REFERENCE (TAGS: REFERENCE) Components (tags: component) Alphabetical List (generated from tags: service, other, draft, approved) Services Other Teams Common Services UIs Other Drafts Capture Services UIs Other Drafts Distribute Services UIs Other Drafts Engage Services UIs Other Drafts Process/Encode Services UIs Other Drafts Schedule Services UIs Other Drafts BA-UX (tags: ba-ux) Alphabetical List (generated from tags: comparative_analysis, draft, approved) Comparative Analyses Teams Common Comparative Analysis Related Documents Capture Comparative Analysis Related Documents Distribute Comparative Analysis Related Documents Engage Comparative Analysis Related Documents Process/Encode Comparative Analysis Related Documents Schedule Comparative Analysis Related Documents DEPRECATED Media Capture and Ingest The end result of the scheduling and capture components is to create new media packages that are managed by the Media Package Service. Internal server error DEPRECATED Media Distribution Media and metadata are distributed to the Engage and other (e.g. youTube) channels via calls to the Distribution Service. The Distribution Service maintains records of each distribution event, so for any given media package, we can resolve the links between a media package and the destination where the media and metadata were distributed. Internal server error A Java-based distribution service implementation may make use of the Workspace API to improve performance and possibly simplify the programming model (though this latter claim is still under discussion): Internal server error DEPRECATED Media Processing Media processors and analyzers access source media and/or metadata from the URLs specified in a media package. New tracks, metadata catalogs, and attachments may be uploaded to either the Matterhorn or 3rd party repositories, then added to the media package via the media package service. MEDIA PACKAGE SERVICE Matterhorn's processing services operate on Media Packages. A media package contains a set of related media tracks, metadata catalogs, and attachments. Here is a sample media package: Sample Media Package XML Media packages are stored and accessed separately from their content. This allows Matterhorn services to: 1. Access and operate on media stored in any location available via URL 2. Store any output, whether it is media, metadata, or something else entirely, at any location that is URL addressable. The Media Package Service manages media packages themselves, but not the underlying content. In order to store arbitrary files to reference in a media package, a Matterhorn service may utilize the Repository service. REPOSITORY SERVICE The repository service provides arbitrary file storage to other Matterhorn services. Files are stored and accessed via the standard HTTP verbs GET and PUT. WORKSPACE API The workspace API is essentially a cache that allows an application server to access files referenced in a media bundle as if they were in local storage. Local file access is a requirement for 3rd party command line tools (e.g. ffmpeg) to operate, and the workspace API provides that kind of access. Another advantage of utilizing the workspace API is that, when a previous service call accesses media, metadata, or attachments at a given URL, the next service call need not download the file again. Depending on how development proceeds, we may add more functionality into the workspace API to handle checkin / out, locking, synchronization, or any other kinds of coordination with the media package repository. Internal server error See DRAFT Workspace API Requirements USAGE EXAMPLES Lecture capture 1. A capture device records the VGA output and video from a lecture. 2. The capture device uploads each of the media tracks and metadata catalogs to Matterhorn's repository service, getting a URL back from the repository service for each successfully uploaded file. 3. The capture device calls the media package service, asking it to create a new media package for the media and metadata URLs obtained from the repository. Since the capture device knows the details of the recording, it can provide the technical metadata needed by the media package service. Encoding 1. The encoding service is called with parameters indicating that the first track in a specific media package should be transcoded to h.264. 2. The encoding service calls the workspace API to get a file handle. If the file does not exist in the local workspace, the file is downloaded. 3. The encoder transcodes the file and temporarily stores the resulting h.264-encoded file locally. 4. The encoding service uploads the h.264-encoded file to the repository, obtaining a URL for the file. 5. The encoding service calls the media package service to add the new track to the media package. 6. The encoding service calls the notification service to indicate that the encoding task is complete. Using an external repository 1. A yet-to-be-conceived service (we'll call it "Foo") needs to transcode media. The Foo service does not have permission to utilize the Matterhorn repository for storage, so it stores the media on its own web server, http://fooweb/. 2. The Foo service creates a new media package via the media package service. This media package points to media and metadata stored on http://fooweb/. 3. Foo calls the encoding service with parameters indicating that the first track in a specific media package should be transcoded to h.264, and that the output of the media should be put back onto http://fooweb/. This means that http://fooweb/ must implement the RESTful service contract defined by the Repository service. 4. Foo should also implement the notification service contract and pass its own notification endpoint to the encoding service. This will alert Foo when the encoding process is complete. DRAFT Workspace API Requirements Store millions of files in a flat namespace Key the md5 of the URL to directories: 6d535f61a1b31a3edeb01be0951a2b4e would be stored in directory /6d/53/5f Support concurrency If a service call is currently downloading a file, the next call will merely wait for the first download to complete Support LRU semantics Check the size of the download via an HTTP HEAD request, parse the "Content-Length". If there is insufficient space to store this file, remove the least recently used file(s). This must be synchronized, since multiple downloads starting at once could fill up the disk before the downloads complete. Questions from Chris: 1. What happens when disk space is used up? The system should fail gracefully and report the appropriate result. 2. Is it useful to have different notions of permanence (e.g. in between encoding operations) and performance (e.g. memory backed files) for encoding? We have both high speed disk and temporary ram drive space. The latter is much smaller, but is nice to make available to apps that need to be constantly seeking through a file (e.g. we have image characteristic functions that may be able to use this capability). 3. If we assume everything is parallel, and that the workspace api can create multiple workspaces for different encoding jobs, what does it mean if workspace room is requested by an encoding process but is not available (does the process fail, or does it wait until room is available)? 4. Can I grow a request for more workspace? Is space only on a "per external file" request, or do I essentially get a chroot jail for my script with quotas? DEPRECATED MediaAnalysisService Performs a number of time-based analysis operations, e.g. speech-to-text, upon media files. Eventually, this service should be split up among each of the separate analysis steps. For now, they must remain bundled within a single service due to time constraints. Operation Return Exception(s) Desctiption Type listTasks() String[] Returns a list of supported analysis tasks ("speech to text", "ocr"). analyse(MediaPackage, MediaPackage Downloads and processes tracks from the media package according to the processing instructions and uploads the OutURI, (via results to the location specified by OutURI, then makes a callback to the NotificationCallback. Note that this method ProcessingInstruction, asynchronous can only produce a single output file, which is stored via HTTP PUT to OutURI. ProcessingInstructions contain NotificationCallback) callback) information on the encoding profile as well as which track to use. DEPRECATED MediaComposerService Composes new media files from a variety of tracks, metadata files, and processing instructions. Operation Return Exception(s) Desctiption Type listProfiles() String[] Returns a list of supported (hardcoded) profiles like "flash.http", "flash.rtmp", ... compose(MediaPackage, MediaPackage Downloads and processes tracks from the media package according to the processing instructions and uploads the OutURL, (via results to the location specified by OutURL, then makes a callback to the NotificationCallback. Note that this method ProcessingInstruction, asynchronous can only produce a single output file, which is stored via the protocol specified in OutURL. For instance, if the protocol NotificationCallback) callback) defined by OutURL is http:// , an HTTP PUT is used to store the file. If file:// is the protocol, the file is delivered via a filesystem copy. ProcessingInstructions contain information on the encoding profile as well as which track to use. Trailer, bumper, trimmig, censoring, watermarks etc. are defined in the media package "storyboard" section. This has yet to be fully specified. Figure 1: The Matterhorn Conductor, which is part of the lecture capture system and is not intended as a generic workflow service, uses the Composer just as any other client would: a MediaPackage is sent to the Composer, which generates a new media file, stores that media file at the specified URL (via HTTP PUT, file copy, etc), and returns an updated MediaBundle to the specified callback handler. Internal server error DEPRECATED MediaIngestService The Media Ingest Service supports the lecture capture system. This service supports two different styles of ingest: 1. a "thick client" style where the client creates a skeletal media package in XML and then calls addMediaPackage(MediaPackage). This is called the "thick" client because it requires that the client knows the xml structure of a media package. 2. a "thin client" style where the client calls createMediaPackage() to create a media package ID, then individually adds the files to be included in the media package via the addMediaPackage* operations. Once the client creates and optionally adds files to the media package, the ingest operation begins the process of analyzing and transferring the files to the DEPRECATED WorkingFileRepository. Due to the tight coupling between the MediaIngestService and the WorkingFileRepository, these services are neither intended for use by 3rd party applications, nor are they required to make use of the rest of the services. Operation Return Type Exception(s) Desctiption addMediaPackage(MediaPackage) MediaPackageID InvalidMediaPackage A client constructs the media package XML, passes it to this operation, and receives a MediaPackageID to use with the media package. createMediaPackage() MediaPackageID When using the "thin client" operations to ingest files, a MediaPackageID is required. This operation creates a new media package and returns the media package ID for use by the addMediaPackage* operations. addMediaPackageTrack(URL, MediaPackageElementID Adds a media file, optionally accepting an ID for this element. The ID is returned MediaPackageID, regardless of whether one was passed in or not. [MediaPackageElementID]) addMediaPackageCatalog(URL, MediaPackageElementID Adds a metadata catalog, optionally accepting an ID for this element. The ID is MediaPackageID, returned regardless of whether one was passed in or not. [MediaPackageElementID]) addMediaPackageAttachment(URL, MediaPackageElementID Adds an attachment, optionally accepting an ID for this element. The ID is returned MediaPackageID, regardless of whether one was passed in or not. [MediaPackageElementID]) ingest(MediaPackageID, MediaPackage (via Moves the files to the file repository. Once complete, the MediaPackage is returned to NotificationCallback) asynchronous callback) the specified Notification Callback handler discardMediaPackage(MediaPackageID) null Removes all files related to a media package from the temporary ingeste filestore Figure 1: The two options for using the Media Ingest Service, and how this service relates to the other Matterhorn services. Internal server error DEPRECATED MediaInspectionService Inspects a media file to determine its technical metadata (duration, codec, etc). Although this can be done using a variety of desktop tools, each tool gives slightly different information for a given media file. Providing a service allows a variety of clients to use the same software to determine the technical metadata for all media files. Operation Return Type Exception(s) Desctiption inspect(URL, NotificationCallback) TrackInformation (via asynchronous callback) Downloads and inspects the file and returns the track portion of the manifest. TrackInformation An entity that describes the technical metadata for a media file, for example: DEPRECATED NotificationService This service describes a REST-based callback mechanism. It is intended to be implemented by service endpoints that need to accept callback notifications from long-running operations. Operation Return Type Exception(s) Desctiption receiveNotification(MediaPackage) null InvalidMediaPackage Receives notification of a change to a media package. DEPRECATED Service Candidates On this page: Service Candidates Cross-cutting Services Administration Scheduling & Capture Processing Distribution Engage Entities Media Package Distributable Media Other Services Inspired by Deviant Scenarios (for future development after year 1) References Service capabilities & operations should be listed underneath each service or on a separate page for that service. They often be thought of as questions that the application (or other consumer) needs to have answered. SERVICE CANDIDATES Cross-cutting Services Services which may be used by multiple teams. The team primarily responsible for the services in this section indicated in bold. Authentication Service (basic only) Provides access to the current user. Implementation(s) are to be determined. Since authorization is not a pressing concern in the beginning of the project, the authentication service may also be postponed. Logging/Audit Service -> (Open question: MH-221) Search Service(s) The media portal needs a search service, for instance, to support searching from the engage tool(s). The implementation of the engage search service may rely on a global search service. Any search services will be able to index whatever text is provided with the media - both static (e.g. dublin core) & isochronic metadata) NotificationService A service to accept asynchronous callback notifications from long-running processes This could be handled via a message bus (e.g. JMS) but that take the functionality out of the service contracts Use case: the workflow service implementation will also provide a notification service so it can keep track of long-running jobs as they fail or finish. Not sure if this means another notification service is unnecessary. Administration Configuration Service - configures the application so it is ready to use. Josh thinks this adds unnecessary dependencies between services, so shouldn't be done. Reporting Service - provides reports to the administrator. Josh doesn't understand the requirements that this is supposed to service. Scheduling & Capture CaptureAgentService Gets the schedule for a location -> is this just handled by Bedework (e.g. just a simple Bedework's impl of caldav/ical)? Do we need to define a separate services around calendaring & scheduling? Gets the capture agents in a given location Processing ConductorService Provides workflows for the lecture capture system. This is not a general purpose workflow engine (hence, we did not name this "Workflow Service"). Rather, it provides access to workflow definitions, the ability to initiate new workflow instances, and various management operations upon workflow instances. WorkingFileRepository Any number of repositories are supported, since MediaPackages simply reference URLs, but this is the default file storage repository that the lecture capture system uses (including the MediaIngestService and the Conductor Service). MediaIngestService, ConductorService, and WorkingFileRepository are all "Lecture Capture Specific" services with more coupling than the rest of the services. Open question: which protocols need to be supported? We could implement PUT, GET, and DELETE via HTTP, similar operations over FTP, SCP, etc. MediaInspectionService Determines technical metadata for a media file. MediaIngestService Supplies ingest capabilities to the lecture capture system and starts a new workflow in the Conductor service. MediaComposerService Composes new media files based on existing media files and metadata. In addition to transcoding, the Composer can add text tracks to media containers. MediaAnalysisService indexes media to extract text inside a video. Uses information provided by speech to text & captioning services CaptionConversionService (Open question: MH-214) Converts MPEG-7 files to any supported output format (e.g. QTtext) ArchiveService Provides long-term storage and retrieval of MediaPackages and their associated media, metadata, and attachment files AuthoritativeAnnotationService Generates an MPEG-7 file from simple time-based text annotations SiteIntegrationService Provides access to local information, such as locations, people, and meeting dates (e.g. lectures). WorkspaceService A local service within the runtime environment that allows for efficient access to file handles from URLs. Distribution Distribution Service - Josh thinks of this as a handoff to the channel, we could include metadata about when it expires for the distribution channel to consume, but we probably wouldn't handle expiring the media from the distribution channel later BOUNDARY Distribution service likely keeps track of channel requirements (e.g. must be Flash, point to RSS feed) Reporting Service - will be a bottom up analysis - will filter up from what the dist. channels are able to provide - aggregating data across the distribution channels and providing a report (??) Engage Player Service candidates User Generated Annotation Service (Engage) bookmark (within media) Tag (within media) user transcription (could include translation) notes In addition to being public, most all of these things can also be personal *or* shared within a group, but we will not handle either of these things until year 2 (because that's when we'll have the "authorization" that would be required to handle this) Media Access Search Statistics/Reporting Service - report stats based on media tool/player interaction with the media. Operation: show popular segments Search Service Search static metadata across webcasts Search isochronic metadata (within the media) - searching/rank based on stats with a single webcast across webcasts ENTITIES Media Package a manifest or 'at a glance' 'table of contents' file containing metatdata and pointers to all relevant files associated with a recording or playlist, which may include: text tracks metadata attachments (ppt) feeds VGA video audio teleconference can be one or more media packages per single recording (open question: are the source media are all part of one media package, while a trimmed version would be another, or do tracked versions remain in the same media package?) allows view (only) access to all the different services that act upon it two types of media: distributed and pre-distributed (which is more 'raw' and unprocessed). the media package concept may apply only before the media is distributed. After distribution it may not be a media package (though the distribution service should track the relationship between distributed media and the media package) - see Distributable Media below.' Distributable Media OTHER SERVICES INSPIRED BY DEVIANT SCENARIOS (FOR FUTURE DEVELOPMENT AFTER YEAR 1) Distribution YEAR 2: statistics (distributed media) - aggregating stats across across distribution channels to provide a reports Engage Embed media player (a service to bring in a media player into another website or application) potential year 2 potential inputs: Type of player, URL of media, streaming/progressive download REFERENCES High-level Activity Diagram DEPRECATED Distribution Service Ideas from Alex Rosen/Momentum SI on a potential structure for the Distribution Service: My expectation for the distribution services is that there would be a DistributionService which is a business service that take an order for distribution. That service would include logic about which distribution channels to use (such as business rules on lowest cost options or rules on the types of content that go to specific channels). The DistributionService would then invoke a DistributionPartnerService which might have operations like PostMediaToITunes and PostMediaToYoutube. That service does not have business logic but instead focuses on the translation from our view of the world to the partner's view. We might actually break DistributionPartnerService into DistributionViaItunesService and DistributionViaYouTubeService. That would allow us to only adjust a single service when one of our partners adjusts their interface. The key point is that we have isolated most of our software from changes in our partner's interfaces. DEPRECATED Editing Service Note: Editing is distribution-channel agnostic. Processing's actions are dependent on the distribution channel's capabilities. Capabilities Year 1 Specify trim points (e.g. using timecodes) Delete media segments Replace Media Group This refers to any Media Group currently persisted in Matterhorn's 'working' repository) Open question: is the 'archive' repository 'in Matterhorn'? Add Media File (does this make another version of the Media Package?) Replace Media File (does this make another version of the Media Package?) Add Captions (really just a specialized way to merge a/v, vga, etc. track(s) with the text track) Add/Edit Media Package metadata Add/Inject metadata into Distributable Media (this may need to be moved since its distribution channel specific) Apply intro/outro Apply watermark Note: We've decided that Branding is just a form of Editing, therefore have not separated it out into its own service. Future Adjust audio levels Adjust color/hue Choose audio channel (e.g. l, r, or stereo) Add/replace tracks (e.g. audio, video, or VGA) Merge tracks Split media into independent segments (create a playlist) - this becomes a new Media Package Generate thumbnail for Media Package Generate image for Media Package Synch tracks Apply a visual template (I think this would be to a Media Group, not a Media Package?) DEPRECATED Encoder Service Instructional notes for this template are in blue and preceded with the icon. Remove instructional notes and this note before publishing. Encoder Service Unknown macro: {html} Name EncoderService Version Release Notes/History Based Upon If based upon another service (e.g. a Kuali Student service), link to that service here. | Description | Classifications | Assumptions | Dependencies | Security Requirements | References | Operations | Description Enter a concise description of the service here. Classifications Service Type (e.g. Business Service) Service Domain (e.g. Distribution -> iTunesU) Assumptions List any assumptions on which this service is based here. Dependencies List any services or entities which this service uses, and is used by, here. Security Requirements Explain any security requirements for this particular service here. References Source Code JavaDoc Operations Write encode Write">Write Method encode Description Encodes media and (optionally) periodically alerts a statusService endpoint of the status of this encoding job. Parameters PathIn string Path to the media file. PathOut string Path to the location where the encoded media file should be placed. StatusServiceEndpoint string Endpoint to notify about the status of the encoding job. Return StatusMessage TBD Errors DOES_NOT_EXIST validationTypeKey not found INVALID_PARAMETER invalid validationTypeKey, XInfo MISSING_PARAMETER missing validationTypeKey, XInfo OPERATION_FAILED unable to complete request Dependencies List any dependencies on or assumed by this operation here. Reference Artifacts Link to any artifacts used to define the operation here. This may include workflow, swimlane, or entity diagrams, user stories or use cases. Notes Notes may include constraints, transactional properties of an operation, questions, comments, or other notes. Back to Operations DEPRECATED Media Package Entity This page needs to be re-drawn to show what the media package entity looks like now. The current version (including the XML) can be found here: https://wiki.opencastproject.org/confluence/display/open/MediaPackage+Manifest Internal server error DEPRECATED SiteConductorService This service is the place to implement service orchestration for the lecture capture system that is using many of the other services. It is also the proper location to add business rules according to your local needs (hence the Site in the service name). Operation Return Type Exception(s) Desctiption DEPRECATED SiteIntegrationService Provides access to local information, such as locations, people, and meeting dates (e.g. lectures). Operation Return Type Exception(s) Desctiption TODO Review REPLAY interfaces. If acceptable for use across a variety of institutions, expose the interfaces as REST / WSDL with XML entities. DEPRECATED WorkflowService Conducts services to accomplish a larger goal, such as "capture, process, and distribute media". Operation Return Type Exception(s) Desctiption listWorkflowDefinitions() String[] Clients wishing to initiate a new Workflow must provide a valid WorkflowDefinition. This method provides all known WorkflowDefinitions. findWorkflowsByState(State) List findWorkflowsByMediaPackage(MediaPackageID) List findWorkflowsByTitle(Title) List findWorkflowsByAuthor(Author) List findWorkflowsBy(Namespace, Field, Value) List findWorkflowsByRange(Namespace, Field, Lower, List start(WorkflowDefinition, MediaPackage, List stop(WorkflowID) suspend(WorkflowID) resume(WorkflowID) findWorkflowsByDate(Begin, End) List getNotifications(WorkflowID) List The Working File Repository is a RESTful file storage service that supports the lecture capture system. It may be used by other clients, but is neither intended nor required to be used by other systems. Operation Return Type Exception(s) Desctiption put(MediaPackageID, 200 OK 403 Forbidden, 5xx Server Puts an arbitrary file into the repository. The file is accessible via GET MediaPackageElementID, URL) Error /MediaPackageID/MediaPackageElementID get(MediaPackageID, 200 OK with file download (how is the 403 Forbidden, 404 Not Returns the file stored under this MediaPackageID and MediaPackageElementID) mime type determined?) Found, 5xx Server Error MediaPackageElementID delete(MediaPackageID, 200 OK 403 Forbidden, 404 Not Deletes the file stored under this MediaPackageID and MediaPackageElementID) Found, 5xx Server Error MediaPackageElementID DEPRECATED WorkspaceService An osgi-local (non-remote) service that allows clients to efficiently access java.io.File objects from potentially remote URLs. This prevents different service implementations running in the same osgi container from downloading remote files multiple times. Additionally, when the system is configured to use shared storage, this performance gain is also achieved across distributed osgi containers. The methods from WorkingFileRepository are also available as a convenience to clients. Operation Return Type Exception(s) Desctiption get(URL) java.io.File Returns the file handle for a given URL put(MediaPackageID, 200 OK 403 Forbidden, 5xx Puts an arbitrary file into the repository. The file is accessible via GET MediaPackageElementID, Server Error /MediaPackageID/MediaPackageElementID (delegates to WorkingFileRepository) URL) get(MediaPackageID, 200 OK with file download (how is 403 Forbidden, 404 Not Returns the file stored under this MediaPackageID and MediaPackageElementID MediaPackageElementID) the mime type determined?) Found, 5xx Server Error (delegates to WorkingFileRepository) delete(MediaPackageID, 200 OK 403 Forbidden, 404 Not Deletes the file stored under this MediaPackageID and MediaPackageElementID MediaPackageElementID) Found, 5xx Server Error (delegates to WorkingFileRepository) DEPRECATED - Release 0.5 ~ Deliverables (Aug. 09 - Jan. 10) Break down of deliverables by quarter. Admin Tools Release 0.5 (Aug. 09 - Jan. 10) Q1 (AUG. 09 - OCT. 09) Q2 (NOV. 09 - JAN. 10) Admin Tools Admin Tools Job Controller UI Job Controller UI List of all distributed episodes View jobs by date/time/type Integration with download and streaming servers View successful/unsuccessful ingest job. View sucessful/unsuccessful encode job. Ingester UI View successful/unsuccessful distribution to the MMP. Upload replacement video/audio and rerun job Upload a video/audio file Manually enter "basic metadata" Ingester UI Manually submit metadata file View progress of upload Scheduler UI Upload caption file Upload branding materials Add recurring event for scheduled recording Edit recurring event for scheduled recording Scheduler UI Delete recurring event for scheduled recording View event in personal calendar via icalendar feed Enter metadata for event Bedework osgi implementation Iteration II (Aug. 1-31) Logging/reporting form standardized (buy-in cross-project) and service api developed Admin Tool Story Cards View list of currently scheduled events Expected Deliverables: MH-132 "Go with Bedework for scheduling" - As a project manager I need to pick an appropriate calendaring option so customization of it to Matterhorn can continue. MH-494 Create Rev1 Ingest UI -Single Upload & Basic Metadata Entry (to Repository Service) MH-267 As an administrator, I would like to specify a language so that the UI is in my native language. Open Questions: MH-338 How does unit testing work for JavaScript/Ajax components and how is it integrated into the build? MH-672 Where do the UIs reside in Matterhorn? Iteration III (Sept. 1-18) Expected Deliverables: MH-598 Create metadata updating OSGi service stub MH-609 Create js library for creating media packages MH-614 Bedework included in build process "Upload Attachments" "Upload Multiple Media Files" "Enter Metadata without Uploading Media" "Scheduler supporting recurring events" "Finalize Xprops" and Xprop representation in Bedework Open Questions: MH-671 How is data persisted for the Admin App pre and post distribution? MH-673 What does it mean to do CRUD operations on a uploaded or recorded file? Engage Tools Release 0.5 (Aug. 09 - Jan. 10) Q1 (AUG. 09 - OCT. 09) Q2 (NOV. 09 - JAN. 10) Engage Tools Engage Tools Media Player and MMP Engage Tool Story Cards Play/Pause/Stop video/audio (basic media player) Media Player and MMP List of all distributed episodes Integration with download and streaming servers View list of available feeds Search media files (full text - non-isochronic) Iteration II (Aug. 1-31) View Captions for audio/video Embed player in blog Engage Tool Story Cards Expected Deliverables: MH-622 Basic accessible Videoplayer (Play, Pause, Stop, Slider) MH-576 Define testing strategy for Flex MH-674 Progressive Download Service MH-675 Media Streaming Service Open Questions: See Admin Tools open questions Iteration III (Sept. 1-31) Expected Deliverables: "Search static metadata" "Distribution service for MMM" "Support Captions in video" Capture Release 0.5 (Aug. 09 - Jan. 10) Q1 (AUG. 09 - OCT. 09) Q2 (NOV. 09 - JAN. 10) Capture Team Capture Team Clean up missing components on MH-73: Provide capture "By-request" capture appliances available for capture hardware for capture test environments. testing. captures "right now" Expand hardware profiles covered (specifically, native h264 Validate capture packages (sync, etc.) capture and dv) Create media packages from capture Capture client can subscribe to iCalendar feed Start/stop capture client (no UI) Ingest a media package Gstreamer toolkit and language bindings (e.g. java) for 0.5 Log/Report capture activity release Candidate list of x-props Skeletal reporting api from capture/schedule perspective (at least a couple of #proposals) Iteration II (Aug. 1-31) Expected Deliverables: MH-73: Provide capture hardware for capture test environments. MH-46: Choose best video capture card and best language gstreamer framework for the chosen formats. Open Questions: Unfinished; what is the difference between capture metadata and overall metadata? MH-133: As a developer I need to determine which metadata strings need to come from a configuration service, and which might be static Iteration III (Sept. 1-31) Expected Deliverables: MH-70: As an external component I need to start a capture immediatly (service description and innitial implementation) MH-133: As a developer I need to determine which metadata strings need to come from a configuration service, and which might be static Open Questions: Distribution Services Release 0.5 (Aug. 09 - Jan. 10) Q1 (AUG. 09 - OCT. 09) Q2 (NOV. 09 - JAN. 10) Distribution Services Team Distribution Services Team FeedDistributionService RSSiTunesUDistributionService LocalDistributionService YouTubeDistributionServices (tentative) Channel Configuration (tentative) Iteration II (Aug .1 - 31) Distribution Story Cards Expected Deliverables: MH-664 LocalDistributionService Design Draft MH-665 YouTubeDistribution Service Design Draft Open Questions: MH-506 As a developer I need to know the path to local storage is passed to the distribution service so that I can distribute files to local storage. MH-669 Where are the local distribution and rss feeds hosted OOTB? Iteration III (Sept .1 - 31) Expected Deliverables: "LocalDistribution Design/Impl" Achitecture and Process Services Release 0.5 (Aug. 09 - Jan. 10) Q1 (AUG. 09 - OCT. 09) Q2 (NOV. 09 - JAN. 10) Arch/Process Services Team Arch/Process Services Team Service and architecture documentation CaptionConversionService Setup testing infrastructure MediaAnalysisService MediaIngestService WorkingFileRepository DistributionService API ConductorService MediaIngestService WorkspaceService MediaInspectionService MediaComposerService Iteration II (Aug .1 - 31) Architecture and Process Services Story Cards Expected Deliverables: MH-362 Establish media inspection service MH-355 Establish media ingest service MH-402 Establish media package Open Questions: MH-279 Do we need pub/sub, or is point-to-point messages sufficient? Iteration III (Sept . 1 - 18) Architecture and Process Services Story Cards Expected Deliverables: MH-421 Add distributed event admin service bundles MH-376 Establish composer service Usage Requirements The current list of requirements, referred to as "Story Cards", are documented and maintained in the Opencast Jira project. Anyone is welcome to browse these story cards to see what features are being planned for Matterhorn 1.0. For archive purposes, there are also two previous versions of a requirements listing available below. Requirements gathered from Summer 2008 Workshops Requirements proposed in April 2009 grant proposal Potential User Interfaces Proposed Matterhorn Requirements Requirements from Face-to-Face Meetings File Modified No files shared here yet. Drag and drop to upload or browse for files Potential User Interfaces The following list is a simplification of the "infamous" green dots from the Matterhorn in-person meeting which indicated that there was a user interface associated with a story card. In iteration 1 the BA/UX team is completing a competitive analysis of engage and admin tools. When they're finished, the plan is to start work on low fidelity designs in iteration 2. In terms of what is in scope for release 0.5, imo, we need at least: an ingest UI to submit content. Matterhorn Media Player (simple player for now) Simple functionality to schedule events for capture. Basic way to indicate the success or failure of a workflow/capture. Of course we'd be in much better shape if we had more features in place by 0.5, but this seems to be the bare minimum. Login users can log in to the admin screen. Capture/Scheduling add/delete/edit an individual event add/delete/edit a recurring event specify classroom (recording devices) specify capture type (audio/video/screencast/etc.) edit event title edit information assoicated with event (TBD) Job Monitor success/failure/in progress of job (capture, encode, distribution, etc.) capture device feed (ensure audio, video feed works) Job Center see the jobs that I ran (status) see job details (workflow with dates/times, metadata) edit job details (metadata) re-run a job Ingest manual upload of media (video, audio, powerpoint, etc.?) manual upload of captions* manual upload of metadata* manual entry of metadata fields (TBD) specify workflows (TBD. ex. chaptering + iTunes + video) specify encode quality and types* specify distribution channels* specify branding* *could be abstracted as workflow type Matterhorn Media Portal search media files search within media files navigate within media files (chaptering) support for captions media player atom/rss feeds these seem to be the basics already avail through virtpresenter. still an openquestion whether we'll offer features common in a distribution channel such as http://opencast.mirocommunity.org. such as most popular videos, share embed, add to social network, comments, etc. category browser Proposed Matterhorn Requirements *** ARCHIVE DOCUMENT *** For the current listing of requirements for Opencast Matterhorn, vist the Opencast Matterhorn Project in Jira. This page contains basic use cases, business and technical requirements proposed for the 1.0 Matterhorn Release in the grant proposal. The basic use cases list found on this page represents baseline functionality, but these use cases are unlikely exhaustive. We hope the community will provide additional requirements and/or applications. Preparation Phase Specify whether scheduled recording should be automatically captured, captured on site manually, or initiated by lecturer/presenter Pre-populate recording schedule from import of campus registrar data (This data will need to be provided by an institution's IT administrator in a specific format) Add/Update/Remove capture locations and their supported capture capabilities (i.e. video, screencast, audio) Enter manually individual or recurring recordings based on date/time/location Specify start/stop offsets for individual or recurring scheduled recordings Specify institution wide exclusion dates (i.e. holidays, midterms) for a given time span Administrator Login/Logout Choose locale (internationalization) Specify bitrate, framerate, frame size, codec, and wrapper for scheduled recording(s) Capture Phase Report media feed connection status Report successful start, in process, and stop of capture Report capture failure of media feed(s) As a presenter] start, stop and pause capture Specify bitrate, framerate, frame size, codec, and wrapper for scheduled recording(s) Preview samples of captured video and audio Report appliance connection status Automatically upload captured recording(s) for Matterhorn media pipeline ingestion Report storage status Initiate capture via cached schedule Cache previous recordings for specified time period Processing Phase Remove media segments from existing media Add custom branding intro/outro to audio/video Select specific audio channel from stereo recording for mono audio Increase/decrease audio levels Split media into independent segments Edit metadata associated with media Unpublish media/metadata from distribution channel Unpublish media/metadata from distribution channels Initiate workflow specified for media/metadata Report capture failure of media feed(s) Utilize an existing open source, standards-based workflow engine Tools that enable closed captioned media Insert new media into existing media Support specified business processes for Matterhorn 1.0 media life cycle Automatic media chaptering Specify bitrate, framerate, frame size, codec, and wrapper for scheduled recording(s) Manage access based on authorized actors Serve as a temporary repository for storing media before it is distributed Store automatically captured media, manually submitted media, attachments, and metadata Provide content access to each of Matterhorn's services Watch ingest folder Report in queue, start, in process, and completion of encoding Report encode failure Inject metadata into media container Apply default branding intro/outro to media Apply default watermark to video View preview media Report success, failure, in process status for un/publishing Report storage status for distribution channel(s) (i.e. un/used storage) Add/Update/Remove distribution type and channel Define distribution type and channel Video OCR metadata extraction Indexing static, dynamic, and user generated metadata Metadata packaging to standard format Usage Phase Play/Fast Forward/Rewind/Pause/Stop media Discovery of distributed media based on static metadata. (ex: lecture, department, professor, date, distribution type, screencast text, licensing/copyright, etc. --need to define) Choose chapter within audio/video Find specific segment within audio/video by keyword Provide the statistical feedback for each distribution channel (i.e. most viewed, most downloaded) Insert new media into existing media Discovery of distributed media based on captioning and annotations Discovery of distributed media based on dynamic/isochronic metadata from media analysis Combine viewed and downloaded stats across channels Support UI localization Requirements from Face-to-Face Meetings **** ARCHIVE DOCUMENT *** For the current listing of requirements for Opencast Matterhorn, vist the Opencast Matterhorn Project in Jira. What follows is a combined, distilled list of requirements that were generated during the requirements gathering/prioritizing activities conducted at the 3 meetings (Cupertino 10/2007, Berkeley 6/2008, and Oxford 7/2008). Each group of participants began with a blank slate and brainstormed requirements of the proposed Opencast system based on the needs of their institution. Participants then ranked and prioritized this list. The list below was developed by choosing those requirement ranked with the highest number of blockers, dittoes or priority. Redundant requirements were eliminated. We found several of the requirements were better represented as general principles (e.g. "easy-to-use interface") that should be applied across the board. We pulled those and listed them separately in the General Principles section. GENERAL PRINCIPLES Leverage a variety of centralized IT resources: Opencast will have the ability to leverage the institution's existing IT infrastructure, including: Authentication Learning Management System Data Systems (e.g. student info, registrar) Platform preference Sustainable, scalable IT infrastructure Leverage open source technology when available Standards-based: The Opencast system will be based on standards wherever possible, such as: Media formats Level of media quality Tagging formats (e.g. delicious style) Metadata format (e.g. RDF format) Citations format (e.g. Latex/Bibtex) Ease of use: Opencast will be easy to use for faculty and students, including the following components: Minimum interference with the instructor's teaching Multiple User Interfaces, depending on the role of the user, so that they only see what they need Published, accessible technical documentation ** Well-documented code Community-generated tutorial repository FUNCTIONAL REQUIREMENTS Infrastructure Ability to integrate with institutional authentication system Ability to integrate with and leverage existing LMS Ability to integrate with institutional data Roles-based distributed administration/clearly defined roles Flexible and expandable storage Flexible and expandable bandwidth Ability to work in a clustered server environment Ability to support different media capture devices and methods Open APIs Ability to support multiple platforms Ability to integrate with post production facilities/tools Versioning of media files and of metadata Provide different pricing models/captured media Policy Support & Participation Management Protect intellectual property Manage releases from students, faculty and presenters Free/open formats (software, standards, licenses) Ability to ensure copyright compliance according to local guidelines/laws Ability to communicate copyrights to end users Provide/incorporate institutional policies regarding rights to publish Define and configure roles according to institutional needs Ensure ADA (Americans with Disabilities Act) compliance Ability to automatically invite instructors to podcast Media capture Automated and scheduled media capture Record on demand, no preschedule Capture lecture with minimum intervention Ability for presenter to control capture (e.g. start, stop, pause) Easy to use, central location to schedule recordings Ability to capture supplemental media Automated course calendar/production schedule Know if my course is in podcast-capable room Highly reliable capturing Upload in batch Feedback on where in the process content is Flexible, multiple and/or simultaneous sources of capture (doc cameras, smart boards, video) Ability to choose type of capture (audio, video, etc.) Ability to upload in multiple formats Automated notification when, where capture is not working Have a master control panel for all capture facilities Metadata/tagging/search Apply standardized metadata to all content Automated and synched metadata from existing data systems (student info, registrar, directories, etc) Update metadata after publishing Updates to metadata propagate through all distribution channels Attribute ownership Delegate support and admin tasks (renaming/fixing metadata) Tag content Collaborative tagging (enable peers/viewers to add tags) Search by transcript Search by slides Find specific parts within a lecture Search across multiple lectures Search across institutions and repositories Navigate easily through content Access to associated content (syllabus, reading list) Versioning of metadata Create ontologies of similar terms Media enhancement Add supplemental media Organize content Able to edit (remove portions, capture subsection) Capture and insert content into existing content Attach additional media (slides, pdf, etc) at specific points in video Automated transcription of audio, synched with video (captioning) Automatic chaptering with slide information Annotate/bookmark specific points in lecture video Add translations (subtitles) Simple media enhancement tools (e.g. adjust brightness, noise filter) Links to university library resources embedded as citations Publishing/distribution Flexibility to encode and publish according to institution's deadlines Integrate with multiple distribution repositories using standardized metadata mappings and open APIs Schedule release of media by date Ability to publish to multiple distribution channels and in multiple formats Ability to unpublish from multiple distribution channels Incorporate media on course page, ePortfolio, marketing Enable privacy, specify and restrict access Manage social network around media Notification when media is available Consuming/reusing media Share specific segments of content with others Embed specific segments into assignments, discussion posts, etc. Link media into course syllabus Ability to organize and create playlist of media for reuse Annotate/bookmark specific points in lecture video Accessible from any device Rate content Best of breed content View same lectures from previous semesters Content subscription model Users can tell which lectures they have seen Know in advance which lectures will be webcast Market programs/events with audio/video Translated content Comparative/juxtapositioning analytic tools Allow learners to provide feedback to the instructor Production & branding Institutional branding Custom branding Self-branding (faculty can put link to own website) Archiving Long term content management formats Archive content indefinitely Archive content in a format that is open/transferable to a new system Ability to choose a media capture format to use Archive source media Statistics Get viewership stats/analytics Performance stats for system Track media capture assets (cameras, VGA, etc) and their usage Understand media use by learners File Modified No files shared here yet. Drag and drop to upload or browse for files DEPRECATED StatusMessage Structure Unable to render {include} The included page could not be found. StatusMessage Name StatusMessage Version Release Notes/History Based Upon If based upon another message structure (e.g. a Kuali Student message structure), link to that service here. | #Description | #References | #Structure Definition | #Example | DESCRIPTION Notes REFERENCES StatusMessage JavaDoc STRUCTURE DEFINITION Type Complex ShortName Name Type Required Cardinality XML Attribute? Comments/Feedback Message string Reference string Source string EXAMPLE Containing element for representation purposes only. DEPRECATED Distribution Team Diagrams Topic Inputs Media Package • Contains links to metadata files and media files Distribution Instructions • Store original as archive? • Store on locally mounted file system? Send to remote service? • Youtube • iTunes U • FTP Outputs Local File Storage • Finds local media location • Moves files from original location Writes metadata to feed • XML files at channel and item level Archive Storage Sends original recording to archive server • Only 1 version of the original recording Remote File Uploads • Uploads media file(s) to designated service • Passes any necessary credentials to the service • Passes any necessary metadata to the service DEPRECATED IngestService IngestService Version Snapshot Classification Data:Administration Team:Media Description A service to augment https://wiki.opencastproject.org/confluence/display/open/_MediaIngestService_. This service uses an asynchronous design pattern, and requires that beginIngest() and endIngest() are called to submit media packages. #todo expand on this CONTEXT Assumptions #todo Service Dependencies #todo Known Clients Capture agents and HTML UI will use this. Security #todo OPERATIONS Name String MediaPackageID ingest(org.opencastproject.media.mediapackage.MediaPackage mediaPackage, java.io.InputStream[] tracks, java.io.InputStream[] attachments) Description Adds a mediapackage with a set of tracks or attachments to be injested to the system. If the mediaPackage contains an identifer that already exists in the system an exception is thrown (this method is not intended to be used to update media package information once it has been set other than to add tracks or attachments). It is legal for tracks and/or attachments to be null. Binary data for tracks and attachments are associated with mediaPackage.getTracks() and mediaPackage.getAttachments() in the order they are provided. #todo: outline exception information Notes This method is transaction based, and should only be called after beginIngest() and before endIngest(). Adding more tracks or attachments such Name String MediaPackageID ingest(String MediaPackageID, java.io.InputStream[] tracks, java.io.InputStream[] attachments) Description Adds tracks and/or attachments to a media package by the package identifier. If MediaPackageID is null then a new org.opencastproject.media.mediapackage.MediaPackage is created and its identifier is returned to the caller. It is legal for tracks and/or attachments to be null. Notes This method is transaction based, and should only be called after beginIngest() and before endIngest(). BINDINGS Replace myservice in the URLs with the new service name in lowercase Type Java JavaDocs http://build.opencastproject.org/apidocs/org/opencastproject/myservice/api/package-summary.html Source http://build.opencastproject.org/xref/org/opencastproject/myservice/api/package-summary.html Type REST Documentation http://nightly.opencastproject.org/myservice/docs WADL http://nightly.opencastproject.org/myservice/?_wadl&_type=xml Type SOAP WSDL http://nightly.opencastproject.org/private/myservice?wsdl