TimeSpanPicker with day and week support

Dec 19, 2012 at 8:05 AM

TimeSpanPicker is a great control, I use it very often.

Unfortunatly I missed something. TimeSpan Ends not after 24 hours. It is sometime necessary to have greater time spans, like days or even weeks. I extended the control to also have sliders for days and weeks. They are shown only, if the maximum is greater then a day or week, using the same logic as right now, To Support month and year makes no sense, since the span is not deterministic.

If there is an interest to include the Extension into the control here or someone else will have the sources, then contact me.

Coordinator
Dec 19, 2012 at 8:03 PM

I see where you're coming from but at that scale, it starts getting a bit crowded.

Seconds, Minutes, Hours, Days, Weeks, ...  I think it almost becomes a sliding scale then for resolution.  if you're going 3 weeks out, do seconds or even minutes really matter?

Can you give me some use cases where you'd want a timespan of a 3 weeks, 2 days and 4 hours?

Dec 20, 2012 at 8:19 AM
Edited Dec 20, 2012 at 8:24 AM

That's a good point and may be my fault not explaining the behavior at all. There is not really a use case you mentioned.

First, the current control is limited to a maximum of 24 hours (correct me, if I'm wrong), which is sometimes not enough. What value is to be entered if you will "go 3 weeks out"?
Second, the lowest value for a step is one second, milliseconds are also not supported.
The TimeSpan class has no such limitations.

I use the that timespan control in an app for controling my heating in a cottage. And therefor I use a hardware where you can set a timespan which is internally an integer representing a value in minutes, so the maximum is 65535 minutes, which is  45 days and 12:15:00 hours. And therfor I needed a control. Sure I could implement my own, but why not to extend the current one. And providing the user only an integer selector and let himself calculate the correct timespan was not my intention.

So I added support for milliseconds, days and weeks. It displays only up to three sliders (that's to answer your concerns about an overcrowded UI), depending on the step and maximum value like the current control does. It is a bit up to the developer to select usefull values. So the developer has to set step at least to 1 minutes if he wants to have a day slider or to 1 hour if the week slider shall be shown.

Milliseconds I have added, since the hardware I use also has the ability to send trigger pulses with a length lower then a second.

Since there is no official time format displaying weeks, I also made here some assumptions. The timespan control checks, if there is a "w" within the display format. If so, the slider for weeks is displayed and the day value is limited to 7, otherwise no week slider is displayed and the day maximum is limited to the timespan limit given to the control.

Could that answer your questions?

Coordinator
Dec 20, 2012 at 5:45 PM

First, I see what you're using it for.  To me, thinking what I would do for a large timespan, I would have date and time pickers that default to the current datetime and you manually do a diff between them.  That is what most calendar applications do.  For your use case, I would say "I want my house on for 8 hours every day for the next 3 weeks" instead of "I want my house on for the next 3 weeks". 

More so, just because an actual programming class supports something doesn't mean that should be bubbled up to an end user.  Also making complex controls extremely flexible is hard.  DatePicker/TimePicker/TimeSpanPicker work largely since they expose a very finite set to an end user and the developer.

Exposing new control metaphors on the same control to do the same behavior breaks the user's experience.  This works for you since you want it to work / look that way where a normal end user wants it to look more "system" style.  My default user with ease of use cases is my mom (it seriously is).  Having the default style + slider controls would confuse her.  Maybe I'm misunderstanding how you created the control but based on what was talked about, i'm seeing a hybrid of control types.

Does it make sense to display Milliseconds, Weeks, Months?  This is where I think you need a sliding shift. 

If you need a month resolution, does seconds make sense anymore?  Could I see having 4 of the spinners, sure, but it starts getting crowded really quick.  If you expose months, does weeks make sense?

Dec 20, 2012 at 6:41 PM

I do also understand, that it is problematic to extend such an often used control, it may break other applications. That's why I asked here, and if this is common opinion (currently it is only yours), then I will reject my suggestion.

What I do not get is, how you can use Date- and TimePicker to pick a TimeSpan. TimePicker can work (then why we have a TimeSpanPicker?), but DatePicker is unusable. A TimeSpan of a Month or Year makes no sence, it has indeterministic length, what is a TimeSpan of 1 Month, 28, 30, 31 or even 29 days? And how would you provide the user to enter a TimeSpan of 30 hours? Shall he enter 1 day and 6 hours using two controls? And even the DatePicker maximum will be then 31 days. To change your use case "I want my house on for 8 hours every day for the next 3 weeks", how it would work for my 30 hours example? Shall the user select 5 times for six hours?

You're right, if I need month resolution, then seconds don't make sense. As I told you, my implementation shows only up to three spinners. If you set step resolution to some seconds, then you get only seconds, minutes and hours spinners displayed, in case of minutes as a step resulution, you can have minutes, hours and days spinners, not weeks.

As I read you posting more carefully, it seems that you misunderstood me, because of my english. I used the therm "slider" and meant the "spinner", sorry, my fault. So, the style of the control is not changed at all, it has only the spnners. This shouldn't confuse someone. Currently the logic of the steps influences the lowest spinner to be shown and the maximum value influenecs the highest spinner display. This behaviour is kept but you have an additional spinner for milliseconds and two for days and weeks.

It would be great to hear any other opinions. If they have the same, then ces't la vive, I use my TimeSpanPicker how I extended it since it fullfills my needs. Posting here in this forum I would give someone a chance to hear about my extensions. May be it was the wrong way and I shall blogg it somewhere else.

Coordinator
Dec 21, 2012 at 3:37 PM

Sounds cool and a good addition.  I have a lot of questions in your implementation however. Submit a patch

create a datetime from each start and end date and time picker. From there you subtract the two and get a timespan.