Open niels9001 opened 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 👍
Duration Picker is great, and the Alarms app has something similar.
Could it be combined with a Time Span Picker?
Does anyone have thoughts on how extensible this should be?
TimeSpan
type.)ShowDays
, HowHours
, etc.)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:
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.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.@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.
Could it take a format string to change it to Days Hours Minutes, or even Week and Year scopes.
@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 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"
orDurationLength="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
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?
Please think about internatiomalization (i18n)
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?
@mrlacey not really. Currently I'm thinking about the labels.
Some Google Image searches...
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.
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 :)
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.
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
On the I18N theme, need to also consider different pluralization options for different languages/cultures.
It would of course require keystroke handling logic and internal focus handling.
5
sets the spinner to 5 and advances focus0
sets the spinner to 0 or 1 (depending on the starting number)3
sets the spinner to 30, as opposed to 30
+3
sets the spinner to 30
, but would require a non-numeric keystroke to advance, and this might not be intuitiveEnter
would complete the full input selection with what digits are shownTab
could move focus to the next spinner, and Shift
+Tab
could reverse3
= 30)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)
FYI @grochocki @rudyhuyn
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.).
Does anyone plan to work on this control for the 1.0 release of Windows App SDK?
Any update on this control?
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):
Rationale
Scope
..
Important Notes
Related issue: https://github.com/microsoft/microsoft-ui-xaml/issues/1440
Open Questions