Open ctsims opened 4 years ago
@benrudolph This is the example I mentioned
Ok nice, thank you, will have a look and follow up with questions
Ok this spec makes sense. My gut here is that this violates all sorts of isolation done in the formplayer frontend code. IIRC, each question has no knowledge of any other question so it might be a huge hack to get this in. It would be cool if a case property could just store geopoints on any question type and it acted more as meta data on the question itself
@benrudolph Yeah, it's a bit tricky in a lot of different directions. Backend would be great, but in practice we really do need both pieces of data as validated since a lot of places won't have clear Addresses, but also a lot of places will prefer address to geopoint :/.
In terms of the hackiness, what I was thinking might be possible was creating the input box for the 'address' tagged input with a semantic tag / class / something (potentially also tagged with the parent group path to differentiate between these paired widgets) and then having the GPS widget be built under the presumption that the page may or may not contain an element with that tag.
That would let the two pieces still function more or less independently, but not sure if what it would take to get all of that set up would introduce a big burden of hackiness.
Abstract Support a consistent pattern for capturing both address and GPS coordinate data without requiring redundant entry from users.
Motivation In contexts where users are using webapps capturing both GPS Coorindate data and Canonical Address data for the same entity, right now they need to perform an awkward interaction where they provide an address and then copy/paste the address into a lookup field.
This could lead to errors in both the copied address, but also prevents users from using the feedback loop clearly to correct issues (IE: If the geopoint points to the wrong location it may be because of an error in the address which can/should be corrected).
Specification Formplayer should be updated to identify when there is a text entry field with the appearance
geopoint_address
inside of a group at the same level as the question. If it is difficult to identify the grouping, it is fine for this to look over the whole form instead as long as things fall back reasonably (IE: If there are 3 GPS entries and 4 address entries, nothing special should happen).When this pattern exists, the "Search" field input should be able to be populated from the value of the address field. This could either be with a "Default until overridden" pattern (IE: physically bound text input between the two fields which breaks when the user changes it), with a button that loads the value into the search field, etc.
We should likely not eliminate the search field entirely in the event that the address captured is an edge case and the user needs to search a different address to get a starting point for associating the right location.
Long term, Mobile could also implement this kind of pattern by providing a second button underneath the GPS trigger that does a geolookup of an entered address if network is available.
A sample vellum block follows which can be pasted into the form editor for testing
Impact on users User entry on Address+Geopoint pairs will be faster and more consistent.
Backwards compatibility This feature is a "best effort" way to help users, but any failures can revert to the pre-existing functionality of the system without issue.