Clip Man


Daniel Einspanjer's journal

Data warehousing, ETL, BI, and general hackery

Previous Entry Share Next Entry
The best DHTML date range picker I've ever seen
Clip Man
Filament Group's Date Range Picker

It uses jQuery and a JavaScript date parsing library by the name of Date.js.  This thing is simply amazing.  Some of the reasons I think so:

  • The developer can configure a start and end date limits based on what is valid for the system (e.g. if you only have data going back to 1999, no sense in letting the user chose a date in 3000 BC)
  • The developer can configure a set of predefined ranges such as "Last week", "Month to date", "Year to date".
  • If the developer allows it, the user can use any combination of preconfigured ranges, a single date, an arbitrary range of dates, or they can use the back and forward arrows to roll the current date range forward or back.
  • It is smooth and crisp, able to be easily themed, and seems pretty extensible/tweakable.
It is still a work in progress (they just released it today), but I think it is still usable.  The only downside that I've found so far is that the back and forward arrows in this very first released version can produce some unexpected ranges.  They are currently strictly math based, so if you do something like select the current month and then hit the back arrow thinking it will select the previous month, you'll probably get something slightly different since most adjacent months don't have the same number of days.

I'm also pretty sure it has an off by one error in it that I suspect they'll fix shortly.  If you select Sunday to Saturday of a week and then scroll backward, the next range is actually Monday to Sunday and the next Tuesday to Monday...

Ignore these nitpicks and go check it out right away if your website needs a date picker though.  To get such a fantastic widget in the very first release can only mean that it is going to be the bee's knees after a little public beta testing.

Powered by ScribeFire.

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

Great writeup - thanks!

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)

Re: Great writeup - thanks!

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.

Month increment

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.

  • 1

Log in

No account? Create an account