Duration input is difficult to use when a duration that is not a round number of hours is desired

[nus-pe-bot]

When a duration that is not easily expressed as a decimal number (e.g. NOT 1 hour, 15 minutes, 30 minutes, 6 minutes, etc) is desired, the user will have to calculate the exact duration required in hours.

This is not particularly user-friendly, and can also be somewhat counter-intuitive:

Here, attempting to add a 20-minute meeting by setting duration = 0.3333 causes a 19-minute event to be added, even though 20/60 ~= 0.3333... and rounding that off to the closest 4dp number results in 0.3333.

The user would then have to use trial-and-error in order to determine that the duration has to, in fact, be 0.3334 for a 20-minute event to be created.

Steps to reproduce:

• Attempt to add a meeting with e.g. a 20-minute duration with add n/Tutorial 10 u/https://test.net d/01-01-2023 0200 dur/0.3333 m/1 r/Y t/Boring
• Realize that the time display rounds down, and your meeting is now 19 minutes long

---

_{[original: nus-cs2103-AY2122S2/pe-interim#2437] [original labels: severity.Medium type.FeatureFlaw]}

[NatalieTanML]

Team's Response

Thank you for raising this issue. However, even though it is a valid issue, our current use cases are targeted towards NUS students, where each lecture/tutorial is usually divided into 1 to 2 hour blocks. Hence, there is a low chance that users will need to specify a duration outside of these usual timings, and hence this is out of the scope of the current iteration of the app. Additionally, such durations are usually edge cases and not the usual 1 or 2 hour meetings, therefore it is considered Low instead of Medium severity. Finer granularity can also be implemented in the future; but the current goal is to have an app that serves the general NUS community and hence the current unit (in hours) is sufficient.

Duplicate status (if any):

--