Case Study: Radio Program Analysis App for the Swiss Federal Government Agency

The world of web development solutions is vast. Therefore, there is no need to stay on the technical path. In simple terms, by exploring and learning new approaches, we grow and evolve both as individuals and as developers.

 

Building the Radio Program Analysis app in collaboration with LINK Institute is one of the shining projects where the team ventured into unknown territory, explored various approaches to app creation, and as a result, gained great joy and rewards.

 

I would like to clarify in advance that this is not another case study of Jamstack.

Instead of a typical walkthrough case study, we wanted to approach this differently this time. Therefore, we spoke with Mr. Kai Wasternack, the head of the IT development department at LINK Institute, about the challenges faced, enjoyable moments, and solutions found during the radio program analysis app project.

 

 

Hello Kai. Without further ado, 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 the IT development department to which I belong, we provide software as needed and support researchers. As the head of IT development, I decide on the planning and design of software and write code together with three colleagues.

 

What is the project for the radio program analysis app?

 

One of the clients wanted to conduct and maintain a detailed analysis of a Swiss radio program and needed a simple and engaging solution. This project had two aspects: recording and analysis. The recording required an 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 recordings, adhered to the information, and categorized them into pre-set categories (news, weather, music, etc.). Each category has its own unique subcategories, and there are complex dependency rules between them.

 

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

 

Did you create the app from scratch?

 

No. This survey was conducted by another provider that relied on desktop applications in the past. While that was not a bad approach, we were confident that web applications are a far superior approach and can solve many of the issues they experienced.

 

Furthermore, solutions based on browser-independent web applications offer many benefits for IT support, as they are not troubled by the rollout of releases.

 

To perform the complex task of analyzing radio programs, a user interface that is as efficient as possible is absolutely necessary. Additionally, a simple solution for handling user permissions was also required.

 

What is our role in this project?

 

The decision for the web application was made at a very early stage. On the other hand, it was also understood that there were not enough resources in the in-house development team to implement both the front end and back end simultaneously.

 

Our development team has extensive knowledge of C# and SQL, while on the other hand, you have excellent knowledge of web frontend design and implementation, especially with React-based solutions, so our decision was clear.

 

We use SQL Server for data storage and React for front-end technology. Communication between the front-end and back-end is handled by a REST service implemented in C#.

 

Yes, that's right. Most of it is a React application built on Umi.js, which is a scalable enterprise-level front-end application framework. We also used dva.js, which is a global state solution and a component of Umi.js. For the visual layer, we used Ant Design. This React UI framework already provides many components, so we didn't need to write a lot of styles.

 

Were there any challenges you faced?

 

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

 

Each media file (usually a 5-hour recording) contains a list of logs. The logs are media record fragments that include some data regarding the start time, end time, and the values of each form field. While playing the media file, when you reach the appropriate log, this log will be automatically marked on the table side, resulting in the need to fill in all fields of the form.

 

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

 

Another issue was the idea of leaving the form validation rules on the backend side. After processing these validation rules, we encountered significant problems during the re-rendering of each form field (value update process). This idea of validation emerged after constructing the component structure, so there was a lot of refactoring of the code structure, and we also had to address other rendering/refresh issues.

 

Certainly, I could have done better. I believe there are many areas where the overall code structure can be improved/refactored to reduce the number of re-renders.

 

Putting my story aside for a moment, what was the outcome?

 

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

 

When playing a game, the main goal is to clear it. However, the side quests you undertake, which aim to help you achieve that goal, make the game even better.

 

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