How to prevent users using your app while driving?

Question

I'm working on an app project for professional drivers.

Besides all the features we need to offer them, we need to prevent as much as we can our users to use the app while driving.

Can you think of any tricks to reach this goal?

For instance, I was thinking it could be blocked when the smartphone is not still (ie when you detect it's moving)? But if the sensor is not precise enough, it could make it impossible for the user to use the app while walking.

Maybe you could have to wire it to the car to use and you be blocked if the car is moving ?

Sounds silly, but it seems a pretty difficult thing to do...

EDIT : For this particular audience, we know the driver is alone (or at least, is not authorize to have any passenger)

It'll probably end up with a warning message, like in Waze if I remember well. But I was wondering if there were any other technology or idea around here.

Answer 1

Don't overdo this. How can you distinguish the driver looking at the app vs. the front passenger looking at it? Location / movement will be identical.

Navigation systems warn upon start up, "Don't do this when driving." That should be enough.

I think some thinking is needed in this world. As it used to be back in the times of caves and leopards.

Answer 2

Having worked on an iOS app like this previously, I'll just relay my experiences and some conclusions. Please note that all of these experiences are developing an iOS app which at the time more heavily sandboxed apps than Android apps. Know the platform you're developing for.

• You can use GPS to determine if a person is moving, and that's about it. Using a person's current GPS location, you can compare it with the previous coordinate and determine the speed they traveled that distance within the time between the two points. The problem with GPS is that in order to accurately determine a person's speed, you need to be pinging for data points pretty often. Yet the more you use GPS, the more this burns through a person's battery. Also, while I'm not sure about iOS 7, I know within iOS 6, a developer couldn't be pinging for GPS coordinate more than once every minute or so (I believe) if the app was in the background. Having that much time between GPS pings won't give you very much accuracy in determining if the person is moving.
• Remember to consider the app experience outside of driving. Be careful about asking questions every time someone opens the app to see if their driving. This could get frustrating and could develop into another problem...
• Be careful to not inadvertently encourage bad habits with your app. That is, if you ask a user if they're driving, they respond honestly, and you shut them down but they really wanted to use the app. So the next time they might just say lie and say "No" in order to get to where your going. Now your data is dirty and unreliable. Every time thereafter they may respond with "No." Now you have a worse problem than before — people are using the app while driving and lying about it. People will figure out a way to get around rules.

It's a great goal that you're shooting for, but think bigger. You don't want your drivers to not use just your app, but you want them to not use any app, text message, or even phone call. Increasing data shows that distracted driving impairs a driver's ability. In fact the response time of someone responding to a text message is worse than a drunk driver. Texting while driving kills at least 11 teenagers a day, and the National Safety Council estimates at least 28% of all traffic crashes every year involve a cell phone. Most responses to this problem though are negative (disable the phone or app). Have you considered a positive response? Maybe some way you could reward drivers for not using their phone?

Answer 3

You say that your target audience is professional drivers. A professional should know better than to operate the phone while driving. (And if they do violate that bit of common sense, they'd have the skill to still avoid a crash.)

Instruct the user on startup to not operate while driving, and then trust the human element to not be stupid. The universe will always build a better idiot, of course, but the matter is out of your hands regardless.

Answer 4

Calculating the user's speed based on GPS and disabling the app when travelling above a certain speed sounds like the most obvious solution.

The OneProtect app, for example:

OneProtect technology blocks drivers from using their phones while in motion. Once your phone's GPS indicates your car is moving above a speed of your choosing — the default is 15 miles per hour — it will lock up

OneProtect also incorporates an "Attention Verification Test" which allows a passenger to bypass the block and continue using the app.

...which asks you to precisely tap on letters that appear on your screen in a short amount of time. The AVT is tested be essentially impossible for drivers, but doable for passengers.

Answer 5

Apple was awarded a patent earlier this year that disables certain functions on a mobile device based on the location of the driver within the car. An AppleInsider article on the subject can be found here: http://appleinsider.com/articles/14/04/22/apple-tech-takes-on-distracted-driving-blocks-users-from-texting-while-behind-the-wheel

The summary of the patent, from the article, follows:

The U.S. Patent and Trademark Office issued Apple U.S. Patent No. 8,706,143 for "Driver handheld computing device lock-out," a system that intelligently determines whether a device user is driving and shuts off distracting phone functions accordingly.

The patent is an interesting read. It talks about two methods to determine if the individual using the phone is the driver, or a passenger.

One of the methods discussed requires modifications to the car, using RFID to determine where the user is in relation to other elements within the vehicle (e.g., the wheel or ignition switch).

In your question you make some inference that you might have limited modification ability over the vehicle (you mention wiring the car). If this is the case, one such related solution might be a dongle on the phone (required to be present by the app) and receiver in the cigarette lighter (or whatever they call it these days, since they don't include the lighters anymore). Based on the proximity to that, you could figure out where they are in the car. Hey... I didn't say it was an easy solution!

The other method discussed in the patent related to a "scenery analyzer", and is a little more abstract in its definition.

One discussion uses the camera to determine when a device holder is in a "safe" or "unsafe" operating area. An example of this is given by the above linked article:

For example, the analyzer algorithm may find that a user is in the driver's seat by analyzing a photo or video that shows one face and a steering wheel.

Ultimately, the answer falls to what others have said on how much effort you want to (or can) put into the effort and how much we just have to rely on drivers being smart about what they're doing. To find the "unsafe operating area" would be very difficult and fraught with potential error and circumvention.

Answer 6

I think the motion sensor showing a warning message should be good enough, like in Waze.

I don't think the app should be "responsible" in a way for not letting the driver use the app while it's moving because we can simply never tell what the scenario would be and the possible exceptions... Right?

Answer 7

This would only work with vehicles with bluetooth technology, but you could tie it to paired bluetooth devices. Presumably, since these are professional drivers, they're using company phones. Require that bluetooth devices be configured as "is car" or "is not car" and use an admin password that only the supervisor would know so that the driver could not change the setting.

It's not perfect, but it's another approach.

Answer 8

In my opinion, these make the app less safe, because instead of taking the message to heart, drivers will push the buttons to get around it, which takes more time and hence moves their attention away from the road even longer.

I would rather focus on making the app usable in as short of bursts as possible, so as to minimize the amount of time the driver spends looking away from the road. Any action should require a minimal number of button presses, and all buttons should be large enough that they can be hit inaccurately. As an added bonus, this will also make the app more useful in non-driving contexts as well.

Answer 9

What service does the app offer? And how can you make that service simply be undesirable when the user is operating a moving vehicle?

Anything you do with GPS or similar motion detection would fail rather quickly - sure, that user is not supposed to have a passenger, but what about when they are the passenger? Is your program of zero value when the user is in another vehicle, like a taxi? Could the "passenger" be another company driver?

The pass codes, quick-enter letters etc. mentioned elsewhere make your app more difficult to use in general, and speaking as a user you would be on a one-way trip to the delete function the third time it came up. Irritating your users never helps. If it's a company-issued phone it might have an unfortunate "accident".

Let me make a couple of guesses - if it's a driver's logbook, make it work automatically based on scheduled shift times and motion. If it receives messages, hold the messages until the phone stops moving for 10 seconds (red light).

Trains used to have a dead-man's switch that had to be held down. This was bothersome so drivers just put a brick in their lunchbox. Or a rope depending on the mechanics. Today the system looks at every control in the train's cab and expects something to be operated on a regular basis. As the driver will operate something on a regular basis anyway the drivers don't bypass it anymore.

Answer 10

Step 1) You are going to need to determine how much control you can have over the phone itself.

Step 2) Clarify reasonable assumptions. Can you assume you know when the person is actually supposed to be driving? At the time, before hand, or only after the fact? This ties in to...

Step 3) Can the user of the app be individually identified - is it registered to a known person's identity/phone?

