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 or accidental clicks.
This commit expands the clickable area of tables where the left-hand
column is a link to include the meta information under the link.
We can’t make the whole row clickable, because sometimes we have links
in the right hand column which go to a different place
This commit also removes the CSS for `.spark-bar-label`, because these
elements are visually identical to `file-list`s now.
1. https://en.wikipedia.org/wiki/Fitts%27s_law
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.
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.
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.
It’s a confusing proposition to have two features which are almost
identical. Even differentiating between them in the template menu would
be tricky.
I think the better thing to do is rename the whole feature to ‘send
one-off message’.
Then if someone wants to use there own phone number or email address,
give them a quick shortcut to doing that, once they’re in the flow.
In the background this reuses the ‘send yourself a test’ code, but
the user is never aware that they’re going through a different route
to send an individual message. So the proposition stays nice and clean.
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.
Previously they were relative (ie percentages). This made sure that they
worked on mobile, when the letter might be narrower.
However it broke when the preview was more than one page, because
13% of the height of 2 pages is different to 13% of the height of one
pages.
This commit changes the positions to be pixel values, which match the
calculated percentage values when the preview is one page.
It’s uneven ever since we upgraded the toolkit. Guess it’s probably
allowing space for an arrow image. But I don’t like the arrow image
because it looks like it’s pointing at the ‘or sign in’ link.
So this commit overrides the button’s default spacing.
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.
Not sure why we were doing this. But as part of the Elements upgrade
our back buttons got bigger (because they weren’t constrained by the
line in our `app.scss`) but any green submit buttons stayed smaller in
height, so didn’t line up.
This commit removes the override, so all buttons have the size that
Elements intended.
The Elements CSS was making the `label` and `input` of disabled radio
buttons `opacity: 0.5`. This was resulting in text that was:
- too pale, especially where we were nesting 16px ‘hint’ text inside the
label
- waaaay too pale when inside a link inside the label
This commit overrides elements to dim the disabled radio button by
making it’s text colour grey, rather than making the whole thing
semi-transparent.
