ODK Build Suggestions

Support
1

I recently had a discussion about ODK with members of our team that
are now using ODK regularly. I want to pass on the feedback and
suggestions. Overall, in-field usage seems to be doing well and
everyone is happy with the data quality that is achieved with ODK
instead of paper based forms.

Most of the requests for improvement surround the building of forms/
surveys and management of questions and changes to questions.

  1. Pre-fix questions with sequential numbering:

    • For long surveys, it become hard to find a specific question
      on the survey based on the text of the question. People have been
      giving each question a number based on section and question (Example:
      Q: 1.1). However, if questions are added or removed during survey
      creation, these numbers get messed up. If would be helpful to have an
      option to automatically number the questions.

  2. Make entire sections conditional. Currently, the conditional logic
    must be added to each question.

  3. Drag and drop re-ordering of response options.

  4. Improve usability of saving, renaming, and copying forms.

    • Suppose you have a form called "Form A". If you choose to "save
      as" and use the default choice "Form A" you end up with two forms
      named "Form A". So you created a copy with the same name.
    • Suppose you have a form called "Form A". If you "save as" and
      call it "Form B" a new form is created (you can see it by going to
      Open Form). However, the name remains "Form A" on the form creation
      screen and if you hit save, it you will no longer have "Form B" but
      will have two named "Form A".

  5. Limit number of selections allowed in a select multiple question.

  6. A printable version of the form. This is something I mentioned
    previously and is something I'm hoping our team of developers can work
    on. It seems like more of a stand-alone task that may or may not be
    integrated into ODK Build.

Anyway, I thought I'd pass along some of this feedback. I'd be
interested in knowing which of these could be easily done and whether
any are planned.

We may also considering working on some of these improvements
ourselves, although that will depend on some budgets and timelines and
how much work it would be to setup the environment, understand the
Ruby code-base, make changes and then submit them back to the
community.

Thanks,
Matt

2

Hi Matt:

Thanks for all the suggestions. Point by point:

  1. Good idea. I'll add it to the features queue.
  2. There is already a task filed for this, I don't expect it to be difficult to do.
  3. Good idea. This should also be reasonably easy to do.
  4. There is a bug filed on the latter point here. I'll figure out how to deal with the former point when I build a better form manager.
  5. If this is possible in XForms then I can do it.
  6. I should actually be able to build something for this. Are you looking for a rendered/fillable paper form or just a representation you can look over?

Best,
Clint

··· On Monday, August 8, 2011 at 11:43 AM, Matt Langeman wrote:

I recently had a discussion about ODK with members of our team that
are now using ODK regularly. I want to pass on the feedback and
suggestions. Overall, in-field usage seems to be doing well and
everyone is happy with the data quality that is achieved with ODK
instead of paper based forms.

Most of the requests for improvement surround the building of forms/
surveys and management of questions and changes to questions.

  1. Pre-fix questions with sequential numbering:
  • For long surveys, it become hard to find a specific question
    on the survey based on the text of the question. People have been
    giving each question a number based on section and question (Example:
    Q: 1.1). However, if questions are added or removed during survey
    creation, these numbers get messed up. If would be helpful to have an
    option to automatically number the questions.

  1. Make entire sections conditional. Currently, the conditional logic
    must be added to each question.

  2. Drag and drop re-ordering of response options.

  3. Improve usability of saving, renaming, and copying forms.

  • Suppose you have a form called "Form A". If you choose to "save
    as" and use the default choice "Form A" you end up with two forms
    named "Form A". So you created a copy with the same name.
  • Suppose you have a form called "Form A". If you "save as" and
    call it "Form B" a new form is created (you can see it by going to
    Open Form). However, the name remains "Form A" on the form creation
    screen and if you hit save, it you will no longer have "Form B" but
    will have two named "Form A".

  1. Limit number of selections allowed in a select multiple question.

  2. A printable version of the form. This is something I mentioned
    previously and is something I'm hoping our team of developers can work
    on. It seems like more of a stand-alone task that may or may not be
    integrated into ODK Build.

