We’ve run into an issue where our CHWs have started capturing duplicate entries.
After some investigation it seems to be a multi faceted problem.
- We used a version of CHT that had the 50 contact limit, limiting work visibility.
- Users were on-boarded & trained with minimal data, possibly being unaware just how much the list items will grow and how to work through that in the UI.
- Users weren’t initially trained to use the “search everything bar” at the top.
- Users sometimes create an entry as a location/plot instead of a household (one layer down).
- There seems to be no mechanism to “look up” previously created records once in the creation flow.
From a training & design perspective we’re/we’ve:
- Upgraded to a newer commit where the 50 character limit issue had been addressed.
- Working with designers to create more “descriptive” icons, to clearly differentiate between the types of hierarchy people and places.
- Training users how to structure search terms when using the search bar.
- Emphasized users need to first look through the left hand side list before simply creating a new contact.
- Training users to provide more descriptive place (plot/location) names, and updating existing entries.
That being said, as devs we’re trying to make the usage of the app as seamless as possible.
There are two areas that need to be addressed:
Since suggesting the usage of the search bar, we’ve encountered some unexpected behavior as noted in this thread.
While some inconsistencies between the server & client have been addressed, the way the search functions fundamentally remains the same. We’re hoping that training our CHWs to use more descriptive names will largely mitigate the short & ambiguous location names, however, if the need remains to tweak the “ignored minimum search term length” - how would one go about doing so? I’m reluctant to do so, as I’m sure this will have a performance impact.
Our CHWs we’re use to the previous app halting duplicate contact creations, so it’s understandable that they would assume the same of this platform. Since recently learning of the
descendant-of-current-contactcompletion we thought of two ways to possibly address this:
- Back porting the
descendant-of-current-contactfunctionality to our instance version (4.2.2). I’m unsure how possible this would be, however I’m hoping it would be a quick implementation due to being CHT’s own code. We’d then, as soon as a person tries to register a household, use the parent ID (Indawo) to do a lookup to check for existing households that match that string.
- Write an extension library that can, using fuzzy logic, query the database for records that match a given string. Notify the user if the entity already exists, halt form creation, and perhaps also redirect the user to the entity they are interested in. Again, I’m not sure how possible it is to expose the db to such an extension-lib, so would greatly appreciate any guidance/thoughts.