Since we’re removing the write email/write text message calls to action
from the tour, we should reintroduce them to the dashboard, for users
who are unsure what they should do next.
After the tour we should ground users by dropping them on the dashboard.
In the background, we delete the example text message template. This
means that users start from a clean slate when they go to add their own
templates
This also means some wording changes to the tour so it still makes
(some) sense:
- 1, 2 and 3 should refer to the current step, not describe the next
one
- the link should take you to the dashboard
- change from ‘Get started’ to ‘Try this example’ because we’re using
‘Get started on the dashboard’
Since you can’t really send or edit a deleted template we should show
a message telling you that the template has been deleted.
This is important because deleted templates still show up in the
template statistics.
This commit extends the `ajax_block` component to take a `dict` of
partials, from which it can select the partial matching its `key`
argument and print its HTML to the page.
This means that the same markup is only rendered in one place, rather
than in two (individually in the JSON endpoint and as `include`s in the
parent template).
This is less repetitive than typing out the HTML with all its attributes
every time.
It also lets us wrap up the idea of ‘finished’ as a parameter, so the
AJAX code will only be initiated when it’s needed, eg if a job is still
processing.
Previously, the AJAX update for the dashboard was returning a big blob
of JSON with one key.
This commit splits it up to return:
- one key for each section of the page
- each containing a smaller chunk of HTML rendered from a partial
The jobs page was already working this way (pretty much) but just needed
a little tweaking to get it the same.
Previously the structure was
```
dashboard.html
|_ today.html
|_ some random html
|_ a few things split into partials
```
This commit simplifies the structure to just be:
```
dashboard.html
|_ partial
|_ partial
|_ …
```
When you register you type in your email address. If you don’t get the
email there’s no way of knowing it’s because you’ve mistyped it.
If we play back the email address, you can double check it.
This commit also removes the 2/3 column on this page to make sure a long
email address doesn’t wrap.
It’s been unclear that:
- the dashboard exists
- that you click the name of the service to get back to it
So this commit:
- takes the link off the service name
- adds a link labelled ‘Dashboard’ to the navigation
Text messages have a maximum length, which we tell the users. We
shouldn’t expect people to count the characters in the message
themselves.
This commit borrows [the word counter from the Digital Marketplace
frontend toolkit](9d17690de5/toolkit/javascripts/word-counter.js)
and adapts it to count characters instead.
Things I’m still not sure about with this:
- what should it say when the message goes over the length of one text
message
- what’s the interaction with placeholders, which will change the length
of the message
This commit also adds a line to the pricing page which explains that
service name counts towards the length of the message.
There are some common questions that keep coming up when users are
editing or creating templates. This commit adds a pattern for sections
of guidance which can be shown/hidden.
It then modifies the guidance as follows.
Change:
- guidance about placeholders; give an example about what to do and what
not to do (because the mistake we keep seeing people make is putting
the thing itself, not the name of the thing)
Add (pretty basic at the moment but a need for these has come out of
research):
- guidance about links
- guidance about message length for text messages
It was a `<dl>` before which is kinda weird. Especially when the jobs
table was a real `<table>`.
It also means we can give it column headings so that new and invited
users have a better idea of what it is.
When you’re dropped straight into the ‘edit template’ page it’s still
a bit confusing what the thing you’re typing is—the mental model isn’t
quite there yet.
I think it will help (rather than redirect to the dashboard) to redirect
to the choose template page. You can then choose to edit the example or
add your own template.
This should help people understand that the example is one of a number
of templates that you create.
The table on this page looked too much like something you were supposed
to interact with. To understand what’s expected of you from this page,
you need to know:
- what you’ve done to make this page happen (you changed some stuff)
- what actions are available now (confirm, back)
The rest of the information is supplemenatary—it helps you make a
descision, but it’s not key to understanding what the decision _is_.
This also matches what we do on the upload file page, where the
non-essential example is under the button.
> When we have jobs that have over 3% failure rates we should highlight
> those so that peoples attention is drawn to deal with the failure.
>
> They would then go to the job view to see what the details are where
> they could filter by failure, but that's a different story...
>
> This is just about calculating and highlighting those that need their
> attention.
— https://www.pivotaltracker.com/story/show/121206123
This commit:
- calculates the failure rate for each job
- makes jobs with a failure rate of > 3% go red on the dashboard
A long email message needs to be collapsed to only show the first few
lines. The problem is that we were doing this by adding a class with
Javascript, meaning that the email wasn’t being collapsed until the
script in the footer ran.
This caused a jump in the page because the browser was painting the
whole email message, then repainting it once it was collapsed.
This commit takes advantage of the `.js-enabled` class added to the
`<body>` by a script in the `<head>` of GOV.UK template.
This means that the email message is collapsed with CSS before the first
paint of the page, so no jump.
This introduces some complexity in how we determine which emails get the
expander toggle. Because they’re already collapsed we can’t get their
height and work out if they’re long enough to need collapsing.
So we need to take a copy of the message, put it off-screen, expand it,
get its height, then remove it from the DOM. Bit of a faff.
Because of this there’s still a quick flash of the toggle if you see an
email message that’s too short to need collapsing. I think this is the
lesser of two evils—very short email messages will be few and far
between in the real world.
