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