Since we added the end time picker:
- we have discovered that broadcasts can’t be longer than 24h
- we have observed that most users confuse picking the end time for
scheduling the message, or don’t understand exactly what it means for
the broadcast to ‘end’
- we’ve developed the concept of ‘training mode’, which you should be
going through before sending a real broadcast
We also think that, for most scenarios, you won’t necessarily know when
a broadcast should end at the time of starting it because the cause of
the danger is not within your control. So giving you control of the
end time before the broadcast has even been approved is a confusing
distraction.
Having to pick a time at all also makes the whole process feel more
planned and less immediate. Whereas in reality all the phones in the
area will be getting the message in seconds. It’s only people coming
into the area later to whom the ‘ongoing’ aspect of the broadcast
applies.
The best place to explain what’s happening with the phones is at the
approval stage and once you’ve sent your first (training mode)
broadcast. It’s easier to explain what’s happened if it’s in direct
response to something you’ve just done.
Later on we should add some kind of email reminder after 12 hours to
make sure you still want the broadcast live, again after 18 hours, etc.
We could let you schedule an end time once the broadcast is live, but
don’t think there’s a strong need. Knowing enough that you want to
cancel is one thing, but knowing enough to want to cancel but wanting to
wait a bit… nah.
We recently introduced a form control that lets user choose when a
broadcast ends.
Based on the most recent research participant, we think:
- there is a specific misunderstanding of what this control does
- there is a general low level of understanding of what a ‘broadcast’
means
People will try to understand what a ‘broadcast’ is by using mental
models they have for other kinds of messaging, for example text
messages.
Other kinds of messaging are one-to-one, i.e. they go from a sender to a
recipient. They are not ongoing in any way.
Emails and texts are sent at a time (and for all practicable purposes
are received at that same time). So, when we present the user with
a form that controls time, they might well assume it controls the time
when the message will be sent.
This is a feature we offer for sending messages using a spreadsheet, and
that’s where we’ve borrowed this pattern from.
We reinforce this assumption with the labelling of the form control. By
front-loading it with the word ‘When’ we are playing to the users
confirmation bias, i.e. they are interpreting the meaning of the control
in a way that confirms their prior beliefs about how messaging works.
So this commit does two things:
- re-labels the form to front-load the word ‘End’ not ‘When’
- adds text to the page explaining when the broadcast will start, so
there’s a chance of overriding that confirmation bias
If we can get users to go through this before sending a broadcast for
real, it could help them learn what a broadcast is, and how it differs
from sending text messages.
Different emergencies will need broadcasts to last for a variable amount
of time. We give users some control over this by letting them stop a
broadcast early. But we should also let them set a maximum broadcast
time, for:
- when the duration of the danger is known
- when the broadcast has been live long enough to alert everyone who
needs to know about it
This code re-uses the pattern for scheduling jobs, which has some
constraints that are probably OK for now:
- end time is limited to an hour
- longest duration is 3 whole days (eg if you start broadcasting Friday
you have the choice of Saturday, Sunday and all of Monday, up to
midnight)
We don’t want one person going full yolo and start broadcasting without
any oversight. This commit changes the flow so that the button on the
‘preview’ page puts the broadcast into `pending-approval`, rather than
directly into `broadcasting`.
This commit removes the code the puts areas into the session and instead
creates and then updates a draft broadcast in the database.
This is so we can avoid session-related bugs, and potentially having a
large session when we start adding personalisation etc.
Once a broadcast is ready to go it is set to `broadcasting` straight
away with no approval. We’ll revisit this as we learn more about how
users might want to manage who can create and approve broadcasts.
The tests are a bit light in terms of checking what’s on the page, but
clicking through the pages is probably good enough for now.
Gives them some colours, borders and stuff to make them visually
consistent with the rest of Notify.
The idea is the tags and polygons have a similar affordances (i.e.
border thickness, colour) to visually link them and imply that they are
two representations of the same thing.
These are just so we have some pages to click through for now. They
don’t use real templates, or any of the broadcast stuff from the
database.
But I think it’s useful to get some skeleton pages in first so that we
can see the map etc working in production, then build on that, without
having to do it all in one mega PR.
For that reason there are two short term things I’ve done in this commit
which should be revisited soon:
- no tests for the endpoints
- data about which areas are selected is stored in the session
