SUMMA H2020–688139 D1.2 Initial Prototype Report

Scalable Understanding of Multilingual MediA(SUMMA)

http://www.summa-project.eu

H2020 Research and Innovation ActionNumber: 688139

D1.2 – Initial Prototype Report

Nature Report Work Package WP1Due Date 31/07/2017 Submission Date 31/07/2017

Main authors Peggy van der Kreeft (DW)Co-authors Lauren Boyes (BBC), Andreas Giefer (DW), Hina Imran (DW)Reviewers Steve Renals (UEDIN)Keywords prototype, business analysis

Version Controlv0.1 Status Draft 11/07/2017v0.2 Status Draft 14/07/2017v1.0 Status Final 20/07/2017v1.1 Status Reviewed 24/07/2017v2.0 Status Final 31/07/2017

page 1 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

Contents

1 Introduction 51.1 Purpose of Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Related Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Use Cases 62.1 External Monitoring Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Internal Monitoring Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Combining the External and Internal Monitoring Use Cases . . . . . . . . . . . . . 7

2.4 Data-Driven Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 User Requirements – MoSCoW Prioritisation 8

4 Prototyping the External and Internal Media Monitoring Use Cases 94.1 Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2 Defining the MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.3 Prototype Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.4 Weekly Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.5 Current Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Roadmap 175.1 Future Iterations of the Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2 Sprint and Evaluation Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.3 Configuring the Prototype for Different Users . . . . . . . . . . . . . . . . . . . . 18

5.4 Data-Driven Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Designing the Data-Driven Use Case 196.1 Data-Driven Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2 Data Journalism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.3 Collaborative Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7 Conclusion 21

page 2 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

List of Figures

1 SUMMA Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Requirements List in D1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 SUMMA Scribble Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 SUMMA Static Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 SUMMA Clickable Wireframes - Mockup . . . . . . . . . . . . . . . . . . . . . . 10

6 SUMMA MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7 SUMMA Early Prototype v0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

8 User Feedback Button Functionality . . . . . . . . . . . . . . . . . . . . . . . . . 13

9 SUMMA Prototype DW Content View v1.0 . . . . . . . . . . . . . . . . . . . . . 13

10 SUMMA Prototype BBC Content View v1.0 . . . . . . . . . . . . . . . . . . . . . 13

11 SUMMA Prototype v1.0 LETA Server . . . . . . . . . . . . . . . . . . . . . . . . 14

12 SUMMA Prototype v1.0 UEDIN Server . . . . . . . . . . . . . . . . . . . . . . . 14

13 Weekly Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

14 Jira Requirements Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

15 Current Admin View: Tabs, Filtering and Sorting . . . . . . . . . . . . . . . . . . 18

16 SUMMA Dashboard - Trending Issues . . . . . . . . . . . . . . . . . . . . . . . . 20

17 SUMMA Dashboard - Coverage of Topics . . . . . . . . . . . . . . . . . . . . . . 20

page 3 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

Abstract

This document describes the prototype work in the SUMMA project, and in particular the userpartner view on this process. It builds further upon the use case definition and user requirementsdescribed earlier in D1.1. It provides details of achievements since setting the requirements andshows how the broadcast partners moved from these user requirements to designing the platformand actually using it.

The current prototype focuses on external and internal monitoring. A common prototype has beendeveloped to cater for both these use cases, resulting in an efficient platform that is wide in itspotential application and allows for customisation through filtering and visualisations.

This deliverable is the second in a series of three: it was preceded by D1.1 (Requirements)inM6 and will be followed by D1.3 (Final Prototype), due M36. It describes prototype efforts andplans by the user partners and their collaboration with other consortium partners, and in particularthe integrator, and serves as input for further prototype development. The prototypes are in turnsubject to user evaluation. It details the prototype definition and development, with wireframes,still and clickable mockups, and the first versions of the functional prototypes. It describes howagile development is implemented, using Sprints.

page 4 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

1 Introduction

1.1 Purpose of Document

The purpose of this document is to illustrate the user partner view of the prototyping process andrelates to Work Package 1 “Requirements”. The report includes:

• details of the achievements for the first reporting period

• a description of the different phases

• how the broadcast user partners moved from defining requirements to designing and usingthe SUMMA platform

1.2 Related Deliverables