Anyway, I thought I'd pass along some of this feedback. I'd be
interested in knowing which of these could be easily done and whether
any are planned.

We may also considering working on some of these improvements
ourselves, although that will depend on some budgets and timelines and
how much work it would be to setup the environment, understand the
Ruby code-base, make changes and then submit them back to the
community.

Thanks,
Matt

--
Post: opendatakit@googlegroups.com (mailto:opendatakit@googlegroups.com)
Unsubscribe: opendatakit+unsubscribe@googlegroups.com (mailto:opendatakit+unsubscribe@googlegroups.com)
Options: http://groups.google.com/group/opendatakit?hl=en

3
  1. yes, you can limit what you select as well as the total number of
    selections. how do you that elegantly in a ui is up to clint :slight_smile:
··· On Mon, Aug 8, 2011 at 11:47, Clint Tseng wrote: > Hi Matt: > Thanks for all the suggestions. Point by point: > 1. Good idea. I'll add it to the features queue. > 2. There is already a task filed for this, I don't expect it to be difficult > to do. > 3. Good idea. This should also be reasonably easy to do. > 4. There is a bug filed on the latter point here. I'll figure out how to > deal with the former point when I build a better form manager. > 5. If this is possible in XForms then I can do it. > 6. I should actually be able to build something for this. Are you looking > for a rendered/fillable paper form or just a representation you can look > over? > Best, > Clint > > On Monday, August 8, 2011 at 11:43 AM, Matt Langeman wrote: > > I recently had a discussion about ODK with members of our team that > are now using ODK regularly. I want to pass on the feedback and > suggestions. Overall, in-field usage seems to be doing well and > everyone is happy with the data quality that is achieved with ODK > instead of paper based forms. > > Most of the requests for improvement surround the building of forms/ > surveys and management of questions and changes to questions. > > 1. Pre-fix questions with sequential numbering: > - For long surveys, it become hard to find a specific question > on the survey based on the text of the question. People have been > giving each question a number based on section and question (Example: > Q: 1.1). However, if questions are added or removed during survey > creation, these numbers get messed up. If would be helpful to have an > option to automatically number the questions. > > 2. Make entire sections conditional. Currently, the conditional logic > must be added to each question. > > 3. Drag and drop re-ordering of response options. > > 4. Improve usability of saving, renaming, and copying forms. > - Suppose you have a form called "Form A". If you choose to "save > as" and use the default choice "Form A" you end up with two forms > named "Form A". So you created a copy with the same name. > - Suppose you have a form called "Form A". If you "save as" and > call it "Form B" a new form is created (you can see it by going to > Open Form). However, the name remains "Form A" on the form creation > screen and if you hit save, it you will no longer have "Form B" but > will have two named "Form A". > > 5. Limit number of selections allowed in a select multiple question. > > 6. A printable version of the form. This is something I mentioned > previously and is something I'm hoping our team of developers can work > on. It seems like more of a stand-alone task that may or may not be > integrated into ODK Build. > > Anyway, I thought I'd pass along some of this feedback. I'd be > interested in knowing which of these could be easily done and whether > any are planned. > > We may also considering working on some of these improvements > ourselves, although that will depend on some budgets and timelines and > how much work it would be to setup the environment, understand the > Ruby code-base, make changes and then submit them back to the > community. > > Thanks, > Matt > > -- > 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 >
4

Thanks for the quick response! As for #6, the ideal would be a
fillable paper form that could be used in cases where some field
officers are not comfortable with ODK, or if there are security issues
in certain areas. I was thinking if this was presented in nice HTML
output it could easily printed or turned into a PDF and it would be
part way towards a fillable HTML5 version.

Thoughts?

Matt

