Files
notifications-admin/app/assets/stylesheets/main.scss

91 lines
2.6 KiB
SCSS
Raw Normal View History

// Path to assets for use with file-url()
$path: '/static/images/';
// Dependencies from GOV.UK Frontend Toolkit
2015-11-23 13:50:37 +00:00
// https://github.com/alphagov/govuk_frontend_toolkit/
@import 'conditionals';
@import 'shims';
@import 'measurements';
@import 'css3';
@import 'colours';
@import 'typography';
@import 'grid_layout';
@import 'helpers';
2015-11-23 13:50:37 +00:00
// Dependencies from GOVU.UK Frontend Toolkit, rewritten for this application
@import 'url-helpers';
// Specific to this application, needs to go at the top of the cascade
@import 'globals';
// Dependencies from GOV.UK Elements
2015-11-23 13:50:37 +00:00
// https://github.com/alphagov/govuk_elements
@import 'elements/helpers';
@import 'elements/reset';
@import 'elements/details';
@import 'elements/elements-typography';
@import 'elements/forms';
@import 'elements/forms/form-multiple-choice';
@import 'elements/forms/form-validation';
@import 'elements/lists';
@import 'elements/panels';
@import 'elements/tables';
// Dependencies from GOV.UK Frontend, packaged to be specific to this application
@import './govuk-frontend/all';
// Custom overrides
.govuk-link {
font-weight: bold;
}
// Specific to this application
@import 'local/typography';
2015-12-17 10:18:31 +00:00
@import 'grids';
@import 'components/site-footer';
@import 'components/placeholder';
@import 'components/sms-message';
@import 'components/page-footer';
@import 'components/table';
@import 'components/navigation';
@import 'components/big-number';
2015-12-17 14:05:35 +00:00
@import 'components/banner';
Enhance message textbox by styling placeholders 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
2015-12-20 00:00:01 +00:00
@import 'components/textbox';
@import 'components/file-upload';
@import 'components/browse-list';
@import 'components/email-message';
@import 'components/copy-to-clipboard';
@import 'components/vendor/previous-next-navigation';
@import 'components/radios';
2019-02-27 15:44:52 +00:00
@import 'components/checkboxes';
@import 'components/pill';
@import 'components/show-more';
@import 'components/message';
@import 'components/research-mode';
@import 'components/tick-cross';
Add a page to manage a service’s whitelist Services who are in alpha or building prototypes need a way of sending to any email address or phone number without having to sign the MOU. This commit adds a page where they can whitelist up to 5 email addresses and 5 phone numbers. It uses the ‘list entry’ UI pattern from the Digital Marketplace frontend toolkit [1] [2] [3]. I had to do some modification: - of the Javascript, to make it work with the GOV.UK Module pattern - of the template to make it work with WTForms - of the content security policy, because the list entry pattern uses Hogan[1], which needs to use `eval()` (this should be fine if we’re only allowing it for scripts that we serve) - of our SASS lint config, to allow browser-targeting mixins to come after normal rules (so that they can override them) This commit also adds a new form class to validate and populate the two whitelists. The validation is fairly rudimentary at the moment, and doesn’t highlight which item in the list has the error, but it’s probably good enough. The list can only be updated all-at-once, this is how it’s possible to remove items from the list without having to make multiple `POST` requests. 1. https://github.com/alphagov/digitalmarketplace-frontend-toolkit/blob/434ad307913651ecb041ab94bdee748ebe066d1a/toolkit/templates/forms/list-entry.html 2. https://github.com/alphagov/digitalmarketplace-frontend-toolkit/blob/434ad307913651ecb041ab94bdee748ebe066d1a/toolkit/scss/forms/_list-entry.scss 3. https://github.com/alphagov/digitalmarketplace-frontend-toolkit/blob/434ad307913651ecb041ab94bdee748ebe066d1a/toolkit/javascripts/list-entry.js 4. http://twitter.github.io/hogan.js/
2016-09-20 12:30:00 +01:00
@import 'components/list-entry';
@import 'components/live-search';
@import 'components/stick-at-top-when-scrolling';
@import 'components/fullscreen-table';
@import 'components/conditional-radios';
@import 'components/vendor/breadcrumbs';
@import 'components/vendor/responsive-embed';
@import 'components/preview-pane';
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765
2018-08-23 14:15:16 +01:00
@import 'components/task-list';
@import 'components/loading-indicator';
@import 'components/area-list';
@import 'components/content-metadata';
@import 'views/dashboard';
@import 'views/users';
@import 'views/api';
@import 'views/product-page';
@import 'views/template';
@import 'views/notification';
@import 'views/send';
@import 'views/get_started';
@import 'views/history';
// TODO: break this up
@import 'app';