The Indian Ocean Island Gamesis an annual highlight for Fabrik customer, Seychelles Broadcasting Corporation–who have secured an app for each of their radio stations, the Creole-language based Radyo Sesel and the English-language-based Paradise FM. Whilst coverage was provided on-air in regular news and sports inserts, in 2019 the stations created a dedicated app-based feed to provide more real-time coverage of the games within the Paradise FM and Radyo Sesel mobile apps. These channels were set up so that only authorized members of the team could post content in the channel, opting for the informational or ‘broadcast’ mode rather than the typical conversational format. This content related to updates on the Seychelles team, audio and video clips of the events and images of the event. Key Findings •Monthly Active Users increased to 160% on Paradise FM and 148% on RadyoSesel. •Monthly App Visits increased by 223% on Paradise FM and 205% on Radyo Sesel. •In-App Live Streaming increased by 288% for Paradise FM and 300% for Radyo Sesel. •The opening Announcement for the games caused a spike in Radyo Sesel in-app listening. This message was delivered as a direct alert to the IOIG channel within the app.

Smile 90.4FM completed a successful Xmas in July campaign where they mentioned keywords related to Christmas on-air and prompted the audience to enter the keywords either via premium SMS or through their Fabrik powered mobile branded app. The campaign ran for 2 weeks in July and was managed via the Fabrik campaign manager which selected random winners during each show. All analytics were done using the Fabrik reporting engine. Key Findings: •A total of 396309 messages were received by the station across all channels,with75% received via the app. •Monthly Active in-app users doubled during the campaign. •In-app live streaming increased 3-fold during the campaign.

South African full-service technology company, immedia, has invested R10-million ($684, 230) with the aim of helping African media entrepreneurs to build sustainable community radio. This will be accomplished through the use of Fabrik, a set of cloud-enabled digital tools that empower media entities to live-stream shows, grow and engage with audiences around the world whilst benefitting financially through the monetisation of their audiences. Read more

Durban-based tech company, immedia has invested R10-million to help African media entrepreneurs to build sustainable community radio by using Fabrik, a set of cloud-enabled digital tools that empower media entities to live-stream shows, grow and engage with audiences around the world, and benefit financially by monetising their audiences. Read more

We are living in the age of online platforms, and most brands are increasingly seeing the value of having a mobile App as part of broadening their reach and tapping into the new age consumer. Having a mobile app for your business gives you the power to influence how and when your app members consume the content you share with them, and it also gives you the control to protect your app member's data as we gravitate to the age of POPI. Like every touchpoint for your brand such as your website or social media, the app needs a clear content strategy that is aligned to your business goals and objectives whilst staying true to the essence of who you are as a brand. Having an app is an amazing addition to your consumer engagement strategy. That strategy needs a clear and concise content strategy to support it. When this is done right, you will experience an increase in app downloads, app registrations, and member engagement - thus adding value to your consumer engagement strategy. Here's a summary guideline that can add benefit to your own content strategy: 1. Set out clear goals Setting goals is the starting point in any content endeavour you choose to undertake. Having a goal helps you create a foundational structure of where you want to go content wise and how the journey will look. Even the simplest content strategies have set goals - this is what sets the tone, and informs the type of content that needs to be created, thus helping create content that will an impact on your app members. The goals of your content strategy will vary, and might include: Increase the in-app Conversation and Channels member count Brand/app awareness Increase app downloads Increase app registrations Greater user retention rate Increase app member engagement. These are just a few examples — when you create content, bear these in mind throughout, and your strategy will have greater resonance as a result. 2. Clearly define your app target audience One of the most important principles of building a successful content strategy is to know your app members. This forms the foundation of every good mobile app content strategy too. What is important is seeing your app members as personalities for whom you can create tailored content for unique needs and interests. For instance, if your app members prefer a certain social platform over another, you could add that site as a provider on your Smashboard to see and respond to all messages received. Another great way to gain an understanding of who your audience is and what makes them tick is to create surveys geared to give insights into their personality. 3. Write content with a tangible hook As content creatives, we often produce our content with a consideration of the medium on which the content is being consumed. Because the app is on a mobile device, we might assume that most app members are less likely to engage with lengthy blog posts. That assumption is a bit far-fetched because app members or content consumers in online platforms are quite happy to read long-form content via a mobile app if it is engaging. To provide a teaser, share a summary of the article linking to your website so that you can kill two birds with one stone. If you want your audience to engage with the content from the first paragraph to the last word, you need to entice them with interesting content throughout. One way of maximising this would be to add content that is trending in another platforms. 4. Deliver fresh and diverse content As an app content creative, a vital intention is to keep your app members coming back in the app and spend time consuming the content in the app. This means you need to be creative in the pillars you choose to focus on in terms on the content you decide to publish to your audience. The precedence here is when app members keep getting exposed to the same content repeatedly, they become disengaged and, as a result, they decide not to come back in the app or read or listen to your podcast for a few seconds and disconnect from the app. The best strategies lead the charge in diverse content pillars to keep your app members stimulated. The best content strategies embrace a diverse array of content formats to keep audiences stimulated and engaged, and your mobile app’s content strategy is no different. Some of the content pillars you can get started with for your mobile app. Example include: Product sneak peeks: mobile apps are a terrific way to source app member feedback. Offer teasers for new products and invite customer input via in-app surveys. Here you can partner with a potential advertiser to give them brand awareness. Product tutorials: value is key in your mobile app content strategy, and how-to and explainer videos are perfect for delivering that straight to your audience. More on content pillars here: Creating Killer Content Pillars 5. Use metrics to guide and hone your content strategy One of the key benefits of having an app is the fact that it gives you real-time insightful result to report on and, in this case, helps you create content that is heavily consumed. For example, if one live podcast gets more plays, find out what the discussion around that podcast was about and use that as a pillar for creating content. Better yet, use the four most-played content as a foundational pillar for the next round of podcasts you add. If your audience engage heavily with news posts in the news channel, take note of what news content they reacted to mostly and in future instead of just having a post, include a podcast of it and it link on your socials. Lastly, if you are uncertain about how to create an app content strategy, contact us - we can help!

