Merge pull request #271 from keaganpzh/branch-UG

UG/DG: Fix layouts

docs/DeveloperGuide.md

@@ -56,7 +56,7 @@
     8.9. [Remove full-screen support for help window (macOS)](#8-9-remove-full-screen-support-for-help-window-macos)<br>
     8.10. [Better colour scheme](#8-10-better-colour-scheme)
 9. [Appendix D: Effort](#9-appendix-d-effort)<br>
-    9.1. [Replacing `Person` with `Guest` and `Vendor` classes](#9-1-replacing-person-with-guest-and-vendor-classes)<br>
+    9.1. [Augmenting `Person` with `Guest` and `Vendor` classes](#9-1-augmenting-person-with-guest-and-vendor-classes)<br>
     9.2. [Altering most fields to become Optional](#9-2-altering-most-fields-to-become-optional)<br>
     9.3. [Enhancing `Guest` class with new parameters](#9-3-enhancing-guest-class-with-new-parameters)<br>
     9.4. [Enhancing the `add` and `edit` commands](#9-4-enhancing-the-add-and-edit-commands)<br>
@@ -1189,15 +1189,15 @@ by changing the relevant style attributes in the `.css` files.
 
 This section documents the effort required to evolve AB3 into WedLog.
 
-### 9.1. Replacing `Person` with `Guest` and `Vendor` classes
+### 9.1. Augmenting `Person` with `Guest` and `Vendor` classes
 
 This involved: 
 * Creating `Guest` and `Vendor` classes.
 * Rewriting all existing code dealing with `Person` to handle `Guest` and `Vendor`.
   * E.g. `EditCommand` into `GuestEditCommand` and `VendorEditCommand`.
 * Splitting parsing of vendor and guest commands to their respective Parser classes `GuestCommandParser` and `VendorCommandParser`.
 * Updating UI to display both lists.
-* Removing all depreciated classes handling the `Person` class.
+* Removing all deprecated classes handling the `Person` class.
 
 This was time and effort intensive as:
 * Tracking two entities as opposed to one in AB3 increased the complexity of our project.
@@ -1217,13 +1217,13 @@ variations in values.
 ### 9.3. Enhancing `Guest` class with new parameters
 
 We enhanced the `Guest` class to track additional information not covered in the original `Person` class. This involved:
-* Introducing the `TableNumber`, `RsvpStatus` and `DietaryRequirements` classes and integrating them into existing 
+* Introducing the `TableNumber`, `RsvpStatus` and `DietaryRequirement` classes and integrating them into existing 
 features like `add` and `edit`.
 
 This change was challenging as it required lots of in-depth design discussions on how to best represent the information.
   * For `RsvpStatus` class: We debated on the appropriate amount of flexibility to give users, and eventually 
   settled on restricting acceptable values for `RsvpStatus` to `Yes`, `No`, and `Unknown`.
-  * For `DietaryRequirements` class: We initially stored the information as a string, but later adapted it into a 
+  * For `DietaryRequirement` class: We initially stored the information as a string, but later adapted it into a 
   tag system to facilitate UI design and filtering.
 
 <br>
@@ -1258,7 +1258,7 @@ This involved:
 
 <br>
 
-### 9.7. Introducing `RsvpStatus` pie chart and `DietaryRequirements` statistics panel
+### 9.7. Introducing Rsvp Status pie chart and Dietary Requirements statistics panel
 
 This involved creating a new UI design and logic that was not available in AB3.
 

docs/UserGuide.md

@@ -345,9 +345,9 @@ Let's narrow down the guest list based on specific criteria using the `guest fil
 
 Before we can begin filtering our guests, we must add more guests to the list. Enter each of the following lines one-by-one into WedLog. Each line will add a new guest to the guest list.
 
-`guest add n/Mary Fowl t/friends`
-`guest add n/Bob White`
-`guest add t/friends t/university n/Lily Mae`
+`guest add n/Mary Fowl t/friends` <br>
+`guest add n/Bob White` <br>
+`guest add t/friends t/university n/Lily Mae` <br>
 
 <box type="tip">
 

docs/_markbind/layouts/default.md

@@ -27,23 +27,26 @@
       <site-nav>
 * [Home]({{ baseUrl }}/index.html)
 * [User Guide]({{ baseUrl }}/UserGuide.html) :expanded:
-  * [Quick Start]({{ baseUrl }}/UserGuide.html#1-quick-start)
-  * [Features]({{ baseUrl }}/UserGuide.html#2-features)
-  * [FAQ]({{ baseUrl }}/UserGuide.html#3-faq)
-  * [Known Issues]({{ baseUrl }}/UserGuide.html#4-known-issues)
-  * [Future Implementations]({{ baseUrl }}/UserGuide.html#5-future-implementations)
-  * [Command Summary]({{ baseUrl }}/UserGuide.html#6-command-summary)
-  * [Appendices]({{ baseUrl }}/UserGuide.html#7-appendices)
+  * [How to Use This Guide]({{ baseUrl }}/UserGuide.html#1-how-to-use-this-guide)
+  * [Getting Started]({{ baseUrl }}/UserGuide.html#2-getting-started)
+  * [Understanding the WedLog Interface]({{ baseUrl }}/UserGuide.html#3-understanding-the-wedlog-interface)
+  * [WedLog Tutorial]({{ baseUrl }}/UserGuide.html#4-wedlog-tutorial)
+  * [Features]({{ baseUrl }}/UserGuide.html#5-features)
+  * [FAQ]({{ baseUrl }}/UserGuide.html#6-faq)
+  * [Known Issues]({{ baseUrl }}/UserGuide.html#7-known-issues)
+  * [Future Implementations]({{ baseUrl }}/UserGuide.html#8-future-implementations)
+  * [Command Summary]({{ baseUrl }}/UserGuide.html#9-command-summary)
+  * [Appendix: Acceptable Values for Parameters]({{ baseUrl }}/UserGuide.html#10-appendix-acceptable-values-for-parameters)
 * [Developer Guide]({{ baseUrl }}/DeveloperGuide.html) :expanded:
-  * [Acknowledgements]({{ baseUrl }}/DeveloperGuide.html#acknowledgements)
-  * [Setting Up]({{ baseUrl }}/DeveloperGuide.html#setting-up-getting-started)
-  * [Design]({{ baseUrl }}/DeveloperGuide.html#design)
-  * [Implementation]({{ baseUrl }}/DeveloperGuide.html#implementation)
-  * [Documentation, logging, testing, configuration, dev-ops]({{ baseUrl }}/DeveloperGuide.html#documentation-logging-testing-configuration-dev-ops)
-  * [Appendix A: Requirements]({{ baseUrl }}/DeveloperGuide.html#appendix-a-requirements)
-  * [Appendix B: Instructions for manual testing]({{ baseUrl }}/DeveloperGuide.html#appendix-b-instructions-for-manual-testing)
-  * [Appendix C: Planned Enhancements]({{ baseUrl }}/DeveloperGuide.html#appendix-c-planned-enhancements)
-  * [Appendix D: Effort]({{baseUrl}}/DeveloperGuide.html#appendix-d-effort)
+  * [Acknowledgements]({{ baseUrl }}/DeveloperGuide.html#1-acknowledgements)
+  * [Setting Up, Getting Started]({{ baseUrl }}/DeveloperGuide.html#2-setting-up-getting-started)
+  * [Design]({{ baseUrl }}/DeveloperGuide.html#3-design)
+  * [Implementation]({{ baseUrl }}/DeveloperGuide.html#4-implementation)
+  * [Documentation, logging, testing, configuration, dev-ops]({{ baseUrl }}/DeveloperGuide.html#5-documentation-logging-testing-configuration-dev-ops)
+  * [Appendix A: Requirements]({{ baseUrl }}/DeveloperGuide.html#6-appendix-a-requirements)
+  * [Appendix B: Instructions for manual testing]({{ baseUrl }}/DeveloperGuide.html#7-appendix-b-instructions-for-manual-testing)
+  * [Appendix C: Planned Enhancements]({{ baseUrl }}/DeveloperGuide.html#8-appendix-c-planned-enhancements)
+  * [Appendix D: Effort]({{baseUrl}}/DeveloperGuide.html#9-appendix-d-effort)
 * Tutorials
   * [Tracing code]({{ baseUrl }}/tutorials/TracingCode.html)
   * [Adding a command]({{ baseUrl }}/tutorials/AddRemark.html)

docs/team/keaganpzh.md

@@ -28,23 +28,24 @@ Given below are my contributions to the project.
    * Justification: This feature allows users to easily see the statistics of their guest list. This is useful for the user to see how many guests are coming, not coming, or unsure yet. It is also useful for the user to see the dietary requirements of their guests, so that they can organise the catering accordingly.
    * Highlights: One challenge faced was making each component react and change accordingly after each command execution. This required rebuilding parts of the UI after each command entered. Another challenge was to pass the correct data to the UI components. This required the use of the `RsvpStatistics` and `DietaryRequirementStatistics` classes to store the data.
 
-5. **New Feature**: Reworked the UI to suit the two-list idealogy.
+5. **New Feature**: Reworked the UI to suit the two-list ideology.
    * What it does: displays two lists side by side, one for guests, and one for vendors. The statistics panel with the logo is displayed alongside the two lists.
-   * Justification: originally, AB3 is designed taller than wide. By making WedLog wider than tall, it allows the user to see more information at a glance, and is more suitable for the two-list idealogy.
+   * Justification: originally, AB3 is designed taller than wide. By making WedLog wider than tall, it allows the user to see more information at a glance, and is more suitable for the two-list ideology.
 
 
 ### Code Contributed
 [RepoSense link](https://nus-cs2103-ay2324s1.github.io/tp-dashboard/?search=keaganpzh&breakdown=false&sort=groupTitle%20dsc&sortWithin=title&since=2023-09-22&timeframe=commit&mergegroup=&groupSelect=groupByRepos)
 
 ### Documentation
 * **User Guide**:
-    * Added section on Quick View panel.
+    * Added section on Rsvp Status panel.
+    * Added section on Dietary Requirements panel.
     * Added descriptions to each feature/command.
 * **Developer Guide**:
     * Updated Glossary and Appendix. [PR #42](https://github.com/AY2324S1-CS2103T-F11-2/tp/pull/42)
     * Created new class diagrams for UI and Guest. [PR #144](https://github.com/AY2324S1-CS2103T-F11-2/tp/pull/144)
-    * Added documentation for tacking of guests and vendors. [PR #144](https://github.com/AY2324S1-CS2103T-F11-2/tp/pull/144)
-    * Added "Planned Enhancements" section.
+    * Added documentation for implementation of tracking of guests and vendors. [PR #144](https://github.com/AY2324S1-CS2103T-F11-2/tp/pull/144)
+    * Added "Planned Enhancements" section. [PR #238](https://github.com/AY2324S1-CS2103T-F11-2/tp/pull/238)
 
 ### Contributions to team tasks
 * **Project Management**: