Tender DHP Agency Brief (DOC, 1.42Mb)

1

DIGITAL HERITAGE PROJECT

AGENCY BRIEF

ScreenEast

SE/DHP agency brief 23.2.10

2

1. Project outline3

1.1 Background 31.2 Contacts 4

2. Functional specification5

2.1 Functional overview 52.2 Site structure 62.3 Content management 72.4 User interactivity / comments / upload

82.5 Keyword search 92.6 Timeline functions 92.7 Mapping functions

102.8 Building larger articles

102.9 Language packs

102.10 User login and handling

112.11 Mobile, IPTV and GeoPoint applications

11

3. Technical specifications12

3.1 Video specifications12

3.2 Server / bandwidth specification12

3.3 Compatibility13

3.4 SEO specification13

SE/DHP agency brief 23.2.10

3

1. Project outline

1.1 Background

Screen East (www.screeneast.co.uk) is the regional screen agency for the East of England, dedicated to promoting the film and TV industry in the region, and communicating the value of film and TV to the public.

As part of this work, Screen East works extensively with screen heritage material for research, education and public interest / entertainment. Screen East financially supports the East Anglian Film Archive (owned by the University of East Anglia) where the film collections are held. Given the recent evolution of online video – and a wider project to digitise more of the Archive’s material – Screen East has recognised the need to make archive material more accessible to the public, through a video-enabled web site as part of the Digital Heritage Project.

To facilitate the project’s delivery and secure funding from the INTERREG IV A European pool, Screen East has teamed up with Pôle Image Haute-Normandie (www.poleimagehn.fr), which supports all audiovisual activity around their region. They have been vital in offering technical guidance and will be working extensively with Screen East to achieve our common goals.

While initially the idea of one site to serve both SE and PIHN was mooted, following discussions PIHN will continue to construct and provide their own site and functionality, as this will give them greater access to local government facilities at CRIHAN in France and allow them to create a site more specific to their needs.

However, it is planned to co-ordinate some aspects. For example will run Flash video, for example, use a common screen resolution and ratio. Education programmes will be co-ordinated across the two regions. And it is planned to choose one video editing tool for use by the public (see 2.11 and separate video edit suite tender doc).

SE and PIHN will also share common branding and styling for their two sites. A branding document, comprising logotypes (in English and French), typeface instructions, colours and basic styling guidelines, will be supplied at or about the date of commencement of full build.

SE/DHP agency brief 23.2.10

4

1.2 Contacts

In the first instance please contact:Lance Paterson / [email protected] Technical consultant / ScreenEast

Screen East,2 Millennium Plain,Norwich NR2 1TF

For ref:Jane Jarvis – Screen East / [email protected] manager, Digital Heritage / Screen East

SE/DHP agency brief 23.2.10

5

2. Functional specification

2.1 Functional overview

Any candidate bid should fulfil all of the following functions:

- be attractive, reasonably accessible, searchable, and easy/intuitive to use

- deliver user-friendly video at good download speeds and reasonable quality

- allow content management of the video and material surrounding the video, including but not limited to:

o a full but simple and searchable tagging schemao allow text and pictures to be uploaded to sit beside

video, turning it into a full “article page”o allow geo-tagging and mapping (via Google or Live) so

that clips can be placed in geographical context (eg: jump to modern Street View), and nearby clips displayed

o allow a for a time tag that will place the clip in a relevant historical timeline

- allow moderated comments by users (login required)

- provide a simple suite of social networking tools to allow users to share and link to video

- allow users to form and join groups and forums based around content interests

- allow access via mobile devices and IPTV

The ability for users to upload, and possibly edit, their own clips on the server is currently still under discussion but should be discussed in any candidate bid.

A separate bid document has been issued for an editing suite system that would allow users to edit together or sequence clips for educational purposes. This would be used by both SE and PIHN. Note that while SE are currently planning to use this feature as a site attractor, PIHN’s version of this system will be orientated more as a structured educational tool.

SE/DHP agency brief 23.2.10

6

2.2 Site Structure

As this is envisaged as a fully or partly CMS-driven site (see 2.3), the Topics section and menu could be fully or partly auto-generated. The page and menu based on keywords or keyword groups. If a drop down menu is used, the number of topics available will be limited to avoid visual overload, with a clear invitation to “see more”.

Timelines could be broken down into decades or into relevant periods (eg: birth of film to WW1, 1840-1919, inter-war period 1920-1938, war and recovery 1939-1950…) These could be placed on a “CoverFlow” timeline app, with videos signposted along the time axis.

Places could bring up an interactive (Google?) map screen centred on the selected target area, with videos shown as pins or icons. Selecting one would bring up an info bubble with a link to the clip.

Education would feature a link to the timeline editor / video compiler, historical education sections, and if possible a small film school section looking at the history of film making.

Forums (or Groups) would give people a chance to interact with each other and discuss local history and film, ensuring the site is “sticky” and users have an additional reason to return.

The About tree (and page-base links) would cover all other necessary items like Contact, legals, etc etc.

