Main features

The PuReWidgets toolkit provides a number of important features for interactive public display applications:

Multiple, extensible, widgets The toolkit incorporates various types of interac-tion widgets, supporting the previously identified interacinterac-tion tasks¹: select, data entry, upload, download, and check-in. Existing widgets can be cus-tomised and composed into new widgets, and completely new widgets can be created by application programmers.

Dynamically generated graphical interfaces The toolkit automatically gener-ates graphical user interfaces for desktop and mobile interaction with public displays. It also generates Quick Response codes (QR codes) for user interac-tion through camera equipped mobile devices.

Independence from specific input mechanisms and modalities The toolkit supports several interaction mechanisms such as Short Message Service (SMS), Bluetooth naming, OBject EXchange (OBEX), email, touch-displays, in addi-tion to the already menaddi-tioned desktop, mobile, and QR code interfaces.

Asynchronous interaction The toolkit supports asynchronous interaction, allow-ing applications to receive input events that were generated when the appli-cation was not executing on the public display.

Concurrent, multi-user interaction The toolkit supports concurrent interactions from multiple users, and provides applications with user identification infor-mation that allows them to di↵erentiate user input.

Graphical a↵ordances The toolkit provides default graphical representations for its widgets. Widgets also provide graphical input feedback on the public dis-play when an input event occurs.

1We left out the dynamic manipulation task at the moment, because it imposes greater restric-tions on the supported interaction mechanisms, and requires very application-specific solurestric-tions for handling multiple user interaction.

• Applications can easily take advantage of the extensive web content and con-tent access Application Programming Interfaces (APIs) that already exist.

• Applications are easier to distribute, update and maintain. Updates are im-mediate and display owners² will not have to reinstall the application.

• Applications are naturally multi-platform and independent of the OS running on the public display.

• Because there is no need to copy files to install the application, configuring the same application on various public display can also be made easier by using a single web interface.

Web applications also have some limitations, namely regarding the restrictions on the availability of various types of machine resources, such as graphical processing, file system access, and local input resources. However, given the recent advances in browser technologies and the current trend towards wider use of the web as an execution environment, we can expect that the limitations faced by web applications will continually decrease.

Application life-cycle

Although PuReWidgets is not tied to a particular application life-cycle, to facilitate the description of the architecture, we assume that the usual life-cycle of a public display application is the one depicted in Figure 6.1, and described next.

An application is initially developed and deployed by an application developer. De-ploying an application means that it will be hosted on a third-party web server and publicly accessible from that point forward, via a Uniform Resource Locator (URL).

Once an application is deployed, display owners are able to use it in their displays. In the PuReWidgets context, it is not important how display owners find applications.

In order to use an application in a display, the display owner will have to associate it with a particular display. This step may entail several things such as configuring the display scheduler software with the address of the new application, specifying the amount of display time and screen area the application should have, and possibly

2We use the term display owner to refer to the person that is responsible for maintaining the public displays in a specific location, setting up and configuring their content.

Figure 6.1: General life-cycle of a public display application

configuring the application so that it displays content that is appropriate for the particular place where the display is located.

Once an application is associated with a display, the display scheduler can decide to give the application display time by putting it on-screen.³ Putting an application on-screen means loading the web page of the respective application in a browser component. Putting an application o↵-screen means removing it from the display, probably shutting it down by closing the web page, unloading it from the browser component. (Although PuReWidgets also works with applications that are simply taken to a background state, hidden from view.) We make no assumption as to the type of scheduler that a particular display will use. Scheduling could use a simple time-based algorithm, based on a pre-defined timetable of display time for each application, or a more complex event-based algorithm, which dynamically gives applications display time based on external events such as user interactions.

API design

While designing the API of the programming library, we had a number of design goals in mind.

Low learning threshold. We wanted an easy to program system, integrated into the regular application development cycle. We did not want to introduce additional steps in the typical development process, nor change too much the existing ones.

Dynamic interfaces. We wanted to allow applications to have dynamic interfaces where widgets can be created, changed, and removed at any time. We did not want to introduce compile time mechanisms that would, for example, force programmers

3We borrow the terms on-screen and o↵-screen from the cinema terminology which refer to characters that are present on a scene, but are not seen by the audience. We apply the terms to both applications and widgets.

6.2 Architecture

The PuReWidgets system was designed to support displays in various independent administrative places, running various applications developed by third-party devel-opers. Figure 6.2 depicts the main physical components of a network of public displays. From the perspective of a public display, a PuReWidgets based public dis-play application is a standard web application that is downloaded from a third-party web server and runs in a standard web browser component in the public display.

Interaction with a public display application is accomplished through an Interaction Manager (IM) server that is part of the PuReWidgets toolkit. A single IM supports various independent applications and displays.

The PuReWidgets toolkit is composed of a widget library that programmers include in their application’s code, and a web service that handles interaction events (see Fig-ure 6.3). When the application is on-screen, the PuReWidgets library receives input events from the PuReWidgets service, and triggers the appropriate high-level events on the application. The development process of a public display application that uses PuReWidgets is similar to the development of a regular web application: devel-opers include the PuReWidgets (object-oriented) library in their projects and use the available functions of the library to code the application, instantiating widgets and registering callback functions for interaction events. These callbacks correspond to high-level interaction events and are triggered by the widget instances after an interaction event is detected and processed by the widget. Developers then deploy the set of HyperText Markup Language (HTML), Cascading Styles Sheet (CSS), and Javascript files that compose their application to a web server.