How to default the time data type to the current time?

Hi Yaw,

I think I've come up with a couple of partial workarounds. Neither are exact replacements for the missing behaviour but will suffice for my organization. See attached file for my documentation of the fixes. I apologize for what is likely non-standard documentation. I have no formal training at this.

Greg

Split DateTime.xml (3.71 KB)

··· On Friday, May 12, 2017 at 2:45:38 PM UTC-6, Yaw Anokwa wrote: > Greg, > > Thank you for your kind response! > > We really need people to say something when things aren't going the > way they expect. For me, some of the biggest contributions we can get > are from users who report bugs, answer support questions, and detail > the problems they need ODK to help them solve. > > If you want to go above and beyond and help with code, then the basic > skill that is needed is experience with Java and a willingness to work > with the community. > https://github.com/opendatakit/collect/blob/master/CONTRIBUTING.md has > the steps to get started. A lot of the community developers hang out > at http://slack.opendatakit.org and are ready to help. > > Over the next few months, we'll be rolling out platforms that make it > easier to contribute form design tricks and documentation. Until that > happens, if you find a good workaround using XML, just post it to the > list. > > Thanks again, > > Yaw > > On Fri, May 12, 2017 at 3:04 PM, Pest Lab COE wrote: > > Hi Yaw, > > > > I can only imagine how difficult it is trying to develop software that > > takes in to account the needs of such diverse groups of users. ODK is > > amazing and has transformed how we collect data. We appreciate your efforts > > to keep it so robust. It's nearly bulletproof reliability makes it a much > > easier sell to our organization. We hadn't noticed these errors but maybe > > we were just lucky given that our work environment is relatively homogeneous > > I'm sure compared to many of the users of ODK. However the ability to > > collect empty dates I would never have even imagined was a desire. Live and > > learn. > > > > I'll look into joining the beta program. Perhaps I can contribute > > something useful even at the level of development I operate at. However, as > > we can't even get stable funding for the work that I perform as the > > developer of our program it seems unlikely we'll get funding for development > > of any underlying code. However if that were to happen, how would we > > contribute to the development of dynamic defaults and what knowledge base > > should that person have? Also, if I think of any ways to implement our needs > > just using the XML script of ODK, would it be desirable to share that > > somehow and where could I share it? > > > > Thank you, > > > > Greg > > > > > > On Friday, May 12, 2017 at 12:44:51 PM UTC-6, Yaw Anokwa wrote: > >> > >> Hi Greg, > >> > >> One of the challenges we have as ODK developers is that we don't > >> always know when people are using features (or bugs) in unexpected > >> ways. We try hard to get feedback on the issue tracker before we make > >> these changes, but I understand that it's not always easy for > >> implementers to keep up-to-date. > >> > >> Next week, we'll be announcing a beta program to get implementers > >> early access to changes we are making in Collect. This will give folks > >> a chance to see exactly what changes will be had and provide feedback. > >> You can join that program early at > >> https://play.google.com/apps/testing/org.odk.collect.android. > >> > >> I've trained a fair number of people in my time, and so I don't think > >> it's silly at all that you want to reduce the training burden. But we > >> have to balance that training burden with the need for increased data > >> quality. The inability to add empty dates has been a long-standing > >> issue in Collect. That is, you couldn't distinguish between "I don't > >> know" and "today" without form design tricks (e.g., enter 1900-01-01 > >> or have extra questions to ask about the validity of the date). > >> > >> I should also note that the changes we made in the last release were > >> informed by a report showing that the previous widgets resulted in > >> significant errors when entering dates. You can find that report here > >> > >> https://www.ehealthafrica.org/latest/2017/1/9/combinations-that-yield-low-error-rates-for-dates-on-touchscreen-devices-1. > >> > >> In your specific case, you should be able to add a required attribute > >> to make the field required. And then your users just need to tap the > >> button and hit OK. Can you try that as a solution? > >> > >> Also, we are also exploring a way to set dynamic defaults in Collect, > >> but that may be a significant amount of work. Perhaps your > >> organization can help fund someone to contribute that code? > >> > >> Thanks, > >> > >> Yaw > >> > >> On Fri, May 12, 2017 at 1:05 PM, wrote: > >> > Hello, > >> > > >> > Before the current time feature was "fixed" we were using it to > >> > auto-fill Date and Time fields upon the start of a form. The auto-fill was > >> > very handy because users could change it if required but otherwise wouldn't > >> > have to worry about it and could swipe through quickly. It was also nice > >> > being able to separate the Date and Time fields for easier sorting and > >> > filtering later on in our tables. Rather than "fixing" this useful feature > >> > it would seem to make more sense to me to create another feature allowing > >> > the date/time fields to be blank or perhaps put a switch on this one. > >> > Programming isn't my trained field of expertise so I hope that made some > >> > sense. > >> > > >> > I'm going to have to figure out how to recreate the functionality > >> > of the auto-fill date/time on all my forms now, swap over the data to the > >> > new forms, and have all our users update everything if we want to keep a > >> > relatively simple and very useful feature. I know it seems silly that they > >> > only have to push two buttons to enter date and time but user training is > >> > difficult, people don't remember these things, and we've already had many > >> > records entered without our date/time fields entered. > >> > > >> > Regards, > >> > Greg > >> > > >> > > >> > On Tuesday, May 9, 2017 at 10:54:04 AM UTC-6, Hélène Martin wrote: > >> >> Hello, > >> >> > >> >> In Collect versions previous to 1.6.0, it was possible to get the > >> >> current time without user input because it was not possible to store > >> >> blank times and so the fallback became the current time. This was sort > >> >> of an accidental feature that we didn't realize people were using. > >> >> > >> >> For now, your best bet if you would like to keep using this is to go > >> >> back to a version of Collect 1.5.1 or below. You can download them > >> >> here: https://opendatakit.org/downloads/ > >> >> > >> >> If you are using this to get a general sense of enumerator timing > >> >> through a survey, I wrote a little bit about the challenges presented > >> >> by this approach at > >> >> https://groups.google.com/d/msg/opendatakit/R0XBiZfR8YQ/sHXbeeiXHAAJ > >> >> > >> >> In general, it would be very useful to better understand how you have > >> >> been using this functionality so that we can design a good replacement > >> >> for it. If you could describe the general problem you are trying to > >> >> solve, that would be wonderful. If anyone else has been using this, > >> >> we'd love to hear from you as well. > >> >> > >> >> For those interested in the technical details, please join us at > >> >> https://github.com/opendatakit/xforms-spec/issues/123 > >> >> > >> >> Thanks! > >> >> > >> >> Hélène. > >> >> > >> >> On Fri, May 5, 2017 at 4:33 PM, wrote: > >> >> > I am using version 1.6.1 and I noticed a problem with the time data > >> >> > type. When using earlier versions of ODK, this data type would default to > >> >> > the present time thus requiring no input from the user. This does not seem > >> >> > to occur anymore in 1.6.1 and when I attempted to specify a default of now > >> >> > in the XLS form, it still would not actually default to that time without > >> >> > manually opening the widget. Is there some default term I don't know or do I > >> >> > need to turn this into a calculation? > >> >> > > >> >> > -- > >> >> > -- > >> >> > Post: opend...@googlegroups.com > >> >> > Unsubscribe: opendatakit...@googlegroups.com > >> >> > Options: http://groups.google.com/group/opendatakit?hl=en > >> >> > > >> >> > --- > >> >> > You received this message because you are subscribed to the Google > >> >> > Groups "ODK Community" group. > >> >> > To unsubscribe from this group and stop receiving emails from it, > >> >> > send an email to opendatakit...@googlegroups.com. > >> >> > For more options, visit https://groups.google.com/d/optout. > >> > > >> > -- > >> > -- > >> > Post: opend...@googlegroups.com > >> > Unsubscribe: opendatakit...@googlegroups.com > >> > Options: http://groups.google.com/group/opendatakit?hl=en > >> > > >> > --- > >> > You received this message because you are subscribed to the Google > >> > Groups "ODK Community" group. > >> > To unsubscribe from this group and stop receiving emails from it, send > >> > an email to opendatakit...@googlegroups.com. > >> > For more options, visit https://groups.google.com/d/optout. > > > > -- > > -- > > Post: opendatakit@googlegroups.com > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > > Options: http://groups.google.com/group/opendatakit?hl=en > > > > --- > > You received this message because you are subscribed to the Google Groups > > "ODK Community" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to opendatakit+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout.
1 Like