Seen it a few times in research where people are like “so it’s live now
… I think. Is it?”
Let’s tell them exactly what’s happened. Also a chance to get @minglis’
idea about showing the daily limit.
The yellow banner didn’t make this information much more noticeable,
and it made some people miss the request to go live link because it
wasn’t blue.
This commit brings the design back to where it was as of this PR:
https://github.com/alphagov/notifications-admin/pull/904
This is trying to resolve these confusions:
- that you’re in trial mode, which means you can’t have a live key yet (
or you can but it wont work, which is what we used to have)
- what does simulate mean
The create key page is the right place to resolve these confusions
because it’s where users are actively reading.
This commit also removes the trial mode banner from API integration
page because this where users _aren’t_ actively reading. A whole bunch
of users weren’t seeing this banner at all.
The implementation of the disabled API key options is kinda clunky
because WTForms doesn’t have a native way of doing this.
¯\_(ツ)_/¯
If we want someone to read something (ie that they need to have the MOU
signed), then the best way is to make them interact with it.
And if someone doesn’t have the MOU in place, then we need to know to
send them a copy. The best way of them telling us this is in this form,
rather than sending them to the generic contact form and have them
compose a message saying ‘please send me the MOU thanks’, which we
haven’t seen anyone actually do.
We’ve had some non-helpful answers to these questions, eg ‘3’.
This commit adds examples of the kind of response we’re looking for, to
help users write good answers.
If you’re looking back at a job that was scheduled and has now been sent
it’s more useful and consistent to know what time it went out. The time
it was uploaded at is a bit arbitrary once it’s sent.
The only time the uploaded time is relevant is when the job is still
waiting to be sent.
Slightly fiddlier than it sounds because we never want to show
‘uploaded by’ for a job that hasn’t been scheduled because it almost
immediately changes to ‘sent by’. This flickering of the UI is
undesirable.
Friday at 4pm is easier to understand than 14 October at 4pm, especially
when the UI you’ve used to choose this time has talked about days of the
week.
The options for scheduling a job by time should be grouped by day,
because a long list of 96 options is not very usable.
On the server side, this commit generates label for the next 4 days in
a friendly format (ie today/tomorrow/Sunday/Monday)
The Javascript component for choosing a time was built in a kind of
old-school jQuery way, where it manipulated the elements on the page.
The complexity of introducing groups of options was just too much for
this pattern, because it involves storing a lot of state in the DOM.
This commit completely rewrites the JS to:
- read the initial options and groups from the HTML and store them
in the object
- use Hogan to completely re-render the UI from a series of Mustache
templates, each of which represents a state of the UI and takes the
inital options and groups
- filter the choices to show when the today/tomorrow/… buttons are
clicked