This document is intended to be read as a standalone report. However, should the reader requirefurther background or clarity on some of the content, they can find more information via:

• D6.3 Intermediate Report on the Platform - technical details of the prototypes

• D1.1 Use Case Descriptions and Requirements - describes the use cases, defines the specificuser scenarios and lists the user requirements

• D7.2 Initial Evaluation Report

1.3 Intended Audience

This is a public document and, whilst the initial target audience of this deliverable is largely internalto the project, it is open to other stakeholders. This includes the wider scientific and industrialaudience, in particular the media industry. We hope to trigger their interest in showing the benefitsof the tool for the media industry. All SUMMA public deliverables are made available on theSUMMA website.

1.4 Authors

Deutsche Welle is overall work package and deliverable leader. BBC is task leader of Task 1.3(Prototyping). The two user partners collaborate on all aspects and ensure a common and consistentuser view facing the developers, while keeping the unique objectives of each use case intact.

page 5 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

Figure 1: SUMMA Scenarios

2 Use Cases

SUMMA foresees three use cases: external monitoring, internal monitoring, and a third one to bedeveloped at a later stage, the data-driven use case.

2.1 External Monitoring Use Case

This use case is the primary target for BBC Monitoring (BBCM). It monitors media sources indifferent languages outside the monitoring organisation.

BBCM is a specialised area of the BBC. Its aim is to understand the world through its media.BBCM’s journalists keep track of broadcast, press and social media sources in multiple languagesfrom over 150 countries worldwide. They filter, translate and report breaking news, media beha-viours and emerging trends with direct insight from local sources even in hard-to-reach places.

The SUMMA platform would be a major asset to this team.

2.2 Internal Monitoring Use Case

This use case is the primary target for Deutsche Welle, although DW ultimately envisages com-bining internal and external monitoring with this platform. In internal monitoring, we analyse,summarise and visualise content produced in Deutsche Welle in different languages and editorialdepartments in order to get a continuously updated overview of internal production and trendingnews topics in one common language (English).

page 6 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

2.3 Combining the External and Internal Monitoring Use Cases

During the requirements elicitation phase, it became clear that there is considerable overlap betweenthe two primary use cases. As outlined in D1.1, it was therefore decided, and supported by the en-tire consortium, that one common prototype will be built that can be customised to meet specificuser requirements. The combined prototype covers both internal and external monitoring object-ives.

Such a setup allows us to build a more flexible prototype, leave room for adaptations (as it has tomeet wide-ranging requirements), keep development simpler and robust, encourage close collabor-ation between the two broadcasters, allow for evaluation scenarios where results can be compared,and come up with a tool that is usable for the broadcasting/monitoring/media world in general.

Thus, we started with two overall and partly overlapping use cases (external monitoring and in-ternal monitoring), 17 detailed user scenarios and a set of 107 requirements, set up and agreedupon by the joint consortium (Figure 1).

2.4 Data-Driven Use Case

Still in its infancy, the Data-Driven Use Case relates to Task 1.4 (Develop Alternative Use Case).In this report we will describe the initial activities conducted by Deutsche Welle and BBC indeveloping this use case.

page 7 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

Figure 2: Requirements List in D1.1

3 User Requirements – MoSCoW Prioritisation

The initial user requirements were established within the first six months of the project and coveredthe Use Cases and scenarios at varying levels of detail. Using the MoSCoW (Must-Should-Could-Won’t) prioritisation method, the user partners were encouraged to agree upon a priority for eachindividual requirement. The requirements that achieved an overall priority of Must Have andShould Have were used to inform the first design phase of the user interface. As the Data-DrivenUse Case was not fully described at this time, none of the requirements for this use case wereprioritised above a Could Have. The full list of the MoSCoW requirements can be seen in D1.1. Asample of the collected requirements is shown in Figure 2.

page 8 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

4 Prototyping the External and Internal Media Monitoring Use Cases

This section of the deliverable relates to Task 1.3 (Prototyping), focusing on user partner involve-ment in developing a prototype that matches the use cases for internal and external monitoring ofbroadcast media.

4.1 Wireframes

A workflow for processing and visualising content was established to start the design process. Thebasic workflow consisted of automated transcription of audio, followed by automated translationinto English, then summarisation. A more specialised workflow for an enriched experience in newsmonitoring included news ingestion, clustering, annotation, etc.

