I too would be very interested in hearing about others' experience and best practices. I've mostly been involved in train-the-trainer contexts myself but I have had the opportunity to observe or read reports from some field staff trainings. Here are some of my observations:
- where possible, co-designing forms with field staff can go a long way in reducing training needs. Field staff can advise on things like what order it's appropriate to ask questions in, what kind of introduction is expected, how big of devices they'll have if using their own, how they're most comfortable expressing dates, etc.
- getting buy-in from field staff is really important. If they understand and believe in the goals of the project, they can be creative problem-solvers if needed. This may seem like an obvious point but it can feel really tempting to jump into mechanics and neglect this.
- relatedly, field staff benefit a lot from seeing the big picture of the form(s) they're going to be using. This could be using a high-level workflow diagram or a very granular flowchart like @Dalerhoda has shown examples of in this post. This again makes data collectors more like partners in the work rather than just followers.
- where possible, use hints, labels, images, audio, video within forms instead of external training materials. Those will get translated along with the form and won't go out of date. You can even have an option at the beginning of the form to see a tutorial. This can be shown/hidden based on a question like "are you practicing yes/no" or "do you want to see instructions yes/no"?
- think about the end-to-end workflow and limit the Collect interface as much as you can to reduce what data collectors have to think about. For example, if you don't want data collectors to be saving partially-filled drafts, use settings to prevent saving drafts and hide the draft button. This guide provides some example configuration ideas.
- spend your training time role playing and/or piloting. This will let you focus on real problems and misunderstandings.
- use the audit log at least for training and initial data collection. This will let you see how data collectors navigate your form and help identify sections that may not be working as intended.
Unfortunately I think the geoshape question type is one of the least intuitive in ODK. This is something we want to improve on both in Collect and web forms.
For now, you could do something like embed an image in the form that shows which controls to press (e.g. tap the "play" triangle, select the second "automatic" option, etc) right before the geoshape question. I think this is a case where practice with a trained facilitator would be ideal so that the facilitator can identify common mistakes and come up with suggestions on how to address them either in form design or further practice.
You could take an entirely other approach and instead use a repeat to capture points for the different vertices of the plot. You could have simple audio prompts like "walk to one corner of your field" with a picture of what a corner looks like (you might need community input on how to phrase this so it makes sense). You can use a technique like this one to ask a question like "are you back where you started?" to end the repeat.
You could also try things like making the form a bit fun and friendly by doing things like showing pictures of smiling community members or healthy cashew plants at the beginning or end. If data collectors have some numeracy and you already have estimated field sizes, you could show a comparison of the estimated and actual area.