SE/DHP agency brief 23.2.10

7

2.3 Content Management System

The CMS should allow for the upload of video – and preferably its auto-encoding – by staff, and possibly by users.

Each video should then have its own SEO-friendly display page with the following:

- Video title- Video- Notes and information- Author details if available- Timeline details- Keywords linked to relevant searches for that clip- Mapping function- User comments field and user comments- Tag cloud

Each of these elements should feature on a single edit page for the clip and be as simple as possible to upload and edit. If possible, the video upload itself should also be conducted as part of clip creation.

Ideally, the notes and information section should support TinyMCE or similar for basic formatting of text. Text should be limited to default font sizes and faces only, but bold, italic, linking, paragraphs, bullets, image insertion, and other simple tagging should be supported.

Image upload should be available either on this screen or via a separate screen. If possible, auto-resizing (using WebMagick or similar) should be enabled to help staff and users keep to a standard template.

Finally, if possible, the CMS should allow functional modules to be enabled/disabled/added/removed/moved via an AJAX type interface. This will allow one CMS to build a greater variety of pages via a modular system.

It is suggested that clip information be held as XML, allowing easier transformation for functions such as mapping or timelining.

SE/DHP agency brief 23.2.10

8

2.4 User interactivity / comments / upload

SE wish to encourage users to share and interact with the available content as much as possible. Therefore the site should support a reasonable range of Social Media functions, such as:

- send to a friend- add to Facebook (see note below)- submit to Digg, del.icio.us, LinkedIn, Google Bookmarks, reddit

and other social bookmarking services- submit to Twitter (using shortform link service if possible)

Please note that a full Facebook Connect integration is not required for this project and should not be quoted for, as development timescales / costs are excessive for the relative needs of this project.

Users should be able to enter comments about each clip. Registration and login would be required and comments would be post-moderated (ie: comments are not published immediately. Instead, a notification would be sent to a site moderator that a comment was waiting for publishing. Moderator can then decide whether or not to approve comment based on relevance.)

If budget is available, users should be able and encouraged to upload their own clips. Preference will be given to archive material, but clips that are relevant to a subject area can be showcased alongside the existing archive material. This will have particular relevance for compare and contrast, and will also give schools and colleges the opportunity to upload “reconstruction” type material or their own interviews.

User generated material should be clearly tagged as such, with the user’s ID placed prominently. Again, this will be subject to manual post-moderation, based on content and relevance. User generated videos will also not have access to full CMS features – TinyMCE controls (or similar) should be disabled and entries filtered for links, emails and any other possible advertising or hacking method.

Should an edit facility be available (see 2.10), users should be able to trim and timeline clips prior to submission.

SE/DHP agency brief 23.2.10

9

2.5 Keyword functions

Content should be held/categorised under moderator-defined keywords, based around popular topics (holidays, rivers, festivals, commerce, etc etc). At least one keyword must be defined for each clip to allow it to be searchable.

Should a user click on the keyword link on a content page, this will pull up a full list of the available clips, held in timeline order (as in when the film/video was shot, not when it was uploaded, oldest to most recent.)

The listing page could also present a short introduction to each keyword/topic section, which would be defined (again, using TinyMCE or similar) when the keyword is created. This will explain what the topic is about and possibly point the user in the direction of fuller reference material.

If possible, filters should be applicable to such keyword pages to select only clips from a certain decade (eg: 1930s) or from a certain area.

Author names (whether users or archive cinematographers) should also bring up a similar page.

2.6 Timeline functions

As these will be archive-based, when the clip was uploaded is not relevant – when it was originally filmed is the most important time factor.

This could be placed into the schema by simply making the “upload date” tag user-definable, or with a separate tag should this become necessary.

Timeline pages should work in a similar way to keyword pages above, but with an elegant mechanism of some kind (possibly similar to a Coverflow application attached to a timeline) that allows the user to locate clips relevant to their time of interest, and see how they relate to each other historically.

SE/DHP agency brief 23.2.10

10

2.7 Mapping functions

Each clip should be able to be geo-tagged using standard co-ordinates (eg: latitude/longitude) using a map interface such as Google. They can also be assigned to a larger keyword tag (Le Havre, Rouen, Norwich, Yarmouth etc) either manually or based on the map location selected.Users should be able to call up maps of their

region and display relevant clips thereon. Again, these should be filterable for content by keyword and/or date range. Map modules should also be available on each clip’s page showing the location the clip was taken (if available) and other clips taken nearby.

Finally, locations used in major motion pictures and TV series could be marked with links to sceneonscreen.

2.8 Building larger articles

Once all the modules for video, pictures, mapping and timeline have been assembled, the ability will be required to assemble these into a larger article page. These could include:

- multiple text/html areas- multiple video / photo pods- multiple text pods- mapping area / timeline pod- comments area

Each module should be able to be added, removed and ordered as necessary on such pages to allow easy page construction around particular topics.

2.9 Language packs

