Introduction

EARS, an acronym for Early Alert & Response System, is one of the web applications I was deeply involved in designing and developing during my tenure at the Fiji National University in the early stages of my career. It's a web application that provides a platform for academic staff such as a tutor, lecturer, or course coordinator to lodge academic or behavioural concerns about the student they teach. The referrals are then handled by a dedicated team at the Centre for Learning and Teaching Enhancement to contact, analyse and plan methods to guide the student, implement them, and leave traces of their progress with the student throughout the semester.

You might be curious about our decision not to opt for an automatic detection system in favour of the "manual" referral-based approach. It's important to note that both referral-based approaches and automatic detection systems come with their own set of pros and cons when it comes to identifying at-risk students in an educational institution. The effectiveness of each method can vary depending on the specific context, resources, and the goals of the educational institution. In our assessment, we concluded that the referral-based approach aligned more closely with our specific needs and objectives. I won't get into the details because I want to focus on the technical details of the system instead.

System Architecture

The architecture of EARS is illustrated below. It's important to clarify that the depiction of the physical server in the diagram does not literally represent a singular physical server. Instead, it represents an instance of the server application. It's noteworthy that multiple server instances, running various applications, can coexist on the same physical server.

The decision to separate the web API server from the web application server stemmed from the desire to maintain the simplicity and compactness of each component. This approach also facilitates the independent modification and deployment of both the frontend and the backend, empowering different team members to concentrate on the components they are most proficient with.

Web API server

The API server is the backbone of the system which integrates with every other component in the system. It grants authorized users or applications controlled and consistent access to features and data through its RESTful APIs. It implements the core business logic of the system, such as how a referral is handled, and coordinates components to to ensure their accurate execution.

Designed to be stateless, the API server offers several advantages:

• Instances can be shut down and restarted without concerns about losing state.
• Each instance operate independently and do not require a mechanism for sharing state.
• They can recover from failures and disruptions simply by restarting whenever necessary.
• The server can easily achieve horizontal scalability by effortlessly spawning new instances.

Web application server

The web application server essentially operates as a static file server, delivering client-side assets such as HTML, CSS, JavaScript, and images to facilitate user interaction via web browsers. The client-side application, developed using React.js and employing client-side routing as a Single Page Application (SPA), engages with the API server through asynchronous API invocations. SPAs are particularly advantageous for internal tools like this due to the following reasons:

• Internally used web applications don't necessitate optimization for search engines.
• SPAs easily enable the caching of client-side assets for subsequent visits, enhancing the application's responsiveness and reducing the need for repeated downloads.
• Assets served from an on-premise server, situated closer to the user within the intranet, contribute to faster downloads. This minimizes the initial loading time of the SPA.
• SPAs facilitate a more seamless user experience by eliminating the necessity for full page reloads during route changes. Leveraging client-side routing allows for dynamic updates, enhancing user interactions and overall application usability.

Background task handler

Not depicted in the diagram is a component responsible for periodic checks on the expiration status of referrals. A referral is deemed expired if the initial contact email sent to the student goes unanswered for a configurable period, typically set at 2 weeks. Upon expiration, the system is designed to automatically alert the referrer, notifying them of the referral's expiration due to lack of response. Additionally, the system provides actionable suggestions for the referrer to consider in further addressing the situation.

Reverse proxy

