Stability, reliability, security…..and intelligence. These are some of the leading design goals that a successful digital signage technology should display consistently over time. That these are desirable traits of an effective digital signage player, and that a powerful hardware device is a cornerstone of a solid solution, seems like the only things the digital signage “industry” can agree upon these days. But how are these design goals achieved? Now that’s where the debate starts.
Browser-based or native? That is the question
With some digital signage software vendors swearing by their browser-based solutions (i.e., webkit), and many reputable hardware vendors claiming that mature commercial-grade hardware is really the key, we thought we’d offer some perspective. Some say it’s a question of choosing the right building materials for your presentation layer, either HTML5 or Flash. At ScreenScape we believe the more important question is actually one that the broader world of mobile software development has been grappling with for some time. The real question is should you develop your digital signage player software in the web browser where access to the underlying hardware device is constrained, or is the better choice to build native apps?
Recently ScreenScape signalled its direction by introducing the new Smart Player for Windows. Smart Player for Windows (“SP4W”) is a major advance in the software that resides on Windows devices that run ScreenScape software. SP4W replaces the web-based player which powered ScreenScape displays since our inception. Why the change? Well, we feel a move to a standalone “native” app approach is a crucial step in the right direction and this post will explain why. We have some experience with developing browser-based software and yet we believe that every place-based media company on the planet will likely follow our lead in developing player software that isn’t stuck inside the browser but instead, as a native app, takes full advantage of resources at the device layer.
First, a story.
Where have we seen this before?
In 2012 Mark Zuckerberg announced that facebook had changed course and no longer considered the “mobile web” a central platform for developing mobile applications. After much effort to work with it, facebook was essentially announcing they were moving away from the web browser as the preferred environment for building applications for smart phone users. Until this time they had held to the belief that the web browser, and its promise of offering a platform neutral, build-once-play-anywhere platform, was the right environment for building mobile applications. So what changed? According to Zuckerberg….
The biggest mistake we made as a company was betting too much on HTML5, because it’s just not there yet. We went for this approach, an internal framework called Faceweb. We just couldn’t translate it to mobile with the quality we wanted. We had to start over and rewrite everything to be native. We burned two years. It may turn out it was one of the biggest if not the biggest strategic mistake [we’ve ever made]. Source.
In fact, by now, most (if not all) leading software makers have come to the same conclusion. They are choosing to build native apps over in-browser solutions for mobile. Like Facebook, many of them have done so after abandoning a web-based approach.
It will be interesting to see if vendors in the digital signage software arena decide to follow suit, and when. In the world of digital signage today there are still many software companies going against this experience by continuing to base their player software on browser technology. What can the lessons of these failed attempts to build mobile applications inside the browser teach us about the future of place-based media?
Media player software is actually more complex and in many ways more difficult to control as compared to a mobile application. So what kind of future does browser-based digital signage really have if the goal is to professionalize and provide quality, reliable solutions? This is an important question facing the industry. To answer this question, let’s look at the important role the media player plays in a place-based media solution.
For digital signage media players, reliability is job one
A media player for digital signage is a device that renders media on a screen, on location in a place of business. It is comprised of two major components; hardware and software. Typically a media player is controlled remotely so content can be updated dynamically and programmed with timely, relevant messaging for a specific audience, and that means it needs a connection to the Internet (at least intermittently). In this way a media player, used for digital signage purposes, is like a mobile device. But in other ways it is also quite different.
When a reliable media player is plugged in it should “just work” and to just work it needs to play content on a screen as it is supposed to according to rules that trusted authors, sometimes various authors, have pre-programmed. Not only must it “just work” it must continue to work incessantly during business hours when its job is to engage and entertain visitors in a place of business. Indeed, one critical difference between a mobile phone and a media player is that unlike a mobile phone a media player is essentially unattended, or “unmanned” if you like. It sits on a wall behind a screen and is invisible to the audience. There is no active user on hand and ready to respond to a challenge or a prompt from an active application. There are other very important jobs that a media player must do, as we’ll see in a moment, but to “just work”, continuously, and play back beautiful content, such as HD video, is paramount.
One of the challenges of the digital signage industry over the past twenty years has been the struggle of companies to develop media player technologies to do this one simple job well and to do it well all the time. Chances are you’ve probably walked by a screen in an airport or in a shopping mall that, instead of a beautiful video, is displaying an error message. This is an all-too-common occurrence that, each time it happens, damages the credibility of the industry and the medium itself. There can be other challenges as well that affect the integrity of a place-based media solution, some which are easy to spot and others which are less visual and hidden beneath the surface.
So why does this happen and what is required for a media player to always just work? First and foremost the device, both hardware and software, must be reliable. Not just reliable today under ideal conditions…but reliable always, over time, even while new advances in software and new changes to content might impact the behaviour of the media player. And what goes into a solution that is secure, stable and thoroughly reliable? It turns out there’s quite a lot involved and this is where we see the deficiencies of the browser environment laid bare.
The browser is designed to limit access to the device environment
The browser was invented to create a safe environment in which to run web sites, and increasingly web applications that might be delivered from any other computer on the web and executed on a local machine. A safe environment means a place within your computer that is inside a secure sandbox where, if the application is corrupt, or out of control, the extent of its damage will be limited and will be contained within a secure sandbox that is the browser. Part of the exercise to constrain web applications to a secure sandbox involves limiting its power and its capabilities: partial or no access to the underlying operating system, no access to system services, no database, etc… In tech speak we talk of no inter-process communication, no multi-threading of application code. What this means is that web applications, including media players that run inside a browser, are forced to live in an environment that is intentionally constrained and intentionally firewalled to prevent what, in theory, could be malicious code that was downloaded from an untrusted source and executed inside a corporate network, for example. The security sandbox that would, for most web applications, serve to protect the user from unwanted, unexpected behaviour inside the browser is in many ways the challenge with developing robust, multi-threaded, reliable applications for place-based media, or for that matter, for developing mobile device applications in general. If reliability is a priority, device access is a big deal. Developing robust apps inside a browser isn’t just difficult…often it feels like building on quicksand. This is one reason why every serious mobile application developer has moved away from the mobile web and toward building native applications such as Android and iOS apps. Full device access leads to more control, and more control leads to stable, resilient, high quality applications.
Getting closer to the metal
Performance itself is another reason software companies are choosing to build native over browser-based applications. There’s an old saying in software that goes…to do what you want, sometimes you have to get “closer to the metal”. Essentially this means that in order to get the kind of performance and control you need to build a robust application your code needs more direct access to system resources such as processing power and memory allocation. Device hardware, in general, continues on its dramatic decline in price (while increasing in power), and the new generation of hardware architectures (like ARM) do offer potential advantages for device software – but not if you have a flaky app that is stuck in the browser! Taking advantage of this new, cost-effective breed of hardware doesn’t mean building “lite” web apps that, incidentally, can also run on your phone. Rather it means building smart, resilient software that is deep and purpose built for the hardware it is designed to run on.
Toward Modern Feature-rich Media Players
Together these are just some of the reasons why we at ScreenScape believe every serious developer of place-based media solutions will follow our lead and move towards building native applications, for Windows, for Android, and eventually iOS. The goal, for all of us, is to create a smart network of screens that can scale reliably powered by media players that can perform a range of important duties. The materials to use when building your application’s presentation layer may be debatable, but that’s not half as important as the robustness of its overall system architecture. This is becoming even more obvious over time as the industry matures and as expectations of would-be advertisers become more sophisticated.
Modern media players have to become more feature rich and more robust than their browser-based ancestors. In addition to rendering content to look fantastic on a screen a player now has many other jobs to do. These jobs include the registration of the device as part of a broader identity management system, storing of content for use when the device is offline, managing the health of the device itself, reporting content playbacks, dealing with exceptions, auto-updating and more. Many of these features are necessary to maintain the integrity of the system, to keep the system up and running 24/7, to capture all the necessary data to comply and demonstrate compliance with quality standards, and more. When you are constrained by the browser, each of these jobs becomes more difficult in their own right, let alone all together. This is why we think device access is too important and why we switched to building native apps. With no room for error, it pays to do all you can to ensure it’s going to “just work”.
To learn more about the subject of native apps vs. browser-based solutions see:
We hope you enjoyed this article. We wish you a happy, prosperous 2014 and thank you for your interest in ScreenScape. Reliability, performance, and security, in combination with scalability, are primary design goals for our development team as they continue to build the world’s first Smart Network for digital signage. If you are a professional network operator out there that has a demanding ad partner and you don’t want to get caught, know your core needs and consider the implications if your browser-based player should fail. And then try ScreenScape’s Smart Player.