[Systers-dev] A sample use case
Robin Jeffries
robin at jeffries.org
Wed May 5 22:03:04 PDT 2010
Comments in []s are meant to be meta comments, not part of the use case.
Enjoy. I picked this one because a) it is core dlist functionality, and b)
I thought it would be very small and simple. Of course, they never are :-)
Robin
*
*
*Unsubscribing to conversations*:
*User scenario:* Janie has just joined a mailing list that uses dlists and
is going through the settings, setting up her options. After reading about
how dlists work, she decides that she would like to get all incoming
messages till she indicates that she is no longer interested in a
conversation. She makes that choice on the settings page. A few weeks
later, a conversation starts which wishes the moderator happy birthday.
After about the 10th "+1", "me too", Janie has had it. She remembers there
is some way to "turn off" this conversation; she figures out how that works,
and shuts off the flow of content-free messages to her mail box.
*Actors*: Janie (mailing list subscriber), list moderator, mailman process,
email client [yes, computer processes can be actors in use cases]
*Workflow:*
A. setting dlist options [if we were further along, you might just point to
another use case that covers this]
- go to list settings page [we sort of assume here that she starts on
this page; presumably there is another use case that covers getting to the
settings page]
- The second setting is "subscribed to new conversations". She reads the
help for this option. Sounds like what she wants is Yes. She checks it [do
some thinking about whether the wording will be clear, given that Janie
probably doesn't know that there are mailing lists that have this option and
may not be clear to her how the system knows that two messages are in the
same conversation. Is she likely to understand this? If she doesn't, which
is she likely to select -- yes (the default) or no?]
- She scrolls to the bottom of the page to click Submit My Changes [will
she think to do this? Probably in this case, where she is doing her account
setup, but would she if she were changing just one option?]
B. unsubscribing to a conversation
- Janie looks at the bottom of the email that was the final straw. She
sees the following:
To unsubscribe from this conversation, send email to <systers
+foo+unsubscribe at systers.org<systers%2Brepresentati%2Bunsubscribe at systers.org>>
or visit <http://systers.org/mailman/options/systers
?override=9999&preference=0<http://systers.org/mailman/options/systers?override=2934&preference=0>
>
To contribute to this conversation, use your mailer's reply-all or
reply-group command or send your message to
systers+foo at systers.org<systers%2Brepresentati at systers.org>
To start a new conversation, send email to
<systers+new at systers.org<systers%2Bnew at systers.org>
>
To unsubscribe entirely from systers, send email to <systers-request at systers
.org> with subject unsubscribe.
- She's pretty clear that the first link is what she wants. She clicks
on the first link, which creates an email message in her email client to
that address [will all email clients do that? What might go wrong?].
- ???Does she click send immediately or does she enter text into either
the subject line or the body? What would she enter? [here we are a little
unclear on the most likely user action. Best to express our uncertainty at
this point, and make it more crisp when we have some data or when we have a
design that we are pretty sure resolves the issue or makes it work for all
variations. We know now that we need to consider what she has typed into
the message. Just for fun, and because I happen to know that this is what
many people do, let's assume she puts a subject of 'unsubscribe' and then
clicks send] [notice that this important step goes on outside of mailman and
in a program we can't control]
C. mailman processes the email Janie sent [it's easy to describe the
current behavior, as it is the behavior of a computer, and we can test it to
see what happens. Of course, in many cases, we don't have the program
written, so we are still describing desired behavior; in this case the
current behavior will lead us to understand that we want something better,
though it doesn't tell us how to fix it]
- mailman processes the headers of the incoming message
- mailman identifies this as a message to be posted to an existing list,
but possibly containing administrative requests (like unsubscribe)
- mailman sends this to the moderator queue for approval
- the moderator (who knows that this happens all the time) approves the
message (possibly several hours later)
- mailman then hands this off to the dlists module (because of the second
+ in the to:address) which sees it as a conversation unsubscribe, and
updates the database (using Janie's from: address) so that Janie won't
receive any more messages sent to that conversation.
[notice that the flow I describe is based on her putting unsubscribe in the
subject line. We get a different flow if she leaves that blank ]
D. Another message is sent to the happy birthday conversation
- [I'm going to be lazy here, for lack of time, but we need to cover how
mailman determines that some people, including Janie, don't get this
message. This might lead to more detail being required in step C -- it
certainly would require more detail if we were working out how these
conversation unsubscribes were managed in the database]
* Variants to consider*
- what if Janie gets the digest?
- how confident are we that Janie will figure out how to turn this off?
What else might she try? What can go wrong?
- what if Janie leaves the subject line and the body blank? Or writes
"get me out of here" for the subject?
- there are actually two ways to do the turn-off-messages part: via email
and via the web. Work through the other one
- a day later, someone else on the list tells her that this conversation
turned into a fascinating discussion of how CS can be very ageist (treat
people who are getting older very badly). Janie wants to see these messages
and contribute to the conversation. What should she do? [several factors
to consider -- reading missed messages in the digest, turning the message
spigot back on, replying]
[you should spend some time both writing down the variants you need to
consider and thinking about how they complicate things and how they will
work. If any of them seem like they introduce interesting new things to
consider, you ought to write them out as full use cases, but often just
listing them as variants is enough. I would work through the digest one,
turning off via the web and turning conversations back on, based on my
knowledge of dlists and mailman]
To contribute to this conversation, send mail to <systers-dev+sample at systers.org>
More information about the Systers-dev
mailing list