Usability of of ODK Template

[fretchen]

          Hi there, sorry in advance for the length of the post and if any of these points are off topic, but this can happen with an external point of view 😊. I admit I didn't read all the associated documentation, but also on purpose, as I think it's useful to have such data collection tools as self-explanatory as possible to make sure everything is done for a quality data collection.

I guess the users will be perfectly aware/trained on all the notions etc explained (as else very hard to get the whole understanding for someone who does not have prior knowledge)? Because I doubt that many will open the external documentation, so it can be good to embed it further as hints/explanations in the form in my opinion. Relatedly, I would add a clearer title to the form, a quick intro explaining the purpose for the user (who is capturing, when & why), perhaps some section labels to give it flow/ for better readability (project general information, location specific info, location specific geo etc)? Perhaps add color/bold to some labels to make sure some elements are well read/ user friendly, ie start and end date in the activity_start /activity_end labels (https://xlsform.org/en/#styling-prompts).

Here is more specific feedback:
Unique-ID :

• It’s not clear to me for new locations what should be done for the code, as the variable is mandatory. Is there any guidance on how it should be built that could be added to the hint? Or a skip pattern on whether it’s new or not to be added to deal with the case?
• For the hint, maybe talk of variable rather than column, easier for the person collecting the data to understand

All text / number / data variables: any constraints that should be added (Regex- https://cartong.pages.gitlab.cartong.org/learning-corner/en/5_survey_design_mdc/5_6_form/5_6_4_validation_criteria#use-of-regex--when-how-and-examples-in-the-humanitarian-and-development-fields) or min/max for ex) to avoid errors? For example for it to be in a range of numbers, to start with a letter and then have X numbers, for there to be a min and max date or budget, to avoid avoidatable errors. Even just making sure there is no negative data captured:)

Data owner: perhaps add example in hint to make it more user friendly? I suppose a dropdown list with an “if other, please specify” would be too complicated to compile?

publishing_restrictions: will the person answering always know for sure if yes or no, or should a “to be discussed further” option be useful?

Location name: what should they do if there is no name? Describe its location, write NA?
Location Activity Status: there is no need to have an “if other please specify”? Just checking

Additional Activity-Description : would it make sense to make the text multiline in appearance so they can describe in more detail? I guess this depends if data is collected on web at all, which I imagine it is?

KC Theme/Sub-sector: I guess this is not finalised, but the names are not coded in a format that is exploitable, they are “just” normal labels, so the cascading lists can’t work -there are spaces, special characters etc)

DAC 5: don’t get the new row for each location, you mean a new submission? Or do you want a repeat group in the form so that a series of location per project can be captured inside one submission?

Budget share: same, do you want this in a repeat group, to then be able to make and check the sums through calculations? Sorry if off topic, hard for me to be sure of the general logic of what is being collected

Latitude & Longitude: If the data is not always captured in the field, could you not at least have a skip pattern to make a GPS type variable usable if relevant (as so much easier / less error prone…). Or if using an online app like Enketo in Kobo for capture, to be able to capture it by pointing on the map as such tools make possible? And if “yet unknown”, should there not be a skip pattern so the latitude/longitude not be captured, or else not make it mandatory?

Do you want any [metadata](https://cartong.pages.gitlab.cartong.org/learning-corner/en/5_survey_design_mdc/5_6_form/5_6_6_quality_control) (such as when the submission was started/ended?) or is it not useful?

And just a side note that made me smile- I just saw in the “start here” tab a mention of our XLSForm cheat sheet, that I initiated a few years ago, nice to see it being used 😊.

hope this is useful, don't hesitate if you have further questions,
Maeve

Originally posted by @maevedefrance in #18 (comment)

[fretchen]

@Maja4Dev gave the following response and list

Dear Maeve (@Jo-Schie @fretchen @goergen95),

thank you, this is very useful! We will try to add more explanation to the data fields, but we need to make sure that they dont become too long for data entry by mobile phone.

Unique-ID: is only mandatory if there are earlier versions that have received this ID by KfW. We will have to explain this better in this data field. And calling it variable here makes sense!

All text / number / data variables: we have lots of constraints in the excel template - who could add them in Kobo?

Data owner: This will be the name of an institution, so we can say, e.g. KfW or Ministry of Health Tansania. A drop down menu cannot be created, too many potential institutions.

publishing_restrictions: will the person answering always know this? Yes, because KfW will define this in the ToR. But we can add here: see also ToR

Location name: what should they do if there is no name? Describe its location, write NA? Yes, describe its location. We should make this clear.

Location Activity Status: there is no need to have an “if other please specify”? You are correct.

Additional Activity-Description: We would like to avoid lenghty descriptions. This field is for additional output features, like MW for a plower plant to show them on a map, not all the details.

KC Theme/Sub-sector: They only serve as a filter to help quickly finding the right location type among the 254 options, not to be themselves saved in the database. In the database should be only the location types. What do you mean that the cascading lists don't work?

DAC 5: don’t get the new row for each location, you mean a new submission? Or do you want a repeat group in the form so that a series of location per project can be captured inside one submission? - I am not sure I understand what you mean by new submission vs repeat group 🤔. A new row in the excel template would describe a different activity and/or location type/output and/or DAC-subsector at the same GPS-coordinates. We only did not clarify how to enter this in Kobo instead of Excel - we need to do this. If we can do this more elegantly by creating repeat groups, this would be cool!

Budget share: same, do you want this in a repeat group, to then be able to make and check the sums through calculations?
If this would be possible in Kobo, this would be cool!

Latitude & Longitude: If the data is not always captured in the field, could you not at least have a skip pattern to make a GPS type variable usable if relevant (as so much easier / less error prone…). Or if using an online app like Enketo in Kobo for capture, to be able to capture it by pointing on the map as such tools make possible? And if “yet unknown”, should there not be a skip pattern so the latitude/longitude not be captured, or else not make it mandatory? - We need to discuss this.

Do you want any [metadata]? All of the above is metadata but the coordinates ;-). We have the data of the latest update, the data owner - the timeframe of the collection is too much detail for us. We need to keep it simple. Any crucial metadata you are missing?

RE: Your XLSForm cheat sheet: Everything that goes around, comes around 😊. @ckreutz is always ever using the good stuff 😊.

So we should now try to work our way through the list:

• Unique-ID
• All text / number / data variables
• Data owner
• publishing_restrictions
• Location name
• Location Activity Status
• Additional Activity-Description
• KC Theme/Sub-sector
• DAC 5
• Budget share
• Latitude & Longitude
• Metadata

[maevedefrance]

Hello @fretchen @Maja4Dev,
Seeing Maja's, answers, I feel there may not be a need to create an issue for Data owner/publishing restrictions/additional activity-descrption.
For the others, especially those that require clarification, would you want us to plan an oral chat first? I'm available today before 11 or this afternoon if you wish.

[fretchen]

@S-r-f-l maybe you could attempt to implement the suggested changes ?

[maevedefrance]

Hi,
Thanks for the call.
so on this Unique ID side, from what I understood, it is not a "meaningful" ID for KFW, so a system generated ID would work fine. If this is the case, know that by default in your KoboToolbox database you always have a system generated UUID (the variable is called _UUID), which I suppose could fit this purpose.

Else, if you want a relatively "user understandable" unique ID you could set up the current Unique ID variable, that you would change to a calculate type question, with the following calculation:
concat(${project_abbreviation},'-', format-date-time(now(), 'M%mD%d-%Hh%Mm%Ss%3'))
(or else use another variable depending on what is relevant). It includes a timestamp (milisecond one, which means there is next to no chance of a dupplicate) as you had tested before, which might have been what you tested already? You would then just need to make sure that the variable is after the project_abbreviation for obvious reasons, and also use a regex constraint on the project_abbreviation text to ensure that there are no spaces and perhaps only capitals and numbers and a few special characters such as a dash or something.
Not sure how useful this is, but we can keep the conversation going :)
Maeve

