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
Interacting with prayer items: Create, edit, and delete them. These are the main functionality of the web app
Authentication: Sign in/up/out, and edit account details.
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 flow of events:
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
the web app makes a request to the server for the list of prayers items the user has
the server queries the database and sends back the list of prayer items
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
If the item is encrypted, decrypt it with the secret key, and display it with a lock icon
If the item is not encrypted, display it
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 flow of event:
the user input the prayer item details
the user press add item or press enter on the keyboard
the web app performs client-side input validation. Including the input length
the web app sends a request to the server to add the item
- If the user enabled encryption, the prayer content will be encrypted before being sent to the server
the server performs server-side validation, including prayer item count
the server adds the prayer item to the database
the server increments the total number of prayer items for that user from the database
the server sends a response to the web app
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:
the user completes the sign-up form
the web app sends the sign-up request to the server
the server creates the user
the after-insert trigger function triggers, inserting the user in the other tables
if the user uses email auth, they have to go to their email account and verify the email
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.
![Focuster review: My experience as a student in summer [week 3]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1693222238382%2F06452c01-14a3-423a-9311-83b9d82f6fcc.png&w=3840&q=75)
![Reclaim.AI review: My experience as a student in internship [week 2]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1692385558997%2F5cd2253e-b50d-4d47-9aad-72807848b1a9.png&w=3840&q=75)
![Motion Review: My experience as a student in internship [week 1]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1690840123756%2F5bdf844a-d728-430c-8d9b-b88b7b77c726.png&w=3840&q=75)
![Trialling Productivity Tools to Rescue My Time [Week 0]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1690321356599%2F2f404dbe-3c2a-421b-903c-04d72c8febed.png&w=3840&q=75)