SEARCH
TOOLBOX
LANGUAGES
Create a book
Portal/Design criteria for portal

Portal/Design criteria for portal

From Steeple

Jump to: navigation, search

Contents

[edit] 1 Introduction

The purpose of this page is to describe design criteria for a 'web-based podcast portal'. "Portal" here simply means a tool to display a collection of video or other media: This might be a small collection of video, e.g. on research group or departmental level, it might be a institutional collection (for instance mirroring the iTunesU/YouTube offering of an institution), or it may be a cross-institutional/national/international/subject-based portal.

This portal would be developed as open source, and should have similar functionality to some of the portals mentioned link the links section below (YouTube, etc.). The ambition for the portal software is that it would be used very widely within UK-HE, and possibly HE world-wide. Only if the portal software has a substantial number of users, it will continue to be popular, and will continue to develop.

[edit] 2 Architecture

[edit] 2.1 Loosely coupled with data store (and data processing)

  • Multi-distribution channel paradigm suggests that a portal should be loosely coupled with data store
  • institutional portals may need to combine data from several data services
  • may want to create cross-institiutional portals

The portal should thus be fed from (a set of) media feeds, c.f. Syndication, and also see talks at Oxford and for JANET, linked from Podcasts.

[edit] 2.2 CMS integration

  • A portal would need to integrate with existing CMS solutions.
  • Common CMS solutions are: Wordpress, drupal, joomla as solutions for public web sites.
  • Common solutions for e-learning are: Moodle, Sakai, eduCommons.
  • Ideally the portal would be able to work stand-alone, and as a component to one of the above CMS.
  • Ideally use an existing framework, rather the writing from scratch.

Analysing the CMS integration requirements, php is widely used (wordpress, drupal, joomla, moodle). For Sakai, an AJAX solution might work best, particularly for the inclusion of individual video assets, or smaller groups of video assets. AJAX/javascript can also make for easy integration of smaller groups of videos on other web pages.

[edit] 2.3 Flexible templates

The appearance of the portal would need to be very flexible, using a templating mechanism.

The ambition for the portal software is that it would be used very widely within UK-HE, and possibly HE world-wide. It must therefore be highly flexible in terms of appearance to accommodate institutional requirements.

[edit] 2.4 Supported media formats

At the very least, the portal must support the following media formats:

  • video formats (mp4 family, mov, wmv, rm, ogg theora)
  • audio formats (mp3, mp4 family, mov, wav, aiff, ogg vorbis)
  • Flash applications
  • Text-based formats: plain text, (x)html, pdf. Where possible (text, xhtml), web display should be available, otherwise download.
  • A small, well-defined range of formats (audio+slides, video+slides, that is to say 'composite media items provided in constituent form') should be available for playback online.
    • synchronised playback of audio and slides
    • synchronised playback of video and slides
  • Content packages (common cartridge, etc.). Download sufficient, unless we can easily find appropriate players.
  • links (That is to say: a 'media item' in the portal may just link out to an external player, i.e. the main piece of 'media' for that particular item is just a link)

A particular media item may contain any combination of those media formats. Thus the media feed from which the portal is built needs to be flexible enough to accommodate those formats. (C.f. also Syndication).

[edit] 2.5 Statistics

The portal must provide statistics to content providers.

  • These statistics would need to specifically cover the content provided by a particular content provider. I.e. a content provider can obtain statistics information for their content.
  • Summaries should be available automatically, e.g. by email.

[edit] 3 Accessibility

The portal must meet the broadest possible set of accessibility requirements.

The portal software must have multi-language support, and it must be have good usability.

The portal must respond flexibly to the type of browser used. In particular, it must support mobile browsers.

[edit] 4 End user features

In this section, we list desirable end-user features of the portal.

[edit] 4.1 Basic features

  • Allow playing of (multi-format) media
  • Allow downloading of media
  • Allow subscription to media feeds, at least in rss and atom, for
    • individual items
    • publisher-defined podcasts
    • categories
    • searches
  • Users should be able to leave feedback, that is forwarded to portal operators and content providers. (Not publicly visible.)
  • The portal provides for searching and browsing:
    • Content should be browsable according to metadata categories added to the content.
    • Metadata for content should be searchable
    • Where time-based metadata is available (e.g. transcripts or slide-OCR), searches should return results pointing to specific locations within videos.
  • Social bookmarking
  • Tag clouds

[edit] 4.2 Interactive and collaborative tools

User interaction-based:

  • Users should be able to create their own collections, and subscribe to relevant feeds (with or without login)
  • Users should be able to view their 'trail' through the site, i.e. the things that they have viewed or played
  • Users might be able to see which parts of an item they have watched (cf. Osnabrueck's tools)
  • Blog-like features: Public comments and discussion.
  • Users are able to log in, to make their collections/searches persistent

Collaborative filtering and recommendations

[edit] 5 Marketing

It is important to realise that the portal should have many opportunities for advertising to people the range of material and that areas of the design are primarily marketing focussed to help people find high quality material and for serendipity by the casual viewer.

Functional marketing includes

  • Advert panels for series - e.g New Credit Crunch series
  • Recommendations by staff
  • Top 20 downloads - Global and per subject
  • Top picks - e.g. High profile famous speaker

The marketing panels should ideally be tracked to see how much effect they have on downloads.

[edit] 6 Links

[edit] 6.1 Links on architectural discussion

http://www.opencastproject.org/category/6/26

[edit] 6.2 Links to portals

Portals chosen for consideration of TECHNICAL features, not for CONTENT!

On this page, we're going to collate video/audio web portals, for technical evaluation. So we're not trying to list web pages that have HE video on it, but we're trying to list video/audio web portals, that might be interesting in terms meeting technical requirements for Steeple.

[edit] 6.2.1 Portals running commercial services

[edit] 6.2.2 Portals in HE

For many of these projects, there are descriptions on the http://www.opencastproject.org site.

[edit] 6.2.3 Portal plugins

Retrieved from "http://www.steeple.org.uk/wiki/Portal/Design_criteria_for_portal"