What is the general goal of the feature?
Allow entry and display of dates to match expectations of users (enumerators)
Shifting conversation from GitHub. Here is the historic conversation:
@LN, is the case @Dalerhoda is referring to one in which one would want the same form to handle data entry is different formats on different prompts?
That is something like
Q1: Please enter today in DD-MM-YYYY
...
Q10: Please enter due date in YYYY-MM-DD
?
If so, this strikes me as a pretty 'power user' (edge?) case.
Not to say it is not a useful feature--I'd defer to the broader community on that.
BUT it does seem like a different feature/fix than the GitHub issue.
I'd describe the TWO issues as:
Date entry and display format should match device locale settings
Date entry and display format should be individually settable per prompt/label in a Form—and this should override device locale settings.
And to be fully exhaustive, drawing from your comments, there is maybe a 3rd feature:
3. An app-wide preference to set date entry and display format that overrides device locale (but doesn't override individual prompt settings from a form)
If this breakdown into 3 separate features makes sense, I would argue that #1 (follow locale settings) is broadly useful and highest priority.
Question: do people feel the enhancements to the Date widget in 1.1x fulfill #1 (follow device locale)?
I didn't initially understand that specific GitHub issue but talking to @Dalerhoda cleared it up. From the issue:
In some contexts, field staff are copying dates from a written record and it would be helpful to be able to format the interface to look as much like the written dates as possible.
The order of month, day, and year elements in the no-calendar version of date data collection is currently tied to the device locale
So yes, we're talking about giving the form developer the power to set the date order on a question-by-question basis or on a form-by-form basis.
Your number 1 case is indeed handled though it would of course be good to get feedback it. To be more precise, date entry and display format mach the device local settings unless the language is set in the Collect general settings in which case the locale matching that language choice is used.
Your number 2 case is what that issue was about. I agree it feels like a power user feature. We should get more feedback on how useful it would really be before adding it.
Your number 3 case I would hope we don't have to do because it gets tricky and hard to understand once we have to reason about device locale, Collect language setting AND Collect date format setting. It could be useful in cases where different language variants use different date orders and not all variants are available on devices or in Collect.
Thank you for clarifying the issue. I agree that #1 (match the device locale) should take care of most cases and the #3 is confusing and probably unnecessary as changing the device's locale, for the purpose of changing format display in Collect, is a work around.
And I agree #2 is worth discussing. I worry addressing it through display hints in the form could be confusing to a user who doesn't understand why dates are not matching the device's locale.
In respect to #1 (device locale and formats matching) I'll play around with date entry/display in the latest beta and provide feedback/issues if anything looks weird.
Hi Jeff & Hélène...thanks for the rich discussion. I'm just back from twelve days away and working thru my inbox.
Jeff: I think you captured my heart's desire well in your list of 3 issues: As a person who wants to run experiments on data collection in absentia, I want to have ultimate and specific control of the mm-dd-yyy order even if I'm not present to set or confirm device locale or app-wide settings. So I think a hierarchy of control by locale, over-ride-able by app, over-ride-able by question or what you're calling prompt/label sounds terrific. But I am inferring thru what you've written that it also sounds hard.
Hélène: I would be delighted to coordinate an experiment to see if the improvements to date make a difference and I have ideas for improvements in the instructions given to interviewers, as well. With financial support, we could design an experiment anytime that would shed some light on several important questions.
My question is whether the second two enhancements (override with app setting, prompt-specific overrides) have application outside of the experimental context.
If they are not more broadly useful, those enhancements would probably remain relatively low-priority on the feature list.
And I wonder if for the experimental case specifically it might make sense to use mock-ups instead.
I'm not familiar with the current state-of-the-art in mock-up kits for Android, but even a few years ago, they were getting pretty good.
By which I mean, not using ODK itself for the tests, but a limited mock-up of ODK with the UI changes you want to test...
Incidentally, @jwishnie is one of the people behind that funding opportunity. Does this kind of usability testing seem to fit what you had in mind, @jwishnie? Perhaps this component of the proposal could include evaluating the current state of date widgets, writing up better training documentation and mocking up other possible future changes.
The 'Dirty Jobs' theme is intentionally wide so I'm not going to cut off any ideas. The key is to make the argument that the tasks to be funded are important but constantly overlooked--perhaps because there is always some greater priority, or because they are hard to fund.
One way to think of it is DIAL wants to help projects take care of the stuff they have wanted to take care of forever, but haven't been able to.
This grant facility is going to run regularly--with a new theme each time, and UI/user-testing (and responding to what is learned through the testing) is a likely future theme.
Hi all, just jumping into this since I'm still hitting a problem w/ dates. My specific problem is that a date is being saved as "31/08/08" and it's not pushing into a SQL db until I change it to 2018-08-31. Anyway, I see that date formatting is a fairly complex issue, and perhaps it's still unresolved (sorry if I'm wrong).
Just going to throw in 2 cents.
I think the ISO standard for date is YYYY-MM-DD exactly to avoid this. If everything in any locale were mapped to that standard I think it would be a pretty clear (if heavyhanded) approach, no?
I think any global settings should be on a per-form basis. I will for example be managing around 40-60 forms, spanning the world. A global setting won't work for me. But perhaps it would really work to have this as a setting in the settings tab?