Since I was making a new theme for dojo http://www.nikolaionken.com/dojo/images/dojo-nihilo_03.png I stumbled over the current version of the datepicker (I was about to make some design for it) and found that it was in a quite not yet usable state (which is not a new discovery).
I wanted to give my concrete suggestion on how it should look like since the trac item is closed or prosponed to after the 1.0 release.
My main concerns with having a time picker are solely usability. I am currently writing an application for a university which administers besides other stuff the schedule of teachers, students, etc. (>2000 students and teachers). Now the person doing the administration has only one thing in mind and thats 'get it done fast'. The timepicker from 0.4 proves to be too complicated (Here we use 01 - 24, and am/pm seems to cause confusion sometimes :) ) and the current one as well. What we need would be:
- Keyboard friendly (skipping through times with cursor, tab and all that stuff)
- Fast
- No mouse needed!!
The only usale time picker I can imagine is a simple combobox-style dropdown with predefined values (See google calendar).
This enables fast skipping of times - I enter 13: and get all presets of 13:XX, I enter 1 and get all presets of 1XXX, I can use the cursor and all other great features of combobox.
In regards to development time this should be a super fast one since it really only is a combobox with predefined values and custom time values.
I know that this solution is not fancy and great looking, but in real life - or at least in a heavy used scheduling situation - its all about speed and usability.
nikolai
TimeTextBox, not DateTextBox, right?
Yes, TimeTextBox has been the subject of much debates and strong opinions. Interesting idea about the Combobox though, I don't think I've heard that one before. We've heard "spinner" and "four separate drop downs (for hour, minute, second, am/pm)" quite a bit.
Just to confirm, above you first wrote "DatePicker" but really you are talking about picking a time, right?
All dijit widgets are supposed to be keyboard friendly for a11y reasons and also for the reason you mentioned (fast data entry).
no a11y on Date/Time popups, I think
I think the current Date/TimeTextBox widgets are technically accessible via keyboard and otherwise, but I think we cut a corner by not making the popups totally accessible, so it's not a perfect experience for the disabled and/or keyboard users, but hopefully it's possible to achieve what needs to be done. That said, I don't think we're ruling out making the popups more accessible...
Is there a way you think we could make the current design work, with the right keyboard support? maybe with some sort of wildcard match like you describe (though that sounds tricky)
Hopefully the new TimePicker is localized properly, such that 24 hr and am/pm conforms to local conventions (you may need to set djConfig.locale -- if you find that it's not, then please file a bug) The new design was also done to try to provide a graphical analog to the datetextbox/calendar combo, which seems popular. I know, the tasks really are quite different. And perhaps there are multiple ways a user may want to pick a time? There's a time spinner being worked on in dojox as well.
@bill - I was referring to
@bill - I was referring to the time picker - sorry for the confusion :) Date picker works like a charm I find (haven't tried keyboard accessibility though)
I am in favour of the simplest design - which in my eyes is a combobox - since most of the people who use my applications are working in administration. They know the keyboard well and they really really want to get things done fast.
I remember on quite nice article by Marco Tabini in PHParch about keyboard acessibility.. only forgot which issue :|
On the other hand you might want to have a time picker for fancy websites - like booking a dinner in a restaurant. This of course should look nice and fancy - and a11y is less important (still I am in favour of the speedy one)
@peller
In regards to the wildcard match; wouldn't the combobox provide such a thing already at this point? If the default values would be something like
00:00 | 00:30 | 01:00 | 01:13 (or even increments of 15)
than when entering say 0: I would get 00:00 and 00:30 and still could enter 00:33 - the support of internationalisation would be quite straightforward as well I believe.
I am trying to fiddle around a little to get some sort of example going but I am no expert of dijit so it might take some time :)
worth trying
not convinced that it's as simple as you say or that i18n matches will always make sense (you'll get AMs and PMs when matching 1: for example, and 1:00...1:45 and 10:00...12:45 when matching on 1?) but if it's a simple impl based on ComboBox, it's definitely worth trying. It would be great to see a mock up or dojox contribution.
http://www.nikolaionken.com/d
http://www.nikolaionken.com/dojo/dijit/tests/form/test_TimePicker.html
A real quick mockup!!
What is missing:
- Combobox too long (should have max. length of current locale time format)
- As you write when entering 1 it does not show 01:00 but only everything starting with 10:, 11:, etc. (does date.format support stripping leading zeroes?)
- Validation shows error when value is not one of selected. How would I make it validate a time value using i18n?
If that would work I would be using the widget right away and it would make quite some people happy :)
pretty cool
What we really want is a TimeTextBox with the combo behavior mixed-in (I don't know how well the current code will accomodate that!) So you can pick up on not just the i18n but all the other behavior of _FormWidget. Otherwise, it's just a matter of calling dojo.date.parse() to see if it's valid instead of letting the Combobox do the work, I guess.
It would also be nice to somehow have the combo dropdown sort not by the string but by the associated time (Date) object, so the 1:xx shows up before 10:xx, etc. I don't know much about ComboBox...
I don't think dojo.date.format is permissive on the leading zero thing. If your locale wants 01:00 I think 1:00 is just not valid (perhaps that's not good behavior?) You may have to do a special case and tack it on in your search?
-Adam
not related to Combobox?
I don't think the filtering issues or sorting issues are related to ComboBox... ComboBox just does a dojo.data query and then displays the results in the order returned from dojo.data... so you could write a custom data store to do what you want. QueryReadStore might be a good example to follow.
I have not yet worked with
I have not yet worked with the new data.store library but as you say it should be quite possible to write some sort of dateStore for cases like this.
Will see if I can find some time to digg around QueryReadStore... Then eliminating the 1: "problem" should be an easy one and the other features peller added could be integrated as well.
great
Great, ok please do that. What you said about TimeTextBox extending ComboBox makes sense from a usability standpoint, so if you can come up with a good implementation of that I'd like to integrate it into dijit.
You can ping Wolfram (cain on IRC) about custom dojo.data stores if you have questions, although I guess it's pretty straightforward.
As for the start time / end time thing, of course that's also useful but there are a large range of things like that that we need to do, such as start date / end date, and limiting a city drop-down according the selected state in the state drop-down, etc. The dojox wires project may do some/all of this but I need to look at it more closely.
just added a isValid
just added a isValid function so only sorting and widget width is left...
just updated the picker now
just updated the picker now supporting comparison of two times..
http://nikolaionken.com/dojo/dijit/tests/form/test_TimePicker.html
Following issues are remaining open:
- how can I remove values smaller than the comparing time from the selection list without deleting them from the store?
- how can I resize the select to the max width of the locale?
Then the timepicker should be workable
is a TimePicker gui really neccessary?
I'm confused what the point of making a TimePicker popup is. As you're entering the time you have in mind selecting the option that pops up will take longer than continuing to type the rest of the time. I think having a TimePicker widget is mostly valuable for formatting reasons. Automatically adding the am/pm or colon as you type is useful, as is ensuring that the time will always be of a certain format. If for some reason your form requires only a small selection of times I can see such a combo box being useful. But in most cases I feel using a gui will take longer than typing unless you want to choose a time on the hour, in which case maybe selecting the time in a list maybe quicker if you can select it in just one click.
You are right if you use the
You are right if you use the mouse and keyboard together to select a time. In the case of a lot of people who work in administration, they use the keyboard only and a combobox is a very keyboard-only-friendly thing.
We're talking about comparing 3 keyhits vs. 4 (so you could argue whether this should be compared at all) - but say you want to enter 13:00 - in the case of the combobox you enter 1,3,arrowdown,enter instead of 1,3,shift+;,0,0 (and you are not shure whether there is a typo or not.)
The difference is very small (just 1 key hit) but at least the people I work with who are working with schedules on a daily base for several hours, are most happy to get any amount of support through things like comboboxes, etc.
Btw. once you use times like 13:34 it is of course faster to enter them right away (which is possible with a combobox) but we're talking about supporting where possible and leaving the normal way when needed.
right
As nonken mentioned, it's to prevent typos, and it's also useful for people that are only using a mouse (or a touch screen).
However, I do see your point.
Also, I'm not averse to having widgets that auto-correct user input, for example if you typed "13" it would change it to "13:00", or if you typed "3pm" it would change it to "15:00". We just haven't had a chance to implement that. Patches are welcome (I think it would be functionality in dojo core, not something specific to the TimeTextBox widget).
Looks really nice
A couple of things I noticed:
* If you enter an invalid value in the start box, it causes an exception in setCompare (this._startCompare is null)
* The values seem to start at 9:00 AM. Is a range specified?
For the _getTimeDiff() part, I wonder if x hrs x mins would be better than decimal representation for mins > 60?
Specifying a time range is actually one place where I think the graphical model (dijit._TimePicker) may offer an advantage, or at least where I both are attractive. I definitely prefer the combobox approach for entering times free-form.
Drupal weirdness
That was me (peller) responding to nonken. Somehow, it edited your message when I refreshed instead of adding a reply :-/ The back button usually doesn't seem to work, and Drupal + Safari is just a bad combination, I guess.
The url nonken posted was http://nikolaionken.com/dojo/dijit/tests/form/test_TimePicker.html
heh, you responded under my
heh, you responded under my name.. weird... anyways..
I fixed the invalid date in the start box
at this point you can set the start and end range in the dijit code itself, trying to figure out how to pass it through though..
Probably the _getTimeDiff should be done as you said in x hrs xmins, how do I internationalize best?
nikolai
I've added the _getTimeDiff
I've added the _getTimeDiff so it represents like 2 hr 20 mins - now hr and mins needs to be internationalized and passing start end end time to the widget and we're all set.. any advice on the passing would be appreciated
nikolai
http://nikolaionken.com/dojo/dijit/tests/form/test_TimePicker.html
Factoring out strings
timeDiff: "(${0} hr {1} min)"
}
dojo.requireLocalization("dijit.form", "time");
...
var res = dojo.i18n.getLocalization("dijit.form", "time");
var timeDiff = dojo.string.substitute(res.timeDiff, [numHours, numMinutes]);