A few of note
Count in list of live services - this should be set to no in the API (to
be implemented) so we never show broadcast services in the list of live
services to reduce security leaks
Organisation - all broadcast services are currently going to be found in
a single organisation so we keep track of them easily. Therefore there
is no need to allow the changing of the organisation
Email authentication - we may in time not allow these services to use
email auth to log in but this hasn't been decided so let's keep it for
the moment
Rate limit - although a service may end up using our API to create
broadcasts, there is currently no rate limit check on this endpoint
and it's also extremely unlikely that any service would ever breach
the default limit
This stops the 'inset text' linking to the design system on the
'edit-and-format-messages' page. The link has been removed to avoid
confusion - someone thought they needed to use the design system
code in order to create inset text in templates.
Add more spacing between characters for billing reference number and PO number, so they are easier to read.
Also remove unnecessary autofocus.
Co-authored-by: Chris Hill-Scott <me@quis.cc>
As per ticket and as per Caley's request, so everything can be
edited together.
Also pluralise labels for billing contact info, to indicate
that putting multiple in is ok, and widen the input fields so
that it is more comfortable to input multiple contact details.
Broadcasts created by the API are different in that:
- they aren’t created by any user, so don’t have a `created_by_id`
- they are created instantly, not in steps, so don’t have an
`updated_at` time
This commit alters the views to account for when these pieces of
information aren’t present.
The following were added without the macro ever
being called:
- app/templates/views/add-service-local.html
(added in
e6f49825e5)
- app/templates/views/service-settings/data-retention/edit.html
(added in
4b8b571a87)
- app/templates/views/organisations/organisation/settings/edit-domains.html
(added in
936883bf7b)
The following were used when they were first added
but not removed when the macro stopped being used:
- app/templates/views/edit-letter-template.html
(macro removed in
20ae200de9)
- app/templates/views/organisations/organisation/settings/edit-agreement.html
(macro removed in
45526598c6)
Includes changing the code so that the radios
aren't split into two columns in the HTML present
when the page loads. This layout is now added by
the JS.
At the moment the admin app expects all broadcasts to have a template,
and expects the content of the alert to come from the template.
This commit makes it so those pages can still get a `Template` instance,
but populated with content straight from the `content` field in the
database.
We think that in some cases alerts will be composed in the moment, and
therefore making people first create a template is:
- not a good use of their time
- adding some conceptual complexity which they don’t need
This commit makes it possible to type some words and have them go
straight into the `content` field in the database.
In the future we might want to progressively enhance the radio buttons
so they show on the same page (like we do with the grey buttons on the
templates page).
The content length message was making the page jumpy and causing reflows
in three ways. This commit addresses each of those ways:
As the user scrolled
---
The footer went from fixed to sticky and the spacing around the message
changed. This change in spacing was needed so that the message looked
right in both contexts.
I think the best way to resolve this is to not use the sticky footer
when editing text message or broadcast templates.
On my 1440×900 screen I can fit a 5 fragment text message, plus the
‘will be charged as 5 text messages’ message, plus the save button.
Our top 10 screen resolutions according to our analytics are:
Position | Resolution | Percentage of users
---------|------------|--------------------
1 | 1920x1080 | 27.37%
2 | 1280×720 | 11.07%
3 | 1366×768 | 8.88%
4 | 1536×864 | 5.79%
5 | 1440×900 | 4.52%
6 | 1600×900 | 3.71%
7 | 1280×1024 | 3.10%
8 | 1680×1050 | 2.42%
9 | 1920×1200 | 2.33%
10 | 2560×1440 | 1.99%
When the page first loaded
---
The message is empty so takes up no space, then the javascript fires
and inserts the message, taking up a line of space.
This is resolved by making the empty message take up space with a
non-breaking space character.
When the user first typed
---
We previously didn’t show any message until the user started typing.
This meant that, with the above fix, there was a larger than normal
empty space between the textarea and the save button.
This is resolved by always showing the message, even when the user
hasn’t typed anything yet.
***
These are design decisions which made sense when the message was
displayed along side the button, but we’ve had to change now that the
message is above the button.
We feel that this is more appropriate because it’s part of the
information you’re agreeing to before you hit submit.
Sometimes users can missing information that doesn’t start left-aligned
to the column they’re interacting with.
It also makes it closer to the Design System component.
We’re keeping it in the sticky footer, so that it’s always visible no
matter where in the message you’re scrolled to (this means you won’t
have to edited to content then scroll down to check whether you’ve
made it fit).
This looks tidy, and because of the sticky footer it means the message
is always visible, even if your template is quite long. So no matter
where you’re scrolled to in the template you don’t have to scroll to the
bottom to see the count update.
