Skip to content

Application Plan (November 9 ~ December 9)

Jump to bottom
Markus Shriner edited this page Nov 9, 2020 · 1 revision

Homework 5: Plan

Team Member Names and Roles:

  • Harkiran Saluja, Designer
  • Victoria Huynh, Developer
  • Jill Nguyen, Developer
  • Markus Shriner, Project Manager

1. How will you coordinate your work?

Going forward, we have decided to use a similar approach to coordinating work like the one we have used so far in the quarter, as it has been effective in distributing work and ensuring that assignments are submitted on time.

The team has decided that the Project Manager (PM) will help coordinate the work between members of the team. While the PM will take primary responsibility for this, other members of the team will also provide their input so that the most efficient allocation of work is established. The goal of this is to allow each team member to focus on their respective areas of expertise (design, development, etc.) and provide input on scheduling based on their expertise.

To accomplish this, the team will work together to maintain a clear set of requirements and milestones to be followed throughout the project. The team will also coordinate to create deadlines for these milestones in order to make sure that work is completed in a timely manner. In the event of unexpected setbacks or complications, the team will communicate these events as soon as possible to each other so that a quick solution can be created.

To increase communication between team members, we will meet twice a week for class 1 hour and 50 minutes each time. If these meetings are not enough to coordinate and complete work, then we will have a check-in on Friday to compare work and share thoughts. If additional meetings are required then they will be scheduled as needed. The agenda for these meetings will be created following the previous meeting by the PM with input from all members of the team and communicated prior to the meetings or as the meetings begin.

2. What tools will you use to communicate?

Discord will be the primary communication tool used for communication since the class server and team channels are already there for text and voice communication. Using Discord allows our team to have a centralized location to meet and share messages while also checking updates for the class.

If Discord is unavailable or not working, we will use Zoom and/or Facebook Messenger as alternatives. Zoom is a suitable alternative as all members of the team use it on a regular basis, and it would allow us to communicate easily via video call. Facebook Messenger is also a great alternative tool for communication as it allows all members of the team to quickly send messages to each other. Discord has been picked over these alternatives as it allows its users to use both video and text chat while keeping all of the class resources easily accessible.

3. Who will own components in your architecture?

While every member of the team will work together to complete each component, our developers will share the primary responsibility of owning the components in our architecture. This is because they have the technical knowledge to fully understand the functionality of each component and ensure that each one is functional and correct. As such, the person in charge of each component is listed below.

GameModel - Victoria Huynh
SessionModel - Jill Nguyen
LobbyView - Jill Nguyen
OptionView - Jill Nguyen
PromptView - Victoria Huynh
ResultView - Victoria Huynh
GameController - Jill Nguyen & Victoria Huynh

4. What is your timeline?

In addition to completing and submitting assignments before their deadlines, we have created a timeline of milestones with deadlines. This timeline will be used to make sure individual components are completed in a timely manner so that a complete application can be delivered by December 9th.

  • November 9th
    • Review plan as a team
  • November 15th
    • Confirm design of the application
  • November 16th
    • Initial design review with the team
  • November 17th
    • If required, make updates to design
  • November 18th
    • Secondary design review with the team
    • If required, make additional design updates
  • November 22nd
    • Work on application front-end
    • Work on the following components:
      • LobbyView
      • OptionView
      • PromptView
      • ResultView
  • November 24th
    • Check-in with the team to discuss front-end updates
    • Continue working on front-end
  • November 25th - 29th
    • Thanksgiving weekend!
  • November 30th
    • Initial review of application front-end
    • Team discussion of front-end progress
    • Make sure design and front end implementation correlate with each other
  • December 1st
    • Work on the application back-end
    • Work on the following components:
      • GameModel
      • SessionModel
      • GameController
  • December 4th
    • Check-in with the team to discuss back-end updates
    • Continue working on the back-end
  • December 6th
    • Complete back-end and review with the team
  • December 7th
    • Conduct final verification
    • Final code review
    • Re-run automated tests
    • The team uses web application together
  • December 8th
    • Address any final issues
  • December 9th
    • Release completed application

5. How will you verify that you've met your requirements?

  • Automated tests will be run by the developer who wrote the tests after each component is implemented and/or changed.
  • The code will be written in separate branches for each developer and reviews will be done via pull requests. Code reviews will be done after each component is completely implemented. Developers will review the other developer’s code.
  • After front end development is complete, the team will meet to make sure all usability and front-end requirements are verified via the plans mentioned below.
  • Final verification will be done with the whole team after development is complete. All tests will be run to check if they pass and developers will do a brief final code review. The team will use the web app together to represent a group of users.