[goergen95]

Hi all,

I just have to add my two cents to the UID topic. This topic can become very complex fast if you take into account
that some kind of persistency of identifying objects over time is within scope.
That is to say, how do we make sure that an object that once entered a system is identifited as the same object when new
data is coming in at a later stage?

What I want to point out is that there is a difference in the required process between simply assigning a unique identifer (either a UUID or a combination of timestamp + project identifier as suggested) and ensuring that a given object is persistently tracked as itself over time.
If the latter thing is a requirement, we need to carefully develop a processes for it.

Best,
Darius.

[maevedefrance]

Hello, I completely agree Darius. It just wasn't really clear to me the aim of this UUID (and I didn't hear anything about a follow up over time), but again, I didn't read the documentation (but which user does? 😉). Best, Maeve

…

________________________________ De : Darius Görgen ***@***.***> Envoyé : vendredi 22 mars 2024 15:39 À : openkfw/open-geodata-model ***@***.***> Cc : Maeve De France ***@***.***>; Mention ***@***.***> Objet : Re: [openkfw/open-geodata-model] Usability of of ODK Template (Issue #25) Hi all, I just have to add my two cents to the UID topic. This topic can become very complex fast if you take into account that some kind of persistency of identifying objects over time is within scope. That is to say, how do we make sure that an object that once entered a system is identifited as the same object when new data is coming in at a later stage? What I want to point out is that there is a difference in the required process between simply assigning a unique identifer (either a UUID or a combination of timestamp + project identifier as suggested) and ensuring that a given object is persistently tracked as itself over time. If the latter thing is a requirement, we need to carefully develop a processes for it. Best, Darius. — Reply to this email directly, view it on GitHub<#25 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BD254JLLBPZMXLLTZ72NGM3YZQ7DHAVCNFSM6AAAAABFC4QPVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGI2DQMJYGU>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[goergen95]

I agree with you as the aim of a UID is also unclear to me. A UID for its own sake is not of any practical value and if it is required by a process the definition of that process is still opaque to me.

[fretchen]

So. I think that this UID issue is actually quite independent from the ODK issue or am I wrong ? The same issue also exists for the Excel version and even in the general description of #20. So I would agree that this is an important point, might even merit a separate issue but that we will not be able to fix this for the ODK template at this stage ? This would require consistent updates across the board ...

[ckreutz]

@Maja4Dev and me knew from the start that an ID would be needed to differentiate between location types when we were still theorizing the standard.

But the UID totally depends on the use case scenario. If data collectors just run up KoboToolbox to do their manual upload, then the UID will be probably set automatically as I learnt today from @maevedefrance AND it is not required and probably not possible what @goergen95 refers to. And yes we also thought already about versioning, but this again depends on the respective use case scenarios and system.

I can only recommend to not make this overly complicated. It is fairly easy to still assign later on unique IDs e.g. just combining project number with some other identifiers.

[S-r-f-l]

@S-r-f-l maybe you could attempt to implement the suggested changes ?

Yes i will try to. :)