Contrib.social

Suggestions to solve UX issues with Proximity Form Field location based views

Open on Drupal.org →
Created on 10 November 2024, 6 months ago

Problem/Motivation

Hi all,

For a fairly large location based website, I'm facing some serious UX issues. It has proximity based views on the most important landing pages, taxonomy pages, and nodes. One big problem is that there is no way to remember the user's location. So every page loads twice as the location is fetched for each page load repeatedly.

The biggest complaint from users is for catalog pages, where the page reload usually happens just as people are trying to filter the results. It is also annoying to users that they've scrolled down a list of posts, and then the page load occurs and takes them back up the page.

Another issue is that no IP based sorting is available, that would be great to have as a fallback for when people don't have GPS on their device (Desktops, etc), or when they don't want to grant location access. That's especially the case for new users not yet familiar with the platform.

These are basically the features https://www.drupal.org/project/ip_geoloc → provided back in the day. Unfortunately, development for D8, 9, 10, and up seems to have stalled (#[1938750]).

It would be really great if the Geofield module could implement the settings from that module:
- Remembering user location once geo-located
- Setting the URLs where location should be determined
- Fallback to smart IP ( #1901750: Integrate Smart IP with Geofield's Views proximity handlers → )

Steps to reproduce

- Create 2 pages with proximity based views that sort based on the Proximity Form Field set to "Client location" with "Auto-submit form" checked and "Hide coordinates form" set. Add some exposed filters to the second view on the second page.

- Navigate to the first page, grant location access. The page will reload.
- Navigate to the second page, change some of the filters and the page reload will happen again, interrupting and resetting your filter options.
- View the site on a device that is not GPS enabled and see how the proximity based views are no longer relevant to the user because there is no IP fallback.

Proposed resolution

- Store the user's location in a session variable just like the ip_geoloc module used to do, and make it available to views for sorting.
- Add SmartIP or something similar as a fallback option in case user location can't be determined via GPS.

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Active

Version

1.0

Component

Code

Created by

🇹🇭Thailand AlfTheCat

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @AlfTheCat
  • Comment 6 months ago →
    🇹🇭Thailand AlfTheCat
  • Comment 6 months ago →
    🇹🇭Thailand AlfTheCat

    Another UX issue I would like to add, is that with the current implementation, refreshing the page prompts a "confirm form re-submission" dialog to the end user. The problem with that is, is that in doing so the user actually re-submits the original location data. So if the user moves from point A to point B, and refreshes the page in their browser, instead of seeing updated proximity values based on their new location B, they see the old data from point A. This is completely counter-intuitive to the end user because they expect that a page refresh would show the data based on their new location.

  • Comment 6 months ago →
    🇮🇹Italy itamair

    Thanks @alfthecat for reporting this.
    As immediate feedback I would highlight to you that the "Client Location Origin" (id: geofield_client_location_origin) is a @GeofieldProximitySource Drupal Plugin, like any other @GeofieldProximitySource ones (that implement GeofieldProximitySourceInterface),
    and that you, as everybody else, can implement your own @GeofieldProximitySource Drupal Plugin in a custom module,
    and thus try to implement all the features that you further require as custom.

    I might find some spare time to better go through this feature request of mine (I couldn't reproduce your use cases yet, and make it more mine) but in the meanwhile I welcome you to eventually contribute in start developing / drafting yourself the @GeofieldProximitySource plugin & related functionalities that you have in mind / need ...

  • Comment 6 months ago →
    🇹🇭Thailand AlfTheCat

    Hi @itamair, thanks very much for your attention to this and your guidance. I'm indeed looking into developing and contributing a solution and it's very helpful to know about the @GeofieldProximitySource Drupal Plugin.

    My thoughts so far are to look at a javascript based implementation of storing a visitors lat/long in Localstorage and passing that data on to views.

    I will study the plugin and it will be great if I can share a working implementation here once I establish one, and maybe get your thoughts on it.

  • Comment 6 months ago →
    🇮🇹Italy itamair

    Sure @alfthecat ...
    The Localstorage (or may be better Sessionstorage) approach looks promising, but I don't know if it could be kept embedded only in the new dedicated @GeofieldProximitySource Drupal Plugin.
    If not, may be you could also propose some patch / Merge Request to the whole Geofield Proximity system itself ...

    Please keep me updated on your progresses, Pretty curious about those.

  • Comment 5 months ago →
    🇹🇭Thailand AlfTheCat

    Awesome @itamair, excited to work on this. I'll keep you posted, thanks very much.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024