Digital Experience Delivery System (DEDS)

Owned by Adrian Kingston
Last updated: 08 May 2018
5 min read

Version: 24 April 2018


DEDS is a business process, and supporting tools/tech, that Te Papa uses to create digital experiences for the floor.

We use an agile/scrum methodology with two week sprints to develop products (and improve the DEDS process and tools). The allows a positive feedback loop where we improve everything such as our research, ideation process, communication with each other and outside stakeholders, and the tools themselves.

This was built from the outside-in, focussing on the needs of the internal customers (digital producers, the wider digital team, and other groups at Te Papa), and acknowledging that these needs change over time as we learn more, and as the public's expectations change. (E.g. most people expect that swipe works, and that they can pinch and zoom images.)

The tools we conceived to support that process, and loosely coupled, so that we can improve parts, replace of remove others, or combine them in new ways.

DEDS is built on foundations:

The DLS

The Design Language System documents foundations, principles, and patterns that are based on research and testing. This is a living document, and is publically available on github.

https://dls.tepapa.govt.nz/

Design Principles

The DEDS design principles are based on organisational requirements:

  • Modularity
  • Off-the-shelf
  • Standardisation
  • Stability
  • Adaptability
  • Built for change/Sustainability
  • Data-Driven Improvement
  • Consistent Naming
  • Reusable
  • Accessibility
  • Multilingual
  • One Source of Truth

HTML

The big underlying technology principle is to use web technologies wherever possible - HTML5, CSS, and Javascript - as our primary toolkit. The reasons were flexibility, speed, and them being open standards.

Process

The DEDS process has to sit alongside and interface with existing Te Papa processes such as writing and video production. The existing processes are stable, and we don’t want to disrupt those too much while working on and improving the DEDS process.

Our process has already changed multiple times, and for Natural History we are using a small CMS to improve interface points with the writing team.

Tools

Initially we built a framework around Marko - a Javascript templating system built by eBay. We built two stand-alone digital interactives with it as a trail. We learned a lot, but decided not to continue with that technology due to lack of community, and it being too monolithic in nature. It was also impossible to get contractors who knew the framework. We pivoted to using ReactJS, and decided how to architect things up front, creating a component suite and a starter kit.

The first part of DEDS is the component suite.

This contains reusable elements such as the video player, image zoom, and language toggle

  • Built using ReactJS and Redux
  • Can be imported into other projects as a node module

The second part of DEDS is the starter kit.

  • Contains the basic elements for creating an interactive, and includes examples of how to use the components for common tasks, such as an image gallery.
  • Sets out the directory structure and locations for images, video, and CSS.

The third part of DEDS is the Player:

  • Based on Electron - which is a chrome web browser packaged to run as a standard desktop application.
  • Always runs full-screen.
  • Registers with our build platform
  • When there is an update, it downloads the new code and assets, and reloads the code
  • It runs the interactive stand-alone, and it can run if it cannot connect to the internet. (All the content is on the hosting device)
  • Can run on Windows or Linux. Currently we use Windows on the floor, but we have also built a linux kiosk running an interactive as a proof-of-concept.

The fourth part is the build system.

  • based on Jenkins
  • Takes the code and assets - image, video - and packages them in a format that the DEDS players requires.

Lastly there is a custom deployment system to deploy built interactives (and their assets) to specific instances of the player on the museum floor.

We currently package up the code to run standalone on the on-floor device. The interactive does emit analytics, which require an internet connections, but it can function without it. It would be possible to run these off some sort of remote API, but we opted to have all the assets locally for speed.

New code (or content) can be deployed at any time, even during public hours, provided no one is around. We used to only do updates outside of ours.

In order to improve what we design, all interatives have live analytics.

  • Each component has default analytics built in
  • This allows for coherent metrics across multiple interactives
  • Future plans are to have an integrated system that will also us to easily track and compare whole exhibitions over time.

Another important aspect is monitoring.

  • We are trialling Nodel for monitoring of the interactives and the host PC.
  • It was funded by Museum Victoria, and released as open source
  • We have added a few features such as
    • the ability to automatically run the DEDS players at startup
    • Monitor the state of the running interactive
    • Report the version number of the live interactive on the dashboard (helps during deployments)

Now that we have many of our patterns codified as DEDS components it is trivial for designers to include them in work. For example, the video player component has it controls and layout pre-defined, has sensible default analytics built in, and can take as many language files (for sub titles) as needed. We can also caption (names of speakers) from the language files. This makes it very fast and simple for everyone, and frees us up to work on new components, testing and improvements to the system.

The Future

Work has planned for the future includes:

BrightSign

We are going to make it possible to run DEDS HTML5 apps on BrightSign (subject to the hardware version of the BrightSign) and also write a BrightScript component to allow Nodel to interrogate the status of the device. We'd like to run simpler apps - like ones with simple object -> information mappings, and single/selectable on-demand video - on BrightSign as there is no player setup.


Once we have this in place, we will be seeing how far we can push the BightSign hardware in terms of complexity of HTML5.

Session Tracking

At the moment, session time out after 90 seconds. We are looking at adding face tracking so that we know when a session ends (all the faces leave) and how many faces were viewing that session. We have some privacy research to do around this.

Linux

We have a proof-of-concept Ubuntu-based kiosk that can run DEDS interactives. We have yet to build a DEDS player for Linux, but this is trivial. At the moment we use Windows on HP Minis where more horsepower is needed that BrightSign, but there are no current plans to test a Linux machine. They are certainly faster to set-up, and less maintenance (no forced udpates, etc), but at the moment we have limited in-house expertise in this area.