Requirements (verification steps are written below each requirement)

Before game

  1. The system should allow users to set a name before they enter a game lobby.
    • Have name input in the same view as game code input
    • Ensure both inputs are required (as in add required attribute)
  2. The system should allow users to create a game lobby.
    • Use Postman to send a request and check if the lobby is added to the database
  3. The system should allow users to enter an existing lobby by typing in the code to that lobby.
    • Use Postman to send a request and check if a player is added to the lobby
  4. The system should display 5 Mad Lib titles as clickable options to the user so that they can select a game.
    • Generate a game code to enter the lobby.
    • When you enter the lobby, you should see a list of clickable Mad Libs to choose from.
    • Hover over each of the Mad Libs titles to see if they are clickable (they change color and are underlined while hovered over)
    • Justification: We want there to be options to choose from when it comes to playing a Mad Lib, but we didn’t want to overwhelm the user with a lot of options. We wanted to make it as easy for users as possible by ensuring there is feedback when they hover over a title.
  5. The system should allow the user who created the lobby to start the game once they’ve selected a Mad Lib.
    • The button to start the game remains unselectable if a specific Mad Lib has not been chosen by the lobby’s creator.
    • If a specific Mac Lib is selected, the button to start the game becomes selectable by the lobby’s creator.
  6. The system should not allow more than 4 users in the same game lobby.
    • While there are less than 4 users in the lobby, other users may join.
    • If the number of users in the lobby is greater than or equal to 4, other users are blocked from joining the lobby.
  7. The system should store the Mad Libs templates sourced from the Mad Libs website and the team's own creations.
    • Perform code review to ensure that all Mad Libs are in the database
  8. The system should credit the Mad Libs templates that it gets from the Mad Libs website.
    • Generate a game code to enter the lobby.
    • When you enter the lobby, you should see a list of clickable Mad Libs to choose from.
    • Check to see if there is a credit to the Mad Libs website next to any of the Mad Libs.
    • Justification: If we do take a Mad Lib from the official Mad Libs website, we don’t want plagiarism and we need to give the credit where it’s due.
  9. The system should display Mad Libs templates handpicked by the team in alphabetical order by title.
    • Generate a game code to enter the lobby.
    • When you enter the lobby, you should see a list of clickable Mad Libs to choose from.
    • Check to see if that list of Mad Libs is in alphabetical order.
    • Justification: Alphabetization is a simple and easy way to organize elements, and it’ll be easy for children (our target audience) to understand and find titles quickly.
  10. The system should display to the players which other players are in the game lobby.
    • Generate a game code to enter the lobby.
    • Once in the lobby, copy the code displayed on the bottom left corner of the page to share the code with other people you want to play with.
    • When they enter the lobby, check to see if you see that they are in the lobby by looking to see which other players are in the lobby on the top right.
    • Justification: If someone sends the code to another person, and that other person joins the lobby, then the person who sent the code should be able to verify that by seeing their name in the list of players.

During game

  1. The system should be able to receive text input from every player in the game.
    • Perform code review to ensure the turns cycle through each player
    • In other words, ensure turns are sequential, not random
    • Ensure input is received before moving onto next player
  2. The system should be able to determine which user’s turn it is to input text.
    • Write tests to ensure that turns update when the previous player’s input is received
    • Test pass if turn field is updated in the database
  3. The system should request input from users when it is their turn.
    • Perform code review to ensure that prompt is displayed when it’s the specified players turn
  4. The system should display to a user when another user is currently taking their turn.
    • Generate a game code to the lobby. Ensure there is another person playing with you.
    • Choose a Mad Lib to play and start the game.
    • Input a word, and then while it’s the other player’s turn, check to see if the system tells you that the other player is typing in their word.
    • Justification: There should be no confusion as to whose turn it is to input a word, as all users should be able to tell otherwise there will also be impatience among the children.
  5. The system should send input information to the server for later use in the final Mad Lib.
    • Use Postman to send a request and check if inputs are being stored in the database
  6. The system should not request input from more than one user at a time within a game session.
    • Perform code review to ensure that only users whose turn it is receive a prompt
    • Because turn is stored, this should be verifiable
  7. The system should not request the same input specific part of speech at a specific point in the Mad Lib) that it has previously requested from any user in the current session.
    • Perform code review to ensure that prompts aren’t displayed more than once
  8. The system should be able to identify what input specific part of speech at a specific point in the Mad Lib) to request.
    • Perform code review to ensure that the program cycles through each prompt
    • In other words, ensure that the prompt to display is updated after each input is received
  9. The system should allow text input to be a minimum of 2 characters and a maximum of 25 characters.
    • Generate a game code to the lobby
    • Choose a Mad Lib to play and start the game
    • While inputting words, check to see if the system will let you proceed by either leaving it blank or having 1 character. Also check to see if the system stops you from going over 25 characters with your input.
    • Justification: Having 0 or 1 characters doesn’t give the input any meaning, and we want this to be fun for children and have them enjoy the input since it is the main element that makes the game enjoyable. Some children also like to type many characters at once, so we decided to go as far as 25 characters, but at the same time, we didn’t want the input to be completely indiscernible or take too long to read.
  10. The system should give all players at least one chance depending on the length of the Mad Lib to input a part of speech to contribute to the Mad Lib.
    • Perform code review to ensure the turns cycle through each player
    • In other words, ensure turns are sequential, not random

