Use cases: verschil tussen versies

Versie van 24 okt 2015 om 21:41

To be added is a activity diagram of user behaviour in the unified modeling language based on these use cases.

At any of these stages the user might need help or want information about what the site is about, who is behind it etc. Can be found in the footer.

These use cases required the following screens.

The system sends out these e-mailmessages which are numbered in these use cases.

The most common use case is the one of a user signing a petition. Here follows a breakdown.

User finds petition

• user gets an e-mail (1) with a direct link to the shared link of a petition (mostly by e-mail, mentioned in the news, through social media, or a web search)
• heard about the petition, but does not know the exact name or link (most likely to first use web search)
• a minority of users lands on the home page first and browses or searches to find petition. The list of active, new or big will bring most to the petition they look for
• future release we can show tweets about new petitions on the new petitions view to encourage people to follow our twitter account to get updates about new petitions
• some users do not look for a petition, but are issue driven. After a web search on the issue they end up on a petition page about the issue
• some users are searching the web for something unrelated (like the name of a signatory) and are distracted by the petition, some of those even sign

User signs petition

• once on the petition page, user reads the introduction on top (summary of what the petition is about)
• scrolls through the petition text and reads/scans it a bit (formal wording, in order to be taken serious and understood well by recipient of petition)
• request to sign follows the user while scrolling down, it asks (only) for name, place of residence and e-mail address
• as input in the form an e-mail address is required, the name field should receive at least a character, a space and a character as input
• to appear publicly on the web as signatory for this petition an opt-in checkbox needs to be validated
• the user signs by clicking ‘yes, I sign this petition’
• immediately an error message appears (page does not reload) above that same button to sign the petition if there is anything wrong with the input, instructing what to fix. The problematic input fields get a thick red box around them, in small print it says in detail what is the problem for each field. A user can not sign one petition twice with the same e-mail address. But the error message can not be used to check up on people to see if they have signed (privacy!).
• if there are no errors in the input the button disappears and a ‘checked’ icon appears with a thank you message; "Thank you, your signature only needs your confirmation. On $e-mailaddress$ you receive an e-mail (2) from info@petities.nl with Please confirm in the subject line. Otherwise, just sign again."
• User goes to mailclient or opens webbrowser for webmail and looks for the message.
• Below the Thank you it also says: "Also check your spam mailbox if you can not find it. Without confirmation your signature does not count.” Also when the address has already been used to sign, the message appears. An explicit suggestion to consult the help section, ‘More help’ ends the sentence. Sending e-mails to those who already signed is a bit tricky, because our system should not allow abuse. A stalker can be really annoying like this. Each e-mail that is sent should therefore have an opt-out, for either the particular petition or all e-mails from petities.nl.
• While waiting for the confirmation mail, user already shares the petition on social media using the bar with share icons because a line in the Thank you message says. "You can share this petition using $subdomain$.domain as link." where the word share links to an anchor in the sharing bar a bit lower. The icons are not communicating with third parties because they do not show how many times it was shared. Perhaps in a future release, using the opt-in social media approach.
• User also receives confirmation e-mail (2) if (s)he already signed, but with the same confirmation link as before (to make sure one can not sign more than once)

User confirms petition

• In the e-mail (2) a button appears that only needs to be clicked on. Below the button also the actual link is mentioned for copy pasting in the address bar.
• User clicks on button or the link below it, browser opens.
• The link without the code or an incomplete, corrupted should give a page where the totally clueless can paste or type the link. Especially civil servants and bank employees have problems clicking on a link, their system does not allow them, to prevent trojan horses.
• Wether user has already signed or not, the confirmation link is sent. The link to the confirmed signature if that is the case, to prevent multiple signatures per e-mail address.
• On the confirmation page at petitions.eu/signature/uniquestring (English) or petities.nl/ondertekening/uniquestring (Dutch, legacy) more information is asked. Some is required, depending on the type of petition. The confirmation page is basically the ‘start a petition’ page, just different fields. Instead of ’Start a petition’ it says ‘Confirm your signature for petition ‘$namepetition$'. On the left are the input fields, on the right is the explanation about each input field. Next to the field ‘place of residence’ a box might appear asking if they would like to get invited by the city to participate more and in other ways. This appears only if the city signed a contract/subscription for this service with us. If so, below the input field ‘place of residence’ a check box appears for ‘Yes, let $City$ invite me’.
• Users can opt-in to subscribe to three e-mail (5) newsletters about the petition. The word e-mail is in bold, so that people do not confuse the checkbox with agreement with the conditions or a similar convention.
• Above ‘the fold’ (without scrolling) the user already sees a button ‘confirm my signature’, but this will lead in most cases to the same button below all the information to confirm, but with an error message about certain required fields. This is to avoid that people miss the confirm button because they do not scroll down. Petitions that do not ask for any more information than just a name are confirmed by just following the link (after all, we got all we need already). The page still appears, but the buttons appear as ‘update my data’ and on top of the page the tekst ‘Confirm your signature for petition ‘$namepetition$' is replaced with 'Thank you $namepetitioner$ for confirming your signature for petition ‘$namepetition$'
• Below the lowest ‘Confirm my signature’ button there is an info box, just like the one with info for a petition. A quick summary with: date and time of signature and e-mail address (with the words ‘more information’ and then ip-address, computer os, browser, etc are displayed.)
• When no confirmation in a week, then one friendly e-mail (3) reminder. Plus one friendly e-mail (4) reminder a week before the petition closes. Again with the usual opt-out options in the e-mail.
• Future release: After confirmation the option 'remember my information for __ days to sign other petitions with just one click' puts data from all fields in a cookie that will autofill when you visit another confirmation page.
• Future release Signed anonymously but with description? Then e-mail asking if this anonymous was the intention (6).

