Remove pop-up date picker

[drubage]

The pop-up date picker is not good for screen readers, how can we disable it from fields like birth date?

[Dave Greenberg]

There's been some discussion of modifying the date picker so you could EITHER type in a date value in a text field OR use the date picker. However there would need to be sufficient validation routines to handle various typed in dates in order for this to work out, and no one has stepped up yet to work on this.

I think current jQuery  widget  (datepicker) is being updated to the latest version for 3.3. - which might handle screen-readers better??

Bottom line is there's no configuration option to remove it. You'll need to look at modifying or replacing templates/CRM/common/jcalendar.tpl.

[drubage]

That did help, I removed the javascript it was adding, thank you!

[sonicthoughts]

We've been having LOTs of problems with the datepicker on ver 3.2.3.  many complaints that people can't use it properly.

[pbarmak]

sonicthoughts,
I don't know if this will help, but our folks had been complaining as well, mostly about not being able to manually input dates themselves.  So I went ahead and modified the file Dave refers to above and removed the readonly setting on the date form field.  Of course, what Dave mentions about validation is correct, allowing manual entry can cause some issues, but our folks were willing to live with those.

What I did was a quick hack (not sure if it's the best way to handle this):
1. copy jcalendar.tpl to your custom templates folder
2. find the following line (line 46 in my version of the file):
   

Code: [Select]

{$form.$elementName.html|crmReplace:class:dateplugin}3. comment that and replace it with:
   

Code: [Select]

{$form.$elementName.html|crmReplace:class:dateplugin|replace:'readonly="1"':''}
I think that's all it took.

I also changed some of the params to the datepicker widget to make it more user friendly for our folks (they didn't like the month and year dropdowns, made input confusing) - here are the params I use:

Code: [Select]

      cj(element_date).datepicker({
                                    closeAtTop        : true,
                                    dateFormat        : date_format,
                                    changeMonth       : false,
                                    changeYear        : false,
                                    constrainInput    : false,
                                    altField          : alt_field,
                                    altFormat         : 'mm/dd/yyyy',
                                    yearRange         : yearRange
                                });

So the combination of manual entry and the changes to the widget give us the best combo.  People who want to quickly change a year can do so manually, folks who want to skim through calendar dates can still do that with the widget.

Hope that helps a little.  Again, it's not a perfect solution because people can type in incorrect dates and the form will accept them, but in our case, the pros outweighed the cons.

[sonicthoughts]

thanks!  our main issue is that you first have to put the year but people tend to do it last.  i put some help on the forms and hopefully that will be a band-aid without getting into surgery but will definitely consider this approach.  As i searched for datepicker found LOTs of issues people are having, but this seems to be the big one for us.  S.

[Donald Lobo]

can you check and see if the datepicker in Civi v3.3 / jQ 1.4 is better. You can try it out at http://sandbox.civicrm.org/

Would be great if some members of the community can group together and help improve the "date" situation. Would really help to make it more flexible but stil check the dates entered etc

lobo

[sonicthoughts]

Same issue on the sandbox.  Basically the only way to actually enter a date in the field is to select a specific day.  If the user has already selected the correct day or selects a month and then a year, it's not necessarily intuitive that you have to select the day to enter the date in the field.  If there were a note at the bottom of the widet that said "select a day to enter" or if the day highlighted when you hover so it looked like a "button" or if there were another "enter" button on the widget, it would probably be more intuitive.

This is strictly a usability concern.  i think others have identified other weaknesses:

limiting the date range
inputing part of a date (day, or year)
quickly entering a date with the keyboard
enable / disable of widgit vs. typing the date


Overall I think this is a great addition, but needs some more flexibility.

If i were a developer, and not a hack, I might be in a better position to contribute.

S.

[TwoMice]

Would be great if some members of the community can group together and help improve the "date" situation. Would really help to make it more flexible but stil check the dates entered etc.

Any thoughts on what that might look like, Lobo?

[Donald Lobo]

Not sure i understand the question twomice?

lobo

[TwoMice]

Sorry, I just meant, if folks wanted to get together to explore ways of improving the date picker, what might that discussion look like, how might it get started, etc?

-TM

[Dave Greenberg]

TM - It seems like figuring out how to modify the existing UI / widget code so that it allows the user to either type in a date OR select from the pop-up calendar would solve a large number of the concerns expressed.

I think the biggest obstacle to this is making sure that key-entered dates are validated - ideally client-side - and consistent with the installation's configured / localized date format. Example: 31/12/2010 is a valid date if Date Format configuration is set to dd/mm/yyyy (but not valid for mm/dd/yyyy format). The existing jQuery datepicker widget that we are using can be configured to allow user-entered dates, but as far as I know doesn't include support for input validation.

http://jqueryui.com/demos/datepicker/

[Chris Burgess]

If you're seeing CSS issues rendering the date picker in CiviCRM pages, this CSS fixed it for me.

Note that the body.section-civicrm class is present on my site but may not be on yours (unless you happen to have sections module installed, I think).

Code: [Select]

body.section-civicrm .ui-datepicker-header select {
    position: relative ;
}

What this does is override the CSS added by date_popup/themes/datepicker.css

There are two issues on this specific UI problem: http://issues.civicrm.org/jira/browse/CRM-5471 (removes date_popup/themes/datepicker.css from pages which are in CiviCRM path, and therefore potentially breaks Drupal datepickers in the sidebars or otherwise visible when on CiviCRM pages) and http://issues.civicrm.org/jira/browse/CRM-7133 (clone of the first issue, but for 3.2.x and with CSS-only fix recorded there). Latter issue needs an admin to move it from 3.1.x to 3.2.x as I can't do that on a cloned issue*.

* Apparently I have misunderstood the purpose of cloned issues, if they are locked to the original issue's details. What's the point of having a clone, if you can't mess with it?

[Dave Greenberg]

Thanks Chris - issue is moved to 3.2.6. I don't know what CLONE is for either :-(

[sonicthoughts]

Complaints got really bad so I tried below and it works well enough - thanks!  Note that you have to delete the civi cache for this to take effect (spent some time wasted on that ...) S.

sonicthoughts,
I don't know if this will help, but our folks had been complaining as well, mostly about not being able to manually input dates themselves.  So I went ahead and modified the file Dave refers to above and removed the readonly setting on the date form field.  Of course, what Dave mentions about validation is correct, allowing manual entry can cause some issues, but our folks were willing to live with those.

What I did was a quick hack (not sure if it's the best way to handle this):
1. copy jcalendar.tpl to your custom templates folder
2. find the following line (line 46 in my version of the file):
   

Code: [Select]

{$form.$elementName.html|crmReplace:class:dateplugin}3. comment that and replace it with:
   

Code: [Select]

{$form.$elementName.html|crmReplace:class:dateplugin|replace:'readonly="1"':''}
I think that's all it took.

I also changed some of the params to the datepicker widget to make it more user friendly for our folks (they didn't like the month and year dropdowns, made input confusing) - here are the params I use:

Code: [Select]

      cj(element_date).datepicker({
                                    closeAtTop        : true,
                                    dateFormat        : date_format,
                                    changeMonth       : false,
                                    changeYear        : false,
                                    constrainInput    : false,
                                    altField          : alt_field,
                                    altFormat         : 'mm/dd/yyyy',
                                    yearRange         : yearRange
                                });

So the combination of manual entry and the changes to the widget give us the best combo.  People who want to quickly change a year can do so manually, folks who want to skim through calendar dates can still do that with the widget.

Hope that helps a little.  Again, it's not a perfect solution because people can type in incorrect dates and the form will accept them, but in our case, the pros outweighed the cons.