Merge branch 'master' of https://github.com/AY1920S1-CS2103T-T12-4/main

docs/DeveloperGuide.adoc

@@ -190,7 +190,7 @@ This section describes some noteworthy details on how certain features are imple
 === Add feature
 ==== Implementation
 
-The add feature allows the user to add flashcard with compulsory field of `QUESTION` and `ANSWER`. `CATEGORY` is optional fields which the user can add to the flashcard later using the `edit` feature.
+The `add` feature allows the user to add `FlashCard`(s) with compulsory field of `QUESTION` and `ANSWER`. `CATEGORY` are optional fields which the user can add to the flashcard later using the `edit` feature.
 
 [NOTE]
 Following are the prefixes for each field: +
@@ -200,20 +200,20 @@ Following are the prefixes for each field: +
 
 Given below is an example usage scenario of `add` :
 
-The user executes `add q>1+1 a>2 c>math` to add new flashcard.
+The user executes `add q>1+1 a>2 c>math` to add new `FlashCard`.
 
-The following sequence diagram shows how the add operation works:
+The following sequence diagram shows how the `add` operation works:
 
 image::AddSequenceDiagram.png[]
 
 
-The add feature does not allow adding of duplicate FlashCards.
-If the FlashCard exists in the storage, an error will be shown.
+The `add` feature does not allow adding of duplicate `FlashCard`(s).
+If the `FlashCard` exists in the storage, an error will be shown.
 
 [NOTE]
-Duplicate FlashCards refers to FlashCards that have the exact same question and answer.
+Duplicate `FlashCard`(s) refers to `FlashCard`(s) that have the exact same question and answer.
 
-The following activity diagram summarizes what happens when a user executes an add command:
+The following activity diagram summarizes what happens when a user executes an `add` command:
 
 image::AddActivityDiagram.png[width="300"]
 
@@ -223,9 +223,9 @@ image::AddActivityDiagram.png[width="300"]
 * **Alternative 1(current choice):** Use command `add` together with
 prefixes like `q>`, `a>` and `c>`
 ** pros: Easier to implement and easier to process the data.
-** cons: User might miss the prefixes hence adding wrong FlashCards
+** cons: User might miss the prefixes hence adding wrong `FlashCard`(s)
 * **Alternative 2:** Make use of the GUI. After user execute `add` command,
- an **add flash card window** would pop up and there is segment for individual fields.
+ an **add `FlashCard` window** would pop up and there is segment for individual fields.
 ** pros: More user friendly and void user input error.
 ** cons: Harder to implement.
 
@@ -242,7 +242,7 @@ In addition, there was limited time.
 The deadline feature allows the user to add tasks with specific due dates, with a compulsory field
 of `TASK` and `DUE DATE`.
 
-The following are new classes used to integrate the Deadline feature.
+The following are new classes used to integrate the `Deadline` feature.
 
 * `Deadline` -- Object class, containing important information such as the `Task` and `DueDate`.
 * `UniqueDeadlineList` -- Contains a `ObservableList` of `Deadline` objects. The list will be initialised from the storage
@@ -253,7 +253,7 @@ the `Deadline` that will be added.
 * `RemoveCommand` --  Holds information on which `Deadline` to be removed. Contains an `Index` object.
 * `RemoveCommandParser` -- Parses user input and uses it to construct a `RemoveCommand` instance.
 
-In addition, various Exception classes are added to handle possible runtime errors while adding or removing `Deadline`.
+In addition, various Exception classes are added to handle possible runtime errors while adding or removing `Deadline`(s).
 This is done to ensure that the user specified `Deadline` is valid for storage and processing.
 
 * `DuplicateDeadlineException` -- This exception is thrown when the user attempts to add an identical `Deadline` object
