Case Study: Radio Program Analysis App for Swiss Federal Government Agencies

The world of web development solutions is vast. Therefore, there is no need to limit oneself to the path of technology. Simply put, by exploring and learning new approaches, one can grow and evolve as both a person and a developer.

 

One of the brilliant projects that the team was able to step into unknown territory and explore various approaches to creating an app, resulting in great joy and rewards, was the construction of a Radio Program Analysis app in collaboration with LINK Institute.

 

Just to clarify, this is not another case study on Jamstack.

Rather than a typical walkthrough-style case study, we wanted to approach this one differently. So, we spoke with Kai Wasternack, the head of the IT development department at LINK Institute, about the challenges, highlights, and solutions encountered during the radio program analysis app project.

 

 

Hello Kai. So, what are you in charge of / what does your company do?

 

Link Institute is the market leader in market research and social research in Switzerland. In my IT development department, we provide software as needed and support researchers. As the head of IT development, I make decisions on the planning and design of software and write code with three colleagues.

 

What is the project for the radio program analysis app?

 

One of our clients wanted to perform and maintain a detailed analysis of Swiss radio programs and needed a simple and attractive solution. This project had two aspects: recording and analysis. For recording, they needed the option to track radio programs from five public broadcasting stations on randomly selected recording days throughout the year.

 

In the analysis, we listened to the recording, followed the information, and classified it into pre-set categories (news, weather, music, etc.). Each category has its own subcategories, and there are complex rules of dependency between them.

 

The Project Manager in charge of this project requested the IT department to build software that supports the analysis process, provides a user interface to play back recordings, display different (sub)categories, and manage their interdependencies.

 

Did you create the app from scratch?

 

No. This survey was conducted by another provider who relied on desktop applications in the past. While it was not a bad approach, we believed that a web application would be a much better approach and could solve many of the issues they experienced.

 

In addition, solutions based on browser-independent web applications have many benefits for IT support as they are not affected by the rollout of releases.

 

In order to perform the complex task of analyzing radio programs, an efficient user interface is absolutely necessary. Additionally, a simple solution for managing user permissions was also needed.

 

What is our role in this project?

 

The decision for the web application was made at a very early stage. However, it was also understood that there were not enough resources within the company's development team to implement both the front-end and back-end simultaneously.

 

Our development team has extensive knowledge in C# and SQL, while on the other hand, you have great knowledge in designing and implementing web front-end, especially in React-based ones. This made our decision clear.

 

We use SQL Server for data storage and React for front-end technology. Communication between the front-end and back-end is done through REST services implemented in C#.

 

Yes, most of them are React apps built on top of Umi.js, an extensible enterprise-level frontend application framework. We also used dva.js, a global state solution, as a component of Umi.js. For the visual layer, we used Ant Design. This React UI framework already has many components available, so we didn't have to write a lot of styles.

 

Are there any difficulties?

 

The most challenging part was the coding section in the radio view. In this view, it was necessary to connect the Media Player and Table of Log. To understand this process, let me explain the main workflow.

 

Each media file (usually 5 hours of recording) has a list of logs. The log is a media record fragment that contains data on start time, end time, and values for each form field. While playing the media file, when reaching the appropriate log, a mark is automatically added to this log on the table, resulting in the need to input all fields in the form.

 

This is a huge React component that has many child components internally. As you can imagine, there are many props, Redux actions, and internal states. The main issue was how to save performance as these small components are re-rendered multiple times.

 

Another issue was the idea of leaving the form validation rules on the backend. After handling these validation rules, we ran into a major problem with re-rendering each form field (updating values). This validation idea came up after constructing the component structure, so there was a lot of code restructuring and addressing other rendering/refresh issues.

 

Certainly, it may have been possible to do better. I think there are many places where the entire code structure needs to be improved/refactored in order to reduce the number of re-renderings.

 

What happened with the results, leaving my story aside for now?

 

Education for analysts began 6 months after development started. Currently, 20 analysts are working on 350 hours of radio broadcasts simultaneously.

 

When playing a game, the ultimate goal is to clear it. However, the subquests you take on, which are quests that aim to help you clear the game, make the game even better.

 

Stepping into the wilderness of app development was truly a subquest for us.