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.
Let users create/edit/delete letter templates.
Let them upload a CSV file or send a test against a letter template.
Big assumption at the moment is that addresses only have one line, and
therefore one column in the CSV file.
The yellow banner didn’t make this information much more noticeable,
and it made some people miss the request to go live link because it
wasn’t blue.
This commit brings the design back to where it was as of this PR:
https://github.com/alphagov/notifications-admin/pull/904
This is trying to resolve these confusions:
- that you’re in trial mode, which means you can’t have a live key yet (
or you can but it wont work, which is what we used to have)
- what does simulate mean
The create key page is the right place to resolve these confusions
because it’s where users are actively reading.
This commit also removes the trial mode banner from API integration
page because this where users _aren’t_ actively reading. A whole bunch
of users weren’t seeing this banner at all.
The implementation of the disabled API key options is kinda clunky
because WTForms doesn’t have a native way of doing this.
¯\_(ツ)_/¯
Fixes the height of the component until it’s loaded so that it doesn’t
causes the page to reflow while it’s rendering the buttons.
Stops the options being shown and then immediately hiding on initial
page load.
Categories before:
> Now, today, tomorrow, Friday…
Categories after:
> Now, later today, tomorrow Friday…
This reduces the ambiguity of ‘now’ vs ‘today’, and keeping the word
‘later’ suggests what this features is about.
This implementation here is a bit hacky, but it works…
The options for scheduling a job by time should be grouped by day,
because a long list of 96 options is not very usable.
On the server side, this commit generates label for the next 4 days in
a friendly format (ie today/tomorrow/Sunday/Monday)
The Javascript component for choosing a time was built in a kind of
old-school jQuery way, where it manipulated the elements on the page.
The complexity of introducing groups of options was just too much for
this pattern, because it involves storing a lot of state in the DOM.
This commit completely rewrites the JS to:
- read the initial options and groups from the HTML and store them
in the object
- use Hogan to completely re-render the UI from a series of Mustache
templates, each of which represents a state of the UI and takes the
inital options and groups
- filter the choices to show when the today/tomorrow/… buttons are
clicked
The polyfill we use for details/summary only renders the arrow if the
browser doesn’t natively support the feature.
The latest versions of Firefox _do_ now support the feature (after 5
years), but for some reason they don’t draw the arrow. So this commit
forces the arrow to be polyfilled in all browsers, and hides the browser
default one, for those browsers that do render it.
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)
