Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CEP] GPS Address Based Assistance #26879

Open
ctsims opened this issue Mar 17, 2020 · 4 comments
Open

[CEP] GPS Address Based Assistance #26879

ctsims opened this issue Mar 17, 2020 · 4 comments
Labels
CEP CommCare Enhancement Proposal

Comments

@ctsims
Copy link
Member

ctsims commented Mar 17, 2020

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.

image

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).

image

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

Form Builder clip	version 1
id	type	labelItext:en-default	appearance
/gps_question_example	FieldList	gps_question_example	field-list
/gps_question_example/enter_a_full_address_here	Text	Enter a full address here	geopoint_address
/gps_question_example/gps_coordinates	Geopoint	GPS Coordinates	null

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.

@ctsims ctsims added the CEP CommCare Enhancement Proposal label Mar 17, 2020
@ctsims
Copy link
Member Author

ctsims commented Mar 17, 2020

@benrudolph This is the example I mentioned

@benrudolph
Copy link
Contributor

benrudolph commented Mar 17, 2020

Ok nice, thank you, will have a look and follow up with questions

@benrudolph
Copy link
Contributor

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

@ctsims
Copy link
Member Author

ctsims commented Mar 18, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CEP CommCare Enhancement Proposal
Projects
None yet
Development

No branches or pull requests

2 participants