A developer’s view of the journey as we prepare to launch our newest Fabrik application to the world. Data - we all have it and it's our job as developers to try to figure out where to put it. Furthermore, businesses and teams are all trying to extract valuable insights from this data, which is easier said than done.  At immedia, we are not exempt from this rule and have spent our fair share of time wrangling our data to try and highlight key insights for the clients of our Fabrik platform. Metrics, Fabrik's new analytics and data visualisation tool, was born from the desire to consolidate our previous efforts in surfacing our data into a single self-service portal that would not only present informative data, but surface it with expedition. As a developer who’s been instrumental in building Metrics with cost, scale and speed in mind, I’ve been taught many lessons along the way – and I’d like to invite you along for a glimpse into my journey so far. In the Beginning The wilderness awaits When evaluating the data in any system you will generally find an assortment of formats: structured, unstructured, text, tabular, binary, some API endpoint written by a person that left three years ago (and also didn’t care that you would be using it today) – a primordial soup, if you will. This wilderness that is set before you can seem daunting but, much like mowing your lawn after a year, the reward is well worth it when you smell the freshly-mowed grass or enjoy a languorously luxurious picnic between neatly arranged flower beds and carefully planted rows of trees. Metrics started with these questions: Where do we need to trim our lawn and neaten up the hedge? What flowers do we need to get; are roses the best choice for our climate and budget? Where will we place our short flower beds and our tall trees? And most importantly – who will be coming to the picnic? Or more simply, data is used to answer the 5 W's: who, what, why, when and where? For Metrics, whilst planning our garden, we came up with the following key questions that we wanted to answer in the initial release candidate: (who is)/(when are they)/(what are they using when)/(where are they when) listening to the live stream of the client? (who is)/(when are they)/(what are they using when)/(where are they when) using the client’s mobile application? when is the client’s application downloaded? As for the ‘why’ – while the subjectivity of that question and the requirement for verification of the various possible answers can halt a project before it even begins, sometimes, the answers quickly reveal themselves. For instance, what we’re currently observing with Metrics is that our clients’ live-streaming and engagement have seen an upward trend over the last few weeks, which would most likely be attributed to a population currently in lockdown during the COVID-19 pandemic. Find Your Source The source is within you – or, at least, somewhere Once our questions were established, it was time for us to identify from where our answers would come. As alluded to in the previous section: in any system, there will be multiple sources of data available and the selection of the source is a process. It may require some trial and error before you find a source that appropriately answers your question. We’ll skip over the boring stuff here and outline the sources that we eventually identified: Streaming Audio streams are served from HAProxy which provides us with configurable log output options. We used these to configure the logging to output what we need to answer our questions. We’ll get to how we parsed this information in a later section of this post. App Engagement How people use the services and engage with content is tracked via Matomo. Matomo provides a powerful API for retrieving the tracked data. What’s more, it provides our members with total privacy. Application Downloads App download numbers are retrieved via the Apple App Store Connect API and Google Cloud Storage API. Both provide us with files in CSV format. We’ll talk about how we used these in a later section. Laying the Groundwork Foundations are important Now that we knew what we were solving for, and from where we would be retrieving our answers, we needed to decide on which approach we would take for processing, storing and displaying the data. We vetted some options and finally decided to use Azure Databricks as our data processor with Scala as our data processing language. Azure Databricks provides us with an Apache Spark cluster that we can scale on demand to meet workloads. It’s also fast. Very. Very. Fast. For storage of our processed data, we identified Azure Cosmos DB and Azure Storage; Azure Cosmos DB for its ease of storage and retrieval of data (with a familiar SQL-like syntax) and Azure Storage for cost effective storage of files. The data in Matomo was already being stored in a MySQL database which we don’t need to query directly because Matomo's API already provides us with all the data we need. We would have a .NET Core API serving as the gateway between users and the stored data and an Angular application that would serve as the frontend. With the outline of our garden in place we felt confident that we would be able to tame the wilderness set before us and we were ready to get started planting and arranging our flower beds. THE PEOPLE BEHIND THE DATA A key part of building a tool that provides insights on how humans are using the tool, is being respectful of the humans themselves. Before we jump in to all the technical details, it is important to note that at immedia we hold the privacy and data rights of the people that use our platform in high regard. This means that we are always thinking about what needs to be done to ensure that data is properly anonymised before surfacing it to the people who use the platform. Metrics fully anonymises the data before it gets surfaced. Anything that can be used to identify a user is removed. For instance: when processing our streaming data we perform a one way hash of the IP address of the request before all of our data processing is performed. Furthermore, Matomo, our analytics engine, has user privacy baked into its design and also discards identifiable information as soon as it can. Streaming From logs to lines Our pipeline for importing streaming data works roughly as follows: Every hour a log file is rotated on HAProxy and uploaded to Azure Storage via the post-rotate hook. We read these log files into our Azure Databricks environment via a streaming query. The log files are processed, and relevant information is extracted and inserted into Delta Lake tables. Identifiable information, such as IP addresses are dropped before we write to Delta Lake storage. We have another pipeline that will run and create rollups of our data for use with frontend applications, which roughly works as follows: It calculates the peak number of listeners for all the newly created sessions per minute and saves the result to Delta Lake storage. It then creates rollups of all our specified periods and stores it in JSON format in Azure Storage – we’ll look at some examples of this soon. Lastly, we have a pipeline that will: calculate and store peak, total and unique listeners for different periods of time, and write the entries to Azure Cosmos DB. Exploring Streaming Results Summary Data Calculation of the summary data is merely done as an aggregate count or sum over the period of the rollup. For instance, 'Total Sessions' is calculated as a count and 'Total Days' is the sum of all streaming session lengths. Streaming Numbers Streaming numbers are calculated as an aggregate over the size of the granularity specified. In the graph above, 'Total Sessions' is the count of all listens per day, 'Total Unique Listeners' are the number of people who listened per day, and 'Peak Concurrent' is the maximum number of listeners for that particular day. These are stored in Cosmos DB which allows us to search and display arbitrary ranges. Streaming Numbers by Hour Streaming Numbers By Hour are calculated as an aggregate over the hour of day for sessions. This graph depicts the sum of all hours, the count of sessions streamed by listeners, the number of people who listened per hour, the count of sessions that were started, and the count of sessions completed per hour. Streaming Session Length Breakdown Session Length Breakdowns are calculated by using the Bucketizer class in Scala. We count the amount of sessions for every single duration ranging from 1 minute all the way to 18 hours. The frontend displays this as a pie chart, while the raw rollup data looks as follows: Summaries By Dimension Summaries By Dimension are calculated as a group by aggregate over session data. For instance, the 'Total Sessions' section lists the count of sessions grouped by each source, displayed from highest to lowest. App Engagement While statistics that describe how people use the Android and iOS apps is an exciting part of our data for our clients, it was much less exciting in terms of the data transformation work to be done. In essence, we query the Matomo API and display the data on the frontends. Luckily for us, Matomo did the heavy lifting in this regard and our biggest concern was displaying the data. App Downloads Our pipeline for application downloads works roughly as follows: An Azure Function App retrieves the CSV files from the Google and Apple APIs respectively. The function app does some slight preprocessing on the files and then stores them in Azure Storage. These CSV files are read into our Azure Databricks environment via a streaming query. Databricks does some processing on the data and writes the results to Cosmos DB. The result of this pipeline is that we can query App Downloads for any arbitrary period. The summary data is calculated by running an aggregate count query against our Cosmos DB container. The charts are rendered by querying Cosmos DB and displaying the entry of each day. The summary data is calculated by running an aggregate count query against our Cosmos DB container. The charts are rendered by querying Cosmos DB and displaying the entry of each day. Live Data Initially one of our goals was to surface data and surface it with speed. Up until this point we have only discussed static rolled-up data and the exploration thereof. Whilst this is useful for doing some rudimentary analysis after the fact, these stats are not able to tell our clients what is happening right now. In other words: we haven’t checked expedience off our list. To surface live data, we had to do some out of the box thinking. Processing log lines in real time wasn’t feasible as we only rotate the log every hour (unless of course you deem an hour ago as “live”) and we couldn’t really speed up the rotation. Live Stream Listeners For stream listeners there are two distinct types. HLS streams and Icecast streams and both of these required a unique approach to surface the live listener data. For HLS we wrote a .NET Core application that we deployed to our HAProxy server. This server checks the HAProxy Stick Table for the listener count of the tenant. We initially tried the HAProxy Stream Processing Offload Engine but this went bad – very bad – as it could not handle the amount of requests our servers were doing. In the end we got it working along the following lines: Our .NET Core application runs a command to check listener counts on the HAProxy Stick Table. It sends the listener count over Azure Event Hubs. An Azure Function picks up the event hub message and stores it in Redis (we keep about 2 hours of this data in Redis). We query Redis to show live stream data. Icecast was slightly simpler to retrieve the live listener count for, as it exposes administration endpoints that return XML data. The process is roughly as follows: An Azure Function imports the listener count from Icecast. We store the listener count in Redis. We query Redis to show the Icecast stream data. Live App Visitors & Engagement Retrieving the live app engagement numbers follows a very similar pattern to the Icecast listener count imports. We rely on Matomo’s reporting to achieve this. The process is roughly as follows: An Azure Function imports the current live visitor count and the actions taken in the last minute. These values are stored in Redis. We query Redis to show the App Visitor data. Events Prior to our Metrics application, Fabrik already had an Azure Event Hub to which it would report events. The reported events are retrieved via an Event Hub Listener. The process is roughly as follows: An Azure Function listens for events on the Event Hub. It stores the events in Redis. We query Redis to show the event data. The example above is during a relatively quiet hour – it can get crazy at time as seen in the screenshot below. The Road Ahead Growing our garden All things considered, the creation of Metrics has been quite a journey for us and we have learned a lot about what it takes to build a data pipeline that is cost effective and scalable. We aren’t planning on letting the weeds grow in our data garden over the next few months either - our clients have multiple new features to look forward to that are sure to teach us new lessons and provide greater insights into our data. Our mission to figure out what data we have and where we want to share it is a lot closer to being complete, but will never be completely so. We hope that we can keep delivering valuable insights to our clients and help you answer some of your operational questions going forward by delivering new insights to you. This journey is not yet over and we’re excited and ready to take on the future of Metrics.

