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

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

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: 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.

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: 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.

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: 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. > > -- > -- > 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.

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, <gpo...@gmail.com > 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, <alb...@swcacloud.com > 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. >

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.

Thank you Yaw, I'll see what I can do.

Greg

··· 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.

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

Thanks for sharing, Greg. Hopefully, others will find this useful!

··· On Tue, May 16, 2017 at 12:40 PM, wrote: > 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 > > > 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. > > -- > -- > 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.
2 Likes

I've attached an XLSForm version in case that is useful to someone.

DateTimeSplit.xlsx (12.8 KB)

2 Likes

Dear Greg and Yaw,

Many thanks for your inputs on the timestamps. I am trying to use the timestamps as I am trying to keep track of reaction time of respondents, but the timestamp give me a same time every time I use them. Could you provide some help please?

Thanks!

Maria Isabel

I checked it, seems fine for my case.

This is the structure that I am using in XLSform:
type Name label read_only calculation
start TimeStamp
string time_stamp1 Time true() format-date-time(${TimeStamp},'%H:%M:%S.%3')

Could you advise on what I am doing wrong?
Many thanks on advance!

Dear Hélène,
I am trying to implement a timestamp for odk questions, and I came across a couple of support threads that discussed the item.
In the link below an audit meta element is discussed, however when I try to use it with XLSform I get a problem when converting the file to xml.

Could you provide some help here please?
Thanks, it is highly appreciated!
Best,
Maria Isabel

I just answered a similar question in Timestamping responses - #3 by LN -- it's funny how people around the world seem to have the same ideas at the same time!

To summarize, you can use the audit log by adding a row of type and name audit in your form:

survey
type name label
audit audit

A first pass at deeper documentation is at https://github.com/opendatakit/docs/pull/649. Note that you will need to use Aggregate 1.5+ to receive the audit logs.

If you only want to time one or two questions, you can use something like if(${age}='', '', once(format-date-time(now(), "%b %e, %Y at %H:%M:%S"))) to time when a field named age is first edited. See a full sample form here.

Dear Hélène,

Many thanks for your reply. We tried it and it works well so far. We get a audit.csv file with start and end date for each question.
It did not work before when I used the XLSForm Offline 1.4.0 by Nafundi. It did work when I converted the XLSform to Xform using the online tool.

Best,

Maria Isabel

1 Like

I wanted to add that both suggestions worked well. The message before was meant for the audit option.

1 Like