The reverse proxy plays a crucial role in establishing a unified access point, seamlessly consolidating interactions with separate backend components. By assigning a single domain and routing to components based on paths like /api/*, the reverse proxy efficiently directs traffic behind the scenes. Additionally, it serves as the endpoint for HTTPS termination, eliminating the need to configure HTTPS individually for each component.

The internal architecture retains flexibility, allowing for changes as long as the exposed URL remains consistent across internal modifications. Traefik, chosen as the reverse proxy, offers valuable features for integration with Docker Swarm. Its capability to automatically discover containers and route traffic based on configurations specified in the Docker Swarm file, using container labels, enhances the system's adaptability and simplifies the management of dynamic containerised environments.

Database Management System

Relational databases stand out as a highly effective solution for storing and managing data in most scenarios. I firmly advocate for the use of a relational DBSM unless compelling reasons necessitate the adoption of a non-relational DBMS. The robust capabilities of relational databases, including their structured data management, adherence to ACID properties, and support for data integrity and normalization, make them a dependable choice for a wide range of applications. The preference for a relational database by default ensures a solid foundation for data organization and management, fostering consistency, reliability, and the advantages of a well-established technology. For EARS, MySQL—a relational DBMS—has been deliberately chosen to align with the requirements of the application.

It's crucial to note that while I strongly advocate for relational DBMSs, I recognise the importance of adapting to specific use cases with non-relational databases. In practice, I also incorporate non-relational DBMSs when their features align more closely with the requirements of certain applications.

Other components

Authentication for the system seamlessly integrated with FNU's underlying authentication system, ensuring a secure and streamlined user access process. The email server utilised was Microsoft Outlook 365, providing a robust communication platform within the system. Student data was sourced directly from FNU's system, ensuring accuracy and consistency. For efficient management, the applications were containerised and handled using Docker Swarm, facilitating a well-orchestrated deployment and maintenance process.

Client-side Application Design

In the realm of product development, the significance of user-experience design comes to the forefront. It serves as the initial gate, decisively shaping whether a product is embraced or left behind. The user experience stands as the pivotal factor that can either secure adoption or lead to abandonment. Shifting away from a narrow focus on the tangible aspects of the user interface, my focus turns towards the broader goal of the design, which revolves around minimising friction. This overarching objective underscores the importance of creating a seamless and user-friendly journey, ensuring that interactions with the application are intuitive, efficient, and devoid of unnecessary obstacles.

Organise information

Effectively organising information within a user interface is crucial for optimal user experience design. Recognising the hierarchy of information is key to guiding users through the application, allowing designers to emphasise crucial details and de-emphasise less significant elements. This visual communication aids users in focusing on the most important aspects, contributing to a more intuitive navigation experience.

Emphasis and de-emphasis techniques, including the varied use of font size, colour, and formatting, direct users' attention to essential components, enhancing visual appeal and usability. Simultaneously, chunking information into manageable sections prevents overwhelming users with excessive details. This strategic approach enables users to effortlessly find and consume information at a glance.

Make it intuitive

To achieve an intuitive design, familiar elements of conventional design, such as the positioning of navigation menus, sign-in/sign-out buttons, and content are deliberately reused. Consistency with other FNU applications is maintained, encompassing color palettes and layouts, establishing a sense of familiarity and cohesion across the user's digital experience. The representation of the referral handling process and its various stages is thoughtfully integrated into the user interface, enhancing user understanding and engagement.

Minimise effort required

For applications that require a lot of input from the user on a web form like EARS, minimising inputs and typing requirements within the application can significantly improve the overall user experience. This streamlined approach reduces the time and effort needed for users to complete forms and engage with the application. The thoughtful integration of autocomplete suggestions further enhances user interactions by providing quick and accurate suggestions, while minimising typing errors for inputs like student IDs where human errors can easily occur. This commitment to simplicity and user-centric design principles aligns with the broader goal of minimising friction in client-side application design, ensuring a positive and engaging digital journey for users.

Summary

EARS emerges as a comprehensive web application designed for academic staff at the Fiji National University. The decision to prioritize a "manual" referral-based approach over automatic detection aligns with the institution's specific needs, showcasing a nuanced understanding of the diverse methods available for identifying at-risk students. This strategic choice serves as an early lesson in tailoring technical solutions to unique institutional contexts.

The architecture of EARS exhibits a modular design, separating the web API server from the web application server for flexibility and independent development. The implementation of Traefik as a reverse proxy which integrates directly with the container orchestration tool underscores a key lesson in facilitating adaptability, allowing seamless changes in internal architecture while maintaining a consistent user-facing URL. This design choice offers valuable insights into the importance of system flexibility and scalability.

Reducing friction played a pivotal role in facilitating a seamless onboarding experience for users, enabling them to swiftly engage with the application and contribute to the support of students. The meticulous incorporation of familiar elements, consistent layouts, and recognisable patterns ensured that users could intuitively navigate, operate, and access the necessary information effortlessly. By seamlessly integrating the steps of the referral process into the UI design, users gained a comprehensive understanding of the workflow, anticipating subsequent stages without the need for verbal explanations. The success of both system and user-experience design fostered a positive and efficient user interaction that furthered the overarching goal of supporting students effectively.