milestone 1

[tristanmkernan]

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

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

[johnhbenetech]

Can you clarify 'library for JSON <-> ODK2.0 XML'? My understanding is that XML isn't used in ODK2.

My thoughts of file formatting is as follows:

• While I agree that .XLSX isn't the best format for machines to read, for better or worse it is the format that the core ODK 2.0 developers are relying on at this point in time. ** Current process: user manually creates a XLSX file in the proper format. User runs XLSX through the ODKAppDesigner xlsxconverter function. User winds up with a directory that contains formdef.json, definition.csv, and properties.csv files. This directory is read by the mobile client and rendered as a survey,

For this reason, I would think the import/export from our designer should all be in XLSX. This way it has a better chance of benefiting down the line from other tools that may be developed by the community. If their isn't good support for this in browser let me know and we can discuss how to proceed.

[tristanmkernan]

@johnhbenetech you caught a typo - yes, XLSX and not XML haha.

[johnhbenetech]

Thought I would double check! thanks

[bripc]

We should break these high level plans down into separate issue threads so that individual devs (like me!) can pick something to work on.

[tristanmkernan]

@bripc totally - please feel free to pick something that sounds interesting and create a separate issue asking questions about it. there's a lot to do and it's difficult to spend as much time writing the issue as it would be to just do it myself sometimes!

[tristanmkernan]

@johnhbenetech could you review the current state of the application and let me know if the groups and text functionalities are correctly implemented?

[johnhbenetech]

@russon77 In general I think we are moving in the right direction. Some things I would like some thought around:

• Using the checkbox (4th button) to choose the actionable object is a bit confusing. Is there a way we could have the object selectable simply by clicking anywhere within that row? We can hold off on this if we think there is a better option or a11y considerations. @bripc thoughts?

• I think sub items (like a text question) should all be left aligned so that the action buttons are in the same place regardless of question length. I think sub-items should be an ordered list (numbers instead of bullets). We could also indent things slightly if we think that helps with understanding.

• Groups probably wont need the 'required' property as I imagine only questions (sub-items) will have required functionality. So i think just shifting those indicators to questions only would be great.

• Some responsiveness work is needed when word length exceeds container width. Currently the text pushes everything out of the container.

• eventually I think we will need to rethink the right-panel 'properties' paradigm. For instance, if you add several groups and questions, you will need to scroll down to view these items. When these items are selected, you then need to scroll back to the top to access the properties for that group. We have a couple options here, but interested in hearing more:

1. The right pane could float and scroll along with the user. In this manner it will always be in view. This probably has a11y considerations and also might be bad UX as it can suggest relationships between non-selected objects and the right-pane simply because they appear next to each other.

2. The properties can appear 'inline' with the questions in an accordion paradigm. Once you click on a row the accordion expands and property fields appear below.

3. Properties stays on right, but always appears to the right of the selected object. Once an object is selected, a panel appears to the right with a visual indication that it is related to that object.

[tristanmkernan]

Using the checkbox (4th button) to choose the actionable object is a bit confusing. Is there a way we could have the object selectable simply by clicking anywhere within that row? We can hold off on this if we think there is a better option or a11y considerations. @bripc thoughts?

"clicking anywhere in the row" was my original idea - but a11y is against clickable "divs" and specifically for "buttons". i agree that the current design is confusing 👍

Groups probably wont need the 'required' property as I imagine only questions (sub-items) will have required functionality. So i think just shifting those indicators to questions only would be great.

👍

Some responsiveness work is needed when word length exceeds container width. Currently the text pushes everything out of the container.

could you be more specific? are there limits to text lengths in odk?

For instance, if you add several groups and questions, you will need to scroll down to view these items. When these items are selected, you then need to scroll back to the top to access the properties for that group. We have a couple options here, but interested in hearing more:

the original design accounted for this by scrolling the groups only. this has not been implemented yet.

as for the other design questions, i don't "care" right now - i want to focus on the functionality for this milestone 1, make sure all the moving pieces are working together. we'll get back to making the design awesome when the application works!

[johnhbenetech]

wrt text length: https://imgur.com/a/Mp8Pr

It's a minor bug we dont have to deal with now.

+1 on the getting the milestone out the door before tackling some issues. I'll just keep bringing things up so we can have stuff in our heads as we proceed.

[tristanmkernan]

@DattaUSC could you create a new github repository for the JSON<->XLSX converter? maybe 'odk2-format-converter'

[tristanmkernan]

@johnhbenetech with the latest changes deployed live, basic import and export are working! i would like for you to review the site with a fine-toothed comb. there are definitely some issues, but i'd like your feedback specifically geared towards what needs to be done in order to put this in the hands of users - even in a reduced capacity, like for creating the template and then manually filling in whatever we're missing while it's developed. that's my ideal here.