recipe search view implementation

README.md

@@ -1,181 +1,102 @@
-# Lab 5: Logout
+# CSC207 Course Project- Recipe Management System
+# Group 150
+# Collaborators: Noura Francis, Adya Gopaul, Zain Malik
 
-## Preamble
 
-In the current homework, you added code to the login use case to save the currently-logged-in
-user by saving the user in the Data Access Layer. You also added a unit test for this.
+# Table of Contents
+- [Software Specifications](#software-specifications)
+- [Features of the Software](#features-of-the-software)
+- [Installation Instructions](#installation-instructions)
+- [Usage Guide](#usage-guide)
+- [License](#license)
+- [Feedback](#feedback)
 
-In this lab, you will complete a logout use case as a team. You will also begin to discuss your project
-and the use cases that need to be implemented. 
+## Software Specifications
+This program allows users to either create a new account for a recipe organization system, or log in to their account
+using existing user credentials. Users will be able to search for recipes and apply filters to narrow search results and
+easily obtain recipes that appeal to them. Users save recipes to their profiles to better organize them and reference 
+them for future use. Additionally, users may choose to review recipes that they have saved by providing a rating from
+one to five, with one being the lowest and five being the highest, and an optional comment.
 
-We have created all the Clean Architecture classes necessary for the logout use case.
 
-By Friday, your team will submit:
-- your completed lab code [for credit]
-- a draft of your project blueprint proposal. [required, but not for credit]
+## Features of Software
+### User Management
+- **Sign Up**: The user can create an account using a username and password.
+- **Log In**: Existing users can log in to their accounts.
+- **Log Out**: Users can securely log out of the application.
 
-# Phase 2 [for credit]
-_(recall, Phase 1 was your solo task of adding the storage of the currently-logged-in user)_
 
-## Task 0: Fork this repo on GitHub
-**To get started, one team member should fork this repo on GitHub and share it with the team. 
-All of you should then clone it.**
+### Recipe Search
+- **Search for Recipes**: Users can search for recipes by name.
+- **Filter Search Results**: Filters include options for:
+  - Calories
+  - Nutrients (Protein, Carbs, Fat)
 
-* * *
-
-Suggested logistics: One of you should invite the others to collaborate on their fork of the
-original repo on GitHub. You can do this in your repo on GitHub under `Settings -> Collaborators`.
-This will allow you to push branches to a common repo and then use pull requests to contribute
-your code and review. To prevent others from pushing directly to the main branch,
-we recommend you set branch protection rules on GitHub. Below are how the settings might look if you
-add branch protection rules:
-
-![image of branch protection rules for main with the
-requirement of two approvers to merge in pull requests.
-](images/branch_protection_rules.png)
-
-* * *
-
-Open the project in IntelliJ and make sure you can successfully run `app/Main.java`.
-Note: you may need to set the Project SDK in the `Project Structure...` menu, and possibly
-also manually link the Maven project, as you did in Phase 1.
-
-## Task 1: Understanding the Program
-
-You may notice that we have refactored the CA engine code _slightly_ since Phase 1, but the
-way we build the engine is drastically different: we have switched from using Factories to
-using the Builder design pattern, which we'll be discussing in lecture soon. 
-
-Open up `app.Main` and read it as a team.
-- What are the Views and what are the current Use Cases?
-- Which Uses Cases are triggered from each View?
-- Which version of the DAO is `app.Main` using?
-
-The major change since Phase 1 is that we have added the `app.AppBuilder` class which makes
-it easier to understand how our CA engine is being constructed — it also makes `app.Main` nice and concise!
-- Why do all those `addX` methods end in `return this;`? 
-
-Run the program and make sure the signup and login Use Cases work.
-
-Currently, you'll notice that the "Log Out" button still doesn't actually log you out. It's time to fix
-that button, which is part of the `LoggedInView`.
-We have created all the classes for you, but some of the code is missing.
-As a team, your task is to fill in the missing code so that the Logout Use Case is implemented.
-**The next part of the readme describes how your team will do this.**
-
-* * *
-
-**Your team will know when you are done when:**
-
-- Clicking the "Log Out" button takes the user back to the Login View when you use the program.
-- The provided `LogoutInteractorTest` test passes.
-
-The "Log Out" button is an instance variable in class `LoggedInVew`. Go find it.
-Also look at the `interface_adapter.change_password.LoggedInViewModel`, which contains any
-data showing on the `LoggedInVew`.
-
-* * *
 
-## Task 2: Dividing up the work
+ <img src="./images/recipe search screenshot.png" alt="Search Example" width="400">
 
-There are `TODO` comments left in the files
-Recall that you can use the TODO tool window to conveniently pull up a complete list.
 
-Once the TODOs are all complete, the "Log Out" button _should_ work!
+### Recipe Interaction
+- **Review Recipe**: Users can add reviews to a recipe.
+- **Save Recipe**: Users can save recipes to their profiles for easy access later. 
 
-As a team, split up the TODOs (see below) between the members of your team.
 
-There are TODOs in seven of the files.
-Make sure each member has at least one TODO which they will be responsible for completing.
-If your team prefers to work in pairs, that is fine too. Your individual branches
-will not be graded for this — only the final, working version.
+### Profile Features
+- **View Saved Recipes**: Users can view a personalized list of saved recipes.
 
-The TODOs are summarized below (by file) to help your team decide how to split them up:
 
-* * *
-
-- `Main.java`
+---
 
-  - [ ] TODO: add the Logout Use Case to the app using the appBuilder
 
-* * *
+## Installation Instructions
 
-- `LoggedInView.java` (tip: refer to the other views for similar code)
 
-  - [ ] TODO: save the logout controller in the instance variable.
-  - [ ] TODO: execute the logout use case through the Controller
-
-* * *
+## Prerequisites
+- **Java Development Kit (JDK)**: Amazon Corretto 11 or higher
+- **Apache Maven**
 
-- `LogoutController.java` (tip: refer to the other controllers for similar code)
 
-  - [ ] TODO: Save the interactor in the instance variable.
-  - [ ] TODO: run the use case interactor for the logout use case
+## Instructions for CMD:
+- **Clone the repository from**: [The Repository](https://github.com/NAF308/Recipe-Management-System)
+- git clone https://github.com/NAF308/Recipe-Management-System.git
+- cd Recipe-Management-System 
 
-* * *
 
-- `LogoutInputData.java` (should be done with the LogoutInteractor TODOs below)
+- **Use Maven to compile the project and fetch dependencies**
+- mvn clean install 
 
-  - [ ] TODO: save the current username in an instance variable and add a getter.
 
-- `LogoutInteractor.java` (tip: refer to `ChangePasswordInteractor.java` for similar code)
+- **Run the application**
+- mvn exec:java -Dexec.mainClass="app.Main"
 
-  - [ ] TODO: save the DAO and Presenter in the instance variables.
-  - [ ] TODO: implement the logic of the Logout Use Case
 
-* * *
+---
 
-- `LogoutOutputData.java`
 
-  - [ ] TODO: save the parameters in the instance variables.
+## Usage Guide
+- Once the application is started. You will see the Sign up screen.
+- Choose your username and password.
+- Repeat the password then press sign up
+- You will then see the Login screen
+- Enter your password then press log in
+- You will then see the Profile Screen
+- Here you can change your password and go to recipe search and saved recipes
+- Pressing Recipe Search will take you to the recipe search window
+- There you can write parameters for the recipe search eg. Recipe Name, and calories range
+- Note: At Least one parameter needs to be filled and when writing ranges, the minimum can not be more than the maximum.
+- Pressing search will make an API call and you’ll be taken to the search results window.
+- In the Profile view if you press the Saved Recipes button, you’ll see a list of all the recipes you saved along with the rating you gave them.
 
-* * *
+## Feedback
+Considering the user’s experience with the Recipe Management System is an integral aspect of this project. We, the creators of this project, are open to accepting feedback on your experience using the system, suggest ways in which the system can be improved or recommend features you would like to see in the future. If you wish to do so, the best way to contact us is through the following email addresses.
+- Noura Francis: noura.francis@mail.utoronto.ca
+- Adya Gopaul: adya.gopaul@mail.utoronto.ca
+- Zain Malik: za.malik@mail.utoronto.ca
 
-- `LogoutPresenter.java` (tip: refer to `SignupPresenter.java` for similar code)
+## Contributions
+This project is not accepting contributions at the moment. Persons interested in working with this software may create a fork of the repository by pressing the “Fork” button located in the top-right corner of the repository. Changes to the code may be made on the individual’s local repository after cloning their fork. Any merge requests made will neither be reviewed nor merged into the project. The individual will be solely responsible for any and all changes made to their fork of the repository.
 
-  - [ ] TODO: assign to the three instance variables.
-  - [ ] TODO: have prepareSuccessView update the LoggedInState
-  - [ ] TODO: have prepareSuccessView update the LoginState
 
 * * *
+=======
 
-1. Make a branch named the first part of your UofT email address, everything before the `@`.
-For example, if your email address is `paul.gries@mail.utoronto.ca`, then the branch name would
-be `paul.gries`.
-
-Make sure you switch to the new branch.
-
-In the terminal, this would look like below, but replaced with your own information:
-```
-git branch paul.gries
-git switch paul.gries
-```
-
-2. Complete your assigned TODOs and make a pull request on GitHub. In your pull request,
-   briefly describe what your TODOs were and how you implemented them. If you aren't sure
-   about part of it, include this in your pull request so everyone knows what to look
-   for when reviewing — or you can of course discuss with your team before making your
-   pull request since you are physically working in the same space.
-   - **Important: don't push any changes to the `.idea` folder, as that
-     may cause issues for your other teammates, as some files contain
-     configurations specific to your individual IntelliJ projects.**
-
-3. Review each other's pull requests to ensure each TODO is correctly implemented and that
-   there are no Checkstyle issues in the files that were modified.
-
-4. Once all TODOs are completed, your team should debug as needed to ensure the
-   correctness of the code. Setting a breakpoint where the log-out use case
-   interactor starts its work will likely be a great place to start when debugging.
-
-And that's it; you now have a working Logout Use Case! Instructions for
-how to submit your work on MarkUs will be posted later.
-
-Your team should spend the rest of the lab working on your project blueprint.
-
-* * *
-
-# Project Blueprint
-
-See Quercus for details about the project blueprint! By the end of the week,
-the goal is for your team to have a fully drafted blueprint so that your team
-will be ready to get started on your project after Reading Week.

accessibility-report.md

@@ -0,0 +1,45 @@
+# Accessibility Report
+
+## Principles of Universal Design
+
+### Equitable Use
+“The design is useful and marketable to people with diverse abilities”
+- A computer mouse, touchpad or touch-screen device can be used to navigate the application, making it usable to people of different abilities.
+- Individuals who may not have the fine motor skills necessary for using a computer mouse will still be able to use the application to its full capabilities using a touch screen.
+
+### Flexibility in Use
+“The design accommodate a wide range of individual preferences and abilities”
+- Currently, the application on its own does not support full flexibility of use, however a user may still be able to utilize accessibility features built into their personal electronic devices to facilitate speech-to-text functionality, manually increase the font size or zoom in to improve their experience using the application.
+
+### Simple and Intuitive Use
+“Use of the design is easy to understand, regardless of the user’s experience, knowledge, language skills or current concentration level”
+- Simple, non-technical langauge is used to communicate instructions to the user, so that prompts, labels and messages can be easily understood by anyone, regardless of their level of experience with technology.
+- The flow of the application is logical and cohesive, and the sequence of views that a user engages with is particulary intuitive. Prompts and text labels are also provided for additional clarity.
+
+### Perceptible Information
+“The design communicates necessary information effectively to the user, regardless of ambient conditions or user’s sensory abilities”
+- Non-technical language with appropriate prompts, labels and error messages.
+- While this may be adequate for our purposes, the project can be further improved by using colour to reflect different functionalities. For example, having “back” and “cancel” buttons in red and “search” and “save” buttons in green may make the buttons' functionality clearer to the user and prevent accidental mis-clicks.
+
+### Tolerance for Error
+“The design minimizes hazards and the adverse consequences of accidental or unintended actions”
+- The "back" buttons and "cancel" buttons allow a user to exit the program in the event that they wish to restart after making a mistake.
+- However, once a change is made it cannot be undone. This aspect can be improved upon by implementing an “undo” or “edit” functionality for features such as reviewing a recipe.
+- Furthermore, a “forgot password” feature can be added so that users will not lose access to their account and saved recipes, even if they are unable to remember their login credentials.
+
+### Low Physical Effort
+“The design can be used efficiently and comfortably and with a minimum of fatigue”
+- The application is quite straightforward and does not require excessive button clicks to navigate to different views and features, which reduces the physical effort exerted by the user.
+- However, this principle can be improved upon further by increasing the size of the buttons to make them more easily clickable.
+
+### Size and Space for Approach and Use
+“Appropriate size and space is provided for approach, reach, manipulation and use regardless of user’s body size, posture, or mobility”
+- The main frame of the application can be made larger and depending on the device on which the software is being used, the user may also be able to zoom in on parts of the frame they wish to see better.
+- However, this is largely dependent on the user’s device rather than the software itself. This principle can be improved upon by implementing a feature that allows the user to enlarge the size of the panels and/or text on the frame rather than manually zoom in.
+
+
+
+## Intended Users
+In the event that this program were to be made available to customers, we would likely market the program towards individuals who are passionate about cooking or baking, whether that be as a profession, hobby, or necessity to provide for oneself and/or one’s family. Such individuals would benefit from having a system which allows them to easily search for new recipes and save them in the same place. Additionally, someone who is health conscious or has a condition that requires strict dietary monitoring (such as diabetes, high blood pressure, or simply a food allergy) may be attracted to the program’s filtering feature as it would make searching for recipes that meet their dietary requirements much easier.
+
+Despite the wide variety of people who would enjoy using this program, it may not be best suited for individuals who do not cook often, whether that be due to a busy schedule, or to a preference for ready-made meals over those they have prepared themselves. An example of people who may fall into this category are healthcare workers, such as doctors and nurses, who work long hours and may not have the time to dedicate to meal planning and preparation. Additionally, since this project is entirely web-based, it may not be used by those who struggle to use or do not have reliable access to technology, for example elderly individuals or people who do not have their own electronic devices. Such groups may have no need for a Recipe Organization System, or may prefer physical cookbooks to online recipes.