Like any form of software implementation, IT involvement is essential. Your focus will likely be on the strategic implementation, so we want to make it as easy as possible to get the platform in place and ready to go.
The information in this section has been written ready for you to share with your IT department, but if you or they have more questions, please feel free to ask.
System architecture
[diagram id=”system-architecture”]
The Culture Shift platform is built in TypeScript and consists of three major components: an API, sites, and an admin dashboard.
The API is built using the Serverless framework, using AWS Cognito for authentication, and exposes a GraphQL server using NodeJS on AWS Lambda. AWS RDS provides a PostgreSQL database which the API uses as a datastore. The API is used by the administrative interface, as well as select ‘super admin’ functions which are restricted to Culture Shift staff.
The Sites component is built using the Serverless framework using NodeJS on AWS Elastic Container Service with Express. It exists to serve the public-facing reporting websites. Each organisation is provisioned with a CloudFront distribution that corresponds to that organisation which is protected by a TLS certificate issued and managed by AWS to provide secure HTTPS communication under the organisation’s domain.
Emails are sent to administrators and case workers when a report is submitted or assigned, and this comes from a no-reply email address managed by Culture Shift and does not contain any personal information about the report.
The admin dashboard is shared between all organisations, and is a single-page web application written with React. It authenticates users with AWS Cognito and then communicates with the API using GraphQL.
The following types of data are stored in the database:
Branding information: This is managed by the API under a super-admin function. The Sites component reads this information when determining how to style a request to a user.
Reports: Reports are submitted through the Sites component. Further updates can be made to fields in a report through the admin interface redaction function. The admin interface can show report data, with the API enforcing access control to a particular report or reports query. Reports can be exported by a user, which is provided as a password-protected XLSX file.
Site content: These are created and updated through the administration interface, with access control applied in the API which the interface uses to access the data. The Sites component has read-only access to the site content to present this information publicly.
Uploaded images: Images can be uploaded by content editors to be used in articles. To upload an image, the API first generates a signed URL which the administrative interface uses to upload the image too. This uploaded image is then verified to check it is a well-formed image file, resized if it is too large, and then moved into a public location where it can be accessed by public users of a site.
Supported browsers
The administration interface is built as a web application, and as such requires a modern web browser. For the administration interface, web browser versions with greater than 0.2% of global usage are supported on a best effort basis, with the exception of Opera Mini and browsers deprecated by their vendor. No support guarantee is made for a web browser which does not meet this requirement.
For the reporting interface, a “progressive enhancement” technique is used to maximise browser support. Our intention is to provide a basic level of usability to all browsers, with a full-level of support to all web browsers with greater than 0.2% of global usage, with the exception of Opera Mini and browsers deprecated by their vendor.
The administration interface and public site are tested with the following browsers to verify this:
Google Chrome on Windows, macOS and Android (latest version only)
Firefox on Windows and macOS (latest version only)
Safari on iOS and macOS (latest version only)
Internet Explorer (latest version only)
Edge (latest version only)
Single Sign On
Organisations can implement Culture Shift’s Reporting tool using their existing single sign on provider.
The Culture Shift platform supports the SAML 2.0 protocol for Single Sign On. In order to set up Single Sign On, please provide your Culture Shift technical contact with either a URL for your SAML IdP metadata, or a metadata file. Culture Shift will be able to provide you with a SAML SP metadata file.
In order to provide Single Sign On, we will require the NameID to be set to an appropriate username for your organisation (this will be used by your admins to add users to a team), and additional claims for a display name and e-mail address to be set up. Please let us know the names of the claim attributes.
We have successfully integrated with several SSO solutions such as Azure, ADFS and Shibboleth. We use AWS Cognito as our SP implementation.
Once set up, you’ll be able to simply add users to teams using their Single Sign On username – adding an extra level of security to the product.
Age Appropriate Design Code
If you’re an organisation that works with under 18 year olds, you may be interested to know how the Culture Shift platform meets the Age Appropriate Design Code (AADC) to protect younger audiences and to ensure that they can make informed decisions.
We’ve worked hard to ensure that we’re meeting the AADC and we work with our partners to help support younger audiences.
We recommend that partners:
Ensure that they’re privacy and data policies are accessible to a younger reading age
That cookies are set to the highest degree of security as default
Have geolocation off by default
Include explanations on “why we’re asking questions”
Give reporting parties ownership of their data, and ensure that they’re able to delete all of their data from the system
We’re still working through some of the finer details and will be:
Ensuring our best practice questions meet AADC guidance
Undertaking a DPIA for under 18 year olds using the system
Understanding the under 18 reporting journey
If you want to find out more about AADC and what it means for you, please get in touch either through the contact us page or by contacting your Relationship Manager.
Accessibility
How accessible is the system?
Although Culture Shift is not a public sector organisation, we recognise that many of our customers have obligations under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, in addition to our legal responsibilites under UK law and ethical responsibilities as good citizens. This statement is made to set out our accessibility standards and to help our customers ensure compliance with their own standards.
The Culture Shift product consists of two different websites: a customisable public website, and an admin dashboard. These websites are built in such a way to be compliant with the Web Content Accessiblity Guidelines, version 2.1 to the AA standard (this is in line with UK government guidance).
We use the tool Pa11y on our Dashboard and Demonstration website to check our compliance with these standards. When Pa11y identifies an issue, we handle these as a high priority bug.
The public-facing websites of an organisation allow users to customise the look and feel, including the use of images and colours. It also allows users to publish content including linking to images, embedding videos and other documents. Culture Shift does not validate that these user configured options and content meet the requirements of WCAG 2.1, so it is up to customers to ensure that their colour and image choices are compatible with the standard, as well as any additional content such as videos.
Keep in touch
Sign up to our newsletter to receive monthly insights and resources.