In the previous blog, I talked about my plan to build this prayer tracker website. This time, I will talk about the use cases of this website, to better plan the website.

• Side note: I will call this a web application from now on. Websites tend to be more static and focused on providing information, while web applications are more interactive and focused on providing a specific service or functionality to users. Therefore my idea classifies as a web app.

Use case diagram

As you can see, I am to provide a lot of functionality to the user. They can be classified into three major parts

1. Interacting with prayer items: Create, edit, and delete them. These are the main functionality of the web app

2. Authentication: Sign in/up/out, and edit account details.

3. Payment: Provide payment method via a Payment provider.

Interacting with prayer items

The idea of the app is to remind the user to pray about things, therefore items that the user should pray for will be displayed. There is also a pray button, when clicked, it indicates that the user has prayed for this item today, and the item will only come back to the list after the selected frequency.

There is an options button, when clicked, opens a dropdown menu, allowing the user to edit, mark as prayed, mark as denied, and delete the item. If the user clicks the item content, the item will expand showing more details.

There should also be an add new button, which will create a prompt for users to fill in details of the new prayer item the user wishes to create.

There should also be two separate areas for answered and denied prayers, with the options of editing and deleting.

Authentication

The web app should support signing up with email and asking for the username in the process. It should also support signing up with OAuth using Google or Facebook.

For sign-in, we should allow users to sign in with email or OAuth. If the user forgot their password, we should allow the user to reset their password through email authentication.

For logged-in users, they should be able to change passwords, change email, log out, and even delete their accounts because of GDPR regulations.

Payment

I want to implement a subscription system so that users that want more functionalities can do so by subscribing to more advanced plans. To do so, I need a page for users to view their current subscriptions, purchase a subscription, and manage their current subscriptions.

Detailed use case

Below I am going to document the key use cases

Use case 1: Display the list of active prayer items

Actors: User, System

Preconditions:

• The web app has established a connection to the server

• The user is authenticated

The flow of events:

1. If the user has encryption enabled, try to read the encryption key from local storage, if it is not there, prompt the user to enter it

2. the web app makes a request to the server for the list of prayers items the user has

3. the server queries the database and sends back the list of prayer items

4. the web app sorts the prayer items by the next_date, then display the ones with a next_date before or equal to today with a for loop

   1. If the item is encrypted, decrypt it with the secret key, and display it with a lock icon

   2. If the item is not encrypted, display it

5. for the prayer items with a next_date in the future, they will be displayed below with a grey overlay, to symbolize that they are queued for the future.

Postconditions: The list of active prayer items is displayed on the UI

Use case 2: Add a prayer item

Actors: User, system

Preconditions:

• The web app has established a connection to the server

• The user is authenticated

The flow of event:

1. the user input the prayer item details

2. the user press add item or press enter on the keyboard

3. the web app performs client-side input validation. Including the input length

4. the web app sends a request to the server to add the item

   1. If the user enabled encryption, the prayer content will be encrypted before being sent to the server

5. the server performs server-side validation, including prayer item count

6. the server adds the prayer item to the database

7. the server increments the total number of prayer items for that user from the database

8. the server sends a response to the web app

9. the web app displays the additional prayer item

Postconditions: the newly added prayer item is in the web app as well as the server database

Alternative flow:

• In steps 5-6, if there is any error causing the insert to be unsuccessful, the server will send back a response about why the insert failed, and the web app will display the reason to the user

Use case 3: New user signup

Actors: User, system

Preconditions: The web app has established a connection to the server

The flow of event:

1. the user completes the sign-up form

2. the web app sends the sign-up request to the server

3. the server creates the user

4. the after-insert trigger function triggers, inserting the user in the other tables

5. if the user uses email auth, they have to go to their email account and verify the email

6. the user logs in

Postconditions: the user lands on the dashboard, and sees a basic tutorial

Conclusion

After doing this analysis of use cases, I now have a better understanding of the specific needs and goals of users, which helps to ensure that the web app is designed and developed to meet their expectations.