Duration Data Type

[ghislaineguerin]

The specs related to issue #241 are ready for review. Please take a look at the attached document and follow the review guidelines.

Document Link

https://wiki.mathesar.org/en/design/specs/data-type-duration

@mathemancer @kgodey @pavish, your feedback is required by Tuesday 17th. Please plan your review so that at least one round of changes can be made and reviewed if needed.

[kgodey]

@ghislaineguerin Nice work on this! Just a couple of points:

(1) I think we should support the same "range" grouping that we support for numbers for durations, since durations are fundamentally numbers. This should be in addition to the hour/minute/second grouping that you have.

(2) You only have hours, minutes, and seconds as unit options for durations. Durations could also involve days, weeks, months, etc.

(3) I think it would be better to replace "greater than" with "longer than" and "lesser than" with "shorter than" for durations. I know I didn't spec it out in the issue that way, I realized while looking at the prototype that it would be easier to read.

[ghislaineguerin]

@kgodey

1. Agreed, I have updated the document.
2. Updated
3. Updated

[kgodey]

(1) I think the range control needs to show users what the unit is. They're not going to know what 200 means in this case.

(2) The display format options still show only hours, minutes, and seconds. The grouping options look good.

(3) When you click on "longer than", the dropdown reverts to "greater than". Otherwise it looks good.

[pavish]

@ghislaineguerin This looks good to me.

Kriti seems to have covered all the thoughts I had.

[ghislaineguerin]

@kgodey @pavish
I have updated the specs to include the global data type options. The duration type updates include fixes for:

• Formatting duration display
• Showing or hiding time unit labels (1:00 vs 1 hour 0 minutes)

[kgodey]

Looks good, thanks!

[pavish]

@kgodey @ghislaineguerin

(1) How would the UX for editing a duration cell on the table look, when there are years/months, along with unit labels are involved?

(2) Would the API accept duration as per the display format, or would it only communicate in epoch time milliseconds? This is not related to the frontend UX, but knowing this would help with me planning things in advance for any UX concerns that may arise.

(3) We could potentially use a similar representation as the option I've specified for date/time in #530 (reply in thread), which I would prefer for duration as well. However, I'm not sure which offers a better UX between this option and the checkbox based prototype. Customization depends on how (1) and (2) would be handled.

[pavish]

@kgodey My bad, I mentioned epoch time instead of milliseconds. The API structure makes sense.

I would like to hear both of your thoughts on using the custom input field (the comment from date/time format) for duration.

[kgodey]

@pavish I commented on the date/time discussion and said we should only pick from a list of presets for the MVP (to avoid complexity). I don't see the benefit for a custom input format for duration if we're not doing it for date/time.

I would either:
(1) pick from a preset list for duration as well.

• Using presets might be harder for duration because they involve different permutations of years, weeks, months, days, hours, minutes, and seconds, and it would make the list long.
• We could avoid the problem by only supporting hours, minutes, and seconds for the first version, but this may not work for all types of data.

(2) use the previous version of the design with checkboxes

[pavish]

@kgodey @ghislaineguerin I would like to understand the displayed value for a duration with an example.

Let's assume a duration: 1Y 11M 8D 5H 2m 1s 100ms

Irrespective of the design, if we select the format with only minutes and seconds i.e (mm:ss), the displayed value would be 998222m 1s.

If we select only months (MM), it would be 23M.

It doesn't make much sense to specify explicit formats for duration, with respect to individual units.

A better option might be to allow the user to select a range, of highest accuracy to lowest accuracy.
eg.,
Month -> hours would display duration as M:D:H. For the above example, it would be 23M 8D 5H
Hours -> ms would display duration as H:m:s:ms. For the above example, it would be 16757H 2m 1s 100ms
Auto would display units as they increase, eg., if days spill over 30, it will display months + days. The above example would display as 1Y 11M 8D 5H 2m 1s 100ms

User can select either Auto, or a range with highest unit and lowest unit. Thoughts?

[kgodey]

@pavish Your idea sounds good to me, although I think we'd have to do weeks instead of months for accuracy (months are different lengths and it might mislead users). It would end up being 1Y 48W 2D 5H 2m 1s 100ms in your example.

[pavish]

@kgodey I agree, accuracy of months is a problem.

I personally would prefer having months since it's something I am used to most, rather than weeks. I generally assume a month to be 30 days, whenever I deal with durations, but those are for projects where the duration was just representative and accuracy wasn't a concern.

For our MVP, I am okay with omitting months. If there are user requests to include them later, we can reconsider it.

[ghislaineguerin]

@kgodey @pavish
I've talked with Kriti, we decided that selecting a minimum and max time unit would solve our problem.

[kgodey]

@ghislaineguerin Can we also have the format preview box back? I think that would be useful, especially with the showing unit labels.

[pavish]

@kgodey @ghislaineguerin It just occurred to me, if we have 2 dropdowns, I think it may confuse the user.

1. Min time unit cannot be higher than max time unit. In the above image, if the user changes min time unit to weeks, max time unit will have to be either automatically updated to anything >weeks, or show an error.
2. Can we show a range slider instead? Or could you please update the behaviour in such scenarios and other error states for the UX. None of the data type switching prototypes contain any loading or error states. It would be better to have them right away, since contributors are working on them.
3. As discussed here: Duration Data Type #536 (reply in thread), we can remove months from the available options.

[ghislaineguerin]

@pavish we had considered the slider, but I'm worried about labeling each step within the space available.
Could we make the choices within min and max dependent on each other? I prefer to disable some options rather than throwing errors. So for example, if the min is set to hours, you can't have minutes or seconds as a max value.

[ghislaineguerin]

@pavish @kgodey I have updated the prototype. I think we can do the following:
We can allow users to select an initial value and then based on that, we can either:

• Disable the invalid options in the other dropdown
• Allow selection of invalid, but reset the other so that user selects a new value (might be confusing without a warning)
• Allow selection of invalid, and provide an error message "max value must be..."

[kgodey]

@ghislaineguerin I think disabling the invalid options would work best.