How human behaviour influences the technical approach to a platform ~
A walk-through of how Frank Digital redesigned cancer support services by using technology to create positive change for people affected by cancer.
From discovery and design to code
After working through our process to understand the goals of the CanTeen Connect users (see Part 1 of our CanTeen Connect article series), it was time to define the technical approach for the features of the platform. With our overarching platform goal to achieve connection, there were a number of key technical approaches we needed to consider to ensure a great experience for our core and administrative users:
- A single content repository to simplify CanTeen’s content management workflow, while making it easy for users to connect with this content across digital touch-points (inc. CanTeen Connect);
- Easy to search and find content and people based on a cancer situation;
- Optimised platform performance to allow for user-base growth, both in size and activity;
- Ensuring communication features (such as discussion boards) are optimised; and,
- Connect and communicate through direct messaging.
Connecting content from a single source; the Headless CMS
The first key technology requirement was to determine how we would manage content across the platform. As the overarching requirement was for CanTeen to leverage their vast cancer resources and content across multiple digital touch-points, a single content repository was a must. So naturally, this technology decision needed to be thoughtfully considered with implications across CanTeen’s entire digital ecosystem.
Our approach was to leverage a Headless CMS. For those new to the term:
A Headless CMS is a content management system (CMS) that takes an API-first approach, providing content via an API instead of a specific front-end view (the head). It provides the flexibility to choose the technology for the head independently from the CMS. Further, it allows for the creation of multiple heads without the need to change the CMS. For example, you could build a native mobile application and a web application using the same CMS.
Or in other words; manage content in one place, display content in many places.
Having integrated with enterprise Headless CMS solutions (like City of Sydney News, leveraging the Contentful platform), as well as building a bespoke solution (like City of Sydney What’s On), we knew a thing or two about the approach. But which solution?
When assessing the best solution for the requirements of CanTeen Connect, a new Headless CMS solution had come on to the market, Prismic. So with the best interests of CanTeen in mind, rather than just roll with what we already knew, we completed some due diligence. CanTeen’s requirements were pretty simple:
- Simple, cost effective integration; and,
- Easy to use interface to manage the content.
And our comparison:
In the end, Prismic was deemed the best fit.
The only short-fall we experienced was when large-scale content updates to tags were required.
As Prismic does not yet offer a write API, updates need to be made manually. While this process was nominally cumbersome, it did not out-weight the cost-effectiveness and simplicity of the integration.
While the lesson here is to ensure you have a complete content plan for your content types (no matter your chosen solution), Prismic has been a fantastic Headless CMS platform overall.
With such a large array of content across the platform, we needed to ensure that search was quick, intuitive and simple to deliver content to users.
Frank has worked with a number of solutions for search and filtering, ranging from plugins, third party, and bespoke solutions. But none have delivered to the level of Algolia. Once configured, Algolia provides results within milliseconds, whether you’re searching for keywords or applying search filters. Check it out in action:
We have also used the Algolia solution in our digital transformation of Merivale.
Optimising platform performance
To deliver a dynamic user-experience, quick and efficient platform performance would be a key driver in delivering a great product. Performance always proves critical in gaining user traction and uptake on the platform. We implemented a few techniques to achieve this.
React server-side rendering with NextJS
With Canteen Connect, we knew we would be building more than a traditional website.
To get the best of both worlds, a technique called Server-side rendering has emerged to counteract these issues. It works like this:
With the Frank being a React-based tech team (we won’t go into why here — an article for another time 😊), naturally, we investigated some React-based server-side rendering frameworks. While we explored the likes of Razzle and Gatsby, we ultimately chose NextJS for its documentation and world-wide community.
On top of React, we leveraged Redux for managing the state of the platform. This allowed us to simplify the build of complex interactions such as API calls, authentication state management or actions side effects (e.g. updating details in your user profile).
For example, when a user creates a new discussion through a modal:
- On success, the modal is closed and the user is redirected to the newly created discussion
- If an issue occurs, we display the error message via a global error notification component
To simplify the hosting of the NextJS application, while making the application more robust and scalable, we leveraged the latest in serverless infrastructure technologies using the AWS API Gateway and Lambda.
In a serverless infrastructure, the cloud provider (AWS in our case) is in charge of provisioning the servers and managing the computing resources. This means infrastructure pricing is based on the number of resources consumed per call.
In other words, we only pay for what we use rather than the traditional ‘always on’ approach. So, in a month of very low traffic the hosting cost would be close to nothing, rather than what can be exorbitant fees to support the cost of running an ‘always on’ server.
Another advantage of this infrastructure is its scalability. The application would be able to go from 0 to million connections per second seamlessly.
And, as each execution is independent, a server error on one request doesn’t impact other requests — no more server crashes!
All this allows us to focus on our code, rather than worrying about the underlying hardware or hosting overheads.
For CanTeen Connect we took this all a step further by using a new feature of NextJS (released with version 8) called Serverless NextJS.
When building a server-side application, NextJS now splits the code on a per-page basis instead of one bundle for the whole website. This reduces the amount of code to be parsed and executed by a page, meaning faster page speeds and less computing resources required to execute the serverless function.
When considering the discussions feature, we quickly acknowledged that threads could reach hundreds of comments as the platforms, causing a significant load issue which would negatively impact the overall user experience.
We decided to implement a technique called virtualised scroll.
The idea here is to only keep part of the comments in the thread in the DOM: the ones in the user’s viewport plus some comments above and below. The rest of the comments are kept in memory or are waiting to be initialised (querying their content via the API and rendering it). By not overloading the DOM with elements that aren’t rendered, we are able to keep the scroll process smooth maintaining an optimal experience.
Being a React-based team we first tried using the React virtual scroll library, with some unfortunate critical issues:
- Using the dynamic recalculation of the rows height resulted in some visual glitches of comments in a discussion were collapsing.
- When attempting to programmatically jump to a specific comment using the “jump to row X” function, either the jump didn’t happen it jumped to the wrong item.
So, we built our own from scratch around CanTeen’s specific requirements.
The piece-de-resistance for the platform is the introduction of its own messaging platform — the key feature in achieving connection.
The messaging hub allows users to connect with people just like them, leveraging the existing content taxonomies to reveal people going through similar cancer journeys as the user.
We designed our bespoke messaging API to deliver a holistic messaging experience with multiple integrations across the platform.
For example, users are able to share resources and blogs directly with others, resulting in a new or continued conversation. Or, much like other messaging platforms, when someone messages a user they are notified via the notifications system.
One of the biggest technical considerations when developing the messaging feature was to ensure the experience worked like products that people are familiar with. Think Facebook Messenger or direct messages on Instagram.
The messaging API and facade were built to:
- send and receive conversations almost instantaneously
- add, edit and remove members from a group conversation
- rename group conversations to something more representable for the members
- send a variety of message types including text, images, YouTube or Vimeo videos, links, and GIFs (leveraging Quill.js and React.js)
Now after a little over 18 months of discovering, designing and coding we are proud to have built one of the largest, most complete and robust products we have ever created. We are prouder to get to do it with one of the best, most forward-thinking organisations we have ever worked with.
CanTeen and Frank Digital have created a platform that is truly ‘connecting’ people affected by cancer; both with each other and with the significant support services CanTeen provides. And together, that is something we can be truly proud of.
You can check out the CanTeen platforms here:
To discover more of our work visit Frank Digital