D4.3: Report piloting activities, user interfaces and integrations for intermediate pilot 2 - HRadio
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Grant Agreement No.: 761813
Call: H2020-ICT-2016-2017
Topic: ICT-19-2017
Type of action: IA
D4.3: Report piloting activities,
user interfaces and
integrations for intermediate
pilot 2
Editors : Alexander Erk (IRT)
This deliverable will provide a report of the preparations for the second intermediate
pilot activities, including user interface mock-ups, implemented user interface
description and specifications, and a report on the integration between user
interfaces and the technical components.
HRADIO.eu
D2.3: Report piloting activities, user interfaces and integrations - pilot 2
Basic Information
Work package 4
Due date 31/03/2019
Submission date 05/09/2019
Deliverable lead IRT
Version 1.0
Alexander Erk (IRT), Leo Andrews (Radioplayer), Maximilian
Authors
Knoop (Konsole)
Reviewers Iris Jennes (imec), Klaas Baert (VRT)
Document Revision History
Version Date Description of change List of contributor(s)
V0.1 11/03/2019 Initial version Alexander Erk
Alexander Erk (IRT),
Leo Andrews
V0.2 09/08/2019 Version for review (Radioplayer),
Maximilian Knoop
(Konsole)
V0.3 18/8/2019 Reviewed version Alexander Erk (IRT)
V1.0 04/09/2019 Coordinator review Simon Delaere (imec)
Page 2 of 27
D2.3: Report piloting activities, user interfaces and integrations - pilot 2
Disclaimer
This project has received funding from the European Union’s Horizon 2020 research and
innovation programme under grant agreement No 731677. This document reflects only the
authors’ views and the Commission is not responsible for any use that may be made of the
information it contains.
Project co-funded by the European Commission in the H2020 Programme
Nature of the deliverable: to specify R, DEM, DEC, OTHER*
Dissemination Level
PU Public, fully open, e.g. web X
Classified, information as referred to in Commission Decision
CL
2001/844/EC
CO Confidential to HRadio project and Commission Services
Page 3 of 27
D2.3: Report piloting activities, user interfaces and integrations - pilot 2 EXECUTIVE SUMMARY This deliverable provides an overview of the two HRADIO pilot 2 applications. With the results and learnings from pilot phase 1 as well as with the feedback from the 1st review. The project decided to go for a set of two different applications for the Android platform. 1st a general radio application with a special focus on in car usage. 2nd an Android application with a, for radio applications, novel approach in radio applications user interfaces. The piloted idea is to present the ongoing stream of events like a chat history commonly known from applications such as WhatsApp and Threema. In order to deploy these applications, a Google PlayStore account has been set up, from which the applications could be deployed to any Google user account as part of a closed beta program. Page 4 of 27
D2.3: Report piloting activities, user interfaces and integrations - pilot 2
TABLE OF CONTENTS
1. HRADIO APPLICATIONS FOR PILOT 2 ...................................................................... 9
2. USER & TECHNICAL TESTING PRODUCTS ...............................................................11
2.1. Technical Basis for pilot 2 Applications ........................................................................................ 11
2.2. Product 1: HRADIO Car-Client ............................................................................................................. 13
2.2.1. Time-shifting...................................................................................................................................................... 14
2.2.2. Favourites............................................................................................................................................................. 15
2.2.3. A-Z List/Menu .................................................................................................................................................... 17
2.3. Product 2: HRADIO general Mobile Client ........................................................................................... 18
2.3.1. Start Screen (Menu) ..................................................................................................................................... 19
2.3.2. Radio Station Screen (radio feed)..................................................................................................... 19
2.3.3. Player-Bar............................................................................................................................................................. 21
2.3.4. Timeshift Feature .......................................................................................................................................... 22
2.3.5. Substitution Feature (only local) ..................................................................................................... 22
2.3.6. Slideshow Feature ........................................................................................................................................ 22
2.3.7. Chat Feature ...................................................................................................................................................... 23
2.3.8. Voting Feature ................................................................................................................................................. 23
2.3.9. Greeting Feature ............................................................................................................................................ 23
2.3.10. Analytics ............................................................................................................................................................... 23
3. DEPLOYMENT VIA GOOGLE PLAY ........................................................................... 25
4. CONCLUSION .................................................................................................................. 27
Page 5 of 27
D2.3: Report piloting activities, user interfaces and integrations - pilot 2
LIST OF FIGURES
FIGURE 1: FROM PILOT 1 TO PILOT 2 .......................................................................................................... 10
FIGURE 2: OVERVIEW OVER HRADIO TECHNICAL COMPONENTS ........................................................12
FIGURE 3: STATION SCREEN RUNNING VRT’S MNM HITS SERVICE ..................................................... 13
FIGURE 4: TIME SHIFTING “RADIO1” FROM RBB ..................................................................................... 14
FIGURE 5: FAVOURITE BAR ............................................................................................................................. 15
FIGURE 6: EDITING THE USERS FAVORITES............................................................................................... 16
FIGURE 7: A-Z LIST .............................................................................................................................................. 17
FIGURE 8: RADIOWEB SAMPLE FOR VRT “RADIO1” ................................................................................ 18
FIGURE 9: APP RUNNING WITH START SCREEN SHOWING VRT’S RADIO SERVICES ..................... 19
FIGURE 10: APP RUNNING WITH STADION SCREEN SHOWING RBB’S RADIOEINS, RIGHT WITH
SLIDE SHOW ............................................................................................................................................... 20
FIGURE 11: APP SHOWING RBB’S VOTING FEATURE ..............................................................................23
FIGURE 12: GOOGLE PLAY CONSOLE WITH HRADID SAMPLE AND CHAT PILOT APPS................ 25
FIGURE 13: MANAGEMENT OF BETA TEST PARTICIPANTS .................................................................. 26
Page 6 of 27
D2.3: Report piloting activities, user interfaces and integrations - pilot 2 LIST OF TABLES TABLE 1: OVERVIEW OF TECHNICAL COMPONENTS TESTED IN PILOT 1 .......................................... 9 Page 7 of 27
D2.3: Report piloting activities, user interfaces and integrations - pilot 2 ABBREVIATIONS API Application Programming Interface DAB Digital Audio Broadcasting DLS Dynamic Label Segment DL+ Dynamic Label Plus DNS Domain Name System DRM Digital Radio Mondiale EPG Electronic Programme Guide FM Frequency modulation HbbTV Hybrid broadband broadcast Television HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IP Internet Protocol JPEG Joint Photographic Experts Group PI Programme Information PNG Portable Network Graphics NFC Near-Field Communication RBB Rundfunk Berlin-Brandenburg RDS Radio Data System SI Service Information SLS Slideshow Service SPI Service and Programme Information STOMP Simple Text Oriented Messaging Protocol TCP Transmission Control Protocol UI User Interface VRT Vlaamse Radio en Televisieomroeporganisatie VUB Vrije universiteit Brussel XML eXtensible Markup Language Page 8 of 27
D2.3: Report piloting activities, user interfaces and integrations - pilot 2
1. HRADIO APPLICATIONS FOR PILOT 2
This deliverable describes the final UIs and technical implementation details for the
HRADIO pilot phase 2. While in pilot phase 1 the focus was set on individual technical
features (see table 1), in pilot phase 2 real radio applications have been developed,
this enables pilot testing with end users in a more well-known usage scenario in
order to evaluate the basic concepts and UIs of the HRADIO use-cases.
Table 1: Overview of technical components tested in Pilot 1
Product
Product 1: Content Selection and Presentation
(Daylist)
Product 3: Menu
Product 4: Recommendations
Product 5: Voice Control
Product 6: Guaranteed Signal Quality
Product 7: Channel Screen
Following the first review meeting (4 October 2018), an exploitation plan was drawn
up to plan the transition towards a fully exploitable HRADIO platform and
applications. Features tested in pilot phase 1 have been taken as the basis for the
definition of two radio applications: one for in-car usage and a second for usage on
mobile android platforms.
Page 9 of 27
D2.3: Report piloting activities, user interfaces and integrations - pilot 2
Figure 1: From Pilot 1 to pilot 2
(Image taken from D5.1 “2nd Pilot execution and evaluation plan)
This process has been described in detail in deliverable 5.1 “2nd Pilot execution and
evaluation plan”.
Page 10 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2 2. USER & TECHNICAL TESTING PRODUCTS 2.1. TECHNICAL BASIS FOR PILOT 2 APPLICATIONS The technical libraries and API implementations of the HRADIO project will form the foundation of the implementation of the two pilot 2 applications. Starting with the OMRI Libraries, which handle the tasks of receiving the radio signals (either DAB broadcast or IP), decoding audio and data services and finally, enabling the player implementation for timeshift and skipping use cases. On top of the OMRI Libraries, the Pilot application makes use of APIs and implementations for the following functionalities: RadioDNS Library: Discovers and downloads RadioDNS/WorldDAB-SPI/VIS/WEB signalisations and information such as station Logos, additional IP only services, program information and other additional metadata. On top of this, application developers can use this library to handle RadioVIS STOP messages. Timeshift player: The time shift player library provides a ready to use player component for integration in Android applications. The timeshift is saved as a temporary file in the Apps cache directory. Usually it's no problem, however in the case that the device runs low on space it will clean up those directories and could delete the timeshift file. RadioWEB View: For the integration of interactive components, defined by the broadcasters and dedicated for the individual radio station that the applications are currently tuned to, the RadioWEB view provides a ready to use HTMLView and provides a JavaScript interface for the HTML pages to control the OMRI based radio services (pause, mute….). Additionally, callback methods can be added from the JavaScript code to add listener functions for radio services such as DynamicLabel+ and Slideshow. A detailed description of the libraries and APIs is given in D3.3 “HRADIO mobile and HTML client API implementations”1 1 https://static1.squarespace.com/static/59cba0e890bade022b5f58c5/t/5b9a37770e2e7257288402f6/15 36833410927/D3.3+-+HRADIO+mobile+and+HMTL+client+API+implementations.pdf Page 11 of 27
D2.3: Report piloting activities, user interfaces and integrations - pilot 2
HRADIO Metadata platform: This HRADIO component provides additional Metadata
search and lookup services and is used in the Car pilot application for the provision
of recommendations for alternative radio stations. A detailed description of the
REST-APIs and functionalities is given in deliverable D3.2: “HRADIO
CommunicationPlatform”2
Figure 2: Overview over HRADIO technical components
Figure 2 shows an overview of all the HRADIO technical libraries and components.
However, the parts “Usage Data collection”, “TimeShift storage” (for server based
time shift implementation) and the iOS OMRI libraries and components are not part
of pilot phase 2.
2
https://static1.squarespace.com/static/59cba0e890bade022b5f58c5/t/5b9a374803ce64cdc8537709/15
36833360574/D3.2+-+HRADIO+Communication+Platform.pdf
Page 12 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
2.2. PRODUCT 1: HRADIO CAR-CLIENT
Figure 3: Station Screen running VRT’s MNM Hits service
The Channel Screen (or station screen) is the view the user sees when listening to a
particular station. It identifies the station, shows any artwork that might be available
and presents schedule and ‘now playing’ information.
The focus is on eliminating driver distraction due to safety issues. Additionally, there
are laws in many jurisdictions about what screens in cars may and may not do. The
station screen shown in prior work conducted by Radioplayer will be adopted and
refined.
Page 13 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
2.2.1. Time-shifting
Figure 4: Time shifting “radio1” from RBB
Timeshifting has a relatively high TRL. IRT already has a working module which stores
audio client-side and are actively working on a server-side solution. It is intended
however to use the client-side implementation as, at the time of commencing
development, this was more mature. Existing libraries will be integrated in order to
provide a test scenario, during user testing, of pausing and rewinding live radio.
These tests will be of interest because although television has had such capabilities
for many years, radio has never really got to grips with it. Niche radio sets do exist
which support timeshifting, but none have achieved a good UX.
Therefore, serious consideration will be given to the user experience around pausing
and rewinding live radio. There are some challenges related to how the user is
informed about what’s happening and how they revert to the linear broadcast.
Page 14 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
2.2.2. Favourites
Figure 5: Favourite bar
Research by RAJAR in the United Kingdom shows that most radio listeners have a
small number of stations that they listen to the most. The above screen shows how
favourites are added to the app. A heart icon on the right hand side allows the user
to set a favourite. This appears in the Favourites bar at the bottom.
To edit the favourites, a large button on the left of the screen opens the screen
shown here (right). From this screen it is possible to delete the favourites no longer
required.
Page 15 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
Figure 6: Editing the users favorites
Page 16 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
2.2.3. A-Z List/Menu
Figure 7: A-Z list
The menu which was proposed in the first pilot and prototypes will be adopted here.
Therefore, the same functionalities that were available for testing in Pilot 1, will be
found here.
2.2.4. Other features included in the pilot
Recommendations - The Recommender has already been developed by LMU but
has not yet been tested in the field. We should attempt to test the recommendations
API in the lab using live radio listening only, as it’s easier to create associations
between radio stations rather than between individual items of on-demand
content.
RadioWeb view - In order to allow testing of content-led experiences, it is useful to
provide a method by which broadcasters can present content in the radio
experience. At the same time, we must consider the impact of driver distraction. A
web view will be introduced into the channel screen. For a station that has additional
content available, a button will appear on the screen which opens a web view. The
URL of the webview would be determined by the broadcaster.
Page 17 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
Figure 8: RadioWEB sample for VRT “Radio1”
Voice Control - Voice feedback will provide the user with an audio confirmation
whenever they change stations. It will announce the station without the user
needing to look at the controls. Voice commands are also important - the ability to
change stations via voice commands will completely remove the need for a screen.
Excluded from the pilot
Guaranteed Signal Quality - Otherwise known as true hybrid service following, has
been built into the OMRI libraries. As this is a technical capability not a feature, it was
operational transparently in the pilot but no attention was drawn to it with users
during tests.
2.3. PRODUCT 2: HRADIO GENERAL MOBILE CLIENT
For the Smartphone app we used libraries from IRT for following purposes:
• OMRI - Scanning to stations (IP and DAB), decoding the DAB streams
• IRT time shift player - stream playback, time shifting
• RadioDNS - Retrieving and Parsing the RadioDNS EPG data + images
Page 18 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
• Substitution - second player to integrate your own music files into the DAB
stream
2.3.1. Start Screen (Menu)
After starting the app displays a channel overview with all found channels. If a DAB+
Device is connected to the phone, it is possible to perform a DAB band scan and use
DAB+ Channels over the air, otherwise we show provided EDI Streams (DAB+ over IP).
Figure 9: App running with start screen showing VRT’s radio services
We are using OMRI for scanning for stations and Radio DNS for retrieving logos of the
stations. After opening a channel by tapping on the specific Icon, the app starts the
channel and opens the channel screen:
2.3.2. Radio Station Screen (radio feed)
The radio station screen is built as an information feed to make it highly
customizable, with different features in one view.
Page 19 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
Figure 10: App running with Stadion screen showing rbb’s radioeins, right with slide show
The stream is built as a raw AAC stream and comes from the OMRI library. The OMRI
Library searches for DAB stations; after selecting a station, the stream is converted
and transferred to the time shift player and played.
For metadata, a distinction is made between RadioDNS EPG data and metadata
directly from the DAB stream.
• Metadata from DAB Stream: coming as textual and visual data from the OMRI
Library into the Time shift player. There they are processed (collected, sorted
by DAB tags until skip signal arrives) and forwarded to the chat view. In the
ChatView, the data is then re-evaluated to generate chat elements.
• Radio DNS EPG data: The EPG data are read in at the beginning -after selection
of the stream- and processed internally. These are then sent directly to the
ChatView to display additional information about the current content (i.e.
information that was not transmitted via the DAB stream).
Technically, the view is built as a webview with HTML (+ CSS Styling ) and Javascript,
actually served by a webserver for giving an easy possibility to update and change
parts, without creating a new App Version. Basically, it is designed to run locally, so
that in later phases all the view-dependent stuff can be shifted over to the app. This
is needed to make the app usable without a working internet connection, with just
Page 20 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
usage of a DAB+ Stream. For sure, without an internet connection some features are
not usable.
Used Libraries:
• IRT time shift player - stream playback, time shifting
• RadioDNS - Retrieving and Parsing the RadioDNS EPG data + images
• Substitution - 2. Player to integrate your own music files into the DAB stream
Libraries in Webview:
• jquery - for comfortable javascript and ajax functions
• sweetalert - nice alert dialogs
Distinction of metadata (see above):
1) Metadata from DAB+ Stream - Required to create chat items and current song
information, taken from dynamic Labels with the specific types.
Differentiation of the chat elements:
a) Song Elements: Show Song Title, Artist, Cover u.U. more interaction options.
They also offer the possibility to Timeshifting to specific points in the stream
(beginning of each element)
b) Slideshow elements: If present, display changing images (DAB-SLI) for the
current song element. Only 1 slideshow element per song element. Are not
Timeskippable and offer no further interaction possibilities
c) Information elements: Are created independently of metadata of the DAB
stream or the Radio DNS data. Integration takes place via own data interface
or via the MARCONI-Integration
Current song information includes title, artist, cover image and other
information, if available, such as presenter, current news, genre, program name
2) RadioDNS data was used to enrich the metadata in the Player Bar (lower edge)
and the Station Images
2.3.3. Player-Bar
A small view element fixed at the bottom of the station view, to display the actual
playing state (playing or paused in mode "Live", "Time shifted", "Substitution", later
also Audio on demand for podcast or similar), the actual song/artist and actual
program information from the EPG data. Also the area provides control buttons for
the player. Depending on the actual state, users can start and stop the Stream or
Page 21 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
skip (substitute) the actual item. Also, the player can be extended to make more
controls visible and accessible, for example rewind, fast-forward and back-to-live.
If available, it also displays artwork for a playing song. For demo purposes the
backend requests covers from iTunes, but the source can be changed easily. (For
example by a cover database provided by the station itself).
2.3.4. Timeshift Feature
This is done using Time shiftplayer (AAC Stream) and collected metadata. There are
two ways to activate the feature:
1) By clicking on song elements / Time shifting metadata-based:
During playback of the DAB stream, all associated metadata is collected and
stored. This allows for skipping (time shifting) at certain times within the stream
being played, e.g. the beginning of a song.
2) By Click on one of the player buttons / Time shifting time-based:
Possible time-based time shift interactions are: pause / continue, jump 30s back,
jump to the beginning of the stream, jump to the live stream
2.3.5. Substitution Feature (only local)
The music substitution allows a user to replace a currently live song with a locally
stored song. This is done in two steps:
• Select a local folder with music files to use for substitution. While the stream
is playing, the user can tap on the substitute button to change over from the
actual playing live stream element to a local stored music (mp3) file.
• Substitution is done with a second internal audio player (called substitution
player) which is used in parallel with the time shift player. The time shift player
is just muted but remains to handle incoming DAB+ Stream data to make it
available later, or to jump to the missed part (if the user changes his mind).
After the substitution player stops, the time shift player takes over again.
2.3.6. Slideshow Feature
DAB+ Slides, coming over the DAB+ streams, are inserted to the radio feed as a single
item, which updates its content while the same song (element) is played. After a
new element starts (such as. A new song, news, … ) a new slide is inserted as a new
item.
Page 22 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
2.3.7. Chat Feature
If the currently playing channel supports a chat backend, the user is able to send
messages to the studio. For fast access to some predefined information requests,
such as asking for actual weather, we added some quick-buttons that send a
specific question to the backend.
2.3.8. Voting Feature
Figure 11: App showing RBB’s voting feature
The user is able to Like or Dislike a song. His vote is sent to our server via an ajax
request and stored with a unique user id (generated by the App). Later the
information can be displayed to the broadcaster’s editorial side via an app CMS. We
also plan to use this information for automated recording of a song, that then can
be used for substitution.
The audio (song) information is transferred from the DAB+ stream, the dynamic
label data, to the chat view via the time shift player.
2.3.9. Greeting Feature
A small feature but nice experience provides a small greeting in the radio feed. On
the first visit, the user is asked for his name. Later it is used for a welcome back
message.
2.3.10. Analytics
To analyse pilot activities, we collected data on when a feature is used and how long
a channel is opened. Data is stored anonymously at first; only if the user provides a
name - we store a reference to it. This makes analysis of pilot activities easier. In a
real environment, users will not be identified and usage data will be anonymized.
Page 23 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2 Collected data is stored in a table with the following fields: • Date-Time • Channel • User-ID • Feature used • Optional parameters Page 24 of 27
D2.3: Report piloting activities, user interfaces and integrations - pilot 2
3. DEPLOYMENT VIA GOOGLE PLAY
Google Play is an app store that lets you install apps and games on Android
smartphones, tablets and Android TV. The apps offered come almost exclusively
from third-party companies and free software developers. Both free and paid apps
are offered, with free apps outnumbering paid apps.
For the deployment of the HRADIO pilot 2 applications, an HRADIO dedicated Google
Play Store account has been set up. Normally, the aim of the Google Play store is to
distribute apps to millions of customers and handle the payment for commercial
applications. For developers there is a one-time registration fee and the possibilities
to deploy applications to a closed user group for testing only.
Figure 12: Google Play console with HRADID sample and chat pilot apps
This set up makes it very easy to add people to the pilot test program because only
the person’s GoogleID (which is used to sign into the Google Play Store) must be
added to the list of allowed beta testers. Once added, an invitation link is sent to the
Page 25 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2
person and the application can be installed as any normal Android application from
the Google Play Store. Updates are automatically announced to the beta testers.
Figure 13: Management of beta test participants
Page 26 of 27D2.3: Report piloting activities, user interfaces and integrations - pilot 2 4. CONCLUSION For the HRADIO pilot phase 2, two android applications have been developed and deployed. Both of these two applications make use of the WP3 developments such as OMRI, Timeshift substitution and RadioDNS libraries. While the Car application follows the approach to provide a general radio app to the pilot participants with the focus on in car usage (clean UI, voice control), The “Chat” application for smartphone focuses on the chat concept UI with a strong integration of time shifting, substitution and user interaction. For the deployment of the pilot applications to the pilot participants, a Google Play Store account has been set up. This proved to be very handy in case of short-term changes and bug fixes, which wouldn't be possible with APKs distributed over Slack, Mail or general file sharing. Page 27 of 27
You can also read
