Initiatives
Description of a range of engineering initiatives as part of the Panic Button development in order to organise and track progress with important problems and tasks that are larger than specific features, inter-related and have a significant impact on the app and its users.
- 1. Power Button Trigger: dealing with the power button trigger false alert problem
- 2. Haptic Feedback: providing meanigful feedback about the state of the app through vibrations
- 3. New Trigger Research: researching other trigger and related options
- 4. Alert/Alarm Mode Research: researching the possibility to have 2 different modes of alert/alarm.
- 5. Non-Smart Phone Research: researching panic features for non-smart phones.
- A. Testing and Deployment Process: structuring testing and roll out of new features for the Panic Button app
- B. Modular Architecture: architectural changes related to the Guardian Project Panic Architecture and the Open Mentoring approach.
Proposed overall roadmap to implement various aspect of the initiatives focusing on reducing the problems caused by the false alert problem first.
The rationale is that the current version should eliminate a very large proportion of the false alert problem but that we want to make sure that:
- Users have better ways to know whether the alert is triggered or not (through the haptic feedback) so they can deactivate it faster in case of false alert.
- Users can try to change the configuration of the trigger themselves so that they have another option rather than uninstalling
- Users can also deactivate the power button trigger (in case they want the feature deactivated most of the time and want to control when to activate it).
- Users are well aware of the new confirmation based triggering pattern.
- Implement configurable haptic feedback via Advanced Setting to change vibration pattern. (See 2. Haptic Feedback)
- Implement configurable trigger pattern via Advanced Settings. (See 1. D. Trigger Pattern)
- Implement deactivation of power button trigger via Advanced Settings. (See 1. C. Trigger Deactivation)
- Implement one-time notification to prompt users to take the training wizard again for the new confirmation trigger pattern. (Also improve the wizard explanation about the confirmation pattern. Possibly create an online video and improve communication on the trigger change.)
The objective would be to bring the false percentage of false trigger to zero by identifying all possible false trigger situations and testing various event filtering code which might be more adapted to various devices, os versions and configurations.
- Implement Trigger Event Logging and log sharing branch for team, lab and pilot testers.
- Implement Trigger Filtering Debug Settings to 1/ log behavior of filtering code and share 2/ change filtering code actually in use.
- Implement Interactive Feedback Debug Settings. (See 1. A. False Trigger Data > Interactive Feedback and 1. C. Trigger Deactivation)
Depending on the results of this we could either :
- In case of success: Go out of Beta.
- In case of continuing false alerts:
- Continue researching root causes by developing a testbench (See 1. A. False Trigger Data > Hardware Test Bench)
- Discontinue power button trigger and develop new trigger approaches to replace it.
- New Trigger Research
- Alert/Alarm 2-mode Approaches Research
- Modular Architecture
- Non-Smart Phone Research
-
Problem : There are many different devices, different operating system versions, different configurations and apps and different user bahvior patterns that will potentially generate different false triggers. We currently don't have enough in depth data about what might trigger false alerts.
-
Solutions :
- Passive Feedback : Collect more systematically information about what caused a false alert trigger. Help identify device/config/os/event specific problems.
- Interactive Feedback: Create a debug mode which can allow users to report back whether triggers where false or not. (see C. Trigger Deactivation)
- Passive Trigger Code Data Collection: Create a debug mode to collect data about the reaction of various trigger code approaches (while only one is active).
- Passive Filtering Code Data Collection: Create a debug mode to collect data about the reaction of various filtering code approaches (while only one is active).
- Hardware Test Bench: Create a test-bench to test power button behavior and other system events in the lab with actual devices.
+----------------------+-----------------------+----------------------------------------+------------+-------+--------------+-------------+
| | | | | | | |
| Approach\\Phase | Description | Comments | UX Lab | Pilot | Private Beta | Release |
| | | | | | | |
+======================+=======================+========================================+============+=======+==============+=============+
| Passive Feedback | Debug option to | This should aim to minimize collected | lab branch | YES | YES | Deactivated |
| | collect data about | data by: | | | | by default |
| | trigger and send logs | - collecting only after 2 triggers | | | | |
| | | - deleting logged events daily | | | | |
| | | - not being active for released | | | | |
| | | version. | | | | |
+----------------------+-----------------------+----------------------------------------+------------+-------+--------------+-------------+
| Interactive Feedback | Debug mode to | This should only be deployed | lab branch | YES | NO | NO |
| | confirm or qualify | with users who have the time | | | | |
| | trigger | and awareness to activate/deactivate | | | | |
| | | the trigger. See C. Trigger | | | | |
| | | Deactivation below. | | | | |
+----------------------+-----------------------+----------------------------------------+------------+-------+--------------+-------------+
| Passive Trigger | Debug option to | | YES | YES | YES | NO |
| Code Data | collect data | | | | | |
| Collection | about triggering code | | | | | |
+----------------------+-----------------------+----------------------------------------+------------+-------+--------------+-------------+
| Passive Filtering | Debug option to | | YES | YES | YES | NO |
| Code Data | collect data | | | | | |
| Collection | about filtering code | | | | | |
+----------------------+-----------------------+----------------------------------------+------------+-------+--------------+-------------+
| Hardware Test Bench | Create an approach | This might involve a mechanical | N/A | N/A | N/A | N/A |
| | to test power button | test suite (power button press, | | | | |
| | trigger in the lab | proximity, charge...) and other | | | | |
| | | system event generation (call, sms...) | | | | |
+----------------------+-----------------------+----------------------------------------+------------+-------+--------------+-------------+
Develop different code to filter out non-power button events.
- See https://github.com/PanicInitiative/PanicButton/issues/135
- See https://github.com/PanicInitiative/PanicButton/issues/38
+-----------------+-----------------------+--------+-------+--------------+---------+
| | | | | | |
| Approach\\Phase | Description | UX Lab | Pilot | Private Beta | Release |
| | | | | | |
+=================+=======================+========+=======+==============+=========+
| Filtering Code | Debug option to | YES | YES | YES | MAYBE |
| Selection | change filtering code | | | | |
+-----------------+-----------------------+--------+-------+--------------+---------+
For specific users (I'm thinking of staff of international organisations specifically) there is a very clear delineation between being in a safe environment and being in a hostile environment, generally associated with a number of preparation steps, possibly dedicated equipement and organisational interactions (brief by security officer, setup of communication channels, check-ins,...).
For this type of users it might be natural to deactivate the power button trigger "at home", and activate it when "in the field". Also as mentioned above when "at home" it might be possible to provide valuable feedback on the trigger behavior (by activating debug options) without creating any additional risk.
Include in the Advanced Settings as "Deactivate Power Button Trigger". Maybe as a Radio Select with:
- (*) Activated (default)
- ( ) Deactivated
- ( ) Debug Mode
When the Deactivated or Debug Mode is deactivated add a Notification such as "The Panic Button Power Button Trigger is deactivated." as an icon and on the lock screen.
-
Problem: changing the pattern of presses on the power button has an impact on:
- the false alert problem as it might diminish or increase the sensitivity of the alert to non intentional power presses or unwanted
- usability, as different patterns might not be as simple to learn or to use in a stressful or life threatening situation.
-
Solutions:
- Allow the user to change the trigger code.
-
Initial Presses (Number of presses needed to trigger the alarm. Increasing the number of initial presses can help reduce false alarms. Also note that some devices might not detect the first press.)
4 presses / (default) 5 presses / 6 presses / 7 presses
-
Initial Time (Time to complete the number of initial presses. Decreasing this number might create problems with detecting multiple presses with certain devices.)
4 sec / 5 sec / (default) 6 sec / 7 sec / 8 sec
-
Confirmation Wait Time (Time to wait until the confirmation press. This wait will help avoid false alarms. You can try to augment it if you experience false alarms.)
1 sec / (default) 2 sec / 3 sec / 4 sec
[ Cancel ] [ Test and Save ] [ Save without Testing ] (-> Warning "You have changed the trigger pattern and have chosen not to test your new settings. Are you sure you want to continue? [ Go back and Test ] [ Continue without Testing ]
After changing the Haptic Feedback option the user should be offered to do the trigger exercise again.
+-----------------+---------------------+--------+-------+--------------+---------+
| | | | | | |
| Approach\\Phase | Description | UX Lab | Pilot | Private Beta | Release |
| | | | | | |
+=================+=====================+========+=======+==============+=========+
| Trigger Code | Debug option to | YES | YES | YES | MAYBE |
| Selection | change trigger code | | | | |
+-----------------+---------------------+--------+-------+--------------+---------+
- Testing power button deactivation UX.
- Data collection about problems.
+-------------------+------------------------------+--------------------+---------------------------+
| Name | Trigger | Status | Comment |
+===================+==============================+====================+===========================+
| v1.3.0 | 5 presses < 10 sec | | |
+-------------------+------------------------------+--------------------+---------------------------+
| v1.4.0 | 4 presses < 8 sec | Currently Deployed | Still some false triggers |
| | + 2 sec guard time | | |
| | + 1 conf < 3 sec | | |
+-------------------+------------------------------+--------------------+---------------------------+
| Extra Click | 5 presses < 6 sec | | |
| | + 2 sec guard time | | |
| | + 1 conf < 3 sec | | |
+-------------------+------------------------------+--------------------+---------------------------+
| Extra Guard | 4 presses < 5 sec | | |
| | + 5 sec guard time | | |
| | + 1 conf < 3 sec | | |
+-------------------+------------------------------+--------------------+---------------------------+
| Countdown | 4 presses < 6 sec | | |
| | + 4 sec cancelling countdown | | |
| | + 1 conf < 3 sec | | |
+-------------------+------------------------------+--------------------+---------------------------+
| Guarded Countdown | 4 presses < 6 sec | | |
| | + 2 sec guard | | |
| | + 3 sec cancelling countdown | | |
| | + 1 conf < 3 sec | | |
+-------------------+------------------------------+--------------------+---------------------------+
| S.O.S. | 4 presses < 6 sec | | |
| | + 2 sec guard | | |
| | + 4 sec cancelling countdown | | |
| | + 4 conf < 6 secs | | |
+-------------------+------------------------------+--------------------+---------------------------+
See Trigger Pattern test spreadsheet : https://docs.google.com/spreadsheets/d/10manJsPWWh1D3NmoIcxXtILV8Y0cBJ-qRBdoTTnJsk0/edit#gid=0&vpid=E2
See Trigger Pattern diagram:
- Experimenting with new feedback mechanisms.
-
Confirmation Wait Vibration (Vibration pattern during the wait time until the confirmation press). (X) (default) Vibrate Continuously ( ) Vibrate Every Second
-
Alarm Sending Confirmation (Vibration pattern to confirm the alarm has been activated. Choosing a recognisable pattern can help you be reassured that the alert has been sent, or identify better potential false alarms). (X) (default) Long Vibration ( ) Repeated Short Vibrations ( ) Three short - pause - Three short ( ) SOS: Three short - Three long - Three short ( ) None
[ Cancel ] [ Test and Save ] [ Save without Testing ] (-> Warning "You have changed the trigger pattern and have chosen not to test your new settings. Are you sure you want to continue? [ Go back and Test ] [ Continue without Testing ]
- Headphone pin removal
- Fall detection
- Android Launcher Widgets
Research and develop more sophisticated approaches to alert/alarm such as:
-
Activate a heightened alert mode (different from alarm) by using another dedicated pattern on the power button or the disguise (for instance 10 presses - which would look like dialing a phone). This heightened alert mode would for instance:
- Send another predefined message such as "I don't feel very safe so I've just activated the alert mode, no need to worry yet!", maybe to only one of the 3 contacts.
- Make the power button trigger more sensitive or activate the fall detection trigger.
-
Activate a "deadman switch" mode (maybe also with a dedicated pattern) which would
- Send a predefined message.
- Send a haptic feedback prompt every 30 seconds waiting for a power button response within 5 seconds.
Research and develop approaches to managing emergency situations with non-smart phones for instance with:
- SMS, USSD (a la Vumi), or code for feature phones
- self-hosted or colocated approaches (Frontline Panic) to better manage risk situations in environments with only GSM connectivity, or specific organisational or team configurations.
+--------------------+----------------+--------------+------------------+----------------------+---------------------+---------------+
| | | | | | | |
| Description\\Phase | Dev | Team | UX Lab | Pilot | Private Beta | Release |
| | | | | | | |
+====================+================+==============+==================+======================+=====================+===============+
| **Purpose** | Experiment | Review | Test | Engage | Scale | Release |
+--------------------+----------------+--------------+------------------+----------------------+---------------------+---------------+
| **Who** | Dev team | Whole team | Lab Participants | Partners / Champions | Beta testers | Public |
+--------------------+----------------+--------------+------------------+----------------------+---------------------+---------------+
| **Distribution** | code | apk | apk | - App Store | - App Store | - App Store |
| | | | | - F-Droid Pilot Repo | - F-Droid Beta Repo | - F-Droid |
+--------------------+----------------+--------------+------------------+----------------------+---------------------+---------------+
| **DevOps** | feature branch | named branch | named branch | alpha branch | beta branch | Public (Beta) |
+--------------------+----------------+--------------+------------------+----------------------+---------------------+---------------+
-
Panic Architecture:
- Allow Panic Button to be a Trigger. See https://dev.guardianproject.info/news/210
- Separate the Power Button trigger from the Panic Button app.
-
Open Mentoring:
- Could aim to replace the Help section.
- Maybe in the future could also aim to replace the Wizard.