I am doing a comparative analysis of ODK and OpenCRVS. While ODK surpasses in a lot of benchmarks,(including and especially offline working), there are 2 features which are causing the difference. One is the certificate printing qith the form data right at-the-spot. Second is the 2-way working of data (so submission gets approved and gets updated with new status on the field submission phone).
I am wondering if both these features are there on ODK, especially the certificate thing.
Would you mind to share your benchmark list (empty or filled) with the community, please? (For example, it might be interesting for further development of ODK.)
Can you please say more about what this means? Do you mean something like a receipt? Could the print form field type address this need? You can try it out in beta and we expect it will be released next week. It's not quite the same as a dedicated receipt or form printing button but it can be used as a way to output a summary formatted to your liking.
Our current primary focus is on supporting workflows with 2-way data sharing needs in a really generic way. That means we're not specifically targeting the kind of approval workflow you describe so there isn't a specialized UI around it.
You can do use entities for server-based approval workflows but you'll have to design forms that support each workflow step. For example, you could have one form that data collectors use that create new entities that they first encounter. Then a second form can list all entities for supervisors to review and then show a list of statuses like "approved", "needs corrections", "talk to supervisor", "rejected", etc. and maybe a text field for questions. That form can update entities when submitted. It could update both a status column and the label (e.g. prepend when approved). A third form can be used to show a list of supervisor-processed entities with possible actions to take.
The forms I described would look quite similar to the community reporting forms from the Entities tutorial that we recently published but the statuses would have different meaning.
This requires more form design work than a built-in review workflow and may also require more training. The tradeoff is that it's completely flexible and can be adapted to your specific needs.
If you were thinking more about an offline, on-device review workflow, see this guide for ideas.
It occurs to me that I answered the functionality questions but there's a broader question about how to compare ODK to special-purpose tools. ODK is designed to be general-purpose so its primary benefit is its flexibility. We try to balance that with relatively rapid and low-barrier access. We also aim to build robust, simple software that is stable over time.
When comparing it with a special-purpose tool, I would ask these questions:
Am I doing exactly the thing that the special-purpose tool is designed for? If so, I should probably use the special-purpose tool.
Do my assumptions about the thing that the special-purpose tool is supposed to do match those of the designers of the special-purpose tool?
Does the special-purpose tool provide workflow support that would reduce training burden vs. me having to encode that workflow across one or more forms?
Does the special-purpose tool require training and special knowledge that won't apply to other domains the same way ODK knowledge could?
Is the special-purpose tool interoperable with other systems in its domain in a way that ODK is not likely to be?
Is this special-purpose tool likely to be supported for the forseeable future?
when approved). A third form can be used to show a list of supervisor-processed entities with possible actions to take.