fbd2102832
We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765
notifications-admin
GOV.UK Notify admin application.
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
Brew is a package manager for OSX. The following command installs brew:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Languages needed
brew install node
NPM is Node's package management tool. n is a tool for managing
different versions of Node. The following installs n and uses the latest
version of Node.
npm install -g n
n latest
npm rebuild node-sass
The app runs within a virtual environment. We use mkvirtualenv for easier working with venvs
pip install virtualenvwrapper
mkvirtualenv -p /usr/local/bin/python3 notifications-admin
Install dependencies and build the frontend assets:
workon notifications-admin
./scripts/bootstrap.sh
Rebuilding 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
Create a local environment.sh file containing the following:
echo "
export NOTIFY_ENVIRONMENT='development'
export FLASK_APP=application.py
export FLASK_DEBUG=1
export WERKZEUG_DEBUG_PIN=off
"> environment.sh
AWS credentials
Your aws credentials should be stored in a folder located at ~/.aws. Follow Amazon's instructions for storing them correctly
Running the application
workon notifications-admin
./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.