handling current location

[courtney-rosenthal]

It looks like there currently are two location markers: a house and a person.

Can we just have one?

Use Cases

Initial load

• Perform automatic geolocation to obtain lat/lng of current position.
• Place marker at current location.
• Reverse lookup current location (lat/lng) to street address, and place address in address field.
• Query voteatx webservice at current location.
• If voteatx query succeeds: place voting places, set district info.

  Address typed into address field.

• Clear any currently displayed icons, regions, district info.
• Perform geolocation query on address to get lat/lng, and make that the current location.
• Place marker to current location.
• Query voteatx webservice at current location.
• Place voting places, set district info.

  Marker gets moved to a location or a click event occurs on the map

• Clear any currently displayed icons, regions, district info.
• Identify lat/lng of the selected position, and make that the current location.
• Place marker to current location.
• Reverse lookup current location (lat/lng) to street address, and place address in address field.
• Query voteatx webservice at current location.
• Place voting places, set district info.

[avickers]

We are addressing two separate "user stories."

User Story 1 (US1) is to help users find their district info. User Story 2 (US2) is to help users find nearby polling stations.

If we are going to use Geolocation to automatically place a marker at the current location, then we absolutely cannot just populate the precinct and city council district information, as this runs a risk of confusing users. I understand that you do not feel that this is a serious risk, but I do on the grounds of inclusiveness. Some of the users most likely to need help figuring out their voting information are also the same that are easily flummoxed by technology. It is a legitimate risk that they will accept the information provided by geolocation as their actual information without scrutiny. To some people, all new technology seems like magic. They won't understand that the app doesn't know they're at work or waiting in line at HEB. The tech economy is built around knowing information about consumers that they haven't deliberately provided. This is a red line for me.

The alternatives are making separate apps for each user story or using more UI complexity to clearly communicate that the geolocation driven results are for their current location and not their home location. The latter pretty much means an additional alert every time the app loads.

I think the dual markers is the lesser of two evils because:

• Nothing lowers user satisfaction like multiple dismissible modals (alerts);
• Having multiple modals at once makes it much more likely that users won't actually read them and will reflexively close them; and,
• This is likely to net the least amount of inconvenience.

Finding the nearest polling stations is likely to be the most common use case for the app. Dual markers doesn't delay that at all. The extra context approach will popup a modal that will have to be dismissed on smaller screens, and stress many people on any screen size. (The time it takes to complete something on a website doesn't add to frustration, as long as the tasks/latency seems reasonable. Website delays that seem unreasonable induce stress, as measured by MRI doohickeys.)

Typing in an address can take a little time, depending upon how quickly autocomplete finds the correct one, but this is something that should need to be done between zero and a few times. Both the county and newspaper have maps with overlays of every district, and that's truthfully the most efficient way to help people find that info. What we're better at than everyone else is finding nearby polling stations, so my preference would be to not inconvenience what we're best at for the sake of the marginal use case.

Typing in the address is much more likely to be perceived as a legitimate delay--and not induce stress--than dismissing a modal stating the obvious for 90%+ of people. Unfortunately, we must account for the 1, 5, or 10 percent of people that would be shocked that we don't magically know their home address. Just like the airline stewardess has to explain how a seatbelt works every flight. Inclusiveness can be inconvenient, but I feel strongly that it is the right thing to do. If you prefer one of the other approaches, we can test it out.

The biggest issue is the city apparently cares most about US1, but the app we've developed is really much better suited to US2. The best approach to US1 is just to show a zoomable map of the city with all of the council districts drawn in different colors--end of story. By disabling geolocation, they're disabling the biggest selling point of our app--conveniently finding nearby polling places. This is awkward, and what really should have happened is what the new Play Book that Kerry shared recommends and had someone from the city on the team and more involved in the process to help shape the development of the app and better understand these issues and tradeoffs. We've followed the old waterfall method, rather than properly using an agile approach.

[courtney-rosenthal]

resolved