Depending on these answers, you have a variety of tools from the phone at your disposal - or do you?

• Clock
• GPS
• internet connection
• truck/car mounted equipment that can be communicated with

The best solution for a situation where you have a known driver, a set schedule, and a phone where you have access to time, GPS, and reasonable internet, would use a combination.

You might first get a driver schedule for the day, and use it to determine when a driver should be working. You can then use the GPS (or vehicle equipment) to determine movement beyond human walking (anything over 10-20mph would be pretty obviously "not walking"), and if this is within a time period the person should not be driving you either refuse use of the app, and preferably report it to the company for human inspection with applicable information.

If you have vehicle equipment, when the vehicle is not parked the phone/app cannot be used. Even easier!

Each individual thing has human failings or is easy to beat - a person can just say they aren't working, falsify or not enter a work schedule, turn GPS off to hide their movement, not install this app on their own phone or use a second one, etc. But if it is combined with a company system that can combine documentation, and the company takes this as seriously as they should, then you have a hybrid solution that combines all available knowledge.

"You were tooling around with your phone while you were scheduled to be driving, and were in fact actually driving. If this happens again you will no longer be employed with us."

If this is just a casual or non-mandatory app, then obviously many of these solutions won't suit your use case at all - but this is precisely why the use case must be clearly defined so you know what tools you have available to solve your problem.

