Use cases

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 link (in some webmailclients) should give a 404-page where one 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. Also some anti-virus software or mal configured computers bar clicking on links.
• Wether user has already signed or not, the confirmation e-mail (2) with 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 (27).
• User receives an e-mail (13) when the petition is handed over to the addressee (the authority)

User invites to sign and shares signature

• Once confirmed, then below the summary of the signature data extra lines 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 replacing the e-mail address with a new one. 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). To be friendly to the user the old link points to the new page.
• 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 any text file with addresses 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) a week later 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, ask me later', webpage opens 'we will remind you by e-mail (8) to sign next week and again 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 (10) me'.
• 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 (11) when enough donations were promised." After the pull-down bar is set to anything.
• 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|" and receives an e-mail (12) with a customised link to a generic webshop with objects for this particular petition.

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 closes this page with the 'finalise' button
• user receives an e-mail (14) with a confirmation link (including a generated long string) to a page where one can also login with the chosen or supplied password. When the chosen password does not work, then a password reset can be requested there, which will sent an e-mail (15) to a page where a new password can be chosen.
• when a user tries to login using an unconfirmed username (impatiently, immediately after creating a petition), the confirmation link is sent again with the feedback 'please confirm your e-mail address before login'. All this just to make sure e-mail arrives. A petition can not be started without a working e-mail address and a human interaction (preventing bots from creating petitions).
• when a user uses an old confirmation e-mail (14) to reach the login page this also works, redirects to login 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 (16) 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 (17), 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 confirmation link received by e-mail (14) (address from users.email) and logs in
• user improves text of petition, uploads picture for a better one, etc.
• optionally changes e-mail address (petitions.petitioner_email) and anonymises name (petitioner_name) which has no consequences for users.email and users.name but sends a confirmation e-mail (14) to that e-mail address for it to become active
• when ready to go open presses the button 'publish' and a status change e-mail (18) goes to user, admin and petition desk
• 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

• user goes to login page or the link in the footer and enters e-mail address and password
• as above after confirmation
• 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 (19) with recommendations on how to improve petition, with a request to login to keep the petition alive, otherwise it goes up for adoption.
• petitioner receives e-mail (20) 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. With a request to login to keep the petition alive, otherwise it goes up for adoption.
• 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. With a request to login to keep the petition alive, otherwise it goes up for adoption. (21)
• petitioner receives statistics about performance: how many signatories, growth compared to other petitions, etc. With a request to login to keep the petition alive, otherwise it goes up for adoption. (22)
• 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.

System hands over petition

Also see the flowchart

• petition status changes to_process a week before the actual hand over, petition remains signable. E-mail (18) to user and admin. When petitioner scheduled the date for the handover within a week after publishing the petition, or without (m)any signatures then status does not change and only admin receives a message and admin contacts signatory (fix this or confirm that it was your intention). Make sure that a hand over date in the past does not cause a loop with endless messages.
• User is asked by e-mail (18) to write an update about the pending hand over (when and where) with the information received from the addressee. The update will appear under the petition. And a reminder to call the addressee when they did not call.
• e-mail (23) with petition and stats about signatures (not the 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 as petition desk (23) 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 and/or user does this manually. Addressee is asked to call + e-mail petitioner to explain the hand over process and such formalities.
• when addressee does not reply, the hand over date is prolonged with a week and a reminder e-mail (24) is sent. After four reminders the petition closes automatically and a 'virtual' hand over takes place, a PDF by e-mail (25) and the status closes to in_process, as below.
• The petition and list of signatures goes out by (25) on the day of the hand over as PDF, 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 this 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 (24) with the question what the addressee will do with the petition and when. A list of options appears in the e-mail (24).
• Addressee can reply by e-mail or follow unique link in the e-mail (24) to choose an 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 e-mail (24) is sent every two weeks, with reference to all the previously sent messages.
• Once the date for the answer to the petition as indicated by the addressee is reached, an e-mail goes out to ask what the outcome was, how the petition was treated. A list of options appears in the e-mail. Addressee can reply by e-mail (25) or again follow a unique link to choose an option in a pull-down menu and write text in a text window (hyperlinks to documents and videos are possible and encouraged).
• This answer will be published next to the petition and the status changes to 'concluded'.
• The answer to the petition (26) 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 log in ever
• petition status changes a week before hand over date to new status 'orphaned' which will show in the 'details' of the petition, will remain signable though
• oldest signatory is asked by e-mail (31) 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...

• when signatory does not respond, after a day the next one is asked
• when user wants to adopt but next one is already asked, the quest stops and all already asked are given a week to adopt: "hang on, we already asked others, let's wait if they want to adopt this petition"
• when petition closes and goes to 'withdrawn', then the results of the above survey is published next to the petition
• e-mail (32) 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 one asked 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 (27) 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 (28) 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 (28) 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 (29) 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 (27) 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 to be included in e-mail (30) alert
• publishes petition (e-mail (30) 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