Currently, the barcode widget only contains a "Get Barcode" button however occasionally the barcode is not available. For example: barcode is damaged or missing. There is no way to enter a value without scanning the barcode.
The goal of this feature is to have a second option called "Barcode not available" (or similar) which would allow the user to type the value instead.
This would be similar to what stores do when barcodes can not be scanned.
This feature would increase the flexibility of the barcode widget.
What are some example use cases for this feature?
In general, use cases will be when the code represented in the barcode is known but the barcode is used for speed/avoiding misentry.
User attempts to scan barcode but it is damaged so will not scan. Using this feature, the user types in the human-readable code below the barcode.
User attempts to scan an item ID'd with a barcode but the item is missing. To record that this particular item is missing, the user will look up the barcode value in a log and, using this feature, enter this item's ID.
What can you contribute to making this feature a reality?
This will be quite difficult for us as we need to automatically convert predefined forms from an established database into ODK forms and then convert filled forms back into the original format.
For other projects, this work-around could function but I can see some disadvantages compared to the suggested functionality: Complicates building forms: For every barcode field, two fields need to be created along with a relevance expression. Complicates data entry: Those using the forms to enter data will have to be taught that sometimes when they skip a field a second field for the same data is presented. If this message doesn't make its way to the user, they may not know how to proceed if they cannot scan a barcode as there is no direction on-screen. Complicates pipelines: If a project uses ODK as part of a wider system of data collection, fields will have to be split/merged and logic will need to be in place for if both fields are filled (user could skip the barcode widget, type a value in second, then return to barcode screen and scan if a barcode becomes available. Which field should be accepted?).
While I believe that the work-around could do the job for some projects, adding an alternative method of barcode data entry would be cleaner and more user-friendly.
An optional appearance on type="barcode" to enter a string, or an optional appearance on a type="string" to capture it via a barcode... Ring a bell @LN?
[this was a debate we had some time ago... I 'lost' ]
I'm inclined to stick with the barcode type now, and just add another fallback question to capture it via a separate string question, which you can hide if your barcode returns something, as suggested by @yanokwa .
Hi @R_am
Welcome to the ODK forum. We're glad you're here. When you get a chance, please introduce yourself on this forum thread. I'd also encourage you to add a picture as your avatar because it helps build community!
]