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.
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
The heading structure of most pages is incorrect (`<h2>` followed by
`<h1>`). The `<h1>` indicates the main purpose of the page, the service
name (currently the first `<h2>`) doesn't need to be a heading.
> If both sections of the page have errors and the page is submitted,
> focus moves to the mobile numbers section so screen reader users may
> not be aware of preceding errors - focus should move to a dedicated
> error summary at the top of the page.
Right now we use Javascript to focus the first error on a page (if any
errors are found). This commit adds more JS to then focus the error
summary, if there is one on the page. So this is where the focus will
rest.
It also makes some modifications to the ‘dangerous’ banner to make it
focusable, and to visually indicate that it is focused.
We didn’t have an element with an `id` of `content` on the product page
because we didn’t want the styles that come with it (from GOV.UK
Elements here: d6226bd2c8/public/sass/elements/_layout.scss (L9-L20))
This meant that the skiplink didn’t work on the product page because
it’s target was not on the page. The skiplink’s target is hardcoded to
point at `#content`.
The proper way to fix this would be to not hardcode the skiplink to
point at `#content`, ie what this pull request does:
https://github.com/alphagov/govuk_template/pull/275
Until that is merged, we can hack around the problem by overriding the
styles that Elements applies to `#content`, which is what this pull
request does.
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”
The ticks and crosses on the team page are served bigger than actual
size (128×128px). They are then resized using CSS3 `background-size`
to their displayed size (19px).
The reason for doing this is so they display crisply on retina screens.
IE8 doesn’t support `background-size` (see
http://caniuse.com/#feat=background-img-opts). This means that the ticks
and crosses get show at their original size (way too big).
This commit adds resized versions of the ticks and crosses which are
then served to these older browsers only.
We grey-out the non-current step in the tour so the user knows whether
they’re at step 1, 2, or 3.
This is done using CSS opacity.
IE8 doesn’t support the standard CSS opacity syntax. But it does support
the weird, old, Microsoft-specific `filter:` syntax. So this commit:
- makes the greying out a class rather than an inline style, to reduce
duplication
- adds the filter syntax so the greying out works in IE8
We have a bunch of helper classes (bottom gutter) which are used to
vertically separate components on the page.
This vertical spacing might get ignored if one of these containers
contains floated items. This is because:
> elements that contain floated items don't take those floated items
> into account in calculating their height
– https://css-tricks.com/containers-dont-clear-floats/
GOV.UK Frontend toolkit has a shim to prevent this from happening.
d15e738b92/stylesheets/_shims.scss (L38-L55)
So this commit uses that shim to make the spacing consistent in older
and newer browsers, irrespective of whether floats are being applied.
This hasn’t been a problem because we’re not using a lot of `float` in
Notify. But we are using it now to work around some other
inconsistencies in old browsers.
We use flexbox to lay out the counts of sending/delivered/failed on the
activity and job pages. flexbox makes the best use of the space when
the numbers can be significantly different widths (eg 0 sending, 5000
delivered).
Flexbox was only supported from IE 11 onwards [1]. And since we were
setting the `display` property of the individual numbers to `block` they
were rendering one-per-line on browsers that don’t support flexbox.
This commit changes these items to be floated and a predefined width. In
browsers that support it, flexbox seems to override these hard-coded
widths. It’s not quite as good as the flexbox solution because:
- it doesn’t adjust the widths in the nice way that flexbox does
- it’s hard-coded to expect 4 items (we don’t have this component with
any other number of items at the moment, so it won’t actually break
anything)
But it’s pretty much OK because:
- it’s a lot better than the before
- IE 8 and 9 combined only make up 5% of our users, and this will be a
declining number
- polyfilling flexbox would mean using Javascript, and we don’t serve
working Javacript to IE 8 users anyway
1. http://caniuse.com/#feat=flexbox
Skewing the letter results in a bunch of slightly-off-vertical diagonal
lines. This is a bit visually jarring when everything else on the page
lines up vertically or horizontally.
This commit makes the bottom half of the letter straight, by offsetting
it instead of transforming it. The ‘fold’ now has depth, so it has to
be drawn in somehow, that’s what the `:before` is doing.
This might be taking the skeumorphism too far (especially with the
animation). But it’s a way of indicating that the letter will ‘unfold’
if you click it. Might revert this, but let’s see how it feels.
Users might wonder why they can’t see the whole letter. We should make
it obvious that it’s because the letter is folded. We can use CSS to
draw the bottom half of the page behind the top half. With some
transforms this makes it look like the letter is actually folded.
It’s a bit skeumorphic but:
- I think it achives the desired effect
- the way we show emails and text messages is also mildly skeuomorphic
The letter previews take up too much space on the page (more than a
typical email or text message). This means that users have to scroll too
much.
When we send the real letters they will be folded in half to fit in the
envelope.
So by showing the letter previews on the page cropped to half the
letter’s height:
- it reduces the need for scrolling
- it gives an accurate preview of how the letter will be delivered
This is acheived without hard-coding any heights by using a little-known
quirk of CSS, namely that padding set as a percentage is calculated from
the width of the element, even for top/bottom padding. This means that
we can always set the ratio of the displayed letter to be A4 folded in
half – the square root of 2.
Non-outlined text requires the correct font to be installed to display
properly.
Outlined text is the shapes of the letters converted to vector, so it
doesn’t need any font installed to display.
Since we don’t have the right fonts installed on the boxes yet, this
will make things look better.
‘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)
The PDF preview is all good, but it’s hard, finickeity and feels dirty
to embed a PDF in a web page. It’s a more natural thing to embed an
image in a web page.
So this commit adds another endpoint to return an image of a letter
template. It generates this image from the PDF preview, so the stack
looks like:
1. `template.png` (generated in admin)
2. `template.pdf` (generated in admin)
3. HTML preview (generated by a `Renderer` in utils)
4. `Template` instance
5. serialised template from API
6. Template stored in database
The library used to convert the PDF to an image is Wand[1], which binds
to ImageMagick underneath. So in order to get this working locally on a
Mac you will probably need to do:
`brew install imagemagick ghostscript cairo pango`.
To get it working on Ubuntu/EC2 is an exercise left to the reader…
1. http://docs.wand-py.org/en/0.4.4/
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.
This addresses part of the ‘is Notify dependable’ group of needs.
The ones it specifically and partially addresses are:
- is it reliable
- how is it supported
There’s more to come in this section, we’re doing this bit now because
it’s a nice conclusion to the page.
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.
This is part of the new header style that Tim, Stephen et al have been
working on.
This means that we lose the feedback link, so I’m trying out having it
in the top right.
