PROJECT: FlashMind

Overview

FlashMind enables users to organize pieces of information in the form of flashcards, review and tests them in order to absorb knowledge in a very productive manner. The program features an commandline interface (CLI).

Summary of contributions

  • First major enhancement: added the ability to undo/redo commands whenever there is a change to the flashcard list.

    • What it does: Allows the flashcard list to be reverted back to its previous state or restored back to its undone state.

    • Justification: This feature improves the product significantly because it is very likely that the user might input something wrong, accidentally deleted all tags and so forth. This provides them with a very easy way to get back what they want.

    • Highlights: This feature, although not challenging conceptually, is quite time-consuming as I needed to do a lot of refactoring of code to ensure that the undo/redo feature is compatible with all our existing commands, and it turned out that many bugs emerged after adding this command and I spent a lot of time debugging to ensure that this feature becomes bug-free and fully integrated into our program.

    • Credits: The overall undo/redo concept was borrowed from AddressBook 4 and besides lines of new coded added, many of the codes are adapted from its code base.

  • Second major enhancement: redesigned the GUI layout and colour scheme

    • What it does: Recreated the graphical user interface, which is divided into various sections, each responsible for a particular function.

    • Justification: This feature is quite important as it allows future features to be added and integrated smoothly and also it is a major shift away from the original Address Book GUI.

    • Highlights: This feature requires some good understanding of the GUI design and a little bit of CSS knowledge. As a freshman who has no previous experience with GUI, I actually spent hours on this.

  • Minor enhancement:

    • Constantly updating GUI to ensure that it has higher usability and fewer bugs, such as the resizability issue.

  • Code contributed:Click on the link [link] to view my code contributions.

  • Other contributions:

    • Documentation:

      • Documented the undo/redo feature in the Developer Guide.

      • Contributed and modified the majority of the use cases in the Developer Guide.

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Undo/Redo feature

Implementation

The undo/redo mechanism is facilitated by VersionedFlashcardList. It extends FlashcardList with an undo/redo history, stored internally as an flashcardListStateList and currentStatePointer. Additionally, it implements the following operations:

  • VersionedFlashcardList#commit() — Saves the current flashcard list state in its history.

  • VersionedFlashcardList#undo() — Restores the previous flashcard list state from its history.

  • VersionedFlashcardList#redo() — Restores a previously undone flashcard list state from its history.

These operations are exposed in the Model interface as Model#commitFlashcardList(), Model#undoFlashcardList() and Model#redoFlashcardList() respectively.

Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.

Step 1. The user launches the application for the first time. The VersionedFlashcardList will be initialized with the initial flashcard list state, and the currentStatePointer pointing to that single flashcard list state.

UndoRedoState0

Step 2. The user executes delete 5 command to delete the 5th Flashcard in the flashcard list. The delete command calls Model#commitFlashcardList(), causing the modified state of the flashcard list after the delete 5 command executes to be saved in the flashcardListStateList, and the currentStatePointer is shifted to the newly inserted flashcard list state.

UndoRedoState1

Step 3. The user executes add q/What is a machine …​ to add a new Flashcard. The add command also calls Model#commitFlashcardList(), causing another modified flashcard list state to be saved into the flashcardListStateList.

UndoRedoState2
If a command fails its execution, it will not call Model#commitFlashcardList(), so the flashcard list state will not be saved into the flashcardListStateList.

Step 4. The user now decides that adding the flashcard was a mistake, and decides to undo that action by executing the undo command. The undo command will call Model#undoFlashcardList(), which will shift the currentStatePointer once to the left, pointing it to the previous flashcard list state, and restores the flashcard list to that state.

UndoRedoState3
If the currentStatePointer is at index 0, pointing to the initial flashcard list state, then there are no previous flashcard list states to restore. The undo command uses Model#canUndoFlashcardList() to check if this is the case. If so, it will return an error to the user rather than attempting to perform the undo.

The following sequence diagram shows how the undo operation works:

UndoSequenceDiagram
The lifeline for UndoCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

The redo command does the opposite — it calls Model#redoFlashcardList(), which shifts the currentStatePointer once to the right, pointing to the previously undone state, and restores the flashcard list to that state.

If the currentStatePointer is at index flashcardListStateList.size() - 1, pointing to the latest flashcard list state, then there are no undone flashcard list states to restore. The redo command uses Model#canRedoFlashcardList() to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.

Step 5. The user then decides to execute the command list. Commands that do not modify the flashcard list, such as list, will usually not call Model#commitFlashcardList(), Model#undoFlashcardList() or Model#redoFlashcardList(). Thus, the flashcardListStateList remains unchanged.

UndoRedoState4

The following activity diagram summarizes what happens when a user executes a new command:

CommitActivityDiagram

Design Considerations

Aspect: How undo & redo executes

  • Alternative 1 (current choice): Saves the entire flashcard list.

    • Pros: Easy to implement.

    • Cons: May have performance issues in terms of memory usage.

  • Alternative 2: Individual command knows how to undo/redo by itself.

    • Pros: Will use less memory (e.g. for delete, just save the flashcard being deleted).

    • Cons: We must ensure that the implementation of each individual command are correct. There will be a lot coding involved and a higher chance of regression bugs.

      Use case: UC04 - edit a flashcard

Actor: User

MSS

  1. User views all existing flashcards (UC01).

  2. User identifies the index of the particular flashcard that he/she wants to edit.

  3. User request to edit the question, tag or answer of a flashcard.

  4. FlashMind updates the question, tag or answer on the specific flashcard.

Extensions

  • 2a. The requested question or answer is in wrong format

    • 2a1. FlashMind shows an error message including the constraints of the question and answer.

      Use case ends.

  • 2b. The input flashcard index number is invalid

    • 2b1. FlashMind shows an error message.

      Use case ends.

Use case: UC05 - find all flashcards with particular tags

Actor: User

MSS

  1. User request to list all the flashcard sets with the same tags by inputting these tags.

  2. FlashMind shows a list of all current flashcards with the provided tags.

  • 2a. The tag is empty or does not exist.

    • 2a1. System displays an error message. user case ends.

PROJECT: FlashMind