Next, wireframes were created from the requirements and envisaged workflow. Two face-to-faceuser meetings were held for this purpose, with the user partners (BBC and DW) and integrator(LETA) arriving at a common idea for the prototype and streamlining the thought and designprocess. One was hosted by the BBC technical team in Belfast and the next one at Deutsche Welleheadquarters. We moved from draft flipchart sketches (Figure 3) to static keynote wireframes(Figure 4) to clickable Balsamiq wireframes (Figure 5).

Figure 3: SUMMA Scribble Wireframes

page 9 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

Figure 4: SUMMA Static Wireframes

Figure 5: SUMMA Clickable Wireframes - Mockup

page 10 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

4.2 Defining the MVP

During the process of creating the wireframes a lot of new requirements had come to the surfaceand our MoSCoW requirements were in need of updating.It was decided that the requirements would be transferred over to Atlassian Jira prior to the de-velopment phase starting. While transferring the original requirements and documenting the re-quirements that had been added during the wireframing phase it became apparent that not all ofthe functionality requested by the user partners was a Must Have or Should Have requirement.

A series of sessions were set up to re-prioritise the requirements backlog into phased releases. Atthis stage these phases were:

• M14 - to coincide with D6.2, the Initial Platform Release. This release was considered asa proof of concept. The most important pieces of functionality and UI design requirementswere to showcase the Work Package 3, 4 and 5 components created up to this point.

• M16 - the functionality within this release would be considered as the Minimum ViableProduct (MVP) of the SUMMA platform. The date was set to allow the user partners totest the MVP with potential end users of a full SUMMA platform in their work environmentprior to the July Deliverables such as this one.

• POST-MVP - all functionality that user partners wish to see in the platform before the endof the 3 year project

• FRM - functionality that was considered to be ill-defined or a nice-to-have. These require-ments were not expected to be released as part of the SUMMA project lifespan. However,they were documented to form part of an on-going Future Road Map (FRM).

Another set of wireframes was created to show a slimmed-down MVP version of the platform toinform the development of the UI up to June.

The Jira backlog is now a working document (Figure 6). Its content is evaluated week-on-week asimprovements are made to the platform. We will discuss this process in further detail later in thereport.

Figure 6: SUMMA MVP

page 11 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

Figure 7: SUMMA Early Prototype v0.1

4.3 Prototype Releases

At this point, when we say prototype, we are referring to the integrated platform developed byLETA.

From an early phase, while setting up the wireframes, an initial platform (v0.1) was set up byLETA and made available to the user partners for a first feel of the tool, containing DW sourcessupplied via API ( Figure 7). This version, even if incomplete as to content and basic in termsof UI, was important to get the process of integrating technologies and components started. Inaddition, this provided an extra source of conceptualisation for the broadcaster partners.

Once finalised, the clickable wireframes were the basis for the first integrated prototype version.This was considered to be the Proof of Concept release combining the integrated functionalityfrom WP3, 4 and 5 and combining this with a UI. Data included DW sources through API. Thiswas made available to the consortium in M14.

With this version of the platform, user partners could start testing the tool and its functionalitiesand features. At the users’ request, a feedback button was implemented in the tool, so that at anystage while using the system, the user can write a comment, accompanied by a rating (thumbsup/down) and a screenshot of the situation. This proved to be extremely useful, as there is littleor no need to describe the context or add screenshots manually. An example is shown in Figure 8below.

A new release in June 2017 (M16) included all functionality improvements after the April Release(M14), in time for the user evaluation sessions in June/July and the July deliverables. This releaseincluded feeds provided by DW (Figure 9) and BBC (Figure 10).

page 12 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

Figure 8: User Feedback Button Functionality

Figure 9: SUMMA Prototype DW Content View v1.0

Figure 10: SUMMA Prototype BBC Content View v1.0

page 13 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

In order to accommodate the much higher data flow through BBC channels, it offered two versions:one on LETA’s servers primarily used by Deutsche Welle (Figure 11) and the other on University ofEdinburgh’s servers for BBC use (Figure 12). Both versions, however, included content from bothbroadcasters to allow for searching content beyond the organisation’s own sources. This release isconsidered to form SUMMA’s MVP.

Figure 11: SUMMA Prototype v1.0 LETA Server

