The tour teaches you how Notify works by letting you do a thing and then
showing you the effect of the thing you’ve just done – a text message on
your phone.
This is not as effective if you don’t get the text message quickly. It
breaks the association you make between what you’ve done on the computer
and what’s happening on your phone.
Slow text message delivery can happen if you’re doing a big job. We can
get around this by making your text message use the priority queue.
This was observed in the pilot research session yesterday.
We have a bunch of different styles of handling when function
definitions span multiple lines, which they almost always do with tests.
Here’s why an argument per line, single indent is best:
- cleaner diffs when you change the name of a method (one line change
instead of multiple lines)
- works better on narrow screens, eg Github’s diff view, or with two
terminals side by side on a laptop screen
- works with any editor’s indenting shortcuts, no need for an IDE
Also, trailing comma in the list of arguments is good because adding a
new argument to a method becomes a one line, not two line diff.
The test for non-gov.uk domains adding services is still relevant, but
probably makes more sense in `test_add_services.py`.
The others are no longer relevant now the ‘All services’ page has gone.
We reckon that:
- a ‘blank slate’ templates page is a better start
- the example template hurt more than it helped when it comes to
understanding placeholders
_The code for this is quite hacky and light on tests. But I’d really like to get
it in the app for the research tomorrow to see how well the feature works._
This commit changes the tour from being a set of static screens to some help
which guides you through the process of sending your first test message.
The theory behind this is that what users are really struggling with is the
concept of a variable, rather than the relationship between the placeholders and
the column headers. And like learning to program, the best way to learn is by
taking an example and modifying it to your own needs.
This means that when someone adds their first service we set them up an
example email template and an example text message template. Then there is a
guided, three step process where _all_ the user can do is send a test message to
themselves.
Once the message is sent, the user still has the example templates which they
can edit, rather than having to remember what they’re supposed to be doing.
When you add a new service, it’s probably the one you want to do stuff
with.
When you get invited, the service you’ve been invited to is probably the
one you want to use.
This commit adds the ID of the new service or service you’ve been
invited to to the session.
There’s no content in the tour that’s specific to a service. And since
we can now take a pretty good guess at what service you last used, or
which service we should send you to if you only have one service,
there’s no need to make the URLs for the tour service-specific.
This also means that you don’t need to be logged in to see the tour
pages, and we have no good reason to only restrict these pages to users
with accounts.
https://www.pivotaltracker.com/story/show/116960703
We were using a bunch of different styles for form error messages,
including:
- having the name of the field in the error, or not
- can not/cannot/can’t (GDS content styleguide recommends using
contractions)
This commit adds a 3 screen tour, similar to those used on GOV.UK Verify
and Passports.
We guerilla tested this on Friday, and it really helped users to build a
mental model of how Notify works, so that when they’re playing around
with it they have a greater sense of what they’re aiming to do. This
makes concepts like templates and placeholders click more quickly.
https://www.pivotaltracker.com/story/show/116710119
of the name against a list of all service email_from fields.
Update find_all_service_names to find_all_service_email_from, which returns the email_from of all services.
Without the preview service name we probably have to go back to communicating
a bit more on the add service page. This commit brings back the two bullet
points about where the service name will appear, and tries to tie it into the
nice words that Matt Sheret wrote for us.
This page:
- confused users in research
- didn’t communicate what it was intended to (eg the generated email address,
how your service name would appear in messages)
This commit removes the page so that after typing in the service name the user
is sent straight to the dashboard for their new service.
This commit adds a new page, which appears after a user enters the name for
their new service. It shows how the service name will appear in emails and
text messages.
This means that the new service is not created until after they have confirmed
that the name is appropriate in context.
This has also involved:
- visual changes to the ‘email template’ pattern, which wasn’t very refined
before
- removing a bunch of words from the enter service name page, because most users
don’t read them, and we reckon that showing a preview is a better way of
getting them to understand what is meant by service name
Still to do:
- validating the the generated email address for a service is unique (on the
API) side
- having the API return the generated email address, rather than determining it
in the admin app
This commit adds a new page, which appears after a user enters the name for
their new service. It shows how the service name will appear in emails and
text messages.
This means that the new service is not created until after they have confirmed
that the name is appropriate in context.
This has also involved:
- visual changes to the ‘email template’ pattern, which wasn’t very refined
before
- removing a bunch of words from the enter service name page, because most users
don’t read them, and we reckon that showing a preview is a better way of
getting them to understand what is meant by service name
Still to do:
- validating the the generated email address for a service is unique (on the
API) side
- having the API return the generated email address, rather than determining it
in the admin app
Because the redirect after logging in checks the number of services a user has,
this now needs to be mocked.
Right now this means adding `mock_get_login` to any tests that need a login.
This must be one of the first mocks, so that it can be overridden by any use
of `mock_get_services`, for tests that specifically want to rely on a quantity
of mocked services, or their contents.
This is a bit fragile, but there’s already a TODO in the code to make it better
so ¯\_(ツ)_/¯
This commit moves user-related navigation into the proposition header (the black
bar) at the top of the site. It adds some custom SASS to override GOV.UK
template and align these navigation items to the right (because it looks
better).
It then removes the service chooser dropdown (and its associated SASS and JS) in
favour of a link alongside the user-related navigation items. ‘Switch service’
is the best language for this that we’ve come up with so far.
This means that the only way of adding a new service is from the `/services`
page. So this commit removes the redirect if you land on this page with only one
service (else it would prevent you from ever being able to add more).
This page is exactly the same as the page for adding your first service, save
the heading text.
So all this commit does is:
- set up two routes (`/add-service`, `/add-service/first`) for each of the two
journeys and change the existing journeys to use the `/add-service/first`
route
- add logic to show different heading text depending on the journey
- add a link to the new (`/add-service`) route in the service chooser dropdown
Fixed the is_active() method on the Users model, if the user was pending they would come back as active, allowing a user to sign in before being active.
There is still a problem with the validate_sms_code and validate_email_code method.
