This site is from a past semester! The current version will be here when the new semester starts.
TIC4001 2020
**Schedule**
  • Full Timeline
  • Week 1 [Mon, Aug 10th]
  • Week 2 [Fri, Aug 14th]
  • Week 3 [Fri, Aug 21st]
  • Week 4 [Fri, Aug 28th]
  • Week 5 [Fri, Sep 4th]
  • Week 6 [Fri, Sep 11th]
  • Week 7 [Fri, Sep 18th]
  • Week 8 [Fri, Oct 2nd]
  • Week 9 [Fri, Oct 9th]
  • Week 10 [Fri, Oct 16th]
  • Week 11 [Fri, Oct 23rd]
  • Week 12 [Fri, Oct 30th]
  • Week 13 [Fri, Nov 6th]
  • Textbook
  • Admin Info
    • **Links**
  • Report Bugs
  • Forum
  • Gitter (Chat)
  • Instructors
  • Announcements
  • Files
  • Java Coding Standard
  • Git Conventions
  • Participation Dashboard
    •  Individual Project (iP):
  • Individual Project Info
  • iP List
  • iP Upstream Repo
  • iP Code Dashboard
  • iP Progress Dashboard
    •  Team Project (tP):
  • Team Project Info
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
    •

    • Week 4 [Fri, Aug 28th] - Project

    iP:

    1. Add Increments as branches: Level-5, A-CodeQuality, A-AbstractClasses, A-Packages
    2. Review some peer PRs counted for participation

    tP:

    1. Start weekly project meetings
    2. Start a collaborative doc to take project notes before next lecture
    3. Decide on an overall project direction (user profile, problem addressed) before next lecture

    iP

    1 Add Increments as branches: Level-5, A-CodeQuality, A-AbstractClasses, A-Packages

    • Do each increment as a Git branch. Here is an example:
      • Start a branch named branch-{increment ID} (e.g. branch-Level-5). You are recommended to have multiple commits in that branch. Follow the branch naming convention exactly or else our gradings scripts might miss your branch.
      • After the increment is ready, merge the branch-Level-5 back on to master, without a fast-forward so that git creates a separate commit for the merge. git tag that merge commit as Level-5.
      • Push the branch to your fork so that the bot can detect it. As before, push the tag as well.
      • Advanced git users: do not delete the branch after merging.
    Duke Level-5: Handle Errors

    Level 5. Handle Errors

    Teach Duke to deal with errors such as incorrect inputs entered by the user.

    Example:

    todo
        ____________________________________________________________
         ☹ OOPS!!! The description of a todo cannot be empty.
        ____________________________________________________________

    blah
        ____________________________________________________________
         ☹ OOPS!!! I'm sorry, but I don't know what that means :-(
        ____________________________________________________________

    When implementing this feature, you are also recommended to implement the following extension:

    A-Exceptions

         ↳ Use Exceptions to handle errors

    Use exceptions to handle errors. For example, define a class DukeException to represent exceptions specific to Duke.

    • Minimal: handle at least the two types of errors shown in the example above.
    • Stretch goal: handle all possible errors in the current version. As you evolve Duke, continue to handle errors related to the new features added.
    Duke A-CodeQuality: Improve Code Quality

    A-CodeQuality

         ↳ Improve code quality

    Critically examines the code and refactor to improve the code quality where necessary.

    When adding this increment, follow closely the 'Code Quality' topics you have learned so far, rather than merely follow your own intuition about code quality.

    Duke A-AbstractClasses: Use Abstract Classes

    A-AbstractClasses

         ↳ Use abstract classes

    Make the Task class an abstract class. If applicable, use abstract methods as well.

    Duke A-Packages: Organize into Packages

    A-Packages

         ↳ Divide classes into packages

    Organize the classes into suitable java packages.

    • Minimal: put all classes in one package e.g., duke
    • Stretch goal: divide into multiple packages as the number of classes increase e.g., duke.task, duke.command

    2 Review some peer PRs counted for participation

    Please wait till Mon, Aug 31st to start this task, to give others a few extra days to create the PR if they haven't done so yet.

    This task is worth 2x2=4 participtaion points.

    • Learn how you should review PRs in this task:
    Video

    The PR review stage is a dialog between the PR author and members of the repo that received the PR, in order to refine and eventually merge the PR.

    Given below are some steps you can follow when reviewing a PR.

    1. Locate the PR:

    1. Go to the GitHub page of the repo.
    2. Click on the Pull requests tab.
    3. Click on the PR you want to review.

    2. Read the PR description. It might contain information relevant to reviewing the PR.

    3. Click on the Files changed tab to see the diff view.

    4. Add review comments:

    1. Hover over the line you want to comment on and click on the icon that appears on the left margin. That should create a text box for you to enter your comment.
      To mark multiple lines, click-and-drag the icon.
    2. Enter your comment.
      This page @SE-EDU/guides has some best practices PR reviewers can follow.
    3. After typing in the comment, click on the Start a review button (not the Add single comment button. This way, your comment is saved but not visible to others yet. It will be visible to others only when you have finished the entire review.

    4. Repeat the above steps to add more comments.

    5. Submit the review:

    1. When there are no more comments to add, click on the Review changes button (on the top right of the diff page).
    2. Type in an overall comment about the PR, if any. e.g.,
      Overall, I found your code easy to read for the most part except a few places
      where the nesting was too deep. I noted a few minor coding standard violations
      too. Some of the classes are getting quite long. Consider splitting into smaller
      classes if that makes sense.
      LGTM is often used in such overall comments, to indicate Looks good to merge.
      nit is another such term, used to indicate minor flaws e.g., LGTM, almost. Just a few nits to fix..
    3. Choose Approve, Comment, or Request changes option as appropriate and click on the Submit review button.

    • Step 1 Note these additional guidelines:

      • Read the Best practices for reviewing PRs @SE-EDU/guides. You are expected to follow all of them.
      • If the PR has received some review comments already, feel free to confirm/complement/question those comments in your review. Also, look for things the previous reviewers may have missed.
      • At the end of the review, choose Comment (i.e., not Approve or Request changes)

    • Step 2 Do the first PR review as follows.

      • Comment on coding standard violations only.
      • The review allocation is given in the panel below.
    Tutorial Reviewer First PR to review Backup PR to review
    TIC4001-F18 JanuariusJang ZhengShijieNUS Chilaiping
    TIC4001-F18 Yiheng0410 pigoliver Impala36
    TIC4001-F18 Chilaiping dgc5213 binbinhui
    TIC4001-F18 e0260222 daiweinus adi-kd0021
    TIC4001-F18 Chenduo1412 e0260222 daiweinus
    TIC4001-F18 skyventus tototto JanuariusJang
    TIC4001-F18 Impala36 e02161618 Chenduo1412
    TIC4001-F18 daiweinus adi-kd0021 linqing42
    TIC4001-F18 dgc5213 binbinhui Yiheng0410
    TIC4001-F18 tototto JanuariusJang ZhengShijieNUS
    TIC4001-F18 e02161618 Chenduo1412 e0260222
    TIC4001-F18 timmyly7 skyventus tototto
    TIC4001-F18 adi-kd0021 linqing42 timmyly7
    TIC4001-F18 binbinhui Yiheng0410 pigoliver
    TIC4001-F18 linqing42 timmyly7 skyventus
    TIC4001-F18 ZhengShijieNUS Chilaiping dgc5213
    TIC4001-F18 pigoliver Impala36 e02161618

    If the student you have been allocated to review has not created a PR (or the PR has a trivial amount of code), you can review the Backup PR to review provided in the allocation table. Failing both, pick a PR at random to review.

    • Step 3 Do the second PR review as follows.
      • Comment on other code quality guidelines (see the sections on Naming and Readability in this textbook chapter) you have learned so far. It's optional to comment on coding standard violations in this PR review.
      • The review allocation is given in the panel below.
    Tutorial Reviewer Second PR to review Backup PR to review
    TIC4001-F18 JanuariusJang dgc5213 binbinhui
    TIC4001-F18 Yiheng0410 e02161618 Chenduo1412
    TIC4001-F18 Chilaiping Yiheng0410 pigoliver
    TIC4001-F18 e0260222 linqing42 timmyly7
    TIC4001-F18 Chenduo1412 adi-kd0021 linqing42
    TIC4001-F18 skyventus ZhengShijieNUS Chilaiping
    TIC4001-F18 Impala36 e0260222 daiweinus
    TIC4001-F18 daiweinus timmyly7 skyventus
    TIC4001-F18 dgc5213 pigoliver Impala36
    TIC4001-F18 tototto Chilaiping dgc5213
    TIC4001-F18 e02161618 daiweinus adi-kd0021
    TIC4001-F18 timmyly7 JanuariusJang ZhengShijieNUS
    TIC4001-F18 adi-kd0021 skyventus tototto
    TIC4001-F18 binbinhui Impala36 e02161618
    TIC4001-F18 linqing42 tototto JanuariusJang
    TIC4001-F18 ZhengShijieNUS binbinhui Yiheng0410
    TIC4001-F18 pigoliver Chenduo1412 e0260222

    If the allocated PR is not suitable, use the same strategy as before to find an alternative PR to review.

    • Step 4 [When you receive reviews for your own PR] Respond to comments received. You are recommended to (but not obliged to) respond to comments received from peers, especially if the PR reviewer asked you for more info. As mentioned in these guidelines, do not get into arguments with PR reviewers/authors.

    tP: Set direction

    1 Start weekly project meetings

    • We recommend you start weekly project meetings now. You can use the meeting to do tP tasks, but also help each other do iP tasks. On a related note, it is also acceptable to discuss weekly post-lecture quiz (if any) together with team members as you do the quiz i.e., discuss and decide the answer collectively, but you should not give away your answers to someone who was not part of that discussion.

    2 Start a collaborative doc to take project notes before next lecture

    • Keep project notes in easy-to-use collaborative docs (Recommended: use a GoogleDoc). This document will be checked by the tutor at various points.
      Remember to choose a tool that allow public view access (not write access) e.g., GoogleDoc can be shared via a public link so that the document can be viewed by others. You'll be asked to submit this link to us in the next week.
      Make sure all you current and future project notes (if split into in multiple documents) are reachable via links given in this document and are viewable by the public.

    3 Decide on an overall project direction (user profile, problem addressed) before next lecture

    • Decide project direction, target user profile, and problem addressed: Use your first project meeting to discuss with your team members and decide your project direction, target user profile, and the value proposition of the product, as described in the panels below:

    As we are still at the early stages of identifying a problem to solve, do not think of the product (i.e., the solution) yet. That is, do not discuss the product features, UI, command format, and implementation details, etc. unless they are pertinent to the decision of the project direction.

    project expectations

    Outcomes

    The high-level learning outcome of the team project (tP):

    Can contribute production quality SE work to a small/medium software project

    Accordingly, the tP is structured to resemble an early stage of a small software project in which you will,

    1. conceptualize and implement a product, and,
    2. have it ready to be continued by future developers

    The focus of the tP is to learn the following aspects:

    • coding
    • working in a team
    • process/workflow
    • documentation
    • scheduling and tracking project progress, meeting delivery deadline
    • quality assurance

    Direction

    You may develop any product provided it is meant for users who can type fast, and prefer typing over mouse/voice commands. Therefore, Command Line Interface (CLI) is the primary mode of input.

    Constraint-Typing-Preferred

    The product should be targeting users who can type fast and prefer typing over other means of input.
    Reason: to increase comparability of products, and to make feature evaluation easier for peer evaluators.

    Recommendation-CLI-First

    Following from the Constraint-Typing-Preferred, if the app is optimized for the target user (graded under the product design criterion), a user who can type fast should be able to accomplish most tasks faster via CLI, compared to a hypothetical GUI-only version of the app. For example, adding a new entity via the CLI should be faster than entering the same data through a GUI form.
    Therefore, the input to the app needs to be primarily CLI. If you do implement a GUI, that GUI should primarily be used to give visual feedback to the user. While we don't prohibit non-CLI inputs, note that such inputs will reduce the suitability of the product to target users. Therefore, give CLI alternatives to mouse/GUI inputs, if applicable.
    Also keep in mind:

    • Regular typing is usually faster than using key combinations.
    • typing the full command and hitting ENTER will complete the taskOne-shot commands are faster over prompting the user to input one parameter at a timemulti-step commands. If you provide a multi-step command to help new users, you can also provide a one-shot equivalent for regular/expert users.

    • For example, an app to manage one of these:
      • Contact details
      • Bookmarks of websites
      • Tasks/Schedule
      • Location info
      • Thing to memorize i.e. flash cards, trivia
      • Forum posts, news feeds, Social media feeds
      • Online projects or issue trackers that the user is interested in
      • Emails, possibly from different accounts
      • Multiple types of related things e.g. Contacts and Tasks (if Tasks are allocated to Contacts)
      • ...

    You are strongly discouraged from developing a GUI application as it can increase the workload unnecessarily.

    Recommendation-No-GUI

    Creating a good Java GUI takes a lot of extra effort, which can easily push the tP effort beyond the expected range. In addition, good GUI design is not a learning outcome of this module. Therefore, you are strongly discouraged from creating a GUI application. Choose the GUI path only if you are willing to take the extra workload on top of the module's normal load.

    Target User & Value Proposition

    You are expected to:

    • Define a very specific target user profile.
      We require you to narrow down the target user profile as opposed to trying to make it as general as possible. Here is an example direction of narrowing down target user: anybody → teachers → university teachers → tech savvy university teachers → TIC4001 instructors.

      Be careful not to contradict given project constraints when defining the user profile e.g. the target user should still prefer typing over mouse actions.
    • It is an opportunity to exercise your product design skills because optimizing the product to a very specific target user requires good product design skills.
    • It minimizes the overlap between features of different teams which can cause plagiarism issues. Furthermore, higher the number of other teams having the same features, less impressive your work becomes especially if others have done a better job of implementing that feature.

    The size of the target market is not a grading criterion. You can make it as narrow as you want. Even a single user target market is fine as long as you can define that single user in a way others can understand (reason: project evaluators need to evaluate the project from the point of view of the target users).

    • Define a clear value proposition that matches the target user profile i.e., what problem does the product solve? how does it make the user's life easier?
      You should also define the scope clearly i.e., boundary beyond which the app will not help e.g., the app will help to manage tasks within a single project only (no support for multiple projects).
    • Optimize the product to the chosen target users i.e., add features that are especially/only applicable for target users (to make the app especially attractive to them).

      • Example 1: If the product targets TIC4001 instructors, there can be features that are applicable to them only, such as the ability to see a link to a student's project on GitHub

      • Example 2: If your app manages contacts, you can optimize its features based on,

        • the profession of the target user e.g. doctors, salesmen, teachers, etc.
        • the nature/scale of contacts e.g. huge number of contacts (for HR admins, user group admins), mostly incomplete contacts, highly volatile contact details, contacts become inactive after a specific period (e.g. contract employees)
        • what users do with the contacts e.g. organize group events, share info, do business, do analytics

        Your project will be graded based on how well the features match the target user profile and how well the features fit-together.

    Functionality Expectations

    The expected level of functionality from a team is roughly what you can achieve if each member contributes about the same amount of functional code as required by a i.e., if all requirements were met at the minimal level specifiedtypical iP.

    You will get full marks for implementation effort if you meet the expectation stated above. There are no extra marks for exceeding that bar. You are better off spending that effort in improving other aspects of the project.

    Team Expectations

    • Expectation Preserve product integrity i.e. ensure,
      1. features fit together to form a cohesive product,
      2. documentation follows a consistent style and presents a cohesive picture to the reader, and
      3. final project demo presents a cohesive picture to the audience.
    • Expectation Maintain product quality i.e. prevent breaking other parts of the product as it evolves.
    • Expectation Manage the project i.e. ensure workflow, code maintenance, integration, releases, etc. are done smoothly.

    Individual Expectations

    Individual Expectations on Implementation

    • Expectation Contribute to the functional code of the product.
      • User-visible features are preferred, but it is not a strict requirement.:
      • The enhancement(s) should fit with the rest of the software (and the target user profile) and should have the consent of the team members. You will lose marks if you go 'rogue' and add things that don't fit with the product.

    • Tip: Contribute to all aspects of the project e.g. write backend code, frontend code, test code, user documentation, and developer documentation. Reason: If you limit yourself to certain aspects only, you could lose marks allocated for the aspects you did not do. In addition, the final exam assumes that you are familiar with all aspects of the project.

    • Tip: Do all the work related to your enhancement yourself. Reason: If there is no clear division of who did which enhancement, it will be difficult to divide project credit (or assign responsibility for bugs detected by testers) later.

    Individual Expectations on Documentation

    • Objective: showcase your ability to write both user-facing documentation and developer-facing documentation.
    • Expectation Update the User Guide (UG) and the Developer Guide (DG) parts that are related to the enhancements you added. The minimum requirement is given below. (Reason: Evaluators will not be able to give you marks unless there is sufficient evidence of your documentation skills.)
      • UG: 0.5 or more pages
      • DG: 1.5 or more pages
    • Tip: If the UG/DG updates for your enhancements are not enough to reach the above requirements, you can make up the shortfall by documenting 'proposed' features and alternative designs/implementations.
    • Expectation Use at least 2 types of UML diagrams in your DG updates i.e., diagrams you added yourself or those you modified significantly.

    Individual Expectations on Testing

    • Expectation Write some automated tests so that we can evaluate your ability to write tests.

    🤔 How much testings is enough? We expect you to decide. You learned different types of testing and what they try to achieve. Based on that, you should decide how much of each type is required. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.
    There is no requirement for a minimum coverage level. Note that in a production environment you are often required to have at least 90% of the code covered by tests. In this project, it can be less. The weaker your tests are, the higher the risk of bugs, which will cost marks if not fixed before the final submission.

    Individual Expectations on Teamwork

    • Expectation Do an equal share of the team-tasks.

    Team-tasks are the tasks that someone in the team has to do.

    Here is a non-exhaustive list of team-tasks:

    1. Setting up the GitHub team org/repo
    2. Necessary general code enhancements
    3. Setting up tools e.g., GitHub, Gradle
    4. Maintaining the issue tracker
    5. Release management
    6. Updating user/developer docs that are not specific to a feature e.g. documenting the target user profile
    7. Incorporating more useful tools/libraries/frameworks into the product or the project workflow (e.g. automate more aspects of the project workflow using a GitHub plugin)

    • Expectation Carry an equal share of project roles and responsibilities.

    Roles indicate aspects you are in charge of and responsible for. E.g., if you are in charge of documentation, you are the person who should allocate which parts of the documentation is to be done by who, ensure the document is in right format, ensure consistency etc.

    This is a non-exhaustive list; you may define additional roles.

    • Team lead: Responsible for overall project coordination.
    • Documentation (short for ‘in charge of documentation’): Responsible for the quality of various project documents.
    • Testing: Ensures the testing of the project is done properly and on time.
    • Code quality: Looks after code quality, ensures adherence to coding standards, etc.
    • Deliverables and deadlines: Ensure project deliverables are done on time and in the right format.
    • Integration: In charge of versioning of the code, maintaining the code repository, integrating various parts of the software to create a whole.
    • Scheduling and tracking: In charge of defining, assigning, and tracking project tasks.
    • [Tool ABC] expert: e.g. Intellij expert, Git expert, etc. Helps other team member with matters related to the specific tool.
    • In charge of[Area XYZ] of the code: e.g. In charge of the code that deals with storage, etc. If you are in charge of an area, you are expected to know that area well, and review changes done to that code.

    Ensure each of the important roles are assigned to one person in the team. It is OK to have a 'backup' for each role, but for each aspect there should be one person who is unequivocally the person responsible for it. Reason: when everyone is responsible for everything, no one is.

    • Expectation Review each others work. Reason: reviewing skills is a learning outcome, and it is mutually beneficial.

    Your project should comply with the following constraints. Reason: to increase comparability among projects and to maximize applicability of module learning outcomes in the project.

    Constraint-Typing-Preferred

    The product should be targeting users who can type fast and prefer typing over other means of input.
    Reason: to increase comparability of products, and to make feature evaluation easier for peer evaluators.

    Constraint-Single-User

    The product should be for a single user i.e. (not a multi-user product).
    Reason: multi-user systems are hard to test, which is unfair for peer testers who will be graded based on the number of bugs they find.

    Constraint-Incremental

    The product needs to be developed in a breadth-first incremental manner over the project duration. While it is fine to do less in some weeks and more in other weeks, a reasonably consistent delivery rate is expected. For example, it is not acceptable to do the entire project over the recess week and do almost nothing for the remainder of the semester.
    Reasons: 1. To simulate a real project where you have to work on a code base over a long period, possibly with breaks in the middle. 2. To learn how to deliver big features in small increments.

    Constraint-Human-Editable-File

    The data should be stored locally and should be in a human editable text file.
    Reason: To allow advanced users to manipulate the data by editing the data file.

    Constraint-No-DBMS

    Do not use a Database Management System e.g., MySQLDBMS to store data.
    Reason: Using a DBMS to store data will reduce the room to apply OOP techniques to manage data. It is true that most real world systems use a DBMS, but given the small size of this project, we need to optimize it for TIC4001 module learning outcomes; covering DBMS-related topics will have to be left to database modules or level 3 project modules.

    Constraint-OO

    The software should follow the Object-oriented paradigm primarily (but you are allowed to mix in a bit other styles when justifiable).
    Reason: For you to practice using OOP in a non-trivial project.

    Constraint-Platform-Independent

    The software should work on the Windows, Linux, and OS-X platforms. Even if you are unable to manually test the app on all three platforms, deliberately avoid using OS-dependent libraries and OS-specific features.
    Reason: Peer testers should be able to use any of these platforms.

    Constraint-Java-Version

    The software should work on a computer that has version 11 of Java i.e., no other Java version installed.

    Constraint-Portable

    The software should work without requiring an installer.
    Reason: Testers may not want to install your product on their computer.

    Constraint-No-Remote-Server

    The software should not depend on your own remote server.
    Reason: Anyone should be able to use/test your app any time, even after the semester is over.

    Constraint-External-Software

    The use of third-party frameworks/libraries is allowed but only if they,

    • are free, open-source, and have permissive license terms (E.g., trial version of libraries that require purchase after N days are not allowed).
    • do not require any installation by the user of your software.
    • do not violate other constraints.

    and is subjected to prior approval by the teaching team.
    Reason: We will not allow third-party software that can interfere with the learning objectives of the module.

    Please post in the forum your request to use a third-party libraries before you start using the library. Once a specific library has been approved for one team, other teams may use it without requesting permission again.
    Reason: The whole class should know which external software are used by others so that they can do the same if they wish to.

    Constraint-File-Size

    The file sizes of the deliverables should not exceed the limits given below.

    • JAR file: 100MB (Some third-party software -- e.g., Stanford NLP library, certain graphics libraries -- can cause you to exceed this limit)

    • PDF files: 15MB/file (Not following the recommended method of converting to PDF format can cause big PDF files. Another cause is using unnecessarily high resolution images for screenshots).

    In addition, you are strongly encouraged to follow these recommendations as they can help increase your project score.

    Recommendation-Minimal-Network

    It is OK to use a reliable public API e.g., Google search but we recommend that you have a fallback mechanism (e.g., able to load data using a data file if the network is down).
    Reason: During the mass peer-testing session, the network access can be intermittent due to high load. If your feature cannot be tested due to lack of Internet, that will have to be counted as a major bug, to be fair to those whose app is being tested and bugs found being penalized.
    If you use NUS data (e.g., scrape data from an NUS website), please work with NUS IT directly to get their approval first. Even well-intentioned use of NUS data without approval can get you into serious trouble (has happened before). The teaching team will not be able to get approval for you as the use of NUS data is not a module requirement.

    Recommendation-Testability

    Avoid implementing hard-to-test (both for manual testing as well as automated testing) features or features that make your product hard-to-test.
    Reason: testability is a grading criterion. If you choose to implement such a feature, you will need to spend an extra effort to reach an acceptable level of testability. Here are some examples of features that are hard-to-test:

    • Features that depend heavily on remote APIs: Those APIs can block your access if they mistake your automated tests as a bot attack. Some remote APIs require setting up accounts, keys, login etc, that will irritate the testers of your product and give a low rating to the testability of your work.
    • Audio-related features: The peer testing of your product is done under exam conditions where it is not appropriate to play audio.
    • Features that require creating user accounts, login, logout etc.

    Recommendation-No-GUI

    Creating a good Java GUI takes a lot of extra effort, which can easily push the tP effort beyond the expected range. In addition, good GUI design is not a learning outcome of this module. Therefore, you are strongly discouraged from creating a GUI application. Choose the GUI path only if you are willing to take the extra workload on top of the module's normal load.

    Recommendation-CLI-First

    Following from the Constraint-Typing-Preferred, if the app is optimized for the target user (graded under the product design criterion), a user who can type fast should be able to accomplish most tasks faster via CLI, compared to a hypothetical GUI-only version of the app. For example, adding a new entity via the CLI should be faster than entering the same data through a GUI form.
    Therefore, the input to the app needs to be primarily CLI. If you do implement a GUI, that GUI should primarily be used to give visual feedback to the user. While we don't prohibit non-CLI inputs, note that such inputs will reduce the suitability of the product to target users. Therefore, give CLI alternatives to mouse/GUI inputs, if applicable.
    Also keep in mind:

    • Regular typing is usually faster than using key combinations.
    • typing the full command and hitting ENTER will complete the taskOne-shot commands are faster over prompting the user to input one parameter at a timemulti-step commands. If you provide a multi-step command to help new users, you can also provide a one-shot equivalent for regular/expert users.

    If you are not sure if your product complies with a certain constraint/recommendation, please seek clarification by posting in the forum (preferred) or emailing the supervisor.

    1. Project Grading: Product Design [ 5 marks]

    Evaluates: how well your features fit together to form a cohesive product (not how many features or how big the features are) and how well does it match the target user

    Evaluated by tutors

    Based on the product features.

    • Submission: Submit your product name, target user profile, the value proposition, and the public link to your collaborative project notes via TEAMMATES. You'll receive an email from TEAMMATES with the submission link. Only one member needs to submit on behalf of the team. All members can view/update the submission.
      Submission link will be sent to you by Mon, Aug 31st (reason: we need a few days to set up the submission system after teams have been finalized).