Figure 12: SUMMA Prototype v1.0 UEDIN Server

page 14 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

4.4 Weekly Sprints

With a version of the tool available for testing as of April 2017, weekly (virtual) prototypingmeetings were started involving the user partners (BBC and DW), integrator LETA and coordinatorUniversity of Edinburgh. See an example as shown in Figure 13 below.

Figure 13: Weekly Sprints

After entering the initial list of requirements into Jira, weekly status updates, checks and prioritysetting were the subject of these weekly sprints, reporting and documenting status and progress inJira, resulting in a smooth collaborative process in which user partners were actively involved andkept up to date. Priorities were set for each week, with an update of the expected MVP (minimumviable product). This is illustrated in Figure 14 below.

Figure 14: Jira Requirements Tracking

Users try to convene twice weekly, on Tuesdays for the Sprint meetings, setting the priorities forimplementation in the coming week, and on Thursdays for a user evaluation meeting to discuss

page 15 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

the most recent user feedback and follow up on earlier recommendations and bug reports and QAcontrol, until the issue can be reported as done.

In parallel with the weekly Sprints, new interim releases of the platform are issued on an almostweekly basis, thus ensuring that the users are able to see fast-moving implementations of thesuggested recommendations and priority requirements. User feedback and evaluation are reportedon in detail in D7.2 (Initial Evaluation Report).

4.5 Current Status

At the time of writing this report the June (MVP) release had been completed with all expectedfunctionality and only one minor bug outstanding. The team at LETA had also managed to incor-porate some functionality previously assigned to the POST-MVP workload. The user partners havebeen delighted with the progress made and feedback from user testing sessions have been positive,see D7.2.

We have two versions of the prototype. The first is hosted in LETA and contains all media feedsfrom DW for the SUMMA languages and some BBC feeds. The second is hosted in Edinburghand contains as-live sources (described in D2.2) from BBC and some DW content. This allowsthe user partners to use the same UI and common functionality with different data, while usingtwo parallel systems, thus avoiding overloading the servers and allowing simultaneous testing ofdifferent systems. DW and BBC are able to test the platform to meet the internal as well as externaluser requirements.

page 16 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

5 Roadmap

This subsection describes the plans for the second half of the project.

The MVP covers all the aspects, functionalities and features that are considered necessary and thatshould be implemented by Month 18.

Overall, it is foreseen that SUMMA will develop one common prototype for monitoring broadcastmedia, with extensive customisation, catering for specific needs for internal and external monitor-ing. This means that efforts can be focused on developing a robust system with a lot of functional-ities and rich user profiling, determining view preferences, visualisation options, feed inclusions,etc. geared to organisational and user needs. Additional personalisation is achieved through ad-vanced filtering and queries. Essential, however, is to ensure the UI is easy, useful and efficient;the lack of any of these three requirements will deter further use in a journalistic environment.

5.1 Future Iterations of the Prototype

A new release is expected by September 2017, addressing the improvements suggested and bugsidentified during user evaluation in June and July.

In addition, the requirements list contains many more wishes and demands. This includes anyadditional functionality ”nice to haves” requested by DW and BBC. Although these issues wereseen as not being part of the MVP, they should still be part of SUMMA within the project timescale.Most have not been given a priority. Some are from the first set of requirements. All need furtherclarification before prioritisation into a time-bound release.

5.2 Sprint and Evaluation Meetings

Sprint and evaluation meetings will continue to form part of our working schedule. However, it islikely that we will change to a two-week sprint cycle. The time constraints leading up to the InitialPrototype release meant that improvements to the system needed to be made quite rapidly. Movinginto the next phase, two large pieces of work have been identified for integration and UI design:

• Text-based Media component integration - will include changes to the UI and user journeys

• Bookmarking - an important piece of functionality for BBC, this should be designed asa component feature so other user partners who do not require this functionality are notaffected by the changes

As the two improvements mentioned above are large pieces of work, it follows suit that the de-velopment team in LETA will require longer sprints to deliver a potentially shippable productincrement at the end of each sprint. Every large improvement will also require the user partnersto spend more time in the design and evaluation phases. Combining this with the change in time-constraints leading to the September release means that we can afford to change the sprint andevaluation cycle to suit the needs of this particular release.

page 17 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

