The Design System has standardised on back links being at the top of the
page, decorated with a small text-coloured arrow.
I think this makes more sense than having them at the bottom, because it
suggests, in some way, being able to go back before commiting to any of
the forms on the page. Whereas the things at the bottom of the page
should be performing actions on what’s in the page.
The reason for making this change now is that it de-clutters the area
around the green buttons. This was presenting a design challenge where
multiple levels of interaction were happening in the same form. Moving
these back links to the top of the page should mean that, in these
complicated forms, there’s one fewer thing to compete for the user’s
attention.
I’ve componentised this into a `page_header` macro so that the change is
easier to roll out and maintain.
The gulp-base64 package has 11 dependencies with
vulnerabilities listed against them as of this
time. It also doesn't seem to be maintained any
more. The last commit was in 2015 and there are
issues and pull requests up to bump the
dependencies.
This replaces it with gulp-base64-inline.
gulp-base64-inline takes a single path, which it
prepends to any image paths it finds. Our image
paths are actually URLs, not filesystem paths so
we need to send it a relative path to repoint the
URL.
This commit includes changes that remove a few
`@import`s from one of our sass partials.
They aren't needed as those files are imported
further up the stack and `_typography.scss` has an
import in it that overwrites the new
`_url-helpers.scss` we added here.
We adjust the spacing under the textbox when doing the send one off
flow. This was based on the assumption that there would always be a
sticky header in the send one off flow.
This assumption is no longer true, so this commit implements the same
spacing in an independent way.
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
This commit changes the form that the user sees when inviting or editing
another user, if the service has the ‘caseworking’ permission set.
This will allow creating a new type of user, one who only has the
`send_messages` permission, without the `view_activity` permission.
We are doing this because we think there are a number of services with a
lot of users who don’t need to see the dashboard, or the other team
members, and that we can make a simpler interface for these users.
We have found repeatedly in research that our users don’t know what
‘beta’ means. In this situation they come up with their own
interpretation of what it means, for example that:
- certain features are not available to them
- Notify as a whole is not available to them
- they are using a ‘different’ version of Notify to those using it for
real
In the most severe cases this ambiguity actively dissuades users from
adopting Notify. We know this from support tickets and user research;
there are probably a host of other teams we haven’t spoken to.
Here’s a quote from a user research session just last week:
> Once we’ve got the facility to receive inbound messages […] that’s not
> available to us at the moment with a beta account
From support tickets:
> We see that the service is still in beta mode – can we assume
> uninterrupted service reliability and performance?
> we do not have a .gov.uk email address any longer but I was wondering
> if we would be able to utilize the notify system which is currently in
> beta
> We are currently using the BETA version, are we able to switch to the
> TEST version so we can add other numbers to send SMS to?
> I have previously enquired about this option [receiving text messages],
> but thought it was still at Beta stage. If we can set it up so that
> notify handles the responses that would be great.
> [after going live] Should I see the wording LIVE on the login screen
> as I still see BETA.,....
> Also I note that you are a BETA service just now and that to use the
> service we would need a .gov.uk email address. We don't have this, is
> there any way that [redacted] could use the service as I note that one
> of the teams have an account?
---
This commit removes the beta badge from Notify, and hopefully with it
the confusion it’s causing our users.
Two bits of context:
1. As we start dealing with letters, which have more columns, it’s more
likely that people’s spreadsheets won’t fit in our current layout.
2. We already removed the view of the template from the page that shows
row-level errors (eg bad phone number or missing personalisation) in
spreadsheets because you don’t need to know about the content of the
message in order to fix the errors.
This commit goes further by removing anything that isn’t to do with
the errors, including the normal GOV.UK header and the service’s
navigation.
This means the content can go the width of the page, which means it can
be allowed to scroll horizontally without being a usability car
crash. Which means that the layout doesn’t break with a spreadsheet that
has lots of columns.
Since we’ve removed the table of notifications from the single
notification page there’s no way of knowing the status of a
notification.
This re-adds it in a way that’s similar to how it looks on inbound
messages.
You might need to scroll this page quite a lot to see where a
placeholder appears in your template – especially if you have a long
email or letter.
One of the things I’m trying to stop happening so much is a lot of
scrolling back and forth. This would happen if you were scrolling down
to see the placeholder, then back up to fill in its value.
So this commit makes the textbox ‘sticky’, ie it always stays at the top
of the viewport, even when you scroll down. This lets you see the
placeholder and the textbox side by side, no matter how long the
template is.
The code to do this mostly comes from the GOV.UK Frontend Toolkit
(documented here: d9489a9870/docs/javascript.md (stick-at-top-when-scrolling)).
I had to add some extra CSS to make it look good when it overlaps the
content of the page, which the GOV.UK Frontend Toolkit implementation
doesn’t really anticipate.
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.
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.
This copies what the other GaaP components will be doing for their
product pages.
The SASS and HTML is taken from here:
f05ca1fb71/source/stylesheets/modules/_breadcrumbs.scss
Only changes I’ve made are:
- making the file paths work with our build pipeline
Changes to our code to accomodate this are:
- putting the padding on the product page `<h1>` not its container
- moving the hero image accordingly so that it lines up
- making the `<main>` element on the product page into an anchor so that
the breadcrumb can link to it – screenreader will then announce the
link as “GOV.UK Notify, same page”
This copies the style that Tim and Stephen have been developing for all
product pages.
It also pulls out the CSS for this into its own file, so that it could
potentially be reused.
Let users create/edit/delete letter templates.
Let them upload a CSV file or send a test against a letter template.
Big assumption at the moment is that addresses only have one line, and
therefore one column in the CSV file.
Now that we’ve removed simulated notifications from the dashboard and
activity pages they’re not visible anywhere in the app.
While they should’t be visible to non-technical users, developers have
a real need for Notify to confirm that their code is doing what they
expect. This is needed especially when they’re just getting started with
Notify.
There’s no way of seeing this info from the API either, because a key
can only get notifications created with a key of that type.
It doesn’t make sense to make this a ‘mode’ of the dashboard or activity
because the information about notifications that developers need is
also different. So this commit adds up to 50 of the most recent
notifications sent via the API to the page that developers use as their
‘home’ page.
This also lets us explain the 7 days thing to developers via the
empty slate state of this area of the page.
Services who are in alpha or building prototypes need a way of sending
to any email address or phone number without having to sign the MOU.
This commit adds a page where they can whitelist up to 5 email addresses
and 5 phone numbers.
It uses the ‘list entry’ UI pattern from the Digital Marketplace
frontend toolkit [1] [2] [3].
I had to do some modification:
- of the Javascript, to make it work with the GOV.UK Module pattern
- of the template to make it work with WTForms
- of the content security policy, because the list entry pattern uses
Hogan[1], which needs to use `eval()` (this should be fine if we’re
only allowing it for scripts that we serve)
- of our SASS lint config, to allow browser-targeting mixins to come
after normal rules (so that they can override them)
This commit also adds a new form class to validate and populate the two
whitelists. The validation is fairly rudimentary at the moment, and
doesn’t highlight which item in the list has the error, but it’s
probably good enough.
The list can only be updated all-at-once, this is how it’s possible to
remove items from the list without having to make multiple `POST`
requests.
1. 434ad30791/toolkit/templates/forms/list-entry.html
2. 434ad30791/toolkit/scss/forms/_list-entry.scss
3. 434ad30791/toolkit/javascripts/list-entry.js
4. http://twitter.github.io/hogan.js/
Users need to pick a time in the next 24hrs, or send a file immediately.
Rationale for this is a bit lost in time-before-holiday, but generally:
‘Now’ and ‘later’ as the inital choices makes it really clear what
this feature is about conceptually.
The choice of times is absolute, eg ‘1pm’ not ‘in 3 hours’
The team page was a bit of a mess:
- invited and active tables didn’t line up
- lots of things were wrapping onto two lines
- the empty fields for when a user didn’t have permissions looked broken
This commit splits each row of the table (not actually a table any more)
onto two lines. First line has the user’s info, second has their
permissions and any associated actions.
This commit refactors the `email_message` and `sms_message` UI components to
take fewer parameters.
`name`, `edit_link` and anything to do with versions are identical for both
text and email messages so I’ve moved them to the pages where you choose a
template or see the versions.
This commit also tidies up the wording and styling of the template history
stuff.
The dashboard looked a bit table-y. This commit makes four main changes:
- show a bar chart (drawn in CSS) for template usage (only shown if
you’ve used more than one template recently)
- only break down template usage by template name, not template type
(because that’s happening with the big numbers)
- change the style of the ‘show more’ links under each section so that
they are all consistent, and a little less busy (one less keyline)
- remove the ‘recent templates‘ title so that the first two sections of
the page group under ‘in the last 7 days’
Takes the number of emails and SMS fragments sent from:
https://github.com/alphagov/notifications-api/pull/273
Using these numbers it’s possible to show:
- how much of your allowance is left
- or how much you have spent
For now the allowance and rates are hard coded.
Only for users that have manage service.
For users who:
- want to send messages from a template
- want to edit templates
For developers:
- who need to get the ID of a template
This commit mainly cleans up the choose template page so there are less
options, and the options that are there are less wordy.
This means:
- moving ‘send yourself a test’ onto the send messages page, and making
it button
- stripping a lot of stuff out of the ‘send from API’ page, so it’s more
obvious what the template ID is
This commit adds some basic type sizes, weights and spacing for HTML
elements scoped inside a `.documentation` container.
It also tweaks some of the Markdown so that it renders the same as it
does on Github.
Means you can see, for example emails that have failed.
Means adding:
- logic to generate links which can have a type parameter, a status
parameter, or both
- a ‘pill’ UI component for seeing which filters you currently have
applied
- some logic to change the page title based on which filters you have
applied
We should (and do) keep exact copies of SCSS files that have come from
elsewhere so that we can easily upgrade them. But sometimes they don’t
always pass our linting rules, or throw a lot of warnings, which is
noisy.
This commit:
- moves such files into their own subdirectory
- tells SCSS Lint to ignore files in this directory
Underscores at the start of filenames are a convention that’s supposed
to tell a preprocessor to ignore a file. Since we’re explicitly
specifying which files need to be preprocessed, this isn’t necessary.
Also, it makes SASS lint throw a warning.
The yes/no pattern didn’t work too well, because:
- it didn’t read naturally as a question and answer
- often users left them completely unclicked if they didn’t want to set
the permission (rather than clicking no)
This commit changes both the invite and edit user pages to use
checkboxes to set permissions. If also rewords these pages to read more
naturally, and explain what the permissions mean.
This meant changing some of the view logic around invites and
persmissions, and I ended up refactoring a bunch of it because I found
it hard to understand what was going on.
This takes the original prototype version of this page, and, using the same
fake data (ie nothing is wired up):
- adds an invite users page
- adds an edit (and delete) user page
Both these pages allow the user to set another user’s permissions.
This commit adds images for the ticks and crosses, so we have control over their
appearance.
Since placeholders (almost) work now, it’s worth telling people what the syntax
is.
This commit also removes the ‘template type’ picker, since you can only create
SMS templates at the moment. This will be revisited when we start looking at how
you add an email template.
Based on discussion with Pete.
Make the blue banner an ‘important’ banner (copied from Register to Vote, used
because it’s not as boxy and fits on the page better).
Remove the back button because you haven’t changed any data yet. If you need to
go back you can just press back or start again.
Make the filename stand out more.
Remove the ‘download example’ link. Will need to revist the best way of doing
this.
Make text messages consistently 2/3rd width.
This commit moves user-related navigation into the proposition header (the black
bar) at the top of the site. It adds some custom SASS to override GOV.UK
template and align these navigation items to the right (because it looks
better).
It then removes the service chooser dropdown (and its associated SASS and JS) in
favour of a link alongside the user-related navigation items. ‘Switch service’
is the best language for this that we’ve come up with so far.
This means that the only way of adding a new service is from the `/services`
page. So this commit removes the redirect if you land on this page with only one
service (else it would prevent you from ever being able to add more).