Answer 11

A somewhat over engineered solution, but mentioned for completeness:

You could use the forward facing camera and image processing to detect how long the user is looking at the screen compared to looking elsewhere (i.e. the road). I think that the pattern of attention for a driver using the app would be significantly different to a front seat passenger using the app.

Answer 12

The Waze solution seems to be a good one, in that normal menu/button related actions are allowed but when a keyboard-related task is required when over a certain speed, a warning dialog saying something like "not available while driving" is displayed. The clever bit is that it has two buttons, the 'ok' one but the other is a "Passenger" one.

Done that way, it makes it's point without getting in the way when being used when moving when the user's not the driver...

Answer 13

Whatever you do, don't make it hard to use the app while driving. Making it impossible is fine, making it hard isn't. The reason: There will always be someone who really wants to use your app while driving. And we all know that's stupid because it removes concentration from driving. But if you make the app hard to use while driving, these people will lose even more concentration from driving, making it more dangerous.

Answer 14

Well besides Apple and their patent there exists a system called Mirror Link This will handle your issue actually. The phone is connected to the car and certains functions just aren't allowed. You can find mor information on the website. It might not help you for your current project but maybe for the next one.

Answer 15

Nobody yet has mentioned the possibility of using sound. I can think of a few ideas:

1. Sample a few seconds of sound, then do some signal processing, listening for those characteristic frequencies that occur inside a car (the drone of the engine, tyre hum etc.). You don't mention your budget and you'd probably need a fair bit of research and testing to get this to work.
2. Alternatively, make the speaker beep and listen for the echo. That will give you the distance to the nearest reflective wall. If it's less than a metre or so, he's either in a car or in a very small room.

Answer 16

Can you combine a GPS reading to detect motion, with a Bluetooth connection to detect if a car is present? If the GPS says you're moving, and the car device is always in the vicinity, would that satisfy the criteria? Can your platform use these two features?

I agree with the other answers posted here, but I took it you were curious about the engineering aspects, rather than the question if it was a good idea in the first place. Assuming your target is "professional" drivers this could be a good safety measure. Some cars won't let you play movies in the front seat if the car is moving, so it doesn't seem like too far-fetched a requirement.

Answer 17

It's really difficult to prevent users using their phone and or apps while driving and there is no 100% way to stop them from doing so.

However, there are many roadblocks we can implement to attempt to stop them or at least discourage them from using the apps while driving.

The first thing you could implement is a pass code to access the app, something along the lines of a 4 digit code that they would have to first enter before opening the app.
Another option you could take that is more direct is a prompt when the app opens that asks the user if they are currently driving with a yes or no button and upon pressing yes would automatically close the app.

