Dear all, I have just returned from Liberia where the Carter Center
used ODK for its election monitoring operations for the first time. We
had 28 phones in use across all 15 counties of the country. We used
ODK collect along with the custom form designer/aggregator that I have
built for TCC and previously shared on this list. We used Tableau (a
popular BI package) for analysis. The system worked very well and TCC
leadership was happy with the results.
Several issues with ODK Collect arose during the deployment. I'd like
to raise them one by one below to see if others have encountered
similar issues, or if there is a fix that I'm not aware of, or if
there are suggestions for improvement, etc. So here goes:
-
'Change' username/password
When entering credentials on the preferences screen, the dialog title
is 'Change Username' or 'Change Password'. This has confused some
users who thought they were being asked to change their system
password rather than simply to enter it. So I propose changing these
titles to read 'Enter Username' and 'Enter Password'.
-
Why prompt for credentials when already entered
Even if users enter their credentials in the prefs screen, a prompt
always appears on the first request after ODK is opened. This is both
confusing and slows things down as two request/responses must take
place instead of one. Is there any reason for the prompt or could we
just send the saved credentials with the first request and only show
the dialog if there is an auth failure?
-
"Generic exception"
Attempting to send forms with no internet connection gets a 'Generic
Exception' error message. This was confusing to folks and I got tons
of calls with people wondering what the problem was (many of them had
simply run out of credit and lost their edge connection.) If it said
'No network connection', this would be much more helpful. I can take a
look at this if it's ok with y'all.
-
Hard returns in inappropriate text boxes (login, password, integer, float)
Can we disallow hard returns in these places? Some folks managed to
push enter a few times by accident, leading to great confusion,
especially in the username/password boxes where the extra returns are
not visible but result in auth failure.
-
Show bigger box for 'long text' fields
In my designer/aggregator, the form designer can choose between short
text and long text field types, which effects how the fields appear on
the web version of the forms (text field vs. text area). I suggest
something similar for ODK so that long text questions could have
bigger text boxes when the question loads. Several users didn't know
that the field would expand (a reasonable assumption I think) and thus
wrote something like 'not enough space' for some questions. This could
be as simple as an extra attribute in the xml like boxheightlines="5"
or something. The field type could still be 'string'. Thoughts?
-
n/a for required integer/float questions?
Some of our integer questions were required, but 'not applicable'
would be a valid and useful answer. What have folks done in this
situation? I suppose one could make it a string field with a 'number
or n/a' regexp constraint, but this seems hackish. Couldn't there be
an attribute like allowna="-1" which shows an 'n/a' checkbox and
stores the specified value (-1 in this case) for the answer if this
box is checked?
-
Explanations for 'no' answer
Our forms were composed of mostly yes/no/n/a questions, with 'no'
usually indicating something out of the ordinary (e.g. "Is the polling
station calm and peaceful: Yes/No/N/A). So if an observer answers
'no', we want an explanation. We have tried having a string question
immediately after with a 'if previous == no' condition. This works,
but it's a jolly big pain in the rear to do this manually for all
30-40 questions. Has anyone ever come up with an easier way to do
this? If not I will probably add some kind of shortcut feature to our
designer.
-
Required check
ODK currently complains about unanswered required questions at two
different points: on finger swipe and on save. The only way to
circumvent the on swipe check is to use menu->go to prompt. This was
annoying for our observers who often fill out the forms in non-linear
order. Could we have an option in the prefs that disables the on swipe
check leaving only the on save one? Data integrity wouldn't be
ultimately be affected.
I am willing to make any proposed changes in this email. I just wanted
to sanity check them and get the community's reaction before
proceeding.
Thanks everyone!
Thomas:
this is a fantastic list of feedback and exemplary of what we'd like
from all our users. Thanks for taking the time to put it together.
We will certainly look this over and get back to you.
Gaetano
···
On Thu, Oct 20, 2011 at 9:11 AM, Thomas Smyth wrote:
> Dear all, I have just returned from Liberia where the Carter Center
> used ODK for its election monitoring operations for the first time. We
> had 28 phones in use across all 15 counties of the country. We used
> ODK collect along with the custom form designer/aggregator that I have
> built for TCC and previously shared on this list. We used Tableau (a
> popular BI package) for analysis. The system worked very well and TCC
> leadership was happy with the results.
>
> Several issues with ODK Collect arose during the deployment. I'd like
> to raise them one by one below to see if others have encountered
> similar issues, or if there is a fix that I'm not aware of, or if
> there are suggestions for improvement, etc. So here goes:
>
> 1. 'Change' username/password
> When entering credentials on the preferences screen, the dialog title
> is 'Change Username' or 'Change Password'. This has confused some
> users who thought they were being asked to change their system
> password rather than simply to enter it. So I propose changing these
> titles to read 'Enter Username' and 'Enter Password'.
>
> 2. Why prompt for credentials when already entered
> Even if users enter their credentials in the prefs screen, a prompt
> always appears on the first request after ODK is opened. This is both
> confusing and slows things down as two request/responses must take
> place instead of one. Is there any reason for the prompt or could we
> just send the saved credentials with the first request and only show
> the dialog if there is an auth failure?
>
> 3. "Generic exception"
> Attempting to send forms with no internet connection gets a 'Generic
> Exception' error message. This was confusing to folks and I got tons
> of calls with people wondering what the problem was (many of them had
> simply run out of credit and lost their edge connection.) If it said
> 'No network connection', this would be much more helpful. I can take a
> look at this if it's ok with y'all.
>
> 4. Hard returns in inappropriate text boxes (login, password, integer, float)
> Can we disallow hard returns in these places? Some folks managed to
> push enter a few times by accident, leading to great confusion,
> especially in the username/password boxes where the extra returns are
> not visible but result in auth failure.
>
> 5. Show bigger box for 'long text' fields
> In my designer/aggregator, the form designer can choose between short
> text and long text field types, which effects how the fields appear on
> the web version of the forms (text field vs. text area). I suggest
> something similar for ODK so that long text questions could have
> bigger text boxes when the question loads. Several users didn't know
> that the field would expand (a reasonable assumption I think) and thus
> wrote something like 'not enough space' for some questions. This could
> be as simple as an extra attribute in the xml like boxheightlines="5"
> or something. The field type could still be 'string'. Thoughts?
>
> 6. n/a for required integer/float questions?
> Some of our integer questions were required, but 'not applicable'
> would be a valid and useful answer. What have folks done in this
> situation? I suppose one could make it a string field with a 'number
> or n/a' regexp constraint, but this seems hackish. Couldn't there be
> an attribute like allowna="-1" which shows an 'n/a' checkbox and
> stores the specified value (-1 in this case) for the answer if this
> box is checked?
>
> 7. Explanations for 'no' answer
> Our forms were composed of mostly yes/no/n/a questions, with 'no'
> usually indicating something out of the ordinary (e.g. "Is the polling
> station calm and peaceful: Yes/No/N/A). So if an observer answers
> 'no', we want an explanation. We have tried having a string question
> immediately after with a 'if previous == no' condition. This works,
> but it's a jolly big pain in the rear to do this manually for all
> 30-40 questions. Has anyone ever come up with an easier way to do
> this? If not I will probably add some kind of shortcut feature to our
> designer.
>
> 8. Required check
> ODK currently complains about unanswered required questions at two
> different points: on finger swipe and on save. The only way to
> circumvent the on swipe check is to use menu->go to prompt. This was
> annoying for our observers who often fill out the forms in non-linear
> order. Could we have an option in the prefs that disables the on swipe
> check leaving only the on save one? Data integrity wouldn't be
> ultimately be affected.
>
> I am willing to make any proposed changes in this email. I just wanted
> to sanity check them and get the community's reaction before
> proceeding.
>
> Thanks everyone!
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
tom,
thanks for the feedback. i've filed all these as issues and requests
below. we'll start hammering on them soonish.
-
'Change' username/password
http://code.google.com/p/opendatakit/issues/detail?id=397
-
Why prompt for credentials when already entered
http://code.google.com/p/opendatakit/issues/detail?id=398
-
"Generic exception"
http://code.google.com/p/opendatakit/issues/detail?id=399
-
Hard returns in inappropriate text boxes (login, password, integer, float)
http://code.google.com/p/opendatakit/issues/detail?id=400
-
Show bigger box for 'long text' fields
http://code.google.com/p/opendatakit/issues/detail?id=401
-
n/a for required integer/float questions?
http://code.google.com/p/opendatakit/issues/detail?id=402
-
Explanations for 'no' answer
http://code.google.com/p/opendatakit/issues/detail?id=403
-
Required check
http://code.google.com/p/opendatakit/issues/detail?id=404
yaw
···
On Thu, Oct 20, 2011 at 10:45, Gaetano Borriello wrote:
> Thomas:
>
> this is a fantastic list of feedback and exemplary of what we'd like
> from all our users. Thanks for taking the time to put it together.
> We will certainly look this over and get back to you.
>
> Gaetano
>
>
>
> On Thu, Oct 20, 2011 at 9:11 AM, Thomas Smyth wrote:
>> Dear all, I have just returned from Liberia where the Carter Center
>> used ODK for its election monitoring operations for the first time. We
>> had 28 phones in use across all 15 counties of the country. We used
>> ODK collect along with the custom form designer/aggregator that I have
>> built for TCC and previously shared on this list. We used Tableau (a
>> popular BI package) for analysis. The system worked very well and TCC
>> leadership was happy with the results.
>>
>> Several issues with ODK Collect arose during the deployment. I'd like
>> to raise them one by one below to see if others have encountered
>> similar issues, or if there is a fix that I'm not aware of, or if
>> there are suggestions for improvement, etc. So here goes:
>>
>> 1. 'Change' username/password
>> When entering credentials on the preferences screen, the dialog title
>> is 'Change Username' or 'Change Password'. This has confused some
>> users who thought they were being asked to change their system
>> password rather than simply to enter it. So I propose changing these
>> titles to read 'Enter Username' and 'Enter Password'.
>>
>> 2. Why prompt for credentials when already entered
>> Even if users enter their credentials in the prefs screen, a prompt
>> always appears on the first request after ODK is opened. This is both
>> confusing and slows things down as two request/responses must take
>> place instead of one. Is there any reason for the prompt or could we
>> just send the saved credentials with the first request and only show
>> the dialog if there is an auth failure?
>>
>> 3. "Generic exception"
>> Attempting to send forms with no internet connection gets a 'Generic
>> Exception' error message. This was confusing to folks and I got tons
>> of calls with people wondering what the problem was (many of them had
>> simply run out of credit and lost their edge connection.) If it said
>> 'No network connection', this would be much more helpful. I can take a
>> look at this if it's ok with y'all.
>>
>> 4. Hard returns in inappropriate text boxes (login, password, integer, float)
>> Can we disallow hard returns in these places? Some folks managed to
>> push enter a few times by accident, leading to great confusion,
>> especially in the username/password boxes where the extra returns are
>> not visible but result in auth failure.
>>
>> 5. Show bigger box for 'long text' fields
>> In my designer/aggregator, the form designer can choose between short
>> text and long text field types, which effects how the fields appear on
>> the web version of the forms (text field vs. text area). I suggest
>> something similar for ODK so that long text questions could have
>> bigger text boxes when the question loads. Several users didn't know
>> that the field would expand (a reasonable assumption I think) and thus
>> wrote something like 'not enough space' for some questions. This could
>> be as simple as an extra attribute in the xml like boxheightlines="5"
>> or something. The field type could still be 'string'. Thoughts?
>>
>> 6. n/a for required integer/float questions?
>> Some of our integer questions were required, but 'not applicable'
>> would be a valid and useful answer. What have folks done in this
>> situation? I suppose one could make it a string field with a 'number
>> or n/a' regexp constraint, but this seems hackish. Couldn't there be
>> an attribute like allowna="-1" which shows an 'n/a' checkbox and
>> stores the specified value (-1 in this case) for the answer if this
>> box is checked?
>>
>> 7. Explanations for 'no' answer
>> Our forms were composed of mostly yes/no/n/a questions, with 'no'
>> usually indicating something out of the ordinary (e.g. "Is the polling
>> station calm and peaceful: Yes/No/N/A). So if an observer answers
>> 'no', we want an explanation. We have tried having a string question
>> immediately after with a 'if previous == no' condition. This works,
>> but it's a jolly big pain in the rear to do this manually for all
>> 30-40 questions. Has anyone ever come up with an easier way to do
>> this? If not I will probably add some kind of shortcut feature to our
>> designer.
>>
>> 8. Required check
>> ODK currently complains about unanswered required questions at two
>> different points: on finger swipe and on save. The only way to
>> circumvent the on swipe check is to use menu->go to prompt. This was
>> annoying for our observers who often fill out the forms in non-linear
>> order. Could we have an option in the prefs that disables the on swipe
>> check leaving only the on save one? Data integrity wouldn't be
>> ultimately be affected.
>>
>> I am willing to make any proposed changes in this email. I just wanted
>> to sanity check them and get the community's reaction before
>> proceeding.
>>
>> Thanks everyone!
>>
>> --
>> Post: opendatakit@googlegroups.com
>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>>
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
Wow, super! I have patches for some of these already. I will
contribute when I get a moment.
I would welcome a discussion on #'s 6 and 7 as they are the least
straightforward of the bunch...
···
On 30 October 2011 00:22, Yaw Anokwa wrote:
> tom,
>
> thanks for the feedback. i've filed all these as issues and requests
> below. we'll start hammering on them soonish.
>
> 1. 'Change' username/password
> http://code.google.com/p/opendatakit/issues/detail?id=397
>
> 2. Why prompt for credentials when already entered
> http://code.google.com/p/opendatakit/issues/detail?id=398
>
> 3. "Generic exception"
> http://code.google.com/p/opendatakit/issues/detail?id=399
>
> 4. Hard returns in inappropriate text boxes (login, password, integer, float)
> http://code.google.com/p/opendatakit/issues/detail?id=400
>
> 5. Show bigger box for 'long text' fields
> http://code.google.com/p/opendatakit/issues/detail?id=401
>
> 6. n/a for required integer/float questions?
> http://code.google.com/p/opendatakit/issues/detail?id=402
>
> 7. Explanations for 'no' answer
> http://code.google.com/p/opendatakit/issues/detail?id=403
>
> 8. Required check
> http://code.google.com/p/opendatakit/issues/detail?id=404
>
> yaw
>
> On Thu, Oct 20, 2011 at 10:45, Gaetano Borriello wrote:
>> Thomas:
>>
>> this is a fantastic list of feedback and exemplary of what we'd like
>> from all our users. Thanks for taking the time to put it together.
>> We will certainly look this over and get back to you.
>>
>> Gaetano
>>
>>
>>
>> On Thu, Oct 20, 2011 at 9:11 AM, Thomas Smyth wrote:
>>> Dear all, I have just returned from Liberia where the Carter Center
>>> used ODK for its election monitoring operations for the first time. We
>>> had 28 phones in use across all 15 counties of the country. We used
>>> ODK collect along with the custom form designer/aggregator that I have
>>> built for TCC and previously shared on this list. We used Tableau (a
>>> popular BI package) for analysis. The system worked very well and TCC
>>> leadership was happy with the results.
>>>
>>> Several issues with ODK Collect arose during the deployment. I'd like
>>> to raise them one by one below to see if others have encountered
>>> similar issues, or if there is a fix that I'm not aware of, or if
>>> there are suggestions for improvement, etc. So here goes:
>>>
>>> 1. 'Change' username/password
>>> When entering credentials on the preferences screen, the dialog title
>>> is 'Change Username' or 'Change Password'. This has confused some
>>> users who thought they were being asked to change their system
>>> password rather than simply to enter it. So I propose changing these
>>> titles to read 'Enter Username' and 'Enter Password'.
>>>
>>> 2. Why prompt for credentials when already entered
>>> Even if users enter their credentials in the prefs screen, a prompt
>>> always appears on the first request after ODK is opened. This is both
>>> confusing and slows things down as two request/responses must take
>>> place instead of one. Is there any reason for the prompt or could we
>>> just send the saved credentials with the first request and only show
>>> the dialog if there is an auth failure?
>>>
>>> 3. "Generic exception"
>>> Attempting to send forms with no internet connection gets a 'Generic
>>> Exception' error message. This was confusing to folks and I got tons
>>> of calls with people wondering what the problem was (many of them had
>>> simply run out of credit and lost their edge connection.) If it said
>>> 'No network connection', this would be much more helpful. I can take a
>>> look at this if it's ok with y'all.
>>>
>>> 4. Hard returns in inappropriate text boxes (login, password, integer, float)
>>> Can we disallow hard returns in these places? Some folks managed to
>>> push enter a few times by accident, leading to great confusion,
>>> especially in the username/password boxes where the extra returns are
>>> not visible but result in auth failure.
>>>
>>> 5. Show bigger box for 'long text' fields
>>> In my designer/aggregator, the form designer can choose between short
>>> text and long text field types, which effects how the fields appear on
>>> the web version of the forms (text field vs. text area). I suggest
>>> something similar for ODK so that long text questions could have
>>> bigger text boxes when the question loads. Several users didn't know
>>> that the field would expand (a reasonable assumption I think) and thus
>>> wrote something like 'not enough space' for some questions. This could
>>> be as simple as an extra attribute in the xml like boxheightlines="5"
>>> or something. The field type could still be 'string'. Thoughts?
>>>
>>> 6. n/a for required integer/float questions?
>>> Some of our integer questions were required, but 'not applicable'
>>> would be a valid and useful answer. What have folks done in this
>>> situation? I suppose one could make it a string field with a 'number
>>> or n/a' regexp constraint, but this seems hackish. Couldn't there be
>>> an attribute like allowna="-1" which shows an 'n/a' checkbox and
>>> stores the specified value (-1 in this case) for the answer if this
>>> box is checked?
>>>
>>> 7. Explanations for 'no' answer
>>> Our forms were composed of mostly yes/no/n/a questions, with 'no'
>>> usually indicating something out of the ordinary (e.g. "Is the polling
>>> station calm and peaceful: Yes/No/N/A). So if an observer answers
>>> 'no', we want an explanation. We have tried having a string question
>>> immediately after with a 'if previous == no' condition. This works,
>>> but it's a jolly big pain in the rear to do this manually for all
>>> 30-40 questions. Has anyone ever come up with an easier way to do
>>> this? If not I will probably add some kind of shortcut feature to our
>>> designer.
>>>
>>> 8. Required check
>>> ODK currently complains about unanswered required questions at two
>>> different points: on finger swipe and on save. The only way to
>>> circumvent the on swipe check is to use menu->go to prompt. This was
>>> annoying for our observers who often fill out the forms in non-linear
>>> order. Could we have an option in the prefs that disables the on swipe
>>> check leaving only the on save one? Data integrity wouldn't be
>>> ultimately be affected.
>>>
>>> I am willing to make any proposed changes in this email. I just wanted
>>> to sanity check them and get the community's reaction before
>>> proceeding.
>>>
>>> Thanks everyone!
>>>
>>> --
>>> Post: opendatakit@googlegroups.com
>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>
>>
>> --
>> Post: opendatakit@googlegroups.com
>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>>
>