Figure 15: Current Admin View: Tabs, Filtering and Sorting

5.3 Configuring the Prototype for Different Users

As we move through the iterations of the project and move further from the common MVP, com-ponents of the platform will become more relevant to particular user groups. To combat this, eachmajor piece of functionality is developed as a component of the entire platform and the UI reflectsthis with tabs down the left hand side, alternative views for displaying content and the ability tofilter and sort content. We plan to continue in this manner and, where necessary, will consider userprofile configurations to create tailored experiences for future users of the platform (Figure 15).

5.4 Data-Driven Use Case

Thus far, the focus has been on the progress for the two monitoring use cases (external vs. internaluse cases). A third use case is foreseen to start later on in the project, i.e., the data-driven usecase. This can go into different directions. One is to visualise measurable data for monitoringpurposes (figures on trending topics, regional coverage, etc); another is the more traditional ”datajournalism” case, where we find and use measurable data for journalistic use (to produce graphicsfor inclusion in articles and videos to be published, for instance).

The planned schedule and work up to this point is detailed in the next section.

page 18 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

6 Designing the Data-Driven Use Case

The requirements elicitation for the data-driven use case is due to be complete in January 2018.In May 2017, we started analysis by exploring measurable data for monitoring as that is the focusof SUMMA. Some basic proposals were presented by DW in this regard to the consortium at theplenary meeting in Martigny.

6.1 Data-Driven Dashboard

This proposal makes use of an application developed within Deutsche Welle, referred to as “TheDW dashboard”. It automatically extracts numerical, measurable data from the data in the SUMMAplatform and visualises this measurable data in different ways. In the internal monitoring use casethis can lead to recommendations in terms of processing and reporting on content diversification,use and overlap.

Some of the envisaged visualisations are detailed below. These are initially triggered by DeutscheWelle objectives, but can be applied to and serve both user partners and use cases, as well as thewider media community. The Dashboard currently follows Deutsche Welle’s design specifications.

In the examples in Figures 16 and 17, the Dashboard is divided in seven draggable widgets, eachof which contains one chart:

• Most searched entities today• Trending stories with related topics today• Who to follow on Twitter today• Most covered topics by us last week• Least covered topics by us last week• Most covered topics by external media last week• Least covered topics by external media last week

”us” refers to the media group/broadcaster/department involved, e.g. Deutsche Welle, BBC, oranother media organisation, or a department within an organisation, e.g. the Arabic languagedepartment, the Latin-America regional department, etc.

6.2 Data Journalism

BBC Monitoring’s ambition is to use the power of the platform to extract measurable data for DataJournalism. This would be based on metrics like mentions of entities or airtime given to a subjectover time and how they change. This data would be used in textual or multimedia journalismoutput. The BBC will write this data journalism use case for month 24.

6.3 Collaborative Effort

As was the case for setting requirements and creating wireframing in the Internal and ExternalMedia Monitoring use cases, the user partners expect to:

• work together to identify common requirements• design UI components/views to house user-specific requirements

page 19 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

Figure 16: SUMMA Dashboard - Trending Issues

Figure 17: SUMMA Dashboard - Coverage of Topics

This will optimise resources and allow broadcasting partners to make maximum use of the proto-types and applications, yet customise them and steer them to internal requirements.

page 20 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

7 Conclusion

This document presents an overview of the work by and related to user partners in designing theprototypes for the two primary use cases of the SUMMA project: internal and external monitoring.

The list of over 100 requirements was further analysed and prioritised and added to Jira, for follow-up in weekly Sprints.

The design process went from the established scenarios and requirements to rough wireframes, tostill wireframes, to a clickable mockup, and finally to the ”real thing”.

One common prototype for internal and external monitoring was made available for testing andtrialing by the users. Regular Sprints, setting and updating requirements for an MVP provided thebroadcast partners with improved new releases.

At the mid point of the project, users started evaluating the platform, gathering feedback andintroducing the tool inside their organisations. This is a positive and promising stage to be at.

Work has started on developing an additional, third prototype, the data-driven use case, whichextracts and visualises measurable data from the SUMMA platform.

page 21 of 22

SUMMA H2020–688139 D1.2 Initial Prototype Report

ENDPAGE

SUMMA

H2020-ICT-2015 688139

D1.2 Initial Prototype Report

page 22 of 22