The first step of the requirements capture exercise involved considering a number of use cases based on fictitious pieces of content. Besides research-related content in areas, such as context sensitivity
and spatial reasoning, we deliberately aimed to consider day-to-day content that was not research- related and would be shown on displays whenever they were not in use for experimentation.
3.2.1
Use Cases
The news every hour on the hour. This use case involved showing an hourly news update on all displays in the display network. The news was to be shown exactly on the hour for a few minutes. We had initially foreseen the news to be delivered in the form of text, but later on also considered showing variable length news videos.
The weather hourly right after the news. In addition to the news we thought of showing the weather forecast right after the news.
Content as screensaver. This type of content represented low-priority background content that would be shown whenever no other, more important, content was available.
The bouncing ball. The bouncing ball use case was specifically designed to make use of the geometry of Lancaster University’s main walkway that traverses the whole campus from north to south in a more or less straight line. The e-Campus project was planning to deploy a number of displays along the sides of this walkway. The “bouncing ball” use case foresaw an application that created the illusion of a ball bouncing from display to display along the walkway. The ball would either be able to start on one end of the walkway and bounce independently down the walkway, or it would follow a person as they walked along the walkway, always appearing at the display that was closest to the person. The use case was interesting to us since it represented a personalised, context-sensitive application whose engineering might in the future be coupled with mechanisms for reasoning about geometric relationships between different displays, and also between displays and users.
3.2.2
Derived Requirements
The set of use cases presented above were subsequently used to help derive an initial set of re- quirements.
Support for research-related and non-research-related content. Medium-size public dis- play networks are expensive in terms of hardware and installation costs, but also require a constant stream of funding for maintenance and repairs. It is therefore unlikely that such display networks will be created solely for the purpose of supporting research. Instead we expect a dual model in which airtime is shared between research-related content and other content that is not research-related, including electronic art, announcements and news bul- letins. By opening up the display network for content that is not research-related, additional stakeholders may be motivated to contribute to the costs of public display installations.
Support for showing content based on the time of the day. This requirement was mainly derived from the news and weather report news cases in which content had to be shown at certain times during the day (e.g. on the hour).
Support for bulk operations. The fact that the news and the weather forecast were to be shown on every display in the display network, called for the ability to schedule content on groups of displays without having to individually schedule content separately on each display.
Support for relationships between pieces of content. The weather forecast, while being a separate piece of content that is scheduled separately from the news, is nevertheless linked with the news: it is to be displayed “right after” the news. Support is therefore needed for scheduling content in relationship to other pieces of content, or to link multiple pieces together into atomic units that are always played out sequentially and in the same order.
Support for priorities and preemption. The introduction of background content as described in the screensaver use case requires users to be able to assign different priority levels to content. Moreover, higher-priority content needs to be able to “preempt” displays from lower-priority content, for example making it possible to replace the screensaver with more important content once this becomes available, or to enable the bouncing ball application to preempt displays as it follows a user along the walkway.
Support for context-sensitivity and personalisation. In the case of the bouncing ball fol- lowing a person down the walkway, the position of that person has to be sensed and used as input to the process of reaching scheduling decisions. In general we found that we would need to be able to influence scheduling decisions based on external events, such as user interaction or input from various types of sensors.
Support for spatial and geometric reasoning. Knowledge about the location and orienta- tion of individual displays is required to construct the bouncing ball application. The appli- cation is restricted to displays that are situated along the walkway. To create the illusion of a ball bouncing strictly into one direction, the displays along the walkway have to be ordered according to their location. Moreover, the orientation of a display determines, for example, whether the ball should enter the display from the left and exit to the right or vice versa. Support is therefore needed for selecting and showing content based on geometric properties.