You could also simply display to the user that the app is not to be used while driving every time it opens with an ok button that would be pressed to move onto the app.
It is not a good idea to make the app unusable when the phone is in motion though, as the passenger could be using the app or they could simply be in a train or walking. Just some suggestions, hope this helps.

Answer 18

I'd just go with a warning message that pops up once. If you have it popup every time it'll just annoy user.

Besides that, you could opt for a non-obtrusive banner at the top/bottom of the screen that give you the same warning when it detects you're on the move.

A one time warning message by itself would probably not stop me but when it's always on the screen (not getting in my way), it's a constant reminder of what I'm doing isn't safe.

I definitely wouldn't lock the app completely when a person is on the move as this will probably give you an opposite result. The person might be fiddling with the app while driving just to get it working again.

Answer 19

You don't. It's not your job, even if it is a driving app. How do you stop knife-users from killing people? You don't; you trust them.

Answer 20

Android OS has a way of indicating if the device is docked in a car (it has to be a specific dock, though).

You can consider that a device docked this way is in a position where the driver can always see it (used as a GPS or a radio), and therefore should not allow the use of the app.

But then again, the car could be stopped.

Among the more complex methods, detecting if the device is paired with the car audio system (via Bluetooth, likely) and reading the speed on the GPS can work too (although in the car and unless placed at the right position the GPS is not likely to be very accurate).

Answer 21

I wouldn't change the App experience at all for when someone is driving or not, teh experience should be the same, but I might add a warning message to the App header when motion over x speed is detected. I would then warn the user that App usage over x speed is logged and reported. This log could be accessible to a manager or employing company. This is very much what happens when tracked vehicles go off course or stop too long. Simple people management. Then it's a management and trainign issue.

Answer 22

enable both thumb fingure presence on the screen. Atleast somebody dare to leave both hands from the stearing. or monitor the eye contact of the user on screen if the user have front facing camera in his device.

Answer 23

If the phone has internet connection (even better if your app requires internet connection) then you can use a combination of GPS and OpenStreetMap to determine if a user is on a road, and how fast they are traveling.

If an internet connection will not be available you could require that the app be "initialized" at HQ where there is WiFi, and download the appropriate road data. If the user travels outside of the available road data, and is in offline mode, disable the app - they will be using it against company policy.

With the integration of OpenStreetMap you may even drop the speed calculation; Being on the road pretty much qualifies as driving according to your rules. As you said, there is a policy against passengers. However the speed calc might be useful if you wanted to briefly enable the app while the driver was stopped, at a red light for instance, or a flat tire.

Answer 24

Actually giving an answer... In android when you request a users location you will also get their speed.

The best answer here gives a class that gets location updates. https://stackoverflow.com/questions/3145089/what-is-the-simplest-and-most-robust-way-to-get-the-users-current-location-in-a

http://developer.android.com/reference/android/location/Location.html#getSpeed() And use location.getSpeed() to get the speed. You can disable the app if the user is going a certain speed. The obvious disadvantage of this is being a passenger in a car.

Answer 25

This is how Waze does it. Surprised no one has brought it up as it's a good reference.

Using mobile phones while driving might be a legal offence in certain countries, therefore it's in your best interest to have a clear UI and stay clear from any legal issues.

And Waze does it pretty good. You are either a "passenger" or a "driver". If you are driver then you need to be in a stationary mode (GPS detection) to be able to type.

Sure, drivers might chose the "Passenger" button and still try to type. But then again, technically in legal terms, Waze is not responsible if the user has an accident while doing that.

Answer 26

I like the idea of GPS, but I would use the accelerometer.

You have to block when you find acceleration over a threshold for a certain amount of time (if calibrated, you can even integrate acceleration and place a lock when a speed 20/25km/h is found).

The accelerometer will use a lot less power, and cannot be easily disabled as Location Services. It is especially true if your app does not use GPS by default.

The drawback is sometimes the app will be blocked if the user shake/drop its phone, or the user is a passenger. However, I think it a minor problem. Just give a way to user to unblock following the idea of precise combination and small time.