Our research and prototyping around ‘basic view’ found that:
- a lot of users who send messages rarely or never look at the dashboard
(yet it’s the first page they see when they sign in)
- team managers like the idea of taking away things that users don’t
need in order to make the interface simpler
We’ve disentangled the simpler way of sending messages from being part
of ‘basic view’. This means we can give managers the option of taking
away the dashboard as an independent choice, not something that’s
wrapped up in a separate ‘view’.
I think that this checkbox is a more straightforward proposition than
‘basic view’ ever was (despite all the work we did to explain it and
develop the nested checkbox pattern). In research users would often
explain the feature back to us as being about hiding the dashboard – we
should try to make Notify operate in terms of concepts that come
naturally to people wherever possible.
We’re going to make it possible for some users to be members of a
service, but not have any permissions (not even `view_activity`).
There are some pages that these users should still be able to see
These are the pages that a user with ‘basic view’ would have been able
to see, excluding those that let them send messages.
The one downside of skipping the template page is that you no longer
get such strong confirmation that you’ve picked the correct template.
You still see the preview of the template, but it’s further down the
page, and the name of the template has disappeared.
This commit adds the name of the template to the page title, to:
- have some continuity from the previous page
- make it easier to double-check you’ve chosen the correct template
If you only send messages then there’s no longer much point in the
template page. It now, for you, only has one action – ‘Send’.
This commit changes the journey for these users so they go straight from
clicking the name of the template to the page where you enter the phone
number or email address.
This is better because it reduces the number of steps a user has to
click through to send a message.
This journey is what we were previously calling ‘basic view’. But this
changes makes it automatically available to anyone who would benefit
from it. It removes the complexity of:
- having to opt in to basic view at a service level
- having to choose on a per-user basis who has basic view
- understanding the nuance between basic view and only choosing the
‘Send messages’ permission
Users who will still see the template page are:
- those who can edit templates – they need the ‘edit’ link
- users with the manage API keys permission – they need a place to get
the template ID
‘Upload recipients’ and ‘Send to one recipient’ have always been
slightly clunky phrases.
Now that basic view jumps straight into the ‘Send to one recipient’
flow there’s no way for users to get to the ‘Upload recipients’ flow.
By adding a link to it from the ‘Send to one recipient’ flow it’s
possible for users of basic view to access it.
But we don’t want to introduce too much inconsistency between basic view
and admin view because users will be migrating from one to another. They
might also be talking to their manager, who wouldn’t be able to tell
them where to click if they were looking at two completely different
interfaces.
This also means that we can keep the left-hand navigation in basic view
nice and simple with the two options (‘Templates’ and ‘Sent messages’),
rather than trying to introduce something like ‘Send one message’ and
‘Send lots of messages’ later on.
This is the existing behaviour. It’s broken by this issue in WTForms
2.2.1: https://github.com/wtforms/wtforms/issues/401
This commit hand-crafts the default value, because WTForms is ignoring
the `default` argument on the form object attribute.
Not really sure how this ever worked 🤔
There are some teams who send jobs on a daily/weekly basis. They have
team members who only use Notify for this purpose. So they would
probably benefit from basic view, because they don’t need to see the
dashboard.
This commit:
- adds a new item (uploaded files) to the basic view navigation for
teams that have sent at least one job
- makes the job pages visible to basic view users
I think we should do this now, rather than as a later enhancement to
basic view. We only have one chance to announce the feature, so teams
who do send jobs may otherwise discount it as not useful for them and
the opportunity to have them use it is lost.
This is better than just keying into the JSON because it means you get
an exception straight away when looking up a key that doesn’t exist
(which via mocking you could ordinarily miss).
Having the service floating about as JSON is a bit flakey. Could easily
introduce a mistake where you mistype the name of a key and silently
get `None`.
Also means doing awkward things like `if 'permission' in
current_service['permissions']`, whereas for users we can do the
much cleaner `user.has_permission()`.
So this commit:
- introduces a model
- adds a `.has_permission` method similar to the one we have for users
The list of services this page was looking at only included those not
belonging to an organisation.
On production this excludes services we’ve added to organisations to
make the management of those services easier (eg ‘GDS’ and ‘DVLA’).
Sometimes when setting up a service you might have a few very similar
templates, in which only a small amount of content. Or you might even
have a few of services, which are used by different teams but have
similar templates.
Copy and pasting, especially from one service to another, is a pain.
This commit makes it easier by allowing users to copy an existing
template when choosing to add a new one, instead of starting from
scratch.
At the moment the dashboard does two API calls to find out if a service
has:
1. Scheduled jobs
2. Normal jobs
API calls are slow because they are synchronous, go over the network and
touch the database. We can’t cache these API calls because:
- a scheduled job could become a normal job at any time
- the statistics on a normal job are constantly updating
However there are plenty of services which don’t have any jobs, and
probably never will. And finding out if a service has any jobs is
reliably cacheable (because as soon as a service creates its first job
it has some jobs).
So this commit:
- refactors the way we get scheduled/normal jobs into the job_api_client
to make the view a bit slimmer
- makes an additional, Redis-wrapped call to find out if any jobs exist
before trying to get the jobs
This should result in a speedup on the dashboard, and can be used in the
future if there’s anywhere else we want to show or hide something
depending on whether a service has created any jobs (I have some ideas).
From Karl:
> Templates – this should be consistent with Admin view. Users may
> switch from Basic to Admin view (or vice versa), they will also
> interact with users who have a different view or permissions to them.
> Neither should have to learn new interfaces and language if possible.
> ‘Send a message’ was a nice, active label – but Notify options aren’t
> usually actions. If we’re going to change this we should be consistent
> across both Admin and Basic views.
> For the same reason, I have rejected ‘see’, ‘search’ and ‘view sent
> messages’. It will be interesting to see in user testing whether users
> read ‘sent messages’ as ‘send messages’.
- name
- email
- phone number
- services
- last login
- failed login attempts if any
The view can be accessed from results of find_users_by_email
logged_in_at added to User serialization on admin frontend as
a part of this work
This included:
- creating a new form SearchUsersByEmailForm with validation
on its search field
- introducing 400 status to the view if the form does not validate
- fixing the POST request data structure in the tests (it was
incorrect before and uncaught due to lack of validation and mocking
the response from the API.
Commit 58cc1604a7 sanitises any non-ascii
characters in the headers. CSV filenames get used as a header value, so
this fixed a bug that occurred when non-ascii characters were used.
The CSV filename also gets used as part of the metadata when uploading
the file to S3. Since the S3 metadata can only contain ASII characters,
we also need to sanitise the filename before uploading it to S3.
Most people’s names, especially in government are in the format
firstname.lastname@department.gov.uk. This means that you can pretty
reliably guess that their name is ‘Firstname Lastname’.
When users are invited to Notify we know their email address already.
So this commit pre-populates the registration form based on this guess.
This is a nice little detail, but it should also stop the browser
pre-filling the name field with someone’s email address (which I think
happens because the browser assumes a registration form will have an
email field).
We had kept the original platform-admin page at `/platform-admin` and
created a new page, `/platform-admin-new` for the new platform admin
page. Now that the numbers on both pages look ok we no longer need both
pages, so can replace the original page.
One of the big things we found in user research was that people were
uncertain what the effect of giving someone basic view was.
So in the spirit of ‘show don’t tell’, this commit adds a way for users
to preview basic view. They can go into the preview and click around as
much as they like, just as if they really had the basic view assigned to
them.
Once they have seen enough they can return to the settings page where
they can decide whether or not to switch basic view on for real.
Since platform admins can use the new settings page, this commit:
- links to that page
- removes the platform-admin-only endpoint that switches basic view on
and off
This commit adds radio buttons to the ‘basic view’ page. This will let
users choose whether basic view is on or off for their service.
As before, this page will only be linked to if a service already has
basic view, so this commit does not launch the new feature.
This commit adds:
- a row to the settings page…
- …which links to a page explaining what basic view is
The new row (and link) will only appear for services who already have
the feature switched on. This is because we are not launching the
feature yet, so it shouldn’t be available to just anyone.
We are not consistent about this. We use ‘manage service’ on:
- the page listing all the users
- the request to go live checklist
We use modify service on:
- the page where you edit a team member’s permissions
- the page where you invite a new team member
This commit changes the latter to be consistent with the former.
‘Caseworker’ was a bad name because it:
- suggested that Notify might be expanding into case management
- may or may not map to someone’s actual role, in a confusing way (this
is why ‘manager’ is also a bad name)
‘Basic view’ is the best name we could come up with because:
- it describes the purpose of feature, not the user
- a ‘view’ changes what you can _see_ as much as it changes what you can
do
Admin remains a good word – in research users self-describe their use
of Notify in using it. This commit makes the name ‘admin view’ to match
‘basic view’.
This also means we can hide the legend for this fieldset because the
choices are self-explanatory.
