Usability: selected map pins aren’t prominent enough

[fancyham]

A selected location makes the map pin a tiny bit larger, but very hard to tell if a pin is selected or normal, and which pin is selected.

Recommend trying:

Make selected map pin selected state more obvious. Significantly or perhaps better: a colored outline or something similar.

For example, Google map pins grow about 50-80% and sometimes change shape.

Apple Maps grows selected location pin about 100%

[fancyham]

• Take a look at Meals/Pantry icons don't match order of filter buttons #927 that has some detail about where these SVG files live.

[souronion]

I uploaded the SVG files onto the team's Google Drive: https://drive.google.com/file/d/1fc89FT-ym50gMZ8BA9ePJ67xi6i_hZPA/view?usp=sharing

Here are the screenshots of the two versions:

[entrotech]

@souronion The G-Drive link above only gives you one of the svg's. The link to the folder of SVGs is https://drive.google.com/file/d/1fc89FT-ym50gMZ8BA9ePJ67xi6i_hZPA Thanks for creating them!

[fancyham]

Record keeping:

@entrotech wrote in Slack:
To implement a quick and dirty test of the two styles @ning Zhang created for the Selected Organization Map Icons, I pushed a version to development with the two options. I used Option 1 on the https://devla.foodoasis.net site and Option 2 on the devhi.foodoasis.net site. I'd like for us to choose between the two options by Thursday's meeting.
What we are testing is the usability of two different options for the appearance of the map pin used for the marker of the selected organization.

@fancyham wrote:
Looking at the two, I lean towards Option 2 (Hawaii) because I found it more visible than Option 1. That pin has a kinda weird shadow on my machine, though (Mac Safari 15.1) where I saw a hard right edge on the shadow:

The hard right edge is probably because of some editing I did. The clickable area on the map is the entire svg canvas, and the canvas for the original svg was a quite large invisible rectangular area around the new pin, which causes it to overlap any other pins that are under the canvas, making the underlying pins unselectable by the user (for no apparent reason to them). Moreover, there are limited options about which part of the rectangular svg canvas can be anchored to the intended (lat, long) coordinates, and "bottom center" is the appropriate one for our purposes. This means that the rectangular area extends to the left of the pin point as far as it does to the right. To mitigate this, I clipped the invisible part of the svg, but probably went too far to accommodate the entire shadow. It wasn't very noticeable on the devices I tried, but is pretty apparent in Bryan's case.
Maybe you folks can play with this to see if you find that unselected pins crowded around the selected pin cannot be selected. There might be three options:
(preferred) See if there is a way to restrict the clickable area of the icon smaller than the entire svg.
Increase the svg rectangle size to avoid clipping, and tolerate the unclickable pins under the large svg.
Maybe reduce the blur of the shadow a bit, so the clipping is mitigated.
We can discuss on Thursday. I also have a preference for Option 2 - hopefully, it's not just because the pins are less dense in Hawaii.

@entrotech wrote:
Actually, when marker svgs overlap, the one that gets painted last is "on top" of the earlier rendered svgs, so the "selected" svg isn't necessarily on top of the ones around it. Might need to work on this as well... I think we want the ones further west and south to be on top of the ones to their east and north. That would actually help with the above issue.

@fancyham fancyham wrote:
Yeah, we probably do want pins to the east and north to be clickable.
If necessary, another option:
4. No blur or a really tiny one, kinda like this

[other support for option 4…]

@souronion wrote:
Ning Zhang 10 hours ago
Hi everyone. :) I also prefer option 2 since it stands out more among the other pins. I’m okay with having no drop shadow for option 2, given that the white color has provided enough contrast against the others.

[fancyham]

We all voted unanimously for version 2, option 4!

• Looks nice and obvious
• Dropshadow is nice but not necessary, so option 4 is good.

entrotech said that clickable area is actually a rectangle, so anywhere there's a dropshadow will eat clicks, even if user was clicking on something somewhat visible behind the dropshadow. So removing or minimizing drop shadow is a good idea.

@entrotech will try to reduce shadow and replace, but if can't do that, will do one without a dropshadow.

[entrotech]

@souronion @fancyham Can we close this issue? It has been deployed to production. I wanted to get one last check that it works as you intended.

[fancyham]

@entrotech looks good to me. Good job everyone!