When you’ve sent message(s) using a template, often the next thing you
want to do is go and send the same template again, or edit it.
Currently there’s no way of getting to a template from a job except for
going back to the list of templates and re-finding it.
This commit adds a link at the bottom of the job page that gives you a
shortcut back to the individual template, where you can find actions
like edit/send/etc.
Tests assumed that the API returns the template `id` as part of the
object. It doesn’t – it returns it as the key used to look up the
object. The `id` was missing from the transformation into the format
used by the front end.
For some reason Flask is fine building the URL with `template_id=None`,
but obviously this doesn’t generate a valid link.
Removed as part of refactoring the code to generate the graphs of
template usage on the dashboard:
4a226a7a29 (diff-cf78cb5c29a2d3c4d45b61d8617824b7L29)
Didn’t realise that they were used by the functional tests.
This commit puts them back while keeping the code reuse.
Making the navigation narrower means that we have more space on every
page. So on pages where we had to use 16px type just to fit stuff on the
page we can now bump the type size up to something less miserly. This is
mainly the team and settings pages.
We still need to use 16px on pages which list notifications or previews
of spreadsheets, because we’re still trying to fit a lot of information
onto these pages, so every little space-saving helps.
When adding a letter it’s hard to know how the stuff you’re typing is
going to look. So rather than go straight to the edit form let’s show
users a blank letter. They can then choose which part of it they want
to edit first. And will have a better idea of how their changes are
going to show up.
In research we also saw nervousness around saving a template and wanting
to ‘preview’ it first. Hopefully this flow will make people feel less
precious about saving a template because they’ve already done it once
just by creating the template.
When you add a new template the next thing you want to do is probably:
- send a test
- edit it after seeing what it looks like
So let’s redirect you straight to the page where you can do these
things.
This is especially important for letters where we want to tighten the
edit/feedback loop.
Like the template ID this is an infrequently-used action on a template
and doesn’t belong at the same level as ‘Upload recipients’ or
‘Send yourself’ a test. We don’t think it’s information that’s useful to
working out which template you want to interact with, so it shouldn’t be
on the choose template page any more.
Not necessary to have it on its own page – it’s one line of stuff. And
definitely not as frequent use as the ‘Upload recipients’ or ‘Send
yourself a test’ links.
Because we have space there’s no need to hide this now. Makes it less
confusing to have parts of the email appear/disappear as you’re clicking
through the flow.
The email looks a lot like the normal content of a page (black on white
text, same font, rendered by the browser). It needed differentiating
visually.
This commit adds a border and spacing around the email to separate it
from the things on the page that you’re supposed to be interacting with.
This isn’t needed any more because:
- we’re moving toward not clicking the letter to preview it, so there’s
no need for a (not very intuitive) indication that it’s clickable
- we’re not showing letter templates on the same page as email and text
message templates, so there’s less need to visually differentiate them
(which also worked to limited effect)
Previously we only showed the top half of a letter template, in order
to conserve space and fit multiple letter templates on one page. Now
that we have only one template per page there is space to spare. So
this commit changes the letter preview to show the full height of the
A4 page.
This also requires increasing the resolution at which the preview is
rendered so that it still looks clean at the bigger size.
Since we’ve simplified the left hand nav so much it doesn’t need 1/3 of
the width of the page. By making it smaller we have more space to show
previews of email and letter templates.
Letter templates have (or will have) multiple different editable
regions. I think that the most intuitive way for this to work is to have
- an edit link for each of these areas
- positioned next to the thing to be edited
Again, this isn’t fully hooked up, but since no-one is using letters
live yet this is a good way of getting research feedback and pointing
towards where we want the feature to go.
Uses percentages for the positioning so that the alignment is maintained
on mobile.
We think that sending a test for letters will mean downloading or being
emailed a PDF version of the populated template. While we haven’t
changed the app to do this yet, renaming the button is a good way to get
feedback about it from research.
The links to the right of the template take up valuable horizontal
space. This means that the preview of email and letter templates isn’t
as big as it could be. By making the letter preview bigger it removes
the need to click through to the PDF to see a preview.
Reuses the navigation style used on the API integration page, because I
think it damages consistency to create another new button style.
The find as you type only becomes useful once you have too many
templates to quickly scan visually on the page. I reckon that 7 is the
number where this starts becoming tricky. About 5 fit on the page
without scrolling (on my Macbook).
Not everyone knows how to use `ctrl` + `f`, and it’s not scoped to
just the list of templates.
The template you want to work with is often not the first one in the
list, but ordering by created at is useful for other reasons (mainly
around first time use).
This commit adds a find as you type control which aims to give users a
quick way of getting to the template they want to work with.
When a team has lots of templates the choose template page gets very
long. It gets hard to find the template that you are looking for.
Our initial reckon was that teams would not be giving their templates
very useful names, and therefore a preview would be helpful. What we
have found is that:
- teams actually do give their templates useful names, and refer to
these template names elsewhere
- the previews are less useful for emails and text messages, because
they have so much content (which for emails also makes it harder to
`ctrl` + `f` the template name)
The other problem we found was that this page presented the user with
a _lot_ of options. For each template there were 4 actions, plus the
click-to-preview action for letters, plus the ‘see previous version’
action for templates that had been edited multiple times. It was a very
busy page.
And the final problem (that we recently introduced) was that there was
no way, other than the visual cues, to know whether a template was a
letter, email, or text message.
So this commit strips back the choose template page to be very focused
on finding the right template, by only showing the template name and
type. The user can then click through to a page that shows just a single
template, and perform actions relevant to that template from that page.
This was used on the old product page to do the graphic of three phones
showing three different messages. We don’t have this any more, so this
‘component’ is unused.
Also removes some unused imports which were a hangover from previous
versions of the product page.
Although we integration test the pages that depend on these, it’s
probably a good idea to unit test them as well, to make sure, for
example, that all the different statuses are counted when working out
how many messages have been sent from a template.
- ‘messages sent per month’ is a better description of what will appear
on the page than ‘activity breakdown’
- ‘templates used by month’ instead of ‘this year’ for consistency
I think ‘usage breakdown’ still works for the remaining link – it’s more
than a monthly breakdown, it also breaks down the spend.
Doesn’t need to say ‘by month’ in the `<h1>`s themselves, because you
can see from looking at the page that it’s broken down by month.
Everything is fine and happy locally and on Jenkins.
Getting a `cannot import name viewkeys` error on AWS.
Based on some Googling, it’s possible that this will fix it.
