- 4 min to read
Case Study: Radio Program Analysis App for Swiss Federal Agency
Though we are Jamstack focused web dev shop sometimes, for some of our clients, we step out of our comfort zone to work on interesting projects like Radio Program Analysis App that we built for a Swiss federal agency.
By Gracjan Opiela
The world of web dev solutions is huge. And you don’t have to stay on the beaten paths of the tech, you know. Simply put, by exploring and learning new approaches, you grow and evolve both as a person and developer.
Building an app for Radio Program Analysis in cooperation with The LINK Institute is one of those shiny examples of us as a team venturing into the unknown, exploring different approaches to app building, and find great pleasure and reward from doing it.
Before you continue, I have to warn you: this is not another Jamstack case study of ours. But don’t be put off by that.
Instead of the usual walkthrough case study, we wanted to do this one differently. So, we sat down (actually video chatted and shared notes) with Kai Wasternack, Head of IT Development Department at LINK Institute, to talk about the Radio Program Analysis app project, problems we faced, the fun we had, and solutions we’ve found.
Join our newsletter
Get EXCLUSIVE web development case studies in your mailbox!
Hi Kai….thx for doing this. Now, what is your role/what does your company do?
The LINK Institute is the Swiss market leader in the market and social research. My department, IT Development, supports our researchers with software whenever needed. As head of IT Development, I make the software planning and design decisions and write the code together with my three colleagues.
What is the Radio Program Analysis app project about?
One of our clients needed an easy and elegant solution that would help in running and maintaining a detailed analysis of the radio program in Switzerland. The project had two parts, recording and analyzing. Recording meant they needed an option to follow and record the radio program of five public stations at the randomly selected recording dates during the course of a year.
The analyzing process is done by listening to the recording, adhering to the information, and putting them into predefined categories (News, Weather, Music, etc.). Each category has its unique subcategories with complex dependency rules between them.
The LINK researcher in charge of the project asked the IT Department to build a software that would support the analyzing process by providing a user interface that replays the recording and displays the different (sub-) categories, and manages their dependencies to each other.
Did you build the app from scratch?
Nope. This study has been conducted in the past by a different provider who relied on a desktop application. Nothing wrong with that, but we were confident that a web application is a far better approach that would solve many issues they experienced.
Besides, a solution based on a browser-independent web application is always less troubling for our IT Support because they don’t get bothered about release rollouts.
We were certain that we needed a user interface as lean as possible for the complex task of radio program analysis. And we needed an easy solution to handle user permissions.
Bejamas to the rescue. What was our part in this project?
Well, the decision for a web application was made very early. At the same time, we knew we wouldn’t have enough resources available in our internal development team to implement front and backend at the same time.
Our development team has strong C# and SQL knowledge, and you guys have great knowledge on the web front end design and implementation, especially React-based ones, so our decision was clear.
We would use SQL Server as data storage and React as front-end technology. The communication between the frontend and backend would be done by a REST service implemented in C#.
I think you, Gracjan, can explain it a bit more.
Right. For the most part, this is a React app built on Umi.js, an extensible enterprise-level front-end application framework. We also used the global state solution dva.js since it is a component of Umi.js. For the visual layer, we used Ant Design because this React UI framework already has a lot of ready to use components, so we didn’t have to write so many styles.
And the challenges you guys had?
The biggest challenge was a coding section in the radio view. In this view, we had to connect the Media player with the Table of logs. To better understand this process, let me describe the main workflow.
Each media file (usually 5-hour records) has a list of logs. The log is the media record fragment with some data about startTime, endTime, and values for each form field. Basically, when a media file is playing, when we hit a proper log, we should automatically mark this log in the table and fill all fields in the form.
Under the hood, this is a huge React component with a lot of children components. As you can imagine, there are many props, Redux actions, and internal states. So, the main problem was to save performance in this view because all these small components were re-rendered many times.
Another problem was the idea of keeping the form validations rules on the backend side. Once we handled these validation rules, we hit a big problem with re-renders on each form field - refreshing values process. Because this validation idea was brought up after we built the components’ structure, we had to do a lot of refactors of code structure and met other rendering / refreshing problems.
And yes - we could have done this better. I think that there are many places to improve/refactor the entire code structure to get fewer amounts of re-renders.
Enough talk from me. Results?
Educating the analysts on the app started 6 months after development kicked-off. Today, 20 analysts are working simultaneously on 350 hours of radio broadcast.
When you play a video game, the biggest goal is to finish it. But those sidequests you take, the ones that make you go above and beyond to complete, make the game so much better.
Stepping out into the wild of app making was that sidequest for us.
Need help with your website or an app? Let’s talk!
CLICK HERE to schedule a 1-on-1 talk and let us show you what we can do for you and your business.