··· On Aug 8, 2:47 pm, Clint Tseng wrote: > Hi Matt: > > Thanks for all the suggestions. Point by point: > > 1. Good idea. I'll add it to the features queue. > 2. There is already a task filed for this, I don't expect it to be difficult to do. > 3. Good idea. This should also be reasonably easy to do. > 4. There is a bug filed on the latter point here. I'll figure out how to deal with the former point when I build a better form manager. > 5. If this is possible in XForms then I can do it. > 6. I should actually be able to build something for this. Are you looking for a rendered/fillable paper form or just a representation you can look over? > > Best, > Clint > > > > > > > > On Monday, August 8, 2011 at 11:43 AM, Matt Langeman wrote: > > I recently had a discussion about ODK with members of our team that > > are now using ODK regularly. I want to pass on the feedback and > > suggestions. Overall, in-field usage seems to be doing well and > > everyone is happy with the data quality that is achieved with ODK > > instead of paper based forms. > > > Most of the requests for improvement surround the building of forms/ > > surveys and management of questions and changes to questions. > > > 1. Pre-fix questions with sequential numbering: > > - For long surveys, it become hard to find a specific question > > on the survey based on the text of the question. People have been > > giving each question a number based on section and question (Example: > > Q: 1.1). However, if questions are added or removed during survey > > creation, these numbers get messed up. If would be helpful to have an > > option to automatically number the questions. > > > 2. Make entire sections conditional. Currently, the conditional logic > > must be added to each question. > > > 3. Drag and drop re-ordering of response options. > > > 4. Improve usability of saving, renaming, and copying forms. > > - Suppose you have a form called "Form A". If you choose to "save > > as" and use the default choice "Form A" you end up with two forms > > named "Form A". So you created a copy with the same name. > > - Suppose you have a form called "Form A". If you "save as" and > > call it "Form B" a new form is created (you can see it by going to > > Open Form). However, the name remains "Form A" on the form creation > > screen and if you hit save, it you will no longer have "Form B" but > > will have two named "Form A". > > > 5. Limit number of selections allowed in a select multiple question. > > > 6. A printable version of the form. This is something I mentioned > > previously and is something I'm hoping our team of developers can work > > on. It seems like more of a stand-alone task that may or may not be > > integrated into ODK Build. > > > Anyway, I thought I'd pass along some of this feedback. I'd be > > interested in knowing which of these could be easily done and whether > > any are planned. > > > We may also considering working on some of these improvements > > ourselves, although that will depend on some budgets and timelines and > > how much work it would be to setup the environment, understand the > > Ruby code-base, make changes and then submit them back to the > > community. > > > Thanks, > > Matt > > > -- > > Post: opendatakit@googlegroups.com (mailto:opendatakit@googlegroups.com) > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com (mailto:opendatakit+unsubscribe@googlegroups.com) > > Options:http://groups.google.com/group/opendatakit?hl=en
5

Clint and all,

··· On Mon, Aug 8, 2011 at 11:47 AM, Clint Tseng wrote:
  1. I should actually be able to build something for this. Are you looking
    for a rendered/fillable paper form or just a representation you can look
    over?

We've given a lot of thought to the proper way to represent a paper form in
terms of UX and scannability. If you get started, please give me a shout.

kuang

--
Kuang Chen | 陈旷

6

I think this is exactly the way to go. If something is going be built to
make the form printable, it should definitely be in HTML. As Matt says,
that will take us much of the way towards an HTML5 fillable form.

Gaetano

··· On Mon, Aug 8, 2011 at 1:15 PM, Matt Langeman wrote:

Thanks for the quick response! As for #6, the ideal would be a
fillable paper form that could be used in cases where some field
officers are not comfortable with ODK, or if there are security issues
in certain areas. I was thinking if this was presented in nice HTML
output it could easily printed or turned into a PDF and it would be
part way towards a fillable HTML5 version.

Thoughts?

Matt

On Aug 8, 2:47 pm, Clint Tseng c...@cs.washington.edu wrote:

Hi Matt:

Thanks for all the suggestions. Point by point:

  1. Good idea. I'll add it to the features queue.
  2. There is already a task filed for this, I don't expect it to be
    difficult to do.
  3. Good idea. This should also be reasonably easy to do.
  4. There is a bug filed on the latter point here. I'll figure out how to
    deal with the former point when I build a better form manager.
  5. If this is possible in XForms then I can do it.
  6. I should actually be able to build something for this. Are you looking
    for a rendered/fillable paper form or just a representation you can look
    over?

