Conventions

To differentiate between well-defined concepts used by Viz Social and similar, but not necessarily identical concepts used in everyday life, the former ones are capitalized in the Viz Social documentation. Examples of these concepts and their spelling are: Carousel, Filter, Format, Post, Search, Story, View.

Architecture

The Viz Social solution consists of:

• Viz Social (running in Amazon cloud), which consists of a backend and a frontend, where the customer accesses the frontend via a web browser.

• DCS (usually running locally), which handles the communication between Viz Social and the Vizrt components.

• Viz components.

The Dynamic Content Scheduler (DCS) is the Viz Social component responsible for integration with target environments and destinations. It exposes an API through which other applications and components (in this case the Viz Social Backend) can manage dynamic behavior of scenes provided by the most popular Character Generators (CGs). Today, it natively supports the APIs of Vizrt and Brainstorm. It also forms the gateway to Never.no's HTML-based CG. It is also capable of producing an equivalent XML, JSON or RSS feeds itself. DCS is usually pre-configured with a set of virtual destinations. From within Viz Social, users can select one of the virtual destinations on DCS for each of the Formats. Scenes themselves can be managed via a scene-dependent button menu that is chosen when setting up a social Format.

In parallel, we have introduced the Harvester which allows Viz Social to connect to a wide variety of external feed formats, integrating with them by via configuration changes only. Using the Harvester, new formats, new feeds, and new social networks can be connected and integrated in a matter of hours.

In between those components, Viz Social's data processing infrastructure is responsible for filtering, queuing, storing and selecting of incoming and outgoing data. The queue factory safeguards that asynchronous effects and external interrupts are handled reliably. Storage is provided by an ElasticSearch database with an extremely powerful search engine also used for geographic parameters. The database and the rest of the underlying architecture have been designed so that they can be physically distributed. This safeguards a future growth path by several orders of magnitude. Finally, the Viz Social Backend manages the whole infrastructure and contains all intelligence, with the Viz Social frontend providing parallel web access over simultaneous sessions.

Below are example workflow drawings for a Trio and a DataHub solution.

In these set-ups the role of Viz Social is the collection, moderation and selection of relevant social data and to initiate or trigger the playout. DCS mediates and translates the triggers in instructions for Viz DataHub or Media Sequencer, while uploading attachments to the appropriate shared folders.

DCS can be configured to control one or more devices (for example, MSE, DataHub, or other types of instances), which appear as possible format destinations in Viz Social.

Application

In practice, Viz Social is a web application allowing users to manage Social TV Productions or to feed other broadcast or online events with social data. It standardizes on Chrome, Firefox and, practically speaking, Safari can be used as well.

Internet Explorer, Opera and other browsers are not supported. Viz Social’s Publish module can be installed as an iPad App for TV presenters for live publishing of interesting posts or aggregated Formats such as Polls. Viz Social cannot be accessed via smartphones.

Workflow and Stories

Viz Social works with a well-defined workflow, consisting of three steps: Gather, Build and Publish. Each of these phases corresponds with a dedicated module within the Viz Social application. The fourth module called Analyze monitors the data flows and provides statistics.

Before entering the workflow, users must select an existing Story to work on or decide to create a new Story. This can be done on the Story Overview page, which is the first page after logging in. Via this screen, new (empty) Stories can be created and existing ones can be entered, renamed or deleted. After having selected an existing Story the user enters the Gather module.

System Management

Everywhere in the UI the system status is displayed in the right top corner of the UI via four traffic lights that can each be either red , orange or green . The lights indicate the status of:

1. Access to external APIs.

2. Internal message processing.

3. Storage and queuing.

4. Publication.