niels9001 commented 4 years ago

Proposal: Duration Picker

A Duration Picker control that can be used for setting the duration of e.g. a timer or storyboard.

Summary

A Duration Picker would allow for setting something like a TimeSpan and allows users to set a duration. This is helpful for apps having user interfaces that are timespan based, such as movie storyboards, timers. An example of something that comes close (this doesn't go beyond 24 hours unfortunately):

DurationPicker

Rationale

It's a common control in desktop development (e.g. for timeline based user interfaces)
Inbox apps (such as the Alarms app) would benefit from this as well.
Great extension of the DateTimePicker and TimePicker family of controls.

Scope

..

Important Notes

Open Questions

MartinZikmund commented 4 years ago

Great idea! Hand in hand with the picker it would be great to have a DurationPickerFlyout in the feature proposal to make it complete 👍

mdtauk commented 4 years ago

Duration Picker is great, and the Alarms app has something similar.

Could it be combined with a Time Span Picker?

mrlacey commented 4 years ago

Does anyone have thoughts on how extensible this should be?

Is it important for this to have the ability to include years, months, weeks, days, hours, minutes, seconds? (I think only days, hours, minutes & seconds as they map directly onto the TimeSpan type.)
Would the ability to limit which periods can be selected be required? (With properties such as ShowDays, HowHours, etc.)
What about limits on maximum values? i.e. should it be possible to select more than 23 (or 24) hours from the hours option?
What should be the maximum option for number of days? Is there an argument for making it configurable? (i.e. a property for the maximum number of days that can be picked)
How to handle values larger than can be displayed? (such as a TimeSpan of several days being bound to a control instance that only shows hours and minutes.)
Is there a need to support negative durations? What's the use-case?
Should the control be able to support (and enforce--through error messages?) the ability to limit the maximum and minimum selectable values?

Could it be combined with a Time Span Picker?

I think this would be better to be considered a TimeSpanPicker that uses a Value field that is of the type TimeSpan because:

A Duration can be created from a TimeSpan but it's not always possible to go the other way as a Duration might not have a TimeSpan.
Duration has special cases to consider that TimeSpan doesn't.
Leaving the conversion to the developer who uses the control lets them deal with special cases such as Duration.Forever which may not always be treated the same way in the UI. To my mind, a DurationPicker would need to extend a TimeSpanPicker and add handling for special cases (with things like checkboxes for forever, or automatic.) A native DurationPicker could be a possible future extension but I don't see the need for it initially.

kikisaints commented 4 years ago

@mrlacey I'd imagine that if you were a developer that wanted to have a timer where a user could set over 24 hours as the duration, then you'd essentially be dealing with days and if you wanted a timer that handled more that 365 days, then you'd be dealing with years.

So perhaps having a duration picker that by default was a 24 hour timer, but would have properties on it like DurationLength="Days/Years", and if it was set to days, scrolling past 24 hours would wrap the hours column, but increase the days column by one, and similar for 365 days and the years column.

I don't think there's a need for negative time durations or to limit min/max values. A timer/countdown would only be moving "forward". There's no concept of past in this kind of control, that I can see.

If we were thinking in terms of specific dates, then I can see needing a limitation method of some sort, though.

mdtauk commented 4 years ago

Could it take a format string to change it to Days Hours Minutes, or even Week and Year scopes.

kikisaints commented 4 years ago

@mdtauk it may make more sense to receive a string in the same way the DateTime api does, and just format the duration picker accordingly.

Something like DurationLength="dd/hh/mm/ss" or DurationLength="yy/dd/hh" - then you could have a large combination of picker types depending on the string combo you gave it. Is that along the lines of what you were thinking?

mdtauk commented 4 years ago

@mdtauk it may make more sense to receive a string in the same way the DateTime api does, and just format the duration picker accordingly.

Something like DurationLength="dd/hh/mm/ss" or DurationLength="yy/dd/hh" - then you could have a large combination of picker types depending on the string combo you gave it. Is that along the lines of what you were thinking?

Exactly what I was thinking. The Time Picker is fixed into Hours, Minutes, Seconds - but durations of time are more varied. Nanoseconds, Milliseconds, Microseconds, as well as days, weeks, months, years.

There are some relevant issues that may need to be taken into account with this. #1440 #918 #925 #905

niels9001 commented 4 years ago

Having the flexibility to basically define the length as @kikisaints proposes would be great and very flexible.

We'd need to think about the UX though. If we stick to the current time/data picker design it might become confusing for the user to determine what value is belongs to what time unit, as this concept shows:

When the picker is configured to support days/hours/minutes/seconds it might be hard to distinguish the different units.

Proposed design: I'd propose to add a time unit indicator so it's more explicit:

We'd need to add this to the expanded state as well, here I'm following the timepicker in the Alarms app:

I think this model is pretty extensible and would meet multiple needs. Thoughts?

tibitoth commented 4 years ago

Please think about internatiomalization (i18n)

mrlacey commented 4 years ago

Please think about internatiomalization (i18n)

Beyond labels (for time units) and LTR are there any specific things that need to be considered here?

Are there, for instance, calenders that treat time (spans) differently? Are there cultures that order days, hours, minutes, and seconds differently? Anything else?

tibitoth commented 4 years ago

@mrlacey not really. Currently I'm thinking about the labels.

mdtauk commented 4 years ago

Some Google Image searches...

kikisaints commented 4 years ago

I think having the labels under each column both when in a popup and when in-line would make the most sense localization-wise.

Alternately, we could supply a guidance around or string at the base that tallies up what you're setting, something like what Alarms and Clock does:

But it would say 1 day, 9 hours, 26 minutes and 15 seconds from now.

Edit: @mdtauk although I like the "same line" look of the unit denoting being next to the hour/min/etc. - I worry it won't always work. Especially when introducing non latin-based languages like Arabic, Russian or Korean. Where the physical space the character takes up can vary.

mdtauk commented 4 years ago

Edit: @mdtauk although I like the "same line" look of the unit denoting being next to the hour/min/etc. - I worry it won't always work. Especially when introducing non latin-based languages like Arabic, Russian or Korean. Where the physical space the character takes up can vary.

I haven't spent enough time thinking on the control to have a proposal or suggestion as to how it looks. But I was always taught design is 1 third research (look at how others tackle to problem), 1 third planning (mock-ups and sketches etc), and the final third actually making the thing.

Consider those images part of the research :)

