Yarely – A Software Player for Open Pervasive Display Networks Sarah Clinch, Nigel Davies, Adrian Friday, Graham Clinch School of Computing and Communications, InfoLab21 Lancaster University, Lancaster, LA1 4WA. United Kingdom. [s.clinch | nigel | adrian] @comp.lancs.ac.uk, [email protected] ABSTRACT signage system that has operated at Lancaster University This paper describes Yarely, a software player designed to since 2005. The system consists of a wide range of displays support the next generation of pervasive display networks. including indoor and outdoor installations and both pro- We identify five design goals for future digital signage play- jected and LCD technology. Content creators in e-Campus ers: the ability to provide basic signage functionality (media use the system to create \channels" of signage content that scheduling and playback) and support for openness, extensi- they subsequently publish within the network. Display own- bility, resilience and appropriation. The paper describes the ers subscribe their displays to these channels and the system design and implementation of Yarely in light of these design automatically schedules content to each display based on the goals. We present an evaluation of the system in the form combination of subscriptions and channels relevant to that of deployment and usage data alongside a reflection on the display. Of particular note is the fact that e-Campus offers degree to which Yarely successfully addresses the needs of an API that enables developers to create new applications future pervasive display systems. to control the signage network [14]. The e-Campus system was based on an experimental soft- ware infrastructure that relied on a complex series of mes- Categories and Subject Descriptors sage events to coordinate playout amongst screens. Whilst H.5 [Information Interfaces and Presentation]: Mis- our initial predictions for the software suggested that the un- cellaneous derlying eventing system would be able to handle large num- bers of displays (estimated at between 7,000{15,000 events General Terms per second with 250 displays) we found that during a typ- ical day's operation on campus with 25 screens the system Design, Reliability quickly began to lag. This slowdown was despite a rela- tively modest event channel throughput measured at ap- Keywords proximately 40 events per second. We found that this was public displays, system architecture, experiences partly due to the communications overhead of the e-Campus API over the event channel, but also due to the 250,000 or 1. INTRODUCTION so database queries needed to calculate the schedules for the displays given the 66 content channels and 3,000 or so In this paper we describe Yarely { a software player de- content items in the system. Despite providing the main sig- signed to support the next generation of digital signage and nage infrastructure on campus for seven years, this reliance pervasive display networks. Our work is motivated by a on a common eventing infrastructure and centralised high vision of large-scale networks of pervasive displays forming level scheduler led to a number of concerns with the existing a new communications medium that is open to content and system: applications from a wide range of sources [4]. We believe this openness will encourage innovation and reduce reliance on excessive fragility our system was extremely sensitive to traditional models of funding through advertising { enabling interruptions in network connectivity with these typi- a broad range of signage scenarios such as emergency coordi- cally leading to blank screens or \stuck" displays. nation, personalised information, situated applications and community information sharing. scalability concerns our eventing infrastructure struggled We have previously reported on the design and implemen- to scale as the number of displays grew above 20, and tation of the e-Campus system [14] { an experimental digital became less reliable as each new screen was added. no support for off-line nodes our system could not sup- port ad-hoc deployment of screens (e.g. at conferences) Permission to make digital or hard copies of all or part of this work for without connection back to our infrastructure. personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies problems with firewalls our system did not have support bear this notice and the full citation on the first page. To copy otherwise, to for traversing through firewalls which limited deploy- republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ment options. PerDis 2013 June 04 - 05 2013, Mountain View, CA, USA Copyright 2013 ACM 978-1-4503-2096-2/13/06 ...$15.00. difficulty in pre-fetching content because our displays 25 received instructions on a per content item basis they We also recognised that in order to have our player widely could only pre-fetch a single item of content at a time. adopted it was crucial to develop a multi-platform solution and one that would scale to very large deployments. Together these limitations acted as a barrier to scaling the system beyond the University campus, and even prevented 2.4 Resilience and Disconnected Operation us from increasing the size of the on-campus display network. Core to our design goals is the need to provide a resilient The large-scale, open nature of the future display networks player. Our experiences with e-Campus taught us that hav- we envisaged could not be met by our existing software. ing a tightly-coupled system that relied on network connec- In 2011 we decided to completely re-engineer our software tivity led to significant periods of time when screens failed. infrastructure from the ground up in order to support our vi- We were also aware that while a campus may have generally sion of large-scale open signage systems. In so doing we drew good network connections, many displays are installed at lo- on our extensive experience with the e-Campus system. We cations with little or no network connectivity. As a result begun the re-engineering by creating a new software player we set ourselves the goal of developing a system that was for our signage network. In this paper we describe the design fully functional without network connectivity. In particular, and implementation of this component. we wished to create a system that could make autonomous We observe that in contrast to many papers on digital scheduling decisions and could source content from multiple signage that focus on user experience or new display tech- local sources without network connectivity. nologies, we explicitly aim to provide the community with engineering details of a single component in order to help fa- 2.5 Appropriation cilitate other researchers to create robust open signage sys- Our vision of an open pervasive display network relies on tems. display networks providing users with the ability to appro- priate displays for a wide range of applications. Such ap- 2. DESIGN GOALS propriation might range from simply tailoring content such as news or weather broadcasts through to users executing Our experiences with the e-Campus system enabled us their own applications on a public display and interacting to arrive at a series of concrete design goals for the Yarely with the display for significant periods of time. As a result, player. we set ourselves the design goal of supporting a wide range 2.1 Addressing General Functional Require- of sensing and appropriation methods. In contrast to many ments systems, we specifically designed our player to enable users to execute native applications locally on the display. Clearly, at a minimum, the player needed to support gen- eral signage functionality such as displaying content of a range of media types and on a range of displays. Since we 3. DESIGN AND IMPLEMENTATION are only concerned with the requirements for the player in this paper, we do not consider the more general requirements 3.1 Overall Architecture relating to issues such as content creation and scheduling. For the purposes of this paper we consider digital signage systems to comprise of two main architectural segments { 2.2 Openness Display Nodes (upon which our player software executes) In developing our player we considered it critical that the and sources of content located within the broader network display was able to serve as a component of a future open (e.g. as a Web or cloud service). We recognise of course that display network. Most signage players assume that they display networks are significantly more complex and include are controlled by a single authoritative source that supplies components such as ad-brokers, content creation tools and them with both content and a play out schedule. Our goal scheduling, but this simple model serves to highlight the fact was to design a player that could easily be connected to that Display Nodes are typically separate to content sources. multiple content sources simultaneously. This represents a An important architectural decision for any signage sys- fundamental shift in thinking of signage systems { instead of tem is the distribution of functionality between display clients a player being treated as a simple \slave" that plays the con- and cloud based services such as content sources. For exam- tent that is sent to it, we aimed to create a more intelligent ple, it is possible to construct signage systems in which dis- player that is able to schedule content from multiple sources play clients simply run standard Web browsers and all of the that are not necessarily aware of each other and hence may functionality is provided through cloud services. In contrast, provide the player with conflicting play out requirements. many existing commercial signage systems have relatively To achieve such a degree of openness we specifically set our- feature-rich clients in order to enable them to survive peri- selves the goal of providing a mechanisms that would enable ods of disconnection.