Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add form design recommendations from the ODK webstie #24

Open
yanokwa opened this issue Aug 29, 2014 · 1 comment
Open

Add form design recommendations from the ODK webstie #24

yanokwa opened this issue Aug 29, 2014 · 1 comment

Comments

@yanokwa
Copy link
Contributor

yanokwa commented Aug 29, 2014

http://opendatakit.org/help/form-design/guidelines has useful guidelines that XLSForm designers should be aware of. Examples include:

  • form ID should be short (ideally < 10 characters).
  • form ID should be unique within your organization.
  • form ID must not contain any spaces or punctuation characters.
  • form ID should contain only alphanumeric characters and the characters '_' and '-'.
  • form ID should start with a letter
  • form version must be a numeric string for ODK (recommend yyyymmddhh)
  • value of select choice should not contain spaces ( XLSForm.org )
  • the odk:length attribute
  • field names should be short (ideally < 30 characters).
  • field names must be unique within their enclosing group within the form (this is required by XML and Javarosa).
  • field names cannot contain any spaces.
  • field names should contain only alphanumeric characters and the characters '_' and '-'.
  • field names should start with a letter.
  • field names should all consistently follow either the camel-case convention (e.g., thisFormField) with leading capitals denoting word breaks within the field name, or use either the '_' or '-' characters to mark word breaks (e.g., this-form-field).
  • field names should not have two or more fields that are distinguished only by either their capitalization, use of dashes, or use of underscores. E.g., a form that contains two or more of these field names will be confusing: thisFormField, this-form-field, thisformfield or this_formField.
@yanokwa yanokwa changed the title Add form design recommendations Add form design recommendations from the ODK webstie Aug 29, 2014
@ggalmazor
Copy link
Contributor

ggalmazor commented Oct 25, 2018

Also, the specs say: (emphasis mine)

version: String of up to 10 numbers that describes this revision. Revised form definitions must have alphabetically greater versions than previous ones. A common convention is to use strings of the form ‘yyyymmddrr’. For example, 2017021501 is the 1st revision from Feb 15th, 2017.

For example, ODK Aggregate parses the version string to a long integer and will fail to parse forms that include letters.

Should we say "numerically greater" instead of "alphabetically greater", to completely rule out any possible interpretation that leaves room for letters in the version?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants