translations of the app itself.

From the UI layout as it currently stands, I'm having difficulty deciphering how to use the form builder in order to make it accessible to others. In order to make it accessible for everyone I'd like to know what a few things are:

• What are "Groups"? Is it related questions? Is it the entire survey that you then export?
• Is there more than one form in a survey?
• Can you currently make more than just a text question / do you switch Form Elements by clicking on them or another way?
• What are the "Properties"? I see "Base" is kind of a title of a question? What is the "Display" and does it display anywhere yet?
• What do the buttons in the top left do in a group? I see a trash can (delete I can see) and reordering arrows but I can't tell what the checkbox does and why it turns into a list icon?

Current UI Layout:

Any questions in a section should be displayed as followed:

• left aligned instead of center aligned
• remove bullet points in front of question
• the text that shows should be the base display text, instead of the name

https://build.opendatakit.org/

Motivation

Let's 'universalize' the design for both sections and questions. I have a basic proposal that incorporates feedback and ideas from the other issues and attempts to resolve future, impending issues.

Survey (as a whole)

the survey as a whole has additional properties and the current design has nowhere to put them for editing. thus i propose that the survey be treated the same as sections and questions: you can "select" the survey-as-a-whole in order to edit its properties.

this solves the immediate problem of editing the survey name and the survey display in multiple languages, in addition to [in the future] supporting editing the survey "system" settings.

to this end, let's replace the current single input with the new pencil/checkmark selection button and a helpful label, like "Survey Properties".

Sections

As @johnhbenetech suggested, there should always be at least one section available - and you cannot delete the last section.

I propose a modification of the current design:

The leftmost icon button is edit, as a pencil icon initially and after clicked becomes the same checkmark icon we have now. Then the base display name (not system name), followed by a margin, followed by the up/down movement buttons and finally delete on the far right.

finally, at the bottom of every section (beneath the questions list) will appear a horizontal list of buttons for appending a question of that type. the question will always be appended to the end of the section to which it belongs.

Questions

as seen above, questions are almost identical to sections, except that they will include on the left an icon displaying their type (for screen readers it will be spelled out). questions will appear in order as list items, without the bullet points.

is this a requirement, or can it be ignored?

There are a few needed systems values currently missing from the XLSX export:

setting_name: survey
display.title = user friendly survey name
display.title.spanish = spanish user friendly survey name

setting_name: table_id
value: computer survey id
can be autogen

setting_name: form_id
value: computer survey id
can be autogen

setting_name: form_version
value: computer version code
can be autogen

And then for each section:
setting_name: section name
display.title = english section display
display.title.spanish = spanish section display

The 'survey' sheet should not have a 'required' column nor any values

what do we have right now?

e2e working survey creation with groups and text questions.

high level goals

to gain our first user. considering usage of the application is foreign and complex to the developers, i want to put the application into the hands of its future users asap in order to start a healthy feedback cycle.

high level plans

• what do we need to add, at a minimum, for this application to be available and used?

let's enumerate the possible data types / questions and their properties.

given the complexity of the application, we need to be able to identify errors sooner rather than later.

while we can end to end test the website for site specific errors, i suggest we start integrating the json <-> odk2.0 library asap in order to provide a "start to finish" testing environment for the product owners.

at the same time, i propose that we integrate CI so that deployments to a dev site are always up to date and the product owner can check in on the progress of the site itself at any time.

Should be in

display.title | display.title.spanish

under the 'settings' sheet

where 'setting_name" column = the section name

motivation

to enable the site's access for those who are less accessible.

acceptance criteria

• to achieve WCAG AA compliance for the current iteration of the site
• to document for other developers moving forward how to maintain compliance

etc

i will leave it up to @johnhbenetech to explain the finer details.

i would like to add that the assignee most importantly adds some basic documentation, summarizing what they learned in the process, most helpful resources, anything else they deem necessary.

what do we have right now?

a basic outline of the application, with dynamic forms, groups, questions but without the details.

high level goals

to achieve a working application that can import and export an ODK2.0 compliant file, supporting groups and text questions, with all features expected of MVP release: accessibility, translations (application and within form), etc.

high level plans

• CI for deployment and tests
• dependency management / versioning
• disable form controls, except text control and group
• accessibility
• application translation support
• group control functionality
  • properties from documenation
  • rearrange groups
• text control functionality
  • properties from documentation
  • rearrange controls within group
• import and export
  • create separate library for JSON <-> ODK2.0 XML
  • library should be maintained separately to maximize utility for future applications
  • integrate library into own application
• review and confirm that all required features are done
  • plan milestone 2 to integrate more question types

should include documentation about ODK2, Benetech, developers, licensing, etc.

Questions in a section sheet need to be enclosed in screen tags using the 'clause' column:

clause | type | name | ....

begin screen |
| text | Q1 | ...
| text | Q2 | ...
end screen |