I am supporting an organization as they migrate their Monitoring, Evaluation, and Learning (MEL) data collection from Microsoft Teams/Word to ODK.
The team is currently used to a "cloud office" workflow where multiple staff members "tile" different sections of a report progressively over several days. They rely heavily on two features that seem fundamentally different in the XLSForm ecosystem:
Collaborative, Progressive Filling: In Word, three people can work on different parts of the same report simultaneously. In ODK, submissions seem to be "black boxes" until they are finalized and sent. We need a way for Person A to start a record and Person B to finish it from a different device before it is considered "done."
Conversational Metadata (Inline Comments): The team uses sidebar comments and @mentions in Word to discuss data points during the entry process (e.g., "Check this figure with the finance team"). They need a way to have a dialogue about a specific record within the tool itself.
The Use Case: We are looking for a way to move toward structured data without losing the collaborative, iterative nature of their current process.
Questions for the Community:
ODK Entities: We are looking into ODK Entities to see if "Follow-up Forms" could allow different team members to progressively update properties of a single entity. Has anyone successfully used Entities to mimic a "shared draft" experience?
Philosophy Check: Is this collaborative, conversational drafting fundamentally outside of ODK's design goals?
Alternative Tooling: If the ODK ecosystem isn't the right fit for this specific "document-to-database" hybrid workflow, are there other tools the community recommends?
We would love to hear from anyone who has managed a similar transition or who has found a way to bridge the gap between "fluid document collaboration" and "structured form submission."
My initial thought is that your workflow may be a stretch for ODK. But maybe someone will point out something I’m missing.
Entities might work. The user will only see the most recent values, not the full history. The design could get quite complex. It sounds like you might need to create a new form for each report - which would be a lot of effort and fragment the structured data you’re trying to create with a new tool.
A project manager web-user role can edit submissions. And when you view a submission’s details there is a feed of changes and optional comments. But you don’t want multiple people trying to edit a submission at the same time. And I think the intent is for an audit log, less the collaborative work you describe.
I like the audit trail that you showed me, it is certainly a plus.
There is a tradeoff that would remain here, in between flexibility and control, that our client will have to weight at the end of this process…
The other recommendation i’ve got was to export the XLSForm as a document and use collaborative editing tools for pre-filling it, and then for one person to submit it …
This could work, but we are missing all the really cool features XLSForms have: multiple input widgets, computed fields, conditionals, group repeats, …
I will keep thinking about this and report back, eager to hear others if you have inputs!
Can you please share a little bit about the size and shape of the report? How many indicators are we talking about? It would be filled out from a desk at a computer, right? Are the reports confidential across the team or could they all be accessible from the same form?
Is the end product a consistent format, with 'blocks' of content populated into a template?
As @danbjoseph suggests, entities may get you what you need.
This is a possible approach that might work, assuming x known blocks to populate (via select/free text/etc inputs). Whether it's a good idea overall, depends on the content and workflow, eg simultaneous edits won't be possible, you'd end up with revision# issues if >1 users are editing version n and both submit.;
Create an entity list 'records' with the following fields for each block: content / comment / attention_to / status, plus some identifying fields (project / ID etc)
A simple data collection form could fill the content blocks only (eg field data collection) and set status to 'unreviewed'
A 'reporting' form could select the project --> ID to get to the entity and preload all the collected values for view/edit
any questions/comments could be put in the comment field against the block
attention can be drawn by selecting one or more staff against a block (equivalent of an @Nico in the word comments), and the top of the reporting form could use a staff select to filter only to records with mentions / mentions within in the record attention_to field that matches the user.
when a block is complete, its status can be changed to 'final'. there may be other statuses to filter for certain actions, when all statuses are 'final' the record can be rendered to a report
Extensions...
to preserve history and be visible during edits, you could concat the new value and a timestamp to the old value/timestamp in another field, but this could become quite large quite fast. You could also create a new entity for the record (and increment version #) with each edit and pull the latest when editing.
use the entities from repeats functionality if the report has a non fixed # of elements rather than having a super wide entity list with block1, block2... block100
use the multiple entity list functionality to have separate repeated blocks (some are single values, others are multiple) as well as other entity lists that are updated (survey status etc)