Content
View differences
Updated by Parimal Satyal about 2 years ago
Part of ##40867
Motivation is to be able to record work with different units.
GitLab for instance is using their [gitlab\_chronic\_duration](https://gitlab.com/gitlab-org/ruby/gems/gitlab-chronic-duration) gem to 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.
See below for subtasks
### Acceptance criteria
* **Display the values of Work and Remaining work in different units:**
* The values will continued to be stored in hours (h) in the database
* The different units will be:
* hours (h)
* days (d)
* weeks (w)
* months (m)
* _\[open\] Do we need months? This will require dealing with the complication of different month durations: 28, 30, 31 and leap years._
* **Display these different units in the following places:**
* Work package tables (including totals and sums)
* Work estimates and progress popover
* Work package details page
* Activity (journal updates)
* ...
* **Changes to Administrator settings page** (Calendar and dates → Working days)
* Change title from "Working days" to "Working days and hours"
* Add two sections:
* Work day in hours
* Input field, default value: 8 hours
* Work week in hours
* Input field, default value: 40 hours
#### Open points
* Should users be able to _input_ in units other than hours too? For example, should both "28 h" and "3d 4h" be allowed?
* What about "50h" (1w, 1d, 2h), or "18 d" (3w, 3d)?
* If input in different units allowed, will the input values nevertheless be translated to the correct units?
* On hover?
* On save?
* Should users also be able to define a week in _days_ instead of hours?
* If not, what if the user enters the value of a week to be 40h _but_ has also defined the work week as 4 days? Which value do we take? (Surely 40h, but this is then misleading, since this work would technically need 1 week and 1 day).
#### Out of scope
* 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 days, weeks and months
#### Anticipated UX issues
* **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 • Σ 6w 3d 5h"
* With changes:
* Basic: "3w 3d 4h"
* Sums: "3w 3d 4h • Σ 269"
* **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.
#### Visuals
**Current:**
**<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/101238/content">**
**After:**
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/101239/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)
Motivation is to be able to record work with different units.
GitLab for instance is using their [gitlab\_chronic\_duration](https://gitlab.com/gitlab-org/ruby/gems/gitlab-chronic-duration) gem to 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.
See below for subtasks
### Acceptance criteria
* **Display the values of Work and Remaining work in different units:**
* The values will continued to be stored in hours (h) in the database
* The different units will be:
* hours (h)
* days (d)
* weeks (w)
* months (m)
* _\[open\] Do we need months? This will require dealing with the complication of different month durations: 28, 30, 31 and leap years._
* **Display these different units in the following places:**
* Work package tables (including totals and sums)
* Work estimates and progress popover
* Work package details page
* Activity (journal updates)
* ...
* **Changes to Administrator settings page** (Calendar and dates → Working days)
* Change title from "Working days" to "Working days and hours"
* Add two sections:
* Work day in hours
* Input field, default value: 8 hours
* Work week in hours
* Input field, default value: 40 hours
#### Open points
* Should users be able to _input_ in units other than hours too? For example, should both "28 h" and "3d 4h" be allowed?
* What about "50h" (1w, 1d, 2h), or "18 d" (3w, 3d)?
* If input in different units allowed, will the input values nevertheless be translated to the correct units?
* On hover?
* On save?
* Should users also be able to define a week in _days_ instead of hours?
* If not, what if the user enters the value of a week to be 40h _but_ has also defined the work week as 4 days? Which value do we take? (Surely 40h, but this is then misleading, since this work would technically need 1 week and 1 day).
#### Out of scope
* 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 days, weeks and months
#### Anticipated UX issues
* **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 • Σ 6w 3d 5h"
* With changes:
* Basic: "3w 3d 4h"
* Sums: "3w 3d 4h • Σ 269"
* **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.
#### Visuals
**Current:**
**<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/101238/content">**
**After:**
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/101239/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)