Adding Event Length

[Caleb-Cohen]

Intro

Tech spec outlines the technical details and requirements for Together. It provides a clear and comprehensive description of the product's features, functionality, performance, and design specifications, which will be used by developers, engineers, and other team members to guide the development process.

The purpose of this tech spec is to ensure that all members of the development team have a common understanding of the product's requirements and technical specifications, and to provide a clear roadmap for the development process. By following the guidelines outlined in this tech spec, we can ensure that the final product meets the needs of our users and is delivered on time and within budget.

Instruction

• Review the summary below
• Investigate options and solutions
• Complete the tech spec
  • Not every field needs to be completed. Delete any field that is not relevant to the solution.
• Present your findings during standup!

Summary

Investigate the usage of replacing end time with length of event.

The Task

Summary is self-explanatory.

Potential Problems

• Backend testing validation

Who to contact

When you are done

• Comment on this issue that you've completed the tech spec
• Share the completed document in the issue below
• Prepare to present, if necessary

[Caleb-Cohen]

@gflacruz

[gflacruz]

Summary:

Provide a short (1-2 sentences) overview of the project, including its purpose and goals.

Replacing the end time entry input to to just ask the user for a duration instead. The goal is to prevent the user from submitting incorrect end dates and hopefully be a more intuitive process.

Scope:

Define the scope of the project, including what it will and will not include. List the features, functions, and requirements of the project.

• Two drop downs added (hours and minutes) to the single event creation form
• Function that grabs duration and calculates an end time for the form
• Validation so that users can't input 0 duration or a duration longer than the max

Data model:

No changes to data models should be necessary since we should be able to calculate and submit a new end date with the user's duration input.

User Stories:

User will now enter a duration when creating an event.
User will then select between between two drop downs one for hours (thinking 0-6) and one for minutes (thinking 15 minute intervals)

Implementation Details:

Provide details around how the feature will be implemented, and justify any decisions made. For example, this may include stuff that looks like:

Two drop downs will need to be created for hours and minutes. We will then need to grab the initial start date, convert the duration to milliseconds, calculate the new end date that will passed along, and finally do a validation check for any edge cases.

APIs:

N/A

Security/Privacy:

N/A

Testing:

Possibility of a test or validation needing to be added to ensure user doesn't input 0 hours and 0 minutes as a duration but I believe the current validation will prevent this due to the end date not being after the start date, which should throw an error. Current tests will need to be updated since we will now be allowing users to have a different start date and end date for single events to cover the edge case of an event taking place in times when the day changes. (for example 11:00pm to 12:30am next day)

Open Questions:

What is the maximum duration that we think any one event should be?
Do we like the idea of limiting the users inputs with two drop downs (hours and minutes?)
Should we only allow users to have 15 minutes intervals for the duration or allow any minutes 0-59? (x:00, x:15, x:30, x:45?)

Deployment:

N/A

[Caleb-Cohen]

Summary:

Provide a short (1-2 sentences) overview of the project, including its purpose and goals.

Replacing the end time entry input to to just ask the user for a duration instead. The goal is to prevent the user from submitting incorrect end dates and hopefully be a more intuitive process.

Scope:

Define the scope of the project, including what it will and will not include. List the features, functions, and requirements of the project.

• Two drop downs added (hours and minutes) to the single event creation form
• Function that grabs duration and calculates an end time for the form
• Validation so that users can't input 0 duration or a duration longer than the max

Data model:

No changes to data models should be necessary since we should be able to calculate and submit a new end date with the user's duration input.

User Stories:

User will now enter a duration when creating an event. User will then select between between two drop downs one for hours (thinking 0-6) and one for minutes (thinking 15 minute intervals)

Implementation Details:

Provide details around how the feature will be implemented, and justify any decisions made. For example, this may include stuff that looks like:

Two drop downs will need to be created for hours and minutes. We will then need to grab the initial start date, convert the duration to milliseconds, calculate the new end date that will passed along, and finally do a validation check for any edge cases.

APIs:

N/A

Security/Privacy:

N/A

Testing:

Possibility of a test or validation needing to be added to ensure user doesn't input 0 hours and 0 minutes as a duration but I believe the current validation will prevent this due to the end date not being after the start date, which should throw an error. Current tests will need to be updated since we will now be allowing users to have a different start date and end date for single events to cover the edge case of an event taking place in times when the day changes. (for example 11:00pm to 12:30am next day)

Open Questions:

What is the maximum duration that we think any one event should be? Do we like the idea of limiting the users inputs with two drop downs (hours and minutes?) Should we only allow users to have 15 minutes intervals for the duration or allow any minutes 0-59? (x:00, x:15, x:30, x:45?)

Deployment:

N/A

Hey @gflacruz can you post this to discussions?

[gflacruz]

Yup. I will do it now.

[Caleb-Cohen]

Closed due to going a different route on this issue.

[Caleb-Cohen]

whoops, mistake.