Guidelines for use of Creative Technology at Te Papa

Owned by Adrian Kingston
Last updated: 17 Dec 2020 by Rainer Spittel (Unlicensed)

Date:                     15 August 2018

Version:                 1.0.3

Source document: http://poumataaho.boh.tepapa.govt.nz/otcs/llisapi.dll?func=ll&objaction=overview&objid=3941405

Introduction

These guidelines are designed to strike a balance between creativity and cost of ownership of products developed for Te Papa by a third party. The intention is to outline the existing environment, development principles and some minimum requirements to ensure quality, reliability and maintainability of digital products while allowing vendors to make recommendations on the best ways to achieve high quality, rich, visitor experiences on the floor and online at Te Papa.

In case of conflicts with statements in this document with other documents, such as a Statement of Work or Request for Proposals, the clauses of those other documents supersede the recommendations in this document.

If you have any questions, please feel free to contact Te Papa via your main point of contact.

Existing Environment

While it is not a requirement that your products work within the following environment, a reduced cost of management and support will be realised when these technologies are used. We do not want to restrict creativity, however, and so other platforms will be considered where there are creative elements which require them.

If your design deviates from Te Papa’s existing environment, you should contact Te Papa -Creative Technology Team to discuss your proposed solution.

BrightSign

Te Papa operates over 200 BrightSign players (https://www.brightsign.biz/), a range of models exist and in general will be the preference for delivering projected video and video screens. BrightSign players have a number of features for connecting external sensors and controllers as well as facilities for synchronising video and responding to show control events.

BrightSign provides a BrightAuthor package to create presentations optimised for the player. BrightSign can also deliver interactive experience through the BrightAuthor package and displays HTML5 interactives with some limitations on multi-touch and graphics performance.

Te Papa supports BrightAuthor projects and has developed management and control modules for BrightAuthor projects. Those can be easily integrated into a BrightAuthor project and will automatically integrate the BrightSign into Te Papa’s monitoring and management systems.

Digital Experience Delivery System / Windows 10

The Digital Experience Delivery System (DEDS) includes an HTML5 player (Player) which is locked down to a specific, recent version of Chromium with back-end services provided by a Node.JS server. This Player provides a solid foundation on which to build HTML5 apps and removes the need for providers to concern themselves with operational aspects such as locking full-screen mode and providing monitoring data to Te Papa’s management systems. The Player is maintained by Te Papa and will be updated on a regular basis. Further details will be provided to successful vendors who chose HTML5 as a development platform.

This Player runs on Windows 10, and in general, any other digital products which require a PC would run in this environment.

Te Papa prefers the use of DEDS for digital labels and interactives and the use of open source solutions to enable Te Papa to support your products long-term.

Hardware

Te Papa has significant experience with selecting appropriate hardware and will work with vendors to select an appropriate hardware platform. Where necessary, Te Papa will provide an instance of the hardware configuration to vendors to aid in testing and development during the period of the contract.

You should talk with Te Papa about hardware requirements and infrastructure needs for your products.

Platform Options

Te Papa is flexible in the technology platforms we support. However, there are some aspects which should be given consideration:

  • Development platforms are preferably non-proprietary, allowing Te Papa to update and maintain products into the future.
  • Each solution should support and use open source software, allowing Te Papa to maintain products in the future.
  • Each solution should support open standards, allowing solutions of different vendors to integrate into the Te Papa technology platforms.
  • BrightSign technology is our preferred technology platform. If the technology platform does not support your product, Microsoft Windows 10 are our preferred operating system.
  • Hosting of any cloud-based solutions is typically Amazon AWS, and the Te Papa account shall be used where hosting is required.
  • Data of your product should be made available in a reusable way and is the single point of truth of your data.

Design & Development Guidelines

Te Papa uses an agile exhibition product development process internally and intends that a vendor and Te Papa should provide opportunities throughout the development process to provide feedback and guidance on the product. Te Papa’s exhibition product development process consists of three phases. During the engagement, Te Papa would like to allow to allocate a period of time for solution concept design and validation. This phase would be highly collaborative between the vendor and Te Papa.

Te Papa has created an open-source Digital Language System or DLS (https://dls.tepapa.govt.nz/) which defines a design language of patterns and principles for use in designing digital products. This will be made available to vendors engaged by Te Papa and should be considered for use where suitable patterns exist, in order to provide a consistent visitor experience throughout the museum.

Te Papa requires vendors to use a source control system for managing any source code and recommend that best practices such as Test-Driven Development, Continuous Integration and user testing are used to ensure quality deliverables.

Te Papa should be provided with all source code, build scripts, API and application documentation, design assets and source files required to update and maintain the code. Our development team will attempt to build any software products as part of the commissioning process to ensure our ability to support the product.

Te Papa encourages the use of Te Papa’s source control system (GitHub) and Continuous Integration services (Jenkins or Travis) during the initial project setup phase.

It is important that all code that is provided to Te Papa needs to be clearly structured.  We recommend that all developer use the lint standards to ensure that all code is correctly structured.

Te Papa does not operate under the “Good code does not need comments” mantra.  Te Papa requires that all functionality needs to be clearly documented. We recommend using Javadoc to document functions and classes.  Where possible, all documentation should be built from the documentation comments.

Content

Interactives should allow content to be bi-lingual using both English and Māori, as such fonts should employ macrons and on-screen keyboards should include a facility to provide macron characters.

Te Papa may require the support of additional languages over time. Your product should enable Te Papa to add content in other languages over the lifetime of the exhibition.

Products should have a rest state which attracts visitors to interact.

Screensaver and Attractor Loop

Interactives should, when not used for a selected period of time, switch to an Attractor Loop. This assures that no element of the interactive stays in a static position for a long period of time and helps to avoid possible burn-in.

Quality

Te Papa expects a level of experience consistent with that which would be expected from the national museum. Animations should be smooth, and the execution of design should be of a high standard.

Functional and integration testing should be provided as part of the codebase. Continuous Integration service should run all tests during any build process.

Reliability

Products should be capable of running all day in a high-traffic environment, with thought given to “monkey testing” emulating large numbers of random interactions with the product. It is acceptable for products to be automatically restarted daily. Te Papa performs scheduled shutdown and automated start-up procedures daily for all digital and technical solutions deployed in Te Papa’s exhibition space.

Products have to be resilient to hardware reboots.

Products which are not using BrightSign or DEDS should provide a simple “heartbeat” signal to the back-of-house monitoring systems, more information on the protocol will be provided to vendors engaged by Te Papa.

All technologies employed, whether it be BrightSign, DEDS player, any other PC application or hardware, should be configured to boot directly into the ready state without any user intervention.

Security

  • Any products should meet Te Papa’s security needs, and any data collected from our visitors need to meet the industry best practices on privacy- and security policy.
  • Interactive products should have no gestures, “hot corners” or other ways to access an admin console or debug mode from the visitor side of the experience.
  • Any network access required should not require an external IP address or ports translated through NAT to the product.
  • Right-click/long-tap, context menu access, and text selection should be disabled in any interactive products.
  • Hotkey combinations may be used to quit from digital products where no keyboard is available to the visitor.
  • Any input fields should sanitise against HTML or code-injection attacks.

Visitor generated content

  • Any visitor generated content should filter for profanity using a list of stop words to be provided by Te Papa.
  • A moderation facility should be provided to remove any questionable content.
  • Generally, post-moderation is acceptable in order to provide a real-time interactive experience.
  • Where visitor generated content is provided online or from a visitor mobile device, content should be delivered by an intermediate cloud server to avoid any direct connections to the Te Papa network.
  • Visitor privacy should be considered, only data required for the experience should be stored, and where possible identifying data such as full names or email addresses should not be displayed within the interactive.
  • Any visitor or analytics data should be made accessible securely via APIs and is the single point of truth of your data.

Analytics

Analytics shall be collected on user interactions. At this stage, Te Papa is currently using Google Analytics and will provide vendors with a set of events and interactions which the vendor should configure.

Products should have the ability to adapt to Te Papa’s need to support other Analytics providers.

Te Papa’s DEDS provides you with all common required Analytics and tracking events.

In case your products do not support Google Analytics, Te Papa would consider other solutions if needed.

Configurability

Any connections to external services, control sensitivity parameters, operating schedules, display configuration or other parameters should be configurable either through a configuration tool or stored in a configuration file for Te Papa staff to easily maintain.

Software Architecture Principles

Te Papa encourages vendors to discuss architectural and technology decision at key stages throughout the project cycle. Te Papa would seek conversations with vendors regarding the proposed solution and product design.

If possible, new products should consume existing services or products. Te Papa already uses a number of products and services and would be happy to share those resources with vendors. We encourage the use of existing Te Papa infrastructure, services or products.

If your product cannot be supported by Te Papa’s existing environment, Te Papa would prefer the use of open standards in the product design. This includes HTML5-browser-based user interfaces.

Your product should support open standards to support interoperability. Open-source software shall be compared and considered alongside commercial software for your technology solutions.

If your product requires backend systems, consider those services to be hosted in our cloud-based infrastructure or being consumed as a software as a service.

Your product should limit dependencies of Internet-based services or network-based dependencies to other sub-systems.

Technology

Web Technology

Preferred and supported server-side languages for the implementation of this product are:

  • JS ( JavaScript)
  • Java
  • PHP
  • Python

Preferred and supported technology and frameworks for the client-side Single Page application for this product are:

  • HTML5, CSS3, JavaScript
  • JS
  • WebPack, SASS

Game Technology

For Arcade-like 2D game-like experiences, Te Papa prefers the use of HTML5 based solutions. Te Papa has tested Phaser (https://phaser.io/) and would prefer to use of Phaser for future development.

Te Papa’s DEDS Player supports Phaser and can manage the build and deployment of games.

For highly dynamic, 3D game-like experiences, we recommend the use of Unity3D based solutions which are optimized for MS Windows 10.

Shared Core Services

Te Papa provides a number of core services which can be used for your products.

Continuous Integration / Continuous Delivery

Te Papa provides a Continuous Integration / Continuous Delivery service to support the active development and maintenance of a product over its lifetime. We recommend the build process for your product to be integrated into Te Papa’s release process and build system.

User Management

Te Papa provides an Azure Active Directory Connect Service for user authentication.

If your product required user authentication for Te Papa staff members, e.g. for roles like content writers, content reviewers, and application administrators, the use of Te Papa’s Active Directory Connect Service is recommended.

Intellectual Property Rights

Te Papa’s would like to be able to manage, deploy, re-deploy and alter the product over its lifetime. This will enable Te Papa to adopt changes and ongoing support of the product over the lifecycle of the exhibition.

A re-deployment could be performed to perform some testing on the product (or altered version) as well as the potential second deployment of the product in the museum context.

This could imply that an altered version of the product will be used a second time on the floor. Any licensing needs should be addressed in the contract, including 3rd party licenses.

Te Papa would prefer to have the right to perform smaller changes to the product, such as configuration changes, content changes or smaller code alterations and deploy the altered version into our production environment, maybe in a different location.

Te Papa also seeks the rights to reuse the product for other intentions at Te Papa in the museum context.

Operational considerations and Maintenance

  • A period of “High Care” should be allowed for in the period immediately after releasing products to the floor. Typically 10-15% of the development budget is recommended for this period.
  • Consideration should be given to tasks and budget required to manage products each year that they are in operation, typically this is a period of 5 to 10 years.
  • Content should be easily updated, either through a simple CMS, flat file or a JSON file.
  • Updates to content should be possible over the network, avoiding the need to physically access the hardware on the floor.
  • Remote access for vendors to manage interactives is by default not provided by Te Papa but would be open discussing remote management options with the vendor.

Physical Considerations

When proposing a solution, consideration of physical aspects should be given, including viewing angle for screens, lighting, and ergonomics. The product will be installed on the museum floor and based on the floor layout very likely in a shared floor space.

Where a furniture and hardware solution is provided, the furniture should be lockable, with restricted access to power buttons and physical controls such as brightness and volume. Where hardware is provided, consideration should be given to ventilation and operating temperature under load.