Modernising our native Android and iOS codebases by migrating to Kotlin and Swift. As developers contributing to and maintaining the Android and iOS mobile apps that make up immedia’s Fabrik platform, there are a number of things we expect to happen during the lifespan of the mobile apps we deliver. Bugs will arise, new features will need to be ideated, and both Apple and Google will release major updates to their operating systems - to which our apps will be required to adapt. At each of these junctures, we’ll need to respond quickly as, of high importance to ourselves and our clients, is the guarantee that as environmental challenges evolve, so do our mobile apps to meet these challenges. At a high level, there are 4 areas of coding support that Fabrik apps receive: Corrective, better known as bug fixing. Adaptive; adapting to the latest hardware and OS changes. Perfective; dealing with changes in user requirements. Preventative; code restructuring & optimisations aimed at reducing complexity and preventing future errors. The first three areas are fairly self-explanatory and commonly practiced as our team works hard to ship regular app updates for our Fabrik clients with the latest bug fixes and improvements, additional feature enhancements and finally, updates required to become compliant with the latest OSes. However, as developers, we don’t readily reveal the ‘preventative’ part of what we do i.e. the behind-the-scenes code improvements, re-writes and optimisations that are implemented on an ongoing basis. In this blog post, we offer some insight into what that looks like for Fabrik in particular, and how we’re working to ensure the longevity of our product through modernising our mobile app codebases. When immedia’s development teams started to build Fabrik’s Android and iOS apps, the Objective-C coding language was initially used on iOS whereas Java was used on Android. Since then, alternatives from Apple (Swift for iOS) and Google (Kotlin for Android) have matured and become the gold standard for developing apps on their platforms. Now, any new app developer just starting out will default to using one of these newer languages rather than the 36-year old Objective-C or 20-year old Java. Swift is one of the fastest growing languages in history and, in 2019, Kotlin became Google’s preferred choice for Android development. One of the key benefits of these languages is that they can be used in conjunction with their predecessors. On Fabrik, the code is currently a combination of the old and the new, and our endeavour now is to future-proof our source code as much as we can and systematically re-create as much code as possible into Swift and Kotlin. However, for some features this interoperability does take some effort, so in order for us to keep delivering new features and app enhancements in the future, we’ll need to allocate time now to preventative maintenance with an expanded effort around code rewrites and optimisations. We will move quickly to ease out the historical languages in favour of the modern counterparts, so that our platform will continue to be operational today and for years to come. When we end this journey, our apps will be more efficient and less error-prone, which will make our investment of time and effort into these code migrations worthwhile. For the most part, Swift and Kotlin share the same ideologies and will deliver much of the same benefits on their respective platforms. Here are a few key points on why we’ve chosen to make these transitions: 1. Speed The new languages are fast; for example, a simple search algorithm has been benchmarked as being 2.6 times faster in Swift than Objective-C. Historically Objective-C has never been a fast language. It’s been built as an after-thought on top of the C programming language. Which means it carries with it legacy C functions. Swift has removed the limitations of the C language. Further, Objective-C also uses runtime code compilation rather than compile time: this means that when an Objective-C object calls code in another object, it’s not a direct function call; rather it leverages message passing. The runtime determines if an object actually implements the function represented in the message. If it doesn't implement it, the class will either forward the message onto another object, or throw an exception. This is incredibly fast, but still adds an overhead which would be measurable when it happens millions of times. Swift and Kotlin benchmarks continue to improve with each update of the language. This is a key factor as it’s important to stay up-to-date with the latest releases of the language in order to reap all of the benefits. Swift currently is in version 5.2 with Kotlin at 1.4. (languages also receive updates with additional capabilities, bug fixes and improved methods of performing tasks). 2. Better Syntax The languages are lean, intuitive, easier to read and it’s more efficient to apply changes when needed. Kotlin has removed a lot of clutter and redundancy from code. Literally a class that used to be 100 lines is now only 2 lines. This aids in preventing common programming mistakes (resulting in far fewer crashes!) as the more code you have, the more it costs to maintain due to the additional overhead it brings. An example of a Kotlin feature that helps to reduce the size of the code base are Data Classes which allows the expression of POJOs with minimal code. The following showcases the original code in Java versus the Kotlin implementation. Java Class: public class Person {     private String name;     private String surname;     private String id;     public String getName() {         return name;     }     public void setName(String name) {         this.name = name;     }     public String getSurname() {         return surname;     }     public void setSurname(String surname) { this.surname = surname;     }     public String getId() {         return id;     }     public void setId(String id) {         this.id = id;     }     @Override public boolean equals(Object o) {         if (this == o) return true;         if (o == null || getClass() != o.getClass()) return false;         Person person = (Person) o;         if (name != null ? !name.equals(person.name) : person.name != null) return false;         if (surname != null ? !surname.equals(person.surname) : person.surname != null)             return false;         return id != null ? id.equals(person.id) : person.id == null;     }     @Override public int hashCode() {         int result = name != null ? name.hashCode() : 0;         result = 31 * result + (surname != null ? surname.hashCode() : 0);         result = 31 * result + (id != null ? id.hashCode() : 0);         return result;     }     @Override public String toString() {         return "Person{" +                 "name='" + name + ''' +                 ", surname='" + surname + ''' +                 ", id='" + id + ''' +                 '}';     } } Kotlin: data class Person(var name: String, var surname: String, var id: String) As you can see, Kotlin saves all of the Java boilerplate code that’s needed. 3. Improved Compiler Humans make mistakes and software has bugs. Some of the causes of these bugs can now be detected whilst coding and not only when running the app. Error messages are more precise, and the compiler is now better at pinpointing the exact piece of code that needs fixing. Further to that, code completion is faster and there is increased reliability in debugging. Lastly, building the app, whilst developing, is way quicker. One such improvement is the handling of nulls or, as it’s often referred to, The Billion Dollar Mistake. Be it Objective-C or Java, a pain point for developers is the null reference which causes runtime exceptions or apps crashing. To overcome this, Kotlin provides null safety at compile time with Swift utilising the Optional type. Code examples: Swift let number: Int? = 10 let letter: String? = "abc" Kotlin val number: Int? = 10 val letter: String? = "abc" 4. Open Source The inner workings of the language are freely available to explore, meaning that the developer community at large are constantly working on finding and fixing bugs - this is really why the language has been able to grow in stability. Today on the Swift repo there’s 104 000 commits,  27 000 merged pull requests, 8 400 forks and 341 branches. Kotlin also has astonishing stats: 65 000 commits, 1 372 merged pull requests, 3 900 forks, 3 900 branches. Both languages are actively maintained by both the original developers and the community. A side effect of this is that the languages are also available to perform other tasks. We now have Swift on the Server, Swift for Windows and many other projects and new operating systems. Whilst none of these are mature, being open source does drive the penetration of the language. 5. Industry Standard Over 50% of Android developers now use Kotlin, and Google themselves now take a Kotlin-first approach with many of their new features and libraries being offered first in Kotlin. Apple re-wrote foundational parts of their established operating system in Swift. As an example, on MacOS, the Dock (which is used to launch and switch between apps) is now in Swift. Uber’s iOS code base is now 90% Swift, and many other big apps have either already begun or completed their migration to it. Netflix, Evernote, Lyft, Twitter, Pinterest, Flipboard and AirBnB are just a few examples. Further to this there are also official communities from Podcasts to a Subreddit and even a Slack Group all aiding in taking the languages forward. 6. Future Support If anyone has learnt iOS development in recent years, they would have learnt Swift. And as time goes on, the only developers who can support Objective-C will be the senior developers who have been working on iOS for an extended period of time. The same roadmap will unfurl as developers migrate from Android to Kotlin. Whilst both Apple and Google have made their intentions clear on the way forward for development, it’s unlikely that either predecessor language will become completely obsolete. However, it will become very niche, and already some of the documentation on Objective-C development from Apple has been retired. 7. Developer Happiness This deserves a noteworthy mention. When both Lyft and Basecamp rewrote their Kotlin apps, one of the driving factors was to make a huge difference in programmer happiness. To quote one of the senior engineers at Basecamp: “Happier developers leads to great code and ultimately a better product.” In addition, they wanted to improve developer work quality and speed. In the latest Stack Overflow Developers Survey, Kotlin and Swift positioned themselves at number 4 & 9 of the most loved languages to work in respectively. At the opposite end Objective-C ranked as the second most dreaded. TL;DR: Swift and Kotlin really are better languages - they’re cleaner and less laboured than working on the legacy languages. Debugging is superior and learning advanced coding techniques is easier. Whilst all the hard work and optimisations our teams are doing may not always be visible, our clients can rest assured that we are busy building an even better product that can be enjoyed long into the future! P.S. Don’t worry - it’s not all maintenance work, and we do have some exciting feature updates planned for the next year as well so watch this space!

KC 107.7 entered a new digital world with the launch a brand new App. The biggest Radio Station in the Cape Winelands has partnered on a Digital Leap program with Durban-based tech company immedia who have invested R10m to help African media entrepreneurs build sustainable community radio. Read more

Now it has come to be known as Nkomazi FM, previously accessible only within the Nkomazi jurisdiction, but currently worldwide. Keeping up with the times, this people’s station has just launched its digital platform, which will enable listeners from anywhere around the world to tune in and be part of live shows, entertainment and news. “It’s very simple, really. All you have to do is download our app and follow the easy instructions to tune in anytime and anywhere,” said Makhosi Zulu, the station manager. Read more

There are few local tech inventions that have received international attention, despite an abundance of successful South African tech stories. However, one South African innovation is changing this narrative. Read more

Radio is facing a challenging time. Listener numbers have fallen during the pandemic, advertising budgets have been cut, and streaming is luring audiences away from traditional radio. Read more

There are few local tech inventions that have received international attention, despite an abundance of successful South African tech stories. However, one South African innovation is changing this narrative. Fabrik, developed by SA company immedia, is being used by international public broadcasters to bring audiences into the digital and social revolution. Fabrik has totally transformed and enhanced audience engagement of the publicly funded national broadcaster of the Republic of the Seychelles, the Seychelles Broadcasting Corporation. The Seychelles Broadcasting Corporation (SBC), recognising the need to capitalise on the opportunity inherent in digital transformation, have invested in modernising its offering with a full set of featured mobile apps to support its Paradise FM and Radyo Sesel radio stations. Both apps are built on the Fabrik digital platform, a cloud-based set of tools and applications - backed by Microsoft - that allows broadcast radio organisations to digitise, consolidate, and monetise audience engagement. Derrick Young-Khon, head of marketing, multimedia and corporate affairs at the SBC, says managing fake news during a public emergency like the Covid-19 pandemic has seen the SBC apps deliver tremendous value to citizens, allowing the station to provide listeners with fact-based, objective, breaking news stories from a media source they trust, in real time. “The apps have become the go-to place to get information. Firstly, because it is instant, it is in the palm of our audience’s hands, and the latest pandemic statistics are available on the app with just one click. Second, we give people credible information,” says Young-Khon. Creating cultural impact The SBC also incorporated the Truth, Reconciliation and National Unity Commission (TRNUC) sessions into the apps. The TRNUC was established in September 2018 with the aim of bringing closure to past socio-political events that had negative impacts on many Seychellois citizens. By streaming the sessions, listeners in the country as well as those abroad were able to follow the debates. “What we have provided is not just a service to the public, but to the TRNUC itself,” says Bérard Duprès, CEO of the SBC. Building a more connected and engaged audience In transitioning from traditional media to digital, the SBC already understood that the youth generation were more geared towards mobile technology. “For youths accessing information via radio apps on their phones, without having to tune in on the radio or having to watch TV, the digital route for us as a public broadcaster, is a no-brainer. It has also stimulated citizen engagement, participation, conversation, and the co-creation of content,” says Duprès. The apps deliver live digital streaming with direct access to podcast channels, in-app messaging, in-studio message boards, and social media integration. The consolidated Fabrik platform also delivers proof of play and analytic data where existing content can be seamlessly re-purposed for the apps. The SBC apps currently reach 20% of the adult population of the Seychelles. There is also tangible excitement in reaching the Seychellois diaspora globally, to engage with them in real-time as a truly modern broadcaster. Duprès believes the digital transformation has been game-changing in keeping the public broadcaster at the forefront of positive public opinion. “Not only does Fabrik ensure a direct and immediate connection with our audience, it allows our audience to become co-creators of our broadcasts with us, bringing them into the very heart of our broadcast personality,” he says. The radio programmes are also saved into a cloud archive that serves as a record to all citizens of the Seychelles of their audio cultural heritage. “South Africa can offer game-changing tech innovation for public broadcasters, as proven by the SBC, which broadcasts to a population with a high level of technology adoption. Fabrik has enabled the SBC to realise its imperative for digital transformation to not only compete commercially in a digital era, but also establish itself as the fabric that binds the culture of the Seychelles,” concludes Lumley.