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.
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.
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.
Not sure how these got out of line (maybe when we brought the date into
the left-hand text area). But this commit updates the percentages to
match the comments.
This is so it’s clear from the position of the link which part of the
letter you’re editing.
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.
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.
The message text in our previous illustration was white on light blue,
which didn’t meet WCAG AA colour contrast. WCAG AA requires a contrast
ratio of 4.5:1. The text in our image was only 3.8:1.
The text in this new image has a contrast ratio of 19.8:1, so easily
passes WCAG AAA.
Required a slight tweak to the positioning of the image because it’s
dimensions weren’t exactly the same as the previous one.
The bars were sitting in a table cell with some right padding, so they
never extended all the way to the right. Making it right-aligned removes
this padding, then setting the text to left aligned keeps things looking
the same.
The previous, weekly activity breakdown was what we reckoned might be
useful. But now that we have people using the platform it feels like
aggregating a service’s usage by month is:
- matches the timeframe users report on within their organisation
- is consistent with the usage page
And like the usage page this commit also limits the page to only show
one financial year’s worth of data at once (rather than data for all
time).
This commit also makes some changes to the jobs view code so that our
aggregation of failure states is consistent between the dashboard pages
and the jobs pages.
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”
‘How much does it cost’ is one of the user needs that we identifed for
the product page.
Cost is not the primary reason someone would use Notify (they’re more
likely to cite ease, or that it’s ‘official’). However if you _don’t_
mention cost then it looks like we’re hiding something or that there’s
a catch. So putting it on the page allays fears that people might have,
rather than pushing them towards using it.
Visually I’ve dropped the size of the `<h2>`s on this page so that
there’s enough difference between them and the big numbers. The idea of
the big numbers being big is to catch people’s attention as they scroll
down the page, by breaking up the rythmn.
The button was inheriting a green box shadow from the default GOV.UK
button style, which is typically used on a white background. On the blue
background, a darker blue shadow looks better I think.
The 15% darkening is the same as used by the default green button:
a3fe44e00e/stylesheets/design-patterns/_buttons.scss (L36)
Internet Explorer 11 and below don’t scale SVG images properly when
they’re used in `<img>` tags. See
https://gist.github.com/larrybotha/7881691 for details.
This manifested itself as the SVG images on the product page being
smaller when viewed in IE11 than other browsers.
This commit explicitly sets them the be 100% wide, which seems to fix
the problem.
Also reword some of the `<p>`s so that they flow better from the
headings.
This was a bit me, and a bit sitting down and hammering this stuff out
with Stephen and Sheryll.
This is the first step towards a fully-fledged ‘product’ page.
The needs for the top, blue section of the page are:
- what is Notify?
- can I use it?
- can I test it out?
- how do I create a log in
The needs for the next section of this page (which is the only one added
by this commit) are:
- how will Notify help me work?
- will it work with my service?
This commit shows 4 features of Notify on the home page which address
those needs. They are illustrated because:
1. We want to catch people’s attention – users are reluctant to scroll
on this page because they just want to click the ‘create account
button’. But we hypothesize that they will get on better
with Notify if they look at some of this stuff first.
2. The concepts that they’re talking about are hard to explain with just
words because they’re quite abstract. The illustrations help us be
more specific.
3. Feedback we got from user research was that the product page didn’t
give users any sense of what it was like to actually use Notify.
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.
The details of each notification were not being hidden on page load in
Firefox.
Firefox does not natively support the `<details>` element, so we
polyfill it.
Because of the way the polyfill is written[1]
1. There can’t be any `<div>` elements inside the `<summary>` (this
commit changes them to be `<span>`s instead, and adds CSS to make
sure they wrap as before)
2. The contents to be shown/hidden must be wrapped in a `<div>` (which
this commit adds)
***
1. 48fde82c72/public/javascripts/govuk/details.polyfill.js (L90)
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.
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.
It was a `<dl>` before which is kinda weird. Especially when the jobs
table was a real `<table>`.
It also means we can give it column headings so that new and invited
users have a better idea of what it is.
These numbers don’t look very clickable white-on-black.
Blue is the colour of links, so lets see if they are more clickable in
blue.
The same clicking-a-big-number thing is also happening on the activity
page, so this commit also changes the activity page to look the same.
The graphs of template usage feel a bit weird to me now.
1. They are counts of messages, but the numbers are very small
not big like we do everywhere else (eg the counts on a job)
2. There’s a lot of blue, especially for something that you can’t
click
This commit makes the numbers bigger and the bar chart grey.
The first column of a table is a heading, and will always be 50% wide.
It makes the table harder to scan when the information in the first
column breaks onto multiple lines, and introduces uneven whitespace in
the table.
This commit adds some CSS to force things in the first column to only
ever be one line. If they are too long to fit, they get truncated with
an ellipsis (`…`)
The first columns of our tables are always headings for the
subsequent columns, even though they go horizontally.
HTML has the `<th>` tag, which doesn’t just have to be used for headings
along the top of a table. So this commit changes the first column to be
a `<th>`.
This then allows us to style these elements differently, specifically
making them 50% wide. This makes pages like the dashboard align more
nicely.
It’s possible that users will have email and SMS templates with similar
names, and will send them depending on their users’ contact preferences.
So it’s useful to be able to compare how many emails vs SMS you’re
sending, even if the template names are similar.
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’
- adds a background colour, to words wrapped in `<code>` tags, like we
have for whole snippets of code
- reduces the font size of all code blocks
a) to differentiate them further
b) to fit more on the screen
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.
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.
This commit makes the ‘how to do placeholders’ box part of the tour,
with the same blue background.
It also adds some Javascript enhancement so that:
- it responds to the contents of the message template
- has a ‘show me’ link which inserts ‘Dear ((name))’ into the template
contents textbox
We’ve found that this has helped people understnad what placeholders
are, and how to do them.
In research we’ve seen users struggle with this. Often they’d type
((Joe Bloggs)) or ((XX/XX/XXXX)) instead of a sensible name.
Lets see if explaining it differently helps.
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.
