- Deleted /stylesheets folder
- Removed sass build from gulpfile
- Changed gov links to usa links
- Changed other govuk styles, like breadcrumbs
- Changed name of uk_components file to us_components
- Fixed a few tests that broke on account of the changes
This is what we do on the uploads page now. It makes it more obvious
why your search term has returned a certain result if you can see most
of the address, not just the first line.
If you’ve come to look at a notification via the uploaded letters page
then the ‘< back’ link should take you back there, not to the usual
activity page.
The search form makes a post request, so that phone numbers and email
addresses don’t show up in logs or browser history.
At most the API will return 50 results, with some pagination links. We
can’t easily give you links to click in the admin app, because links can
only perform get requests.
Because the value of seeing more than 50 results feels quite low (users
will probably make their search more specific before scrolling through
all 50) let’s just show a message saying only the first 50 results are
displayed.
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
Now persisting the address to the "to" field of the Notification, after the notification has been validated.
If the letter is pending validation, then "Checking..." will appear as the identifier for the letter.
If the letter has passed validation, then the first line of the address (now persisted in the "to" field) will be displayed, with the client reference underneath.
If the letter has failed validation the "Provided as PDF" will show be displayed, which is now the initial value of the "to" field.
Uses the configured service data retention page to display retention
period length, notification counts and fetch notifications from the
API on the notifications page.
It looks too prominent as a paragraph on the page. This commit moves
the info about how long we keep data for into the ‘empty’ message we
show when there are no results (ie the message people will see if they
search for something that was sent more than 7 days ago).
Precompiled letters can now have two additional states:
* pending-virus-check
* virus-scan-failed
Both new states should show in the notifications dashboard, and
virus-scan-failed should appear as an error state, with a descriptive
message. You should not be able to preview a letter in one of the two
new states, so the preview link has been removed for precompiled letters
in these states.
Most of our tables are now lists which have:
- a thing you click on
- some secondary info about that thing underneath
- some extra numbers/status on the right hand side
Since these are so similar, they should share the same pattern, which
this commit does (using the `file-list` pattern).
Visually this means:
- the secondary text on the inbox becomes grey not black, for
consistency
- the status bit of the notifications tables bottom align like the
status of messages in the inbox
These both seem like OK changes to make for the sake of consistency.
In tables where we show rows and rows of information we used to give
some meta information about the notification, or at least as much as we
could give in the very limited space available.
This information is now on the notifications page, so the information we
show in these tables should just be whatever helps users identify the
right message. I reckon that this is:
- the content of the message for text messages
- the subject for emails and letters
This also makes these pages consistent with:
- the inbound SMS page
- the way the people’s inboxes work for their text
messsages/Whatsapps/emails
For consistency’s sake this makes the job page work the same way. It may
be slightly less useful here because on the job page every message is
sent from the same template, so will have broadly the same content.
We have a page for individual notifications now.
On the job and activity pages each row of the table represents an
individual notification. So it makes sense for these things to be linked
together, so that a user can navigate from one to the other.
This will make more sense once we make some more changes to the
individual notification page.
There’s no need to see the ‘Report’ page for a one-off message – pretty
much all the info about the notification is there on the page. And
‘Sent from _Report_’ looks weird.
We should display it more like an API call instead.
Currently it’s not possible for a screen reader user to know which
financial year they’re looking at. From the accessibility report:
> The financial year links are contained in a navigation region -
> tabbing or arrowing through only reads out the links, not the main
> information of "2016 to 2017 financial year" - that information is
> vital for understanding the page content.
This problem also applies to other pages which use the `pill` component,
which is effectively tabbed navigation (that reloads the page rather
than showing or hiding content on the page).
There are specific ARIA attributes that can be used to mark up a
navigation as being tabbed. This commit:
- adds those attributes
- makes the selected ‘tab’ visible to screenreaders and keyboard
focusable
- adds a visual focus indicator to the selected tab
- adds `id`s to the parts of the page that are controlled by the tabs so
that they are labelled as such
This also means changing the pill component from being a `<nav>` to a
`<ul>` because `tablist` is not a valid `role` for a `nav`.
Mostly follows the example here:
http://accessibility.athena-ict.com/aria/examples/tabpanel2.shtml