kikisaints commented 4 years ago

Absolutely - and I do appreciate it!

A lot of those research images are in the vein of what I'm thinking - however, for the sake of record, I wanted to also put out my own concerns around what I've seen from certain solutions which are similar to those that you've shown.

mdtauk commented 4 years ago

Absolutely - and I do appreciate it!

A lot of those research images are in the vein of what I'm thinking - however, for the sake of record, I wanted to also put out my own concerns around what I've seen from certain solutions which are similar to those that you've shown.

Here is a mockup of the inline labels done with the UWP control style

This would also work with the units split as was proposed in another issue - but it can potentially become a wide control, so not ideal for narrow form fields. Another idea would be to stack the label below, but would result in a taller control

mrlacey commented 4 years ago

On the I18N theme, need to also consider different pluralization options for different languages/cultures.

kmgallahan commented 4 years ago

Would it make sense here to handle keyboard input?

It would of course require keystroke handling logic and internal focus handling.

Logic:

Hitting any number key while the control is in focus would direct the keystroke to the left-most input/spinner, setting the internal focus indicator there
For single digit (0-9) inputs a single keystroke would advance internal focus to the next input/spinner (which means you could end up on the second spinner after 1 keystroke)
- For 1-9, hitting 5 sets the spinner to 5 and advances focus
For double digit (10-99) inputs two keystrokes would advance internal focus to the next input/spinner (a zero would be required first to input 1-9)
Set the currently focused spinner to the first number in the list that is still available to input
- 0 sets the spinner to 0 or 1 (depending on the starting number)
- 3 sets the spinner to 30, as opposed to 3
- 0+3 sets the spinner to 3
Alternative is to not require the 0, but would require a non-numeric keystroke to advance, and this might not be intuitive
On inputting the final digit focus could either loop back to the start or that could be treated as completing the selection
Hitting Enter would complete the full input selection with what digits are shown
Optionally, Tab could move focus to the next spinner, and Shift+Tab could reverse
Optionally apply bold or some other indicator to the last entered digit in the spinner to signify it was just input (e.g. for 1-99 hitting 3 = 30)

mrlacey commented 4 years ago

For additional reference, the native Windows 10 Alarms app doesn't support using the number keys to set a value but support using the up and down arrow keys to advance the number (up or down based on position in the list, not numerically increment or decrement it.) It also supports the PageUp and PageDown buttons to advance the number by 3 (although I'm not sure what the reason behind this value is.

Tabbing is done on each spinner individually and there is no internal looping of focus within the control. A focus visual is displayed around individual spinners. (as below)

michael-hawker commented 4 years ago

FYI @grochocki @rudyhuyn

grochocki commented 4 years ago

the native Windows 10 Alarms app doesn't support using the number keys

Improved keyboard support is something we would definitely want in the Alarms & Clock app.

I really like the direction @mdtauk took with the mockups here. It feels a lot more elegant than what we do today in the Alarms & Clock app, and I think it provides additional flexibility (single/double/triple units, various units, etc.).

pablojimpas commented 3 years ago

Does anyone plan to work on this control for the 1.0 release of Windows App SDK?

Gabboxl commented 1 month ago

Any update on this control?

microsoft / microsoft-ui-xaml