https://www.pivotaltracker.com/story/show/113448149
This commit adds a query string to assets URLs which is generated from a hash
of the file contents. When asset files are changed they will now be served from
a different URL, which means they wont be loaded from browser cache.
This is similar to how GOV.UK template adds its version number as a querystring
parameter for its assets.
This is mostly copied from Digital Marketplace utils:
https://github.com/alphagov/digitalmarketplace-utils/pull/102
They have it in a shared codebase, we only have one frontend app so don’t need
to do that.
Usage in a template:
``` jinja
{{ asset_fingerprinter.get_url('stylesheets/application.css') }}
```
Output:
```
static/stylesheets/application.css?418e6f4a6cdf1142e45c072ed3e1c90a
```
https://www.pivotaltracker.com/story/show/112786779
> There's an emerging convention on admin apps, to have a red strip atop the
> page, also to have a different colour for preview environment... so let's
> adopt that and see how it feels. Red for prod and gold for preview.
This commit adds config so that:
- yellow locally
- orange on preview and staging
- red on live
It will not actually work until each AWS environment uses the right config, but
can be tested locally by setting the environment variable manually, eg:
`export HEADER_COLOUR='#F47738'`
Banners should always be the first thing on the page.
Because headers already have padding we don’t want to put padding on the
container.
So banners should also have top padding to distance then from the red bar.
They should also sit in the 3/4 column if the page has side navigation. This
commit adds a new template (`withoutnav_template.html`) which extends
`admin_template.html`. All views then extend one or the other, never the
`admin_template.html` directly. This means that `admin_template.html` doesn’t
have to make decisions about where the flash messages are displayed.
There’s an argument to be made that the beta label should only apply to
the public-facing parts of services/platforms.
Removing it from here means that we don’t need to deal with the hassle of how it
fits into the navigation. If we have to bring it back then we could follow the
banner example here instead:
http://govuk-elements.herokuapp.com/alpha-beta-banners/#beta-banner
This commit moves user-related navigation into the proposition header (the black
bar) at the top of the site. It adds some custom SASS to override GOV.UK
template and align these navigation items to the right (because it looks
better).
It then removes the service chooser dropdown (and its associated SASS and JS) in
favour of a link alongside the user-related navigation items. ‘Switch service’
is the best language for this that we’ve come up with so far.
This means that the only way of adding a new service is from the `/services`
page. So this commit removes the redirect if you land on this page with only one
service (else it would prevent you from ever being able to add more).
A previous commit removed these to differentiate between this page and the
manage templates page. It turns out that we do want previews on this page
because:
- the users for the two pages might be different—they might only be allowed to
do one or the other depending what permissions they have
- it’s useful to see what the placeholders in the message are before uploading
a CSV, to make sure the CSV has the correct column headings
This commit re-adds the message preview with a simpler UI. Discussed with
@antimega and we both agreed that the speech bubble tails on the messages should
go.
The previous service switcher was built purely in Javascript, which meant that,
for the purposes of progressive enhancement, it had to load in the open state.
Setting it to the closed state with Javascript happened a fraction of a second
after page load. This caused an unpleasant flicker as the whole page shifted up
and down as it loaded.
This commit changes the switcher to use the native HTML5 `details` and
`summary` elements[1].
This commit adds a polyfill from GOV.UK Elements for browsers which don’t
support `details`/`summary`.
1. http://html5doctor.com/the-details-and-summary-elements/
This page is exactly the same as the page for adding your first service, save
the heading text.
So all this commit does is:
- set up two routes (`/add-service`, `/add-service/first`) for each of the two
journeys and change the existing journeys to use the `/add-service/first`
route
- add logic to show different heading text depending on the journey
- add a link to the new (`/add-service`) route in the service chooser dropdown
This is a link not a button because:
- it’s less prominent—delete is an infrequent action
- it’s a two-step process, and only the second part changes any data (so it has
a button)
- by default, the menu is open
- if Javascript is enabled/loaded, the links are hidden, and visual cues (▶) to
show that it can be opened are added
- clicking it opens and closes it
This macro:
- accepts a WTForm form field as a parameter
- renders a form field which follows the GOV.UK Elements patterns, both visually
and in markup terms
It then changes any page which uses either:
- the old, non-WTForms macro or
- the old, WTFforms `render_field` macro
…to use this new macro and removes both of the old ones.
It also adds the option to display hint text above the textbox.
Found a way to create the token that does not need to persist it to the database.
This requires proper error messages, written by people who speak menglis good.
Submit form was
- a confusing name in itself
- not descriptive, because it also has an optional ‘back’ link
This commit also puts this component in as many pages as possible, stripping
out any hard-coded buttons and links.
It replaces any usage of buttons for ‘back’, because these are links, not
buttons (ie they don’t change any data).
Users can add placeholders to their messages, eg
> …your vehicle ((registration number))
when the message is sent, this gets replaced with the data the user uploads, eg
> …your vehicle LC12 BFL
We reckon that it will be useful to see that the placeholder has been
recognised, ie that its syntax is correct, before uploading any data.
We reckon that the best way to do this is by styling it differently to the rest
of the text that the user types.
This is not a trivial problem. There are two possible ways to do it:
1 Write a Google Docs-style text rendering engine, which completely replaces
the native HTML `<textarea>` with a custom control, and programme what should
happen when the user types something that looks like a placeholder, or
presses an arrow key, or makes a selection, or…
2 Leave the `<textarea>` in place, unmodified, and duplicate layers in front
of/behind it to visually replace a placeholder with the blue lozenge
Unsurprisingly, this commit implements 2.
There are four layers. Each layer contains live-updated copy of the text in the
textbox, and each is styled differently:
- one layer behind the textbox to make the blue background
- the textbox itself
- a layer with the white text, which overlays the black text of the textbox
- a layer with an inner shadow to knock back the brackets
This is because of some interesting limitations:
- The text in the foreground and background must occupy the same physical space,
so no deleting characters from the duplicated layers
- Words can’t be split up into multiple elements,
eg `<span>((</span>regist…`:—this results in slightly different kerning to
`((regis…`, which messes up the alignment of the layers
- The textbox can’t be completely overlapped with a block of colour, because
the cursor disappears behind it. Trying to edit text when you can’t see the
cursor is hard.
Implementation
Technically this makes use of Paul Hayes work on Javascript modules in the
GOV.UK frontend toolkit[1].
It also makes use of the `oninput` event to detect changes to the textbox’s
contents. This is much more performant than `onkeydown`, `onpaste`, etc. Without
it the delay between user input and the layers all updating is too slow and you
see misalignment of the layers.
1. https://github.com/alphagov/govuk_frontend_toolkit/pull/227
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
Main thing that was missing was including the main CSS file in the template.
There are a few hacky bits here, like moving the whole of toolkit inside the
stylesheets directory.
Would arguably be cleaner using something that isn’t Flask Assets, but that’s
something for later.
