The green bordered banner feels too much like ‘success’ or
‘confirmation’. Doesn’t feel like it’s something which just gives you
the status of a thing, or here’s a thing you should be aware of.
We use panels with a blue banner to indicate something that’s clickable.
So we should move away from this style for things that are just
notifications. We can’t use teal like other bits of GOV.UK because it
doesn’t pass colour contrast.
Pay are using a box with a green border, similar to the error validation
box (which has a red border). So let’s do the same for now.
The visual convention for redaction is heavy black crossing-out.
Our text colour isn’t always black exactly though (usually it’s very
dark grey, sometimes just dark grey). `currentColor` is a magical CSS
value that let’s us set the background colour to whatever the text
colour is. So both the text and redaction look like they are part of the
same thing.
Couple of subtle visual things here:
- opacity to make the colour better match the text colour – a filled box
naturally looks darker than thin text, so this knocks it back a bit
- an inset shadow to take a few pixels of the bottom edge – the visual
weight of text is biased upwards because text has ore capital letters
and ascenders than descenders – this make it look aligned visually
We’ve made a few changes to the tour recently, without changing the
help text on the left hand side of the screen. So the stuff you see on
the right side of the screen doesn’t quite sync up any more.
This commit adds an extra, introductory page that just shows the
template and a next button, which better matches the ‘every message
starts with a template’ help text.
Works similarly to the delete template flow, because it’s a destructive,
one-way action.
Not on the edit template page, because it’s not something you want to be
considering every time you’re editing a template. And we saw that people
couldn’t find the delete button when it was on this page.
Adds a bit more CSS for the `dangerous` banner type, because the content
here is quite complicated. Breaking it into a list helps, but the
spacing didn’t look right, so needed some tweaking.
Can ship independently of the code that shows the redaction, but needs
the API first.
Generally, bigger click areas are better[1], as long as they don’t cause
ambiguity.
This commit expands the clickable area of links to templates to include
hint text underneath which states the type of template.
1. https://en.wikipedia.org/wiki/Fitts%27s_law
Normally, fixed position elements are positioned at `top: 0`.
The code that stops them from overlapping the footer does so by:
- setting the position to absolulte
- setting `top` to a calculated value (eg `1500px`) which makes it sit
above the footer
The problem is caused because we’re animating `top`, so when scrolling
back up the page elements are getting animated from `1500px` to `0px`,
ie flying up from the bottom of the screen.
The transition between something being static in the page and fixed to
the top of the viewport is a bit jarring.
This commit adds a bit of animation so that, as elements become fixed,
they appear to catch up with the scrolling of the page.
You’ll quite often be landing half way down this page. So the context
afforded by being able to see the phone number gives you some
reassurance that you’ve landed in the right place.
We anchor link to the relevant message in a thread. Which is good, but
it leaves the messages hard against the top edge of the viewport. This
looks sloppy. So this commit:
- makes each message focusable
- shifts the focused message with CSS to sit away from the viewport
> Once an inbound message has been received, there should be a way to
> see the other messages in the system from the same service to the same
> number. Both in and outbound. Nice inbox/whatsapp stylee view or some
> such. This way the context of the reply is understood.
>
> Initially will only see the outbound template, not the actual message,
> but we’re going to change this for the rest (soon), so that you can
> always see the full message for all outbound.
This commit adds two things:
a section on the dashboard to show how many inbound messages the
service has received in the last 7 days, and how recently an inbound
message has been received
---
Doesn’t show the contents of any messages, just like how the rest of the
dashboard is an aggregation, never individual messages.
a page to show all the inbound messages the service has received in
the last 7 days
---
This shows the first line of the message. Eventually this will link
through to a ‘conversation’ page, where a service can see all the
messages it’s received from a given phone number.
Because manually editing the URL isn’t a great user interface, this
commit adds a search field to do this on the user’s behalf.
For this pass at the story it doesn’t do any validation – the user will
just get no results if they search by something which isn’t a phone
number or email address.
If the user navigates to a different ‘bucket’ of notifications (eg
delivered, failed) then the search term is reset, because they’ve
changed the filter which is at a level above the search term.
Because:
- drawing things in CSS is fun
- when we have inbound messages, having a tail pointing the other way
will help differentiate which messages are inbound
Things we don’t do with SMS messages any more:
- put paragraphs in them (we use `<br>` tags instead, to allow for
multiple linebreaks)
- pick them using radio buttons
- render the template’s name as part of the template
- render the phone number that the message will be sent from as part of
the template
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.
Because the email addresses can get pretty long, and have no spaces in
them, they sometimes break out of their containing box. This looks messy
and causes horizontal scrolling.
We’ve seen in research a user getting stuck playing with the
scheduler. They picked a day, but then didn’t want to choose one of the
options for that day. There’s no way to do this except pick a day and
then un-pick it.
What they ended up doing was clicking the grey back button, which took
them back to the previous page, making them upload their file again.
This commit adds a ‘back’ link for the scheduler. ‘Back’ seems like
sensible naming because that’s the thing that the user tried to click,
and the UI of a link matches the thing they clicked to get into this
situation.
The delete link was designed to be used with a button, where it needs
some padding to separate it from the button.
We now have a case where it’s being used without an accompanying button,
so we need a variation without that padding.
Not sure what about the new radios is causing this, but they no longer
expand the size of the container, causing an overlap.
The fixed height was originally for performance reasons, but removing
it doesn’t seem to cause the page to jump around on load, so I think
it’s OK.
The visual appearance of radio and checkbox form inputs changed in
GOV.UK Elements here:
https://github.com/alphagov/govuk_elements/pull/296
This was subsequently reimplemented with different markup and no
Javascript here:
https://github.com/alphagov/govuk_elements/pull/406
This has meant making the following changes to our app:
- changing the markup in our radio/checkbox macros to match the example
markup given by GOV.UK Elements
- removing the previous Javascript file because it’s no longer needed to
make the radios appear visual selected
- making the buttons on the scheduled job picker look like links,
because the grey button style looked weird with the new radio buttons
- SMS message preview gets slightly wider so it lines up with a 4/8
column
- Edit email box gets wider to match more closely the width of the
previewed and delivered emails
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.
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.
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.
In HTML you generally can’t nest an inline level element inside a block
level one, if you want your HTML to validate.
There were a couple of places where we were using a `<span>` as a
containing element:
- inside every table cell (think we inherited this from Digital
Marketplace)
- in the ‘pill’ navigation component for the selected tab
This meant that when we put components like big number inside these,
the resulting HTML was invalid, because big number is built with a bunch
of `<div>`s, which are block level.
This commit removes the use of a `<span>` tag in these places, and
replaces it with a `<div>`. Nesting block level elements in fine in
HTML.
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
