Travel Disruption App - Signly
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
DfT Transport Technology Research Innovation Grant
(T_TRIG April 2018) Feasibility Study
Signly
Travel Disruption App
PREPARED FOR David Franklin & Sviti Pabari
CLIENT Department for Transport
DATE 02 October 2018
VERSION 2.0
Mark Applin/Signly
PREPARED BY Kate Horbury/LNER
Sean Douch/Rendili
1.1 Table of contents
1.1 Table of contents ..................................................................................................................... 2
3 Acronyms 4
4 Executive summary 4
4.1 Intended audience .............................................................................................................. 4
4.2 Project methodology .......................................................................................................... 4
4.3 Most important findings: ................................................................................................... 5
4.4 Main recommendation ....................................................................................................... 5
4.5 Aims, objectives and outline ............................................................................................. 5
4.6 Current initiatives ................................................................................................................ 6
Online ................................................................................................................................................. 6
Stations .............................................................................................................................................. 6
Onboard ............................................................................................................................................. 6
4.7 Analysis .................................................................................................................................. 6
4.8 Data workshops with D/deaf passengers ...................................................................... 7
4.9 Stakeholder consultation ................................................................................................... 8
4.10 Data quality ........................................................................................................................... 8
5 How the idea was generated 8
6 Technology review - Darwin data feed 9
A data table of key disruption messages .................................................................................. 10
6.1 Data collection from Darwin ........................................................................................... 10
Daily schedule and reason codes ............................................................................................... 10
Real time changes ......................................................................................................................... 10
6.2 Conclusions ...........................................................................................................................11
7 Technology review - locating the passenger 11
7.1 Geolocation ...........................................................................................................................11
7.2 Geofencing ............................................................................................................................11
7.3 RFID – Radio-frequency identification / NFC - Near Field Communication ...........11
7.4 Ultrasonic ..............................................................................................................................11
7.5 Wayfinding Beacons ...........................................................................................................11
7.6 Conclusions ...........................................................................................................................11
8 Technology review - current apps 12
8.1 Google and Apple Maps .................................................................................................... 12
8.2 Google Now (Android and iOS) ........................................................................................ 12
8.3 National Rail Enquiries App .............................................................................................. 12
8.4 Conclusions .......................................................................................................................... 12
9 Technical review - assumptions 12
10 Key technical concept 13
11 Push based opportunities 13
11.1 Live or pre-recorded BSL interpreter.............................................................................. 13
11.2 Pre-recorded vocabulary .................................................................................................. 14
2
11.3 Virtualised 3D BSL interpreter .......................................................................................... 14
11.4 Rich notifications / widgets (recommended) ............................................................... 14
11.5 Intellectual property rights ............................................................................................... 15
11.6 How does the feasibility study address key DfT priorities? ....................................... 15
12 Practical applications of the concept to the UK transport system 16
12.1 Primary market and customers ....................................................................................... 16
12.2 Pricing model ...................................................................................................................... 16
12.3 Size of market...................................................................................................................... 16
13 Delivering the product roadmap - next steps for implementation 16
13.1 Darwin data costs ............................................................................................................... 16
13.2 Development Costs ............................................................................................................ 17
Phase 1 (3 months project timeline) ............................................................................................ 17
Phase 2 (6 months project timeline) ........................................................................................... 17
13.3 Potential accelerators ........................................................................................................ 17
13.4 Champion database ........................................................................................................... 18
13.5 Funding calls ........................................................................................................................ 18
13.6 Equity investment and private funding ......................................................................... 18
13.7 Exploitation plan ................................................................................................................. 18
13.8 LNER ...................................................................................................................................... 19
14 Annexes 19
14.1 Promotional video .............................................................................................................. 19
14.2 Bibliography ......................................................................................................................... 19
14.3 Focus group ......................................................................................................................... 19
List of persons interviewed at DCAL........................................................................................... 19
Data ................................................................................................................................................... 19
14.4 Sites visited .......................................................................................................................... 19
14.5 Highlighted comments from focus groups: ................................................................. 20
14.6 Sign language comparator: ............................................................................................. 20
Written English ............................................................................................................................... 20
BSL English ...................................................................................................................................... 20
14.7 What is a Service Worker?................................................................................................. 21
14.8 Proposed system design .................................................................................................. 22
Pros ................................................................................................................................................... 22
Cons .................................................................................................................................................. 22
14.9 Example Push Notification designs ............................................................................... 24
3
2 Introduction
The feasibility study was commissioned by DfT in March 2018 for a duration of six months and the
project was based in the UK. The project team included Signly Ltd (Hampshire), Rendili Ltd
(Hampshire) and LNER (London).
3 Acronyms
BDA British Deaf Association
BSL British Sign Language
CGI Computer-generated Graphic
CIS Customer Information System
deaf Small d deaf people are those who have become deafened or hard of hearing in
later life, after they have acquired a spoken language and so identify themselves
with the hearing community. Small d deaf people are more likely to use hearing
aids and develop lipreading skills. Source: Deafax
Deaf A person who identifies as being Deaf with an uppercase D is indicating that they
are culturally Deaf and belong to the Deaf community. Most Deaf people are sign
language users who have been deaf all their lives. For most Deaf people, English is a
second language and as such they may have a limited ability to read, write or speak
English." Source: NHS Accessible info standard
DCAL Deafness Cognition and Language Research Centre
GPS Global Positioning System
LNER London North Eastern Railway
MVP Minimum Viable Product
NFC Near Field Communication
NRE National Rail Enquires
ORR Office of Rail Regulation
OS Operating System
RAD Royal Association for Deaf
RDG Rail Delivery Group
RFID Radio-frequency Identification
SDK Software Development Kit
SFO Station Facility Operator
Tannoy Colloquial and trademark name of a sound-amplifying apparatus used as a public-
address system used within a station or train
TOC Train Operating Company
UCL University College London
UI User Interface
4 Executive summary
D/deaf passengers can’t always hear Tannoy announcements, missing vital information. This
project investigated potential digital solutions to improve the travelling experience of this user
group and by extension, a wider group – those who render themselves ‘deaf’ when using
headphones.
The overall project goal is to improve accessibility for the D/deaf.
Watch a 90 second video on Disruptly.
4.1 Intended audience
There are 11 million people with hearing loss across the UK, that's around one in six of us. An
estimated 900,000 people in the UK have severe or profound hearing loss. (Loss, n.d.) Applying this
ratio, on a train carrying 1,200 passengers, 16 passengers may have severe hearing loss.
The D/deaf community want to be independent and for this they need access to the same
information which is provided to other rail customers.
4.2 Project methodology
The feasibility study utilised:
4
• a focus group to gather and synthesise research into the needs of the D/deaf community and
public transport - specifically train travel
• discussions with existing providers to test our assumptions around travel issues
• a full technology review of current hardware and software infrastructure and data systems that
could be utilised to deploy a digital solution to enhance travel for the D/deaf community.
4.3 Most important findings:
The feasibility study confirmed our assumptions that the D/deaf community have a specific need,
that of being better informed of rail disruption and that by providing this information in a useful
and timely fashion DfT would provide a large gain in terms of overall rail travel satisfaction from
within the community.
During rail disruption, passengers are often informed through Tannoy systems or by members of
staff. This means that for the D/deaf community, it can be incredibly difficult to understand what is
happening. Whilst the D/deaf community understand that employing more BSL conversant staff
isn’t practical, they felt that disruption information needed to be available to them in a suitable
medium.
Our focus group highlighted this need in many conversations around missing trains, missing
changes on trains that switched to a fast service and thus being forced to use other modes of
transport. Disruption is never good; but the impact on the D/deaf community is even more
profound.
For many D/deaf travellers, just being at a station where passengers could be required to move
from platform to platform, responding to Tannoy announcements is at best a frustrating
experience and at worse a debilitating one.
4.4 Main recommendation
Our main recommendation based on the feasibility study is to secure funding to produce and
deploy a visually rich Push Notification and App service using Darwin train data.
4.5 Aims, objectives and outline
Our feasibility study was designed to gather new first-hand research and enhance current findings
on how best to enhance the D/deaf communities use of rail transport though a digital solution.
Although we understood there are many issues that revolve around travel for this community our
main assumption was that the use of Tannoy messages and current data when trains are disrupted
or changed was a huge barrier for the D/deaf community.
This study builds specifically on several pieces of research. One of these is the report “
(Focus/Southern, 2011)” which highlighted passenger needs:
• Accurate, timely and consistent information is critical to the effective handling of delays
because it allows passengers to make informed decisions about what they do.
• Once caught up in a problem, passengers need to know how long they will be delayed – having
that knowledge allows people to judge the impact on their day.
• Passengers want train companies to actively tell them if there are problems, particularly if there
are cancellations or a temporary timetable is being introduced.
The use of the Tannoy system on stations and in trains along with changes to the information board
data helps to address some of the recommendations, however for many of the D/deaf community,
verbal communication is severely challenging and audio Tannoy announcements present a clear
issue. British Sign Language (BSL) also does not rely on the written word and so even information
broadcast in text will not reach all the travellers in a timely fashion.
The Office of Rail Regulation (ORR) recognised this in their report “ (ORR, 2015)” stating that not
only was the vast majority of this information not accessible to people with hearing impairments, a
lack of consistency across stations meant that customers may have to acclimatise to a new system
at each station.
5
4.6 Current initiatives
We’ve showcased current initiatives specifically by London North Eastern Railway (LNER) to provide
several support options for D/deaf customers which centre on personal assistance provided by
LNER employees.
All Frontline staff receive disability awareness training, and some have attended Introductory BSL
training sessions in their own time. Staff can also be booked to assist - the LNER Journey Care team
can help with planning journeys, reserving seats, wheelchair spaces, buying tickets, arriving at a
station, changing trains, and on reaching the destination.
Online
The LNER website provides a journey planner, service update boards (live line statuses), SMS
updates and a Twitter channel, alongside the National Rail Enquiries site and mobile app who also
provide access to a journey planner, live departure details, TrainTracker and TrainTracker Text and
Alerts and a Twitter channel.
Stations
Services include several Customer information systems. The Control team provide a disruption
warning in the form of messages on a customer information system as well as maintaining an
accurate and updated timetable. Announcements are made from the Control Centre including
automated train delay announcements via mobile public-address equipment and staff are
encouraged supplement standard announcements with more personalised information for
customers at the station.
LNER staff actively look for customers at stations who need additional assistance. Help points are
available on all stations which are handled by National Rail Enquiries or the Control teams.
Additional information pods are being introduced at every station to make staff more visible to
customers.
Knowledgebase is a national database which details accessibility at stations and helpline numbers
and it includes information about significant temporary work being carried at stations.
Clear and consistent aural and visual information about train departures and other relevant
messages is provided through customer information screens and public-address systems available
at all LNER stations, particularly in the event of delays or disruption. LNER have installed additional
’interactive’ smart screens at all stations where LNER are Station Facility Operator (SFO).
Information points and displays at larger stations have staffed information points. At smaller
stations, booking offices can provide information.
Onboard
LNER staff will look out for customers with specific needs and offer to help, whether assistance is
booked or not. Customers with impaired hearing, vision or where mobility is impaired can tell the
onboard team as soon as possible.
All trains have public address equipment and external facing signs in each coach showing the stops
the train will call at. Onboard teams make clear audio announcements when delays occur, and
before each station stop in plenty of time.
During a site visit to Kings Cross station, current rolling stock was reviewed. Carriages do not have
information boards making passengers reliant on audio announcements. Plans are being made to
roll out ticker-tape style information boards on 15 trains.
4.7 Analysis
Commendable though all these initiatives are, the fact remains that when unplanned disruption
occurs, platform screens can be cleared or out of sync with real-time delay and changes, and
passengers become reliant on Tannoy announcements and staff assistance in both the stations and
onboard.
Compounding communication issues is the fact that Sign language has very different vocabulary
and grammatical structures to spoken or written languages. In spoken English the average person
6
has a general vocabulary of about 15-20,000 words. In British Sign language (BSL) it is nearer 3,000
signs. BSL is a more concise and precise language and rarely has two signs meaning the same or
similar things; unlike English which often has several words meaning similar things. In addition, BSL
has a different grammar structure to English, putting the topic or most important part of the
sentence first followed by the timing of the event. It does not have any tenses, instead it positions
verbs or actions along one of its four timelines.
For people born deaf or who became deaf in early childhood, literacy rates are lower. Studies
looking at a cohort of deaf school leavers found that deaf pupils left school with median reading
ages of nine; with poor speech intelligibility and with lip-reading skills no better than those of the
hearing population, despite their training in this area (Conrad, 1979). Such poor achievements were
also demonstrated in other studies from other countries. However, this is often sufficient to read
(and write) simple texts – especially those using only brief phrases rather than full, complex
sentences.
Therefore, the specific situation and current solutions for unplanned disruption mean the D/deaf
community find themselves one of the most vulnerable. The (Action On Hearing Loss, 204) report
Access to rail travel for people with hearing loss found that one third of people feel vulnerable
when using trains because they are D/deaf.
The report also concluded that eight out of ten people feel that staff are not D/deaf aware meaning
they are unable to communicate properly when disruption issues arise. The same number advised
that there is not enough information available to let them know if the platform has changed. Nearly
nine in ten people cannot hear announcements when travelling on the train and only one in ten
people said that visual information screens gave enough real-time information about unexpected
events. This resulted in over a quarter of these travellers missing their station because they
couldn’t hear announcements.
This feasibility report itself extends a 2017 study by Signly commissioned by Arriva Rail London to
better understand the needs of D/deaf travellers, including language(s) of information delivery and
priorities for information to be translated into BSL, specifically using technology.
The feasibility report team met to discuss the project and agree responsibilities, budgets and
project management and control processes. The project was divided into six sprints:
1. Project initiation, including project set up and workshops with D/deaf passengers. Sign up to
Darwin and assess data feeds
2. Investigate how to trigger app to listen – location, beacon, Maps integration. Consult with LNER
on data.
3. Research machine learning element. Research sentiment analysis engines. Is custom
middleware to parse unstructured data – how in integrate
4. Create data table of key disruption messages to enable widget set to be catalogued.
5. Create app database schema highlighting recommended services, connectors. App wireframes.
6. Write first draft report. Write final report and share. Project review. Project ends
4.8 Data workshops with D/deaf passengers
Data was collected in demographic and experience questionnaires alongside focus group
discussions. Demographic information was required to meet recruitment criteria for the two
groups, train staff and D/deaf train customers. The experience questionnaires were designed to
gather quantitative information about train usage and communication preferences.
The focus groups enabled the gathering of feedback and opinions in depth, with each group
member encouraged to participate in discussion of topics pre-planned by the researchers and
guided by a facilitator. Focus group discussions were video-recorded and transcribed for analysis.
The staff discussion was in English; the Deaf discussion was in British Sign Language with a Deaf
facilitator.
The Deafness Cognition and Language Research Centre (DCAL), University College London (UCL)
convened three focus groups of five signers: 18-30, 31-50, over 50, all of whom are commuters or
rail users alongside data supplemented using the on-line questionnaires.
Focus group participants were selected in several ways. The D/deaf participants were recruited
from a large database of D/deaf research volunteers held at UCL. The database was searched for
7
potential participants who identified themselves as Deaf, whose preferred language was BSL, who
lived in the Southeast of England, and who were regular users of main line trains and/or London
transport. Those meeting the criteria were invited to attend the focus group.
General questions gathered background data included:
• Information on language preferences, use of BSL and English, etc.
• Info on use of train services
• Info on how information is accessed: (Regular, Travel updates & in emergency settings)
Currently, when encountering engineering works/disruptions/delays:
• 73% would contact their families or friends by text messaging to ask them to check for them.
• 43% approach station staff
• 34% ask other travellers for information
Analysis of the demographic questionnaires provide quantitative details of the sample
characteristics (age/gender/degree of deafness/language preferences, etc.) Additional
quantitative information was provided by the experience questionnaire (communication with train
and station staff/use of technologies for communication, etc. The analysis of the focus groups used
qualitative methods to identify deductively themes in participants’ responses. As is the case with
focus groups, inevitably there is a balance between access to only a small number of participants
and the depth and breadth of discussion possible in such small groups.
4.9 Stakeholder consultation
Members of the D/deaf community have been actively involved in the development of the
research proposal, selection of participants, and in facilitating the Deaf focus group. To that end,
the workshops for Deaf passengers were led by a Deaf consultant, appointed by DCAL. Sign
language interpretation was provided to support the communication between Deaf and hearing
attendees and participants.
Discussion focussed on their experience at station and on train and included examples of
interactions from passengers and staff. The sessions were videoed (with permission) and
transcripts and analysis provided to the project team.
4.10 Data quality
Protocols were jointly developed by the project team, with extra input from Deaf colleagues. To
ensure quality control, all participant material is video-recorded, with – for the Deaf group - a
simultaneous interpretation into English provided as the sound-track to the video and a second
independent translation prepared after the session. Both versions feed into the analyses. The
demographic questionnaires have been used extensively by DCAL over the past 12 years.
5 How the idea was generated
The project team took the synthesized research and data and ran a workshop to triage the biggest
obstacles to passenger experience for the D/deaf and then met (virtually) bi-weekly, usually on
Tuesday morning. The project plan is available to all members online (SmartSheet).
Unsurprisingly, the experience of the D/deaf travelling public mirrored that of the hearing
population and attendees agreed that disruption is a major issue.
The research supports the concept of more visual presentation of the disruption data for D/deaf
passengers and the overarching commentary was that it would be helpful to sign up for specific
travel updates and to be able to access this information through their phones.
Although prior to travelling, participants were happy to obtain travel information from websites,
apps or by contacting family and friends whilst travelling, a high proportion wanted to be self-
reliant and have visually displayed information to match any unexpected live announcements. This
is essential if all D/deaf travellers are to be aware of what is happening in real-time.
8
To address the findings from the research, we explored a range of digital options that could be
implemented to improve the travelling experience of the D/deaf community.
The purpose of the service would be to provide on-time, insightful information about current
delays and cancellations on the network.
This report outlines the following:
• A review of existing technologies that could be adapted and utilised within an app for rapid and
cost-effective delivery.
• A review of the pros and cons of each solution.
• A recommended solution and requirements for its successful implementation.
• A product definition and a schema describing the coding architecture.
6 Technology review - Darwin data feed
Darwin is the UK rail industry’s official train running information engine, providing real-time arrival
and departure predictions, platform numbers, delay estimates, schedule changes and
cancellations. It is the only system in the UK to take feeds directly from every TOC customer
information system (CIS), combining it with train location data provided by the railway
infrastructure manager, Network Rail. Darwin data powers most online channels including all
National Rail Enquiries products, all TOC real-time digital channels, as well as the digital products
made by hundreds of independent and commercial developers including Google Maps and The
Cloud.
A programme to connect Darwin to CIS screens in every station in the UK was completed in 2015,
meaning that if Darwin data is used in a digital product, the information shown in that product will
be consistent with the information shown on departure and arrival board screens in almost every
station across the country.
Darwin data feeds are openly available to everyone. The following table is an extract of a single
journey update from the Darwin feed:
2
2
1
1
1
1
9
1
From time-to time LNER platform information boards are cleared when extreme disruption occurs.
When services are rescheduled, there can be discrepancies between the boards, what’s happening
on the ground and what the Tannoy is announcing. This creates extreme confusion for those reliant
on the boards by virtue of hearing loss.
The data is well structured and will not need sentiment analysis to extract key information. For the
purposes of data visualisation, we are particularly interested in focusing the data on impact to the
passenger in the first instance – what action they need to take and the likely big picture impact on
their journey.
Key data may include:
• Delays
• Cancellations
• Alternative transport options in the event of above
• Platform changes
• Train arrival at station
• Which carriages will be on the station (for short stations)
• When a passenger is on the move they will not want updates on every single train; instead the
service will display the right information the passenger will need at the right time.
A data table of key disruption messages
Reason Description
Train arriving late at source The train will be late arriving at the embarking station
Train arriving late at destination The train will be late arriving at the destination station
Train has been cancelled at source The train will not be arriving at the embarking station
The train will not be arriving at the destination station.
Train has been cancelled en-route More details need to be given about the next steps
(another service, bus / taxi, etc…)
Train will be arriving on another The train has changed platforms at the embarking
platform station, details provided about old and new platforms
The train is coming to the destination station. Any
Train shortly arriving at destination details about which carriages will be on the platform if
possible
Details about the train splitting and which carriages
Train will be splitting at the next station
will be continuing to the destination station
The proposed format could also be expanded to include a reason chosen from a list of predefined
variables. The arrivals data can be used as is to provide the target audience with information about
when the next train is due, converting the time to minutes until arrival.
6.1 Data collection from Darwin
Daily schedule and reason codes
We would load the data daily for the next available days train journeys from Darwin into our own
database. This will form the baseline setting for each train journey for the system to compare
changes with. Our servers will also get data on the Darwin reason codes which describe why a
service has been changed. These codes will be mapped to our reason disruption messages above
and new codes will be flagged to be manually mapped.
Real time changes
The Darwin Push Port system will be constantly monitored to get notifications about changes to
the services. As these changes are determined, our database is updated and notifies the relevant
passengers.
106.2 Conclusions
The Darwin feed from National Rail has been determined as the most relevant and timely source of
data. LNER have ratified our thoughts.
7 Technology review - locating the passenger
7.1 Geolocation
The location of a user’s device can be determined without a Global Positioning System (GPS) fix
using either cell tower triangulation or connecting to located Wi-Fi network. Triangulating the
signal between cell towers can approximate the position of a user’s phone. There is a global
database of known Wi-Fi networks and their location, using the signal strength of the Wi-Fi
network it can approximate the user’s location. Pinging the user’s location would be more battery
saving than keeping a constant fix on their location. This may not be as accurate as GPS but would
work well for tracking the user to a general area. The phone can attempt to triangulate position or
even prompt and suggest your location. However, repeated use of GPS can drain a device’s battery.
7.2 Geofencing
GPS could be used to create a ring fence around stations, it would require us to know the GPS co-
ordinates of every station.
Using GPS, a device can track its user; an app can then be set up to recognise geographically
defined areas in which a certain action should be triggered. Using the Darwin API, the app could
recognise a user’s proximity to a station with a delay and send a push notification to alert them or
trigger the notification.
7.3 RFID – Radio-frequency identification / NFC - Near Field Communication
NFC is a manual scan and only supported on iPhone 7+ and Android phones with NFC read.
7.4 Ultrasonic
Apps can now send and receive ultrasonic signals via speakers and microphones to communicate
with other mobile devices as well as with TVs, or other IoT devices. Users can be unaware of these
interchanges since the sound of these signals are near the edge of or outside the human hearing
range. Ultrasound can also be useful in establishing precise location tracking to track users’ exact
locations in a way that is more granular than Android’s normal location permission allows. For
instance, apps using ultrasound may know the exact store and level a user is in a shopping mall in
addition to the latitude and longitude normally provided by the Android system.
7.5 Wayfinding Beacons
These can provide a signal that the phone can use to pinpoint its location. Useful in scenarios where
the built environment makes ascertaining location via GPS satellites difficult or impossible
(Underground). These are currently not installed in UK stations.
7.6 Conclusions
RFID and Wayfinding Beacons require significant investment in adding the technologies into
stations that make them unfeasible at this time. GPS and Assisted GPS using the built in location
services of the device seem the most appropriate technology for locating a user in the first
instance. Later ultrasonic station location could be added to give a more detailed information about
a user’s location, such as whether they are on a platform or on the train in the station.
In many ways locating the passenger can already take many different approaches, but what is
needed when in transit is a live connection to ensure that the passenger receives the disruption
data at the very moment they need it. With the current infrastructure, consider mobile data and
Wi-Fi are considered to be the main options. Messages and Notifications can queue server side
until a connection is established.
RFID would be useful for requesting information on platforms and stations and this could be
located on help points to trigger the latest disruption alerts, with the passenger walking up to them
11to scan, but these points would need to be installed and for the main alerts a push notification
would be the correct option. This would need to use mobile, Wi-Fi, ultrasonics or beacons.
However ultrasonic and beacons technology would require new hardware to be installed in many
locations at a large cost.
Wi-fi and mobile data are the most appropriate options at this stage.
Train Wi-fi providers could enable a web service priority over the Wi-fi connection so that
passengers are alerted even when there is heavy Wi-fi usage, the second choice would be then to
use mobile data. Messages and notifications can be very small in data use, testing to use efficient
mobile bandwidth would optimise this, so even on the slowest connections disruption information
could be received. Overall there is a good level of infrastructure for Wi-fi and mobile data in place,
however more stable and faster Wi-fi would ensure that notifications arrive as soon as required.
8 Technology review - current apps
8.1 Google and Apple Maps
Many passengers use a mapping service such as Google Maps to plan their trip. This provides data
on which station and service will be used for the app to draw on. Directions for driving, public
transit, walking, or biking on Google and Apple Maps can be actively adjusted for some elements of
the journey.
Google Maps provides platform details but does not push a platform change notification. Apple
Maps provides no platform data.
8.2 Google Now (Android and iOS)
Utilises Google Cards and can pop up and display information to the user. Google Cards allow the
user to enter information about their interests and the device will learn the habits of the user.
Having learned this, it can suggest travel routes based on the current data.
8.3 National Rail Enquiries App
A free app, available for both Apple and Android, serving up live status updates and alerts.
The new ‘Alert Me’ feature provides a push notification detailing the following:
• When your next train to X destination is scheduled to depart
• Whether that train is on time or delayed
• Whether your service is a replacement bus/other method of transport
• What platform the service will be departing from (providing a platform number has been
released)
• Whether there is disruption affecting your route
8.4 Conclusions
With the Operating System (OS) integration both instances Maps and Google Now, it is the provider
of the service that would choose to integrate a digital service, not vice versa.
The NRE app currently does not issue live platform changes or if a train changes to a fast service in
the middle of its route. We have opened dialogue with NRE to establish what’s possible.
Integration at this level with either party currently would be very hard to obtain.
9 Technical review - assumptions
The Journal of Deaf Studies and Deaf Education paper (Pagliaro, 2014) indicates frequent use of
smartphones, specifically for text-based communication and the web. The study’s findings indicate
that technology may indeed provide a “level the playing field.”
Deaf passengers are thus considered heavy users of the latest technology and it can be assumed
that most will have access to a smartphone or tablet. An important distinction must be made
12between low literacy and no literacy. Whilst Deaf users may be more confident with more visual
forms of communication, this doesn’t preclude them from access to short form pieces of text
based information such as times or place names. A communication preference for sign language
has nothing to do with cognitive ability.
Successful service launch depends on competitors (National Rail or Google for example) not doing
the same thing soon.
We assume the Darwin feed is timely and accurate. Darwin can be updated by staff but will only
show correct info.
10 Key technical concept
Once we locate the passenger, using the data from Darwin we are able to provide at real time
disruption trigger and transform that data and present it to the passenger in a timely fashion. If
location cannot be pinpointed by other means a manual override could enable the passenger to see
all disruption information for that station or service.
Whilst SMS plain text notifications will suit some D/deaf passengers, SMS plain text notifications
also rely on access to the mobile network which may cause delays if the passenger isn’t within
range of a signal.
An email-based notification would need to be requested by the device, rather than pushed to the
device, this setting by default set to check once every 15 minutes, which would make using it for
notifications impractical.
Our research concludes that the D/deaf community would much a prefer smart device notification.
A push based service can be delivered to a smart device over the mobile network or via Wi-Fi, so
gives the best chance to deliver in a timelier manner. A push based service on a smart device can
also deliver the information in a number of formats for our target audience.
11 Push based opportunities
Within the feasibility study we investigated a number of push based opportunities. Below we
outline the three possible solutions we have considered from the study.
11.1 Live or pre-recorded BSL interpreter
A group of BSL interpreters could be recruited to control centres ready to send out live BSL
interpreted delay notifications as video streamed straight to the app. To deliver this service, a
formal arrangement could be made with an existing BSL video relay service (InterpreterNow, Sign
Video etc.) and a service level agreement made. However, the immediacy of the nature of the
messaging combined with pushing a video notification (much higher mobile or Wi-fi data needed)
could result in delayed or buffered transmission.
13Recruiting people to control centres would be costly, though this could be minimized by using an
organisation which has this network already in place and available, such as a BSL video relay
service. Signers would need to work shifts and have cover. Again, this is already provided by video
relay services, though an SLA would be required.
11.2 Pre-recorded vocabulary
BSL does not lend itself to pre-prepared, chunked structures. It is not a verbatim translation of
English, and has its own grammar, syntax and styling options. Not only would a database of
variables be needed (at word, phrase and sentence level), but also the solution algorithm would be
very complex. The resultant video is likely to be jerky and disjointed and may not actually make
sense in BSL.
11.3 Virtualised 3D BSL interpreter
A virtualised 3D BSL interpreter within the app interprets the data about a delay and provides BSL.
Avatars have not been accepted by the Deaf community for delivering sign language. Facial
expressing, body language and non-manual features are all integral to the language, and much of
the sense may be lost when using avatar or Computer-generated Graphic (CGI). The
developmental cost of building a 3D avatar and ‘teaching’ it BSL would be huge. This could be
limited by having a restricted vocabulary. However, once this is developed it could be applied to
any situation with minimal cost beyond translation of a written script.
11.4 Rich notifications / widgets (recommended)
Our recommendation based on the feasibility study is to produce and deploy a visually rich Push
Notification and App service using the Darwin train data.
Rich notifications use icons or widgets to convey data with short-form text labels – an ideal form of
communication for those for whom English isn’t a first language as is the case for many BSL users.
These new-style push notifications that have exciting functionality compared to those in older
operating system versions. Improvements include viewing photos, videos or gifs, right there, within
the notification with option to click through to more detail if required.
Development is made up of two phases - a web service and a native app. The web service would be
treated as Minimum Viable Product (MVP) linking towards a fully-fledged native app; both utilise
the same back end technology, concepts and hardware reviewed in the feasibility study and
highlighted in this report.
• Web service
The visual push notification service would utilize the native User Interface (UI) for both iOS and
Android as either a notification and/or widget.
14Using the Darwin data collection process as stated earlier, a
web service worker, would be connected to our database.
Passengers in advance of travel would visit the Disruptly©
site and by entering in their travel plans they would agree
to receive visual push notifications from Darwin via our
service worker. The service worker is limited to newer
Android and iOS device but allows the default browser to
send these notifications.
The service worker runs passively in the background,
checking the user’s location, sending it to our servers and
allowing the passenger to receive notifications and alert
them to the latest updates. The user’s device would buzz
and display a small message to alert them to an update,
this can then be tapped to go straight to the Disruptly©
website and gain more details on the disruption. The Google Weather Widget /
notifications are however heavily text-based but can Notification Example
display an image and link to the Disruptly© site which could
provide a visually rich representation of the disruption.
Designing the initial microcopy for the push notification text for the D/deaf will be a key factor. At
this stage we have included some basic visual example designs for iOS located in the Annex for
reference purposes.
• Disruptly© Native App
With a native app installed by the passenger enables utilisation of rich notifications as well as
provide an app for viewing and managing journey and disruption notifications. In this instance the
passenger would install the Disruptly© app and use the app to provide journey details (and allow
push notifications) and instead of using a web service worker we would use the native iOS and
Android Software Development Kits (SDKs) to connect to our database and provide updates to the
app and thus also push rich notifications. Rich push notifications enable communication with the
passenger in a more creative and interactive way by adding images, GIFs, video and audio files to
notification content and including multiple options for how the passenger interacts with the
notification.
The Disruptly© apps UI and User Experience (UX) need
to be designed, but in principle the action taken from
the push notification would provide the user with
more details within the app and the app itself could
provide numerous ways to visualise the journey and
disruptions.
The UI the app requires extensive work to create an
interface worthy of a sophisticated travelling public.
Another advantage of an app is that it can provide
many more metrics. Viable metrics allow service
providers to know how an app is being used and
enhance the experience for the passenger based on Example of rich data visualisation
this data ensuring Disruptly© provides the more timely
and useful data for the D/deaf traveller. iOS and Android
have built-in usage tracking which can be implemented, and more in-depth tools are available from
third-party developers.
11.5 Intellectual property rights
The only intellectual property exists in the potential product name, Disruptly©. We will assert our IP
on the design assets.
11.6 How does the feasibility study address key DfT priorities?
This study concludes that by empowering more of the d/Deaf community to successfully use the
rail network for business and leisure it will boost economic growth and opportunity for the Train
operating companies (TOCs) and the country. Economic growth is directly connected to the
15mobility of the population and so enhancing the experience and thus use of public transport for all
of the population will see increased economic benefits for the UK. Of course, if disruption
information isn’t accessible, TOCs risk losing customers to other more accessible modes of
transport. A holistic service to support reducing the impact of disruption would enhance the brand
of the nation’s railways.
The nature of a visually rich Push Notification and App service would promote inclusive design as
part of the modern rail network and connect directly to the DfT accessibility agenda. The Equality
Act 2010 requires all TOCs and station operators to take reasonable steps to ensure that they do
not discriminate against disabled people. Not completely fulfilling those obligations risks damage
to the brand. Should an incident occur, there is the potential for financial cost arising from
litigation. By ensuring the D/deaf community have a safe and as least disruptive journey as possible
DfT can help to increase and maintain sustainable and environmentally friendly travel across the
UK. The positive benefits in doing so for DfT reach to a wider audience as concerns over inclusion
and environment are becoming driving factors in the population choice of services.
12 Practical applications of the concept to the UK transport system
The Disruptly© concept is innovative in the sense it serves up existing data in a new way for the
benefit of a new audience. This unique application of existing technology creates new value. This
technological innovation is an incremental process improvement packaged as a digital service
potentially disruptive in that it seeks to drive demand from the D/deaf passenger population for
new and complementary services.
12.1 Primary market and customers
The service is aimed at improving the customer experience for D/deaf passengers at railway
stations and on trains. As such, the primary market will be Train Operating Companies (TOCs). The
first target will be LNER as it is a member of the project team. The other TOCs will also be key
targets. Beyond that, other transport modes (e.g. air travel) will be explored for potential.
12.2 Pricing model
A pricing model, involving licencing and support, will be developed at a later stage of the project,
once the development of the generic product is underway and the design and development effort
can be costed more accurately. The service will require a capital fund to build and could then be
charged out to TOCS as a flat annual license fee or as micropayments based on the number of calls
on the data per month, per TOC.
12.3 Size of market
Description Ratio Statistic
UK population (Statistics, 2018) - 66,040,200
Percentage of UK population who use surface rail more than once a
60% 39,624,120
year (Dft, 2017)
Deaf passengers or those with partial hearing loss (transportfocus,
2% 792,482
2018)
‘Deafened’ headphone using passenger journeys based on 17m
25% 9,906,030
headphone users in UK (Statista, 2018)
Total market deaf and deafened passengers - 10,698,512
We believe Deaf users should not have to pay for equal access to their equivalent of audio
announcements. The total market seems large enough to support TOCs paying a monthly license
fee to add-value to their customer base as well as delivering and accessibility benefit.
13 Delivering the product roadmap - next steps for implementation
13.1 Darwin data costs
Darwin XML Push Feeds are free for all users regardless of usage volumes. Darwin SOAP APIs feeds
are free for all users up to up to five million requests per four-week railway period. Corporate or
16private users that exceed this amount will be charged for High Volume Usage. Public sector
organisations including Transport for London, passenger transport executives and local authorities,
would not be subject to usage charges.
Darwin technical support is a free service, provided to users openly but at a loss to NRE. As such,
formal user support for the service is not offered. Unofficial informal technical support can be
found via the open rail data user forum Open Rail Data-Talk.
13.2 Development Costs
Phase 1 (3 months project timeline)
Build and deploy the Push Notification service, connecting to both our database and the data from
Darwin. Design the basic push notifications UI and the Disruptly web interface.
Description Cost GBP
Research 5,000
Wireframing 5,000
Prototype 15,000
Design UI 10,000
Design UX 10,000
Database design 20,000
Test 5,000
Project management 50,000
Deploy 5,000
Cloud Services 6,000
Support 600
Total £131,600
Phase 2 (6 months project timeline)
Design and build the Disruptly Native App (for one platform iOS or Android), design rich
notifications. this development builds on top of the database web service.
Description Cost GBP
Wireframing 5,000
Prototype 30,000
Design UI 30,000
Design UX 30,000
Test 15,000
Project management 80,000
Deploy 5,000
Support 12,000
Cloud Services 72,000
Total £279,000
13.3 Potential accelerators
• Rail Accelerator Network
• Intelligent Mobility accelerator
• Horizon SME Instrument for single companies
• Horizon 2020 collaborative work programme
• Transport Systems Catapult
17The newly announced Rail Accelerator Network, the accelerator and incubator programme for the
UK rail industry, is designed to increase the uptake of innovations in the rail market, giving start-ups
and SME's access to the decision makers and systems owners to create real opportunities for
innovation demonstration.
This programme will focus on start-ups and SMEs wishing to access the rail market, scaling their
innovations and that can deliver disruptive innovations (service, product or technology) that fit the
rail industries challenges. Organisations who are successfully awarded a place on this programme
will be sponsored by a rail organisation with the ability to buy the solution at the end of the
programme.
13.4 Champion database
Louise Mothersole/Horizon 2020 UK National Contact Point for Transport
Simon Yarwood/Knowledge Transfer Manager, ICT
Micky Ball/Head of Customer Service Centre at the (RDG) Rail Delivery Group
Tracy Savill/Head of New Mobility Services
Devante Andrew /Assistant Programme Manager - Wayra UK
Alexander Weedon/Director - SME Strategy at Transport Systems Catapult
13.5 Funding calls
The following funding opportunities have been identified:
Funding body Call Value Dates
GWR Customer and Communities £2.25m Until 2019
Improvement Fund
Horizon 2020 Mobility for Growth Share of 2018-2020
€122m
Horizon 2020 Fast Track to Innovation FTI Share of 23 Oct 2018
€100m
Horizon 2020 Smart, green and integrated transport Share of Various
Call : H2020-MG-2018-2019-2020 €12m
13.6 Equity investment and private funding
These would be considered as part of the incubation and acceleration process.
13.7 Exploitation plan
Key stakeholders include the national rail regulators, rail network providers, train operating
companies, and the recipients of the service – Deaf (and hearing) passengers.
In terms of the competitive landscape – the service is currently unique although the idea could be
applied but frontrunners like National Rail Enquiries.
Signly and the project team would jointly pitch to:
• Target beneficiaries, Deaf passengers, and related organisations (Action on Hearing Loss, RAD,
BDA etc)
• Industry influencers, such as RDG, ORR (comprehensive list to be developed)
• Media list, to include trade/rail/transport media, and Deaf passenger media, the influential
social media channels.
• Rail staff organisations
• Innovation networks, in the rail industry and wider.
For each of these, we will include:
• an assessment of their (potential) role
• a description of the impact of the service
• channels, style and other characteristics
• timescales and lead times (within and post the project timetable)
1813.8 LNER
As the (rail) industry member of the project team, it has been assumed that LNER develop PR and
showcase the idea to assist the wider roll–out to other TOCs and potentially other transport modes.
14 Annexes
14.1 Promotional video
Watch a 90 second video on Disruptly.
14.2 Bibliography
Anon., 2018. Deaf passenger experience [Interview] (15 May 2018).
Focus/Southern, P., 2011. Information: Rail passengers’ needs during unplanned disruption. [Online]
Available at: https://www.transportfocus.org.uk/research-publications/publications/information-
rail-passengers-needs-during-unplanned-disruption/
Loss, A. o. H., n.d. [Online]
Available at: https://www.actiononhearingloss.org.uk/about-us/our-research-and-
evidence/facts-and-figures/
14.3 Focus group
List of persons interviewed at DCAL
We can’t provide the names of people who participated or enough detail for them to be
identifiable. The first group comprised station staff and drivers and that the second group were
Deaf people who were fluent users of BSL.
Name Location
Des Not given
Gemma South Croydon
Joanna North London
Kathryn South East
Lisa Stratford
Philippa Orpington
Rosie West London
Tim Croydon
Warren South London
Wendy Forest Hill
The database has around 900 people signed up who have volunteered to take part in DCAL
research. We have substantial demographic information about each of them (e.g. age, gender,
region, family background, occupation, education, handedness, age of onset of deafness, degree of
deafness, language preferences, etc. and we can search the database along whatever criteria we
specify in order to invite them to participate in a specific research study.
Data
The analysis of the focus groups used qualitative methods to identify deductively themes in
participants’ responses.
Rather than setting up categories in advance (for example – the need for alerts on video screens, or
the need for text alerts) into which we would fit the participants’ answers, we created the
categories after we did the interviews, based on the responses themselves (e.g. if the need for text
alerts was mentioned, we created that category (see the Wikipedia entry for “Thematic Analysis”.
14.4 Sites visited
London King's Cross railway station, Euston Rd, Greater London N1 9AL
DCAL Centre, 49 Gordon Square, London, WC1H 0PD
Winchester Railway station, Station Hill Winchester Hampshire SO23
19You can also read
