Improving User 'Discovery' on OFN Map

I realised I’m not running locally so I need to set up a call with you so I can see :see_no_evil: sorry!!! actually the issue has screenshots and maybe if you make a video and share it, that’d be enough?

The reason I added this here is because many users, when entering their address, don’t pay attention to if it’s accurate or not. They assume it is accurate because most systems are looking at well-documented lat longs, city-based data. This was added in to ‘alow the user down’ to really look at the map and say, yes, this is right because our main complaint was users were entering their addresses of rural farms and the existing data plots a pin ‘anywhere’ on their land, possibly the cowshed. This way they can drag the pin to the main house or office which is largely undocumented.

I think the text when selecting “not accurate” is much too long. People won’t read this. My proposal: Drag and drop the pin to the accurate position and click “continue”.

I agree that ‘people don’t read’ but I think I asked that this be selected before a user can continue. In some UI cases such as this we want to give users friction in order to not cause them problems further down the line.
I’d be happy with a ‘Yes’ or 'No radio button but me and Julie discussed that without the ‘yes it’s accurate’ and ‘Not - not accurate’ sometimes users don’t know what the selection is referring to. This is what we call a contextual selection button. The yes and no have context and it’s easier to figure out the answer.

There seem to be two spaces in the headline between “First” and “need”. Maybe in this mockup only, but should be checked. Is there “we” or “OFN” missing between the spaces?

It’s worth digging into the CSS for this one but I expect that’s just the kerning of this particular font. It’s not the most legible web font and I expect we’ll improve this when we have the time.

Instead of the two radio buttons “yes - accurate” and “no - not accurate”, what about just one mandatory checkbox , labeled: I confirm that the indicated position of the enterprise on the map is correct. (or similar). Above the map we could add: Drag and drop the pin to the correct location if not accurate. (or similar). The marker dragging would always be enabled - I think this is what users would expect anyway.

I’m happy to go with this proposal. Agreed moving map pins is an expected user interaction for UI and map savvy users. I’ve tested with people who don’t use computers much and moving a map pin is not something they knew intuitively but happy to test this previous experience.
I think perhaps we chose the yes and no radios because Julie was concerned with something code/data map load wise about an ‘always changeable’ map. But I don’t quite remember our conversation @julia.e.carney

I still think we need the help text which is the ‘Due to many producers…’ again that’s the context for us wanting the users to take extra care on the map/address page. We don’t want delivery drivers and shoppers showing up to a field for pick up. We want them to show up to the right place.

thanks for checking and commenting. I can understand most of the things you explained.
To summarize:

  • We use the button “Locate address on map”.
  • We will have the explaining text “Due to…”. I might find a shorter text in the German translation. :wink:
  • Instead of the radio buttons let’s go for one checkbox “I confirm …” that must be checked before continuing.
  • “Continue” is only enabled, when “Locate address on map” has been clicked and the checkbox “I confirm …” is checked.

So clicking “Continue” without the given preconditions above should display a hint: Please locate address on map first and confirm that the position of the pin is accurate.

To be confirmed by @julia.e.carney (technical reasons):

  • Pin dragging is enabled as soon as the “Locate address on map” button is clicked.


  • I thought that this was not a correct English sentence: “First need to know a little bit about your enterprise.” To me it sounds like there is something missing after “First” - but you are the native speaking people here.
  • My intention was not to remove the “it’s accurate” and “it’s not accurate” labels of the radio buttons. That would be fine if we still had the radio buttons. I meant to shorten the explaining text “Due to …”. Nevermind.

Does that make sense?

1 Like

Oh you’re right! it’s missing a ‘we’ so ‘First we need to…’

Just linking to where this is being managed in product / inception pipe here

Hi @Kirsten, @Erioldoesdesign, @konrad and @luisramos0,

I have a new PR here: 6584 map location confirm by julesemmac · Pull Request #6825 · openfoodfoundation/openfoodnetwork · GitHub. @luisramos0 I’m not used to rebase, I just grabbed a fresh copy of master and reapplied the changes from my other PRs :woman_shrugging: @Erioldoesdesign and @konrad, I tried to get your changes applied as best as I could interpret them… I included a video in the PR, please have a look and let me know if you need tweaks. The bigger thing you’ll notice I didn’t include was disabling the continue button should the user not click the checkbox to confirm the accuracy of the location. The reason for that is that if their entered address never allows a pin to show up on google maps, they won’t really be able to confirm and would be permanently blocked. Another reason is that @luisramos0 asked me to include a condition that disables this update if google maps is not enabled… if that’s possible, then it has to be ok for them to continue with the process without ever having seen the confirm button. In future, you may want to make a change to force them to choose a location with the pin and confirm it before continuing, but it seems like we’d need a few more steps.


Makes total sense why you went this route and no worries. There will still be a potentially inaccurate mailing address so they can continue. It’s best to (obviously) not have users perma blocked :smiley:

Thanks for all your hard work on this @julia.e.carney

Hey @julia.e.carney,
love it! :smiley:
Thank you so much!

Thanks so much @julia.e.carney - really appreciate your effort to get this across the line :slight_smile: we’ll have a look and :crossed_fingers:

1 Like

Thanks everyone, and thanks for your work and suggestions as well. Thanks to Cillian as well, who added into my branch for the downstream/backend part of the flow. Hopefully it’s close to being ready! We shall see how it does in PR and testing.


I know we are just tackling a focused part of our discovery wishlist now. But I wanted to just share here for future reference a couple of recent discover tools that got me thinking about OFN…

The first is a regenerative agriculture map - what I like: farms can create their own profile for the map, and the mapped profile is by donation. Doing that seems like the ‘map’ becomes a gateway to additional features that are charged for. So the map fits nicely in a business strategy. THe profile modals (maybe I have the wrong term) are very clean with links to more info, searchable by categories - and then the results align nicely along the side of the screen, but there is also a keyword search. Click ‘more filters’ to search by certification status (we’d call this properties), way of selling … And you can drag a pin to a location where you want to search nearby. I also like that someone can ‘recommend a farm’ - who the mappers then presumably contact…

The second is a different approach to local product discovery. Not a map - but a search by region approach. Its a ‘storefront’ approach. Its focuses isn’t food and farming. But I could imagine this. It doesn’t have the filtering we would want - but I like how it gives profile to whichever profile is selected.