daniele

Sadly it still needs work: it needs to localise the date field

A couple questions.

re: unexpected ranges:
As you pointed out, the arrows will always advance forward or backward by the amount of time between each date in a range (or by one if a single date is selected). I suppose if you selected a range of the entire month of August, you might expect the arrows to advance by entire months, regardless of # of days per month, but the way this is set up seems to cater more to selecting particular dates explicitly rather than entire months at a time. An exception to this would be if the user had clicked a custom menu preset called "August 08", which would bring more of a mindset that we're now navigating month-to-month, but I'm not sure if that case should call for a different arrow behavior or not. Your thoughts?


re: off by one error:
Here's a sample use flow:
1. click date range option
2. click a date in calendar one (10/17/2008)
3. click a date in calendar two (10/21/2008)
4. Click forward arrow. Date range reads 10/21/2008 - 10/25/2008. Both calendars advanced forward by the difference between the two dates.

Are you expecting it to instead go to 10/22/2008 - 10/26/2008? I can see how that might make more sense since dates wouldn't be repeated...

Thanks again!
Scott Jehl (Filament)

Regarding the off-by-one:
I don't expect the dates to be repeated if I use the arrows, but I guess that is partially because of my use case. I suspect there are three distinct use cases that would have to be selectable by the developer:
1. Arrows always change date range by just one day -- this would be most useful if you are looking for a particular time window, so you select the first through the fifth, and if that doesn't work, you click next to look at the second through the sixth and so on. I suspect this is probably the least useful, but maybe it would be more common for some types of travel planning and such.
2. Arrows change the date range to the next or previous adjacent time window -- in this case, if you have the first through the fifth selected, that is five days, so if you click next, you'd have the next five days, the sixth through the tenth.
3. The current behavior -- If you have the first through the fifth selected and you click next, it will select the fifth through the ninth. I'm not sure what the use case is here, but I'm sure someone else will come up with one. :)

I don't know what the best way to handle the month situation is. I just know for me, it makes sense to be able to deal with months and it makes further sense to be able to easily increment or decrement them. I have to think this would be a common enough use case to support intrinsically.

Since the arrows always move by day increment, there will always be the issue of picking a month with X days in it, then being surprised/disappointed that when you arrow back/forward, it may not cover the whole month (28 days vs. 31 days). So we might want to consider adding a "Months >" option which would open a custom picker with toggles to choose one or a range of months. We could probably show 5-10 years at a time like this:


2008: Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2007: Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
...

Or, even more compactly:
'08: J F M A M J J A S O N D
'07: J F M A M J J A S O N D

If the user selects a month or month range, the feedback would only show month and year to make it clear that is this only month increments, not day. The arrows would then move by month increment so we avoid the issue of not capturing a whole month when you use the arrows. This would affect the form value so maybe we just show the day too but under the covers, it would be nice to have this mode so we could increment by month.

Re: the date field not being localized, this uses the jQuery date picker widget that is localized and has a lot of options. We can show how to change the date format in our article.