For advanced search by dates allow more flexible date formatting
|Assignee:||José Raddaoui Marín||% Done:|
|Category:||Search / Browse||Estimated time:||2.00 hours|
|Target version:||Release 1.4.0|
|Google Code Legacy ID:||Tested version:|
Currently only "YYYYMMDD" is supported, and searching by a year requires padding the value with zeros (e.g. 19980000)Please allow the following date formats:
- Year only (YYYY)
- Full date, with hyphens (YYYY-MM-DD)
- Full date, with forward slashes (YYYY/MM/DD)
#7 Updated by Jesús García Crespo almost 9 years ago
As we discussed, try rebasing Mike's branch. We can take a look once you've reviewed so we can merge it into 1.x. I think he did a pretty good job reusing existing libraries and all, we just need to clarify if we really want to introduce that change as it may be inconsistent with other date fields along the app. But that's not a big deal I guess. Maybe Dan wants to get involved.
Maybe send us a screenshot to see how it looks. Or we can ask Dan to switch his local dev to that branch so he can review before the merge happens.
#8 Updated by Dan Gillean almost 9 years ago
I haven't seen what this would look like with a datepicker at all, but I am curious. The datepicker is only really useful if it helps speed up a user's interaction with date searching - if it is difficult to get to a distant date from the past, then we are just adding bells and whistles without utility. I think that ideally, a text field would still be available, with the datepicker being an option that the user has. The problem with datepickers is that they tend to start on the current date when opened - but for searching archival materials, odds are that the date the user wants to pick is signifcantly older than this. Navigating through a datepicker to a distant date can be incredibly annoying, esp. if the calendar navigation is by month and doesn't have an option to move by year, decade, etc. I would also want to ensure that we have a tooltip on the field that would clarify to the user what date formats can be added to a free-text field, and if necessary, how to navigate quickly in the datepicker (ie in case there is an option to browse for a date by year or some quicker means, but its not immediately obvious to the end-user.
If Jesus shows me how, I could switch branches to see the work that's been done on this.
#13 Updated by Dan Gillean almost 9 years ago
I like it!
I noticed that the date picker only went back as far as 1880, so I tried manually adding 17000101 as a date - when I opened the datepicker again, it now showed a range of dates from 1770 to 1630 - so it's clear that the date picker is not adding any limitations to the range of dates.
I've noticed that there's no way to pick just a year, or year and month in the date picker, so I have two simple suggestions for this:
1) The sort of tooltip below currently reads: "Date format: YYYYMMDD" I would propose we make a simple alteration to have this read: "Date format: YYYYMMDD, YYYYMM, or YYYY"
2) Jesus, when we are finished with the new User manual, can we include a link directly to the Advanced search Sphinx documentation, as is present here in 1.x (linking to wiki)? I think that being able to go straight to documentation help would go a long way to supporting this, as I can make this documentation robust to address specific use cases, etc. Otherwise, some part of me wants to ask for tooltips on the date fields, adding unnecessary complications, and I'd rather keep that information in the docs but make it readily available to users. Ideally, when clicked, this would open in a new tab, instead of taking the user away from the AtoM application.
#17 Updated by Jessica Bushey almost 9 years ago
- Status changed from QA/Review to Feedback
Radda, the GUI calendar for date range searching in Advanced Search is good. BUT we have a problem with adding dates into the data entry fields (and not using the GUI Calendar. For example.
1. Create an archival description with start date 1700 and end date 1800. Save.
2. Go to Advanced Search, date range and enter into the start date field 1700 and enter into the end date field 1800. Click Search.
= unexpected error =
No hits are returned.
If you enter 17000000 and 18000000, it works.
We need to make certain that a user can enter YYYY and YYYYMM to get an accurate response from the search. Right now, only YYYYMMDD works. Please fix.
#18 Updated by José Raddaoui Marín almost 9 years ago
Really sorry Jessica, I forgot that part after I merged Mike's branch.
Now the following formats are accepted:
- YYYYMMDD, YYYYMM and YYYY
- YYYY/MM/DD and YYYY/MM
- YYYY-MM-DD and YYYY-MM
So, do we change the footer with the date formats? Or remove it and specify this in the documentation page linked bellow?
#19 Updated by Dan Gillean almost 9 years ago
Radda, I propose we just change the tooltip to say: "Recommended date format..." and then I will explain it all clearly in the documentation.
If I enter 17000101 in the start date, tab to a different field, and then return and open the datepicker, the dates will show me a range from 1630-1770, ie a 70-year range on either side. But, if I enter 1700, the date range in the date picker does not change (stays at the default 1950) - and if I hit enter when the datepicker is open, it will change my 1700 date to the 19500101 date from the datepicker.
Is it possible that when YYYY, or YYYYMM / YYYY-MM / YYYY/MM is entered and then a user returns to the datepicker, the year dropdown opens on on the YYYY (etc) that was entered, instead of defaulting to 1950?
I'm not sure how complex this would be, but it would improve the intuitiveness and usability of the datepicker solution.
Thanks for all your work on this!
#23 Updated by José Raddaoui Marín almost 9 years ago
#24 Updated by Dan Gillean almost 9 years ago
- Status changed from QA/Review to Feedback
Radda this is great, thank you so much.
One tiny issue that is completely my fault. I should have been more clear and was being lazy when typing.
Can you please change the tooltip to read:
"Recommended date format: YYYYMMDD, YYYYMM, or YYYY."
That was not clear in the way I worded it before, i meant for the ellipsis (...) to mean we didn't change the rest, but I should have just spelled it out. Sorry!
The datepicker's need to add month and day is unfortunate in a way, but it works well now, and we can clarify its use in the documentation. Thanks again for all your tweaks on this, if you change the tooltip I can verify the issue right away.