This is great, but could use a small tweak: Once you select a start date, it should grey out the dates before the selection in both calendars. That will make it easier to pick an end date that's valid. And vice versa for the end date.
Being from Wimberley, I can attest- it is rather difficult to get things done. I've still got a year or so left before I'm free. Glad to see our CS dept has some presence somewhere, eh?
In this same vein, I encountered a bug when I was picking a date after the default selected end date in Chrome 12.0.742.112. Essentially, I couldn't actually select the date. It wouldn't take.
The expected behavior is that I could not only select a date, but the "end date" calendar should jump to at least whatever month-year I selected my start date at if the selected start date comes after the selected end date. Even nicer if you tie the event to the month selection so that the end date calendar's minimum month-year is the furthest point the start date's month-year calendar has gone.
> Chrome updates automatically. So how does he/she avoid auto update?
Kill the auto-update daemon, remove it, prevent it from re-installing itself (by creating an empty "GoogleSoftwareUpdate" directory with write bits unset in place of the removed one). Done.
I have the EXACT same problem and I came here to see how many more people were running into this wall ... the thing is: I'm using Chrome's latest version (21.0.1180.82) ... is this a bug ?
It's sad how more and more people ignore non-mouse-or-touch-oriented users in their UIs. What about damn old keyboard support? Even if I modify input, nothing changes in UI. I'm not even mentioning such things as being able to easily navigate through days and months using arrow keys...
I have to do a ton of clicking to get to last year. It would be much faster to be able to type in arbitrary dates, too, and have the calendars update to reflect those new dates. And when I altered the date text in the editable field (the one you click to drop down the calendars), they did not honor my change; to be consistent, that field should also be readonly.
Same one? Seems to have a slick interface that does not require an apply button, does provide ranges and customizable range options, although it does not have easy keyboard input either.
I don't know about him, but that's no coincidence here. I was staring at the Win7 taskbar calendar while figuring out how to generate calendars for arbitrary months/years, and how to show the overlap from previous/future months. Add the Bootstrap table and button styles, and you end up with what you see.
"This is a great looking timepicker. One thing that I would love to see added is better keyboard support: for instance when modifying input by keyboard it would be nice to see the UI update, it would also be nice to be able to navigate through days and months using arrow keys."
I've had a hell of a time finding a good date AND time picker that compliments Bootstrap well. The combined ones I've found are just a horrid experience.
I have an application that I have to choose dates/times when sections of classes are.
I've seen this pattern a lot, particularly in websites for picking reservation dates (airlines, vacation homes, cars, etc...). It's very useful in that case, and I find that it's much easier for me to keep track of what I've entered that way.
You know what would be a really nice addition to this? Relative range options embedded directly in the picker, with labels like "this week", "next week", "this year", "last 30 days", etc.
Nice work. In the first example, I would put the From and To input boxes directly aligned with the corresponding calendars. Right now, with those inputs being aligned into a right column, they look like a totally different option
Looks nice, but I prefer hipmunk.com's date range selector. It doesn't require a start date picker and an end date picker. You select two dates and it knows the range.
With our new Bootstrap guidelines, we're trying to encourage activity in the upper-left, lower-left and lower right quadrants, and limit certain use cases that occupy the upper-right quadrant.
Nearly eighteen months ago, we gave developers guidance that they should not build form elements that mimic or reproduce the mainstream Twitter Bootstrap experience. And to reiterate, that guidance continues to apply today.
Parent is referencing the Twitter blog post about changes in Version 1.1 of the API which stirred some controversy because of the new rules and limitations for 3rd party developers. See the link below:
It's a joke? I totally missed that! My perception for these things is rather obtuse, so thanks for pointing it out. I thought that perhaps the Twitter devs themselves had jumped the shark.
84 comments
[ 3.9 ms ] story [ 201 ms ] threadhttp://cs.txstate.edu/~bm1362/projects/bootstrap-datepicker/
Yeah right, you expect me to believe that students ever go to class in San Marvelous?
Kidding, sort of. I didn't attend too often :|
The expected behavior is that I could not only select a date, but the "end date" calendar should jump to at least whatever month-year I selected my start date at if the selected start date comes after the selected end date. Even nicer if you tie the event to the month selection so that the end date calendar's minimum month-year is the furthest point the start date's month-year calendar has gone.
Kill the auto-update daemon, remove it, prevent it from re-installing itself (by creating an empty "GoogleSoftwareUpdate" directory with write bits unset in place of the removed one). Done.
This has links on how to do this on a Mac as well.
Ofcourse, Linux is more easily controlled especially if you aren't running a package-manager installed version of Chrome.
Nice-looking UI -/-> Good UI
And even more:
Nice-looking UI -/-> Good UX
http://filamentgroup.com/lab/date_range_picker_using_jquery_...
Same one? Seems to have a slick interface that does not require an apply button, does provide ranges and customizable range options, although it does not have easy keyboard input either.
http://www.eyecon.ro/bootstrap-datepicker/
Maybe it could just improve on it? they look the same ;)
It doesn't hurt to be friendly, you know.
https://github.com/dangrossman/bootstrap-daterangepicker/iss...
I have an application that I have to choose dates/times when sections of classes are.
Nearly eighteen months ago, we gave developers guidance that they should not build form elements that mimic or reproduce the mainstream Twitter Bootstrap experience. And to reiterate, that guidance continues to apply today.
https://dev.twitter.com/blog/changes-coming-to-twitter-api
I don't know of any similar limitations for Bootstrap, so you can probably safely assume that wickedchicken is kidding.
Not that I think Twitter's recent announcements are smart; quite the contrary. However, a false comparison distracts from the real problem.
I also think your comment is funny.