@@ -272,63 +272,63 @@ NOTE: The upper cased `Deadline` represents the object class that contains `Task
 
 Given below is an example usage scenario of `deadline` command:
 
-The user executes `deadline t>Complete Homework d>04/10/2020` to add new deadline to the task
+The user executes `deadline t>Complete Homework d>04/10/2020` to add new `Deadline` to the task
 of completing homework by the 4th October 2020.
 
-NOTE: The deadline feature does not allow adding of duplicate/identical deadlines. Also, new deadlines must
-be later than the current date.
+NOTE: The `deadline` feature does not allow adding of duplicate/identical `Deadline`(s). Also, new `Deadline`(s) must
+be later than the current date and is a valid type of date i.e. 29/02/2019 is invalid as 2019 is not a leap year.
 
-The following sequence diagram shows how the deadline operation works:
+The following sequence diagram shows how the `deadline` operation works:
 
 image::DeadlineSequenceDiagram.png[]
 
-The following activity diagram summarizes what happens when a user executes a deadline command:
+The following activity diagram summarizes what happens when a user executes a `deadline` command.
 
 image::DeadlineActivityDiagram.png[width=320,height=480]
 
-The `remove` command works in a similar way, and hence the Sequence and Activity diagrams will be omitted for redundancy.
+The `remove` command works in a similar way, and hence the sequence and activity diagrams will be omitted for redundancy.
 
 ==== Design considerations
 ===== Aspect: How to implement Deadline
 
 * **Alternative 1(current choice):** Use command `deadline` together with
 prefixes like `t>` and `d>`
 ** Pros: Easier to implement
-** Cons: User might miss the prefixes hence adding wrong deadlines
+** Cons: User might miss the prefixes hence adding wrong `Deadline`(s)
 * **Alternative 2:** Make use of the GUI. after user execute `deadline` command,
- an **add deadline window** would pop up with a section for individual fields
+ an **add `deadline` window** would pop up with a section for individual fields
 ** Pros: More user friendly
-** Cons: Difficult to implement. Might be slower for the user to key in deadlines as compared to using a one liner with prefixes
+** Cons: Difficult to implement. Might be slower for the user to key in `Deadline`(s) as compared to using a one liner with prefixes
 
 // end::deadline[]
 
 //@@author dalsontws
 // tag::badflashcard[]
 
-=== Bad FlashCard feature
+=== Bad rating feature
 ==== Implementation
 
-The `bad` feature allows the user to rate specific `FlashCards` as 'bad' if they did not perform well on them.
-These rated FlashCards will then we stored as a `Deadline` dated 3 days later, where the user will then be reminded to
+The `bad` feature allows the user to rate specific `FlashCard`(s) as "Bad" if they did not perform well on them.
+These rated `FlashCard`(s) will then we stored as a `Deadline` dated 3 days later, where the user will then be reminded to
 re-test them.
 
 This is a simple implementation of a type of https://en.wikipedia.org/wiki/Evidence-based_education[evidence-based]
 learning technique known as https://en.wikipedia.org/wiki/Spaced_repetition[Spaced Repetition]. This is used as a form of
 active recall technique which is said to overcome forgetting, theorised by Hermann Ebbinghaus, and his theory of
 https://en.wikipedia.org/wiki/Forgetting_curve[Forgetting Curve].
 
-The following are new classes used to integrate the "Bad" `FlashCard` feature.
+The following are new classes used to integrate the "Bad" `FlashCard` rating feature.
 
 * `BadQuestions` -- Main object class for the feature. Makes use of a `HashMap` of key-value pairing of a Date `String`
-that is converted to a `LocalDate` class as the key, and the value is a `ArrayList` of `FlashCards`. This allows ease of
-search for "Bad" rated `FlashCards` based on the date stored.
+that is converted to a `LocalDate` class as the key, and the value is a `ArrayList` of `FlashCard`(s). This allows ease of
+search for "Bad" rated `FlashCard`(s) based on the date stored.
 * `BadCommand` -- Contains a `ObservableList` of `Deadline` objects. The list will be initialised from the storage
 at start up of application. A `Comparator` class was added to arrange the list according to ascending `DueDate`.
 * `ListBadCommand` --  Embodies the `Deadline` command by the user. It will hold all the information about
 the `Deadline` that will be added.
 * `RemoveBadCommand` -- Parses user input and uses it to construct a `DeadlineCommand` instance.
 
-In addition, two Exception classes are added to handle possible runtime errors while adding new "Bad" `FlashCards`.
+In addition, two Exception classes are added to handle possible runtime errors while adding new "Bad" `FlashCard`(s).
 This is done to ensure that the user specified "Bad" `FlashCard` is valid for storage and processing.
 
 * `NoBadFlashCardException` -- This exception is thrown when the user attempts to add an identical `Deadline` object
@@ -341,22 +341,20 @@ Following are the prefixes for each field: +
 - `bad INDEX` +
 i.e. bad 2
 
-Given below is an example usage scenario of `bad INDEX` :
-
-The user executes `bad 2` to rate the second `FlashCard` in the list as "Bad".
-
 ==== Design considerations
 ===== Aspect: How to store "Bad" FlashCard in storage
 
-* **Alternative 1(current choice):** Use a `HashMap` with the specified date as the key. Store `FlashCard` as an
-`ArrayList`. Use of the Google Gson library to save and fetch `HashMap` from and to Json format.
+* **Alternative 1(current choice):** Use a `HashMap` with the specified date as the key and the values as `ArrayList` of
+`FlashCard`(s). Use of the Google Gson library to save and fetch `HashMap` from and to Json format.
 ** Pros: Easier for searching and sorting purposes, as entire `FlashCard` object is stored and easily
 referred using the date as key. Can fetch more than just the answer of the `FlashCard`
-** Cons: Separated from the `FlashCard` `UniqueFlashCardList`, which might confuse the user
+** Cons: Separated from the `FlashCard` `UniqueFlashCardList`, which might confuse the user as there will be two
+different lists of `FlashCard`
 * **Alternative 2:** Use similar implementation as how `FlashCard` and `Deadline` objects are stored in storage;
-use a `ObservableList` that can be displayed in GUI.
-** Pros: Easier to implement, clearer for user to see
-** Cons: Difficult to manipulate in the future, especially when we want to implement
+use an `ObservableList` that can be displayed in GUI.
+** Pros: Easier to implement, clearer for user to see and fetch these "Bad" rated `FlashCard`(s)
+** Cons: Difficult to manipulate in the future, especially when we want to implement automated test reminders for these
+"Bad" rated `FlashCard`(s). A `HashMap` will allow easy fetching using the specified date as key
 
 // end::badflashcard[]
 
@@ -468,7 +466,7 @@ NOTE: **Alternative 2** was preferred as it provides users with an experience cl
 // tag::dataencryption[]
 === Test mode
 Test mode allows users to start a flash card test from a selected list of tags. If no parameters are provided, all
-flashcards contained in the system will be tested.
+'FlashCard'(s) contained in the system will be tested.
 
 The following activity diagram shows the typical scenario of a `FlashCard` test. Note that special commands such as
 `skip` and `end` are omitted for brevity.
@@ -542,7 +540,7 @@ This feature is supported by the following classes:
 * `StatsCommand` -- Carries the message to be displayed to the user.
 * `MainWindow` -- Opens a specific window as required.
 * `StatsWindow` -- Builds the statistics window display.
-* `Model` -- To provide a list of FlashCards given a rating predicate and the statistics from test mode.
+* `Model` -- To provide a list of 'FlashCard'(s) given a rating predicate and the statistics from test mode.
 * `Stage` -- To create the pop-up window.
 * `Scene` -- To create an object that contains all the physical contents of the pop-up window.
 * `FlowPane` -- To create the layout of the pop-up window.
@@ -565,14 +563,14 @@ The following aspect was a consideration when designing the statistics feature.
 
 Aspect: Methods to collect statistics
 
-* **Alternative 1 (Current choice):** Collect total number of good/hard/easy flashcards using predicates and those completed in test mode using the model.
+* **Alternative 1 (Current choice):** Collect total number of good/hard/easy 'FlashCard'(s) using predicates and those completed in test mode using the model.
 ** Pros: This is easy to implement.
 ** Cons: This requires extra lines of code to combine all the statistics.
 
 
 * **Alternative 2:** Collect all statistics using the model.
 ** Pros: This allows the collection of all statistics with minimal methods involved.
-** Cons: This requires constant updating of the model when new FlashCards are added, removed or edited.
+** Cons: This requires constant updating of the model when new 'FlashCard'(s) are added, removed or edited.
 
 Alternative 1 was chosen simply because it was easier to implement within the given period of time.
 
@@ -720,10 +718,10 @@ Priorities: High (must have) - `* * \*`, Medium (nice to have) - `* \*`, Low (un
 
 *MSS*
 
-1.  User requests to list all flashcards in a <<category, category>>
-2.  System shows a list of flashcards with index
-3.  User requests to delete a flashcard in the list by providing <<category, category>> and index
-4.  System deletes the flashcard
+1.  User requests to list all 'FlashCard'(s) in a <<category, category>>
+2.  System shows a list of 'FlashCard'(s) with index
+3.  User requests to delete a 'FlashCard' in the list by providing <<category, category>> and index
+4.  System deletes the 'FlashCard'
 
 +
 Use case ends.
@@ -803,7 +801,7 @@ Use case resumes at step 2.
 == Glossary
 
 [[category]] Category::
-A tag that can be assigned to a flashcard for better categorisation
+A tag that can be assigned to a 'FlashCard' for better categorisation
 
 [[mainstream-os]] Mainstream OS::
 Windows, Linux, Unix, OS-X
@@ -812,7 +810,7 @@ Windows, Linux, Unix, OS-X
 A contact detail that is not meant to be shared with others
 
 [[test]] Test::
-The state in which the user is shown their flashcards one-by-one and in succession, allowing them to test their understanding of the covered content
+The state in which the user is shown their 'FlashCard'(s) one-by-one and in succession, allowing them to test their understanding of the covered content
 
 [appendix]
 == Product Survey
@@ -857,13 +855,13 @@ These instructions only provide a starting point for testers to work on; testers
 
 === Deleting a FlashCard
 
-. Deleting a flashCard while all flashCards are listed
+. Deleting a 'FlashCard' while all 'FlashCard'(s) are listed
 
-.. Prerequisites: List all flashCards using the `list` command. Multiple flashCards in the list.
+.. Prerequisites: List all 'FlashCard'(s) using the `list` command. Multiple 'FlashCard'(s) in the list.
 .. Test case: `delete 1` +
    Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated.
 .. Test case: `delete 0` +
-   Expected: No flashCard is deleted. Error details shown in the status message. Status bar remains the same.
+   Expected: No 'FlashCard' is deleted. Error details shown in the status message. Status bar remains the same.
 .. Other incorrect delete commands to try: `delete`, `delete x` (where x is larger than the list size) _{give more}_ +
    Expected: Similar to previous.