Sorry, I don't like the idea of "overloading" and dynamically changing now the instanceName to mix-in a status/workflow concept.
We would prefer a status attribute/variable (maybe a metadata via setting sheet) which allows to clearly separate forms, even in different UI "folders"/menu items", still in progress at enumerator level (e.g. take a lunch break or meet household again next days) and forms declared as "finalised" by the enumerator, i.e. ready for local QA by/with supervisor.
We would also like that new concepts are similar in Collect and Enketo, very often we use both in the same survey. E.g. Enketo/KoboToolbox has a "validation_status" and a "Validate" option in preview.
Can you say more about why? This has always been one of the intended uses of instance name. Its advantage is that it's completely workflow-agnostic and allows you to decide exactly how you want the status information conveyed.
My understanding is that our recent and ongoing changes around finalization are neutral with respect to this unless your form design specifically allowed enumerators to finalize without supervisor approval and then finalize again with supervisor approval so that "finalized" had two different meanings. This is certainly possible but I would expect it to be quite rare. If this is what you did, it would be helpful to see your form design.
You are asking specifically for more built-in support for review workflows. We have considered this at various points over time but it feels like a separate endeavor that we likely won't be able to prioritize in the short term. We'll be sure to reach out as part of user research when we do get to it.
Did you know that the ODK team now maintains Enketo as well? We've been doing our best over time to harmonize concepts between it and Collect as we can. Both have a lot of history and large user bases so we do this iteratively and make sure it's guided by user research. Indeed, harmonization with Enketo is yet another reason we want to move in the direction of having a clear separation between drafts and finalized forms. In Enketo's offline mode, forms can either be saved as draft, in which case they are editable, or can be queued for sending, in which case they are not editable. We are working towards Collect matching that.
As you note, the preview mode of Enketo has a "Validate" button. What we typically hear from users is that it's not immediately obvious that this will check the data entered. Because it's only available in preview, it feels like it should be about the form definition. This is something we do hope to improve. As far as I know, the term "validate" and that functionality are not available anywhere else from Enketo but do let me know if I'm missing something. For Collect, we considered "Validate" at lengths when naming the new "Check for errors" functionality but again, it didn't feel clear enough what it was validating and what a valid form would mean (is it about the structure? Does it include required questions being filled?).
I am slightly uncomfortable with the process of Bulk Finalisation that you have described and it feels a bit like a retrograde step in that I think it loses the 'granularity' of being able to hold different forms at draft or final state. As @BartRoelandt2 indicated the current workflow used when sending multiple forms would intuitively make sense to me too - especially when you have the 'select all' option.
My experience is that 'tap and hold' to initiate multiple select or a 'select all' button is quite common and is a reasonable expectation for enumerators, and having the opportunity to finalise some forms and not others would appear to be more useful than all or nothing. My original suggestion of bulk finalise was implicitly thinking of the same process as for sending forms so that it didn't introduce visual clutter or complexity (naively assuming that you could replicate the process rather than start from scratch!).
Perhaps there are plans to remove that from the workflow of sending finalised forms?
One reason that I am concerned is that your suggestions for validation mean that I need to redesign existing forms to add that validation, and I had moved away from 'required' because enumerators can't move past the question unless it is filled in (unless that behaviour has changed?)...
Apologies if this appears negative, I understand how far backwards you are bending to be helpful and responsive
Thanks for the details, @seewhy. Do you think bulk finalized as described adds any value to you? Note that you could add just a single required question at the end to prevent finalization as appropriate. We could also consider dropping this work for now and continuing to gather feedback.
The major difference is that in “ready to send” the primary goal of a data collector is to send forms. In drafts, we don’t want to steer users towards workflows that involve bulk finalization and so we do want it to be something that end users have to know about to use rather than a primary action.
Not currently but we generally recommend using auto-send and not seeing that screen at all.
Can you actually add a little bit more detail around this, please? Here's what @BartRoelandt2 said earlier which matches my understanding of a case where someone wouldn't want to finalize everything:
Our sense for something like that is that because the numbers are few, you could do two passes: first identify the filled forms that need review and mark them in some way (e.g. check a box for a last question that says "needs further action" or maybe do nothing if a critical piece of information like species is missing), then bulk finalize. I realize it may not be your absolute ideal but it feels like a good balance between efficiency for your workflow and not interfering with other workflows we know are more common.
My understanding of your workflows was that you were mostly offline for a long time and then heading back to an area with connectivity for periodic submission. In that case, it seems everything could be a draft always up until the moment you're ready to send and so bulk finalization would be a good fit. Can you share some specific cases in which you would want to finalize a subset of filled forms, please?
The granularity I mean is about being able to make decisions about my data and when I think it is ready for submission. This has been a strength of ODK Collect that I have always been able to manage the data while it is on my device and I suppose I may even have developed 'bad' habits as a result. If I am using more than one form-set (I'm trying to differentiate between forms / surveys and records here) then they are not always ready to finalise at the same time - in my case it would be 1 or possibly 2 of Form A (the site description) and usually between 20 and 100 of Form B (detailed records for each location), but could be more. This actually arises from having moved away from deep nesting / repeats to simplify data collection on a 'point-by-point' basis (i.e. enumerators not having to navigate the 'add new...' and getting lost in the form). If I am at the same site for more than one day I would usually try to submit multiples of Form B (to avoid potential data loss) but not Form A just in case I need to change anything on that. I would need to make any edits to Form B on the same day either in the field or at the end of that session.
But with more discipline maybe I can work round it so maybe I'm being over-cautious and want too much control. This one feels like a 'breaking-change' so I have to adapt - it's not necessarily a bad one. Maybe I need to change Form A to introduce a 'required' question to prevent finalisation and not touch the design of Form B... I had nearly made Form A redundant by a conditional section that only shows for the first record, dependent on the site name from the previous record being the same but haven't amalgamated them. Maybe that's the cause of reluctance from those of us involved in this discussion - things were 'working' (or at least we'd got accustomed to them) and now they won't without our own intervention.
I recognise that for larger scale data collection there may be good reasons to discourage or even prevent editing a form so maybe, as you say, these requests don't meet those needs of the majority.
I still think bulk finalise is a good idea, so thanks for taking that on board. And hopefully we are more sure of the implications (I am!) of change.
Maybe you need a new job title: The Extraordinary Cat Herder
They're not bad habits, you used some things the tool could do, and now the tool is changing on you! I've been on the other side of that and I know how frustrating it is, even knowing that there's a bigger picture out there. I want to be clear that the whole team feels empathy for those having to rethink some of their processes because of what we're doing. We're really trying to make things as smooth for as many people as possible without ending up with the Homer car as @Aly_Blenkin likes to say.
This is a change I definitely support and that I hope has been overall helpful.
This sounds like it would be a good change. The question could even be something like "Have you sent all Form B records?" to force a sequence between the two. Even if everything stayed the same in Collect, that would prevent you from accidentally autosending the wrong forms if you were going too quickly, for example. In general, if there's a verification step that's required, I think it's very helpful to encode that in the form with a required question.
Hello @LN,
Thanks for explaining more.
Yes, we know and are glad you took over Enketo management. So, hopefully, differences will diminue (like regex and date behaviour
We would then have to program these changes of instanceName:
Saved Prefix_ (in work)
Ready for QA Prefix_ (i.e. "finalised" from enumerator view)
a) QA sucessful Prefix_ (might be with adfitional remark or
b) QA rejected Prefix_
...
Ready for Send Prefix_ (really "finalised", incl. QA)
Sent Done, only visible in menu (cannot be programmed in instanceName).
Until now we used "finalise" by enumerator to check for errors and then to transfer to QA by local supervisor.
A new check for error option (in the sandwich menu) would be great and can replace parts of our finalise usage.
Auto-send should not be the only option, please, esp. in remote areas. Sometimes we even use enumerator devices without Wifi/Internet and transfer via Blutooth/Hotspot (e.g. Supervisor or IT support in the field).
I know what you mean and agree those differences are very annoying. They're not at the very top of our current list (and they're unfortunately not as straightforward as they may seem) but we're aware of them.
What do you think of only adding a prefix for "ready for QA"? Here are how I think the other states can be identified:
in progress: no prefix, only available from drafts
ready for QA: this is where a prefix feels very helpful to me
QA successful: the reviewer can finalize or send depending on connectivity
Ready for send: this feels the same as qa successful to me so I'd need more info to differentiate the two
QA rejected: no prefix, only available from drafts; this feels generally similar to in progress. Alternately, you could include prefixes for common tasks that need to be done or even the full QA comment.
Here is a sample form with the general idea I have in mind. This would work the same way before and after finalization is made truly final.
How are you differentiating between in progress, ready for QA and QA successful currently? I see two options without a prefix:
you don't have a required question for QA. This means that in a world where finalization isn't final, you can finalize to indicate "ready for QA". It also means a "ready for QA" submission can accidentally be sent if there's an internet connection. Or if there's no internet connection, there's no way to differentiate between pre and post QA.
you do have a required question for QA. This means you can't finalize to indicate "ready for QA" and so you need to rely on memory to differentiate between in progress drafts and ready for QA.
It's available now in v2023.2!
We do recognize the value of manual send for certain workflows and don't have any plans to remove it.
This new menu option is initially not available when you reedit/reload a draft (showing the navigation tree), unfortunately, you first need to move to the beginning or end or to open an element (e.g. field). Would be preferable to make it directly clickable here, for ex. for supervisor checks.
Yes, agreed! We are also considering going directly to the first error in the filled form when launching a draft with validation errors. It won't be part of this initial release but we will try to get to it soon.
As a workaround, we used this (finalise click before) to allow an enumerator to find the next position (question) in the form if a household interview was not yet completed and now this form is reloaded to continue. We recommended to always stop at a mandatory field leaving it empty.
It might be good to offer such positioning automatically on edit of a saved form. (Even without check error click)
This bulk finalization is useful.
I agree with @BartRoelandt2 ' s suggestion on making it possible to select or deselect options, instead of all or nothing.
Adding a question dedicated to the supervisor only is not practical because the enumerators can answer yes to yet if they don't pay good attention or check it by error.
We can select some forms to finalize and send, and keep some that don't have missing answers or detected errors, but content verification to check later.
You might add a secret individual id and a "password" field for the operator and validate it (internally). Also a signature field might be an option.
Don't forget to trust your enumerators, please. Sometimes the problem lies deeper, on a more general level, like recruitment, training, motivation, time schedule, payment, teams, ...
The option to add a field to validate internally seems to be good, thank you very much.
You are right, but our question is not about trust or not.
Our enumerators are people that never touched a smartphone before, don't understand any foreign language, and with a low level of literacy. It is by choice to involve local community in the data collection, and to imrpove their skills.
ODK is awesome because those people can use it with basic understanding.
However, we need to take all our precautions, and especially find the best form design and adapted settings to avoid confusion or mess, even in case of small unattentional selection from the enumerators. It is unavoidable and understandable regarding our project time limited for training also.
Very insightful suggestions, thank you very much.
We will take them into considerations within the limits of what is possible (available time, trainer, budget, ...), and in future projects planning.
I really like the idea of a hotline, thank you. It will be the most practical.
We also thought about predetermined answers in a section of "Frequently Asked Questions" as a digital manual in the tablet or printed.
@Fanilo_Andrianisaina thank you for advocating for your enumerators and @wroos for the suggestions. It's very true that we can all make mistakes and ideally the system would prevent most of them.
Have you had a chance to take a look at our new end-of-form guide? There may be some configuration and form design ideas that apply to your situation there.
You may also be interested in some exploration we've started around a possible new way of editing finalized and sent forms. This would work like submission edits on the server: both the original data and the edit would be submitted and appear on the server for review. We imagine this would be off by default and configurable for workflows that can benefit from it. We'll have more to share on the forum soon and it will also be the topic of what I'm sure will be a lively conversation for the next Insiders call.
