alphagov / finder-frontend

Serves finder and search pages for GOV.UK

Finder Frontend

Renders search on GOV.UK:

• Site search is available from the header of every page.
• Finder pages provide facetted searching over a collection of documents.
• Most of these pages support subscribing to email alerts.

Live examples

• gov.uk/aaib-reports
• gov.uk/drug-device-alerts
• gov.uk/government/case-studies
• gov.uk/government/people
• gov.uk/world/organisations
• gov.uk/international-development-funding

Nomenclature

• Finder: Page containing a list of filterable documents and filters.
• Facets: Metadata associated with documents. See app/models/*_facet.rb for examples.
• Filters: Searchable/filterable metadata for example case_state={open|closed} for a CMA case.
• Parser: Transforms API responses into model objects.

Technical documentation

This is a Ruby on Rails app, and should follow our Rails app conventions.

You can use the GOV.UK Docker environment or the local startup.sh script to run the app. Read the guidance on local frontend development to find out more about each approach, before you get started.

If you are using GOV.UK Docker, remember to combine it with the commands that follow. See the GOV.UK Docker usage instructions for examples.

Running the test suite

# run all the tests
bundle exec rake

# run only feature tests
bundle exec cucumber

# run only JS tests
bundle exec rake jasmine:ci

Further documentation

See the docs/ directory for manuals and instructions.

Licence

MIT License

finder-frontend's Issues

Invalid date feedback

Right now, if a User enters an invalid date, nothing happens at all. It would be good to introduce a validation error to tell the user that the value entered isn't a date.

Add a README

Search - iterative improvements

What

As part of this PR this search interaction was reviewed in a holistic way. Some suggestions below:

Search iterative improvements

Issue	Potential Fix
The button on mobile, aren't buttons but links which impacts WCAG 1.3.1	These could be updated to buttons however the overall Design would need be adjusted also
	Review font weight across views
	Update Accordion Design to match updated version, impacting WCAG 3.2.4
	Increase size of mobile copy
	Align search input swap to component

Why

Improve Accessibility and consistency

Toggle functionality should be using a button

'Show more / fewer search options' toggle is an anchor element, and should be a button element as it's not a link to anywhere.

Code in question is in _facet_collection.html.erb

<a href="#" class="facet-toggle" data-controls="facet-wrapper" data-expanded="false" data-track-category="filterClicked" data-track-action="accordion" data-toggled-text="- <%= t("finders.facet_disclosure.fewer", default: "Show fewer search options") %>">
  + <%= t("finders.facet_disclosure.more", default: "Show more search options") %>
</a>

Dependabot can't resolve your Ruby dependency files

Dependabot can't resolve your Ruby dependencies.

As a result, Dependabot couldn't update any of your dependencies.

This could have been caused by a git reference having been deleted at the source, by an out-of-sync lockfile, or by a bug in Dependabot.

To help diagnose the issue, please try running bundle update --patch locally. If no errors occur, get in touch and we'll help dig into it.

You can mention @dependabot in the comments below to contact the Dependabot team.

Use of aria-live inconsistent across www.gov.uk search results

Pages that display search results with filters in a left-hand column do not identify the summary information consistently to assistive tech'.

Overview

When JS is enabled, the search results on these pages are updated by AJAX.

The change in the page content needs to be announced to users of assistive tech'. This is done by setting aria-live on the results summary paragraph but the value it is set to is not the same across www.gov.uk.

The implementation of the live-region is also slightly different for the search page compared to the policies page.

What needs to be done

One value should be chosen for the aria-live attribute and make it the same everywhere.

The implementation is also slightly different on the search page. Both pages should be made the same.

Note: work done on this a while ago was documented in this excellent blog post.

Pages owned by finder-frontend

The pages I've found of this type (there may be others) are:

1. https://www.gov.uk/government/publications
2. https://www.gov.uk/government/consultations
3. https://www.gov.uk/government/statistics
4. https://www.gov.uk/government/announcements
5. https://www.gov.uk/government/policies
6. https://www.gov.uk/search

5 & 6 are owned by this app. I've raised another issue for this on 1-4.

Why is `enable-aria-controls.js` needed?

A question in #2519 by @owenatgov asked why do we have a script https://github.com/alphagov/finder-frontend/blob/main/app/assets/javascripts/modules/enable-aria-controls.js that applies an aria-controls attribute to an element, when this could be applied directly in markup?

Looking through the code, this module appears to only be called once, by the date filter component. This partial is passed a value for the aria-controls attribute by the date_facet template, which the date filter then passes through to the input component.

This is all used to create the date inputs in the filters on the search page. If you look, they have their aria-controls attributes set to the main search area, so that when users update those fields there is that association to indicate to users that the main search results have been updated.

Setting aside the question of the value of aria-controls I'm still left a bit confused what all of this is for. I thought maybe aria-controls was only being applied when JS was enabled, but it also seems to be there when JS is turned off.

I put some logging into my local version and the script is initialised on the search page but doesn't appear to then operate on any elements. I repeated the test using the previous jQuery version of the script and got the same result.

I'm left with:

• the script was intended to apply aria-controls only if JS was enabled, but somehow that got changed at some point
• the script acted on something else that has since been removed
• a third option that I've missed 🤔

cc @leenagupte

Keywords not currently displayed in search description

This means you can type a keyword and it doesn't show up in the search description, although the results do update.
Fix would involve doing some facet/preposition wrangling in order to put it into the frontend.

_reset.scss causes surprising behaviour for <strong>

Currently it's necessary to write: <strong class="govuk-!-font-weight-bold">text</strong> instead of just <strong> [exampe]. This is due to a global reset rule, which means we have to add per-element overrides where the default style for the element conflicts with the imposed reset style.

Apparently we used to add reset.scss to projects in order to provide a foundation for cross-browser compatibility [1] [2]. However, the approach seems to be unique to this app (and Whitehall), possibly because we now do it on a per-component basis [example]. It's unclear what effect removing the resets would have.

We should investigate where we're relying on these resets in this app, and apply them in exactly those places, so that the global resets on each element can be safely removed.

Cucumber tests are not being run in CI

These were accidentally disabled in May (see here). This means we could be deploying breaking changes without knowing. We should get these tests running again in CI ASAP.

An initial attempt at this reveals 24 failing tests, which all need fixing before we can actually enable the tests in CI. Hopefully these failures are all test issues, and don't represent broken functionality.

Incorrect message for Irish checklist criteria

Pointed out by a user on Twitter. "You plan to Ireland"

I believe this is the source:

finder-frontend/lib/checklists/criteria.yaml

Line 204 in 0a6208a

text: You plan to Ireland

Transition email topic is out of date

I just subscribed to the transition check email and got this:

Looks like this needs an update:

finder-frontend/app/controllers/brexit_checker_controller.rb

Line 57 in 7aa6970

"title" => "How to prepare for a no deal Brexit",

Update site search to share code with finders

Search was a straight port from frontend in #313. There's some tech debt (duplication) to refactor out:

• Checkbox filters switched to option select component (see #374)
• Switch site search to use live_search.js and remove live_site_search.js – an older version of the script
• Use the same mustache template
• Use the same base layout and styles
• Use search component for search box

Application components not rendering correctly

Logging this last thing on a Friday in case I forget. I just noticed that the components in finder-frontend don't appear to be rendering properly in the component guide (see below), although they seem to be okay in the rest of the application.

I've only been able to test this locally as the live finder-frontend component guide isn't online at the moment.

e.g. the expander component:

Retail checkbox doesn't affect actions page

If I run a business, and I select that it operates in the retail sector on the final question, the following string is appended to my URL

retail-wholesale-x-food-drink-motors

which doesn't appear at all in actions.yaml. This means it has no effect on the results page or action items that I view.

`<mark>` elements in search results can be invisible in Windows High Contrast Mode

Description of issue

If you use https://www.gov.uk/search with Windows High Contrast Mode (HCM) enabled, your search results will have invisible words.

Affected systems

This happens in Edge, Chrome, and IE11 on Windows, when using Windows HCM with a dark theme.

This doesn't happen in Firefox.

Cause of issue

The finder frontend styles uses <mark> elements to wrap the search query in search results, but styles them to have a transparent background colour:

finder-frontend/app/assets/stylesheets/finder_frontend.scss

Line 30 in 009fa63

mark {

In forced colour modes such as HCM, the browser will will ignore the CSS colour properties, and use the default colours, except for the alpha value of the background colour ¹. This means that the mark will be forced to have a yellow background and black text, except the background will be transparent. With a black background this becomes black text on a black background.

Suggested fix

The tech-docs-gem had a similar issue and fixed it in alphagov/tech-docs-gem#265 by using the CanvasText colour, which is respected in forced colour modes.

Footnotes

1. https://bugs.chromium.org/p/chromium/issues/detail?id=1253295 ↩

Browser back button on the search page does not correctly reset history state

First example

1. Search for something eg “education”
2. See results for “education”
3. Search for something else eg “environment”
4. See results for “environment”
5. Hit browser back button
6. I now see results for “education”, but the search box says “environment” (when I would expect it to say “education”)

Second example

1. Search for something that returns results eg “education”
2. Type something into the search box that won’t return results eg “foobar” BUT DO NOT SUBMIT THE FORM
3. Filter by organisation
4. I see no results
5. Click browser back button
6. I do not go back, but I would expect to return to my previous results
7. Click browser back button again
8. I’m not out of search altogether

Setup details

Mac OS X Sierra 10.12.4
Chrome 57.0.2987.133

Respect metadata facet ordering

Finder schemas define facets in a meaningful order, that should be preserved when displaying metadata for a result. (Example of schema ordered facets)

This order is changed (slightly) by finder-frontend. They'll be re-ordered so all text metadata fields are displayed first followed by date fields (but maintaining their order within those groups), eg:

This is cased by https://github.com/alphagov/finder-frontend/blob/master/app/models/document.rb#L48, and I think it should be as simple as refactoring the metadata code to loop over all facets, selecting the display method by type, instead.

This would match the longer term plans of introducing Metadata models, which could be of different types, eg date or text.

Remove cache content check from readiness probe endpoint

The cache readiness probe should be removed from the /healthcheck/readiness check.

We should export the status of connectivity to memcached and search-api as Prometheus metrics rather than as healthcheck.

Readiness probes should tell us whether a pod is ready to serve requests, and should not check their dependencies.

GOV RFC 141 incorrectly states:

If an app can't talk to a backing service it relies on, then it probably can't be trusted to handle any requests.

This is untrue since application should be expected to degrade gracefully, and an external dependency may not be required for all request paths. For example, this app can serve the /search homepage without the Search API being reachable, and can serve all requests if the memcached instance is down, and will degrade gracefully if Content Store is unavailable.

We should not be causing cascading failures by healthchecking an app's dependencies.

For instance, if memcached is unavailable this app cannot be started in Kubernetes.

Still Add a ReadMe

Please. Because I just looked quickly and my brain's like:

"Why's it called finder when all the filenames seem to be about email/alerts notification?
I'm looking for Search tools, is this something I might use? "

I have little idea.

Missing Filter for GOV.UK Search

Note

• I've noticed a small bug on search where the Search disappears complete when changing the Browser's window from desktop to mobile, back to desktop.

Video

missingfilter_min.mov

Search facet's / pills not removable

The facet / pills / tags are not currently removable. They get added correctly but interacting with them to remove has no effect and throws a JS error.

SassC-Rails upgrade - support CSS `min()` and `max()`

Replacing

gem 'sass-rails', '~> 5.0'

with

gem 'sassc-rails', '>= 2.0.1'

results in errors that (I think) are to do with the conflict between CSS's max() and Sass's max().

SassC Rails uses SassC Ruby, which uses Libsass. Unfortunately, Libsass doesn't currently support CSS min() and max() - issue 2701.

Slightly strange is when SassC Rails is used the app runs fine with no errors, but the tests fail. This might be to do with some gems still relying and installing on Ruby Sass, such as GOV.UK Publishing Components (just updated in v16.7.0) and the deprecated GOV.UK Frontend Toolkit.

The error thrown is:

Error: "calc(0px)" is not a number for `max'

The Sass function also doesn't like having calc() added to it, since calc() will only work in the browser. Sass can't compute percentages, since they rely on knowing the window width - for example: calc(100% - 1em) can only be worked out when you know how big 100% is.

This is triggered by the width container element in GOV.UK Frontend:

@supports (margin: unquote("max(calc(0px))"))

When the library supports CSS min/max, the unquote function ensures that this is output as CSS instead of being processed as a Sass max function.

Solutions:

• Wait for Libsass support (No longer an option as Libsass is deprecated)
• Use Dart Sass which already supports CSS min and max - but I haven't been able to find a Rails-friendly way of doing that
• Use Webpacker to use Webpack to compile the CSS. This would mean making sure that all JavaScript and CSS dependencies are JavaScript modules rather than gems. See Ticket 505 on GOV.UK Publishing Components.

Is hidden search 'Skip to results' link in the right place?

The GOV.UK search has a hidden link Skip to results shown on focus. I'd like to query if it's in the right location on the page / working as expected.

I think it used to be placed at the start of the filters. Now it appears to be right next to the results:

If the purpose is to save keyboard only and screen reader users the pain of tabbing through a bunch of things - I don't think we're helping much as it's so close to the results. I think it used to be before the filters themselves where it saved a bunch of tabbing.

Use .bind

@edds has put a bind polyfil into the frontend-toolkit (https://github.com/alphagov/govuk_frontend_toolkit/blob/master/javascripts/vendor/polyfills/bind.js)

This is a nice alternative to using $.proxy which we are using here, or sometimes we're using that = this or sometimes anotherVariableName = this. So let's make it consistent (and better!) by using the polyfil.