Springfield Multiscreen Toolkit. The presentation engine has evolved from last year’s version into a new product called the Springfield MultiScreen Toolkit or SMT for short. In parts of the documentation we might refer to it as the toolkit or SMT. The toolkit has evolved as the project progresses and tries to resolve and answer the following problems and questions: How do we handle multiple formats (single/multiscreen, group viewing)? How do we handle multiple devices (phones, tablets, tv and HbbTV)? How can partners in the project be involved in the development? How can we host applications built using the SMT in the cloud? How do we display the information streams in different modes? Within the toolkit we tried to resolve most of the problems outlined above and create a solid base for implementation of the final product in year three. As part of the building and testing process we created many small tests and examples of how to work with the toolkit. Describing all of them here would be too much and we will release them as part of the documentation of the toolkit but we have used several of the bigger ones for the technical demonstrators we made as part of this document to explain both concepts and show examples as described in section 2.3 and further. In the rest of this chapter we will expand on how we tried to solve each of the issues with concepts and examples.
Springfield Multiscreen Toolkit. The Springfield Multiscreen Toolkit, the successor of the MediaCanvas API, can be divided into three parts. First a server side part called Xxx that runs the application and handles the multiscreen aspects across multiple devices. Second a client side part called Xxxxx that offers client side support specific for the device, e.g. gestural support for tablets or remote support in case of HbbTV. Finally there is an application manager that allows developers to deploy, test and debug their applications. The SMT uses a unified screen model, meaning that developers don’t have to deal with multiscreen aspects like for example synchronization and the addressing of events to a certain screen. This is to allow developers to work as they were developing a single screen application while the SMT deals with the multiscreen aspects. The different screens all reside on the server in their own application space. From the server the screens are pushed to the client side as can be seen in Figure 3. The advantage here is that the client side requirements can be lowered as the server can render certain parts of the screen, this leads to support of a broader range of devices. Figure 3: Communication from the application to connected unified screens