User invites to sign and shares signature

• Once confirmed, then below the summary of the signature data in this box an extra line appears with date and time of confirmation (and ‘more information’). Below that also ‘Last updated on’ appears, as the two above.
• The e-mail address can be changed here, by clicking on a word 'change' after the displayed e-mail addres. Then the e-mailaddress can be changed. A new confirmation link is sent by e-mail (6) and the address of this confirmation page changes (otherwise there is no check of the new e-mail address), but the old address still also appears as the one the signature is confirmed with (this is for cases where the link to the page ends up in other hands).
• If newsletters are sent to the signatory an extra line appears with "x out of 3 newsletters received: date and time, date and time, date and time. Currently subscribed/unsubscribed." (in a future release each date will be clickable, leading to the newsletter).
• Below the details of the signature and confirmation data there are ways to invite others to also sign. A box appears with a default invitation text (only when confirmed!). It can be copy-pasted or e-mailed by inserting e-mail addresses (or uploading an address book or any file with text in it). As default addressee of this invite the e-mail address of the signatory him/herself is shown with a checkbox after it.
• User invites others to sign by uploading some file which is then scanned for strings that look like an e-mail address. "Upload anything, we try to extract e-mail addresses from it and then we delete it." These appear in a row above the box with the invitation text. Just like what already showed with just the address of the signatory, but then more addresses. Max 100 per batch.
• Users clicks away the addresses that should not get an invite.
• Users clicks the button 'Send invitation' and receives an e-mail (7) listing the e-mail addresses that have received an invite. Explaining that the user can upload this e-mail in the future when inviting (again) (for another petition). In the e-mail is a suggestion they should save it as text. The e-mail (7) is sent with a week delay (or 7 to 1 day before the petition closes, whatever comes first), with the suggestion to check if invitees have signed and to think about who else to invite.
• Below the e-mail invite options there are the usual sharing options. It is important they share not the location of this confirmation page, but the address of the petition. Important that one can only e-mail invites after confirmation, otherwise our system might be abused by spammers.
• The signatory can look up their position in the list of signatures, it has a link. Each page of signatures has 100 signatures (to remain consistent with the legacy links of the current lists, which should continue to work) and also each page has a unique link. If signatures are deleted the number of signatures on that page just gets less, the page numbering does not change.
• The link to the specific signature in the list of signatures can be shared from the signature in the list (there is a little icon called 'link' for that), but also from the invite part of the confirmation page. Inside the default e-mail message a link to the signature is suggested and in the ‘details’ of the signature on the confirmation page is given.
• This link will be shared on social media using the buttons on the confirmation page since right next to the list of signatures there is a link to signing the petition. When someone shares this link on Facebook there should be a preview of the list of signatures with the icon image of the petition as teaser. When the social media icons for this page load, no data goes to or comes from third party websites because the number of shares is not counted/shown. Perhaps in a future release using opt-in social media.

User responds to invitation

• user receives an e-mail (1) with a request from a signatory to also sign (name, e-mailaddress and link to signature are included)
• user follows link and signs (see user signs petition)

The following is for a future release

• user follows link to 'not now, I sign later', webpage opens 'we will remind you by e-mail (8) to sign next week or just before petition closes'
• user follows link to 'no, because...

1. I need to know details, but do not have time
2. in general I support it, but this petition has some weaknesses
3. Please stop all invitations for petitions on this address: $address$

• when invited and user signed, then an 'invited by' line in the 'details' on the confirmation page with a 'thank you' option which sends an e-mail (9) 'thank you for inviting, I signed, see my signature here'.

User indicates extra support

