Use cases: verschil tussen versies

Versie van 1 aug 2015 om 13:17

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.

Signing a petition

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

User finds petition

• user gets direct link to the shared link (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 (instead of news from us, in a future release, we can show tweets about new petitions on the new petitions view)
• 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 and 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 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. The icons are not communicating with others because they do not show how many times it was shared. Perhaps in a future release, using the opt-in social media approach.

User confirms petition

• In the e-mail 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.
• 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.
• On the confirmation page 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’.
• 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.)

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.
• In a future release 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 and the address of this confirmation page changes, but the old address still appears as the one the signature is confirmed with (in case 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 altered, 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. These appear in a row, with checked checkboxes after each one, 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 unchecks the addresses that should not get an invite.
• Users clicks the button 'Send invitation' and receives an e-mail 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 is sent with a week delay, with the suggestion to check if invitees have signed and 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 confirming, 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) 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 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'.
• User can contribute with a donation for something the petitioner chooses. With pull-down bar choice between 1, 5, 10 or 25, only deducted when goal reached.

user responds to invitation

• user receives an e-mail 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)

following for future release

• user follows link to 'not now, I sign later', webpage opens 'we will remind you 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$

starting a petition

• a user comes to our website directly (having signed a petition there once) or after a websearch about starting a petition
• landing on the homepage after search or directly going there, there is a big button 'start a petition'
• a small number of users get inspired while they are on the website (perhaps a link in the footer should be included)

managing/improving 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 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.
• 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 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.

adopting 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.
• 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.

moderating a petition

• petitioner starts a petition, confirms petition (by following link sent by e-mail) and then works on concept 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 concept 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
• 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).

stay informed about new petitions

• twitter-account
• newsletters

stay informed as signatory

• newsletters
• updates/RSS