Showing the template on the job page was semi-useful when you couldn’t
see the contents of each individual message. It was still a bit weird
because it just showed the template, never the actual messages that
went out, with the placeholders.
Now that users can click through to see individual messages, and can see
a short preview of the content on each row I think we can safely lose
the template preview on this page.
Right now we have separate pages for email and text message templates.
In the future we will also have a separate page for letter templates.
This commit changes Notify to only have one page for all templates.
What is the problem?
---
The left-hand navigation is getting quite crowded, at 8 items for a
service that can send letters. Research suggests that the number of
objects an average human can hold in working memory is 7 ± 2 [1]. So
we’re at the limit of how many items the navigation should have.
In the future we will need to search/sort/filter templates by attributes
other than type, for example:
- show me the ‘confirmation’ templates
- show me the most recently used templates
- show me all templates containing the placeholder `((ref_no))`
These are hypothetical for now, but these needs (or others) may become
real in the future. At this point pre-filtering the list of templates
by type would restrict what searches a user could do. So by making this
change now we’re in a better position to iterate the design in the
future.
What’s the change?
---
This commit replaces the ‘Email templates’, ‘Text message templates’ and
‘Letter templates’ pages with one page called ‘Templates’.
This new templates page shows all the templates for the service, sorted
by most recently created first (as before).
To add a new template there is a new page with a form asking you what
kind of template you want to create. This is necessary because in the
past we knew what kind of template you wanted to create based on the
kind you were looking at.
What’s the impact of this change on new users?
---
This change alters the onboarding process slightly. We still want to
take people through the empty templates page from the call-to-action on
the dashboard because it helps them understand that to send a message
using Notify you need a template. But because we don’t have separate
pages for emails/text messages we will have to send users through the
extra step of choosing what kind of template to create. This is a bit
clunkier on first use but:
- it still gets the point across
- it takes them through the actual flow they will be using to create new
templates in the future (ie they’re learning how to use Notify, not
just being taken through a special onboarding route)
I’m not too worried about this change in terms of the experience for new
users. Furthermore, by making it now we get to validate whether it’s
causing any problems in the lab research booked for next week.
What’s the impact of this change on current services?
---
Looking at the top 15 services by number of templates[2], most are using
either text messages or emails. So this change would not have a
significant impact on these services because the page will not get any
longer. In other words we wouldn’t be making it worse for them.
Those services who do use both are not using as many templates. The
worst-case scenario is SSCS, who have 16 templates, evenly split between
email and text messages. So they would go from having 8 templates per
page to 16, which is still less than half the number that HMPO or
Digital Marketplace are managing.
References
---
1. https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
2. Template usage by service
Service name | Template count | Template types
---------------------------------------|----------------|---------------
Her Majesty's Passport Office | 40 | sms
Digital Marketplace | 40 | email
GovWifi-Staging | 19 | sms
GovWifi | 18 | sms
Digital Apprenticeship Service | 16 | email
SSCS | 16 | both
Crown Commercial Service MI Collection | 15 | email
Help with Prison Visits | 12 | both
Digital Future | 12 | email
Export Licensing Service | 11 | email
Civil Money Claims | 9 | both
DVLA Drivers Medical Service | 9 | sms
GOV.UK Notify | 8 | both
Manage your benefit overpayments | 8 | both
Tax Renewals | 8 | both
We’ve seen services that have a lot of activity on their dashboard
miss the usage feature because the link gets pushed a long way down the
page.
We don’t want to move it up the page, because for most users the
templates/jobs stuff is more useful. And we don’t want to remove it
because it’s a useful part of the onboarding to understand the Notify
proposition.
So this commit adds it as a link to the nav, to make users more aware of
it, and as a quick way of getting into it for the small subset of users
who will care about it (a lot).
Order of the links is determined by what’s likely to be most useful for
first time users surfing the nav. Usage is more interesting than
settings, but less interesting than team members.
We grey-out the non-current step in the tour so the user knows whether
they’re at step 1, 2, or 3.
This is done using CSS opacity.
IE8 doesn’t support the standard CSS opacity syntax. But it does support
the weird, old, Microsoft-specific `filter:` syntax. So this commit:
- makes the greying out a class rather than an inline style, to reduce
duplication
- adds the filter syntax so the greying out works in IE8
Platform admins should be able to see what’s going on with a service’s
API integration, including:
- messages sent
- contents of whitelist
- names of keys
They should also be able to revoke keys in an emergency.
The only thing they _shouldn’t_ be able to do is create new keys
(because then they’d be able to send messages as the service).
This commit adds a placeholder page which, for now, just has links to
the API keys page and links to the clients.
There’s more stuff to come on this page, but this commit just does the
reorganising so that it’s easier to review.
Since this page is more than just your API keys, it should be named
something else.
Hopefully the word ‘integration’ will give non-techical users a clue
that it’s possible to use Notify without doing the CSV dance.
Our templates are a littered with `request.args.get('help', '0')`.
This commit refactors these into a single helper method, which can be
used by the view functions, then passed to the template.
This makes the templates cleaner, and should make it easier to refactor
`help` out of the query parameters entirely in the future.
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’
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
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 code for this is quite hacky and light on tests. But I’d really like to get
it in the app for the research tomorrow to see how well the feature works._
This commit changes the tour from being a set of static screens to some help
which guides you through the process of sending your first test message.
The theory behind this is that what users are really struggling with is the
concept of a variable, rather than the relationship between the placeholders and
the column headers. And like learning to program, the best way to learn is by
taking an example and modifying it to your own needs.
This means that when someone adds their first service we set them up an
example email template and an example text message template. Then there is a
guided, three step process where _all_ the user can do is send a test message to
themselves.
Once the message is sent, the user still has the example templates which they
can edit, rather than having to remember what they’re supposed to be doing.
We saw lots of people in the lab clicking activity hoping for…
something. But it’s not really where you go to do a thing, so they
weren’t finding what they were looking for.
Since you can now get to the activity from the dashboard, let’s remove
the link in the nav, to make thing less ambiguous.
Elsewhere (eg the dashboard, the activity page) we have email first.
Emails are also anticipated to be slightly more popular in terms of the
number of services sending them.
Therefore it makes sense to have emails first in the main navigation.
Statuses used to be:
- failed
- complaint
- bounce
- sent
- delivered
Now they are:
- sent
- sending
- delivered
This change broke the notifications page on the admin app.
It also made me realise that we should be ignoring ‘sending’ messages in
the history page—it should only show messages we’ve tried to deliver.
The code for this is a bit of a bodge, but it will get things working
again for now.
We have lots of keylines in our pages, eg tables, email message previews
This makes the pages look quite cluttered, especially because the
keylines don’t always align.
I think it looks much cleaner without the keylines in the nav, and we
have few enough nav items that we don’t need to chunk them up.
Because ‘Send text messages’ isn’t very helpful if you’re looking to
edit a template.
It also helps front-load the navigation, ie ‘Team’ is the first word,
rather than the more generic ‘Manage’.
In the navigation you should see either:
- manage team
- view team members
This depends on which permissions you have. You shouldn’t see both at
once. There was a bug which meant you could see both. This commit fixes
that bug.
https://www.pivotaltracker.com/story/show/116608291
A new permission has been added, view_activity, to resolve this issue.
Another pull request in notifications-admin will be required to update all users with a default permission of view_activity.
