To match the call to action on the template page.
Karl said:
> I feel good about it. You're not really editing it so much as choosing between 2 options. It feels more human.
>
> I think it only started out as edit to match all the other sections of the letter – it certainly wasn't given any real consideration.
It’s a bit rudimentary to only show the current place in the hierarchy
and the parent. You lose a sense of how deep you are.
But we can’t just show the full path, because it can be arbitrarily
long. So what this commit does is show the full path, but truncates the
display of any items. Further-up than the current folder or its parent.
This also helps disambiguate between folders and templates, because
folders are always shown with the folder icon.
This probably won’t affect many teams, because we don’t anticipate a lot
of deep nesting.
We already have a pattern for navigation folders and searching for
templates – let’s use it for the copy page too. And I reckon we can
represent services as folders if the user has multiple services they
could copy a template from.
It’s confusing to have one way of adding things when your service is new
(green button) but a different way once you’ve added your first thing
(the new grey buttons).
For services that have a `edit_folders` permission, this commit
standardises on the grey buttons for a consistent experience.
so that they better align with the front-end, where they'll be used in
data attributes. Also, making the kebab case is nice because it doesn't
give favouritism to either JS or python naming conventions
Since we’re letting users add new folders directly from the choose page
it makes sense that they should also be able to add templates from
there.
This resolves the problem we saw in user research where people found it
hard to know where to go to add a new folder when they were all behind
one green button.
Since you can now see them when searching you should also be able to
select and move them. Which means that they needed to be included in
the `Form`’s list of possible choices of things to move.
The Jinja template for the ‘choose templates’ page is now pulling in
data from a lot of diparate places in order to work out what to show. As
we add more logic about what to show (in order to make the live search
work) it’s going to get harder to have all this logic in the Jinja
template.
This commit refactors it back into Python where we have more language
features for managing complex logic.
It’s a bit weird to call this file a model, in that it’s dealing with
some presentational logic, rather than just data. Conceptually it’s more
like a view model[1].
1. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
It was looking at the count of items at the root level (because it was
passing `parent_folder_id=None` as an argument).
This changes it to look at the total count of items for a service (which
was the intended behaviour).
In multiple user research sessions we’ve noticed people edit the
auto-generated template name to put something at the end of it.
This is fiddly because of the quotes we put around the name:
> Copy of ‘Exiting template’
It also means that if they keep our prefix then the template doesn’t
sort alongside the one it’s replacing.
This commit changes the name of copied templates to better match the
behaviour our users are showing.
Also adds a bit of auto numbering, just as a nice detail.
This commit adds logic to:
- take the list of selected folders and templates
- split it into two lists (of folders and templates)
- `POST` that data to the API, to effect the movement of said folders
and templates
I’ve tried to architect it in such a way that we can easily add more
template ‘operations’ in the future, as we add more forms to the choose
template page.
This commit adds:
- checkboxes to let you select a template or folder
- radio buttons to let you select where to move those template(s) and/or
folder(s) to
It only does the `get` part of this work; handling the `post` and
calling API will be done in a subsequent commit.
It would be quite easy to dissociate the search box from the things its
supposed to be searching.
This commit adds assertions to make sure that the things the search box
is targeting are on the page
This means we can have a method on the service model which hits the API
(or Redis) but can be called multiple times (within the context of a
request) without making multiple network requests.
It does this by storing the results of the method on the object’s
internal `__dict__` the first time the method is called.
We were taking letters away from basic view because there’s no one-off
sending of letters.
But now that basic view isn’t an opt-in thing but something we’re
rolling out to all users who only have the ‘send’ permission it feels
like too drastic a change to remove letters.
It’s too jarring to go straight from the list of templates to the upload
addresses page. So while we don’t have sending a one-off letter as a
thing, let’s keep the template page.
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.
If you have a lot of services it’s hard to find the one you’re looking
for if the sort order is a mixture of `created_by` and which ones belong
to an organisation.
Since the templates within the services are sorted alphabetically it
makes sense to also sort the services alphabetically.
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
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.
