Duncan Mac-Vicar P. wrote:
% > Usability glitches:
% > - date changes correctly accroding to localization but time is always
% >   12 hour a.m./p.m. in any localization
% I left this because it was like that in the current date picker. I will
% improve this, but I have to first make sure the date picker object (Java
% part) support this (if needed at all).

Well, either don't bother with localization at all or make it complete.
Half done things are annoying.

% > - week starts on Sunday in all localizations
% Fixed, I will include it in an updated patch.

Thanks.

% > - clicking on calendar icon pops-up date picker but clicking on clock
% >   icon doesn't pop-up time picker
% Fixed by updating the library

Thanks.

% > - calendar pops above picker, time pulls down
% We could enforce this, but in general the direction is calculated on
% available space, I guess this happens because the picker is at the end
% of the page. Enforcing may have some nasty side-effects

Nope, there's plenty of space both above and bellow the picker. IMHO 
"auto-bottom" option opens it bellow the picker by default.

% > - if I click for the first time to date calendar doesn't highlight
% >   currently selected date (it highlights always today)
% The start date is today, and the calendar highlights today and the
% selected date in different colors.
% So I am not sure I understand what is the problem here.

E.g in monitoring probe there's picker which is set some time in the
future (or in the past). When I click it shows calendar with highlighted
"today" not the date from the picker.

% > - calendar should close when I click chosen date (or at least at
% >   doubleclick)
% Fixed, will go in next patch.

Thanks.

% > Implementation:
% > - What are fn.datepicker.dates arrays needed for? It looks like a kind
% >   of localization but AFAIK bootstrap datepicker cares about
% >   localization itself (language option).
% That way instead of using the built-in locale files from javascript I
% generate
% the localization from the Java strings (Calendar). That way we don't
% have to include the localization .js files and to track them for
% translation.

Well, I'd prefer including static javascript to generating it over and
over with every picker. Even those static localization js can be
generated automatically in rpm build time (from the same sources you
generate it now). Anyway I'm not pushing for it.

% > - bootstrap-datepicker / jquery.timepicker css and js should not be in
% >   branding or web but in a separate package which is required by branding.
% > - What's the benefit of combining bootstrap datepicker with jquery
% >   timepicker over some bootstrap datetimepicker ([1], [2]) which does
% >   both?
% 
% We tried different combinations of pickers. We all kind of agreed that
% the combination of these two give you something very similar to the
% Facebook picker which is a very good balance between easy and convenient
% with the keyboard (you can still use it) from all the ones we tried.
% Cynthia, our UX developer also agreed. So I would say we optimized more
% the user experience than the packaging or the code.

I agree with user experience on the other hand this combination, for me,
isn't good experience. They are two different libs / different styles.
There's visible difference between date picker - pop up window - and
time picker - "classic" pull down menu.

% bootstrap-datetimepicker is also an external library, combining two
% pickers in one, but the date picker is not very nice. You can try it
% yourself and you will see what I am talking about :-), also I suspect
% Facebook also experimented a lot with their picker already. The second
% one you linked is a bit better, though it forces you to go through the 3
% steps.

I've tried [1]. I didn't liked it at the beginning but
after some time I found it in fact quite good. You can set the time with
a precision of seconds in just 3 clicks (try clicking on second number).
Yes, it's a bit uglier on the other hand both date and time part has consistent
look and feel.

The [2] is also more consistent, looks IMHO a bit better then [1], and
allows to set time with 5 min precision.


% Duncan

Regards,

--
Michael Mráka
Satellite Engineering, Red Hat


_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Reply via email to