• User can indicate how to help more, choosing a few options from a pull-down menu. Last option in the list 'I have more to offer then I can indicate, let the petitioner e-mail me'. (10)
• User can contribute with a donation for something the petitioner chooses from options: "I donate |pull-downbar| to hire a... /journalist/lobbyist/communication specialist/legal consultant/graphic designer/photographer/filmmaker/" they click away what they do not like. With pull-down bar choice between 1, 5, 10 or 25, "We approach you by e-mail when enough donations were promised." After the pull-down bar is set to anything. (11)
• A signatory can indicate willingness to buy a t-shirt/banner/sticker/mug/etc about the petition "I would like to buy... |pull down bar|" (12)

User wants to do something

• on confirmation page a signatory can indicate willingness to help out doing something
• journalist can interview me as an experience expert/victim
• carpool when going to a meeting with other signatories
• I have a place to organise meetings
• I can organise a meeting for signatories
• I would like to attend a meeting to meet the other signatories
• I am a member of a political party and can vote there
• I can write a text (op-ed)
• I can talk in public (classroom, court, counsil, rally, demonstration)
• I can talk for the camera or microphone
• I can ask people in public to sign
• I can set up a table in a shopping centre or other public place
• I would like to help out staffing a table in public
• I can carry out a stunt
• I can show up as a member of a crowd
• I can verify if there are no bogus, suspect or famous signatories that go unnoticed
• user receives e-mail (10) when the time has come for the indicated action

User starts a petition

• a user comes to our website directly (having signed a petition there once) or after a websearch about starting a petition
• xor lands on the homepage after a web search or directly goes there or ends there after signing/browsing petitions: for those there is a big button 'start a petition'
• a small number of users get inspired while they are on the website (a link in the new footer should be included)
• user finds the button 'start a petition' or the link in the footer
• user lands on start a petition page and finds a list of input fields with a description for each next to it (or under it, on smaller screens)
• title is text input, introduction is text input, addressee is one pull down menu with 8 kinds, with one selected, a second pull down menu appears with the appropriate actual choices.
• when a field is left empty, a warning appears below the submit button and the problematic areas of the form get a red rectangular
• the organisation field is optional
• user uploads a picture which should be in landscape format future release the picture can be cropped to fit the required shape
• user enters name as petitioner and/or organisation etc. If petitioner wants to be anonymous, name and e-mail can be changed after confirming petition.
• after each change in the form the user can choose 'update', so nothing is lost if user leaves page

User confirms a new petition

• user does not follow the link in the e-mail sent to confirm their user account, then e-mail reminder follows a week later: in it 3 weeks time is given, when no action within 4 weeks after creation, the attempt is copied into an e-mail, sent and the petition attempt is deleted from the database, not the user (could have another petition going). Users without petitions are deleted.
• user follows link to petition received by e-mail (address from users.email)
• user improves text of petition, changes picture for a better one
• optionally changes e-mail address (petitions.petitioner_email) and anonymises name (petitioner_name) which has no consequences for users.email and users.name
• when ready to go open presses the button 'publish'
• message appears that moderation will take a few minutes, perhaps a day. To alert us to come online leave a voicemail, which will reach us the fastest.
• in the same message, the user is encouraged to fix spelling while waiting for the moderator to 'open' the petition

User manages/improves petition

• future release: every 100 or 1000 signatories and petitioner receives a robot phonecall, just one ring (to make sure petitioner fills in phone number)
• petitioner receives e-mail with recommendations on how to improve petition
• petitioner receives e-mail when petition reaches date for hand over of petition to addressee and is asked to choose from: 1. change the date 2. organise the hand over 3. revoke the petition
• petitioner changes date of hand over after login on petitions page
• petitioner receives e-mail when there are 'notifications' about certain signatures: vandalism, famous people signing etc.
• petitioner receives statistics about performance: how many signatories, growth compared to other petitions, etc.
• petitioner communicates with signatories who indicated they are open for this, they ask admin for help. In Future release a messaging system and archive of messages between petitioner and signatory. Only signatories can reach petitioner.

User hands over petition

