Eloy is a smartphone app that gives drivers the tools to improve their driving experience. We want to help drivers understand how and when they use their car and improve the activities around this.
Apps can help make managing road trips easier.
To assist this and building our voice controlled decision engine (the “Eloy Engine”) we were cognizant that we needed drivers and their cars to have identifiable states – where we could clearly determine what actions and activities were happening. In mathematics, this means these states are exhaustive and mutually exclusive.
A decision tree can be used to show how Eloy is thinking about the car and drivers. The first step is about the car in motion:
A) The car is being driven
B) The car is stationary
From these 2 states, a number of likely driver and passenger functions will be more important. Whilst a car is being driven, maps and navigation may be required and then phone should not be touched: voice activation is then very important. When a car is stationary, we need to understand if it is parked or stopped – which brings us to the second branch of the decision tree.
A stationary car has 2 possibilities:
A) Parked – the driver and passengers leave the car
B) Stopped – the driver (and/or passengers) remain in the car
Knowing when a car is parked is important as we can then activate parked car modes – tracking how long a car is in a car park for and reminders if the driver needed to buy a parking ticket. Eventual connectivity into car park payments will happen, even if most currently do not facilitate this. Stopped cars have their own potential list of options: is the car stopped due to picking up or dropping of a passenger or a delivery? Then we want to understand what passengers are being picked up – is a childminder picking up a child and do the parents of that child want to receive automated alerts saying their child has been collected or dropped off.
A car being driven has its own set of further options. We decided to split the events based upon:
A) The destination is known
B) The destination is unknown.
Known destinations are classified as the driver knows the route and doesn’t need navigation to get there. We have further branches that include regular (school, work, close family & friends) and irregular (sport venues, distant family) that introduces another set of Eloy Engine decisions for us.
Unknown destinations are also important. These can have high risk as navigation may be required or the destination is changing (think or picking up a passenger who is not in a fixed location). Drivers may need extra detail in navigation as map information is weaker – and facilitating how this additional information can be transmitted to the driver is important.
A decision tree can be used to show how Eloy is thinking about the car and drivers. The first step is about the car in motion:
A) The car is being driven
B) The car is stationary
From these 2 states, a number of likely driver and passenger functions will be more important. Whilst a car is being driven, maps and navigation may be required and then phone should not be touched: voice activation is then very important. When a car is stationary, we need to understand if it is parked or stopped – which brings us to the second branch of the decision tree.
A stationary car has 2 possibilities:
A) Parked – the driver and passengers leave the car
B) Stopped – the driver (and/or passengers) remain in the car
Knowing when a car is parked is important as we can then activate parked car modes – tracking how long a car is in a car park for and reminders if the driver needed to buy a parking ticket. Eventual connectivity into car park payments will happen, even if most currently do not facilitate this. Stopped cars have their own potential list of options: is the car stopped due to picking up or dropping of a passenger or a delivery? Then we want to understand what passengers are being picked up – is a childminder picking up a child and do the parents of that child want to receive automated alerts saying their child has been collected or dropped off.
A car being driven has its own set of further options. We decided to split the events based upon:
A) The destination is known
B) The destination is unknown.
Known destinations are classified as the driver knows the route and doesn’t need navigation to get there. We have further branches that include regular (school, work, close family & friends) and irregular (sport venues, distant family) that introduces another set of Eloy Engine decisions for us.
Unknown destinations are also important. These can have high risk as navigation may be required or the destination is changing (think or picking up a passenger who is not in a fixed location). Drivers may need extra detail in navigation as map information is weaker – and facilitating how this additional information can be transmitted to the driver is important.
Decision tree to show the different states of the car
From here we start to see some of the initial car management situation filters. With a car parked at home, we can disable certain function calls with voice. So a car parked at home doesn’t need voice functions regarding unknown destinations. This increases the voice accuracy and also coaches the user to know what functions they should use and when. Understanding when a car is coming into s state of transition also allows us to surface other functionality – such as finding parking spaces.
Multi-user
We have also made Eloy multi-user. By this, we allow people to share cars and the car settings. Obvious things this allows are for passengers to mark pick-up locations with specific location information that the driver can receive fully handsfree. Editing destinations and helping less-technology savvy set up their Eloy is also useful: wanting to set up navigation for an older driver is often difficult but within Eloy this is simple and certain to get a navigation to the right place – with inbuilt tracking available to those following a driver and car.
Accident Managemen
Unfortunately accidents do happen. We haven’t yet shared how we are assigning these in our above decision tree as this is a specific are rare use case. We actually placed it under “stopped” as a further decision branch so that GPS information can still be recorded. We have an entire section on accident management within our smart insurance blog with much more details why and how this works.
Better Driving Experience
Much of what we have described above is how we have built our backbone and database that the front-end user functions will operate with. Driving apps need to be very different to most apps in that they have to have a high level of background functionality and voice-first controls as app users will usually be driving when they need to use the app. Replacing animated buttons with easy navigation loops with our new “what situation am I in” decision tree makes voice communication between drivers and Eloy much more robust.
We have a set of use case videos that you can also find on the website and please download the app and drive better.
Multi-user
We have also made Eloy multi-user. By this, we allow people to share cars and the car settings. Obvious things this allows are for passengers to mark pick-up locations with specific location information that the driver can receive fully handsfree. Editing destinations and helping less-technology savvy set up their Eloy is also useful: wanting to set up navigation for an older driver is often difficult but within Eloy this is simple and certain to get a navigation to the right place – with inbuilt tracking available to those following a driver and car.
Accident Managemen
Unfortunately accidents do happen. We haven’t yet shared how we are assigning these in our above decision tree as this is a specific are rare use case. We actually placed it under “stopped” as a further decision branch so that GPS information can still be recorded. We have an entire section on accident management within our smart insurance blog with much more details why and how this works.
Better Driving Experience
Much of what we have described above is how we have built our backbone and database that the front-end user functions will operate with. Driving apps need to be very different to most apps in that they have to have a high level of background functionality and voice-first controls as app users will usually be driving when they need to use the app. Replacing animated buttons with easy navigation loops with our new “what situation am I in” decision tree makes voice communication between drivers and Eloy much more robust.
We have a set of use case videos that you can also find on the website and please download the app and drive better.
