053ed96974
We recently introduced a form control that lets user choose when a broadcast ends. Based on the most recent research participant, we think: - there is a specific misunderstanding of what this control does - there is a general low level of understanding of what a ‘broadcast’ means People will try to understand what a ‘broadcast’ is by using mental models they have for other kinds of messaging, for example text messages. Other kinds of messaging are one-to-one, i.e. they go from a sender to a recipient. They are not ongoing in any way. Emails and texts are sent at a time (and for all practicable purposes are received at that same time). So, when we present the user with a form that controls time, they might well assume it controls the time when the message will be sent. This is a feature we offer for sending messages using a spreadsheet, and that’s where we’ve borrowed this pattern from. We reinforce this assumption with the labelling of the form control. By front-loading it with the word ‘When’ we are playing to the users confirmation bias, i.e. they are interpreting the meaning of the control in a way that confirms their prior beliefs about how messaging works. So this commit does two things: - re-labels the form to front-load the word ‘End’ not ‘When’ - adds text to the page explaining when the broadcast will start, so there’s a chance of overriding that confirmation bias If we can get users to go through this before sending a broadcast for real, it could help them learn what a broadcast is, and how it differs from sending text messages.
notifications-admin
GOV.UK Notify admin application - https://www.notifications.service.gov.uk/
Features of this application
- Register and manage users
- Create and manage services
- Send batch emails and SMS by uploading a CSV
- Show history of notifications
First-time setup
1. Install Homebrew
Install Homebrew, a package manager for OSX:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
2. Make sure you're using correct language versions
Languages needed
Need to install node? Run:
brew install node
2.1. pyenv For Python version management
pyenv is a program to manage and swap between different versions of Python. To install:
brew install pyenv
And then follow the further installation instructions in https://github.com/pyenv/pyenv#installation to configure it.
2.2. n For Node version management
NPM is Node's package management tool. n is a tool for managing
different versions of Node. The following installs n and uses the long term support (LTS)
version of Node.
npm install -g n
n lts
3. Install NPM dependencies
npm install
npm rebuild node-sass
4. Install and use virtualenvwrapper (optional)
We suggest using a virtualenv to separate the python dependencies for this project from python dependencies for other projects.
Install virtualenvwrapper:
pip install virtualenvwrapper
Then follow the virtualenvwrapper installation instructions docs to configure virtualenvwrapper for your terminal.
Set up your virtualenv:
mkvirtualenv notifications-admin
If you need to specify a certain version of python you can do this using -p, for example:
mkvirtualenv -p ~/.pyenv/versions/3.6.3/bin/python notifications-admin
Activate your virtualenv:
workon notifications-admin
5. Install Python dependencies
Install dependencies and build the frontend assets:
./scripts/bootstrap.sh
Note: You may need versions of both Python 3 and Python 2 accessible to build the python dependencies. pyenv is great for that, and making both Python versions accessible can be done like so:
pyenv global 3.6.3 2.7.15
6. Create a local environment.sh file
In the root directory of the application, run:
echo "
export NOTIFY_ENVIRONMENT='development'
export FLASK_APP=application.py
export FLASK_DEBUG=1
export WERKZEUG_DEBUG_PIN=off
"> environment.sh
7. AWS credentials
Your aws credentials should be stored in a folder located at ~/.aws. Follow Amazon's instructions for storing them correctly
8. Running the application
In the root directory of the application, run:
./scripts/run_app.sh
Then visit localhost:6012
Updating application dependencies
requirements.txt file is generated from the requirements-app.txt in order to pin
versions of all nested dependencies. If requirements-app.txt has been changed (or
we want to update the unpinned nested dependencies) requirements.txt should be
regenerated with
make freeze-requirements
requirements.txt should be committed alongside requirements-app.txt changes.
Automatically rebuild the frontend assets
If you want the front end assets to re-compile on changes, leave this running in a separate terminal from the app
npm run watch
Working with static assets
When running locally static assets are served by Flask at http://localhost:6012/static/…
When running on preview, staging and production there’s a bit more to it:
