Content
View differences
Updated by Christophe Bliard almost 2 years ago
Part of ##40867
This work package is not finished yet.
### Summary
Motivation is to be able to record work with different units easily: for instance user can input "2 days 5 hours" (or "2d5h" in short format) and the system will understand it and save "21 hours". When displaying it, it will also use units, so 21 hours will be displayed as "2d 5h".
Initially, more units were supported so that values likes 210.5 hours would be displayed as "1mo 1w 1d 2h 30m" but it was too large to fit the columns in table, and its not convenient to compare values at a glance. It was realized during the validation phase.
To work around these issues, [units were reduced to days and hours](https://community.openproject.org/projects/openproject/work_packages/55466/activity). If there are minutes, they are represented as decimal part of the hour (for instance, "1 hour 45 minutes" is shown as "1.75h"). That's why some screenshots below and the UX issues section may show weeks and months: they are still describing this feature as it was initially planned.
There are also changes in how the user interacts with the popover to input the duration: the duration will be showing units as soon as the user has finished typing a value (but not while typing it).
Acceptance criteria have been updated to reflects the new units.
### Acceptance criteria
* **Allow users to input in the values for Work and Remaining work in different units**
* Based on [gitlab\_chronic\_duration](https://gitlab.com/gitlab-org/ruby/gems/gitlab-chronic-duration)
* Modal needs to give instant feedback of conversions so users are aware of how their input will be converted
* Valid inputs for 2 hours and 30 minutes:
* "2.5"
* "2.5h"
* "2h 30m"
* "2 hours 30 minutes"
* Valid inputs for 6 days:
* "48"
* "48 hour"
* "6d 0h"
* "6 days"
* **Display in mixed units everywhere**
* Work package tables (including totals and sums)
* Work estimates and progress popover
* Work package details page
* Activity (journal updates)
* Always display as
* "\_h" when less than a day (like "3h" or "0.23h"),
* "\_d \_h" when more than a day (like "4d 0h" or "123d 5.3h")
* **Admin settings to define:**
* Change title from "Working days" to "Working days and hours"
* Add one section:
* Hours per day:
* Input field, default value: 8 hours
* ~~Days per week:~~
* ~~Input field, default value: 5 days~~
* (removed as the number of units was reduced)
* ~~Days per month:~~
* ~~Input field, default value: 20 days~~
* (removed as the number of units was reduced)
* **Language:** Different units will only be supported in English
* _known potential inconsistency: date picker uses translated units for days for display_
#### Out of scope
* View query (question of scales, cut-off smaller units, same unit for the entire query)
* The ability to either:
* disable this display option or
* choose between existing mode (hours-only) and different units mode
* ~~Info icons that let users get the original value in hours on hover~~
* Project-level definition of number of hours per day
* User-level definition of number of hours per day
####
#### Visuals
**Current:**
**<img class="image_resized op-uc-image op-uc-image_inline" style="width:449px;" src="/api/v3/attachments/101238/content">**
**After:**
(outdated: only days and hours units are used. For instance "3w 4h" will be displayed as "15d 4h")
<img class="image_resized op-uc-image op-uc-image_inline" style="width:444px;" src="/api/v3/attachments/101239/content">
**Admin options:**
(outdated: only "hours per day" is available)
**<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/101553/content">**
#### Figma:
[https://www.figma.com/file/znrocQvFNLb5jXRXNo7oeD/Progress-estimation?type=design&node-id=1823-5375&mode=design](https://www.figma.com/file/znrocQvFNLb5jXRXNo7oeD/Progress-estimation?type=design&node-id=1823-5375&mode=design)
#### Implementation
Look at GitLab and their [gitlab\_chronic\_duration](https://gitlab.com/gitlab-org/ruby/gems/gitlab-chronic-duration) gem: it can render duration as "2 wks 1 day 1 hr" for instance. See also [this file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/gitlab/time_tracking_formatter_spec.rb) for more examples.
#### Anticipated UX issues (to be reviewed)
* **Difficult to scan and compare values:** Having everything displayed in the same unit makes it easier to scan and quickly compare values (to get a sense of scale). For example, compare the following set of values:
* Current display mode:
* 5h and 15h
* 18h and 56h
* 40h and 122h
* New display mode:
* 5h and 1d 7h
* 2d 2h and 1w 2d
* 1w and 3w 2h
* **Lack of user choice:** Users who are used to using hours might be disappointed or confused to find that they don't have a choice to continue seeing Work and Remaining work displayed in hours.
* **Wider cells required in tables:** In work package tables, we currently display Work and Remaing work in hours, so the width required for these cells is limited. With different units, these cells will have to be wider:
* Current lengths:
* Basic: "188 h"
* Sums: "188 h • Σ 269h"
* With changes:
* Basic: "3w 3d 4h"
* Sums: "3w 3d 4h • Σ 6w 3d 5h"
* **Lack of clarity on original values:** Without a _translation_ in hours (on hover, for example), users might have trouble getting a sense of the "actual" recorded value. Especially for users who might work in different regions where the work week or work day isn't the same as in Germany.
* Because the definition of these units is in at the instance admin level, regular users will simply not have access to the base values.
* ~~V1: Multi-unit input with fixed values~~
* ~~Can input W or RW in minutes, hours, days, week or month~~
* ~~Automatically gets converted to hours on save~~
* ~~V2: Custom values for hours per day, hours/days per week, days per month~~
* ~~V3: Hybrid units (display of entered data into the automatically "correct" scale, 42 hours = 1 week, 2 hours).~~
* ~~V4: Setting per query that lets you pick the unit (one unit, the same for all cells: hours, days, weeks, months)~~
Motivation is to be able to record work with different units easily: for instance user can input "2 days 5 hours" (or "2d5h" in short format) and the system will understand it and save "21 hours". When displaying it, it will also use units, so 21 hours will be displayed as "2d 5h".
Initially, more units were supported so that values likes 210.5 hours would be displayed as "1mo 1w 1d 2h 30m" but it was too large to fit the columns in table, and its not convenient to compare values at a glance. It was realized during the validation phase.
To work around these issues, [units were reduced to days and hours](https://community.openproject.org/projects/openproject/work_packages/55466/activity). If there are minutes, they are represented as decimal part of the hour (for instance, "1 hour 45 minutes" is shown as "1.75h"). That's why some screenshots below and the UX issues section may show weeks and months: they are still describing this feature as it was initially planned.
There are also changes in how the user interacts with the popover to input the duration: the duration will be showing units as soon as the user has finished typing a value (but not while typing it).
Acceptance criteria have been updated to reflects the new units.
### Acceptance criteria
* **Allow users to input in the values for Work and Remaining work in different units**
* Based on [gitlab\_chronic\_duration](https://gitlab.com/gitlab-org/ruby/gems/gitlab-chronic-duration)
* Modal needs to give instant feedback of conversions so users are aware of how their input will be converted
* Valid inputs for 2 hours and 30 minutes:
* "2.5"
* "2.5h"
* "2h 30m"
* "2 hours 30 minutes"
* Valid inputs for 6 days:
* "48"
* "48 hour"
* "6d 0h"
* "6 days"
* **Display in mixed units everywhere**
* Work package tables (including totals and sums)
* Work estimates and progress popover
* Work package details page
* Activity (journal updates)
* Always display as
* "\_h" when less than a day (like "3h" or "0.23h"),
* "\_d \_h" when more than a day (like "4d 0h" or "123d 5.3h")
* **Admin settings to define:**
* Change title from "Working days" to "Working days and hours"
* Add one section:
* Hours per day:
* Input field, default value: 8 hours
* ~~Days per week:~~
* ~~Input field, default value: 5 days~~
* (removed as the number of units was reduced)
* ~~Days per month:~~
* ~~Input field, default value: 20 days~~
* (removed as the number of units was reduced)
* **Language:** Different units will only be supported in English
* _known potential inconsistency: date picker uses translated units for days for display_
#### Out of scope
* View query (question of scales, cut-off smaller units, same unit for the entire query)
* The ability to either:
* disable this display option or
* choose between existing mode (hours-only) and different units mode
* ~~Info icons that let users get the original value in hours on hover~~
* Project-level definition of number of hours per day
* User-level definition of number of hours per day
####
#### Visuals
**Current:**
**<img class="image_resized op-uc-image op-uc-image_inline" style="width:449px;" src="/api/v3/attachments/101238/content">**
**After:**
(outdated: only days and hours units are used. For instance "3w 4h" will be displayed as "15d 4h")
<img class="image_resized op-uc-image op-uc-image_inline" style="width:444px;" src="/api/v3/attachments/101239/content">
**Admin options:**
(outdated: only "hours per day" is available)
**<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/101553/content">**
#### Figma:
[https://www.figma.com/file/znrocQvFNLb5jXRXNo7oeD/Progress-estimation?type=design&node-id=1823-5375&mode=design](https://www.figma.com/file/znrocQvFNLb5jXRXNo7oeD/Progress-estimation?type=design&node-id=1823-5375&mode=design)
#### Implementation
Look at GitLab and their [gitlab\_chronic\_duration](https://gitlab.com/gitlab-org/ruby/gems/gitlab-chronic-duration) gem: it can render duration as "2 wks 1 day 1 hr" for instance. See also [this file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/gitlab/time_tracking_formatter_spec.rb) for more examples.
#### Anticipated UX issues (to be reviewed)
* **Difficult to scan and compare values:** Having everything displayed in the same unit makes it easier to scan and quickly compare values (to get a sense of scale). For example, compare the following set of values:
* Current display mode:
* 5h and 15h
* 18h and 56h
* 40h and 122h
* New display mode:
* 5h and 1d 7h
* 2d 2h and 1w 2d
* 1w and 3w 2h
* **Lack of user choice:** Users who are used to using hours might be disappointed or confused to find that they don't have a choice to continue seeing Work and Remaining work displayed in hours.
* **Wider cells required in tables:** In work package tables, we currently display Work and Remaing work in hours, so the width required for these cells is limited. With different units, these cells will have to be wider:
* Current lengths:
* Basic: "188 h"
* Sums: "188 h • Σ 269h"
* With changes:
* Basic: "3w 3d 4h"
* Sums: "3w 3d 4h • Σ 6w 3d 5h"
* **Lack of clarity on original values:** Without a _translation_ in hours (on hover, for example), users might have trouble getting a sense of the "actual" recorded value. Especially for users who might work in different regions where the work week or work day isn't the same as in Germany.
* Because the definition of these units is in at the instance admin level, regular users will simply not have access to the base values.
* ~~V1: Multi-unit input with fixed values~~
* ~~Can input W or RW in minutes, hours, days, week or month~~
* ~~Automatically gets converted to hours on save~~
* ~~V2: Custom values for hours per day, hours/days per week, days per month~~
* ~~V3: Hybrid units (display of entered data into the automatically "correct" scale, 42 hours = 1 week, 2 hours).~~
* ~~V4: Setting per query that lets you pick the unit (one unit, the same for all cells: hours, days, weeks, months)~~