Best,
Clint

On Monday, August 8, 2011 at 11:43 AM, Matt Langeman wrote:

I recently had a discussion about ODK with members of our team that
are now using ODK regularly. I want to pass on the feedback and
suggestions. Overall, in-field usage seems to be doing well and
everyone is happy with the data quality that is achieved with ODK
instead of paper based forms.

Most of the requests for improvement surround the building of forms/
surveys and management of questions and changes to questions.

  1. Pre-fix questions with sequential numbering:
  • For long surveys, it become hard to find a specific question
    on the survey based on the text of the question. People have been
    giving each question a number based on section and question (Example:
    Q: 1.1). However, if questions are added or removed during survey
    creation, these numbers get messed up. If would be helpful to have an
    option to automatically number the questions.
  1. Make entire sections conditional. Currently, the conditional logic
    must be added to each question.
  1. Drag and drop re-ordering of response options.
  1. Improve usability of saving, renaming, and copying forms.
  • Suppose you have a form called "Form A". If you choose to "save
    as" and use the default choice "Form A" you end up with two forms
    named "Form A". So you created a copy with the same name.
  • Suppose you have a form called "Form A". If you "save as" and
    call it "Form B" a new form is created (you can see it by going to
    Open Form). However, the name remains "Form A" on the form creation
    screen and if you hit save, it you will no longer have "Form B" but
    will have two named "Form A".
  1. Limit number of selections allowed in a select multiple question.
  1. A printable version of the form. This is something I mentioned
    previously and is something I'm hoping our team of developers can work
    on. It seems like more of a stand-alone task that may or may not be
    integrated into ODK Build.

Anyway, I thought I'd pass along some of this feedback. I'd be
interested in knowing which of these could be easily done and whether
any are planned.

We may also considering working on some of these improvements
ourselves, although that will depend on some budgets and timelines and
how much work it would be to setup the environment, understand the
Ruby code-base, make changes and then submit them back to the
community.

Thanks,
Matt

--
Post: opendatakit@googlegroups.com (mailto:
opendatakit@googlegroups.com)
Unsubscribe: opendatakit+unsubscribe@googlegroups.com (mailto:
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

7

Kuang:

if there is stuff you can point us to, I'm sure the entire community would
be appreciative.

Thanks,
Gaetano

··· On Mon, Aug 8, 2011 at 5:11 PM, Kuang Chen wrote:

Clint and all,

On Mon, Aug 8, 2011 at 11:47 AM, Clint Tseng cxlt@cs.washington.eduwrote:

  1. I should actually be able to build something for this. Are you looking
    for a rendered/fillable paper form or just a representation you can look
    over?

We've given a lot of thought to the proper way to represent a paper form in
terms of UX and scannability. If you get started, please give me a shout.

kuang

--
Kuang Chen | 陈旷

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

8

Hi Kuang:

Given the other things Build is sorely lacking right now (better validation, branching, better first-time user experience, better form management), I can't say that printable forms are a top priority for me right now. However, if there's anything you can send my way I'll be sure to incorporate it when I get to the feature. It will be nice to have a solid direction to proceed in when I get started.

Thanks,
Clint

··· On Monday, August 8, 2011 at 5:11 PM, Kuang Chen wrote:

Clint and all,

On Mon, Aug 8, 2011 at 11:47 AM, Clint Tseng <cxlt@cs.washington.edu (mailto:cxlt@cs.washington.edu)> wrote:

  1. I should actually be able to build something for this. Are you looking for a rendered/fillable paper form or just a representation you can look over?
    We've given a lot of thought to the proper way to represent a paper form in terms of UX and scannability. If you get started, please give me a shout.

kuang

--
Kuang Chen | 陈旷

Post: opendatakit@googlegroups.com (mailto:opendatakit@googlegroups.com)
Unsubscribe: opendatakit+unsubscribe@googlegroups.com (mailto:opendatakit+unsubscribe@googlegroups.com)
Options: http://groups.google.com/group/opendatakit?hl=en