After game

  1. The system should be able to generate the completed Mad Lib using accumulated user inputs.
    • Write tests to ensure all inputs are included in the final Mad Lib
    • Tests pass if actual output matches expected output
  2. The system should format user inputs to properly fit within the Mad Lib with regard to appropriate punctuation and capitalization by removing any punctuation and making all words lowercase.
    • Generate a game code to the lobby
    • Choose a Mad Lib to play and start the game
    • Input random words until the game is finished. Make sure the words inputted have either capital letters or some form of punctuation.
    • Click “FINISH.”
    • When the final Mad Lib is outputted, check to see that all your inputs are there as you’re reading through the paragraph and ensure all the letters in the input are lowercase and the punctuation is removed.
    • Justification: We don’t want users to be confused while reading the output, so we are making inputs lowercase and removing punctuation in order to make it easier to read.
  3. The system should display the final result to all users when all inputs have been received.
    • Generate a game code for the lobby
    • Choose a Mad Lib to play and start the game
    • Input random words until the game is finished
    • Click “FINISH”
    • When the final Mad Lib is outputted, check to see that all your inputs are there as you’re reading through the paragraph
    • Justification: What makes Mad Libs fun is reading the output at the end, so the system should display the full paragraph with their input to the users so that the players can read it and have a laugh.
  4. The system should censor inappropriate language (determined by a predetermined list of words) with asterisks.
    • Check the list of words that will be censored in the code
    • Go to the site and generate a game code to the lobby
    • Choose a Mad Lib to play and start the game
    • Input random words until the game is finished, and make sure at least one of those inputs has a word that should be censored
    • Click “FINISH.”
    • When the final Mad Lib is outputted, check to see if the inappropriate words you inputted are replaced by asterisks
    • Justification: Since our target audience is children, we don’t want them to be reading or inputting inappropriate language, so we will censor anything of the sort.
  5. The system should allow users to replay Mad Libs with the same game lobby.
    • Write tests to ensure game state is reset when a replay request is sent to the server
    • Tests pass if game state is reset
  6. The system should display a prompt on the screen to encourage users to read the final story to each other.
    • Generate a game code to the lobby
    • Choose a Mad Lib to play and start the game
    • Input random words until the game is finished
    • Click “FINISH.”
    • When the final Mad Lib is outputted, check for a prompt above the paragraph that encourages you to read the story with your friends
    • Justification: The point of this game is to read the output and laugh because the input the user puts makes no sense in the context of the story. We want to encourage users to read the story aloud to each other so that they can have a laugh.

Compatibility

  1. The system should allow users to fully interact with it using any standard modern web browser on mobile or desktop.
    • Check the CSS code for @media queries to show there is responsive web and mobile design.
    • Make sure there are @media queries for mobile (> 600px) and large devices, such as laptop or desktop (> 992 px)
    • Access the system via desktop and check to see if it’s convenient to interact with (ex. * No elements are cut off the screen, pages are easy to access)
    • Access the system via mobile and check to see if it’s convenient to interact with (ex. No elements are cut off the screen, pages are easy to access)
    • Justification: It’s standard for design to be both mobile and desktop friendly, so we do not want to be deviating from these standards. Furthermore, kids may hop on a Zoom call with their friends while at home and could be playing via mobile.

Sessions

  1. The system should be able to host one or more game lobbies.
    • Use Postman to send a request and check if multiple lobbies are added
    • Justification: We want multiple groups of players to be able to play at the same time, which is why we want the system to be able to host multiple lobbies.
  2. The system should automatically disconnect a session if all players are idle for at least 20 minutes.
    • Perform code review to ensure session duration is implemented
Clone this wiki locally