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).
This commit adds a component for showing an API key. Usage:
```jinja
{{ from 'components/api-key.html' import api_key }}
{{ api_key('e1b0751388f3cd0fc9982c701acdb3c2') }}
```
Depending on the user’s browser, it works in three different ways.
No Javascript
---
The API key is shown on the page.
Older browsers with Javascript
---
The API key is hidden, and users can click a button to reveal it.
Newer browsers that support copying to clipboard without Flash
---
As above, but when the key is shown there is a button which copies it to the
clipboard. This is acheived by using
[this polyfill](https://www.npmjs.com/package/query-command-supported)
to reliably detect browser support for the ‘copy’ command.
The styling of the component is a bit different to the initial sketch. I think
a grey button works better than green. Green feels like it’s going to take you
somewhere else.
Because:
- GOV.UK elements is now published with a package.json that only install the
SASS files (https://github.com/alphagov/govuk_elements/pull/156)
- We can drop Git submodules, so one less dependency management tool
This commit also changes the `gulpfile.js` and `main.scss` files to use the
assets from `node_modules` rather than the Git submodules.
If the templates page contains text messages and emails then there’s two ways it
could be structured:
- into two sections, all text messages first, then all emails
- emails and text messages interleaved, sorted by date
I think the second one is better. Imagine a situation where you mostly do emails
but have a few text messages. You’d have to scroll past the text messages to get
to your emails. Every time.
I reckon that the most commonly accessed templates will be the most recent ones.
- by default, the menu is open
- if Javascript is enabled/loaded, the links are hidden, and visual cues (▶) to
show that it can be opened are added
- clicking it opens and closes it
This macro:
- accepts a WTForm form field as a parameter
- renders a form field which follows the GOV.UK Elements patterns, both visually
and in markup terms
It then changes any page which uses either:
- the old, non-WTForms macro or
- the old, WTFforms `render_field` macro
…to use this new macro and removes both of the old ones.
It also adds the option to display hint text above the textbox.
Found a way to create the token that does not need to persist it to the database.
This requires proper error messages, written by people who speak menglis good.
Submit form was
- a confusing name in itself
- not descriptive, because it also has an optional ‘back’ link
This commit also puts this component in as many pages as possible, stripping
out any hard-coded buttons and links.
It replaces any usage of buttons for ‘back’, because these are links, not
buttons (ie they don’t change any data).
Adds the pages and wires them together, so that it’s possible to click
through them.
The wording is not quite English, but attempts to be an rough description of
what the consequences are for each of the four actions.
Users can add placeholders to their messages, eg
> …your vehicle ((registration number))
when the message is sent, this gets replaced with the data the user uploads, eg
> …your vehicle LC12 BFL
We reckon that it will be useful to see that the placeholder has been
recognised, ie that its syntax is correct, before uploading any data.
We reckon that the best way to do this is by styling it differently to the rest
of the text that the user types.
This is not a trivial problem. There are two possible ways to do it:
1 Write a Google Docs-style text rendering engine, which completely replaces
the native HTML `<textarea>` with a custom control, and programme what should
happen when the user types something that looks like a placeholder, or
presses an arrow key, or makes a selection, or…
2 Leave the `<textarea>` in place, unmodified, and duplicate layers in front
of/behind it to visually replace a placeholder with the blue lozenge
Unsurprisingly, this commit implements 2.
There are four layers. Each layer contains live-updated copy of the text in the
textbox, and each is styled differently:
- one layer behind the textbox to make the blue background
- the textbox itself
- a layer with the white text, which overlays the black text of the textbox
- a layer with an inner shadow to knock back the brackets
This is because of some interesting limitations:
- The text in the foreground and background must occupy the same physical space,
so no deleting characters from the duplicated layers
- Words can’t be split up into multiple elements,
eg `<span>((</span>regist…`:—this results in slightly different kerning to
`((regis…`, which messes up the alignment of the layers
- The textbox can’t be completely overlapped with a block of colour, because
the cursor disappears behind it. Trying to edit text when you can’t see the
cursor is hard.
Implementation
Technically this makes use of Paul Hayes work on Javascript modules in the
GOV.UK frontend toolkit[1].
It also makes use of the `oninput` event to detect changes to the textbox’s
contents. This is much more performant than `onkeydown`, `onpaste`, etc. Without
it the delay between user input and the layers all updating is too slow and you
see misalignment of the layers.
1. https://github.com/alphagov/govuk_frontend_toolkit/pull/227
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
This commit:
- removes the row numbering so it’s easier to scan the list of phone numbers
- adds subheadings for 'first three' and 'last three'
- puts the 'see all' link at the end
We could do something with Javascript to only show the selected template. For
now this is something that works without Javascript.
This means we can put off getting the build and testing pipeline for Javascript
set up, which is a bigger and more unknown piece of work.
As a first guess placeholders can be added to messages with the
`((placeholder))` syntax.
This commit adds a Jinja template filter to convert strings containing
said-formatted strings into HTML, which can then be styled to highlight which
parts will be substituted in messages.
Main thing that was missing was including the main CSS file in the template.
There are a few hacky bits here, like moving the whole of toolkit inside the
stylesheets directory.
Would arguably be cleaner using something that isn’t Flask Assets, but that’s
something for later.