• petitioner chooses to hand the petition over, petition status changes to_process, petition remains signable. When petitioner tries to do it without (m)any signatures and/or within a week after publishing the petition, then only admin receives a message. Fix this or confirm that it was correct.
• e-mail with petition and stats about signatures goes to addressee (cc to admin), including suggestion to join us and open a free account, sent from subdomain@ourdomain with the name of petitioner in From-line.
• when addressee clicks on link in e-mail they can (only!) change the date for the hand over and add a unique identifier the petition got in their own (postal) system. When they reply by e-mail the admin does this manually. Addressee is asked to call + e-mail petitioner to explain the hand over process and such formalities.
• Petitioner is asked to write an update about the hand over (when and where) with the information received from the addressee about it which will appear under the petition. And call addressee when they did not call.
• The petition and list of signatures is e-mailed on the day of the hand over as PDF and the petition closes and the status changes to in_process. The closed petition will show a time stamp of the hand over, the status 'in process' and 'awaiting due date for answer'. Also it says that the process of the petition will be monitored and that the next steps will be: indication on how petition will be treated, date of answer to petition, plus the answer.
• All signatories receive an e-mail (12) about the hand over, that the process until the answer will be monitored on the petition page, how many have signed, where from, how many anonymous, the petition text again and a link to their personal confirmation page to hide their signature.
• Addressee receives at 8:00 the morning after the hand over an e-mail with the question what will be done with the petition and when. A list of options appears in the e-mail.
• Addressee can reply by e-mail or follow unique link to choose the option in a pull-down menu.
• Reply of addressee on how petition will be treated appears next to petition. With the text 'awaiting answer'.
• When addressee does not reply, automatically the same message is sent every two weeks, with reference to all the previously sent messages.
• Once the date is reached as indicated, an e-mail goes out to ask what the outcome was of how the petition was treated. A list of options appears in the e-mail. Addressee can reply by e-mail or follow unique link to choose an option in a pull-down menu and write text in a text window.
• This answer will be published next to the petition and the status changes to 'concluded'.
• The answer to the petition is sent to all signatories of the petition after review by admin. In that message also the assurance that all irrelevant personal data will be deleted and that signatures set to anonymous will be completely deleted. That they can indicate to pass on their e-mail address to the petitioner. That they can donate to us, subscribe to the newsletter, follow new petitions appear on twitter, etc.

User adopts a petition

• petitioner does not reply to the e-mail that hand over date is approaching
• petition status changes to new status 'orphaned' which will show in the 'details' of the petition, will remain signable though
• oldest signatory is asked by e-mail to adopt the orphaned petition
• when signatory declines to adopt, then next oldest signatory is asked to adopt (we asked x others before you, they gave as a reason to decline...)
• this repeats until all have been approached, then petition status automatically goes to 'withdrawn'
• when a signatory declines to adopt, reasons can be chosen on their confirmation page, to be passed on to new petitioner or to publish besides withdrawn petition:

1. request of petition has been met without a hand over of the petition
2. petition is too late
3. the situation changed, petition needs to change too
4. political majority disagrees, no point to continue now
5. we should continue differently: organise ourselves, hire a lawyer, etc.
6. can't adopt the petition for personal reasons (too busy, not my thing)
7. other...

• the reasons to decline adoption can always be changed and also when the e-mail was not received
• when petition closes and goes to 'withdrawn', then the results of the above survey is published next to the petition
• e-mail goes to all signatories when a petition is not adopted and withdrawn, survey results included. In that message also the assurance that all irrelevant personal data will be deleted and that signatures set to anonymous will be completely deleted. That they can donate to us, subscribe to the newsletter, follow new petitions appear on twitter, etc.
• to adopt a petition, a link 'I adopt this petition' can be chosen on the confirmation page. When a new quest for adoption starts, it starts with the signatory after the last to adopt the petition.

User moderates a petition

• petitioner starts a petition, confirms petition (by following link sent by e-mail) and then works on draft petition
• moderator receives e-mail alert about this 'intention of a petition' and can already e-mail or call the petitioner to assist
• petitioner indicates that the petition is ready for publication, moderator receives e-mail alert

user is moderating on behalf of an addressee of petitions (like a city, a province) or is one of us, only gets to see petitions attached to that city/province through their 'office' (one office can be about more places)

• moderator logs in at /admin to get access to petitions to moderate
• when userID+password gives error, a password reset can be requested online
• moderator logs in and gets overview of status for only petitions that belong to her 'office'
• moderator corrects the addressee of the to be published petition if needed, then an e-mail alert goes to the other moderator who should moderate it
• moderator checks the petition type, corresponds with petitioner if needed, changes petition type
• moderator gives feedback on petition with suggestions and gives it back to petitioner, status becomes draft again (petitioner + moderator receive e-mail alert), feedback is both sent in the e-mail alert as saved next to the petition to be consulted by petitioner
• moderator + petitioner receive e-mail alert when petitioner wants to publish petition again
• moderator corrects style, spelling and wording of petition where needed
• moderator chooses subdomain for petition
• moderator chooses tags best fit to the petition (with autocomplete from the limited set, only admin can add tags)
• moderator posts tweet about this new petition in a standardised format: subdomain.petitions.eu new #petition "$Titlepetition$"
• moderator copy-pastes unique link to tweet about new petition
• publishes petition (e-mail alert, including unique link to tweet, goes to petitioner + moderator)

Because external moderators (civil servants) sometimes skip tasks, e-mail alerts should also go to us so we can intervene (correct spelling for example).

User follows new petitions

• Follows twitter-account
• Subscribes to newsletter

Users follows petition as signatory

• Updates on website (RSS)
• Signs up for the three e-mail (5) newsletters
• Receives the system e-mails about the hand over (x)

User needs help

• consults help section on website
• writes a message to the helpdesk and receives a copy by e-mail (x)
• consults the handbook