Software, Content management, Data
This section details our approach to software development, content management, data management, and analytics. It emphasizes modular, future-proof solutions and addresses copyright considerations for digital content.
In the below:
"content" includes compiled and running software and production media files.
"Source files" includes source code and original/source/master media files, for example final cut edit files.
Preferred tools
Content should be delivered with Auckland Museum's preferred tools and environments in mind. Any deviation from these tools must be agreed in writing before work begins.
OS:
Windows 11 (Currently we prefer Windows due to the breadth of skills on staff and tools for management)
Code stack:
Node LTS versions 20+
Typescript Google Guide
Vite for local development and building
Astro for static site building
React 16+ for interactivity in Astro
Tailwind 4+ for consistent CSS
Licensing: All Code must be licensed to the Museum not to suppliers where licensing is involved. See licensing section below
We recommend arranging a code library review with the project team at the museum
The Museum's Github is utilised for source code storing
Content Management:
The Museum uses the Storyblok headless CMS. Content for digital experiences should, where it makes sense, reside in the CMS. This includes text and media. Exceptions for bespoke experiences can be discussed on a case-by-case basis.
The Museum requires on-premises resilience for its digital experiences so that, in the event of disruption to online services, on-site digital experiences continue to operate as expected.
Solution specification | Priority |
Sitekiosk is used to lock down clients (End points / devices) especially anything that supports user input (e.g. Keyboard, Touch Screen) | MUST |
Sitekiosk runs with default security using auto start as the restricted Sitekiosk user and not an administrator account. Auckland Museum will provide a base template to be used during testing. | MUST |
Any HTML content needs to run in Sitekiosk Restricted account using the built in Chromium Embedded Framework | MUST |
Sitekiosk to be licensed. | MUST |
NinjaOne to be installed on the endpoints | MUST |
All Source code must be stored in GitHub | MUST |
ESET Endpoint Suite installed. | MUST |
Any application which needs compiled executables to run must run as a system service on start-up. Avoid storing any data in the %userprofile% as well as avoiding startup scripts as the user. | MUST |
Applications hosted within the Auckland Museum network should be hosted using an IIS 10 web server. Apache and Node Express servers are available but not preferred. | SHOULD |
Publicly accessible applications should be run on Cloudflare as Workers or Pages. Azure and AWS services are available but not preferred. | SHOULD |
Jenkins should be used for automated builds within the Auckland Museum network. | SHOULD |
Full Screen Applications that can run full screen as HTML should do so from a browser (CEF) rather than be a compiled executable in say Electron | SHOULD |
Monitoring:
NinjaRMM
QSYS
Control:
QSYS
UDP Listener Agent.
Logging:
Sentry
Sumo Logic
When digital experiences are developed externally, appropriate logging requirements should be discussed between the external supplier and the Auckland Museum project team lead prior to the production phase of the project.
Accessibility, performance, consistency
Solution specification | Priority |
Content shall play with smooth frame rates. | MUST |
Content shall erase cached material at the same rate as it is created, so that disk space is never fully used. | MUST |
Content shall be able to handle the anticipated in-gallery user traffic. | MUST |
Content shall undergo user testing during the development phase. This will be arranged by facilitated by Auckland Museum's project team lead on the project and adhere to a project specific test plan that includes user, functional, load and or stress tests. Expectations from external vendors will be contracted and specific to the project. | MUST |
Content shall provide captions where necessary. | SHOULD |
Content shall have an attractor state. | SHOULD |
Content shall revert to a usable initial state after an idle time. | SHOULD |
When required, content shall provide friendly error states for user interaction errors and system errors. | SHOULD |
Content shall use a UI that complies with the UI criteria defined by Auckland Museum via the project team lead of the project. Key UI design and branding elements such as text content, logos, background graphics and colours should be able to be changed without extensive developer time required, for example by using a supplied CSS file. | SHOULD |
Content shall adhere to the accessibility requirements outlined in the accessibility and inclusive design section of the Technology and Digital Standards. Content should not require visitors to be able to see or hear in fine detail. | SHOULD |
Robustness, control and security
Resilience statement:
Auckland Museum is committed to ensuring the resilience of its digital software and content systems. All platforms and content delivery mechanisms must be designed and maintained to support continuity, adaptability, and recovery in the face of disruption. This includes prioritising secure, scalable solutions, maintaining reliable backups, enabling version control, and ensuring accessibility and integrity of digital assets over time.
Auckland Museum endeavors to customise operating system installation to minimise issues when experiences are presented to the public. We don't run standard baseline operating systems.
Solution specification | Priority |
Web Content shall run from Sitekiosk Chromium Embedded Framework (CEF) latest version (currently 127.0.6533.120) | MUST |
Content shall run in Sitekiosk Classic 9.9.6744 (or latest release) | MUST |
Content shall automatically run full screen. | MUST |
Any confidential User Data that will be stored should take into account our Audience and comply with any privacy legislation depending on the target audience e.g. New Zealand Privacy Principles, GDPR | MUST |
Content with dependencies, for example a background audio application or interface, web server, database, should run as a system service that can auto recover or restart | MUST |
Any application code or content that will be run must not reside in the user profile. | MUST |
Sitekiosk security manager must not be changed or have any restrictions lifted. | MUST |
Sitekiosk base configuration must come from the Auckland Museum ICT team. | MUST |
Sitekiosk must run as the restricted sitekiosk user account with autostart enabled. | MUST |
Performance testing is to be performed and should include: Load testing measures system performance as the workload increases Stress testing measure system performance outside of the parameters of normal working conditions Spike testing software performance when workloads are substantially increased quickly and repeatedly Soak testing an evaluation of how software performs with a normal workload over an extended amount of time. Scalability testing determine if software is effectively handling increasing workloads Volume testing how efficiently software performs with large projected amounts of data | MUST |
Supply expected values under normal use for- Response time - Wait time/Latency-Average load time - Peak response time- Error rate- Concurrent users - Requests per second - Transactions passed/failed - Throughput - CPU utilization- Memory utilization | MUST |
Content shall allow for configuration of common values via human readable format such as JSON or XML | MUST |
Content shall provide a heartbeat service to monitor the product state. HTTP status of 200 to be returned | MUST |
Content shall run on a non-administrative local user account. | MUST |
Content shall allow remote management by Auckland Museum via login. | MUST |
Content shall provide exit or quit options available to Auckland Museum Staff. | MUST |
Content shall not have exit or quit options available to the public. | MUST |
Content shall, after computer startup (and power cut) require no staff intervention. Essentially, automatically become ready for the visitor experience. | MUST |
Content shall run robustly, i.e. not buggy, no memory leaks, able to run for days on end with no deterioration or demand to equipment exceeding specifications. | MUST |
Content shall work without access to Wifi or the Internet for at least 24 hours. | SHOULD |
Content shall be modifiable with affordable and accessible tools. | SHOULD |
No development libraries or software to be used with known CVE vulnerabilities. | MUST |
Software quality and longevity
Solution specification | Priority |
Software shall include automated tests for all bespoke functionality and must report code coverage. | MUST |
Software shall include integration tests covering all major user functionality. | MUST |
Software shall have no security vulnerabilities present in any dependencies after a security scan, at time of project delivery and warranty period (i.e. provide updates). | MUST |
Software shall not use obsolescent or soon to be deprecated software frameworks such as Adobe Flash. | MUST |
Must avoid unproven or short life cycle SAAS applications when selecting software. | MUST |
Software shall pass linting with a well-recognised linter for the language being used. | SHOULD |
Content shall minimise proprietary file formats. | SHOULD |
Software should have minimal annual license fees. | SHOULD |
The system will be built to anticipate the need for progressive upgrades. | SHOULD |
Content shall run on the current version of enterprise-grade OSes, such as Windows 10/11 Pro. | SHOULD |
Content shall work in a variety of modern browsers, if browser-based, but especially Sitekiosk's version of Chromium Embedded Framework. | SHOULD |
Content shall only use versions of frameworks and languages that have at least 2 years of LTS (long-term support) from date of project delivery. | SHOULD |
Content shall be iteratively delivered and be reviewed by Auckland Museum (including code review) at each delivery. | SHOULD |
Software libraries and licensing to be identified and maintained at current versions during development | MUST |
CMS Integration
Solution specification | Priority |
Software shall obtain text-based content from Auckland Museum Storyblok CMS to allow for updates from a known system. | SHOULD |
Software shall obtain content related media assets from Auckland Museum Storyblok CMS to allow for updates from a known system. | SHOULD |
Software build processes shall copy Storyblok CMS content to local storage for deployment to avoid being reliant on constant working internet. | MUST |
Collaboration and documentation
Solution specification | Priority |
Suppliers shall provide a ticketing system that Auckland Museum can use to register system support issues during the development and support phases. | SHOULD |
Suppliers shall deliver content iteratively in sprints of a negotiated length. | SHOULD |
Sprints shall conclude with developers showcasing new functionality and Auckland Museum performing code reviews against the code. | SHOULD |
Software documentation shall cover all classes and functions in the code according to a code documentation standard that allows for automatically generating code documentation. | SHOULD |
Software documentation shall include build and deployment | MUST |
Monitoring and control
Solution specification | Priority |
Works shall report agreed events to an analytics provider such as Google Analytics or other tools used by Auckland Museum supporting automatic upload (e.g. no csv file for analytics requiring manual file copy on device) | MUST |
Works shall allow for integration with Auckland Museum's tools for remote control of power, display and audio. | MUST |
Works shall allow for remote monitoring of CPU performance, uptime and other device metrics with a monitoring tool. | MUST |
Works shall report errors and crashes to an error handling tool such as Sentry. | MUST |
Works shall include diagnostic tools to allow for turning off components whilst maintaining the operation of the work (this might be temporary in the event of testing for issues via elimination or medium term while waiting for a replacement component). | COULD |
Works shall include diagnostic tools to allow Auckland Museum staff to edit or remove inappropriate content. | COULD |
Works may log errors locally with log rotation and in a human readable format | COULD |
Data
All data collection, storage, and transmission must be compliant with relevant regulatory and legislative requirements (e.g. Privacy Act).
If data of cultural significance forms part of a digital experience, that must be flagged for discussion with the Museum to ensure sovereignty requirements can be considered.
All digital experiences that require any live data feeds (from outside of the Museum’s networks) must be accurately assessed by the Auckland Museum team and may not be considered suitable for deployment into a gallery (see on-premises resilience in the Content Management Section).
Summary and verbose logging capabilities, with log storage management, should be available for troubleshooting digital experiences.
Telemetry and analytics for user interactions should be considered in the design of digital experiences, and developers should recommend what data is kept for this purpose.
Deployment
If a digital experience is unable or unlikely to be able to be deployed on Auckland Museum’s existing platforms (e.g. Storyblok) and is granted an exception by the Auckland Museum project team, consult your Auckland Museum project team lead who will recruit the right specialists to discuss appropriate alternatives.