Use cases

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

This is an updated version of the Use cases 2015 version.

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 require 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

• some users get an invite e-mail (1) with a direct link to the shared link of a petition
• or heard about the petition, but does not know the exact name or link (most likely to first use web search)
• a minority of users land 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
• 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 on the desktop, on small screen below the petition, it asks only an e-mail address
• as input in the form an e-mail address is required
• the user clicks ‘yes, I want to sign this petition’
• if there is anything wrong with the input then immediately an error message appears (page does not reload) above that button , instructing what to fix in the e-mail address.
• if there are no errors in the input the button disappears (or never appeared) and a ‘checked’ icon appears with a thank you message; "Thank you, please confirm your signature by e-mail.'
• perhaps a timestamp in small print appears below it to help identify the message and show the authenticity, to convince those who never click a link.
• it also says: "Also check your spam mailbox if you can not find it."
• user goes to mailclient or opens webbrowser for webmail and looks for the message (perhaps needs to wait!) or a pop-up/sound from the client appears about this new message
• user finds the e-mail with subject "Confirm your signature for the petition $petition.name"
• in the e-mail a link and button is shown to the signature confirmation page which is valid for x minutes and a link to request a fresh one if expired.
• user follows the link with a unique token in it
• if the user already signed this petition user lands on a page with an overview of previously signed petitions with this e-mail address and the preferences for each
• the user is invited to sign other petitions during the same session without the need to confirm the address
• if the user did sign other petitions previously the page asks to confirm credentials known from previously signed petitions
• if the user never signed a petition before fields appear to fill in credentials: name and place.
• user is asked to select checkboxes: 'sign publicly', 'inform about this petition' and 'invite me for more'
• the signature is confirmed by pressing an obvious big button to do so.
• if name is only one word user is asked to add an initial or first name
• if no place is selected the user is asked to add a place
• if credentials are sufficient a thank you appears with the question to share the petition
• user chooses to share the petition by e-mail, then a formatted invite e-mail appears
• user chooses to share the petition as another message, a text with link can be copied
• user chooses to share the petition as a print on an A4 page with a qr-code