The site should be able to switch easily between English and French for all major functions. A full language pack will be provided for the alternate language once the development language is decided.

Agency will not be required to translate individual pages, only functional items (buttons, alerts, error messages, etc)

SE/DHP agency brief 23.2.10

11

2.10 User login and handling

Users will be required to register if they wish to post comments, use send to a friend functionality, use the editing suite, upload new material, or join groups and forums (if available). Registration also adds them to a database which can then be used for update mailing. Single opt-in confirmation should be sufficient for this purpose.

The user’s control panel should also allow them to change personal details, subscription options and list any clips that they have uploaded. Should the site be hosted outside the EU, basic steps should be taken to comply with EU law on data protection.

2.11 Mobile, IPTV and GeoPoint applications

While they are not required for phase 1 build, the following elements should be considered as part of any bid as a “future addition”.

If the initial web site was correctly developed, XML data and a “read once, export many” video system (that generates specific formats on demand) could then be re-used for:

- mobile version on iPhone- mobile version via SymbianOS or similar- IPTV delivery via set top boxes- GeoPoint / Proximity Marketing delivery via BlueTooth at

infokiosks or specific geo-locations

Up to this point, Screen East have entered into early discussions with HyperTag of Cambridge for provision of the GeoPoint service – see http://www.hypertag.com/solutions/visitor-attraction-solutions/mobile-phone-based-visitor-attraction-solutions/ for further details.

Bids may discuss how they would partner with HyperTag or replicate / exceed the service should they choose not to partner.

Similarly, bidders should note that Virgin Media have a stronger than average presence in Norwich, as much of the city was cabled in the 1980s and a large number of customers would have access to their on-demand services.

SE/DHP agency brief 23.2.10

12

3. Technical specification

3.1 Video Specification

Video should be presented as Flash Video (FLV - H.263 or VP6) to ensurecompatibility across almost all internet browsers. While both QuickTime and Silverlight can offer superior playback quality, they also require specific downloads to use - and can attract higher bandwidth usage.

Video should be encoded at approximately 300kb/sec and 600kb/sec, and a simple manual switch enabled for users to switch between a high-speed view and a high quality view. Additionally, an “HD” rate of 1.5mb/sec could be offered for clips which have an exceptional quality of input material. For low-quality / degraded film, the higher bandwidth rating will not deliver any added value on playback.

3.2 Server specification

Any decision on specifics about server capacity, capabilities, etc should be postponed until after an agency has been appointed and a programming direction decided – as not every server would be compatible with every technology they might wish to use.

Moreover, it is no longer necessary for companies to own or even rent a physical server – “virtual” or “cloud” servers can now provide both more resilience and the same programming capabilities as hardware servers, without the onus of maintenance being on the company. An added advantage of virtualisation / “cloud” serving is that should SE and PIHN decide to pursue different directions at a later stage, a clone server can be created within hours rather than days. SE and PIHN would simply have to agree that all code was held in common.

Video hosting costs will need to be budgeted once estimated traffic levels are known and a decision taken on bandwidth transfer rates. As a video-heavy site, bandwidth could be a very significant annual cost and should have a generous allowance made in case of user spikes (say, if a local paper or TV station drives people to a particular clip). If a non-profit delivery partner similar to PIHN’s local government contacts at CRIHAN can be found (university, government organisation or other) then bandwidth costs could be reduced dramatically.

SE/DHP agency brief 23.2.10

13

Alternatively, the CMS and video provision may be taken together as an entirely managed service, by a company such as RealityDigital or BrightCove.

SE/DHP agency brief 23.2.10

14

3.3 Compatibility

The site should be designed for access to a reasonable range of browsers and specifications.

We can assume from average internet statistics gathered from major sites that 90% of PC / Mac users will be browsing at a screen resolution of 1024 x 800 or better. Therefore, the site should assume maximum width of 990 pixels at widest point to allow for scroll bars, and major video / graphic elements such as maps should have a height of no more than 500 pixels in order to allow for toolbars and other header elements.

A decision should be taken early on as to whether or not to fully support Internet Explorer 6, which has compatibility issues with many common script and transitions, and can cause significant additional costs. While this would remove support for approximately 10% of the current average audience, IE6 tends to be used by large corporations and governmental organisations who are dependent on NT-type internal architecture.

All other major browsers (IE8, IE7, Firefox, Chrome) should be supported as a matter of course.

Web accessibility for non flash elements should be to W3C A standard for best practice and SEO reasons only, as users of screen reader software will largely not be able to use the video software.

3.4 SEO functionalities

Proper META and keyword tagging should be enabled on all pages.

URLS should be full and structured and not based on search extensions (eg: display.php?keyword1=XX&keyword2=YY should be rewritten for all links as video/XX/YY/ . This is easily achieved using MOD_REWRITE type functions.)

All text areas and search links should be accessible to search engineswherever possible. The use of frames, IFRAMES and other redundanttechnologies that damage accessibility for search engines should beeliminated wherever possible.

SE/DHP agency brief 23.2.10